[strongSwan] site-to-site vpn tunnel drops exactly every 6 hours : StrongSwan <-> Cisco ASA

Izz Abdullah izz.abdullah at wepanow.com
Mon Sep 16 13:05:28 CEST 2013


I thought that was the issue initially, and have posted on issue 317, I believe it is, but was second guessing myself once the lifetime of the peer has changed from 8 hours to 24.
Thank you Martin.


--
Izz
Sent using Android™



-------- Original message --------
From: Martin Willi <martin at strongswan.org>
Date: 09/16/2013 2:55 AM (GMT-06:00)
To: Izz Abdullah <izz.abdullah at wepanow.com>
Cc: users at lists.strongswan.org
Subject: Re: [strongSwan] site-to-site vpn tunnel drops exactly every 6 hours : StrongSwan <-> Cisco ASA


Hi,

> Sep 15 16:34:02 bhm-ipsec-221 charon: 16[ENC] parsed ID_PROT request 0 [ SA V V V V ]

> Sep 15 16:34:02 bhm-ipsec-221 charon: 15[IKE] deleting duplicate IKE_SA for peer 'XXX.YYY.2.20' due to uniqueness policy
> Sep 15 16:34:02 bhm-ipsec-221 charon: 15[IKE] deleting IKE_SA school-tunnel02[144] between 10.10.100.221[wepa]...XXX.YYY.2.20[XXX.YYY.2.20]
> Sep 15 16:34:02 bhm-ipsec-221 charon: 15[IKE] sending DELETE for IKE_SA school-tunnel02[144]
> Sep 15 16:34:02 bhm-ipsec-221 charon: 15[ENC] generating INFORMATIONAL_V1 request 3554893475 [ HASH D ]
> Sep 15 16:34:02 bhm-ipsec-221 charon: 15[NET] sending packet: from 10.10.100.221[4500] to XXX.YYY.2.20[4500] (84 bytes)
> Sep 15 16:34:02 bhm-ipsec-221 charon: 15[IKE] IKE_SA school-tunnel02[152] established between 10.10.100.221[wepa]...XXX.YYY.2.20[XXX.YYY.2.20]
> Sep 15 16:34:02 bhm-ipsec-221 charon: 15[ENC] generating ID_PROT response 0 [ ID HASH ]
> Sep 15 16:34:02 bhm-ipsec-221 charon: 15[NET] sending packet: from 10.10.100.221[4500] to XXX.YYY.2.20[4500] (68 bytes)
> Sep 15 16:34:02 bhm-ipsec-221 charon: 14[NET] received packet: from XXX.YYY.2.20[4500] to 10.10.100.221[4500] (68 bytes)
> Sep 15 16:34:02 bhm-ipsec-221 charon: 14[ENC] parsed INFORMATIONAL_V1 request 3654723502 [ HASH D ]
> Sep 15 16:34:02 bhm-ipsec-221 charon: 14[IKE] received DELETE for ESP CHILD_SA with SPI aadc2798

The peer tries to re-authenticate the ISAKMP SA. Due to your unique
policy and a limitation of our new IKEv1 implementation, this leads to a
problem: The uniqueness policy deletes the old ISAKMP during
re-authentication before it can complete.

This is a know issue, and I hope I'll find some time to fix this. In the
mean time, you should consider setting uniqueids=no in ipsec.conf, have
a look at the manpage for details.

Regards
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130916/a67b1a2c/attachment.html>


More information about the Users mailing list