[strongSwan] Frequent rekey causes lost tunnel after about 30 minutes

Ruel, Ryan rruel at akamai.com
Wed May 6 17:58:01 CEST 2015


Noel,

Sure.  Attached, please find the logs from the responder (server1) and the
initiator (client2).  These logs were captured using a file logger with a
default log level of "3" for all sub-systems.

I reached 5 successful rekeys, and after that the tunnel dropped, with the
IKE delete messages shown at the end of the logs.  This is easily
reproducible.  

Both server1 and client2 are running strongSwan 5.3.0:

Linux strongSwan U5.3.0/K3.14.31-3.14.0-debug-14769706
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil, Switzerland
See 'ipsec --copyright' for copyright information.


/Ryan

server1 ipsec.conf:

conn %default
   keyexchange=ikev2
   keyingtries=10

conn client2
   auto=add
   authby=secret
   left=198.18.148.73/32[gre]
   leftid="akamai.com"
   right=%any
   rightid="*@akamai.com"
   ike=aes128-sha1-modp2048
   esp=null-sha256!
   type=transport


client2 ipsec.conf:

conn %default
   authby=secret
   keyexchange=ikev2
   margintime=0
   lifetime=1m
   ikelifetime=5m
   keyingtries=10

conn client2
   left=198.18.73.102
   leftsubnet=198.18.73.102/32[gre]
   leftid=client2 at akamai.com
   right=198.18.148.73
   rightsubnet=198.18.148.73/32[gre]
   rightid=akamai.com
   ike=aes-128-sha1-modp2048
   esp=null-sha256-noesn!
   type=transport
   auto=add
   dpdaction=restart
   closeaction=restart




On 5/6/15, 10:48 AM, "Noel Kuntze" <noel at familie-kuntze.de> wrote:

>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Hello Ryan,
>
>Would you kindly share a complete log, so we can see exactly what is
>happening?
>
>Mit freundlichen Grüßen/Kind Regards,
>Noel Kuntze
>
>GPG Key ID: 0x63EC6658
>Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
>Am 06.05.2015 um 12:27 schrieb Ruel, Ryan:
>> Any suggestions on this?
>>
>> Is it necessary to run DPD and set the ³dpdaction² and ³closeaction² to
>>restart in order to maintain long lived connections?
>>
>> I¹m now finding that even with normal rekey intervals, if I leave the
>>tunnel up for a long period of time (even with traffic), I find that
>>it¹s gone the next day.
>>
>> /Ryan
>>
>> From: Ryan Ruel
>> Date: Monday, May 4, 2015 at 7:50 PM
>> To: "users at lists.strongswan.org <mailto:users at lists.strongswan.org>"
>> Subject: [strongSwan] Frequent rekey causes lost tunnel after about 30
>>minutes
>>
>> I¹ve been performing some rekey testing, and purposely configured low
>>lifetimes to force rekey¹s to happen frequently in order to test the
>>system.
>>
>> I¹m seeing that any rekey values less than 10m or so winds up causing
>>issues, such as tunnels completely down, or the outbound SA deleted on
>>one side (but the inbound SA remains).
>>
>> I¹ve just ran a test with two back to back Linux machines running
>>5.2.2.  In this case, I¹m running the tunnel as transport mode over a
>>GRE tunnel, but the problem seems to happen without the GRE tunnel as
>>well:
>>
>> conn b2b
>>     left=198.168.73.101
>>     leftsubnet=198.168.73.101/32[gre]
>>     leftid=198.168.73.101
>>     right=198.168.73.102
>>     rightsubnet=198.168.73.102/32[gre]
>>     rightid=198.168.73.102
>>     ike=aes-128-sha1-modp2048
>>     esp=null-sha256-noesn!
>>     type=transport
>>     auto=add
>>
>> conn b2b
>>     left=198.168.73.102
>>     leftsubnet=198.168.73.102/32[gre]
>>     leftid=198.168.73.102
>>     right=198.168.73.101
>>     rightsubnet=198.168.73.101/32[gre]
>>     rightid=198.168.73.101
>>     ike=aes-128-sha1-modp2048
>>     esp=null-sha256-noesn!
>>     type=transport
>>     auto=add
>>
>> I brought up the tunnel and left it running.  When I came back about 30
>>minutes later, both machines show:
>>
>> Every 2.0s: setkey -D
>>                        Mon May  4 23:44:54 2015
>>
>> No SAD entries.
>>
>> I noticed this in one of the logs:
>> May  4 23:25:54 a198-168-73-102 charon: 04[IKE] initiator did not
>>reauthenticate as requested
>> May  4 23:25:54 a198-168-73-102 charon: 04[IKE] reauthenticating IKE_SA
>>b2b[5] actively
>>
>> And the other side seems to be scheduling a re-auth event earlier:
>> May  4 23:15:54 a198-168-73-101 charon: 10[IKE] scheduling
>>reauthentication in 600s
>> May  4 23:15:54 a198-168-73-101 charon: 10[IKE] maximum IKE_SA lifetime
>>600s
>> May  4 23:15:54 a198-168-73-101 charon: 10[IKE] received AUTH_LIFETIME
>>of 600s, reauthentication already scheduled in 600s
>>
>> Any ideas?  Is the reauth to blame?
>>
>> I know this lifetime is unusually short, but I¹m concerned that the
>>same type of rekey issue may happen if I let the system run for much
>>longer periods of time.
>>
>> Thanks!
>>
>> /Ryan
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>
>iQIcBAEBCAAGBQJVSinOAAoJEDg5KY9j7GZYQPoP/RNYw3JerCP1NJniT7TSNsmk
>h7SP348cFVXZhZUV+aNn3yj8Yi7zEPzSYDtWmUOzii/xQTtnW2JQq7UFC424Ogmh
>1qLx4x86IFyOQwiLVLFu1vpF8jKJ6fzvhfFF9WreKqGVvqIAlQaMN4CralSuwh0e
>8he/pnHt5NcNOl6Qiti6TIbjbr0oW8a4DaQbDfCIszLscEoe+caveyNbwREsDi8I
>MSCVdgig/U9odijsSuO36zIKVklGfZk4Vnzo7A/k3wWX07cQr+PiW1oodi+dCEHt
>zblz0baFGJpZiTIjf8o/a2mUvrWOQoICvQ8wSEMdZ57+FicFGquCcCZQmGYh4hOQ
>BXrfjj30S90zgPrD7a51M7MvqErykDwurihPTzQt2ZhA4GFI7btlwrl1v3+9F6mJ
>Xa/StUdPqQTXYzpCBVZODL3beeI3FMgXu44Y/UaCNWXtLaXlDAW7/cQuCkuptAFS
>CAAbROCnkcOQ9hJYNne8myOVA9Mur5YQAkSJQOHbYhK3MSr2hi2EHtcnH0MWgeA+
>mEeOJDepuQx1qB7Ouf0zdyPNrks2PJzZwdf8eMZ6HctNhGobuBLT2fFd4Z67qNcg
>xv8jts7KI2Esxv2/yZpFjr4vDAPGrVhodTtWLB3FJTmHMy/Jl4iAB8rzw6m2ONJi
>o0cJplgbv3k0bIkuq87P
>=kvNI
>-----END PGP SIGNATURE-----
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: client2.log
Type: application/octet-stream
Size: 177766 bytes
Desc: client2.log
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150506/2f9762f5/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server1.log
Type: application/octet-stream
Size: 99750 bytes
Desc: server1.log
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150506/2f9762f5/attachment-0003.obj>


More information about the Users mailing list