So you don’t want to port-forward on your home router or have Cloudflare decrypt all your traffic? Check out Towonel.

Most open source Cloudflare Tunnel alternatives involve setting up a VPS, terminating TLS there on a reverse proxy, then setting up a Wireguard tunnel to your server at home.

Towonel is different: it does not decrypt your traffic on the VPS and you can easily share one, so not every self-hoster has to buy and maintain a VPS.

Check it out!

Mastodon link: https://gts.erwanleboucher.dev/@eleboucher/statuses/01KS4YNA2SYMSP0FSKJVNJA155

  • irmadlad@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    5 hours ago

    It’s interesting OP. I use the evil Cloudflare Tunnels/Zero Trust, and I’m pretty much sold on it, much to the chagrin of others here. Yes, there are caveats, pros and cons. Even tho I am sold on the product, I would entertain a clone/fork/rewrite if it gave me everything that Cloudflare Tunnels/Zero Trust along with the security features. I’ll do some reading once the blog is back up.

  • PotatoesFall@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    36
    ·
    8 hours ago

    Oh great. So now there’s a tuwunel and a towonel and they’re completely different things.

    (tuwunel is a fork of the matrix backend conduwuit. not to be confused with continuwuity, another conduwuit fork)

    • fhoekstra@feddit.nlOP
      link
      fedilink
      English
      arrow-up
      27
      ·
      edit-2
      7 hours ago

      I know, the naming isn’t ideal.

      On the bright side, you can now expose multiple tuwunel instances via a single towonel and federate with other tuwunels on other towonels for maximum uwu owo

      Which is almost what my friends and I are doing, except we’re running continuwuity instead of tuwunel.

  • Deebster@infosec.pub
    link
    fedilink
    English
    arrow-up
    17
    ·
    7 hours ago

    So I built towonel. In Rust, partly because I wanted to learn the language properly

    This bit makes me a little wary.

    • atomicbocks@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      4
      ·
      3 hours ago

      Why? I didn’t know python until one of my clients decided they would only use it for everything going forward. It took me all of a day to start converting C# code and this was a decade before LLMs.

      Knowledge of a specific language does not reflect development skill.

      • MinFapper@startrek.website
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 hours ago

        Yes, but ported C# usually doesn’t make for the most idiomatic Python.

        99% of the time that doesn’t matter, but a highly security sensitive reverse proxy shared by multiple users most likely part of the stack to be attacked might be an exception.

  • BakedCatboy@lemmy.ml
    link
    fedilink
    English
    arrow-up
    7
    ·
    6 hours ago

    Do most people running a vps reverse proxy terminate tls on the vps? I just proxy TCP 1:1 without touching it to my homelab over my wireguard tunnel. That seems easier than coordinating between the vps which services I’m running locally.

    • hamFoilHat@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      4 hours ago

      Do you have a link to a tutorial or an example setup for that? I’ve wanted that exact setup but couldn’t find how to do it.

      • BakedCatboy@lemmy.ml
        link
        fedilink
        English
        arrow-up
        3
        ·
        3 hours ago

        Not really haha, you could say I followed a tutorial for setting up a wireguard server on a VPS, and then once I had the wireguard container running and my homelab boxes as clients, I started up an haproxy container on the VPS with network_mode: "service:wireguard" so that the wireguard container can also see my homelab boxes through the tunnel, then also added ports 80 and 443 to the wireguard container on the VPS (in addition to the 51820 for incoming wireguard connections) - that has to be on the wireguard container because using network_mode means the haproxy container piggy backs on the wireguard container’s network, then I added a simple haproxy config that listens on 80/443 on the VPSes public IP and proxies it to the appropriate box on the other side of the tunnel.

        For the wireguard config, the key seems to be using mode tcp in any backend or frontend that’s connected to port 443, so that it just proxies raw data without doing termination. With SNI, you can even proxy to different wireguard clients based on domain, because SNI exposes the domain without needing to do termination. So I do that because I have my NAS as well as a NUC connected to the wireguard network hosting different things.

        This is a stripped down version of my haproxy config:

        global
            maxconn     20000
            log         127.0.0.1 local0
            daemon
        
        defaults
            mode http
            timeout connect 10s
            timeout client 1m
            timeout server 1m
            maxconn 8000
            option tcpka
            option tcp-smart-connect
            default-server init-addr last,libc,none
        
        resolvers docker
            parse-resolv-conf
        
        frontend ingress_http
            bind :::80
            bind :80
        
            acl h_secondbox_http hdr(host) -i second.box.example.com
            use_backend secondbox_http if h_secondbox_http
        
            default_backend vault_http
        
        frontend ingress_https
            mode tcp
            bind :::443
            bind :443
            tcp-request inspect-delay 5s
            tcp-request content accept if { req_ssl_hello_type 1 }
        
            acl h_secondbox_https req_ssl_sni -i second.box.example.com
            use_backend secondbox_https if h_secondbox_https
        
            default_backend vault_https
        
        backend vault_http
            server vault_server_http 10.13.13.2:80 send-proxy-v2
        backend vault_https
            mode tcp
            server vault_server_https 10.13.13.2:443 send-proxy-v2
        
        backend secondbox_http
            server secondbox_server_http 10.13.13.3:80 send-proxy-v2
        backend secondbox_https
            mode tcp
            server secondbox_server_https 10.13.13.3:443 send-proxy-v2
        

        The way this is set up, I do have to manually enter every subdomain I want to go to my second box, but the default is to route to my main vault, which is where I host most stuff anyways.

        My docker compose on the VPS is pretty simple:

        services:
          wireguard:
            image: linuxserver/wireguard:latest
            container_name: wireguard
            restart: unless-stopped
            cap_add:
              - NET_ADMIN
              - SYS_MODULE
            environment:
              - PUID=0
              - PGID=0
              - TZ=America/New_York
              - SERVERURL=wg.example.com #optional
              - SERVERPORT=51820 #optional
              - PEERS=vault,secondbox #optional
              - PEERDNS=auto #optional
              - INTERNAL_SUBNET=10.13.13.0 #optional
              - ALLOWEDIPS=10.13.13.1/24 #optional
              - PERSISTENTKEEPALIVE_PEERS=all #optional
              - LOG_CONFS=true #optional
            volumes:
              - ./volumes/wg-config:/config
            ports:
              - 51820:51820/udp
              - 80:80/tcp
              - 443:443/tcp
              - 8090:8090/tcp
            sysctls:
              - net.ipv4.conf.all.src_valid_mark=1
        
          haproxy:
            image: haproxy:lts
            container_name: haproxy
            restart: unless-stopped
            network_mode: "service:wireguard"
            depends_on:
              - wireguard
            volumes:
              - ./volumes/haproxy-config:/usr/local/etc/haproxy
        

        Then on the local side I use the same network_mode: "service:wireguard" trick to link my traefik container to the wireguard container, that way traffic hitting ports 80/443 of the wireguard container which is on the tunnel is also seen by traefik:

        services:
          boringtun:
            image: boringtun
            build: ./boringtun-docker
            container_name: boringtun
            restart: always
            privileged: true
            cap_add:
              - NET_ADMIN
            devices:
              - "/dev/net/tun:/dev/net/tun"
            volumes:
              - "./volumes/wg-config/wg0.conf:/etc/wireguard/wg0.conf"
            logging:
              driver: "json-file"
              options:
                max-size: "400k"
                max-file: "20"
            environment:
              - INTERFACE_NAME=wg0
              - WG_SUDO=1
              - WG_QUICK_USERSPACE_IMPLEMENTATION=/app/boringtun
            entrypoint: /bin/bash
            command: -c "wg-quick up wg0 && sleep infinity"
            extra_hosts: # Allows containers to access the host machine as host.docker.internal, useful for remote access to the host through a container
              - "host.docker.internal:host-gateway"
            networks:
              - ingress
        
          traefik:
            image: traefik:v2.11
            container_name: traefik
            restart: always
            network_mode: "service:boringtun"
            depends_on:
              - boringtun
            command:
              # - "--log.level=DEBUG"
              - "--providers.docker"
              - "--entrypoints.web.address=:80"
              - "--entryPoints.web.proxyProtocol.trustedIPs=10.13.13.1"
              - "--entrypoints.websecure.address=:443"
              - "--entryPoints.websecure.proxyProtocol.trustedIPs=10.13.13.1"
              - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
              - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
              - "--entrypoints.web.http.redirections.entrypoint.priority=100"
              # Timeouts
              - "--entryPoints.websecure.transport.respondingTimeouts.readTimeout=0"
              - "--entryPoints.websecure.transport.respondingTimeouts.writeTimeout=0"
              - "--entryPoints.websecure.transport.respondingTimeouts.idleTimeout=0"
              - "--providers.docker.exposedByDefault=false"
              - "--providers.docker.network=ingress"
              - "--certificatesresolvers.mytlschallenge.acme.tlschallenge=true"
              - "--certificatesresolvers.mytlschallenge.acme.email=youremail@example.com"
              - "--certificatesresolvers.mytlschallenge.acme.storage=/letsencrypt/acme.json"
              - "--serversTransport.forwardingTimeouts.dialTimeout=3m"
              # - "--api.insecure=true"
              # - "--certificatesresolvers.mytlschallenge.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory"
            environment:
              - TZ=America/New_York
            volumes:
              - ./volumes/le-data/acme.json:/letsencrypt/acme.json
              - /var/run/docker.sock:/var/run/docker.sock
        

        I only use boringtun on this side because I think synology doesn’t or didn’t have the kernel module for wireguard and using the userspace mode made it work for me, otherwise you could probably just use the regular wireguard container. Also note that my docker network for communicating between traefik and stuff I’m exposing is ingress, which is specified both on the boringtun container as well as passed to traefik as providers.docker.network, I think that’s needed so that traefik can figure out the container IP of the containers you’re exposing. I also haven’t migrated to traefik v3 because I’m lazy.

        Another note, there’s an annoying condition where if you reboot, it may fail to attach the traefik container to wireguard because it linked via network mode to the old container. Just doing compose down and up fixes it by recreating all the containers. But other than that which I haven’t encountered in a while it works really well. I’m not sure if that bug was fixed because I rarely reboot.

      • stratself@lemdro.id
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 hours ago

        Not exactly a tutorial, but I use SNI routing + TLS passthrough with Caddy-L4 (and previously Traefik), and wrote/collect some stuff about it over the years:

        {
            layer4 {
                tcp/:443 {
                    tcp/127.0.0.1:538
                }
            }
        }
        
    • fhoekstra@feddit.nlOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      5 hours ago

      Very similar.

      The main differences are that those projects are highly configurable and can do a lot of things, while towonel is simpler: opinionated/streamlined for use as a shared Cloudflare tunnel alternative. I also think towonel may be the only one to use QUIC for the tunnel, just like Cloudflare.

      Besides that, towonel is very new and still in alpha. Rathole does not seem to be actively developed anymore, which can be a good or bad thing.

  • DecronymB
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    2 hours ago

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

    Fewer Letters More Letters
    IP Internet Protocol
    LXC Linux Containers
    NAS Network-Attached Storage
    NAT Network Address Translation
    NUC Next Unit of Computing brand of Intel small computers
    SSL Secure Sockets Layer, for transparent encryption
    TCP Transmission Control Protocol, most often over IP
    TLS Transport Layer Security, supersedes SSL
    VPS Virtual Private Server (opposed to shared hosting)

    [Thread #304 for this comm, first seen 21st May 2026, 13:30] [FAQ] [Full list] [Contact] [Source code]

  • EarMaster@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    5 hours ago

    Is the agent only available as a docker image? I quite like the option to run Cloudflare tunnels as a local service (e.g. in LXCs).

  • hirihit640@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    8
    ·
    edit-2
    8 hours ago

    Very cool. I personally use a double wireguard network: a wireguard vpn at home for all my services, and then since my home network is behind a double NAT and impossible to access publicly, I use a second wireguard tunnel to a VPS, to forward traffic to my internal wireguard network. The only thing the VPS can see is encrypted wireguard packets.

    Edit: it seems like this service is more for public or shared services (like a public blog), rather than private personal services, so wireguard is less of an option