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.
Is it technically possible to have something like Tailscale funnel but with something like Cloudflare Access authentication (at least for some options)?
I ended up building something in this space recently (TunnelBuddy – https://www.tunnelbuddy.net I’m the author) that lets you use a friend’s machine as an exit node over WebRTC.
One of the design decisions I made was P2P or nothing: there’s a small signalling service, but no TURN/relay servers. If the peers can’t establish a direct connection, the tunnel just doesn’t come up.
The trade-off is fewer successful connections in weird NAT setups, but in return you know your traffic never transits a third-party relay – it goes straight from your client to your friend’s endpoint.
My traffic will transit third parties all the time, since it's going over the Internet. What's the problem with relays, if the traffic is end-to-end encrypted?
- With a TURN/relay, you’re introducing a single, purpose-built box that:
- sees all the tunnel metadata for many users (IP pairs, timing, volume),
- is easy to log at or subpoena/compel,
- and becomes a natural central chokepoint if someone wants to block the system.
- Without that relay, your traffic still crosses random ISPs/routers, but:
- those hops are *generic Internet infrastructure*, not “the TunnelBuddy relay”,
- there’s no extra entity whose whole job is to see everyone’s flows.
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.
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.
Yeah, because the auth can't be done on Tailscale's end if they don't terminate the TLS connection. However, it is still possible to use an authentication proxy in this situation. Many homelab and small to medium size company setups use OAuth2 Proxy, often with Dex. If you wanted to get fancier, you could use Tailscale for identity when behind the firewall and OAuth2 Proxy when outside the firewall.
This may seem like a lot of effort and it is definitely not nothing, but Cloudflare Tunnels also has a decent number of moving parts and frankly their authentication gateway leaves a bit to be desired for home users.
That's a fair personal decision, but if I would have to put money on it I'd say the chances of new company that raised 160 million of VC funding this year alone vs. established profitable company with a track record of offering free services for many years already I'd put my money on the latter.
> I could probably set it up with caddy and some plugins, but then I still need to expose the service and port forward.
Not so! I have custom domains on my Tailnet with Caddy. You just need to set up Caddy to perform the ACME DNS challenge to get certs for your domain (ironically I use Cloudflare for DNS because they make it very easy to set this up with just an API key). No plugins or open ports needed.
2. Performance and reliability. 100+ PoPs in all major clouds running their data plane routers if they host (still E2EE), or run routers anywhere if you self-host. Dynamic routing to find best paths across the routers.
I don't see any indication that NetFoundry zrok supports end-to-end encryption from the client to the web server. The default configuration definitely terminates SSL on NetFoundry's server, and I don't see any documentation for how to avoid that. There's a TCP tunneling mode, but servers that use this mode can only be accessed by clients that are themselves also connected to the NetFoundry VPN service, not by clients on the public web. What's needed is a TLS tunneling mode that figures out the correct target via SNI, and zrok doesn't seem to provide that.
You are correct, zrok doesn't support mutual TLS. zrok is the free offering that NetFoundry supports so it's easy to see why you looked there for information.
> It'll still terminate TLS at the servers, though. It's not mTLS all the way
> through to the endpoint.
That was the entire point, though. If NetFoundry Frontdoor can see the traffic (because it gets terminated on their servers, mTLS or not), then it's not end-to-end encrypted as the parent commenter claimed.
Tunneling p2p with relay fallback is essentially what connet [1] aspires to be. There are a lot of privacy/security benefits exposing endpoints only to participating peers. You can either run it yourself or use hosted version [2].
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.
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?
Exactly, just today I set up a cloudflare tunnel to a docker compose service running on my home server. I didn’t want to expose the server directly to the internet, and I want to share this service on a certain domain with broader family.
I have a server at home that works well. I don’t reaaaally want to pay an extra $30-$40/yr and have an extra thing to manage when the CF tunnel works fine for free. I like Tailscale more, but I want to share this with family who won’t install TS and also want to use a specific domain.
What worked for me was handing them a credit card and transitioning myself out of the free tier. (I'd use the free credits they offer prior to doing this - they give you something like $300 immediately on signup.)
The always-free infra remains free, you just have the chance of incurring a bill if you make selections that aren't free or exceed block storage/egress (200GB/10TB) limits of the always-free tier. Leaving the free/trial tier gives you access to a much larger pool of instances. I never successfully deployed an A1 instance prior to becoming a "paying" customer - now I've done it hundreds of times without ever having an issue.
I've been running a small k0s cluster and a standalone webserver for months while incurring about $2.50 - $3 in spending each month, primarily from being slow to remove instance snapshots sitting in block storage.
Even things that are oddly expensive on AWS - like NAT - are free on Oracle. There are zero gotchas.
I hit the same roadblock as the above user and it never occurred to me to just cross the barrier with cash and then scale back to free. Thanks for this.
$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 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.
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.
> 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.
The difference is that Cloudflare has their own high quality network and PoPs everywhere, so the quality is generally even better than P2P.
This is my experience, we are a fully remote world-wide company and we recently migrated away from Tailscale to Cloudflare and it has been much better.
Is the connection through Cloudflare still encrypted between the two peers, as it would be going through a Tailscale relay? If not, that's definitely a downgrade using the Cloudflare approach. But if not, I'm not sure the trust model is significantly different with maybe the added benefit of the fact that Cloudflare's relay performance is likely better given that relaying traffic is kind of their main thing rather than a very secondary function like it is for Tailscale.
On the other hand, my experience with Tailscale is that they're very, very good at NAT hole punching and I'd rather have a direct connection where possible from a latency standpoint.
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.
> it’s against the terms of service to use it for video
It for any large files. They want to limit bandwidth usage but not blanket limit everyone. One user using Plex of Jellyfin probably doesn't move the needle.
Yes and that's what people are criticizing - it's just an arbitrary and thus very bad rule. Completely unrelated to CloudFlare, I streamed a single TV series from a friend's plex account 1-2y ago, that's less traffic than some of my friends use in 2 weeks.
I'm not saying they can't have that rule, it's their infra - I'm just saying that "a boatload of bandwidth" can be anything, depending on who you ask.
Why would anyone expect anyone else to serve video for them for free? Is there any CDN that serves video for you for free???
I'm not even talking about the copyright implications here, just the bandwidth costs. A single movie download would cost more than many hundreds of typical simple HTTP website sessions.
> Why would anyone expect anyone else to serve video for them for free?
I would expect that a freemium service selling encrypted "zero trust" networking should have no idea what traffic is being pushed through my network making enforcement impossible.
Nobody's asking for a free lunch, but the reasonable thing to do would be to simply bandwidth limit freemium accounts across the board, not make exceptions for certain kinds of traffic in what should be a secure network.
Cloudflare does say "video and other large files" so in the end it is about volume, not data type. They probably just want to have the arbitrary decision on specific cases without defining a uniform blanket limit.
Not sure if you are a representative from Cloudflare. But regardless, Cloudflare intentionally made it ambiguous so that they can selectively enforce it.
For sure. But OPs point still stands, people run giant Plex servers and charge for access to the pirated content on them. Huge numbers of users. I imagine they want to enforce on those folks and not people who just happen to have their own running.
You can use Cloudflare for DNS, but you just can’t use them for proxying the traffic. I use Cloudflare with proxying on for everything other than a plex subdomain.
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.
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.
Yes. The acronym is “ZTNA” (Zero Trust Network Access).
It is an alternative to a traditional corporate VPN that addresses a few architectural issues; namely:
- L3 connectivity (which allows for lateral movement) to the corporate network.
- Inbound exposure to the VPN gateway (scaling can become a challenge, not to mention continuous vulnerabilities from… certain vendors)
- Policy management can get convoluted if you want to do micro-segmentation properly.
ZTNA is essentially an “inside-out” architecture and acts (kind of) like a L4 proxy. I’m going to butcher this explanation, but:
1. Company installs apps/VMs/containers throughout their network. These must have network reachability to the internal apps/services the company wants to make available to its users.
2. These apps/VMs/containers establish TLS tunnels back to the company’s tenant in the vendor’s cloud.
3. Company rolls out the vendor’s ZTNA client to user devices. This also establishes a TLS tunnel to the vendor’s cloud. Hence the vendor’s cloud is like a MitM gatekeeper.
4. Company creates policies in the vendor’s cloud that says “User A can access App X via app/VM/container Z”
5. Even if App X is on the same LAN segment as App Y, App Y is invisible to User A because connectivity to the internal apps happens at L4.
It is an interesting architecture. That being said, ZTNA solutions have their own issues as well (you can probably already spot some based on my explanation above!)
(Note: I worked for a security vendor that sold a ZTNA solution as part of their ~4-5 years ago. Things could be different now.)
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...
> 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.
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.
>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
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.
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.
reply