IKEv2 Rekeying vs Reauthentication: Why It Drops Later

The tunnel comes up in the morning and works for hours. Then it drops, reconnects after a retry, and does the same thing again the next day. Nothing changed on the network and nobody touched a password. Sessions that fail at a renewal boundary are usually crossing one of two different operations, and only one of them re-checks your credentials. Reading which one fired is the entire diagnosis.

Two operations that look similar from outside

Rekeying replaces security associations or key material under the protocol's defined exchange. Authentication is not repeated, so the identity that was accepted at the start of the session is simply carried forward.

Reauthentication goes further: it establishes a fresh authenticated relationship, which means the credentials are evaluated again. Anything that expired, was revoked or was changed in the directory becomes visible at that moment.

What a rekey actually replaces

IKEv2 keeps two kinds of association with separate lifecycles. The IKE SA protects the control channel, and CHILD SAs protect the actual traffic. Renewing one is not a synonym for reconnecting the client.

That separation explains a familiar pattern: traffic flows fine, then a CHILD SA is renewed and the proposal no longer matches because someone edited phase 2 on one side weeks earlier. The change sat there harmlessly until the renewal exercised it.

Lifetime mismatches behave the same way. Whichever peer reaches its limit first starts the exchange, and the other has to accept it.

What reauthentication re-evaluates

With reauthentication, the client certificate that was valid at login may now be expired. A revoked credential, a rotated password or an unavailable second factor all surface here rather than at rekey time.

This is why extending every lifetime feels like a fix and is not one. You have postponed the check rather than passed it. The next renewal arrives with the same defect and a shorter outage window to notice it.

Some implementations overlap old and new state during reauthentication. Others produce a brief gap. Identical settings on two vendors can therefore give different user experiences. Test the behaviour rather than assuming the standard dictates it.

Read the timestamps before changing anything

Capture the moment of failure together with the association state before and after. If the old association was replaced without an authentication exchange, you were at a rekey boundary. If an AUTH exchange appears right before the failure, you were at a reauthentication.

strongSwan exposes this as separate settings: rekey controls key renewal, reauth controls whether a new authentication happens, and margin values decide how far ahead of expiry each starts. The rekeying documentation describes the interaction, and it is worth reading before copying a lifetime from a forum post.

Distinguish all of this from a plain network loss. A dropped link produces a dead peer detection event or a retransmit storm, not a clean exchange with matching proposals.

Change the thing that failed

A credential rejection needs the identity problem fixed: renew the certificate, restore the account, re-enrol the factor. A proposal or lifetime mismatch needs the parameters compared on both sides.

Stretching lifetimes to avoid the symptom is the one option that always looks like it worked and never does.

Test a controlled renewal

Force the renewal rather than waiting a day for it. Then repeat with a reauthentication if the deployment supports one, and watch both endpoints.

A successful initial login exercises none of this. The lifecycle after it is where these deployments actually break.