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.
Tested this evening w/ latest fedora kernel: kernel-smp-2.6.10-1.741_FC3 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 Thanks!
This indeed looks fixed by the ipsec-tools update. Thank you!