Shortening the DPD Timer Won't Make VPN Failover Faster

Tunnels drop, recovery takes ninety seconds, and the dead-peer timer is set to ten, so the timer gets blamed. That reasoning skips three stages that happen after detection and usually consume most of the time. Liveness detection notices silence; peer selection, authentication, route installation and application reconnection then each take their own turn. Shortening the first stage cannot shorten the others, and it can add churn to a system that was already struggling.

Four stages, one of which you can time

Write the recovery as four events with timestamps. Failure becomes observable: the last useful protected traffic and the first failed request. The owning mechanism reacts: liveness detection, a route monitor or another documented trigger. The alternate becomes usable: peer selection, authentication, a new association, and a route that actually carries the intended traffic. The application recovers: a fresh operation succeeds and whatever was in progress has a defined outcome.

IKEv2's liveness rules describe evidence about the peer and its exchanges, and say nothing about a database or a file service behind that peer. Reading a liveness timeout as a health check for the whole path is the mistake that starts the timer hunt.

Why the timer is the least interesting number

Configured values are not interchangeable units. Some are retry intervals, some are upper bounds on an attempt, and some run concurrently with others. Adding them together produces a number that looks like a prediction and behaves like a rumour. Read the documentation for the field you are about to touch, and note which of the three kinds it is.

Other stages are not timers at all. A reconnect backoff, an interactive authentication prompt or a client that only re-evaluates its configuration on restart can each dominate the outage while every protocol timer sits comfortably low.

Measure the stage that is actually slow

Capture the failure once, with timestamps on both sides, then compare the four events rather than the protocol's own counters. One observation window done properly beats a month of tuning.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

If the alternate endpoint never answers, no timer change helps, because unreachability is not a detection problem. If new security state forms quickly but the route still points at the dead path, the problem is route installation and another liveness tweak only adds churn.

The alternate must already be usable

A backup defined in a configuration is not a backup that works. It has to be reachable from the client's current network, able to authenticate the same identity, and permitted to carry the same traffic under the same policy. Discover any of those three gaps during an outage and the timer discussion becomes irrelevant. Test the alternate while the primary is healthy, because that is the only time you can read both logs side by side.

Pre-provision the alternate, test it deliberately while the primary is healthy, and record which stage of the four takes the time. That record is what makes the next change a measurement instead of a guess.

Failback churn and the management path

Restoring the primary is a separate decision. Aggressive failback can interrupt work that had already recovered on the backup, and a flapping path can look like an unstable tunnel when the real fault is a route that keeps oscillating between two equal options.

Two equal-cost paths with no preference are the usual source of visible flapping, because each monitor reacts to the other's choice. Decide which path is preferred under normal conditions, and make that preference explicit in the configuration rather than leaving it to route ordering. Define the desired failback behaviour and who owns it, in advance. Keep the previous settings and an independent management path, because a change that removes your own access during an outage converts a network incident into a site visit.

Then repeat the same workload and compare the same four timestamps. A shorter recovery that still leaves the application waiting on the same missing route or login is not progress, it is a different number on the same graph.