<img alt="1000137440" src="https://infosec.pub/pictrs/image/1b610c06-152a-481c-ac07-8a365169249f.jpeg">

Holy shit. That’s all I got

<img alt="" src="https://lemmy.world/pictrs/image/3db7dd08-ebfa-40c2-8141-e9ac57b3991a.jpeg">

Oh right, forgot to mention conduwuit was itself a fork of conduit. Man

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.

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:

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:

• theorangeone.net/…/wireguard-haproxy-gateway/. From TheOrangeOne, involves TCP routing with HAProxy and plain WireGuard. Most likely what you want.

• muoi.me/~stratself/articles/tailscale-notes/#the-…. Me using Traefik + Tailscale to route TCP to the backend

• jdedev.org/projects/tophomelabwork/…/traefik/. Another Traefik example

• muoi.me/…/the-cost-of-tls-passthrough/#scenario-1…. Same but for Caddy-L4 and involves SNI routing. If you want plain TCP routing just do

{
    layer4 {
        tcp/:443 {
            tcp/127.0.0.1:538
        }
    }
}