IKEv2 Dead Peer Detection Does Not Test Your App

IKEv2 liveness checking asks one question: is the other peer still answering on the protected control relationship. It does not measure whether an internal application is healthy, whether a route exists behind the gateway, or whether browsing feels fast. The check can pass while every useful thing behind the tunnel fails.

Read the two kinds of evidence separately before changing a timer.

What the Liveness Check Actually Asks

A liveness exchange is sent inside the established IKE security association and expects an answer within a configured window. Success means the peer's IKE implementation is still there and still willing to talk. It says nothing about the child security associations that carry traffic, nothing about routing beyond the gateway, and nothing about the service you opened the tunnel for. Those are three separate questions with three separate failure modes.

That distinction decides where you look when a session goes quiet. A peer that keeps answering while a data path is broken points at policy, routing or a downstream service. A peer that stops answering points at reachability or at the far end's own state.

Read the Security Associations Before the Browser

The control state and the data state are listed separately once you ask the daemon, and the counters tell you whether anything was attempted at all. A child association that was never installed looks nothing like one that installed and then stopped passing packets, even though both produce the same user complaint.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Note the state names verbatim in the ticket, along with the counters at the moment of the complaint. A description like tunnel down hides which of the two associations ended, and that is usually the only fact worth having.

A Route Failure Looks Exactly Like a Dead Peer

The gateway can answer control exchanges while a private server is offline, a forwarded route is missing, or internal name resolution fails outright. From the client, every one of those presents as a session that is up and a destination that is not. Check the return path as carefully as the forward path, because asymmetric routing on the far side produces silence in one direction only.

Test the intended application directly and name the address it tried, rather than testing whether the tunnel is up. A ping to the gateway proves the gateway answers; it never proved the application did. Record the exact address the application tried. That string narrows the search later, and it is the one fact the ticket usually omits.

Keep Timers Out of the Diagnosis

Shortening a detection interval is not a performance change and does not add capacity. Under packet loss it changes how quickly a failure is recognised, which can make a symptom look different without making anything better. Record the real time of failure first, then decide whether the tolerance is wrong for the link you actually have.

NAT mapping refreshes belong in the same category. They keep a translated path usable, and they are not evidence that the remote application works.

A complete recovery policy says what the client should do when a peer is declared dead: restart, close, or hold, and what other traffic may do while that happens. Without that, the same incident gets re-diagnosed from scratch every quarter.