Build a Cloudflare private network

Create the Tunnel and private route

Run the outbound connector beside a private resource and route one narrow IP or CIDR through it.

In the Cloudflare One onboarding flow, choose the device-to-network VPN replacement path and create a Tunnel. A Tunnel is a named connection slot in your organization. The cloudflared daemon fills that slot with live outbound connections.

Placement is the decision that matters most. Install cloudflared on a Linux, macOS, or Windows machine that can already reach the private resource. The connector is a bridge: Cloudflare hands it traffic, and it delivers that traffic over the local network. If the connector cannot reach the resource, nothing upstream can compensate.

So prove local reachability before involving Cloudflare at all. Run this on the machine that will host cloudflared:

ping -c 2 10.0.1.100
curl -I http://10.0.1.100
# HTTP/1.1 200 OK

If either command fails here, stop. Fix the local network first. Everything you build on top of a connector that cannot reach its target is wasted time.

Now install the connector. Use the install command the dashboard generates for you. It embeds a token that binds this daemon to your Tunnel:

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

The token is a credential. Treat it like a password: don’t paste it in chat, and don’t commit it to a repo.

Then define what this Tunnel carries. Add a narrow route such as 10.0.1.100/32 for your one lab host. The route tells Cloudflare: traffic for this prefix belongs to this Tunnel.

Choose a larger CIDR only when every address in it should be reachable through this connector. A route is a reachability promise. Promising an entire /8 to reach one machine is the network equivalent of handing out a master key to open one door.

Wait until the dashboard reports the connector as healthy before configuring the remote device. Healthy means cloudflared has established its outbound connections to Cloudflare’s edge. Debugging device enrollment against a connector that was never up wastes an evening, because every symptom looks identical from the laptop side.

The classic placement mistake is installing cloudflared on a machine in the wrong network segment: a different VLAN, or behind an internal firewall that blocks it from the resource. The symptom appears much later. The remote device enrolls fine, the Tunnel shows healthy, and connections to 10.0.1.100 time out anyway.

The ping test above, run from the connector’s own shell, is what splits that problem in half. If the connector can reach the resource and the laptop cannot, the problem is between the laptop and Cloudflare. If the connector cannot reach it either, Cloudflare is not involved at all.

Lesson completed