What persist-tun and persist-key Actually Survive in OpenVPN

Stopping the service removes the interface even with persist-tun set. That is the option working as documented rather than failing. The option describes one restart path inside a running process, and systemctl stop is not that path.

Read the two names together and the design becomes clear. One keeps a descriptor, the other keeps key material, and both exist because of what happens after privileges are dropped.

The Two Resources and the Reset They Belong To

OpenVPN signals its own restart in two ordinary situations. An explicit SIGUSR1 does it, and a ping-restart triggered by a dead peer does the same. Both leave the process alive and re-run the connection setup, which is where the options earn their place.

Only the soft-reset row is what these two options change, and the work they skip is the expensive part on a busy link. Reopening a device tears down the addresses and routes attached to it, and rebuilding them can drop packets that were in flight when the reset started. A stop destroys the same objects with no option to preserve them.

Why the Options Exist at All

A hardened OpenVPN server usually starts as root, opens its keys and its device, then drops to an unprivileged user. After that drop, some operations are simply gone. Reading a mode-0600 key file, creating a network interface, or changing routes can all be refused.

Without the persist options, a peer that goes quiet long enough to trigger ping-restart would force exactly those operations. The reconnect would fail even though nothing about the configuration had changed. The process would appear to die for no reason, and the log would show a permission error rather than a network one.

With them, the soft reset reuses what the privileged phase already obtained. No magic is involved and the process does not survive anything. Resource acquisition is simply deferred.

Read the First Error, Not the Last

When a reset fails, read the first error rather than the last one. A protected key, an auth file, an interface ioctl and an external hook are four different resources. Retaining one says nothing about access to the others. A hook that calls a firewall tool still needs the privileges that tool demands.

Hooks have their own switch. The OpenVPN manual pairs the persist options with up-restart, which decides whether the up and down scripts run again after a restart. An interface that stayed up therefore tells you nothing about whether your resolver integration refreshed.

# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'

# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0

That pair of commands separates the two failure modes in seconds. An interface that is present with routes missing is a hook or route problem. An interface that vanished means the process actually ended.

A Retained Interface Is Not a Kill Switch

If the requirement is that traffic must never leave outside the tunnel, a persisted device does not deliver it. Routes for the other address family, a second default route, and the case where the process exits entirely all remain outside the option's scope.

Treat the two requirements separately. Keeping the tunnel object across reconnects is a convenience for the daemon. Blocking egress when the tunnel is down is a firewall policy with its own rules and its own test. Conflating them produces a configuration that looks defensive and behaves like best-effort reconnect.

Name the event before diagnosing it. A soft reset, a failed connect attempt and a service stop are three events with three behaviours, and only the first is what these options describe.