[Openswan Users] IPSEC routing refuses to go through the tunnel

Greg Scott GregScott at InfraSupportEtc.com
Thu Mar 18 17:38:58 EDT 2010


I've been banging my head all day on this one.  I'm running an Openswan
tunnel between a HQ site and several branches.  These tunnels have
worked for years with no hassles.   After modifying the HQ system to use
bridging, now all my tunnels have turned to pure crap.  It has to be
something subtle I'm missing but I'm not getting it.  Here are details:

 

The home HQ site is the right, the branch site in Rochester on the left.
HQ is running Openswan 2.6.19.  Rochester is running Openswan U2.4.4.
The main HQ LAN is 192.168.3.nnn/24  The Rochester LAN is 172.21.7.0/24.


 

The problem is on the HQ side.  

 

>From a host inside the HQ network, I can ping anywhere I want inside
Rochester.  But when Rochester tries to ping anywhere inside HQ, the
pings just hang.  So do all other connection types.   Watching tcpdump
on the HQ side, I see the Echo Request/Echo Reply pairs go back and
forth as normal.   But Rochester never sees an echo reply come back.
Trying a traceroute from the HQ firewall to Rochester, instead of going
thru the tunnel, the packets wander out over the public Internet -
**outside** the tunnel - and eventually die.  Trying the same traceroute
from a host inside the HQ LAN works as normal.  

 

The answer has to be right in front of my face but I don't see it.  

 

I've also looked at some ip xfrm policy output and tried to decipher it.
Near as I can tell and comparing with other working tunnel networks, it
looks OK.  So how do I tell ipsec to stop messing around and route the
stuff I want through that tunnel?

 

Here is the relevant portion of /etc/ipsec.d/hq-ipsec.conf with dummied
up public IP Addresses:

 

##version       2.0     # conforms to second version of ipsec.conf
specification

 

# basic configuration

 

conn Rochester-Everywhere

        type=tunnel

        #

        # Left security gateway, subnet behind it, next hop toward
right.

        #

        also=rochester

        #

        # Right security gateway, subnet behind it, next hop toward
left.

        #

        also=hq

        rightupdown=/etc/ipsec.d/hq-updown.sh

        auto=start

.

.

.

include /etc/ipsec.d/sites.conf

 

 

Here is the relevant portion of my sites.conf file:

 

##version       2.0     # conforms to second version of ipsec.conf
specification

 

# basic configuration

 

conn hq

        right=1.2.3.50

        rightnexthop=1.2.3.49

        rightsubnet=192.168.0.0/16

        rightsourceip=192.168.3.5

        rightid=@hq.local

        # RSA 2192 bits   hq.lme.local   Wed Jul 19 21:09:32 2006

        rightrsasigkey=0sAQNb... 

 

conn rochester

        left=3.2.1.145

        leftnexthop=3.2.1.150

        leftsubnet=172.21.7.0/24

        leftsourceip=172.21.7.1

        leftid=@rochester.local

        # RSA 2192 bits   rochester.lme.local   Sat Oct 21 07:04:18 2006

        leftrsasigkey=0sAQNki3sx4...

.

.

.

And here is hq_updown.sh.  I've gone through a few different iterations
of this:

 

#!/bin/sh

 

LOCALNET1=192.168.0.0/16

LOCALNET2=10.200.1.0/24

 

##/usr/lib/ipsec/_updown $*

/usr/libexec/ipsec/_updown $*

if [ "$PLUTO_VERB" = "route-host" -o "$PLUTO_VERB" = "route-client" ];
then

    for dir in in out; do

        ip xfrm policy update dir $dir src $LOCALNET1 dst $LOCALNET1

        ip xfrm policy update dir $dir src $LOCALNET2 dst $LOCALNET2

    done

fi

 

# Route to Rochester

##/sbin/ip route change 172.21.7.0/24 dev br0 src 192.168.3.5 mtu 1400

 

One more clue.  Ip route show... will display the relevant routes after
restarting ipsec, relevant extract pasted in below.  But notice the
route to Rochester, 172.21.7.0/24  - it doesn't say scope link the way
other IPSEC routes on other hosts do.  This is a clue but I don't know
what it means.  

 

[root at lme-fw2 ipsec]# ip route show

.

.

.

1.2.3.48/28 dev br0  proto kernel  scope link  src 12.2.3.50

192.168.4.0/24 via 192.168.3.100 dev br0

192.168.3.0/24 dev br0  proto kernel  scope link  src 192.168.3.5

.

.

.

172.21.7.0/24 via 12.24.248.49 dev br0  src 192.168.3.5

.

.

.

default via 1.2.3.49 dev br0

[root at lme-fw2 ipsec]#

 

 

Thanks

 

-          Greg Scott

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20100318/4bb8ecf3/attachment.html 


More information about the Users mailing list