[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