OpenVPN and HTTPS on port 443: who owns the listener?

Two services can both answer on port 443 without ever competing, because a listener is keyed on transport, address and port together rather than on the number alone. Put a web server and OpenVPN on one box and the only question worth answering first is which socket each process asks the kernel for. Write that list down before you edit a configuration, and most address-in-use errors explain themselves. Everything after the list is a choice between a UDP listener, a shared TCP socket, or a front end that routes by protocol.

Start with the socket each process asks for

A bind succeeds or fails on that triple, so two daemons collide only when all three parts coincide. That is why a website on TCP 443 coexists with an OpenVPN listener on UDP 443 indefinitely, and why moving one of them to a second local address on the same host also ends the argument. Read the live listeners instead of the files that were supposed to create them, because a stale include or a forgotten unit file outlives the edit you remember making.

Run ss -lntup as root and read every row that mentions 443, IPv6 entries included. A wildcard v6 listener usually accepts v4 traffic too, which is how a listener you forgot about keeps the port occupied after you change the file you believed was responsible. If a process name surprises you, narrow the output with ss -lntup 'sport = :443' before touching anything.

Switch the tunnel to UDP when the network allows it

A UDP listener sidesteps the collision entirely and is usually the shortest repair, since no socket is shared and no extra product joins the path. It is not free. Some client networks drop UDP 443 without sending a reset, so the tunnel stops establishing instead of failing to bind, and the user reports the VPN as down with no error to read. A UDP listener also outlives a web tier restart, which counts on a box whose site is redeployed often. Test from the network where the users sit, because a shell on the server only proves the server can reach itself.

Change the transport in the server configuration and in the client profile together. A profile still asking for TCP will loop through reconnects against a UDP-only listener, and that looks like a network fault until you compare the two files.

Let the VPN process own TCP 443 and forward the rest

Community OpenVPN in TCP server mode reads the first bytes of an incoming connection and forwards anything that is not its own protocol to an HTTPS backend, which is what the port-share directive is for. The backend is an ordinary web server with TLS enabled, named by host and port in that directive rather than by a URL.

port-share 10.0.0.5 8080

In a box where the site holds a second private address, that line sends non-VPN traffic to 10.0.0.5:8080, so the HTTPS virtual host must be bound there and the firewall must allow the local hop. The web server has to terminate TLS itself, because the bytes arriving are the browser's original handshake and nothing in between has decrypted them. Aim the directive at a plain HTTP listener and the browser gets an invalid-method error, which reads like a broken site rather than a misplaced backend. The directive exists in TCP server mode only, and a UDP listener has no stream to inspect.

Because the VPN process accepts every connection, the web application sees the forwarded request arriving from one of the host's own addresses instead of from the visitor. Anything that needs the real client address depends on PROXY protocol support in the backend or on a front end that adds it. Moving the backend to another local address does not bring the visitor's address back; it only changes which of the host's addresses the site records. Put that limitation in the deployment notes before an analytics report raises the question.

A reverse proxy is the wrong tool; a layer-four router is not

An HTTP reverse proxy terminates TLS so it can read requests, which means it cannot pass an OpenVPN stream through untouched. A layer-four router that forwards by SNI or by first-packet inspection can front both, provided it does not end the session the VPN depends on. The two devices look alike in a diagram and behave nothing alike at the socket.

Commercial Access Server ships its own port-sharing settings, and those do not map one-to-one onto the community directive. Identify the product and version before adapting a guide written for the other one. A copied setting that is silently ignored is worse than no setting, because the listener list still looks plausible afterwards.

Test the website and the tunnel as two separate paths

Load the site and connect the tunnel, then read the listener list again to see which process owns 443 now. A page that loads proves nothing about the VPN, and a tunnel that connects proves nothing about the site, even though both use the same number. The three commands below check the shared socket, the web path and the VPN service in that order.

ss -lntup 'sport = :443'
curl -sI https://vpn.example.com/ | head -n 1
journalctl -u openvpn-server@server -n 20

Compare the client address in the backend access log with the one in the VPN log for the same moment. If the site records every visitor as the host itself, forwarding works and the address handling does not. If both logs stay silent, the front end never handed the connection over. Either way the listener list settles who accepts the socket, and that is the fact to confirm before you change another file.

Leave that listener map beside the configuration so the next person who touches 443 knows which process accepts and where the other protocol went. Confirm ownership after the change rather than trusting what the edit was meant to do.