[Openswan Users] WinXP host - NAT - internet - openswan problems
Scott Miller
Scott.Miller at prioritytech.com
Fri Mar 9 19:29:38 EST 2007
Hi all,
I'm sending this message out after completely failing to get traffic to
actually flow. I've gotten tunnels to come up, but I'm not convinced
the configurations are correct, but any other combinations of
configuration work have failed to bring the tunnel up at all.
On WinXP we're using the ipseccmd.exe for xp sp2, we're using a script
to create the tunnel configurations, but on our test box, it generates
and then runs the following commands:
ipseccmd -1s 3DES-SHA-2 -1p -1k 1800S -n ESP[3DES,SHA]1800SPFS -f 0=* -f
(0:UDP=*:53:UDP) -t <openswan-address> -a preshare:"TestPassword"
ipseccmd -1s 3DES-SHA-2 -1p -1k 1800S -n ESP[3DES,SHA]1800SPFS -f *=0 -f
(*:53:UDP=0::UDP) -t <xp-address> -a preshare:"TestPassword"
>From the winXP address (10.1.7.90) it is being NATed to a routable
address by a firewall, and then it goes through the internet to hit our
OpenSwan box.
On our Openswan box, our configuration is thus:
# /etc/ipsec.conf - Openswan IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 1.15.2.1 2005/07/26 12:28:39 ken Exp $
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# plutodebug / klipsdebug = "all", "none" or a combation from
below:
# "raw crypt parsing emitting control klips pfkey natt x509
private"
# eg:
# plutodebug="control parsing"
#
# Only enable klipsdebug=all if you are a developer
#
# NAT-TRAVERSAL support, see README.NAT-Traversal
# nat_traversal=yes
#
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
#
# dumpdir=
forwardcontrol=no
fragicmp=yes
# hidetos=yes
# interfaces=%defaultroute
interfaces="ipsec2=eth2:136"
klipsdebug=none
# manualstart=
# overridemtu=1444 - WatchGuard is 1400
overridemtu=1400
#packetdefault=drop
pluto=yes
plutodebug=none
#plutoload=%search
#plutostart=%search
plutowait=no
# prepluto=
# postpluto=
# syslog=daemon.error
uniqueids=yes
#
# NAT Traversal patch
nat_traversal=yes
# defaults for subsequent connection descriptions
conn %default
auth=esp
authby=rsasig
# auto=start
compress=no
disablearrivalcheck=no
dpdaction=hold
dpddelay=10
dpdtimeout=35
keyexchange=ike
pfs=yes
rekeyfuzz=10%
rekeymargin=5m
type=tunnel
#
# algo patch
ike=aes128-md5,aes128-sha,3des-md5,3des-sha
esp=aes128-md5,aes128-sha1,3des-md5,3des-sha1
#
ikelifetime=1h
keyingtries=0
keylife=4h
rekey=yes
#
left=<openswan vpn address>
leftnexthop=<inet router gateway address>
leftsubnet=172.31.0.0/22
leftid=<openswan vpn address>
leftcert=<cert path>
leftrsasigkey=%cert
#
rightrsasigkey=%cert
----- Included file -----
conn client.host1a
auto=add
rightsubnet=10.1.7.90/32
right=<natted routable address>
rightid=@clients-laptop.somewhere.org
also=client.default
conn client.host1b
auto=add
right=10.1.7.90
rightnexthop=<natted routable address>
rightid=@clients-laptop.somewhere.org
also=client.default
conn client.default
left=<openswan vpn address>
leftsubnet=0.0.0.0/0
leftid=<openswan vpn address>
leftcert=
#
authby=secret
ikelifetime=1h
keylife=4h
#keyingtries=2
rekey=yes
Ok, client.host1a config successfully creates a tunnel, and using
tcpdump on the openswan box, I am able to confirm that traffic makes it
to us:
15:24:02 IP (tos 0x0, ttl 128, id 9777, offset 0, flags [none], proto 1,
length: 60) 10.1.7.90 > 172.31.1.28: icmp 40: echo request seq 28424
15:24:07 IP (tos 0x0, ttl 128, id 9786, offset 0, flags [none], proto 1,
length: 60) 10.1.7.90 > 172.31.1.28: icmp 40: echo request seq 28680
15:24:13 IP (tos 0x0, ttl 128, id 9790, offset 0, flags [none], proto 1,
length: 60) 10.1.7.90 > 172.31.1.28: icmp 40: echo request seq 28936
15:24:18 IP (tos 0x0, ttl 128, id 9794, offset 0, flags [none], proto 1,
length: 60) 10.1.7.90 > 172.31.1.28: icmp 40: echo request seq 29192
However, that traffic never makes it into the firewall rules, let alone
out the other interface. (I made iptable rules that would match all
traffic to or from 10.1.7.0/24 at the top of the forwarding tables, and
the counters are stuck at zero). I also attempted to totally remove the
forwarding tables from the picture by emptying the rule set and setting
the policy to accept, no joy there either.
FWIW, the internal interface off the openswan box is within the
172.31.1.0/24 network. We've attempted to limit the tunnel
configuration to specifying just the 172.31.1.0/24 network on both
sides, but the ipseccmd under xp sp2 doesn't appear to do anything (like
actually create a tunnel) with any information other than an asterisk as
the remote network.
Any configuration in which I attempt to create a normal "host to
network" tunnel fails (attempt shown as client.host1b above) because
openswan sees the incoming connection as being from the NATed address,
and not the 10.1.7.90 address (we get "<NATed address>:4500: initial
Main Mode message received on <openswan address>:4500 but no connection
has been authorized" messages). And the only way I've been able to
bring up a tunnel at all is to use the pseudo "network to network"
tunnel with the client "network" looking like a host route
(ipaddress/32). And attempting to just use the NATed address as the
host also fails because it recognizes the 10.1.7.90/32 address as the
destination "network". (we get "no connection is known for
0.0.0.0/0===<openswan address>...<NATed
address>[@client-laptop.somewhere.org]===10.1.7.90/32" messages)
Oh, and if I initiate a ping from my side (from a different box) with
the tunnel up, the traffic flows from me to the client, and I get a
reply, but again, as soon as that reply traffic hits my openswan box,
the traffic then appears to vanish.
14:59:08 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 1,
length: 84) 172.31.1.14 > 10.1.7.90: icmp 64: echo request seq 0
14:59:08 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto 1,
length: 84) 172.31.1.14 > 10.1.7.90: icmp 64: echo request seq 0
14:59:08 IP (tos 0x0, ttl 128, id 8140, offset 0, flags [DF], proto 1,
length: 84) 10.1.7.90 > 172.31.1.14: icmp 64: echo reply seq 0
14:59:09 IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], proto 1,
length: 84) 172.31.1.14 > 10.1.7.90: icmp 64: echo request seq 1
14:59:09 IP (tos 0x0, ttl 63, id 1, offset 0, flags [DF], proto 1,
length: 84) 172.31.1.14 > 10.1.7.90: icmp 64: echo request seq 1
14:59:09 IP (tos 0x0, ttl 128, id 8142, offset 0, flags [DF], proto 1,
length: 84) 10.1.7.90 > 172.31.1.14: icmp 64: echo reply seq 1
In this case I do get hits on the firewall rules going out to the
client. (return traffic should be considered "related", and thus would
not create a hit, but again the response never goes out the other
interface on the openswan box. You can see it come in one interface
above, and then out another interface, that's the apparent duplication
of traffic being sent to 10.1.7.90)
I thank you in advance for assisting us,
-Scott L. Miller
More information about the Users
mailing list