[strongSwan] Loss of tunnel service while reauthenticating IKE_SA?

[Noel Kuntze]

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

Hello Tom,

As the default value for the setting is "yes", a strongSwan endpoint that has it set to "no"
would have it because somebody set it to that value, so an operator had done that.
And yes, "reauth=no" leads to basicly no traffic interruptions.

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 16:22 schrieb Tom Rymes:
> On 03/12/2015 11:16 AM, Noel Kuntze wrote:
>
>> 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.
>
> Noel,
>
> Is there a reason that, when using two Strongswan endpoints, one would not choose reauth=no? It seems to me that using reauth=no would result in fewer traffic interruptions, unless I have missed something.
>
> Tom
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

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

iQIcBAEBCAAGBQJVAbBcAAoJEDg5KY9j7GZYHZUP/jH70zpMPuOsXkK56mis0l79
dCOFkMnPPopZ+LShK8kRvdB4fyKF4G2EfXq0Iv/9aFtwsz1L0nb3+ESBEB6oannV
E87tSaA98W1g92GQRfrol5Av5PUcAdojboJ/BZbqZ7Ak18VSywLFf9KhbTqyedxF
MfFxXyeo2+J8jpyvN7e+Sdh6ifkSfw4Q/kwD1ZS9gKipRdka1WxmOs0EPsGxxanm
frpGPqmV6Uqpjohcoyxtxs+RgkJorFOGI1kPNqKQXcwxyf3TLvvEOgmv3FxA/5eS
Linqzeb5cWTVhEL5SFpWbknp/KVsf/qcqnopXFnBVRh5P6lUvbHP8fF3bVC8f9mF
fpf9iprbDXKqxQ4ORzkzPGhzzD3Npp4DKNbt4+4YG+gomIXdDjiG2icpDqQz4Ac2
CuUzRuCnBAfWHhToJENXegu0bk8HJbWThdlu1w3ccUJk3b9ViS3qiU0CZIvJ3vWw
sHaMD6Q4Gt5bogqLJDpr9r5g7tbRtP8Q3KE/MgccDjzkB4SIH950yyNi6D4/yBH/
rPpH8JYfHm9VOLh8q7trLifqsbvhsoUtUgljfE2d4HAxNdwz7HbiYd1So5zaQJmU
IT4lnkOOHpZRqKIgEMhKvttVMTCYlJDS5+94d+Aa4i6y+eB49Puh9swkEQVftCJg
GiB00g0/cvtPCsl50/7m
=9q9P
-----END PGP SIGNATURE-----