posted in Selfhosted

Replacing Cloudflare Tunnel with a Selfhosted Towonel Tunnel

Every public request to one of my sites used to go through a Cloudflare tunnel. I had a cloudflared deployment in my cluster, some routing rules, and everything just worked. And it was free! But that bugged me. TANSTAAFL right? The whole point of selfhosting is to not rely on big cloud company, and there are few bigger than Cloudflare. And Cloudflare’s tunnels decrypt every single packet, so they see everything you do. I really don’t like that.

So I’ve replaced Cloudflare tunnels with Erwan Leboucher’s towonel, a selfhosted tunnel implementation. I still have my DNS on Cloudflare, but no data is moving through them any more.

blog.jameswynn.com/posts/2026/08/cloudflare-to-towonel/

Replying to an earlier post

between your device

Thats the part right there. Its for not your device to access.

Like a self- hosted website/blog for example. Or taking the complexity of “start this before you try to connect to my eBook server” for your BIL, or “OK mom, when you want to watch the home videos I converted to digital you have to do it only from your phone, press this first, then share to your TV”.

That is the part I think you are missing. Use other than yourself and your own managed devices.

Replying to @⁨moonpiedumplings@programming.dev⁩

I use haproxy just for simplicity, with the https fronted in tcp mode with a tcp request inspect delay and acls using req_ssl_sni allows switching between multiple backend based on hostname, though if you only had 1 backend server then it could just be a raw tcp proxy. I have my stuff split between 2 local boxes that are both connected to the reverse proxy using wg so this works well for me.

Replying to @⁨Shimitar@downonthestreet.eu⁩

I checked and this does a similar thing. You can use WG to punch out a connection, and I have before. The linked program uses quic in a similar way to WG but doesn’t do any of the routing, just registers the connection to a hostname for application level forwarding.

It looks more that it provides an easy setup for an alternative.

Both methods can work on cg-nat as well since you are punching out.

Replying to @⁨Shimitar@downonthestreet.eu⁩

That’s exactly the use case for “tunnels”: allowing public, incoming connections behind CGNAT.

Wireguard requires a public IP on at least one side of the connection and only allows private access. If you want to host a blog or website AND you’re behind CGNAT, then a “tunnel” service is a very easy solution.

Edit: my previous blog post on the topic: blog.k3can.us/posts/…/2025-02-21_cloudflarefort/

blog.k3can.usCloudflare for the Selfhoster - k3can blog

Replying to @⁨Undaunted@feddit.org⁩

Oh, maybe I misunderstood? It sounded like he didn’t understand what advantage a “tunnel” could provide.

If your server is behind CGNAT, you need a TURN-style “tunnel” to allow incoming connections. If you have your own remote server with a public IP, then you can absolutely use that and create the tunnel using wireguard (or openvpn, ssh, etc).

I just mentioned CF in my blog post because it’s probably the most popular solution.

The point is, if you have CGNAT, you need to create that “tunnel” somehow if you want to allow incoming connections.