Why the Cloudflare proxy cannot carry OpenVPN on one name

One machine runs the website and the OpenVPN server, and the temptation is to point one hostname at it and let the orange cloud sort out the traffic. The proxy sorts out HTTP and HTTPS. It does not sort out an OpenVPN session, no matter which port that session uses. Two names, one direct and one proxied, cost nothing and remove the whole class of confusion.

Two names, two transports

Give the website a proxied record so its HTTP and HTTPS traffic passes through Cloudflare. Give the VPN a DNS-only record that resolves straight to the public VPN entry, and let the client use the UDP or TCP port it was configured for.

Both names can end up at the same origin machine. The difference is what happens between the client and that machine, and that difference is the point of the split.

Cloudflare's network-port reference lists which ports the ordinary web proxy accepts. That list is about HTTP and HTTPS on those ports, not about arbitrary protocols that happen to share a number.

The port is not the protocol

Moving OpenVPN to TCP 443 does not turn it into HTTPS. The proxy still expects an HTTP request at the start of the connection, and an OpenVPN client sends a binary control message instead. The connection fails in a way that looks like a network block because nothing useful reaches a log.

If the requirement really is to put a Cloudflare product in the VPN data path, evaluate one that documents support for the protocol you need. Do not assume the orange cloud is a general TCP or UDP tunnel, because it is a reverse proxy for web traffic with a specific job.

A DNS-only record is the boring answer that works, and it is the one to reach for first.

One machine still needs two listeners

Separate names do not let two processes bind the same address, port and transport at the same time. If the web server already holds TCP 443 on all addresses, an OpenVPN instance cannot also take it without a deliberate arrangement.

Bind the VPN listener to a different port, or to a different address, or put a documented multiplexer in front and accept the operational cost that comes with it. Each of those choices should be visible in the firewall rules, because a listener nobody documented is the one that gets missed during an incident. Write the chosen binding into the same runbook that describes the tunnel. Then the next person does not rediscover it at two in the morning.

Certificates follow the connection they protect

The browser's TLS connection to Cloudflare and Cloudflare's connection to your origin are two separate relationships with two separate certificates. The browser sees an edge certificate. The origin presents its own certificate to Cloudflare, and a Cloudflare Origin CA certificate is intended for exactly that second relationship.

That origin certificate is trusted by Cloudflare under Full (strict) mode and is not a generally trusted browser certificate. If someone visits the DNS-only hostname directly and gets a warning, that is the expected consequence of a changed trust path rather than evidence that encryption stopped.

A directly visited website therefore needs a certificate chain its browsers trust. That can coexist with a proxied site whose origin is not meant to be visited at all.

OpenVPN carries its own server identity and client authentication, with its own certificate authority and its own control-channel protection. A padlock on the website provisions none of that, and the two provisioning processes should stay separate.

Exposure follows the name

A DNS-only VPN record publishes the address it points to. If that address is also the web origin, the origin is not hidden, and describing it as hidden because the other name is proxied is a mistake that survives until someone scans for it.

Decide which web requests may reach the origin directly and enforce that at the origin, then permit the VPN listener on its own terms. Management pages, profile downloads and the data listener can have three different exposure requirements even when one package provides all three.

Keep generated links on the public web name and HTTPS scheme, and keep client profiles on the VPN name with the real protocol and port. Neither service should depend on flipping the other's proxy setting during normal operation.

Order of work: proxied name for the site, DNS-only name for the VPN, distinct listeners, certificate per relationship, then one test that proves each name reaches only the service it should.