TURN.STUN REGEX Enable

[iamdoubz]

First off, sslh is wonderful and works great. This is not a bug, more of a "How do I do this" sort of question as I don't quite understand how support is on over the email chain?

End goal

I want to add a TURN server into the sslh.cfg file.

What is happening right now

Per all the README's, I am suppose to add a REGEX from this website that looks something like 0x73 0x74 0x75 0x6E 0x2E 0x74 0x75 0x72 0x6E in order to forward the traffic to my coturn server. However, no idea how to make "matches" so that this gets turned on.

What I've tried

This line in the sslh.cfg file:

{ name: "tls"; host: "localhost"; port: "5349"; alpn_protocols: [ "stun.turn" ]; log_level: 0;  tfo_ok: true },

Any thoughts or insights to regex (besides having my cat play on my keyboard to generate regex queries) in order to enable it for coturn would be greatly appreciated. Thanks in advance.

[knedlyk]

Did you succeed in this? I wanted to add coturn server in my home network behind NAT, but faced up with the same problem.

[yrutschle]

For some reason Github didn't notify me... or my mail server lost it... or I didn't read it... or I did and forgot about it... or my cat ate my answer... whatever.

The regex would read like \x73\x74\x75 [...]. But really the ALPN setting 'should' work, and I don't see anything particularly wrong in your configuration. Can you describe in more details what's happening, setting log_level to some higher value and reporting connection traces (what sslh sees, where it forwards, and whether the receiving server sees something).

[licaon-kter]

{ name: "tls"; host: "192.168.100.100"; port: "5349"; regex_patterns: [ "\x73\x74\x75\x6E\x2E\x74\x75\x72\x6E"]; log_level: 0; tfo_ok: true } matches any TLS traffic, umm what am I doing wrong?

I need to put this as the last option, else none of the websites work. But if I put it last it doesn't matter if I regex or alpn stun.turn right?

Putting alpn_protocols: [ "stun.turn" ]; doesn't help either, traffic is not routed.

[iamdoubz]

Okay, lost my log in for github, so I'm back on this... Quick story, I'm using coturn to do Nextcloud Talk phone calls.

SSLH doesn't match anything I've made except for my backup, backup, backup option.. so the relevant lines in my config are:

{ name: "tls"; host: "localhost"; port: "5349"; alpn_protocols: [ "h2", "http/1.1", "stun.turn" ]; sni_hostnames: [ "turn.dom.ain" ]; log_level: 1;  tfo_ok: true },
{ name: "tls"; host: "localhost"; port: "443"; log_level: 0; tfo_ok: true },
{ name: "anyprot"; host: "localhost"; port: "5349"; sni_hostnames: [ "turn.dom.ain" ]; log_level: 1;  tfo_ok: true },

So the journalctl -u sslh log says:

May 15 14:30:03 compname sslh[18346]: probing for ssh
May 15 14:30:03 compname sslh[18346]: probed for ssh: PROBE_NEXT
May 15 14:30:03 compname sslh[18346]: probing for openvpn
May 15 14:30:03 compname sslh[18346]: probed for openvpn: PROBE_NEXT
May 15 14:30:03 compname sslh[18346]: probing for tls
May 15 14:30:03 compname sslh[18346]: Request did not begin with TLS handshake.
May 15 14:30:03 compname sslh[18346]: probed for tls: PROBE_NEXT
May 15 14:30:03 compname sslh[18346]: probing for tls
May 15 14:30:03 compname sslh[18346]: Request did not begin with TLS handshake.
May 15 14:30:03 compname sslh[18346]: probed for tls: PROBE_NEXT
May 15 14:30:03 compname sslh[18346]: probing for tls
May 15 14:30:03 compname sslh[18346]: Request did not begin with TLS handshake.
May 15 14:30:03 compname sslh[18346]: probed for tls: PROBE_NEXT
May 15 14:30:03 compname sslh[18346]: probing for tls
May 15 14:30:03 compname sslh[18346]: Request did not begin with TLS handshake.
May 15 14:30:03 compname sslh[18346]: probed for tls: PROBE_NEXT
May 15 14:30:03 compname sslh[18346]: probing for anyprot
May 15 14:30:03 compname sslh[18346]: probed for anyprot: PROBE_MATCH
May 15 14:30:03 compname sslh[18346]: connecting to localhost:5349 family 2 len 16
May 15 14:30:03 compname sslh[18346]: flushing deferred data to fd 3
May 15 14:30:03 compname sslh[19003]: anyprot:connection from 174.219.1.159:7766 to compname:4443 forwarded from localhost:50118 to localhost:5349
May 15 14:30:04 compname sslh[18346]: accepted fd 5
May 15 14:30:04 compname sslh[18346]: **** writing deferred on fd -1

Which means two things:

1. It only works with "anyprot" and the sni_hostnames "turn.dom.ain"
2. Nextcloud Talk isn't securing the turn calls? Kinda scary but whatever. Actually, maybe not so much.

Any suggestions? I know that this isn't directly related to sllh and it technically works, but any suggestions greatly welcomed.

[iamdoubz]

So changed my config file to:

protocols:
(
    { name: "tls"; host: "192.168.10.3"; port: "25"; sni_hostnames: [ "smtp.dom.ain" ]; log_level: 0;  tfo_ok: true },
    { name: "tls"; host: "192.168.10.3"; port: "990"; sni_hostnames: [ "ftp.dom.ain" ]; log_level: 0; tfo_ok: true },
    { name: "tls"; host: "192.168.10.16"; port: "443"; alpn_protocols: [ "h2", "http/1.1", "h2c" ]; log_level: 0; tfo_ok: true },
    { name: "ssh"; service: "ssh"; host: "192.168.10.16"; port: "22"; keepalive: true; fork: true; log_level: 0; tfo_ok: true },
    { name: "openvpn"; host: "192.168.10.16"; port: "1194"; log_level: 0; },
    { name: "tls"; host: "192.168.10.16"; port: "443"; log_level: 0; tfo_ok: true },
    { name: "anyprot"; host: "192.168.10.16"; port: "5349"; sni_hostnames: [ "turn.dom.ain" ]; log_level: 1; tfo_ok: true },
    { name: "timeout"; service: "daytime"; host: "192.168.10.16"; port: "daytime"; }
);

I want it to be much higher on the list, but if I use "anyprot", regardless of what I put in for either "sni_hostnames" or "alpn" will PROBE_MATCH.. So in testing, broke my websites for like 15 seconds, but we're all good and everything is running through 443!!

[licaon-kter]

Same results as mine, if it's last it doesn't matter, if it doesn't work as first entry, then it means it doesn't work at all.

Not sure webrtc does alpn.

[iamdoubz]

Same results as mine, if it's last it doesn't matter, if it doesn't work as first entry, then it means it doesn't work at all.

Not sure webrtc does alpn.

What turnserver are you using? What application are you using to connect to your turn server?

It is my understanding that the ALPN is for encrypted traffic only... so that is why my lines, no matter what, did not work for my turn server set up. The webrtc alpn, if encrypted (required by all modern browsers I believe?), would be simply "webrtc".

[licaon-kter]

Have any links for the specs?

Tryed with ejabberd and coturn.

[iamdoubz]

The ALPN specs? Yes.

[yrutschle]

ALPN and SNI are TLS extensions, they only work with the TLS probe. Some day I'd like to add warnings about illegal options, but that involves adding an introspection function to libconfig, which doesn't have one, so that's not going to happen in the near future...

[iamdoubz]

I am closing this issue, because for my environment, the TURN calls are from Nextcloud, and are not encrypted.

[JoshuaPettus]

Nextcloud does use TURNS (TURN over SSL) now. Has someone ever had any luck with the regex for this? It seems the new recommendations to get around annoying firewalls is to place the turn server (coturn in my case) on 443. It would be nice if I could leverage sslh to do that

[yrutschle]

I wouldn't use a regex for this, rather I would use either SNI or ALPN. SNI will be set by the hostname you're connecting to, which is a simple way to separate protocols based on TLS: you can have "www.example.com" for HTTPS, "turns.example.com" for TURNS, and so on.

[iamdoubz]

Nextcloud does use TURNS (TURN over SSL) now. Has someone ever had any luck with the regex for this? It seems the new recommendations to get around annoying firewalls is to place the turn server (coturn in my case) on 443. It would be nice if I could leverage sslh to do that

I just recently set up sslh and coturn to use turns.

Like @yrutschle said, the quickest and easiest way is to add another A record to your domain i.e. turn.my.domain, and have sslh redirect that traffic to your coturn server using this config:

Without UDP:

    { name: "tls"; host: "localhost"; port: "3478"; sni_hostnames: [ "turn.my.domain" ]; log_level: 0; fork: true; tfo_ok: true },
    { name: "tls"; host: "localhost"; port: "3478"; alpn_protocols: [ "stun.turn", "stun.nat-discovery" ]; log_level: 0; fork: true; tfo_ok: true },

With UDP:

    { name: "tls"; host: "localhost"; port: "3478"; sni_hostnames: [ "turn.my.domain" ]; log_level: 0; fork: true; tfo_ok: true },
    { name: "tls"; host: "localhost"; port: "3478"; alpn_protocols: [ "stun.turn", "stun.nat-discovery" ]; log_level: 0; fork: true; tfo_ok: true },
    { name: "tls"; host: "localhost"; port: "3478"; sni_hostnames: [ "turn.my.domain" ]; log_level: 0; fork: true; tfo_ok: true; is_udp: true;},
    { name: "tls"; host: "localhost"; port: "3478"; alpn_protocols: [ "stun.turn", "stun.nat-discovery" ]; log_level: 0; fork: true; tfo_ok: true; is_udp: true;},

HINTS

I never got coturn to use turns because... it was never listening for TLS connections! Check your coturn log and make sure the user that you use to start the coturn server has access to the ssl certificates that you want to use!!!

[JoshuaPettus]

Thanks Guys! I'll give it a try as soon as I can. (Probably over the weekend if I'm lucky).

Great hints iamdoubz! I actually got burned the same way and took me forever to figure it out :) now to get it all on 443.

[yrutschle]

@iamdoubz the TLS probe works with is_udp: true? What is TURN sending then, is it DTLS?

I know DTLS is "based on" TLS, so it's possible that it works, but I'm interested to know if actually does :-)

[iamdoubz]

@yrutschle I can find out here today: To turn on logging for the TURN udp traffic, do all I need to do is add log_level: 1 to my config line?

[yrutschle]

no, verbose_probe_info: 3 rather (or 1 or 2 depending on your preferred logging method). Thanks for your feedback.

[JoshuaPettus]

{Edit} I had a huge post about my configuration and trying to figure out what I was doing wrong, but never mind!

After a reboot with the correct settings, it worked! Odd it took a reboot to clear it out and not a simple reboot of my systemd service, but oh well, lesson learned.

[iamdoubz]

no, verbose_probe_info: 3 rather (or 1 or 2 depending on your preferred logging method). Thanks for your feedback.

Here is what sslh spits out using log verbose level 3:

username@computer:/etc/nginx/conf/servers$ sudo service sslh start
username@computer:/etc/nginx/conf/servers$ sudo journalctl -fu sslh
Dec 14 09:11:00 computer sslh[2554127]: profiling:/home:Cannot create directory
Dec 14 09:11:00 computer sslh[2554127]: profiling:/home/username/gits/sslh/sslh-ev.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/udp-listener.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/processes.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/gap.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/collection.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/argtable3.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/tls.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/probe.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/sslh-main.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/log.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/common.gcda:Skip
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home:Cannot create directory
Dec 14 09:11:02 computer sslh[2554083]: profiling:/home/username/gits/sslh/sslh-conf.gcda:Skip
...
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution
Dec 14 09:11:05 computer sslh[2554083]: tls:connection from turn.my.domain:3646 to 192.168.1.147:4443 forwarded from turn.my.domain:3646 to 127.0.0.1:3478
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution
Dec 14 09:11:05 computer sslh[2554083]: tls:connection from turn.my.domain:3647 to 192.168.1.147:4443 forwarded from turn.my.domain:3647 to 127.0.0.1:3478
Dec 14 09:11:05 computer sslh[2554083]: sprintaddr:getnameinfo: Temporary failure in name resolution

Per this ticket response, if you use turns: + UDP, you are using DTLS. If you use turns: + TCP, you are using TLS. If you use turn: + TCP, it is turn over TLS, but WebRTC needs SSL, so using turns: actually double encrypts your packets causing overhead, but the benefit is to get by extremely tight firewalls... which is why we are all using sslh in the first place 🙌

EDIT:

Actually made a call and this was the webrtc info:

Statistics RTCTransport_0_1
timestamp   12/14/2021, 3:58:04 PM
bytesSent   85965886
[bytesSent_in_bits/s]   923248
packetsSent 98573
bytesReceived   1231958
[bytesReceived_in_bits/s]   31984
packetsReceived 16942
dtlsState   connected
selectedCandidatePairId RTCIceCandidatePair_nHAE7B4i_vlEnNvXa
localCertificateId  RTCCertificate_7E:71:81:A5:37:6D:B5:48:34:87:FB:59:74:D4:DB:DF:73:3F:D7:E1:5D:19:81:DB:05:F2:B8:4B:CC:0B:4C:2A
remoteCertificateId RTCCertificate_82:36:FD:AE:AB:34:DC:27:DC:DD:B4:94:26:87:C5:BC:2B:15:1B:31:5D:49:23:D6:96:EE:1D:4E:F4:BC:05:19
tlsVersion  FEFD
dtlsCipher  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
srtpCipher  AES_CM_128_HMAC_SHA1_80
selectedCandidatePairChanges    1

[yrutschle]

the 'profiling' messages are weird: there are no such messages in sslh...

I also don't see the probing messages. Nevermind your link, and the TURN specs, confirm it is in fact DTLS. So that means the TLS probe works on UDP to match DTLS, which is sort of expected, but not quite, but cool nonetheless :)

Thanks!

[iamdoubz]

Yes it is very nice to know that the TLS sslh probe works for both TCP and UDP traffic!

For profiling, I will continue on my What is sslh-ev? ticket.

[JoshuaPettus]

So actually this is weird. It looked like it was working but it wasn't actually. No coturn connections were ever in the coturn log. I finally verified the situation by killing all coturn instances on the server but when I ran on another machine "turnutils_uclient -p 443 -T -W mysecret turn.mydomain.com" I still would get a

recv: Success (which was enough to make nextcloud think it was working) but nothing after

So that's bizarre. So that must mean another application is taking the connection... SSH?

here is my sslh config

1 # This is a basic configuration file that should provide 2 # sensible values for "standard" setup. 3 4 verbose: 0; 5 foreground: false; 6 inetd: false; 7 numeric: false; 8 transparent: false; 9 timeout: 5; 10 user: "sslh"; 11 pidfile: "/var/run/sslh.pid"; 12 chroot: "/var/empty"; 13 14 # Change hostname with your external address name. 15 listen: 16 ( 17 { host: "192.168.2.2"; port: "443"; }, 18 { host: "10.8.0.1"; port: "443"; } #used for listening on OVPN connections 19 ); 20 21 protocols: 22 ( 23 { name: "ssh"; service: "ssh"; host: "127.0.0.2"; port: "22"; fork: true; }, 24 ### OpenVPN 25 { name: "openvpn"; host: "127.0.0.2"; port: "1194"; log_level: 0; }, 26 { name: "openvpn"; host: "127.0.0.2"; port: "1194"; sni_hostnames: [ "vpn.mydomain.com" ]; log_level: 0 }, 27 ### Coturn 28 { name: "tls"; host: "192.168.2.2"; port: "5349"; sni_hostnames: [ "turn.mydomain.com" ]; log_level: 0; fork: true; tfo_ok: true; }, 29 { name: "tls"; host: "192.168.2.2"; port: "5349"; alpn_protocols: [ "stun.turn", "stun.nat-discovery" ]; log_level: 0; fork: true; tfo_ok: true; }, 30 { name: "tls"; host: "192.168.2.2"; port: "5349"; sni_hostnames: [ "turn.mydomain.com" ]; log_level: 0; is_udp: true; tfo_ok: true; }, 31 { name: "tls"; host: "192.168.2.2"; port: "5349"; alpn_protocols: [ "stun.turn", "stun.nat-discovery" ]; log_leve0: 1; is_udp: true; tfo_ok: true; }, 32 ### TLS 33 { name: "tls"; host: "127.0.0.2"; port: "443"; alpn_protocols: [ "h2", "http/1.1", "http/1.2", "http/1.3", "h2c" ]; log_level: 0; fork: true; tfo_ok: true; }, 34 { name: "tls"; host: "127.0.0.2"; port: "443"; log_level: 0; tfo_ok: true; } 35 36 # { name: "openvpn"; host: "127.0.0.2"; port: "1194"; }, 37 # { name: "xmpp"; host: "localhost"; port: "5222"; }, 38 # { name: "http"; host: "localhost"; port: "80"; }, 39 # { name: "tls"; host: "127.0.0.2"; port: "443"; log_level: 0; } 40 # { name: "anyprot"; host: "localhost"; port: "443"; } 41 );

any ideas?

[iamdoubz]

So actually this is weird. It looked like it was working but it wasn't actually. No coturn connections were ever in the coturn log.

@JoshuaPettus

Could you share your turnserver.conf contents and possibly a screenshot of the Nextcloud Talk config page?

I don't have logging enabled on my turnserver, but I can watch the connection when I test the server from Nextcloud using the command sudo journalctl -fu coturn. It should look similar to this:

Dec 15 06:26:19 computer turnserver[1457714]: 49: udp_server_input_handler:628:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: handle_udp_packet: New UDP endpoint: local addr 192.168.1.147:3478, remote addr my.domain:51994
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4648:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4445:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection: data.buffer=0x7f043800b1dc, data.len=20
Dec 15 06:26:19 computer turnserver[1457714]: 49: handle_turn_binding:2723:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: handle_turn_binding:2910:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: session 006000000000000001: realm <my.domain> user <>: incoming packet BINDING processed, success
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4229:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection: prepare to write to s 0x7f043801b1e0
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4252:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4551:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4682:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: udp_server_input_handler:666:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:74:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:74:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: IPv4. tcp or tls connected to: my.domain:5618
Dec 15 06:26:19 computer turnserver[1457714]: 49: IPv4. tcp or tls connected to: my.domain:5619
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:121:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:121:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4648:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4648:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4682:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4682:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:74:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: IPv4. tcp or tls connected to: my.domain:5620
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:121:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4648:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4682:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:74:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: IPv4. tcp or tls connected to: my.domain:5621
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:121:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4648:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4682:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:74:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: IPv4. tcp or tls connected to: my.domain:5622
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:121:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4648:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4682:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:74:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: IPv4. tcp or tls connected to: my.domain:5623
Dec 15 06:26:19 computer turnserver[1457714]: 49: server_input_handler:121:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4648:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: open_client_connection_session:4682:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4445:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection: data.buffer=0x7f045c0126bc, data.len=28
Dec 15 06:26:19 computer turnserver[1457714]: 49: session 000000000000000003: realm <my.domain> user <>: incoming packet message processed, error 401: Unauthorized
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4229:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection: prepare to write to s 0x7f045c033920
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4252:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4551:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4445:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection: data.buffer=0x7f044c0104fc, data.len=28
Dec 15 06:26:19 computer turnserver[1457714]: 49: session 002000000000000002: realm <my.domain> user <>: incoming packet message processed, error 401: Unauthorized
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4229:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection: prepare to write to s 0x7f044c0228e0
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4252:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4551:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4445:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection: data.buffer=0x7f045c0126bc, data.len=116
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4445:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection: data.buffer=0x7f045c0126bc, data.len=116
Dec 15 06:26:19 computer turnserver[1457714]: 49: IPv4. Local relay addr: 192.168.1.147:61846
Dec 15 06:26:19 computer turnserver[1457714]: 49: session 000000000000000003: new, realm=<my.domain>, username=<1639571480:turn-test-user>, lifetime=600
Dec 15 06:26:19 computer turnserver[1457714]: 49: session 000000000000000003: realm <my.domain> user <1639571480:turn-test-user>: incoming packet ALLOCATE processed, success
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4229:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection: prepare to write to s 0x7f045c033920
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4252:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4551:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4445:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection: data.buffer=0x7f044c0104fc, data.len=28
Dec 15 06:26:19 computer turnserver[1457714]: 49: session 002000000000000003: realm <my.domain> user <>: incoming packet message processed, error 401: Unauthorized
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4229:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection: prepare to write to s 0x7f044c022a50
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4252:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4551:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4445:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection: data.buffer=0x7f044c0104fc, data.len=116
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4445:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection: data.buffer=0x7f044c0104fc, data.len=116
Dec 15 06:26:19 computer turnserver[1457714]: 49: IPv4. Local relay addr: 192.168.1.147:64698
Dec 15 06:26:19 computer turnserver[1457714]: 49: session 002000000000000002: new, realm=<my.domain>, username=<1639571480:turn-test-user>, lifetime=600, cipher=ECDHE-ECDSA-AES256-GCM-SHA384, method=TLSv1.2
Dec 15 06:26:19 computer turnserver[1457714]: 49: session 002000000000000002: realm <my.domain> user <1639571480:turn-test-user>: incoming packet ALLOCATE processed, success
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4229:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection: prepare to write to s 0x7f044c0228e0
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4252:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4551:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4445:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection: data.buffer=0x7f044c0104fc, data.len=116
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4445:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection: data.buffer=0x7f044c0104fc, data.len=116
Dec 15 06:26:19 computer turnserver[1457714]: 49: IPv4. Local relay addr: 192.168.1.147:49184
Dec 15 06:26:19 computer turnserver[1457714]: 49: session 002000000000000003: new, realm=<my.domain>, username=<1639571480:turn-test-user>, lifetime=600, cipher=ECDHE-ECDSA-AES256-GCM-SHA384, method=TLSv1.2
Dec 15 06:26:19 computer turnserver[1457714]: 49: session 002000000000000003: realm <my.domain> user <1639571480:turn-test-user>: incoming packet ALLOCATE processed, success
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4229:start
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection: prepare to write to s 0x7f044c022a50
Dec 15 06:26:19 computer turnserver[1457714]: 49: write_client_connection:4252:end
Dec 15 06:26:19 computer turnserver[1457714]: 49: read_client_connection:4551:end

[JoshuaPettus]

I'm locked out of the whole thing for a bit :( It will be a few days before I can get that to you.

That said, I can confirm that coturn worked when I accessed it directly on it's port of 5349. Gave all the correct responses with turnutils_uclient. It's just when I access it at 443 through sslh that no connection ever reaches the actual coturn server. No response in output, nothing in the logs. Something in SSLH, or a service higher in the list, gave back the recv: Success

I noticed your config didn't attempt to put SSH into the mix, so I wonder if it's that.

I locked myself out messing with the sslh config file moving ssh to the bottom. (May have been a typo) Should have opened up another port for SSH, but wasn't thinking.

[iamdoubz]

Woops (done that before too!). I used to use ssh from work, but now I work from home full time so it was no longer necessary for me to open that up to the internet. I used to use the 5349 port, but never was able to get that port to work and besides, the standard port 3478 accepts both encrypted/non-encrypted traffic.

I also forgot to add what version of sslh are you running and what flavor? I am running sslh-ev v1.22c-50-g4e72800-dirty.

Once you get access back, make sure that you have syslog and Verbose in your /etc/turnserver.conf to be sure that lot's of logging is on, then post the contents of the command sudo journalctl -fu coturn while you try and connect via either "turnutils_uclient" or sending a test connect from Nextcloud.

[JoshuaPettus]

Well off the bat I can tell you I'm using sslh-select v1.22c that I had compiled (I made sure to turn on all the features in the make file including systemd). I had read about how the sslh-forking doesn't do UDP

[JoshuaPettus]

Good news, I got my system back up. I found where the typo was in the sslh.cfg file (left out a : in the config...) So it seems my guess for my main problem was right. Moving the SSH line to the bottom of the protocol list actually worked, and now coturn is getting the traffic. And thankfully SSH still works as with the other services.

So that fixes my sslh side of things.

Sorry to hijack this thread a bit @iamdoubz I was wondering if you had any advice my turnserver.cfg file. It seems it is mostly working, Connecting to two devices each behind the same NAT seems to work now. (Coudln't do that before without the TURN server). But when I connect to a conversation over my Cellphone's data, it doesn't connect.

I put some of the output on of my turnserver from my cellphone's connection here https://pastebin.com/diw8wn42

My ternserver.conf looks like this

1 #server-name=mydomain.com 2 realm=turn.mydomain.com 3 cert=/etc/letsencrypt/live/turn.mydomain.com/cert.pem 4 pkey=/etc/letsencrypt/live/turn.mydomain.com/privkey.pem 5 listening-port=5349 6 #tls-listening-port=5349 7 #listening-ip=192.168.2.2 8 external-ip=my-external-ip/192.168.2.1 9 fingerprint 10 use-auth-secret 11 static-auth-secret=#### 12 total-quota=0 13 bps-capacity=0 14 #stale-nonce 15 no-multicast-peers 16 #no-loopback-peers 17 #no-stun 18 no-tlsv1 19 no-tlsv1_1 20 #no-tlsv1_2 21 dh-file=/etc/turn/dhparams.pem 22 cipher-list="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5" 23 #no-stdout-log 24 log-file=/var/log/coturn/coturn.log 25 syslog 26 verbose 27

[iamdoubz]

@JoshuaPettus Congrats and re-Hello World!

Looking at your config, how are you running/starting turnserver? From a systemd service file? If so, are you running it as root?

[JoshuaPettus]

Thank you!

Yes it is a systemd service but, now that you mention it it is suppose to be running as turnserver but instead it is running as root. The user and group does exist on system... Weird..

1 [Unit] 2 Description=coTURN STUN/TURN Server 3 Documentation=man:coturn(1) man:turnadmin(1) man:turnserver(1) 4 After=network.target 5 6 [Service] 7 User=turnserver 8 Group=turnserver 9 Type=notify 10 ExecStart=/usr/bin/turnserver -c /etc/turnserver.conf --pidfile= 11 Restart=on-failure 12 InaccessibleDirectories=/home 13 PrivateTmp=yes 14 15 [Install] 16 WantedBy=multi-user.target

[iamdoubz]

If it is running as the user "turnserver", then it most assuredly does not have access to:

cert=/etc/letsencrypt/live/turn.pett.us/cert.pem
pkey=/etc/letsencrypt/live/turn.pett.us/privkey.pem

You could create a cronjob that runs ones a month to copy those two pem files to a directory that your "turnserver" can access (i.e. /etc/turn/). This is what I do for my certs sudo crontab -e:

# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command
### REQUIRED SERVICES ON BOOT
@reboot ip rule add from 127.0.0.1 lookup 100&&ip route add local 0.0.0.0/0 dev lo table 100
@reboot ip rule add from 127.0.0.1 lookup 100&&ip route add local 0.0.0.0/0 dev lo table 100
@reboot service coturn stop && service coturn start
### RENEW SSL CERTS
12 19 * * 1 certbot renew --post-hook "service apache2 reload" >> /var/log/le-renew.log
0 1 1 */2 * cp -f /etc/letsencrypt/live/my.domain/fullchain.pem /etc/turn/fullchain.pem && cp -f /etc/letsencrypt/live/my.domain/privkey.pem /etc/turn/privkey.pem && chown -R turnserver:turnserver /etc/turn && service coturn restart

Having a hard time with crontab? I use Crontab Guru to figure what the heck I'm typing in there.

[JoshuaPettus]

A better solution would be to just give turnserver access to the folder and certs via acls.

But I guess it doesn't matter. No matter what I do it seems to want to run as root... Anyway I know that bit is working or It would complain about it in the log.

[JoshuaPettus]

At this point, just looking at the output, I'm starting to think my mixed results has to do with the fact that I can't seem to get sslh in transparent proxy mode. The turnserver is identifying some devices as the internal port of the server. I have another thread for that.

[JoshuaPettus]

I'm glad I waited till after my transparent proxy issues were solved, because now things are worse off. Since I reported last I've changed my port to 3478 but for what ever reason the turnserver will not respond to any connection made from sslh. It does respond perfectly when I bypass sslh and connect to 3478 directly. And I think there are multiple issues going on here.

1. turns signals on tcp/udp doesn't connect at all but I get this from the sslh server output

onnecting to localhost:3478 family 2 len 16 **** writing deferred on fd -1 probing for openvpn probed for openvpn: PROBE_NEXT probing for openvpn probed for openvpn: PROBE_NEXT probing for tls matching [turn.joshpettus.com] with [turn.joshpettus.com] probed for tls: PROBE_MATCH closing fd 11 selecting... max_fd=21 num_probing=0 connecting to localhost:3478 family 2 len 16 socket closed connection closed down

It looks like it should connect but it doesn't

2. on any standard turn connection though tcp or udp i get

selecting... max_fd=21 num_probing=0 received 44 UDP from 19:myip:60789 sending 44 to 127.0.0.2:22 new_fd -1

or

connecting to 127.0.0.2:22 family 2 len 16 closing fd 10 selecting... max_fd=21 num_probing=0 connecting to 127.0.0.2:22 family 2 len 16

Somehow it's being captured by the ssh line at the end.

my sslh config now looks like this

1 # This is a basic configuration file that should provide 2 # sensible values for "standard" setup. 3 4 verbose: 1; 5 foreground: false; 6 inetd: false; 7 numeric: false; 8 transparent: true; 9 timeout: 5; 10 user: "sslh"; 11 pidfile: "/var/run/sslh.pid"; 12 chroot: "/var/empty"; 13 14 # Change hostname with your external address name. 15 listen: 16 ( 17 { host: "192.168.2.2"; port: "443"; is_udp: false }, 18 { host: "192.168.2.2"; port: "443"; is_udp: true }, 19 { host: "10.8.0.1"; port: "443"; is_udp: false }, 20 { host: "10.8.0.1"; port: "443"; is_udp: true } 21 ); 22 23 protocols: 24 ( 25 ### OpenVPN 26 { name: "openvpn"; host: "127.0.0.2"; port: "1194"; log_level: 0; }, 27 { name: "openvpn"; host: "127.0.0.2"; port: "1194"; sni_hostnames: [ "vpn.mydomain.com" ]; log_level: 0 }, 28 ### Coturn 29 { name: "tls"; host: "localhost"; port: "3478"; sni_hostnames: [ "turn.mydomain.com" ]; log_level: 0; fork: true; tfo_ok: true; }, 30 { name: "tls"; host: "localhost"; port: "3478"; alpn_protocols: [ "stun.turn", "stun.nat-discovery" ]; log_level: 0; fork: true; tfo_ok: true; }, 31 { name: "tls"; host: "localhost"; port: "3478"; sni_hostnames: [ "turn.mydomain.com" ]; log_level: 0; is_udp: true; tfo_ok: true; }, 32 { name: "tls"; host: "localhost"; port: "3478"; alpn_protocols: [ "stun.turn", "stun.nat-discovery" ]; log_level: 0; is_udp: true; tfo_ok: true; }, 33 ### TLS 34 { name: "tls"; host: "127.0.0.2"; port: "443"; alpn_protocols: [ "h2", "http/1.1", "http/1.2", "http/1.3", "h2c" ]; log_level: 0; fork: true; tfo_ok: true; }, 35 { name: "tls"; host: "127.0.0.2"; port: "443"; log_level: 0; tfo_ok: true; }, 36 ### SSH 37 { name: "ssh"; service: "ssh"; host: "127.0.0.2"; port: "22"; fork: true; } 38 39 # { name: "openvpn"; host: "127.0.0.2"; port: "1194"; }, 40 # { name: "xmpp"; host: "localhost"; port: "5222"; }, 41 # { name: "http"; host: "localhost"; port: "80"; }, 42 # { name: "tls"; host: "127.0.0.2"; port: "443"; log_level: 0; } 43 # { name: "anyprot"; host: "localhost"; port: "443"; } 44 );

and my turnserver.conf looks like

1 #server-name=mydomain.com 2 realm=turn.mydomain.com 3 cert=/etc/letsencrypt/live/turn.mydomain.com/cert.pem 4 pkey=/etc/letsencrypt/live/turn.mydomain.com/privkey.pem 5 listening-port=3478 6 min-port=10000 7 max-port=20000 8 #tls-listening-port=5349 9 listening-ip=tried localhost, tried my server's local ip, tried 127.0.0.1 nothing seems to work with sslh 10 external-ip=myip/192.168.2.1 11 fingerprint 12 use-auth-secret 13 static-auth-secret=mysecret 15 bps-capacity=0 16 #stale-nonce 17 no-multicast-peers 18 #no-loopback-peers 19 #no-stun 20 no-tlsv1 21 no-tlsv1_1 22 #no-tlsv1_2 23 dh-file=/etc/turn/dhparams.pem 24 cipher-list="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5" 25 #no-stdout-log 26 log-file=/var/log/coturn/coturn.log 27 syslog 28 verbose

[licaon-kter]

Can you try explicit IP instead of "localhost"? I bet your turn server listens to a certain IP... use that.

[JoshuaPettus]

@licaon-kter Sorry for the long delay in response. I have had a busy Christmas and haven't gotten around to to tackling this again. Good thought, and I originally had it that way though. I only use localhost because that is what @iamdoubz had and it worked for him. It seems to me sslh-select isn't capturing the packets for coturn correctly. Though I'm not sure why. I'll see if I can get some sslh output on what's going on when I can find the time.

[iamdoubz]

And sorry to beat this issue, but you are certain that the packets being sent to coturn are in fact encrypted?

[JoshuaPettus]

@iamdoubz Yes they are, the output from my turnserver says:

: : Domain name: 0: : Default realm: turn.mydomain.com 0: : CONFIGURATION ALERT: You specified --lt-cred-mech and --use-auth-secret in the same time. Be aware that you could not mix the username/password and the shared secret based auth methods. Shared secret overrides username/password based auth method. Check your configuration! 0: : ERROR: CONFIG ERROR: Empty cli-password, and so telnet cli interface is disabled! Please set a non empty cli-password! 0: : SSL23: Certificate file found: /etc/letsencrypt/live/turn.mydomain.com/cert.pem 0: : SSL23: Private key file found: /etc/letsencrypt/live/turn.mydomain.com/privkey.pem 0: : TLS1.2: Certificate file found: /etc/letsencrypt/live/turn.mydomain.com/cert.pem 0: : TLS1.2: Private key file found: /etc/letsencrypt/live/turn.mydomain.com/privkey.pem 0: : TLS cipher suite: ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5 0: : DTLS: Certificate file found: /etc/letsencrypt/live/turn.mydomain.com/cert.pem 0: : DTLS: Private key file found: /etc/letsencrypt/live/turn.mydomain.com/privkey.pem 0: : DTLS1.2: Certificate file found: /etc/letsencrypt/live/turn.mydomain.com/cert.pem 0: : DTLS1.2: Private key file found: /etc/letsencrypt/live/turn.mydomain.com/privkey.pem 0: : DTLS cipher suite: ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5 0: : Relay address to use: 127.0.0.2

Actually I just made some positive steps! @licaon-kter was right. It really wasn't liking localhost. I changed the listening-ip to 127.0.0.2 and the sslh.conf to route to 127.0.0.2. And that actually got the turnserver to respond!

I then noticed in the sslh output that non encrypted traffic (standard turn) was being sent to my ssh rule instead. I took a look at the config you posted in another thread and realized I had missed an important rule

{ name: "anyprot"; host: "localhost"; port: "5349"; sni_hostnames: [ "turn.my.domain" ]; log_level: 0; fork: true; tfo_ok: true; },

So I put that in on the bottom (changing the host to 127.0.0.2) then in the turnserver.conf uncommented the tls-listening-port=5349 (I think it was doing that by default anyway) and now turnserver responds to both turn and turns, udp and tcp, only for some reason it's dropping the connection once it gets going and not returning ICE candidates. At this point I'll go through my turnserver configuration as that is where it's looking like the problem is now

[JoshuaPettus]

Got it!

I listened to some bad advice on some forum, external ip should just be the external ip. not external / local So it looks like it is working now!

Oh and I modified the port on your line { name: "anyprot"; host: "localhost"; port: "5349"; sni_hostnames: [ "turn.my.domain" ]; log_level: 0; fork: true; tfo_ok: true; }, to also be 3478, because why not keep it the same?

Thanks guys!

[JoshuaPettus]

Oh for the record, to make it work fully, I had to add to the config for coturn: allow-loopback-peers. Then coturn complained that I had to add a cli password. so I chose to just disable cli altogether no-cli In certain situations it would still see traffic coming from 127.0.0.2