<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body smarttemplateinserted="true" bgcolor="#FFFFFF" text="#000000">
<div id="smartTemplate4-template">I received an email that issue #317 was fixed in 5.1.1. I checked out the patch(es) below and although the official release isn't slated until Nov 1, I see those patches in 5.1.1dr4 and decided to remove 5.0.2 rpm and compile
dr4 from source to test it that is going to work for us. I am still getting the same issue. Here are the logs when it drops (right Public IP has been obscured for privacy reasons):<br>
<br>
<small>Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[NET] received packet: from A.B.C.D[4500] to 10.201.1.121[4500] (172 bytes)
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[ENC] parsed ID_PROT request 0 [ SA V V V V ]
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[IKE] received NAT-T (RFC 3947) vendor ID
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[IKE] received FRAGMENTATION vendor ID
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[IKE] A.B.C.D is initiating a Main Mode IKE_SA
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[ENC] generating ID_PROT response 0 [ SA V V V ]
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[NET] sending packet: from 10.201.1.121[4500] to A.B.C.D[4500] (140 bytes)
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[NET] received packet: from A.B.C.D[4500] to 10.201.1.121[4500] (304 bytes)
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[ENC] parsed ID_PROT request 0 [ KE No V V V V NAT-D NAT-D ]
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[IKE] received Cisco Unity vendor ID <br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[IKE] received XAuth vendor ID <br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[ENC] received unknown vendor ID: c9:59:52:a7:a5:50:6f:32:9c:cf:c6:a4:23:ab:26:52
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[ENC] received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[IKE] local host is behind NAT, sending keep alives
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[NET] sending packet: from 10.201.1.121[4500] to A.B.C.D[4500] (244 bytes)
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[NET] received packet: from A.B.C.D[4500] to 10.201.1.121[4500] (92 bytes)
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[ENC] parsed ID_PROT request 0 [ ID HASH V ]
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[IKE] received DPD vendor ID <br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[CFG] looking for pre-shared key peer configs matching 10.201.1.121...A.B.C.D[A.B.C.D]
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[CFG] selected peer config "univ-tunnel03"
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[IKE] IKE_SA univ-tunnel03[28] established between 10.201.1.121[wepa]...A.B.C.D[A.B.C.D]
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[IKE] scheduling reauthentication in 89400s
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[IKE] maximum IKE_SA lifetime 89940s <br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[ENC] generating ID_PROT response 0 [ ID HASH ]
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[NET] sending packet: from 10.201.1.121[4500] to A.B.C.D[4500] (76 bytes)
<br>
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[IKE] detected reauth of existing IKE_SA, adopting 1 children
<br>
Oct 22 04:45:52 vpc2-ipsec-1-121 charon: 02[NET] sending packet: from 10.201.1.121[4500] to 130.132.2.20[4500] (92 bytes)
<br>
Oct 22 04:45:55 vpc2-ipsec-1-121 charon: 01[NET] received packet: from A.B.C.D[4500] to 10.201.1.121[4500] (92 bytes)
<br>
Oct 22 04:45:55 vpc2-ipsec-1-121 charon: 01[ENC] parsed INFORMATIONAL_V1 request 3820753939 [ HASH D ]
<br>
Oct 22 04:45:55 vpc2-ipsec-1-121 charon: 01[IKE] received DELETE for IKE_SA univ-tunnel03[28]
<br>
Oct 22 04:45:55 vpc2-ipsec-1-121 charon: 01[IKE] deleting IKE_SA univ-tunnel03[28] between 10.201.1.121[wepa]...A.B.C.D[A.B.C.D]
<br>
Oct 22 04:45:55 vpc2-ipsec-1-121 vpn: - A.B.C.D 172.27.7.0/24 == A.B.C.D -- 10.201.1.121 == 10.201.0.0/22
</small><br>
<br>
Here are the relative portions of my ipsec.conf and strongswan.conf files:<br>
<br>
<small>#ipsec.conf<br>
config setup<br>
# I thought I had this set previously to yes...but with the patch, it shouldn't matter right? worst case it would duplicate the tunnel temporarily during reauth<br>
uniqueids = no<br>
<br>
conn univ-tunnel03<br>
type=tunnel<br>
auto=start<br>
keyexchange=ikev1<br>
ikelifetime=25h<br>
lifetime=24h<br>
margintime=9m<br>
rekeyfuzz=100%<br>
authby=secret<br>
auth=esp<br>
ike=aes-sha1-modp1024!<br>
esp=3des-md5!<br>
left=10.201.1.121<br>
leftid=wepa<br>
leftsubnet=10.201.0.0/22<br>
leftfirewall=yes<br>
right=A.B.C.D<br>
rightid=A.B.C.D<br>
rightsubnet=172.27.7.0/24</small><br>
<br>
<small># strongswan.conf - strongSwan configuration file which is default - I left the comments for completeness<br>
charon {<br>
# number of worker threads in charon<br>
threads = 16<br>
# send strongswan vendor ID?<br>
# send_vendor_id = yes<br>
plugins {<br>
sql {<br>
# loglevel to log into sql database<br>
loglevel = -1<br>
# URI to the database<br>
# database = sqlite:///path/to/file.db<br>
# database = mysql://user:password@localhost/database<br>
}<br>
}<br>
# ...<br>
}<br>
pluto {<br>
<br>
}<br>
libstrongswan {<br>
# set to no, the DH exponent size is optimized<br>
# dh_exponent_ansi_x9_42 = no<br>
}<br>
</small><br>
<br>
I would greatly appreciate any assistance you can be. For whatever reason, this is still an issue with me and I am not 100% confident on the configuration except for the ecryption, etc. When it comes to the lifetime, dpd, rekeyfuzz, I've read the documentation,
but am not sure what the best practice would be. I can open another ticket, but am afraid that I am actually not doing something correct in the above config. Please note I do not have access to the remote site as our remote endpoint is a customer. I did
assist over the phone on the config so that we could get the PSK set and tunnel up initially, so I may be able to provide some information on the remote. I do know it is an ASA on the other side, but unsure of the model. Considering this particular customer,
I would like to think it is in the 5500 series.<br>
<br>
<br>
<b>Izz Abdullah</b><br>
<i>Senior Systems Engineer</i><br>
<a class="moz-txt-link-abbreviated" href="http://www.wepanow.com">www.wepanow.com</a><br>
<br>
</div>
<br>
<div id="smartTemplate4-quoteHeader">
<hr>
<br>
<b>From:</b> Martin Willi <a class="moz-txt-link-rfc2396E" href="mailto:martin@strongswan.org">
<martin@strongswan.org></a><br>
<b>Sent:</b> Monday, September 23, 2013 08:21<br>
<b>To:</b> Izz Abdullah <a class="moz-txt-link-rfc2396E" href="mailto:izz.abdullah@wepanow.com">
<izz.abdullah@wepanow.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:users@lists.strongswan.org">
users@lists.strongswan.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:users@lists.strongswan.org">
<users@lists.strongswan.org></a><br>
<b>Subject: </b>Re: [strongSwan] site-to-site vpn tunnel drops exactly every 6 hours : StrongSwan <-> Cisco ASA<br>
<br>
</div>
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">I've pushed a few changes to [1] that should fix the issue when
reauthenticating an IKE_SA having a keep or replace unique policy.
</pre>
<blockquote type="cite">
<pre wrap="">I have tried this but end up with what appears to be multiple tunnels
to the same endpoint after renegotiating the initial tunnel.
</pre>
</blockquote>
<pre wrap="">With IKEv1, overlapping ISAKMP are hard to avoid. We keep it in certain
situations (reauthentication) where deleting them explicitly can lead to
problems. The ISAKMP SA should get deleted once the hard lifetime times
out; having congruent rekeying parameters on both ends can certainly
help.
Regards
Martin
[1]<a class="moz-txt-link-freetext" href="http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/ikev1-reauth">http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/ikev1-reauth</a>
</pre>
<br>
</body>
</html>