Rekey, Reconnect or Reauthenticate: Which Do You Need?

A session that has been up for hours will not keep the same keys forever, and that is by design. Three different events get described as key rotation: new session material under an existing association, a full rebuild of the connection, and a repeat of the identity check. Each has a different trigger, a different cost and a different failure signature. Pick the wrong one and the fix either does nothing or takes the tunnel down for no reason.

The decision depends on which layer actually expired.

Three Operations That Get Called Rotation

A rekey creates fresh traffic keys within the existing control relationship, using the mechanism the protocol defines. IKEv2 does this with a new child security association, TLS 1.3 with a key update message, and WireGuard with a fresh handshake once its time or message limits are reached. The tunnel addresses and the authenticated identity stay where they were.

A reconnect discards the connection and builds it again from the beginning, which repeats address assignment, routing installation and any negotiation the first attempt performed.

Reauthentication repeats the identity proof itself, which may involve a credential, a certificate or a second factor. It can happen with or without a reconnect, depending on the product.

What Users Notice at Renewal

A rekey should be close to invisible. Association identifiers change, counters may reset, and applications keep their sockets; a brief pause in one direction is normal during the exchange. Seeing a new identifier in a status listing is not evidence of a fault. The log line that follows the exchange is what tells you whether it finished.

An actual drop at renewal points somewhere specific. A proposal mismatch, an expired credential or a path change each produces a different log line, and only one of them is fixed by adjusting lifetimes.

Where the Three Diverge in Practice

If the only thing that expired is key material, rekey. If the peer address, route or NAT binding changed and packets no longer arrive, reconnect. If the organisation requires a periodic identity check, that is reauthentication and no amount of lifetime tuning replaces it.

Protocol defaults usually encode the right answer. WireGuard rekeys after a time and a data-volume threshold without any user action; IKEv2 lifetimes are negotiated per child association; TLS-based tunnels rotate keys inside the existing session. Raising lifetimes to avoid a recurring error postpones the failure and lengthens the exposure if a key is compromised.

One caveat matters for long sessions: frequency alone does not create forward secrecy. The property depends on how session keys relate to long-term secrets and on whether old keys are destroyed, which is a design and implementation question rather than a setting.

Pick Defaults, Then Record the Stage

Keep the vendor's defaults unless a documented requirement says otherwise, and change lifetimes on both peers if you change them at all. Then record which stage each event reached, so the next occurrence can be checked against the same point in the handshake.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

After a correction, run a controlled renewal and send fresh application traffic through the new association. A tunnel that reports established but forwards nothing is the failure this check exists to catch.