[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