[HN Gopher] I finally understand Cloudflare Zero Trust tunnels
___________________________________________________________________
I finally understand Cloudflare Zero Trust tunnels
Author : eustoria
Score : 79 points
Date : 2025-11-16 17:39 UTC (5 hours ago)
(HTM) web link (david.coffee)
(TXT) w3m dump (david.coffee)
| plantinthebok wrote:
| 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?
| throwaway678339 wrote:
| I don't think you are missing anything. They have a bunch of
| half baked features like this that aren't as robust as real
| security vendors and lock you in just like you said.
| josteink wrote:
| Maybe I'm misunderstanding something...
|
| But are you accusing someone of promoting vendor lock-in
| (cloudflare) while at the same time promoting vendor lock-in
| (tailscale)?
|
| If you're ok with vendor lock-in, shouldn't you in theory be ok
| with any vendor?
| bingo-bongo wrote:
| Headscale is the not-vendor-login version of Tailscale.
| fragmede wrote:
| No. Not all vendors are equal. We can treat ProtonMail
| differently then Gmail, for example. Looking at what's gone
| down with VMware, definitely don't get in bed with Broadcom.
| killingtime74 wrote:
| For many homelabbers, just being cheap and avoiding the $3 VPS,
| that's it
| comrh wrote:
| I dont even pay anything, my tiny homelab is completely
| covered by the free tier
| kohbo wrote:
| What provider still has decent free tier?
| antonkochubey wrote:
| Oracle. 4 vCPU, 24 GB RAM, 200 GB SSD. It's arm64 but
| nowadays that doesn't really matter.
| gear54rus wrote:
| Which region were you able to create this in? They seem
| to be out of capacity all the time in EU.
| k_bx wrote:
| $3 VPS running Headscale is not simpler since you won't be able
| to run both headscale and tailscale on your end user machines,
| I don't recommend it.
|
| The solution we've found is running a white IP container (or
| VPS) which looks like regular Wireguard outside, while inside
| it "forwards" to your existing tailscale network.
|
| I don't remember if we use https://github.com/gravitl/netmaker
| or https://github.com/juhovh/tailguard
|
| Also see: https://tailscale.com/blog/peer-relays-beta
| zrail wrote:
| Tailscale has what they call Peer Relays now to help solve this
| problem:
|
| https://tailscale.com/blog/peer-relays-beta
| hexbin010 wrote:
| 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!
| jchw wrote:
| 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.
| keehun wrote:
| TLS termination is neither required nor enabled by default,
| right?
| crimsonnoodle58 wrote:
| Correct. We run it without it and just use the DNS filtering
| aspect.
| philipwhiuk wrote:
| How does it do DNS filtering without TLS interception -
| takeover for DNS resolution?
| jchw wrote:
| For tunnels many of the features basically have to work this
| way, so I'd be surprised if you could avoid it. It's also
| impossible to avoid if you use normal Cloudflare "protected"
| DNS entries. You can use Cloudflare as just a DNS server but
| it's not the default, by default it will proxy everything
| through Cloudflare, since that's kind of the point. You can't
| cache HTTP requests you can't see.
| jpdb wrote:
| I generally prefer tailscale and trust them more than
| cloudflare to not rug-pull me on pricing, but the two features
| that push me towards cloudflared is the custom domains and
| client-less access. I could probably set it up with caddy and
| some plugins, but then I still need to expose the service and
| port forward.
| jchw wrote:
| I'm definitely not trying to dissuade anyone from using
| Cloudflare, just making sure people realize the potential
| privacy implications of doing so. It isn't always obvious,
| even though some of the features pretty much require it (at
| least to be handled entirely on Cloudflare's side. You could
| implement similar features that are split between the
| endpoint and the coordination server without requiring full
| TLS stripping. Maybe Tailscale will support some of those as
| features of the `serve` server?)
|
| > client-less access
|
| JFYI, Tailscale Funnels also work for this, though depending
| on your use case it may not be ideal. Ultimately, Cloudflare
| does handle this use case a bit better.
| yuvadam wrote:
| 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.
| qudat wrote:
| 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.
| yegle wrote:
| 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...
| mandelken wrote:
| My free account runs cloudflared tunnel just fine for jellyfin.
| Is it just plex?
|
| I use the tunnel because my girlfriend cant install tailscale
| on her work laptop, so this way she can still login to jellyfin
| while traveling.
| amluto wrote:
| > 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.
___________________________________________________________________
(page generated 2025-11-16 23:00 UTC)