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.

[im-ichat]

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 :)

would this mean that you could run that module in caddy and now expose all of nextcloud including talk even through a cloudlfare tunnel

• as i now stil need to expose tcp / udp 3478 via a portforward and would love to be able to do all of that some other way as portforwarding is still a pita.

[JoshuaPettus]

I'm afraid cloudflare tunnel only does http/s traffic. No other protocols even if it is over 443.

[A4alli]

what about pangoline. Can I do it with it? I mean nextcloud-aio on localhost machine and pangoline on vps? than make VPS to route the traffic to my selfhosted home nextcloud-aio?

[im-ichat]

sadly you are right after reading up on this, however im actually still kind of interested in seeing if or how this can go...

setting up caddy as reverse proxy on just one port and either forwarding data a dockerized http server or to something else might actually be awsome. its not as great as having a hosted reverse proxy and hiding my ip and not having to portforwarm but forwading just one 443 is better than forwarding many.

[A4alli]

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 :)

can I do it for synapse server as well?

[szaimen]

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

[szaimen]

Hi, there is now a PR that implements this: szaimen/aio-caddy#75