I finally understand Cloudflare Zero Trust tunnels

One thing that makes Cloudflare worse for home usage is it acts as a termination point for TLS, whereas Tailscale does not. If you use a Tailscale Funnel, you get the TLS certificate on your endpoint. With Cloudflare, they get a TLS certificate for you, and then strip and optionally re-add TLS as traffic passes through them.

I actually have no idea how private networks with WARP are here, but that's a pretty big privacy downgrade for tunneling from the Internet.

I also consider P2P with relay fallback to be highly desirable over always relaying traffic through a third party, too. Firstly, less middlemen. Secondly, it continues working even if the coordination service is unavailable.

I've experimented with Cloudflare tunnels before to sit in front of my Immich instance in my homelab. Only issue is the 100MB upload size for videos. But Immich added upload chunking support to their roadmap so its possible this will work very well in the future.

What's the actual win here? Avoiding relay latency in the rare cases Tailscale can't punch through NAT? If that's it, a $3 VPS running Headscale seems simpler. The complexity feels like you're optimizing for the 5% case while adding permanent vendor lock in. What am I missing?

> after frustration with Tailscale in environments where it couldn’t properly penetrate NAT/firewall and get a p2p connection, I decided to invest some time into learning something new: Cloudflare Zero Trust + Warp

...which doesn't even try to get a p2p connection. Instead you always get the thing you didn't want. If you're okay with that you could've just ignored how Tailscale connected those devices, that's kind of the point. You've also in the process converted your entire security model to Cloudflare's idea of "Zero Trust" which involves 100% trusting Cloudflare.

The rest of the blog post is fine, but the motivation is honestly baffling.

This seems like an excellent guide. I love these "how the pieces fit together" kind of guides.

Perhaps CF could license it and slap it in their docs!

Nice article. For easily exposing private services to the internet I’ve been using https://tuns.sh which lets you run ssh tunnels. It’s nice for a zero install solution.

Free Cloudflare account cannot be used to serve my Plex server. To me that's a no-go.

The specific term is: https://www.cloudflare.com/service-specific-terms-applicatio...

I'm using Netbird [0] for my home / private needs: - Synology NAS - All the laptops and desktops my family uses - All family mobile phones

Given i work in Tmux, its super convenient to take a laptop with me and just use it as a thin client to my Desktop wherever I am.

[0] https://netbird.io/

Thanks a lot. Both the post itself and the comments are very useful. I'd like to comment on the content of this post, but it'll take much time for me to wrap my head around.

In the mean time: the images in the article seem to be broken — produce 404 errors. Like this one: https://david.coffee/targets-config-screen.png

I stopped reading at "everything goes through the Cloudflare network, no direct p2p"

https://github.com/alecbcs/hyprspace has penetrated every NAT I've ever encountered. No megacorporation required.

But is this vendor-lockin, as in CloudFlare being the vendor here? Because at least with Tailscale there's no vendor lock-in.

Tailscale now has the awesome feature of peer relays and now there's no more excuses why you can't traverse that NAT and you can forget about all those DERP servers.

Oh man, someone has to talk about this!! Cory told me about CF's gold issues and it really does seem problematic to me, I'm glad ZT is finally being criticised.

I don't understand the use case here. Is this supposed to be for enterprise to control access to internal applications via network access policies?

what's the difference between this and a reverse SSH tunnel, for example making a local port on your laptop accessible to a public-facing internet server or even running on localhost on that same server... or using sshuttle to access your local network from a remote server .... it doesn't sound like "zero trust" if you're proxying everything through some third-party company that you know nothing about what they're doing with your actual data that you're sending across the wire...

I am anti cloudflare. All my homies are anti Cloudflare. If you are pro cloudflare you can not hang with us, sorry, you are pro destruction of the internet.

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