Red Hat Bugzilla – Bug 144797
ipsec sends packets out wrong interface
Last modified: 2007-11-30 17:10:58 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):
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
IPSEC is the only network related problem we are having... the
standard routing and firewall seems to be working normally.
Tested this evening w/ latest fedora kernel:
the bug is still present.
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
This indeed looks fixed by the ipsec-tools update. Thank you!