Bug 145507

Summary: ipsec spd does not work with kernel 2.6.10 for routing
Product: [Fedora] Fedora Reporter: Bryan Clingman <bac>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 3CC: 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
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
>           ;
>

Comment 1 Bill Nottingham 2005-01-19 05:24:48 UTC
Just confirming, this worked on all 2.6.9-based kernels?

Does the same script (adding of forward rules) fail on those kernels?

Comment 2 Bryan Clingman 2005-01-19 06:24:48 UTC
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

Comment 3 Bill Nottingham 2005-01-19 17:54:43 UTC
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.

Comment 4 Bill Nottingham 2005-01-19 19:18:46 UTC
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.

Comment 5 Bill Nottingham 2005-01-19 19:47:00 UTC
initscripts-7.93.6-1 is in FC3 test updates now... please check to see
if that works for you.

Comment 6 Bryan Clingman 2005-01-20 04:41:46 UTC
The fwd is in the incoming.  I don't think outgoing fwd makes any
sense.  I'll try the 7.93.6-1 ASAP.

Comment 7 Trevor Cordes 2005-03-02 14:48:27 UTC
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).



Comment 8 Trevor Cordes 2005-03-05 16:06:09 UTC
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?


Comment 9 Bill Nottingham 2005-03-07 17:53:49 UTC
Yes, the new ipsec-tools automatically adds fwd rules.