Create the Tunnel and private route

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 it with live outbound connections.

Placement is the decision that matters. Install cloudflared on a Linux, macOS, or Windows device 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.

Prove local reachability before involving Cloudflare at all:

# on the machine that will run cloudflared
ping -c 2 10.0.1.100
curl -I http://10.0.1.100
# HTTP/1.1 200 OK

Use the install command generated by the dashboard. 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)

Then define what this Tunnel carries. Add a narrow route such as 10.0.1.100/32 for 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, and promising an entire /8 to reach one machine is the network equivalent of handing out a master key.

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: 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.