OpenVPN keepalive or systemd restart: which one recovers?

Three different things can go wrong with a tunnel, and they call for three different reactions. The peer stops answering, the daemon process dies, or the application behind the tunnel stops serving. A configuration that restarts the service on any of them is not careful supervision; it is one blunt action applied to unrelated failures. Comparing what each mechanism can actually observe makes the division of labour obvious.

Three failures that look like one

Peer silence means the other end stopped sending, and OpenVPN can detect that itself because it owns the heartbeat. Process death means the daemon exited, which the service manager notices and OpenVPN cannot. Application failure means the tunnel is fine and something behind it is not, and neither of the other two mechanisms has any way to know. Each one needs a different reaction, and none of them is the same as noticing that the tunnel is up.

These are different signals from different layers, and each one has an owner that can act on it without guessing. Mixing them produces a system that restarts on symptoms it cannot interpret.

Write the three cases down before changing any timer. The list itself usually shows that one mechanism is being asked to cover all three.

What keepalive actually expands to

The keepalive directive is shorthand, and the expansion differs by mode. On a server, keepalive 10 60 becomes a local ping every ten seconds, a local restart timeout of 120 seconds, and pushed values of 10 and 60 for clients. The server timeout is deliberately doubled so a client gets a chance to restart before the server gives up. Read the expanded form in the running configuration rather than the shorthand in the profile.

That doubling is why any description claiming both ends restart after sixty seconds is wrong. It also explains why the two ends do not flap in step when a path degrades.

The heartbeat is OpenVPN peer traffic, not an ICMP probe of some public host. A reply only proves the far end of the tunnel is alive. It says nothing about the database or web service the user actually needs.

What Restart=on-failure does not watch

Read the installed unit before adding an override. Restart=on-failure responds to documented process-failure conditions, which is not the same as watching connection state. It does not fire because an internal reconnect started, and a clean exit has different semantics from a crash.

That distinction matters because an internal restart keeps the same process alive. The unit sees nothing, the tunnel recovers on its own, and that is the correct outcome.

Set RestartSec and start limits deliberately, or a crash loop will hammer the gateway and bury the real error under restart messages. A restart limit that trips leaves the unit failed, which is visible, while an unlimited loop is not.

ping-restart and ping-exit are not interchangeable

ping-restart triggers OpenVPN's internal restart and keeps the process. ping-exit ends the process on the same kind of timeout, which hands the decision to the service manager. They are mutually exclusive, and choosing the second changes who owns recovery. The difference is who decides to try again, and how much state survives the attempt.

If you choose exit-on-timeout, the unit needs a restart policy and exit-status handling that match, or a liveness failure looks like a permanent stop. Persistence options can also preserve interfaces and routes across an internal restart but not across a process exit.

Pick one lifecycle per deployment and write down why. A profile carrying both directives is a profile that has not decided.

Test each failure as its own case

Simulate a quiet peer, a killed daemon and an unavailable application in an approved window, then check which recovery fired. A quiet peer should produce an internal reconnect, a killed process a unit restart, and an application outage neither of those. When two cases produce the same action, the ownership is still mixed.

Repeated recovery is not a repair, either. Rejected credentials or two clients sharing an effective name will keep replacing each other, and faster timers only make that flapping quicker.