[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