<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body smarttemplateinserted="true" text="#000000" bgcolor="#FFFFFF">
<div id="smartTemplate4-template">
<title></title>
Below is the strongSwan config which I have complete control over:<br>
conn school-tunnel02<br>
type=tunnel<br>
auto=start<br>
keyexchange=ikev1<br>
ikelifetime=25h<br>
#keylife=480m<br>
# 28800s = 8h<br>
#lifetime=28800s<br>
lifetime=86400s<br>
#margintime=19m<br>
## commented above line and added below line - 20130909 - Izz<br>
rekey=no<br>
# above line setting rekey=no had no affect on 6 hour timeout of tunnel<br>
#dpdaction=restart<br>
#dpddelay=30s<br>
authby=secret<br>
auth=esp<br>
ike=3des-sha1-modp1024!<br>
esp=3des-sha1!<br>
left=10.10.100.221<br>
leftid=wepa<br>
leftsubnet=10.10.100.0/24<br>
leftfirewall=yes<br>
right=XXX.YYY.2.20<br>
rightid=XXX.YYY.2.20<br>
rightsubnet=XXX.YYY.43.0/24 <br>
<br>
I have requested the admin on the other end of the tunnel to change the lifetime to 24h which they have done, and it made no difference. The tunnel is dropping at exactly every 6 hours. Here are the logs from the drop time:<br>
<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 16[ENC] parsed ID_PROT request 0 [ SA V V V V ]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 16[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 16[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 16[IKE] received NAT-T (RFC 3947) vendor ID<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 16[IKE] received FRAGMENTATION vendor ID<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 16[IKE] XXX.YYY.2.20 is initiating a Main Mode IKE_SA<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 16[ENC] generating ID_PROT response 0 [ SA V V V ]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 16[NET] sending packet: from 10.10.100.221[4500] to XXX.YYY.2.20[4500] (132 bytes)<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 13[NET] received packet: from XXX.YYY.2.20[4500] to 10.10.100.221[4500] (304 bytes)<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 13[ENC] parsed ID_PROT request 0 [ KE No V V V V NAT-D NAT-D ]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 13[IKE] local host is behind NAT, sending keep alives<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 13[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 13[NET] sending packet: from 10.10.100.221[4500] to XXX.YYY.2.20[4500] (244 bytes)<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 15[NET] received packet: from XXX.YYY.2.20[4500] to 10.10.100.221[4500] (84 bytes)<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 15[ENC] parsed ID_PROT request 0 [ ID HASH V ]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 15[CFG] looking for pre-shared key peer configs matching 10.10.100.221...XXX.YYY.2.20[XXX.YYY.2.20]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 15[CFG] selected peer config "school-tunnel02"<br>
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<br>
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]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 15[IKE] sending DELETE for IKE_SA school-tunnel02[144]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 15[ENC] generating INFORMATIONAL_V1 request 3554893475 [ HASH D ]<br>
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)<br>
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]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 15[ENC] generating ID_PROT response 0 [ ID HASH ]<br>
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)<br>
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)<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 14[ENC] parsed INFORMATIONAL_V1 request 3654723502 [ HASH D ]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 14[IKE] received DELETE for ESP CHILD_SA with SPI aadc2798<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 14[IKE] closing CHILD_SA school-tunnel02{22} with SPIs c1777483_i (12096 bytes) aadc2798_o (15552 bytes) and TS 10.10.100.0/24 === XXX.YYY.43.0/24
<br>
Sep 15 16:34:02 bhm-ipsec-221 vpn: - XXX.YYY.2.20 XXX.YYY.43.0/24 == XXX.YYY.2.20 -- 10.10.100.221 == 10.10.100.0/24<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 10[NET] received packet: from XXX.YYY.2.20[4500] to 10.10.100.221[4500] (84 bytes)<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 10[ENC] parsed INFORMATIONAL_V1 request 2406045800 [ HASH D ]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 10[IKE] received DELETE for IKE_SA school-tunnel02[152]<br>
Sep 15 16:34:02 bhm-ipsec-221 charon: 10[IKE] deleting IKE_SA school-tunnel02[152] between 10.10.100.221[wepa]...XXX.YYY.2.20[XXX.YYY.2.20]<br>
<br>
<br>
<br>
I am running CentOS 6.4 x86_64 with kernel 2.6.32 and strongSwan 5.0.4 from the EPEL repo from CentOS. (this is not a compile from source)<br>
Here is the output of 'strongswan version':<br>
Linux strongSwan U5.0.4/K2.6.32-358.14.1.el6.x86_64<br>
<br>
I have two strongSwan instances setup between the same box and another in Amazon AWS Cloud for site-to-site to our DR, and the tunnel never goes down. Traffic passes through this problematic tunnel as it should and everything is great until 6 hours passes.
I have configured a bash script that runs on a */1 minute cron to check the tunnel and if it is down it brings the tunnel back up and emails me. This is how I have been able to keep timestamps. As you can see in the logs, it appears to be a renego that goes
wrong, but all within the same 1 second. My cronjob picks it up at 16:35 in the above case, sees the tunnel down, runs a strongswan up school-tunnel02 and mails me the output of the command, showing success. This continues each and every 6 hours like clockwork.<br>
<br>
I appreciate any input. I can probably find the configs sent to me by the admin on the other end with the Cisco ASA, but I can assure you the initial tunnel lifetime was set to 8 hours (28,800s), so I am having problem believing the ASA is doing this, even
after a change to 86,400s.<br>
<br>
Ideas please?<br>
<br>
Thanks,<br>
Izz<br>
<div class="moz-signature"><font color="blue"><br>
<br>
<b>Izz Abdullah</b><br>
<i>Senior Systems Engineer</i><br>
<a href="mailto:izz.abdullah@wepanow.com">Izz.Abdullah@wepanow.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.wepanow.com">www.wepanow.com</a>
</font><br>
</div>
</div>
<br>
</body>
</html>