IPsec Drops at Regular Intervals: Trace Rekeying Before Retrying

A tunnel that drops at roughly the same age each time deserves a renewal investigation. IPsec can pass traffic normally until an IKE or CHILD security association needs replacement. Reconnecting the client may restore service while hiding the reason the next renewal will fail.

Start by measuring elapsed tunnel age, not just wall-clock outage time. A failure sixty minutes after every connection is a different clue from a failure at 09:00 every day. The strongSwan renewal documentation distinguishes rekeying from reauthentication and describes overlap considerations. Apply its guidance to your exact version and peer configuration.

Separate the associations involved

An IKE security association supports the control relationship between peers. CHILD security associations carry protected traffic. Their renewal schedules and failure modes need not be identical.

Write down configured lifetimes and renewal settings on both sides. Include whether the connection uses reauthentication, which involves authenticating again, rather than only replacing key material. Do not assume two similarly named lifetime fields in different vendors’ interfaces control the same event.

Identify the affected traffic selectors as well. One application subnet may lose its CHILD association while another continues working, making the incident look like an application-specific routing problem.

Build a shared event timeline

Collect logs from both authorized peers for a short period spanning the expected renewal. Record clock offsets or synchronize the interpretation of timestamps. Protect identities, public addresses where sensitive, certificate details, and secrets before sharing logs.

Capture the initial successful establishment, renewal attempt, peer response or timeout, old-association deletion, new-association installation, and first observed traffic failure. These events explain much more than a generic “tunnel down” message.

Use an association identifier to connect related events rather than matching only similar timestamps. If several tunnels renew concurrently, a log line from the wrong connection can lead to an entirely false diagnosis.

Ask which handover step fails

There are several distinct possibilities. A peer may not respond to the renewal request. A proposal may be rejected. A new association may be established but not selected for outbound traffic. The old association may be removed before the replacement is usable.

For each possibility, identify the evidence that would distinguish it. A successful negotiation message does not prove data traffic switched to the new state. Confirm packet counters or a controlled application probe after the handover.

Do not immediately weaken algorithms or disable authentication checks to make a negotiation succeed. First compare supported, approved settings and identify the specific mismatch. Any cryptographic policy change requires the appropriate security review.

Consider reauthentication separately

Reauthentication can expose credential or certificate problems that were not visible during an earlier connection. It can also involve different overlap behavior from ordinary rekeying. Check the documented make-before-break or break-before-make behavior supported by the actual peers.

If a certificate expired during a long-lived connection, reconnecting with a different credential may obscure the original failure. Record which identity and credential were actually used at each event. Do not post private keys or authentication material in a diagnostic ticket.

Changes to renewal timing should preserve the intended security policy. Extending lifetimes indefinitely or disabling renewal is not a sound production remedy for an unexplained handover failure.

Test one cycle under controlled conditions

Choose a maintenance environment or a low-risk test tunnel. Save current settings and a rollback procedure. Use the implementation’s supported renewal mechanism, or a short test lifetime appropriate to that isolated environment, to observe the failure without waiting for a production outage.

Run a low-volume bidirectional application probe during the cycle. Record whether existing traffic stalls, whether new connections fail, and how long recovery takes. These are different user-visible effects and may indicate different state transitions.

Make one setting change at a time. If you alter proposals, lifetimes, routing, and firewall rules together, a successful cycle will not reveal which change mattered or whether an unnecessary security relaxation remains.

Check the path after a successful negotiation

If both peers show successful replacement, inspect route selection, policy installation, NAT behavior, and packet counters. The control plane can appear healthy while data packets use stale or mismatched state.

A size-dependent failure may instead require VPN MTU testing. Keep that investigation separate: a regular renewal clock and a large-packet threshold are different observations, even when both affect the same tunnel.

After the apparent fix, observe more than one renewal cycle and test traffic in both directions. A single successful reconnect does not verify renewal reliability.

Check whether both peers initiate renewal at nearly the same time. Simultaneous attempts can exercise collision-handling paths that an ordinary one-sided test misses. Record the behavior before changing timer offsets, and verify that any adjustment remains within the approved lifetime policy.

Conclusion

Treat periodic IPsec loss as a state-transition problem. Correlate both peers, identify the association and handover step involved, and prove that protected traffic survives renewal before closing the incident.