[Openswan Users] Windows XP - ISAKMP SA

Mike Horn lists at caddisconsulting.com
Fri Feb 2 16:59:15 EST 2007


Hi,

I have a setup with a laptop running Windows XP connecting to an Openswan
server using L2TP/IPsec.  The server is using Openswan 2.4.6 with NETKEY on
kernel 2.6.19.  If I don't configure the ikelifetime value, so it uses the
default of 3600s, after an hour when the ISAKMP SA expires I continuously
(every 10s) get the following log messages on the server. 

Feb  2 16:36:31 uml-5 pluto[8301]: "l2tp-psk"[1] 192.168.2.139 #510: max
number of retransmissions (2) reached STATE_QUICK_I1
Feb  2 16:36:31 uml-5 pluto[8301]: "l2tp-psk"[1] 192.168.2.139 #510:
starting keying attempt 30 of an unlimited number
Feb  2 16:36:31 uml-5 pluto[8301]: "l2tp-psk"[1] 192.168.2.139 #512:
initiating Quick Mode PSK+ENCRYPT+TUNNEL to replace #510 {using isakmp#443}
Feb  2 16:36:31 uml-5 pluto[8301]: "l2tp-psk"[1] 192.168.2.139 #443:
ignoring informational payload, type INVALID_ID_INFORMATION
Feb  2 16:36:31 uml-5 pluto[8301]: "l2tp-psk"[1] 192.168.2.139 #443:
received and ignored informational message

What I'm guessing is that the ISAKMP SA timeouts out on the server which is
the responder and then the server tries to renegotiate a new ISAKMP SA, but
the Windows XP laptop is refusing the renegotiation attempts, possibly
because it has an unexpired ISAKMP SA for this peer.

The laptop is still able to pass traffic (the ESP SA is still active) until
the ESP SA timeouts at 28800 seconds.  At that point the tunnel fails and I
need to restart the Openswan tunnel connection and reconnect from the
laptop.

Is there some configuration setting I can use, other than extending the
ikelifetime, that would enable the two systems to successfully renegotiate
the ISAKMP SA when the renegotiate is initiated by the responder?  Does
anyone else see this behavior?


conn l2tp-psk
        left=192.168.2.75
        leftprotoport=17/1701
        rightprotoport=17/1701
        rightsubnet=vhost:%priv,%no
        right=%any
        auto=add
        authby=secret
        pfs=no
        type=transport


-mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070202/26d947b0/attachment.html 


More information about the Users mailing list