A VPN should be considered healthy only when its tunnel, routes, and real traffic all work. Checking just one of these can report a false success.
The design decision
A network interface marked “up” does not prove that a VPN can carry traffic. The interface may still exist after a broken handshake, a routing problem, or an unreachable remote endpoint.
A useful health monitor should test the connection in layers. Each layer answers a different question and makes failures easier to diagnose.
Use three health checks
- Find the tunnel interface. Confirm that the expected VPN interface exists and is active. Avoid relying on a temporary interface number because operating systems can assign a different number after reconnecting.
- Check the routes. Confirm that the routes which should use the VPN actually point to that tunnel. An active interface without the required routes cannot carry the intended traffic.
- Test real connectivity. Make a short HTTPS request through the tunnel itself. Bind the request to the tunnel address or interface so a successful request cannot silently use the normal internet connection.
Why one signal is not enough
Cause: The tunnel interface exists, but the VPN session is no longer usable.
Fix: Add a real outbound request through the tunnel.
Cause: A normal connectivity test succeeds through the default network instead of the VPN.
Fix: Bind the test request to the VPN interface or tunnel address.
Cause: One remote test service has a temporary outage.
Fix: Try a second independent HTTPS endpoint before declaring a failure.
Cause: A brief packet loss event triggers a noisy alert.
Fix: Require two consecutive failed runs before marking connectivity as down.
Alert only when the state changes
A monitor that sends the same warning every few minutes quickly becomes background noise. Store the previous result and notify only when the state changes:
- Healthy to down: send one alert with the failed check and local time.
-
Down to healthy: send one recovery notice.
-
No change: stay quiet.
A missing tunnel or missing required route is usually clear enough to report immediately. For an outbound timeout, confirming the failure on the next run helps prevent false alarms.
Keep monitoring separate from recovery
Detection and repair are different responsibilities. Start with a read-only monitor that does not reconnect the VPN or change routes. Automatic recovery can be added later, after its safety rules and failure modes are understood.
Bound the probe and inspect HTTP results
An example for a curl build that supports interface binding is curl --interface YOUR_TUNNEL --connect-timeout 5 --max-time 10 --fail --silent --show-error https://example.com/health. Replace the interface and endpoint for the platform. Check the exit status: receiving an HTTP error page is different from a healthy response. Keep each probe bounded so a hung request cannot stall monitoring.
The practical takeaway is simple: monitor the tunnel interface, the route, and traffic through the tunnel, then alert only after a confirmed state change.
Reference: curl options.