Tag: nat

The nightmare that is NAT: Network Address Translation. We require TURN: Traversal Using Relays around NAT and STUN: Session Traversal Utilities for NAT. These servers facilitate the connections between clients, navigating around NAT, for voice and video communications*. In this implementation we assume the coturn server will be publicly routeable (have a public ip).

install coturn

apt-get install coturn

enable it

vi /etc/default/coturn
TURNSERVER_ENABLED=1

Fixup the turnserver config. I recommend using “/” to search through your config and uncomment the following items, this keeps your original config as close to stock as possible. It does have the downside of being a pain to read, see my grep trick below to help with that.

vi /etc/turnserver.conf

fingerprint
use-auth-secret
static-auth-secret=[some long password]
realm=example.com
total-quota=100
stale-nonce
cert=/etc/letsencrypt/live/example.com/cert.pem
pkey=/etc/letsencrypt/live/example.com/privkey.pem
syslog
no-multicast-peers
no-cli
no-rfc5780
no-stun-backward-compatibility
response-origin-only-with-rfc5780

Here is a description of each parameter at coturns github

grep out all the comments and whitespace so you can see what is enabled and confirm your config is correct

grep -v ^# /etc/turnserver.conf |grep .

Use letsencrypt with turnserver

We will use the same certs as we are using for Nextcloud. See my post on installing Nextcloud server.
The letsencrypt directory needs to be opened up for coturn to use it. The best way to do this is add turnserver to the group ssl-cert and then allow this group access to the certs. First fixup the group

usermod -a -G ssl-cert turnserver

Keep the owner as root and change the group to ssl-cert. Then change the group to have read and execute permissions.

chown root:ssl-cert /etc/letsencrypt/live/ /etc/letsencrypt/archive/

chmod g+rx /etc/letsencrypt/archive/ /etc/letsencrypt/live/

Additionally, the private key is only read and writeable by root as shown below.

#confirm perms are not ok
ls -l /etc/letsencrypt/archive/example.com/privkey1.pem
-rw------- 1 root root  241 Nov 22 17:49 privkey1.pem

Change owner (chown) and change mode (chmod) for the privkey1.pem. Future renewed keys will continue with these set permissions. So privkey2.pem will also have “-rw-r—– root ssl-cert”.

chown root:ssl-cert /etc/letsencrypt/archive/example.com/privkey1.pem

chmod g+r /etc/letsencrypt/archive/example.com/privkey1.pem

#confirm perms are good
ls -l /etc/letsencrypt/archive/example.com/privkey1.pem
-rw-r----- 1 root ssl-cert 241 Nov 22 17:49 privkey1.pem

Verify and test. Look through the log for coturn after a restart. Press “G” to go to the end of log and then scroll back up to see any errors from your last restart.

systemctl restart coturn
journalctl -u coturn

run the turnutils client against the server. This package is part of coturn
First test turn://

turnutils_uclient -p 3478 -W [static-auth-secret] -v -y example.com

and then turns:// (-S)

turnutils_uclient -p 3478 -W [static-auth-secret] -v -y example.com -S

The end of this connection should look like this:

8: : Total transmit time is 4
8: : Total lost packets 0 (0.000000%), total send dropped 0 (0.000000%)
8: : Average round trip delay 93.400000 ms; min = 88 ms, max = 104 ms
8: : Average jitter 3.700000 ms; min = 0 ms, max = 13 ms

Now we add this server to Nextcloud, under Administration Settings -> Talk
set STUN to “example.com:port”
set to TURN to “turn: and turns:” | “example.com” | “[static-auth-secret]” | “UDP and TCP”

Look for the green check mark to see that it works

* Here is a description of how TURN and STUN work from Nextclouds documentation

Talk tries to establish a direct peer-to-peer (P2P) connection, thus on connections beyond the local network (behind a NAT or router), clients do not only need to know each others public IP, but the participants local IPs as well. Processing this, is the job of a STUN server. As there is one preconfigured for Nextcloud Talk that is operated by Nextcloud GmbH, for this case nothing else needs to be done.

But in many cases, especially in combination with firewalls or symmetric NAT, a direct P2P connection is not possible, even with the help of a STUN server. For this a so called TURN server needs to be configured additionally.

Nextcloud Talk will try direct P2P in the first place, use STUN if needed and TURN as last resort fallback. Thus to be most flexible and guarantee functionality of your Nextcloud Talk instance in all possible connection cases, you would want to setup a TURN server.