Publishing a private app through a Cloudflare Tunnel

Four prerequisites. Missing any one of them causes a failure much later that looks unrelated.

What you are building

The connector on your Debian server opens outbound connections to Cloudflare's edge. Visitors reach a hostname on your domain, Cloudflare checks their identity against your Access policy, and only then forwards the request down the existing tunnel to your local port. Your firewall never opens an inbound port, and the server's IP is never published.

Dashboard-managed, so configuration lives in Cloudflare rather than a local YAML file.

1. Choose connector type Cloudflared and select Next.
2. Give the tunnel a name that identifies the machine, not the app — one tunnel commonly serves several hostnames. debian-home is a better name than grafana.
3. Select Save tunnel.

The next screen shows install commands containing a long tunnel token. Leave this page open; you need it in the next step.

Remotely-managed vs locally-managed

Creating the tunnel in the dashboard makes it remotely-managed: hostnames and routes are edited in the UI, and the server holds only the token. The alternative, cloudflared tunnel create on the server, is locally-managed and reads a config.yml on disk. The two modes do not mix — a remotely-managed tunnel ignores local ingress rules entirely, which is a common source of "my config changes do nothing".

Use the apt repository rather than the one-off .deb so the connector receives updates.

Add Cloudflare's repository

# keyring directory (already present on most systems)
sudo mkdir -p --mode=0755 /usr/share/keyrings

# repository signing key
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg \
  | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null

# add the repo ("any main" is correct for all Debian releases)
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' \
  | sudo tee /etc/apt/sources.list.d/cloudflared.list

sudo apt-get update && sudo apt-get install -y cloudflared

Confirm the binary is present and reports a recent version:

cloudflared --version

Install the service with your token

Copy the command from the dashboard, or substitute the token yourself:

sudo cloudflared service install <YOUR_TUNNEL_TOKEN>

This writes a systemd unit, enables it at boot, and starts it. Verify:

systemctl status cloudflared
journalctl -u cloudflared -n 40 --no-pager

Healthy logs contain Registered tunnel connection lines — usually four, to two Cloudflare data centres. Back in the dashboard the tunnel status flips to Healthy within a few seconds. Do not continue until it does.

A different shape of connectivity. Replaces steps 01, 02 and 06 — not an addition to them.

Cloudflare Mesh is the current name for WARP Connector; existing deployments keep working unchanged. Instead of publishing a hostname, every participant — Linux servers, laptops, phones — receives a private Mesh IP from 100.96.0.0/12 and can reach the others directly over TCP, UDP or ICMP.

Which one fits

Prerequisites

• Zero Trust subscription — the Free plan is eligible.
• Debian 12 or newer (also RHEL 9+, Ubuntu 22.04 LTS+), amd64 or arm64. Note this is stricter than cloudflared, which runs happily on Debian 11.
• 75 MB disk, 35 MB memory. An MTU of 1381 is recommended on the node's network.
• The device profile must use MASQUE, not WireGuard — see the caveat at the end.

Create the node

1. Name the node after the machine, e.g. db-server.
2. Select Create node.
3. The wizard shows a connector token. Capture it now — it is single-use, and you'll need the node detail page to retrieve it if you navigate away.

Enable IP forwarding on Debian

Required before installing, so the node can route subnets rather than only answer for itself:

printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\nnet.ipv6.conf.all.accept_ra = 2\n' \
  | sudo tee /etc/sysctl.d/99-zzz-cloudflare-warp-connector.conf
sudo sysctl --system

Install the Cloudflare One Client

A different package and repository from cloudflared — this is cloudflare-warp:

curl -fsSL https://pkg.cloudflareclient.com/pubkey.gpg \
  | sudo gpg --yes --dearmor -o /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(. /etc/os-release && echo $VERSION_CODENAME) main" \
  | sudo tee /etc/apt/sources.list.d/cloudflare-client.list

sudo apt-get update && sudo apt-get install -y cloudflare-warp

Join the mesh, headless

sudo warp-cli --accept-tos connector new <CONNECTOR_TOKEN>
sudo warp-cli --accept-tos connect
warp-cli --accept-tos status

The node appears in Networking › Mesh with its assigned Mesh IP. No interactive login happens — the token is what authenticates the machine.

Advertise the subnets behind it

A node can publish CIDR routes, making an entire backend subnet reachable by Mesh IP from any enrolled participant. Add them on the node's detail page. Client devices — laptops, phones — can join the mesh but cannot advertise routes; only nodes can.

Enrol the devices that will connect

Install the Cloudflare One Client on each laptop or phone, choose Zero Trust security, enter your team name, and authenticate with your identity provider. Then check the device profile under Settings › WARP Client › Profile settings:

• Protocol set to MASQUE.
• Split Tunnel in Include mode, with 100.96.0.0/12 routed through Cloudflare. Include mode matters — it keeps the rest of the device's connectivity untouched.

Verify

nc -vz <MESH-IP> 22          # port open through the mesh
ping <MESH-IP>                # ICMP works too, unlike a tunnel

Do this before creating the application, so the provider is selectable when you need it.

Option A — One-time PIN

Enabled by default and requires no configuration. Cloudflare emails a six-digit code to the address the visitor enters, and the policy decides whether that address is allowed. For a single-user private app this is genuinely sufficient — choose it unless you have a reason not to.

Option B — Google

Smoother day to day, but requires registering an OAuth client first.

1. In Google Cloud Console › APIs & Services › Credentials, create an OAuth client ID of type Web application.
2. Set the authorised redirect URI to exactly:

   https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback

3. Copy the Client ID and Client secret into the Cloudflare Google login method.
4. Select Save, then Test. Fix it here — a provider that fails its own test will fail behind an application too, but with a far more confusing error.

Create this before the hostname exists. Order matters, and this is why.

Application configuration

Identity providers

Untick Accept all available identity providers and select only the one you configured. Leaving it ticked means every enabled method is offered, including One-time PIN — which is fine if intended, and a surprise if not.

With exactly one provider selected, enable Automatically redirect to identity to skip the chooser screen and send visitors straight to the login.

An application without an attached policy protects nothing. This is the step most often left half-finished.

On the policies step choose Add a policy › Create new policy.

Action — the field that matters most

Rules

• Include — match any one of these and the policy applies. Put your identity here: selector Emails, value your address.
• Require — additional conditions that must all hold, e.g. Country or a valid device posture. Optional.
• Exclude — carve-outs that override an Include match.

A minimal single-user policy:

For a team, prefer Emails ending in with your domain, or create a reusable Access group under Access › Groups and include the group instead — then one edit updates every application.

This publishes the app. With steps 04–05 done, it comes up already protected.

Save. Cloudflare creates the proxied CNAME to <tunnel-id>.cfargotunnel.com automatically — you do not add a DNS record by hand.

Additional application settings

• No TLS Verify — required when the origin is HTTPS with a self-signed certificate, which is typical for Proxmox, Unifi, and similar appliances.
• Origin Server Name / HTTP Host Header — set when the app does name-based virtual hosting and returns the wrong site or a redirect loop.
• Connect timeout — raise for slow-starting applications.

Most verification methods quietly test the wrong thing. This one doesn't.

The test that actually works

Use a device outside the WARP tunnel — a phone on mobile data with WARP off is easiest — and open the hostname.

• Login screen appears → Access is enforcing. Sign in; the app should load.
• App loads immediately → not protected. Go to step 08's checklist.

From a shell, on a machine without WARP

curl -sI https://grafana.example.com | head -1

To see whether a 200 came from device identity, inspect the cookie Cloudflare issued:

curl -sI https://grafana.example.com | grep -i set-cookie

A CF_Authorization JWT whose payload contains "warp_as_auth": true means Access did run and authenticated you as a known device — the app is protected, and you simply can't observe that from this machine.

The tunnel protects one path in. These close the others.

Stop the app listening on the network

A service bound to 0.0.0.0 is still reachable from your LAN, and from the internet if a router forwards to it — neither path touches Access. Bind to loopback instead:

# check what is exposed
ss -tlnp

Anything showing 0.0.0.0:<port> that only needs to serve the tunnel should be rebound to 127.0.0.1 in the app's own configuration. Where that isn't possible, block the port:

sudo ufw allow from 127.0.0.1 to any port 8000
sudo ufw deny 8000

Remove any port-forward on the router for these services — the tunnel replaces it entirely.

Worth doing next

• Default-deny. Add a final policy with action Block and include Everyone, placed lowest in precedence, so a mistake in an Allow rule fails closed.
• Service tokens for API clients — Access › Service Auth, then a Service Auth policy including that token. Keeps automation working without weakening the human policy.
• Verify the JWT at the origin for anything sensitive, so a request that somehow bypasses the edge is still rejected by the app.
• Watch the logs — Logs › Access records every allow and deny with identity and policy.

Symptoms in the order you're likely to meet them.

Useful commands

systemctl status cloudflared          # service state
journalctl -u cloudflared -f          # live logs
sudo systemctl restart cloudflared    # after config changes
ss -tlnp                              # what is listening locally
cloudflared --version                 # connector version