Bug 145507
Summary: | ipsec spd does not work with kernel 2.6.10 for routing | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bryan Clingman <bac> |
Component: | initscripts | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | davej, rvokal, trevor |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-04-20 03:29:29 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bryan Clingman
2005-01-19 04:13:02 UTC
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. |