Bug 144797

Summary: ipsec sends packets out wrong interface
Product: [Fedora] Fedora Reporter: Aaron Straus <aaron>
Component: kernelAssignee: David Miller <davem>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: davej, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: ipsec-tools-0.5-0.fc3 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-07 00:16:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Aaron Straus 2005-01-11 16:49:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041128 Firefox/1.0 (Debian package 1.0-4)

Description of problem:
we have a fedora i386 hyperthreaded box routing between two interfaces
eth0 (external) and eth1 (internal).

we run ripd and have many firewall rules on the box.

in addition we run racoon and use this box as our IPSEC (tunnel mode)
gateway. 

as of 2.6.9-1.681 everything was fine.  Once upgrading to 2.6.9-1_724
we are noticing the following:

NORMAL:
o   racoon negotiates the connection with the peer correctly.
o   packets are encrypted from our internal network fine and the peer
    receives them fine.
o   the peer responds and the packets are decrypted correctly.

BUG:
o   _BUT_ the packets coming in have destination address on our 
    internal network so you'd expect them to go out on eth1.  
    However, as of the _724 kernel they go out on eth0???
    We can see this by doing a tcpdump...

If we reboot to 681 the problem disappers (packets go out on eth1).
We've checked the routing tables and it's clear the packet should
be destined to go out eth1.  

You can also ping an internal machine fine from this box and as you'd
expect the packet goes out eth1 so it seems to only be an IPSEC problem?

Anyway thanks.  We will try the latest kernel this afternoon to verify
the problem is still in 2.6.10-1.737_FC3.


Version-Release number of selected component (if applicable):
kernel-smp-2.6.9-1.724_FC3

How reproducible:
Always

Steps to Reproduce:
1.  setup a router as described
2.  boot kernel 724
3.  try IPSEC
    

Actual Results:  decrypted packets destined for the internal network
leave eth0 despite a routing table that says they should leave eth1

Expected Results:  decrypted packets destined for the internal network
leave eth1

Additional info:

IPSEC is the only network related problem we are having... the
standard routing and firewall seems to be working normally.

Comment 1 Aaron Straus 2005-01-15 00:43:30 UTC
Tested this evening w/ latest fedora kernel:

kernel-smp-2.6.10-1.741_FC3

the bug is still present.

Comment 2 Aaron Straus 2005-03-05 01:09:30 UTC
I believe upgrading to the latest ipsec-tools (ipsec-tools-0.5-0.fc3) solved
this with the most recent kernel.  I will test next week and respond here.  Many
Thanks!


Comment 3 Aaron Straus 2005-03-07 00:16:46 UTC
This indeed looks fixed by the ipsec-tools update.  Thank you!