TLS termination is neither required nor enabled by default, right?

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?

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

Tailscale ‘serve’ works well at my startup. SSL and DNS still but unlike funnel it’s limited to your tailscale network.

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.

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

Zero Trust, except for the trust in Cloudflare.

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.

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.

The productized version, NetFoundry Frontdoor (doc here https://netfoundry.io/docs/frontdoor/how-to-guides/create-mt...) is what offers mutual TLS support.

It'll still terminate TLS at the servers, though. It's not mTLS all the way through to the endpoint.

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

i should have been more clear - you have the option:

+ e2ee via netfoundry's zero trust products

+ non-e2ee via netfoundry frontdoor

I think the issue is zrok vs. NetFoundry/OpenZiti. Zrok is the easy button to project a public endpoint from inside a network. It is not encrypted all the way through, as it is a proxy solution. NetFoundry/OpenZiti provides methods to provide tunnels all the way through. NetFoundry is a company, OpenZiti is a FOSS project/technology sponsored by NetFoundry, and zrok is a product of NetFoundry built on OpenZiti tech, so it is easy to cross things up. I think the comment was in regard to NetFoundry/OpenZiti, while your response referenced zrok. The list above has both.

For that kind of end-to-end encryption I use pinggy.io tls tunnels.

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?

Fair point!

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

Thats a big privacy issue if they strip TLS, does it have a technical reason or they just don't want to offer privacy?

Is it technically possible to have something like Tailscale funnel but with something like Cloudflare Access authentication (at least for some options)?

That would be great!!

> Cloudflare […] acts as a termination point for TLS

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