Run a VPN and a Website on One Host Without Collisions

Share one host between a public site and a VPN and you inherit two questions, not one: what listens where, and who authenticates whom. Answer both before touching a configuration file, because the defaults are wrong in ways that appear only under load. A page that loads over HTTPS proves the web listener answers and nothing about the peer listener. What follows is a decision order that keeps the two from eating each other.

Decide what listens on which address and transport

Write a table with three columns, address, transport and port, and one row per service, including the administrative interface. TCP 443 for the site and UDP 443 for the VPN are not a conflict even though the numbers match, because the transport differs. Two services on the same address, transport and port need an arrangement the implementation documents, not one you invent during an outage. That table is also the artefact that makes the next change reviewable.

Separate addresses or a second port make ownership visible in a packet capture, which is worth more than elegance. Some VPN implementations support sharing a port with a web server, but the mechanism is specific: the daemon inspects the first bytes and forwards traffic that is not its own protocol. A generic HTTP reverse proxy does not do that, and rewriting headers will not make it understand an encrypted tunnel handshake. Read the protocol's deployment notes, such as the OpenVPN listener documentation, and follow the arrangement it describes.

Decide which identity belongs to which service

A browser certificate and a VPN peer credential are different objects with different trust models. The web certificate is validated by a public authority and names a hostname, while the peer credential authenticates a device or a user to the concentrator and may be self-signed or issued internally. Reusing one as the other works in narrow cases and is rarely worth the coupling. Disabling verification so a shared certificate fits is not a separation plan; it removes the check that gave the credential meaning.

Keep the two stores independent and write down which authority issues each. When one is rotated, the other should not need to change, and if it does, the coupling is the thing to fix.

Decide where administration lives

The administrative interface of the VPN belongs on a management path, never on the public listener, even when the host already serves the internet. A web server on 443 does not imply that the peer console should be reachable from anywhere, and the console is usually the higher-value target. Bind it to a loopback or management address, restrict it by source, and keep a recovery path that does not depend on the tunnel being up. The recovery path matters because the common failure is locking yourself out while fixing the lockout.

Write narrow firewall rules, one per listener, naming the interface or service account where the platform supports it. Broad rules that open the host because the site needs 443 are how management interfaces end up in scanner indexes.

Review those rules against the listener table whenever a service is added. The review is cheap and it catches the rule someone added at two in the morning.

Decide what to do when the two contend

Sharing a host means sharing CPU, memory, file descriptors and bandwidth, and the contended resource is not always the obvious one. A busy site can fill the connection table, exhaust worker slots, or push the disk queue hard enough that VPN logging stalls. Watch per-service use rather than host totals, because an average hides which process is starving. If one workload repeatedly disrupts the other, isolate them instead of tuning around the symptom.

Isolation can be a container, a cgroup limit, a separate queue or a second host, and the right choice depends on which resource contends. A port change fixes nothing here, and a larger instance fixes nothing if the limit is one saturated queue. Decide with a measurement: name the resource, load it, then pick the smallest isolation that removes the contention.

Verify from outside, then again after a restart

Test from a device that is not on the host's own network: load the site, bring up the tunnel, and reach one resource that requires it. Then restart each service on its own and repeat the other test, because a restart is when a shared listener arrangement loses its ordering. If the VPN starts before the web server that owns the shared port, the sharing mechanism may never attach, and the symptom is a tunnel that worked yesterday. Make the dependency explicit in the unit ordering.

Then confirm the boundaries: the site answers on its port, the VPN answers on its own, and the management interface answers only from the management path. Record the result beside the listener table with the date. A host that passes all three checks after a reboot is a host you can hand to someone else without a briefing.