Which Ports Does OpenVPN Access Server Actually Listen On?
Walk the socket list on an Access Server host: recognise the default listeners, tell loopback from published, and check forwarding before closing a port.
You run ss -lntup on an Access Server host and get a list twice as long as expected. Half the entries are daemon-shaped ports nobody mentioned during setup. The reflex is to close everything that is not 443 or 1194, which is how people break their own client portal.
Access Server is not one listener. It is a VPN service, a web service, and a cluster participant, and it can generate extra daemon-specific ports and firewall redirections depending on how many TCP daemons you configured.
Walk the inventory in order: read the sockets, map the familiar ones, classify the rest by owner and bind, then check what actually publishes them.
Start with one read-only command
sudo ss -lntup gives you transport, local address, port, and owning process for every listening socket. The flags matter: -l listening, -n numeric, -t TCP, -u UDP, -p process. Without root you get sockets but not process names, which is exactly the column you need for classification.
Record four fields per row before forming any opinion: protocol, bind address, port, and command. Keep the Access Server version and the configured daemon count next to that list, because both change what is expected.
Two rows that look identical are not. TCP and UDP on the same number are separate sockets with separate exposure, and 0.0.0.0 and :: are separate binds for separate address families. A service bound only to 127.0.0.1 is not directly reachable from another host, though a local redirect can still publish it.
The listeners you should recognise
These defaults cover most deployments and give you a baseline to compare against. They are defaults, not a complete allowlist.
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
Everything beyond that needs an explanation, not an assumption. You will often see local-only listeners belonging to components the product installs for itself. Confirm them by PID and service configuration rather than by a remembered port number, and do not treat an unfamiliar port as hostile on the strength of unfamiliarity alone.
A socket outside the familiar pair is also not automatically a leftover. When multiple TCP daemons are configured, Access Server creates per-daemon listeners and redirects traffic to them, so their number and port values follow that configuration.
Classify before you close anything
For each uncertain row, answer three questions in this order.
- Owner and purpose. Match the PID to a unit or process and read that service's configuration. If you cannot name the owner, you are not ready to decide anything about the socket.
- Bind scope. Loopback is local to the namespace. A wildcard bind is reachable only if routing, host filtering and any cloud-level rules allow it, so the bind address is necessary but not sufficient. Check IPv4 and IPv6 as separate decisions.
- Published path. Look for service forwarding, daemon-specific redirects, an external proxy, and the effective firewall policy. This is the step people skip, and it is the one that turns a harmless-looking backend port into a reachable administrative path.
The same question reads differently from outside the host. A port with no host firewall rule can still be closed by a cloud security group, and a port with a permissive host rule may be unreachable because nothing routes to it. Look at both ends before writing the inventory conclusion.
Where the published path differs from the socket list
Access Server's own documentation covers the case that causes most confusion: when several TCP daemons run, the front-facing port forwards to daemon-specific ports, and the visible layout stops matching the socket list. The web interface filtering tutorial describes those rules and why a filter written only for the obvious port can miss the redirected path entirely.
Cluster control is the second place where version matters. On 3.0 and newer it shares 943; older cluster configurations used 945. Opening or blocking one of them without checking the version produces an inventory that looks tidy and is wrong.
So the externally visible surface is the union of three things: listening sockets, forwarding rules that republish them, and the network controls in front of the host. Any inventory that records only the first is incomplete, and any change that considers only the first will either leave a path open or cut off a service.
Verify after any change
Change listener settings through the supported configuration owner and keep a recovery console open while you do it. Losing administrative access to a web UI on a remote host is not recoverable through the VPN you just disabled.
Then validate the four things a deployment usually needs: a VPN client connects, the client portal loads, administrative access works, and cluster communication still functions if you run more than one node. A VPN-only test passes comfortably while the portal is broken.
Finish by writing down the permitted path for each service: which socket, which bind, which forwarding rule, which network control. That document is the useful security output. A minimal socket count is not, and neither is a bulk reset that closes listeners nobody has finished identifying.