Can you give a working example using the uniqueids=no? I have tried this but end up with what appears to be multiple tunnels to the same endpoint after renegotiating the initial tunnel. I would imagine this would require the use of dpd on strongSwan end, but have yet to have a successful trial without any downtime. Again, my check script seems to be the better alternative, but I am still giving way to a possible 59s downtime. and this is not a production solution. Assistance is greatly appreciated.
Regards. Izz Izz Abdullah Senior Systems Engineer [email protected]<mailto:[email protected]> www.wepanow.com<http://www.wepanow.com> ________________________________ From: Izz Abdullah <[email protected]><mailto:[email protected]> Sent: Monday, September 16, 2013 :06AM To: Martin Willi <[email protected]><mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: Re: [strongSwan] site-to-site vpn tunnel drops exactly every 6 hours : StrongSwan <-> Cisco ASA 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 <[email protected]><mailto:[email protected]> Date: 09/16/2013 2:55 AM (GMT-06:00) To: Izz Abdullah <[email protected]><mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> 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 _______________________________________________ Users mailing list [email protected]<mailto:[email protected]> https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
