Bug 145507 - ipsec spd does not work with kernel 2.6.10 for routing
Summary: ipsec spd does not work with kernel 2.6.10 for routing
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts   
(Show other bugs)
Version: 3
Hardware: All Linux
medium
low
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-19 04:13 UTC by Bryan Clingman
Modified: 2014-03-17 02:51 UTC (History)
3 users (show)

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: ---


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.