[Openswan Users] Multiple roadwarrior clients behind same NAT
John Riley
jriley at dsbscience.com
Thu Nov 10 02:38:31 CET 2005
I have a remote office scenario where each client in the remote office
has to be able to connect to multiple computers in the home office. The
home office uses a Mandrake 10.1 Linux box running OpenSwan as the VPN
Gateway/Router configured to allow roadwarrior connections.
LAN (192.168.1.0/24) -- VPN GW 206.74.49.20 --- Internet ---
70.147.158.96 Linksys Router --- LAN (192.168.2.0/24)
VPN Gateway:
Mandrake Linux, kernel version 2.6.8.1-12.mdk (2.6.8 kernel with some
patches from 2.6.9 iirc)
OpenSwan Version 2.3.1 (netkey)
Clients:
Remote Office clients, Windows XP SP2 with Marcus Meuller's Ipsec policy
package, with patch that 'undoes' SP2 ipsec
iptables is configured using MARK so that all traffic arriving on the
tunnel is allowed, and I can connect any TWO remote office clients to
the home office net and use all needed services. Sometimes the latency
is VERY large even though ping times are reasonable (pinging with
packets of 56 - 1400 bytes). Any attempt to connect any third client
fails to get an SA.
If I want to change one or both of the remote office clients that can
connect, I have to restart ipsec on the VPN server.
I have one Mandrake 10.0 (kernel 2.6.3-7.mdk) Linux box behind a
DIFFERENT NAT (it's at a different location) also running 2.3.1 OpenSwan
as a client that I can connect using the same roadwarrior conns. Having
this tunnel up does not change the behavior of trying to connect more
than two clients from the actual remote office.
As I looked to /var/log/secure on the home office VPN server for clues
as to why additional clients were failing to get an SA, I noticed
constant activity (ie, constantly regotiating) for those clients
connected. Here is a log excerpt for one client connected:
/var/log/secure:
-----------------------------------------------------------------------------------------------------------------------------------
snip --
Nov 7 08:00:20 lancgw pluto[27438]: packet from 70.147.158.96:4500:
ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Nov 7 08:00:20 lancgw pluto[27438]: packet from 70.147.158.96:4500:
ignoring Vendor ID payload [FRAGMENTATION]
Nov 7 08:00:20 lancgw pluto[27438]: packet from 70.147.158.96:4500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set
to=106
Nov 7 08:00:20 lancgw pluto[27438]: "charlotte"[43] 70.147.158.96 #343:
responding to Main Mode from unknown peer 70.147.158.96
Nov 7 08:00:20 lancgw pluto[27438]: "charlotte"[43] 70.147.158.96 #343:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Nov 7 08:00:20 lancgw pluto[27438]: "charlotte"[43] 70.147.158.96 #343:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
Nov 7 08:00:20 lancgw pluto[27438]: "charlotte"[43] 70.147.158.96 #343:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Nov 7 08:00:21 lancgw pluto[27438]: "charlotte"[43] 70.147.158.96 #343:
Main mode peer ID is ID_DER_ASN1_DN: 'C=US, ST=South Carolina, L=Lugoff,
O=DSB Scientific Consulting, CN=charofc04.goins.net,
E=jriley at dsbscience.com'
Nov 7 08:00:21 lancgw pluto[27438]: "charlotte"[43] 70.147.158.96 #343:
crl update for "C=US, ST=South Carolina, L=Lugoff, O=DSB Scientific
Consulting, OU=IT, CN=DSB Scientific RootCA 2005,
E=jriley at dsbscience.com" is overdue since Jun 26 20:05:36 UTC 2005
Nov 7 08:00:21 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#343: deleting connection "charlotte" instance with peer 70.147.158.96
{isakmp=#0/ipsec=#0}
Nov 7 08:00:21 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#343: I am sending my cert
Nov 7 08:00:21 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#343: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Nov 7 08:00:21 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#343: sent MR3, ISAKMP SA established
Nov 7 08:00:21 lancgw pluto[27438]: "charlotte"[16] 70.147.158.96 #344:
responding to Quick Mode {msgid:bd88d0ac}
Nov 7 08:00:21 lancgw pluto[27438]: "charlotte"[16] 70.147.158.96 #344:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Nov 7 08:00:21 lancgw pluto[27438]: "charlotte"[16] 70.147.158.96 #344:
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Nov 7 08:00:21 lancgw pluto[27438]: "charlotte"[16] 70.147.158.96 #344:
IPsec SA established {ESP=>0xf1c89e95 <0x0284fe27 xfrm=3DES_0-HMAC_MD5
NATD=70.147.158.96}
Nov 7 08:00:21 lancgw pluto[27438]: packet from 70.147.158.96:4500:
Informational Exchange is for an unknown (expired?) SA
Nov 7 08:01:31 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#343: received Delete SA payload: deleting ISAKMP State #343
Nov 7 08:01:31 lancgw pluto[27438]: packet from 70.147.158.96:4500:
received and ignored informational message
Nov 7 08:02:57 lancgw pluto[27438]: packet from 70.147.158.96:4500:
Informational Exchange is for an unknown (expired?) SA
Nov 7 08:03:50 lancgw pluto[27438]: packet from 70.147.158.96:500:
ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Nov 7 08:03:50 lancgw pluto[27438]: packet from 70.147.158.96:500:
ignoring Vendor ID payload [FRAGMENTATION]
Nov 7 08:03:50 lancgw pluto[27438]: packet from 70.147.158.96:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set
to=106
Nov 7 08:03:50 lancgw pluto[27438]: packet from 70.147.158.96:500:
ignoring Vendor ID payload [Vid-Initial-Contact]
Nov 7 08:03:50 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#345: responding to Main Mode from unknown peer 70.147.158.96
Nov 7 08:03:50 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#345: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Nov 7 08:03:50 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#345: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer
is NATed
Nov 7 08:03:50 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#345: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Nov 7 08:03:52 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#345: Main mode peer ID is ID_DER_ASN1_DN: 'C=US, ST=South Carolina,
L=Lugoff, O=DSB Scientific Consulting, CN=charofc04.goins.net,
E=jriley at dsbscience.com'
Nov 7 08:03:52 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#345: crl update for "C=US, ST=South Carolina, L=Lugoff, O=DSB
Scientific Consulting, OU=IT, CN=DSB Scientific RootCA 2005,
E=jriley at dsbscience.com" is overdue since Jun 26 20:05:36 UTC 2005
Nov 7 08:03:52 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#345: I am sending my cert
Nov 7 08:03:52 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#345: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Nov 7 08:03:52 lancgw pluto[27438]: | NAT-T: new mapping
70.147.158.96:500/4500)
Nov 7 08:03:52 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#345: sent MR3, ISAKMP SA established
Nov 7 08:03:52 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#346: responding to Quick Mode {msgid:da2ed8b8}
Nov 7 08:03:52 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#346: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Nov 7 08:03:52 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#346: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Nov 7 08:03:52 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#346: IPsec SA established {ESP=>0xdb86b921 <0xf3c8cbda
xfrm=3DES_0-HMAC_MD5 NATD=70.147.158.96}
Nov 7 08:05:16 lancgw pluto[27438]: "charlotte-net"[6] 70.147.158.96
#345: received Delete SA payload: deleting ISAKMP State #345
Nov 7 08:05:16 lancgw pluto[27438]: packet from 70.147.158.96:4500:
received and ignored informational message
--snip
-------------------------------------------------------------------------------------------------------------------------------------------------------
This continues constantly.
-- ipsec.conf:
---------------------------------------------------------------------------------------------------------------------------------------------
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# Debug-logging controls: "none" for (almost) none, "all" for lots.
# klipsdebug=none
# plutodebug="control parsing"
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.1.0/24
# connections
conn %default
keyingtries=1
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
conn charlotte-net
leftsubnet=192.168.1.0/24
also=charlotte
conn charlotte
# gateway is left
left=206.74.49.20
leftcert=lancgw.goins.net.pem
# remote client is right
right=%any
rightsubnet=vhost:%no,%priv
auto=add
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
-- end ipsec.conf
------------------------------------------------------------------------------------------------------------------------------------
Unfortunately, at this time I don't have the Oakley logs for the remote
office clients, but I can get them if it is thought they are needed.
Is this constant renegotiation related to why I cannot get more than two
clients connected over the tunnel?
Is this two-client limit behind a single NAT device a known issue with
the kernel and OpenSwan versions I am using?
If the remote office clients were running OpenSwan on Linux, would the
whole set-up be more reliable? (I can do that, since the main services
on the protected network is rdesktop on a Win2003 server and some smb
shares, but it will require some gyrations with the Office Staff).
Thanks,
--
John S. Riley, Ph.D.
DSB Scientific Consulting
http://www.dsbscience.com
More information about the Users
mailing list