Why a busy IPsec tunnel rekeys early: time versus volume limits

Every fifty minutes or so, a tunnel on a busy link drops for a few seconds, and the first suspect is the clock. Associations can end on a time limit or on a byte count, and whichever boundary arrives first is the one that retires them. On a link carrying real traffic, a volume limit can fire long before the configured hour is up. So "too early" is a statement about the clock, not about the association.

Count what the association counts, not the interface

An interface byte total, a dashboard's combined throughput and the association's own counter are three separate numbers, and only one of them is compared against the limit. Record the inbound and outbound associations separately with their identifiers, so a rekey that touches one direction shows up as a directional event instead of a mystery. The association counter also starts again at rekey, which is why a total taken from the interface grows while the value that matters resets.

The arithmetic is worth doing once so the order of magnitude stops feeling arbitrary. A counted budget of one gibibyte drained at a steady 128 mebibytes per minute is exhausted in eight minutes, and that is a unit conversion rather than a measurement of your tunnel. If the resulting figure sits far below the time limit, volume is the mechanism and no amount of clock-watching will explain the interval. If it sits far above it, the byte limit is not your trigger and the search belongs somewhere else.

Soft and hard thresholds are two different events

A soft threshold asks for a replacement well before the hard limit ends the association, and implementations layer their own margins and randomization on top of whatever you configured. That is why the observed interval is almost never a round number. The IPsec architecture describes lifetimes expressed as time and byte counts with the two threshold kinds, and the earlier expiration governs. Treat one printed lifetime as a schedule and you will be wrong by the margin.

Read the effective policy from running state instead of inferring it from a number in a file, because the margin belongs to the implementation, not to your intent. Resist stretching limits toward their maximum to silence the symptom: a tunnel that rekeys on schedule is behaving as designed, and a longer lifetime only postpones the event while keeping a compromised key usable for longer. When the replacement itself fails, the limit is the messenger rather than the fault.

Read the effective lifetime from the running state

On strongSwan, swanctl --list-sas prints the association summary with its rekey and life times, so the value the daemon intends to enforce is visible without guessing. On a Linux host without a daemon view, ip xfrm state reports the configured soft and hard byte and packet limits next to the current counters. Those two readings answer different questions and both are worth keeping in the ticket.

swanctl --list-sas
ip -s xfrm state

Compare the printed soft threshold with the interval you measured, because a replacement that starts at a margin below the hard limit is normal and a replacement that never starts is not. If the daemon shows one lifetime and the kernel state shows another, you are looking at two layers that disagree, which is itself the finding.

Watch the exchange that replaces the SA

Keep three renewals separate, since they fail in different ways: an IKE SA rekey builds a new control association, a CHILD SA rekey replaces the data association, and reauthentication repeats the identity exchange. In IKEv2 each peer decides its own lifetimes rather than negotiating one shared value, so an exchange you did not initiate is ordinary. A perfect-forward-secrecy mismatch is a frequent reason a new child SA dies precisely at the rekey interval, and it presents exactly like a timer fault until someone reads the proposal.

Compare the old association with its successor and with the exchange that produced it. An identifier disappearing is routine replacement; a rejected proposal, a missing response or the absence of usable successor state is a different event with a different owner. Preserve that evidence before changing anything, because the version-specific notes, the peer's proposal and the negotiated lifetimes are what make the case readable a week later, after the logs have rotated.

Prove the renewal instead of hiding it

Accept the deployment by passing through a renewal you planned rather than one that happens to you. Force a single rekey inside a maintenance window, then confirm that both directions carry data afterwards and that the application result is unchanged, not merely that the tunnel indicator is green. Record which limit fired and which exchange was involved.

A conclusion of that shape survives scrutiny, while a changed timer value that made the connection look quiet for an afternoon does not. If only the timer moved, the evidence moved with it.