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

Thu Mar 18 22:43:37 EDT 2010

And now  I know the HQ site is routing my tunnel traffic in the clear
even though it should be routing it through the tunnel.  How do I know?
>From Rochester - ping a host inside HQ and watch tcpdump on the HQ
firewall.  Watching for -i br0 net 172.21.7.0/24, I see echo requests
and replies.   Breaking it down to physical eth devices, all looks as it
should.  But watching tcpdump looking for the public side of Rochester -
nothing.  No ESP, just dead space.  

Anything **initiated** from the HQ side works as it should.  But
anything with the HQ side **responding**  tries to route outside the
tunnel.  

OK, so what's different now than before?  The biggie - everything is
bridged now and it was a pure router before.  So now both the inside
(LAN) and outside (Internet) interface is br0 instead of eth1 and eth0.
I have other sites doing Openswan tunnels with bridged firewalls.  The
firewall rules are a little different now because it's a bridge.  But I
can drop all the filtering rules and the problem does not change.  I
also just put in some more nat PREROUTING rules to make sure I'm not
masquerading anything that should be part of a tunnel.  But this didn't
help.  

Why bridge?  Because a Cisco VPN Concentrator and a Sonicwall VPN device
were connected in parallel.  Neither of these work well behind a NAT
gateway.  We want them behind the firewall so I can see all the traffic
in and out of this network.  

So now that I have the problem well defined, it would be lots better if
I knew how to fix it.

-          Greg Scott

From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On
Behalf Of Greg Scott
Sent: Thursday, March 18, 2010 4:39 PM
To: users at openswan.org
Subject: [Openswan Users] IPSEC routing refuses to go through the tunnel

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/1734b88c/attachment-0001.html 