Monitor an IPsec Tunnel Interface: What to Read

A route-based IPsec design installs a virtual interface, and that interface hands monitoring a concrete object: something with a name, counters and a route attached to it. It is not a health signal on its own. The interface can exist while no usable association is installed, and an association can be healthy while no route sends the interesting traffic its way. Reading four states together is what turns a packet count into a diagnosis.

Work through them in order and stop at the first one that fails.

What the Interface Adds to the Picture

With a policy-based design, selection lives in the IPsec policy table and the kernel decides what gets protected from traffic selectors. A route-based design adds an interface and a route, so tcpdump and interface counters see one boundary instead of a set of selectors. That is a real gain for diagnosis and for routing protocols that need an interface to peer over.

The gain is administrative, not cryptographic. The interface reports the traffic it carries, and says nothing about whether the peer's protection is currently usable.

Read the Four States Before Blaming the Tunnel

Start with the interface and the route, then the association, then the application. Each has its own command and its own failure signature. A clean result at one layer is not a clean result at the next. Run all four before drawing a conclusion. One green line rarely settles anything.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

An interface with a rising counter but no matching state entry describes traffic entering a path with nothing protecting it, which is worse than a tunnel that is simply down. A state entry with no route selecting the interface means the cryptography is ready and unused.

The application test comes last and on purpose: a successful ping to the far side of the tunnel does not prove the service behind it accepts connections.

Compare Inner Counters With Outer Counters

Counters on the tunnel interface measure inner traffic; counters and captures on the physical interface show the encapsulated exchange. The two will not match one for one, because encapsulation adds headers, retransmissions duplicate some packets and the implementation's accounting has its own rules. Expect a ratio, not equality.

Capture placement also decides what private data you collect, so use narrow filters and a harmless test address rather than a full capture of production traffic.

If inner counts rise and outer counts do not, the missing step is usually the route or the policy that sends packets into the tunnel, not the tunnel itself.

Watch It Through Rekey and Failover

Observe a rekey, a dead-peer detection event and a link failover while watching the same four states. An interface can remain present through a rekey that never completes, and a failover can leave a state entry pointing at a peer address that is no longer reachable.

Alert on the service path you actually depend on, with the association state as context, rather than on a single up or down flag. Keep the interface name, the peer address and the route in the alert payload so the responder does not have to reconstruct them.

strongSwan documents its own XFRM interface model, and other platforms name and implement the equivalent object differently. Read the route-based comparison for the device in front of you before transferring assumptions from a different implementation. A monitoring template that fits one vendor's counters will quietly mislead on another.