OpenVPN Won't Start: Read the First Line, Not the Config

A VPN that dies in the first second is a different animal from one that connects and then fails, and the usual mistake is to treat them as the same. There is no handshake here, no certificate exchange and no route to examine. One line in the journal decides which of several unrelated repairs applies, and skipping it costs an afternoon editing a configuration that was never read. Read that line first.

Three read-only commands get you there: journalctl -u openvpn@server -b --no-pager first, systemctl status openvpn@server second, and ss -lunp for the UDP listeners and their owners.

The First Line Picks the Branch

A port conflict and a missing binary both kill the start within a second, and they leave different first lines. An address-already-in-use message names the port; a missing executable names a path that no longer exists; a failed condition or an absent configuration file names the file. Those three lead to different repairs, and none of them improves by reinstalling the client. Copy the first failure into your notes before running anything else.

Watch for the retry loop that hides the original line. A unit with a restart policy can bury the first failure under a dozen identical ones, so journalctl -b filtered by the unit and read from the top beats the tail.

Who Else Is Holding Port 1194

The culprit is usually not a second server somebody deliberately configured. Expect a hand-started client still alive in another terminal, a second profile that happened to pick the same port, or a vendor bundle whose own tunnel holds 1194. The socket owner appears in ss -lunp; feed that PID to systemctl status to learn whether a unit is responsible. Take it down through its own control path instead of with a signal.

A signal to a unit-managed process typically triggers a restart, and the same failure reappears moments later looking like a fresh problem. Use systemctl stop for a unit, the bundle's own service command for a vendor install, and a signal only for something you started by hand in that shell.

Leftover Units After a Purge

A purge deletes binaries; unit files written by hand, typically under /etc/systemd/system, survive it. Systemd then retries a unit pointing at a path that no longer exists, and the message concerns that missing file rather than yesterday's removal. systemctl status shows the unit's fragment path near the top, so check it with dpkg -S before deleting anything. Once the orphan is gone, systemctl daemon-reload and systemctl reset-failed clear the state; otherwise every later status check inherits it.

When which openvpn answers with something under /usr/local, the binary in play came from a vendor installer rather than from apt. Such an installer typically brings its own listener, its own boot entry and its own configuration directory, so removing the visible command leaves the socket occupied.

Uninstall it with whatever the vendor documents, confirm the port is free with ss -lunp, and add the distribution client only if you need it.

Settle the State Before Retrying

Clear the failed state before drawing conclusions from it: systemctl reset-failed removes the counters, and systemctl status then reports the unit's current condition rather than its history. Start it once and read that instance's own journal rather than the aggregate state of the box. A unit reporting active while the tunnel carries nothing is a separate problem, and a much more common one. The two get merged in bug reports because both end with the user saying the VPN is not working.

Note the branch you took: port conflict, missing binary, missing configuration. The next occurrence will be quicker to recognise.