Bug 145507 - ipsec spd does not work with kernel 2.6.10 for routing
ipsec spd does not work with kernel 2.6.10 for routing
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2005-01-18 23:13 EST by Bryan Clingman
Modified: 2014-03-16 22:51 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-19 23:29:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bryan Clingman 2005-01-18 23:13:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)

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

How reproducible:

Steps to Reproduce:
1. install 2.6.10
2. try to ping through a router with an IPsec vpn

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;
> spdadd $SRC $DST any -P fwd ipsec
>             ${KEY_ESP_IN:+esp/transport//require}
>             ${KEY_AH_IN:+ah/transport//require}
>           ;
> spddelete $SRCNET $DSTNET any -P fwd;
> spdadd $SRCNET $DSTNET any -P fwd ipsec
>             ${KEY_ESP_IN:+esp/tunnel/$DST-$SRC/require}
>             ${KEY_AH_IN:+ah/tunnel/$DST-$SRC/require}
>           ;
> spddelete $SRC $DST any -P fwd;
> spdadd $DST $SRC any -P fwd ipsec
>           esp/transport//require
>           ah/transport//require
>           ;
> spddelete $SRCNET $DSTNET any -P fwd;
> spdadd $DSTNET $SRCNET any -P fwd ipsec
>           esp/tunnel/$DST-$SRC/require
>           ah/tunnel/$DST-$SRC/require
>           ;
Comment 1 Bill Nottingham 2005-01-19 00:24:48 EST
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 01:24:48 EST
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: 
Comment 3 Bill Nottingham 2005-01-19 12:54:43 EST
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 14:18:46 EST
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 14:47:00 EST
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-19 23:41:46 EST
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 09:48:27 EST
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 11:06:09 EST
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 12:53:49 EST
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.