Put STUN/Turn server on 443 TCP/UDP (Add SSLH) or use caddy?

[JoshuaPettus]

This may not be worth putting into prime time, and personally I use NC on bare metal, but I saw that the AIO version had all the talk stuff included and I thought someone might be interested in this.

From my experience, the stun and turnserver avoids a lot firewall issues if it runs off of 443/TCP instead of the 3478/TCP. ( For example if a phone with the talk app is using some public wifi that has other ports blocked). Now granted that port is of course being used by the web service. It is still very possible to work around that by using sslh https://github.com/yrutschle/sslh as an intermediary proxy and switch board. Its a simple program that listens on 443, scans the incoming packets and forwards the connection to the correct application according to the ACL rules set in the sslh.cfg file. It has sslh-fork and sslh-ev variants (ev being the more robust version) that also support scanning for UDP protocols as well.

To pick up the turn packets I just added to my sslh.cfg file:

listen:
(
    { host: "{External IP}"; port: "443"; is_udp: false },
    { host: "{External IP}"; port: "443"; is_udp: true }
);
protocols:
(
### Coturn
     { name: "tls"; host: "127.0.0.1"; port: "3478"; sni_hostnames: [ "{turn.domain.com}" ]; fork: true; tfo_ok: true; resolve_on_forward: true; },
     { name: "tls"; host: "127.0.0.1"; port: "3478"; alpn_protocols: [ "stun.turn", "stun.nat-discovery" ]; fork: true; tfo_ok: true; resolve_on_forward: true; },
     { name: "tls"; host: "127.0.0.1"; port: "3478"; sni_hostnames: [ "{turn.domain.com}" ]; is_udp: true; resolve_on_forward: true; },
     { name: "tls"; host: "127.0.0.1"; port: "3478"; alpn_protocols: [ "stun.turn", "stun.nat-discovery" ]; is_udp: true; resolve_on_forward: true; }
### TLS
### Webserver is listening on 127.0.0.2 port 443 ###
     { name: "tls"; host: "127.0.0.2"; port: "443"; tfo_ok: true; resolve_on_forward: true; }, 
 ###  Extra catch for tls turn
      { name: "anyprot"; host: "127.0.0.1"; port: "5349"; fork: true; tfo_ok: true; resolve_on_forward: true; }
);

Now this gets a little more complicated if you want to use the transparent proxy feature. That would allow the webservice to see the actual ip of the incoming connection which could be important for fail2ban or various other services.

To make that feature work I had to modify my systemd service file to look like this
/lib/systemd/system/sslh.service

 [Unit]
 Description=SSL/SSH multiplexer
 After=network.target
 Documentation=man:sslh(8)

 [Service]
 ExecStart=/usr/sbin/sslh-ev -F/etc/sslh/sslh.cfg
 KillMode=process
 Type=forking

 #Set routing rules/routes automatically on sslh service start
 PermissionsStartOnly=true

 #Add the ip rules and route to enable Transparent Proxy
 ExecStartPre=/sbin/ip rule add fwmark 0x1 lookup 100
 ExecStartPre=/sbin/ip route add local 0.0.0.0/0 dev lo table 100
 ExecStartPre=/sbin/ip rule add from 127.0.0.2/32 table 100
 ExecStartPre=/sbin/ip route flush cache

 #Remove the ip rules and route to enable Transparent Proxy
 ExecStopPost=/sbin/ip rule del fwmark 0x1 lookup 100
 ExecStopPost=/sbin/ip route del local 0.0.0.0/0 dev lo table 100
 ExecStopPost=/sbin/ip rule del from 127.0.0.2/32 table 100
 ExecStopPost=/sbin/ip route flush cache

 [Install]
 WantedBy=multi-user.target

Supposedly SSLH supports dealing with QUIC as well, but I haven't gotten that to work.

[szaimen]

Hi, thanks for the idea! However I would rather not add yet another dependency to this project. Also we are using caddy internally. If we can somehow make it work with caddy, I would be fine with this idea :)

[JoshuaPettus]

Understandable. I use nginx as my reverse proxy and webserver and it listens on interface 127.0.0.2 at port 443. (though really it can be any port and then no need to specify the interface) and SSLH forwards web traffic to it through the TLS rule. I would think caddy would be the same with SSLH in front of it.

[szaimen]

I meant if caddy can do the same what SSLH does then we could consider this :)

[JoshuaPettus]

Oh I see, ok!

[JoshuaPettus]

Hmm maybe something like this caddy plugin would be useful https://github.com/mholt/caddy-l4. Though that's skirting the line on extra dependencies.

[szaimen]

Though that's skirting the line on extra dependencies.

Indeed. However I am personally maintaining https://github.com/nextcloud/all-in-one/tree/main/community-containers/caddy that could possibly be adjusted to also feature this modul. However the biggest problem that I currently see with https://github.com/mholt/caddy-l4 is that it is not configurable via Caddyfile which makes it much harder to use. So if you find another modul that does the same but can use the Caddyfile, that would be perfect. Afterwards feel free to create a Pull Request in this repo: https://github.com/szaimen/aio-caddy in order to add this feature.

[szaimen]

Hi, it looks like Caddyfile support is now implemented for https://github.com/mholt/caddy-l4 via mholt/caddy-l4#217. So feel free to add this module to https://github.com/szaimen/aio-caddy and change the Caddyfile in there in order to allow to proxy STUN/TURN server via 443 TCP/UDP :)

[rriemann]

@JoshuaPettus Did you manage with caddy-l4? Could you please share your work?

[JoshuaPettus]

No, I have never taken up a project of switching from Nginx to caddy. And other projects I have would be more of a burden for me to switch. I only mentioned the possibility since you were on caddy.

[szaimen]

Hi, I was wondering: could Tailscale maybe be used for this?

[A4alli]

need tailscale coturn and caddy. I ran synapse but need coturn for audio/video