Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Description of problem: the /etc/sysconfig/network-scripts/ifup-ipsec does not add spd forwarding rules. It only adds in and out rules. Kernel 2.6.10 requires forwarding rules. Version-Release number of selected component (if applicable): 7.93.5-1 How reproducible: Always Steps to Reproduce: 1. install 2.6.10 2. try to ping through a router with an IPsec vpn 3. Actual Results: packets going to the ipsec router would die and not be routed to the destination computer Expected Results: packets should go thru to the destination computer. Additional info: I have hacked the ifup-ipsec file as follows: # diff ifup-ipsec-old ifup-ipsec > spddelete $SRC $DST any -P fwd; 130a132,136 > spdadd $SRC $DST any -P fwd ipsec > ${KEY_ESP_IN:+esp/transport//require} > ${KEY_AH_IN:+ah/transport//require} > ; > 146a153 > spddelete $SRCNET $DSTNET any -P fwd; 162a170,174 > spdadd $SRCNET $DSTNET any -P fwd ipsec > ${KEY_ESP_IN:+esp/tunnel/$DST-$SRC/require} > ${KEY_AH_IN:+ah/tunnel/$DST-$SRC/require} > ; > 176a189 > spddelete $SRC $DST any -P fwd; 184a198,202 > spdadd $DST $SRC any -P fwd ipsec > esp/transport//require > ah/transport//require > ; > 197a216 > spddelete $SRCNET $DSTNET any -P fwd; 204a224,228 > spdadd $DSTNET $SRCNET any -P fwd ipsec > esp/tunnel/$DST-$SRC/require > ah/tunnel/$DST-$SRC/require > ; >
Just confirming, this worked on all 2.6.9-based kernels? Does the same script (adding of forward rules) fail on those kernels?
I just tested it with the other end of the vpn. It's running 2.6.6-1.435smp. It works with no complaints. Previously, the vpn worked from the 2.6.10 box to the 2.6.6 box, but not the other way. By this I mean that I could ping machines behind the 2.6.6 box from the 2.6.10 box. I could not ping machines behind the 2.6.10 box from the 2.6.6 box. I found the information about the fwd spd in this thread: http://lkml.org/lkml/2004/12/26/56
Do you need this change for host-to-host mode as well? It appears from the statement that this is only necessary for tunnel mode.
Also, I'd think for tunnels you'd actually need fwd in both directions; at least in the reference you cited, it wanted fwd on the incoming, but you've only set fwd on the outgoing.
initscripts-7.93.6-1 is in FC3 test updates now... please check to see if that works for you.
The fwd is in the incoming. I don't think outgoing fwd makes any sense. I'll try the 7.93.6-1 ASAP.
I just hit a similar bug (see 145846). Thanks to this bug report I was able to fix my manual ipsec setup by adding a -P fwd for every -P in. I did not add any outgoing fwd's, and my setup appears to be working 100% so it must be sufficient to only add fwd's on incoming. Thanks to Bryan for figuring this one out so I didn't have to waste more time trouble-shooting the wrong area (routing, iptables, etc).
This turned out to be not as straightforward as I thought. I was getting very weird results where I could ping from subnet A to subnet B but not back again(??). Following some new examples I found, I abandoned my transport+tunnel rules for all-tunnel rules. You can use 4 tunnel rules to handle all cases (gw-gw, nw-gw, gw-nw, nw-nw). All -P in rules need corresponding -P fwd rules. out rules do not. Lastly, I hit an issue where I forgot to disable MASQing on the nw-nw traffic across the firewall (openswan handled this different so my openswan config would break the new native ipsec). Make sure to exclude nw-nw traffic from any MASQing you are doing. Still sucks that to make NAT work over ipsec you must patch/compile your own kernel (143374). Now it all seems to work 100% as expected. I'm not sure how a newer ipsec-tools package will fix or break the workaround of adding -P fwd. Perhaps it adds fwd rules automatically when it sees someone forgot them?
Yes, the new ipsec-tools automatically adds fwd rules.