I finally understand Cloudflare Zero Trust tunnels | David Mohl
A mental model for Cloudflare Zero Trust that finally makes tunnels, routes, and targets click—plus how to expose home services publicly with granular access control while bypassing NAT entirely.
Read Original Summary used for search
TLDR
• Tunnels are literal exits for traffic (deployed via cloudflared), Routes tell Warp where to send requests, Targets define infrastructure to protect with policies—three distinct concepts that work together
• You can route virtual IPs that don't exist (like 10.128.1.1) through tunnels to build fully custom private networks, independent of your actual network topology
• Layer public DNS + Argo tunnels + access policies to expose home services (like 192.168.1.3) on public domains with login protection, no Warp client required for access
• Use Gateway selector (not Warp selector) in policies to skip login screens for enrolled clients—Gateway only matches your Zero Trust org, Warp matches anyone with 1.1.1.1
• Everything routes through Cloudflare's edge (adding latency) but completely eliminates NAT/firewall traversal issues that plague Tailscale
In Detail
The author spent significant time wrestling with Cloudflare Zero Trust concepts before finally understanding how tunnels, routes, and targets work together. The core insight: tunnels (deployed via cloudflared) are exits for traffic in your target network, routes tell the Warp client where to direct traffic, and targets define infrastructure to protect with access policies. These are three separate layers that interact but serve distinct purposes.
The power comes from flexibility: you can expose private services publicly using DNS records pointing to Argo tunnels (no Warp needed), create private routes only accessible when Warp is connected, or build entirely virtual networks using made-up IPs like 10.128.1.1 that route through tunnels to real infrastructure. Access policies layer on top with Include/Require logic and actions (Allow/Deny/Bypass/Service Auth) to control who can access what. A key detail: use the Gateway selector in policies to identify enrolled Zero Trust clients, not the Warp selector which matches anyone running the consumer 1.1.1.1 app.
The tradeoff versus Tailscale: all traffic routes through Cloudflare's edge network (adding latency) rather than establishing peer-to-peer connections, but this completely eliminates NAT traversal issues. The author demonstrates building a complete setup where homeassistant at 192.168.1.3 is accessible via public domain with GitHub authentication, or directly via IP when Warp is connected, with policies that skip login screens for enrolled clients. The guide provides the mental framework most documentation lacks for actually using Zero Trust effectively.