> Then go into Cloudflare DNS settings and map the domain homeassistant.mydomain.com to the tunnel:
> CNAME homeassistant.mydomain.com a2f17e27-cd4d-4fcd-b02a-63839f57a96f.cfargotunnel.com
> Now all traffic going to this domain will go through the cloudflared tunnel, which is configured to route homeassistant.mydomain.com to 192.168.1.3. No Warp client needed, Argo tunnel does everything for us.
It boggles my mind that Cloudflare ever considered this acceptable for production, let alone that this is still how tunnels work. The whole configuration scheme feels like something that someone might have kludged up as a technology demo and launched in a staging environment. But the fact that a very security sensitive production system where a “DNS” record that looks like a CNAME to a magic hostname causes traffic to get proxied and sent to a “Zero Trust” private network is just … unreal. It’s almost impossible to tell WTF is going on or what policies apply to what. Does Cloudflare’s proxy really try to fetch an upstream resource, notice that the configured domain name ends with “cfargotunnel.com” and invoke some special handling? What happens if, say, someone else adds that same CNAME to their own network? What if some route goes to foo.bar.com and foo.bar.com’s nameserver reports a CNAME to cfargotunnel.com?
I’ve been using this product for several years, and the documentation and configuration pages have slowly evolved from abysmal to very slightly better. At least now it’s sort of clear how tunnels interact with strict TLS.
>What happens if, say, someone else adds that same CNAME to their own network?
Cloudflare network carries identity with traffic. If someone else adds the CNAME, they need an identity in the Zero Trust account that controls the tunnel. If you use the browser, Cloudflare IdP MITM the request and requires login to Cloudflare first. If you use Cloudflare Warp, then identity you use to login to Warp is injected.
>CNAME to a magic hostname causes traffic to get proxied and sent to a “Zero Trust” private network
That's also commonly called a load balancer.
From the Cloudflare UI, it works like:
- URL Normalization
- Redirect Rules
- URL Rewrites
- Page Rules
- Configuration Rules
- Origin Rules
- IP Access Rules
- DDoS protection
- Web Application Firewall
- Bots
- Rate Limiting
- Access
- Bulk Redirects
- Modify Request Header
- Cache Rules
- Snippets
- Cloud Connector
- Workers
- Custom Error Rules
- Modify Response Header
- Compression Rules
The "Access" step is key. Cloudflare acts like an authenticating reverse proxy. Once the request is authenticated, it continues processing and can route to the private backend over the Cloudflare tunnel.
Of course, you can make your app public. This is no different security wise than me adding a CNAME my-special-google.my-tld.com to google.com. Whether is works or not depends on the recipient server setup
This is all true.
However, home users live in IPv4 NAT world and look for solutions:
> Expose private services to the public, on public hostnames, no matter where they are running. You could even put your router running at 192.168.1.1 on the internet, accessible to everyone, no Warp client required
Trusting Cloudflare mitm 100% is a means to their goal.
The cname is just a normal domain. That DNS entry is a real entry. The CNAME is real. You can go directly to that address too. If someone else knows the cname destination they could go to it or cname their own domain to it literally like any other domain.
The only specially handling is cloud flare has a mapping from subdomain to your private network via it's agent and that's it.
I don't get what's the wrong or complicated about this.