Monitor a Router VPN Without Trusting One Status Light
Peer state, the selected route and a permitted application probe answer different questions. Alarm on the boundary that failed, not on a green icon.
The status page says connected, the light is green, and the office cannot reach the file server. One of those facts is about the tunnel and the other is about the path through it. Monitoring both is the difference between an alert you can act on and one you learn to ignore.
Five checks, in order, from the peer outward.
Check 1: peer or association state
Each protocol exposes its own state. WireGuard shows the latest handshake and transfer counters per peer through wg show. OpenVPN writes session state to its status file or management interface, and IPsec exposes security associations through tools like ipsec statusall. The trap is reading a timestamp as a verdict: an idle WireGuard peer with nothing to send will not handshake recently, and that is not an outage.
Compare the timestamp against expected traffic and keepalive settings before you page anyone.
Check 2: the selected route
A tunnel interface can exist while nothing routes into it. Check the forwarding table for the destination you care about, not for the tunnel's own subnet. If the prefix is missing or points elsewhere, the peer state is irrelevant.
That check catches the failure a status light never shows.
A useful second check also compares the source address. ip route get 10.20.5.10 returns the next hop, the interface and the preferred source, and a wrong source is enough to break return traffic at the far end. Record the expected triple once, then alert when any element changes. That single line catches NAT changes, interface flaps and policy-routing mistakes.
Check 3: a permitted application path
Probe something representative of the actual requirement. A router-originated ping leaves from the router's own address and policy, which may differ from forwarded LAN traffic, and many hosts rate-limit ICMP. If the requirement is a private service, test that service on its real port.
Keep the probe volume modest. A monitoring loop should not become the traffic it measures.
Check 4: what changed and when
Correlate WAN changes, rekeys, route withdrawals and application failures on one timeline. Distinguish a tunnel failure from a fallback route quietly restoring ordinary internet access, because those produce identical user reports and opposite diagnoses. Timezone errors will reverse the order, so normalise before comparing. The timeline is what turns four checks into a cause.
Preserve logs for the transitions, not for the payload.
Check 5: the alarm should name the boundary
An alarm that says VPN down sends someone to the wrong place half the time. One that says peer handshake stale for twelve minutes, route to 10.20.0.0/16 absent, or probe to port 445 failing, points at a specific check.
Keep operational counters rather than browsing payloads. Counters answer the monitoring question without collecting content you do not need.
And let the failover policy decide what happens next. Monitoring should identify which boundary failed, not authorise a broad bypass every time a probe fails. The OpenVPN 2.6 manual documents the status file and management interface that make the first check scriptable.