[strongSwan] Loss of tunnel service while reauthenticating IKE_SA?

[Noel Kuntze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Ken,

It is dependent on the IKE version.
Quote from the man page:

       reauth = yes | no
              whether rekeying of an IKE_SA  should  also  reauthenticate  the
              peer.  In  IKEv1,  reauthentication  is always done. In IKEv2, a
              value of no rekeys without uninstalling the IPsec SAs,  a  value
              of yes (the default) creates a new IKE_SA from scratch and tries
              to recreate all IPsec SAs.

Obviously, setting reauth=no will keep the tunnel up during rekeying of the IKE SAs.
You have to use "reauth=no" on both sides to make it work.

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 12.03.2015 um 15:31 schrieb Ken Nelson:
> VPN client & server running StrongSwan v5.2.2.  Both OSes Centos 6.6.
>
> An IKEv2 IPsec tunnel has been up for a couple days with the client initiating a ping, once per minute, of the same host behind the VPN gateway.  This is the only application level traffic on the tunnel.
>
> Roughly every two hours and 40 minutes, the client initiates the IKE SA reauthentication sequence and some times the ping fails:
>
> 2015/03/12 13:14:20 - host ipa.cz.internal is ok
> ping: unknown host ipa.cz.internal
> 2015/03/12 13:15:20 - host ipa.cz.internal is down
> 2015/03/12 13:16:20 - host ipa.cz.internal is ok
>
>
> The .cz.internal DNS domain is served by a host (10.8.65.164) behind the VPN gateway.  Here’s a snippet from the client log file showing the start of the reauthentication and the removal of the DNS server from resolve.conf.
>
> Mar 12 13:15:10 secgw-client charon: 12[IKE] reauthenticating IKE_SA cz-pdc[16]
> Mar 12 13:15:10 secgw-client charon: 12[IKE] deleting IKE_SA cz-pdc[16] between 10.100.34.179[linux-test]...a.b.c.d[secgw.cz-dev.com <http://secgw.cz-dev.com>]
> Mar 12 13:15:10 secgw-client charon: 12[IKE] sending DELETE for IKE_SA cz-pdc[16]
> Mar 12 13:15:10 secgw-client charon: 12[ENC] generating INFORMATIONAL request 9 [ D ]
> Mar 12 13:15:10 secgw-client charon: 12[NET] sending packet: from 10.100.34.179[4500] to a.b.c.d[4500] (76 bytes)
> Mar 12 13:15:10 secgw-client charon: 10[NET] received packet: from a.b.c.d[4500] to 10.100.34.179[4500] (76 bytes)
> Mar 12 13:15:10 secgw-client charon: 10[ENC] parsed INFORMATIONAL response 9 [ ]
> Mar 12 13:15:10 secgw-client charon: 10[IKE] IKE_SA deleted
> Mar 12 13:15:10 secgw-client vpn: - secgw.cz-dev.com <http://secgw.cz-dev.com> 10.8.64.0/23 == a.b.c.d -- 10.100.34.179 == 10.255.252.1/32
> Mar 12 13:15:10 secgw-client charon: 10[IKE] installing new virtual IP 10.255.252.1
> Mar 12 13:15:10 secgw-client charon: 10[IKE] restarting CHILD_SA cz-pdc
> Mar 12 13:15:10 secgw-client charon: 10[IKE] initiating IKE_SA cz-pdc[17] to a.b.c.d
> Mar 12 13:15:10 secgw-client charon: 10[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> Mar 12 13:15:10 secgw-client charon: 10[NET] sending packet: from 10.100.34.179[500] to a.b.c.d[500] (1420 bytes)
> Mar 12 13:15:10 secgw-client charon: 10[IKE] removing DNS server 10.8.65.164 from /etc/resolv.conf
>
>
> And a snippet from the server log file:
>
> Mar 12 13:15:10 secgw charon: 15[NET] received packet: from w.x.y.z[4500] to 10.8.95.244[4500] (76 bytes)
> Mar 12 13:15:10 secgw charon: 15[ENC] parsed INFORMATIONAL request 9 [ D ]
> Mar 12 13:15:10 secgw charon: 15[IKE] received DELETE for IKE_SA remote-access-ikev2-krb[15]
> Mar 12 13:15:10 secgw charon: 15[IKE] deleting IKE_SA remote-access-ikev2-krb[15] between 10.8.95.244[secgw.cz-dev.com <http://secgw.cz-dev.com>]...w.x.y.z[linux-test]
> Mar 12 13:15:10 secgw charon: 15[IKE] IKE_SA remote-access-ikev2-krb[15] state change: ESTABLISHED => DELETING
> Mar 12 13:15:10 secgw charon: 15[IKE] IKE_SA deleted
>
> The clocks on each machine are synchronized using NTP.  The two hosts take ~11-12 seconds to complete the reauthentication sequence and the continuous ping succeeds.
>
> The continuous ping is pretty tolerant of the network outage and since it’s stateless and only occurs every 60 seconds - it often does not notice the outage.  However, if I ran highly sensitive application like a file transfer, would the entire transfer fail?  Is reauthentication equivalent to terminating and restarting the tunnel?
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVAa21AAoJEDg5KY9j7GZYIs0P/3Q8ZBFLLXu6fKuaN+MA6RGO
/L4gMyAjzzwEcWs8MwB2kzC6oeS8vhabbcalQ973zAmfmn08UPeQnUIUOBjcLwQJ
ZTNohvsNtSwvxZGD1enEgdls8YFd0GtyplBzCupj8YOCyU0hBs4NN4UJ768geoxM
Io1Lt3Wf2w+EKNUeEFxhet+aoXscAdaU9VYWpzoXDKgyqsRa/LomkjP69D8lijLm
4rdLe3n1FZc4WxLkDmN+JscRi1CkMXNN2PyqMcMLLdABkI9/2eqRhaRb7CtezfpL
vy/+XGi36QJBgJZgRjo64AyV0aCg3Zyvnu11HcgRyPUcFLU7HfFSfZNW/zRkK2KI
BgJ9UEthsXQEHw/knDR+/QDKfJqCW80UJpckJANmzfnUigJ+ZLrfqT6Y6j5dcFt/
DebffUOSqG6LcsdLo7t+Vgzk4z/V5eMhwNEIt7oWeqsDqjcI4HQM6JJJlhy/dh8b
3Rej7fBiIl441xka72EPg0AJO8ckW7TLBX1uk57UsRo1wpsmE3siuSbDFOUG9kmg
aSKNGmSjRMa3M/QYowckJhr7687vG0NrZ8BUcqba/slDj6fsVz5cbZWy5zIYjieL
4A1f5rJzoI0qiVptEgL9UcyOFsZRkdQcsyQbKgdwHzrhivtbyU95pdb+hKAMwu/H
CbUGifQ/NeRncZgIEFth
=ePWf
-----END PGP SIGNATURE-----