[Openswan Users] IPSEC Stuck between MR2 MR3
Steven M. Gill
steven.gill at sungardsecurity.com
Wed Apr 13 12:25:13 CEST 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(Sorry for the long post)
Hi,
I have been researching this for a while to avoid duplicate questions,
but have not come to a solution yet. I currently have a roadwarrior
conenction set up for a machine in our lab. I can connect to it from
home fine (using NAT-T behind my router). While I am at the office
connecting to our work lab (separate internet connections) the
connectivity works roughly 20% of the time. The roard warrior
connection always gets stuck when sending MI3:
104 "secvpn" #1: STATE_MAIN_I1: initiate
003 "secvpn" #1: ignoring unknown Vendor ID payload
[4f45454642797f64757c5f5b]
003 "secvpn" #1: received Vendor ID payload [Dead Peer Detection]
003 "secvpn" #1: received Vendor ID payload [XAUTH]
003 "secvpn" #1: received Vendor ID payload [RFC 3947] method set to=109
106 "secvpn" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "secvpn" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal):
both are NATed
108 "secvpn" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "secvpn" #1: discarding duplicate packet; already STATE_MAIN_I3
010 "secvpn" #1: STATE_MAIN_I3: retransmission; will wait 20s for response
The other side shows MR2 state entered:
packet from 216.203.6.12:47651: ignoring unknown Vendor ID payload
[4f454578616c467b5f6f606d]
Apr 13 11:03:43 [pluto] packet from x.x.x.x:47651: received Vendor ID
payload [Dead Peer Detection]
Apr 13 11:03:43 [pluto] packet from x.x.x.x:47651: received Vendor ID
payload [RFC 3947] method set to=109
Apr 13 11:03:43 [pluto] packet from x.x.x.x:47651: received Vendor ID
payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using
method 109
Apr 13 11:03:43 [pluto] packet from x.x.x.x:47651: received Vendor ID
payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using
method 109
Apr 13 11:03:43 [pluto] packet from x.x.x.x:47651: received Vendor ID
payload [draft-ietf-ipsec-nat-t-ike-00]
Apr 13 11:03:43 [pluto] packet from x.x.x.x:47651: received Vendor ID
payload [XAUTH]
Apr 13 11:03:43 [pluto] "securityvpn"[16] x.x.x.x #32: responding to
Main Mode from unknown peer x.x.x.x
Apr 13 11:03:43 [pluto] "securityvpn"[16] x.x.x.x #32: transition from
state STATE_MAIN_R0 to state STATE_MAIN_R1
Apr 13 11:03:43 [pluto] "securityvpn"[16] x.x.x.x #32: NAT-Traversal:
Result using RFC 3947 (NAT-Traversal): peer is NATed
Apr 13 11:03:43 [pluto] "securityvpn"[16] x.x.x.x #32: transition from
state STATE_MAIN_R1 to state STATE_MAIN_R2
It will eventually time out, but if I try several times in a row it will
work. I thought it might be an MTU problem, but I changed the x.509
certs to a short PSK and it is just as unreliable. I also ping the
ipsec endpoint without an issue with all differnt data packet sizes.
Here is what I do know for some of the differences:
- - If phase 1 works, phase 2 always works fine
- - The work internet gateway seems to use a NAT pool (as opposed to 1 ip
address at home) as I see the IP Address change. It seems to stay the
same throughout an attempt. I thought it might have a problem when
moving from 500/UDP to 4500/UDP but this does not seem.
- - I do see UDP packet fragmetns, but sniffing show its fragmented in
both the success and failure
here's the config (roadwarrior):
version 2.0
config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=all
nat_traversal=yes
conn secvpn
authby=rsasig
left=%defaultroute
leftcert=/etc/ipsec.d/certs/sgill2.cert
leftid=[removed]
leftsendcert=always
leftxauthclient=true
leftrsasigkey=%cert
#
right=x.x.x.x
rightsubnet=172.16.0.0/16
rightrsasigkey=%cert
rightid=[removed
auto=add
and the endpoint config:
version 2.0
config setup
klipsdebug=none
plutodebug=all
interfaces="ipsec0=wan"
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16
# Add connections here.
conn securityvpn
#
#
authby=rsasig
left=%any
leftrsasigkey=%cert
leftsubnet=vhost:%no,%priv
#
right=x.x.x.x
rightid=[removed]
rightsubnet=172.16.0.0/16
rightcert=/etc/ipsec.d/certs/vpn.sungardsecurity.com.cert
rightnexthop=x.x.x.y
#rightsendcert=always
#rightrsasigkey=%cert
rightupdown=/usr/lib/ipsec/_updown.secvpn
rightxauthserver=yes
auto=add
Any suggesstions?
Thanks,
Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCXTnYH4AiI9jN/70RAlpjAJ9bwefCFDjv7otQf2Wb+HU93SgWTACgufNs
pBGlLQu33vd4Lfjvl/JpSy0=
=qIyM
-----END PGP SIGNATURE-----
More information about the Users
mailing list