The make-before-break re-authentication feature is good news. Very interested
in trying it out - it there an expected date for the 5.3.0 release?
> On Mar 12, 2015, at 9:32 AM, Martin Willi wrote:
>
> Hi Tom,
>
>> Is there a reason that, when using two Strongswan endpoints, one would
>> no
On 03/12/2015 11:32 AM, Martin Willi wrote:
Is there a reason that, when using two Strongswan endpoints, one would
not choose reauth=no?
Yes. Reauthentication re-evaluates authentication credentials, checks
the certificate status or rechecks permissions in the AAA backend.
IKE_SA rekeying, as
Hi Tom,
> Is there a reason that, when using two Strongswan endpoints, one would
> not choose reauth=no?
Yes. Reauthentication re-evaluates authentication credentials, checks
the certificate status or rechecks permissions in the AAA backend.
IKE_SA rekeying, as used with reauth=no, only refreshe
-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 interrupti
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 IK
-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 I
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 hou
