[Openswan Users] 26Sec to OpenSwan-1.0.3 dual-subnet routing problem

linkst8.ipsec at scriptable.net linkst8.ipsec at scriptable.net
Sun Jun 13 13:06:18 CEST 2004


Hello list-ers...

I've been lurking and watching for a few weeks now in hopes of
stumbling across someone with similar problems who has the
answer.  I have also downloaded the archives, and grepped through
them with little success as well.  I have had quite a bit of
success so far interoperating 26Sec (Slackware 2.6.6 kernel) with
OpenSwan 1.0.3 (Redhat 2.4.20-30.9 kernel) between NAT'ed
subnets, but have run into one snag that I can't seem to get
around.

Here is the network layout:

             10.5.5.0/24
                  |
               10.5.5.1
               1.2.3.4   <-- 26Sec NAT gw
                  |
                  ^
                 / \   <-- Internet
                /   \
        --------     --------
        |       \   /       |
     5.6.7.8     \ /     9.8.7.6   <-- OpenSwan 1.0.3 NAT gw's
   172.16.5.1     v    192.168.0.1
        |                   |
 172.16.5.0/24       192.168.0.0/24
                            |
                       192.168.0.4
                       10.10.10.1   <-- Linux router
                            |
                     10.10.10.0/24

I have IPSec connections between all 3 gateways to allow the
NAT'ed subnets behind them to see each other.  (Each gw has
a connection to each other gw)

EVERYTHING works with one small exception:

The 172.16.5.0/24 network CAN see both subnets 192.168.0.0/24 and
10.10.10.0/24 without issue.  This was done by simply duplicating
the connection in ipsec.conf and changing the subnet as needed.
Also, the 10.10.10.0/24 network can route out to the
172.16.5.0/24 network without issue.

The subnet behind the 26Sec gateway (10.5.5.0/24) can ping both
of the other NAT'ed networks.  (192.168.0.0/24 and 172.16.5.0/24)
Likewise, both of the other networks can ping the 26Sec subnet.

However...  (here comes the broke part)

The subnet behind the 26Sec gateway (10.5.5.0/24) does not get
any responses from the subnet behind the OpenSwan 1.0.3 gateway
(10.10.10.0/24).  10.5.5.5 can ping to 10.10.10.5, and the
responses come back, but disappear somewhere within the routing
table of the 26Sec system.

Using tcpdump from the 26Sec box, and watching the ESP packets
shows me that when I ping from a system in 10.5.5.0 to any ip in
the 10.10.10.0 net, responses are coming back to the 26Sec gw,
but are not being passed on to the inside network.  I have the
same configuration setup as in the 1.0.3 box that works.  I will
attach the 26Sec configs in-line for verification:

conn %default
    keyingtries=0
    keylife=1h
    disablearrivalcheck=no
    authby=rsasig
    compress=yes
    pfs=yes
    leftupdown="ipsec _updown_x509"
    rightupdown="ipsec _updown_x509"

conn netone
    left=9.8.7.6
    leftsubnet=192.168.0.0/24
    leftid=@gw.somewhere.com
    leftrsasigkey=blahblahblahblahblahblah...
    leftnexthop=%defaultroute
    right=1.2.3.4
    rightsubnet=10.5.5.0/24
    rightid=@gw.somewhere.net
    rightrsasigkey=blahblahblahblahblahblah...
    rightnexthop=%defaultroute
    auto=start

conn netone-2
    left=9.8.7.6
    leftsubnet=10.10.10.0/24
    leftid=@gw.somewhere.com
    leftrsasigkey=blahblahblahblahblahblah...
    leftnexthop=%defaultroute
    right=1.2.3.4
    rightsubnet=10.5.5.0/24
    rightid=@gw.somewhere.net
    rightrsasigkey=blahblahblahblahblahblah...
    rightnexthop=%defaultroute
    auto=start

The conn statements are identical with the ones on the 1.0.3 box.
Again, everything but the netone-2 conn functions properly.  By
all appearances, the 1.0.3 box is responding properly, and sending
the secured data back, the 26Sec is losing it somewhere in either
the iptables, or routing table.  I am getting nothing in my logs
indicating that iptables is dropping any of it.  This leaves me
with a possible routing problem.  Here is my routing table after
making the connections:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.0      1.2.3.1         255.255.255.0   UG    0      0        0 eth0
172.16.5.0      1.2.3.1         255.255.255.0   UG    0      0        0 eth0
10.5.5.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
1.2.3.0         0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     1.2.3.1         255.255.255.0   UG    0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         1.2.3.1         0.0.0.0         UG    0      0        0 eth0

One final piece of information I'd like to provide, is my
firewalling script.  I am using Jay's firewall, and have added
the following to the firewall-custom.rules file to ensure all
IPsec traffic is given free passage.  If any of you notice any
discrepancies in my logic (or security) with this script, I'd
greatly appreciate any suggestions to fix that as well.  I wrote
this based on a very loose grasp of how 26Sec now handles IPsec
in the kernel without an ipsecx interface.  Mostly just gleaned
from reading other people's interpretations of how it should
function.  I'm sure it's probably rife with holes the way I have
implemented it... so please at least look at this part.

Here is the script:

#!/bin/sh

IPSECGWS="9.8.7.6 5.6.7.8"

IPSECNETS="192.168.0.0/24 10.10.10.0/24 172.16.5.0/24"

IINT="eth1"
EINT="eth0"

for gw in $IPSECGWS
do
    /usr/sbin/iptables -I INPUT -i $EINT -s $gw -j ACCEPT
    /usr/sbin/iptables -t nat -I POSTROUTING -o $EINT -d ! $gw -j MASQUERADE
done

/usr/sbin/iptables -I FORWARD -i eth1 -o $EINT -j ACCEPT
/usr/sbin/iptables -I FORWARD -i eth0 -o $IINT -j ACCEPT

for net in $IPSECNETS $IPSECGWS
do
    /usr/sbin/iptables -I INPUT -s $net -j ACCEPT
    /usr/sbin/iptables -I INPUT -d $net -j ACCEPT
    /usr/sbin/iptables -I OUTPUT -s $net -j ACCEPT
    /usr/sbin/iptables -I OUTPUT -d $net -j ACCEPT
    /usr/sbin/iptables -I FORWARD -s $net -j ACCEPT
    /usr/sbin/iptables -I FORWARD -d $net -j ACCEPT
done

Thanks for taking the time to look this over, and thanks in
advance to anyone who chooses to assist me with this little
issue.  If there is any further information needed, please don't
hesitate to let me know.

Charles Jones
-- 
For a copy of my public key, send an email to gpgkeys _at_ scriptable _dot_ net with "send pgp key" in the subject.

A Windows user spends 1/3 of his life sleeping, 1/3 working, 1/3 waiting.


More information about the Users mailing list