Separate the client, Tunnel, and Workers

Three Cloudflare products show up around this lab, and people casually call each of them “the VPN”. They do different jobs. Mixing them up leads to designs that cannot work.

The Cloudflare One Client, formerly called WARP, runs on user devices. It creates the device-side path into Cloudflare. It registers the device with your organization, applies your enrollment rules, and forwards the device’s matching traffic to Cloudflare’s edge. This is the piece your users install.

Cloudflare Tunnel runs near your private resources. The cloudflared daemon creates the outbound path from Cloudflare into that network. It is the resource-side half of the connection, the counterpart to the client.

Cloudflare Workers runs request-handling code at the edge. Workers respond to requests, which makes them great for APIs, sites, and glue logic. But a Worker cannot accept arbitrary inbound TCP connections, and it is not a VPN endpoint. Its TCP socket API opens outbound connections from your code. Nothing in the platform lets a Worker sit there listening for VPN clients.

Here is the one-line version of each:

Cloudflare One Client   device side      "my laptop's traffic enters Cloudflare"
Cloudflare Tunnel       resource side    "Cloudflare can reach into my private network"
Workers                 edge compute     "my code runs on requests", not a VPN component

Why do I insist on this? Because “can I run a WireGuard server on Workers?” comes up all the time, and the answer is no by design. WireGuard needs a listening UDP port and raw packet handling. A Worker has neither. Knowing each product’s shape saves you from architectures that fail at the whiteboard stage.

For this course lab we need the client and Tunnel. We do not need a Worker at all.

The role split also tells you where to look when things break. Device-side problems show up in the client. Ask it directly:

warp-cli status
# Status update: Connected

If that says Disconnected or names the wrong team, the problem is on the laptop, and nothing you do on the connector will help.

Resource-side problems show up in the connector. Run systemctl status cloudflared on the machine that runs it, and check the Tunnel health indicator in the dashboard. A tunnel marked Down means cloudflared lost its outbound connections, and the laptop side is irrelevant until that is fixed.

When a private connection fails, check each half separately. Client first, then connector. That beats staring at the whole system at once and guessing.