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?

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

https://tailscale.com/blog/peer-relays-beta

[1] https://github.com/connet-dev/connet

[2] https://connet.dev

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.

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.

That would be great!!

This doesn’t sounds zero-trust at all to me. In fact, it’s as far from zero trust as you can get.

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.

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.

I use IPv6 only Emby and Jellyfin servers with my friends. We all have native IPv6 and it works well for us.

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.

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

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.

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.

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

This way I can upload big videos when I get home.