Port 1194 Already in Use: Who Owns That OpenVPN Socket?

Start the same server profile twice and the second process exits with an address-in-use error for port 1194. In the common case the diagnostic launch created the conflict, and the original instance is still serving clients perfectly well. That story accounts for a large share of these reports, and it is worth recognising before anything is restarted. It is also the cheapest version to resolve.

The error describes a local binding and nothing beyond it. It is not evidence that a provider blocks the port, that a client sent the wrong password, or that the certificate chain is broken.

Read the exact bind error

Two errors in this family mean different things, and mixing them up sends you to the wrong layer. Address already in use says another socket holds the endpoint you asked for. Address not available says the address you asked for does not exist on this host yet, which is a readiness problem rather than a duplicate.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

Copy the error text before you change anything, including the address and port it names. A service that waits for an interface to appear will log the second error repeatedly and then bind successfully once the address exists; a service that logs the first error will never succeed until the duplicate is resolved. Recording which one you saw costs nothing and saves a wasted interface hunt.

Inventory the socket, not the port

A port number is an incomplete inventory. The endpoint is a transport, an address family, a local address and a port, all inside one network namespace. A UDP listener and a TCP listener on the same number are different sockets, and two processes on the same number in different namespaces never meet.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

Run the transport the profile actually uses first. Then look at the local address column rather than the number alone: a wildcard binding covers every local address, so a second process asking for one specific address can collide with it even though the printed strings differ. Socket reuse options and platform rules decide the exact outcome, which is why this should be an observation rather than a rule you apply to every deployment.

Find which process owns it

Numeric endpoints plus process information identify the owner when your privileges allow it, and the owner is what you need, not the program name. Two OpenVPN processes can be running different profiles, and the one holding the listener may be the one you least suspect.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

Match what you find against the service manager, a container runtime or a terminal process left over from an earlier test. Absence of process details is not evidence that the socket is unowned; it usually means the query ran without enough permission. Equally, a TCP-only listing does not clear a UDP conflict, so inspect the transport named in the error. A process name alone never tells you which profile was loaded, and the profile is what decides the endpoint.

One owner, or two designed instances

If the deployment intends one server, keep one lifecycle owner and read that instance's journal or configured log instead of launching a second copy to watch it. When a controlled foreground run is genuinely necessary, stop the managed instance deliberately and account for the clients it is serving before you do.

If two instances are intended, give them distinct listeners and distinct everything else: address pools, virtual interfaces, routing policy and configuration ownership. A different port alone separates nothing but the socket, and the two servers will still fight over the same pool and the same routes.

Three shortcuts are worth naming because they appear in every thread on this error. Do not kill an arbitrary PID that looks like the culprit. Do not enable socket sharing to silence the message. Do not switch a server profile to a client-style unbound configuration because that makes the bind error disappear; the server stops being reachable in a way that is harder to diagnose than the original conflict.

Changing the port is a legitimate answer only when the new listener is part of an approved design, which includes the forwarding rule and the client endpoint. If those were not updated, you have moved the conflict to a place where nobody can find it.

Verify the bind before anything else

After the scoped correction, confirm the intended instance is active, that its listener appears on the transport you expect, and that a client can connect. A successful bind only completes the local socket stage; it certifies nothing about authentication or about traffic once the tunnel is up.

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

If the socket is present and the client still fails, the remaining problem is downstream and the bind error is now history. That separation is the whole point of reading the exact message first: one error, one layer, one owner. Read it that way and the next symptom starts from a known state rather than from a guess.