Headless OpenVPN: Supervised Session or a Managed Service
Starting OpenVPN over SSH is a remote network change. Pick a supervised session or an owned service, and prepare credentials plus a way back in.
Running OpenVPN over SSH starts it on the remote machine, in that machine's execution context. That makes it a remote network change rather than a remote button press. The two sensible modes are a supervised foreground session and an owned service, and they have different preparation, different credentials and different failure behaviour.
Two modes, one profile
Both modes consume the same profile and both change routing on the host. What differs is who is present when it starts, and what happens after the session ends.
| Mode | Useful for | What it needs |
|---|---|---|
| Supervised foreground session | A connection with a human watching and able to type | A usable terminal, a reviewed profile and recovery access |
| Managed service | An unattended lifecycle that starts without a login | Owned configuration, supported credential delivery and restart policy |
The foreground mode is for a supervised connection where someone is present. The service mode is for a connection that should come up without anyone logged in. Mixing them, by leaving a foreground process running while also enabling a service on the same profile, is the most common self-inflicted breakage here.
What the foreground session really is
A foreground OpenVPN process is supposed to keep running while the tunnel is up. Initialization Sequence Completed means initialization finished, not that you should wait for a prompt to return. A desktop GUI hides that long-running work behind a window, which is exactly why people expect the SSH command to behave the same way. It does not.
Check the application's access separately. An occupied terminal and one log line prove neither success nor failure.
What an unattended service needs
A service starts with its own account, working directory and filesystem restrictions, and all of those differ from your shell. Use explicit paths and appropriate ownership rather than relying on where you happened to be standing. Give the unit a restart policy you actually want, because a connect loop with no backoff fills a log and irritates the peer. Then verify it comes up after a reboot rather than after your next login.
Interactive MFA breaks the unattended case by design. If the profile needs a code typed by a person, it is not an unattended service, and a stored one-time code is not a credential design. Decide that deliberately instead of discovering it at boot.
Credentials are four different inputs
OpenVPN's manual separates console input, credential files, private-key passphrases and management-driven interaction. A username and password pair is one thing, and an encrypted key's passphrase is another. A management interface that supplies credentials on request is a third. Pick the mechanism that matches your authentication design instead of concatenating everything into one file because that happened to work once.
Protect the profiles and logs that carry identity or private material. The service account reads them, and so does anyone with the right group membership.
One owner, and a way back in
Preserve your SSH administration path before enabling a broad tunnel route. A full-tunnel configuration with an endpoint that dies can leave the machine unreachable, and the fix then involves a console you did not arrange. An approved out-of-band console or a deliberate management-return policy is the insurance policy.
Choose one configuration owner for routine operation. An automatic service and a foreground process competing for the same interfaces, routes and resolver state produce failures that look like a provider problem. Stop a supervised run with its normal interrupt, and stop a managed one through its manager rather than killing every process named openvpn.
The distinction to write down is simple: a supervised run may depend on your session, and an unattended service may not.