Setting up firewall for TURN server



I’m having a hard time setting up TURN server for Talk app. So far I’ve been able to make calls to outside only when they are not running behind a NAT/firewall. In that case, I only see a black screen and no sound.

As this post lines out, you need to have a TURN server, which I’ve installed on the same server as Nextcloud (Ubuntu - Coturn).
I think I’ve set it up properly.
When using this command from outside stun I got the following output:

STUN client version 0.97
Primary: Independent Mapping, Independent Filter, preserves ports, no hairpin 
Return value is 0x000013

So I guess everything is up and running.

Here is my turnserver.conf:

external-ip=<my external-ip>

My network layout:


INTERNET-to-DMZ (GREEN): Port 3478 forwarded to NC-server
DMZ-to-LAN: (PURPLE): UDP source pourts 59000 - 59100 allowed to destination ports 40000 - 65535 (explanation: turn server is allowed to use ports 59000 - 59100 see turnserver.conf)
LAN-to-DMZ: (RED) Port 3478 allowed to NC-server
DMZ-to-INTERNET (YELLOW): UDP port 3478 allowed & UDP source pourts 59000 - 59100 allowed to destination ports 40000 - 65535

When I try to call to someone behind a NAT, my pc is trying to connect directly to my peer through a high UDP port (fi 63408) so hence my call is not coming through. No log in my turnserver, so I guess something else needs to be set up in order to use my turnserver for this kind of calls?
Could someone help me please? I don’t think I need to open up another high range of UDP ports from my Lan to internet?
Also, is it a good idea to set up this range for UDP from my DMZ to LAN & INTERNET (limited through source ports 59000 until 59100)?




You mean that is all content of the file or this is what you changed? I how latter is the case, since there are many other settings defined by default, which I would suggest to leave untouched (besides logging and TLS related, if required).

From what I leaned, at first always a direct P2P connection is attempted by Nextcloud Talk “clients”. If not possible, with STUN, then TURN as last resort. Obviously fallback to TURN in your case not work? How exactly did you configure it within Nextcloud admin settings?

Next is course would to checking coturn status carefully, but since you check the logs already, I guess all up and running without error?


This is my complete turnserver.conf file indeed (that is to say: I left everything that is commented out).
What other things would I need to leave in?

In NC admin settings I typed (notice: no https in front) andUDP & TCP and my secret
When connecting to someone behind a normal router, I have output in my turnserver log so I guess it’s working properly?

Does using TLS matter for this case? Now I’m not using it.


Open desired port in your firewall via NAT and run this script:

It looks like this:


Ah sorry, mixed it up with Redis server conf. Jep in turnserver.conf, everything is commented by default so yours should be fine.

However please try to comment external-ip. Setting any IP in the config caused issues during my tests. I think this is only required, if your TURN server is directly connected to www (not behind NAT) and/or the Nextcloud server is on a different local network.

For comparison, this works in my case (TURN server + Nextcloud on same machine behind NAT) with TLS enabled:

2018-12-07 20:33:22 root@micha:/var/log# grep '^[^#[:blank:]]' /etc/turnserver.conf


Sry for my late reply, I had other things I need to settle first.

Thanks for your suggestion; I’ve commented
external-ip, guess this is indeed for the case the TURN server is directly connected to the internet.
I’ll do a test with these new settings.

Another question regarding enabling TLS: I see you use a Letsencrypt certificate, do you need to renew this one every 90 days? Could you also use a self-signed certificate for this application?



Jep, letsencrypt certs need to be renewed every 90 days. With Debian/Raspbian package in my case, this is automatically done via systemd timer. You can also easily add a cron job, that e.g. runs certbot renew weekly, so no big deal.

If you anyway run Nextcloud, which you, I guess also want to access HTTPS, I strongly recommend to not use self-signed certificates anyway, since they can cause access issues with browsers and other clients, prompt warnings or deny access at all, since you are no trusted CA (certificate authority). And when the certificates are in place anyway, why not use them for coturn as well?
But coturn (and all clients I tested with) also run fine with a self-signed certificates.

The stronger (4096 bit) than default DH file also enhances security btw., but increases access delay of course. I just have this in place, since playing around with 100% result :wink:. Surely overkill, but speed doesn’t play a big role in my home server case.
cipher-list above is an old example that is just still mentioned in all found cuturn + Nextcloud Talk guides. But this is actually a bid weak. You can e.g. use a stronger list, e.g. based on: modern option, that matches the one for your webserver then. Test this with all your clients to assure they support it. E.g. old Android versions might not support the “modern” cipher. Oldest supported versions are also mentioned on the mozilla generator page.


Off course, I’m already usiing Letsencrypt for my https-certificate, didn’t think of that I can re-use this certifiate for TURN if I want (as your configuration describes). I think I’ll implement this in the beginning of next year, first see if it’s working now.