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

[Noel Kuntze]

-----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-----