Red Hat Bugzilla – Bug 145846
problem with netfilter and ipsec
Last modified: 2007-11-30 17:10:58 EST
Description of problem: There is a problem with the FC3 kernel kernel-2.6.10-1.741_FC3 The problem doesn't appear when booting with kernel-2.6.9-1.681_FC3 I have created an IPSEC tunnel between two networks over the internet. When I try to ping a host in the internal network I have a problem because the ipsec gateway (running FC3) doesn't forward the ICMP echo reply packet. The packet is received in the outside interface (as shown by the tcpdump logs) showing the ESP encapsulated icmp echo request and the reply packet. 10:45:32.952817 IP 213.16.151.39 > 62.38.193.194: ESP(spi=0x0afc9507,seq=0xb) 10:45:33.043123 IP 62.38.193.194 > 213.16.151.39: ESP(spi=0x0ab64ab7,seq=0xb) 10:45:33.043123 IP 192.168.0.4 > 10.3.0.8: icmp 64: echo reply seq 71 however from the internal network we only get the ICMP echo request: 10:48:37.964391 IP 10.3.0.8 > 192.168.0.4: icmp 64: echo request seq 256 10:48:38.963640 IP 10.3.0.8 > 192.168.0.4: icmp 64: echo request seq 257 10:48:39.963499 IP 10.3.0.8 > 192.168.0.4: icmp 64: echo request seq 258 10:48:40.963390 IP 10.3.0.8 > 192.168.0.4: icmp 64: echo request seq 259 Version-Release number of selected component (if applicable): kernel-2.6.10-1.741_FC3 problem kernel-2.6.9-1.681_FC3 OK How reproducible: Steps to Reproduce: 1. Boot with kernel-2.6.10-1.741_FC3 2. create an ipsec tunnel between two networks 3. ping from the inside of one network to the inside of the other network 4. verify that ping fails to work Actual results: ping fails, ICMP echo reply are NOT forwarded Expected results: ping works, ICMP echo reply ARE forwarded Additional info:
Created attachment 110088 [details] gateway iptables configuration
The problem exists also withe the following simple iptables configuration: # Generated by iptables-save v1.2.11 on Sat Jan 22 11:01:47 2005 *mangle :PREROUTING ACCEPT [35788:8346069] :INPUT ACCEPT [17225:1329797] :FORWARD ACCEPT [15377:6749388] :OUTPUT ACCEPT [13496:2656364] :POSTROUTING ACCEPT [28823:9531852] COMMIT # Completed on Sat Jan 22 11:01:47 2005 # Generated by iptables-save v1.2.11 on Sat Jan 22 11:01:47 2005 *filter :INPUT ACCEPT [162:13225] :FORWARD ACCEPT [48:4032] :OUTPUT ACCEPT [102:16280] COMMIT # Completed on Sat Jan 22 11:01:47 2005 # Generated by iptables-save v1.2.11 on Sat Jan 22 11:01:47 2005 *nat :PREROUTING ACCEPT [2151:189759] :POSTROUTING ACCEPT [1069:144712] :OUTPUT ACCEPT [33:3432] -A POSTROUTING -s 10.3.0.0/255.255.255.0 -o ippp0 -j MASQUERADE COMMIT # Completed on Sat Jan 22 11:01:47 2005
I'm seeing something like this also. At first I thought it was my routing tables or my iptables, but I've quickly exhausted every fix and test case I can think of. I too have a working setup with 2.6.9-1.681 (patched to handle the ipsec/NAT bug). I'm attempting to make another setup where both sides are 2.6.10.766_FC3 (again patched to handle the ipsec/NAT bug) and weird stuff is happening: 1. ping gateway to gateway WORKS (I have both a tunnel and transport setup) 2. ping gateway to remote host FAILS -- the ping gets encapsulated and sent to the remote gateway and there enters PREROUTING chain and then is dropped/lost for no apparent reason 3. ping host to remote host FAILS -- generates ICMP dest_unreach net_unreach on local gateway. Doesn't generate any traffic over the ipsec link. This may be a routing issue, but my routing is simple and I'm pretty sure it is correct (works on 2.6.9). I'll do more testing on 2.6.10 and check out some other bugs and report back.
duplicate of 145773 ? Fix is try ipsec-tools-0.5-rc1? I'll test that out. 145507 could possibly be related. Looks like new semantics for us folk doing manual setkey stuff. Must add fwd spd's. This sounds most promising.
Ta-da! It's magic! Add yourself some matching -P fwd rules for every -P in spdadd you do with setkey. Definitely this is a usage issue "feature" that changed between 2.6.9 and 2.6.10. I'm not sure how a newer ipsec-tools would help, unless it automatically adds fwd's for every in? That would not really make sense. This bug will hit anyone who has a working MANUALLY CONFIGURED 2.6.9 ipsec setup and then upgrades to 2.6.10. It will just stop working for most packet traversal cases. Hopefully they will see this and not waste 3 hours troubleshooting like I did! If you use the (redhat specific?) ifup-ipsec scripts then the next version will probably fix the problem automatically for you (ala bug 145507). So this bug isn't really a bug as there's really nothing to fix (on the vendor side).
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
Note, as per other bugs on this subject, the newer ipsec-tools and/or other packages have this problem fixed so you don't need to manually add fwd rules anymore. So this bug was just a transient problem. As of ipsec-tools-0.5-2.fc3 the behaviour should be the same as it originally was. Also note, adding the fwd rules anyways didn't seem to hurt anything, even with the updated packages. Don't quote me on that though.