Bug 144797 - ipsec sends packets out wrong interface
ipsec sends packets out wrong interface
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-01-11 11:49 EST by Aaron Straus
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: ipsec-tools-0.5-0.fc3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-06 19:16:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Aaron Straus 2005-01-11 11:49:35 EST
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)

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

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.

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):

How reproducible:

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-14 19:43:30 EST
Tested this evening w/ latest fedora kernel:


the bug is still present.
Comment 2 Aaron Straus 2005-03-04 20:09:30 EST
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
Comment 3 Aaron Straus 2005-03-06 19:16:46 EST
This indeed looks fixed by the ipsec-tools update.  Thank you!

Note You need to log in before you can comment on or make changes to this bug.