Every publicly reachable server starts with the same liability: open inbound ports. A traditional setup means punching holes in a firewall, pointing DNS at a real IP address, and hoping nothing on that exposed surface gets found by a scanner before you patch it. A Cloudflare Tunnel removes that liability entirely by flipping the connection direction: the server reaches out to Cloudflare, not the other way around.
Why Use a Tunnel Instead of Port Forwarding
-
No inbound firewall rules at all — ports 80/443 never need to be open on the VM
-
The VM’s real IP address is never exposed publicly, only Cloudflare’s edge is
-
TLS termination, DDoS protection, and caching are handled by Cloudflare automatically
-
Works even behind NAT or CGNAT, where the VM has no fixed public IP at all
How It Works
A lightweight daemon called cloudflared runs on the VM and opens several persistent outbound connections to Cloudflare’s nearest edge locations. Public traffic hitting your domain never touches the VM directly — it arrives at Cloudflare, gets matched against the tunnel’s routing rules, and is relayed back down one of those existing outbound connections to whatever local service you’ve pointed it at (in our case, the reverse proxy sitting in front of WordPress).
Step-by-Step Setup
-
Install
cloudflaredon the VM (available as a .deb/.rpm package or a static binary from Cloudflare) -
Authenticate it against your Cloudflare account:
cloudflared tunnel login -
Create the tunnel:
cloudflared tunnel create my-vm-tunnel -
Write a config file mapping your hostname to the local service, for example routing
example.comtohttp://localhost:80 -
Point DNS at the tunnel instead of an A record:
cloudflared tunnel route dns my-vm-tunnel example.com -
Run it as a persistent service so it survives reboots:
cloudflared service install
Traditional Exposure vs. a Tunnel
| Traditional Port Forwarding | Cloudflare Tunnel |
|---|---|
| VM’s IP is public and scannable | VM’s IP is never exposed |
| Requires open inbound ports 80/443 | Zero inbound ports required |
| Firewall misconfiguration is a real risk | No inbound firewall surface to misconfigure |
| DDoS protection is your own problem | Absorbed by Cloudflare’s edge |
The trade-off is a dependency on Cloudflare’s availability and a bit of trust placed in a third party sitting in front of your traffic. For a small VM serving a low-risk public site, that trade-off is easily worth it: the entire inbound attack surface disappears, and the only thing left reachable from the internet is Cloudflare itself.
