Understand Cloudflare private access

Cloudflare calls this a VPN replacement. The result is the same as before: a remote device reaches a private resource. But the architecture is different from the single VPN server we just built, and the difference is worth understanding before you build anything.

Our WireGuard server had a public address and listened for inbound UDP. The whole design depended on that open door. Cloudflare’s model turns it inside out: nothing on the private network listens for anything.

A connector called cloudflared runs on a machine inside the private network. It creates outbound connections to Cloudflare’s edge and keeps them alive, waiting for work. It only needs to reach the private resource on one side and the Internet on the other.

The Cloudflare One Client runs on the remote device. It sends matching traffic to Cloudflare. Cloudflare routes it through the connector to the private destination.

Here is the shape:

laptop (Cloudflare One Client)
   │  outbound connection to Cloudflare
   ▼
Cloudflare edge   ← identity and policy checks happen here
   ▲
   │  outbound connection from inside the private network
cloudflared connector ──▶ 10.0.1.100 (the private resource)

Notice that both arrows point outward. No public inbound port is required on the private network. The firewall stays closed to inbound traffic entirely. There is no UDP 51820 to expose and nothing for an Internet scanner to find.

Two properties follow from this shape. First, the attack surface changes. A listening VPN port is discoverable and probeable by anyone on the Internet. An outbound-only connector offers nothing to connect to. Second, every connection passes through Cloudflare’s edge, and that is where identity and policy get evaluated. Access decisions can consider who is asking, not just who holds a key.

The price is that Cloudflare now sits in the path of every connection. We look at that trade in a later lesson. For now, just notice it exists.

On the connector machine, health is easy to check:

systemctl status cloudflared
# ● cloudflared.service - cloudflared
#      Active: active (running)

active (running) means the daemon is up and holding its outbound connections. If it says failed or keeps restarting, run journalctl -u cloudflared -n 50 and read the last lines. The usual cause is an expired or mistyped token.

One misconception to drop right now: cloudflared does not “open a port” or “expose the server”. If you find yourself adding an inbound firewall rule for it, you have misread the model. It needs outbound connectivity and nothing else.