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.
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].
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 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.
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.
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.
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.
> 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.
> 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.
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.
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.
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 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?
$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.
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.
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.
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.
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.
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.
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].
[1] https://github.com/connet-dev/connet
[2] https://connet.dev
The other option from this great list https://github.com/anderspitman/awesome-tunneling which seems to meet both sets of goals is NetFoundry.
1. End-to-end encryption.
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.
Zero Trust, except for the trust in Cloudflare.
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.
Tailscale funnels do work, but it's public only. No auth.
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.
TLS termination is neither required nor enabled by default, right?
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.
Correct. We run it without it and just use the DNS filtering aspect.
How does it do DNS filtering without TLS interception - takeover for DNS resolution?
In what way are DNS resolution and TLS related except for the little-used DoT?
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...
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.
It’s not that it can’t do it, it’s that it’s against the terms of service to use it for video.
Isn’t that for their CDN, rather than Zero Trust? I don’t think they even know what traffic is going over Zero Trust.
You can't play corporate videos over Cloudflare Warp? Where is the line drawn?
I think they don't want you using a boatload of bandwidth, since data proxies through their servers.
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.
You could just disable cdn/caching.
It’s not enforced in practice unless you run a giant server with a lot of traffic.
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.
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!
> 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.
> 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.
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.
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.
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.
But is this vendor-lockin, as in CloudFlare being the vendor here? Because at least with Tailscale there's no vendor lock-in.
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?
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.)
Yes, this is exactly what this does.
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?
$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
Tailscale has what they call Peer Relays now to help solve this problem:
https://tailscale.com/blog/peer-relays-beta
For many homelabbers, just being cheap and avoiding the $3 VPS, that's it
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.
I dont even pay anything, my tiny homelab is completely covered by the free tier
What provider still has decent free tier?
Oracle. 4 vCPU, 24 GB RAM, 200 GB SSD. It’s arm64 but nowadays that doesn’t really matter.
That can't possibly be free?
https://docs.oracle.com/en-us/iaas/Content/FreeTier/freetier...
Only caveat I see is they reserve the right to delete underutilized/ idling instances
That’s generous but Oracle is very generous.
Which region were you able to create this in? They seem to be out of capacity all the time in EU.
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.
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?
Headscale is the not-vendor-login version of Tailscale.
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.
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.
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.