Jitsi and Coturn both behind NAT

Hello Community!

I have a pretty complex setup due to limitations of public IP Addresses:
I have a Firewall Appliance to protect my company network.
Both, Jitsi-Meet and Coturn are installed behind that Firewall on 2 different virtual machines.
I share the Coturn Server with a running Nextcloud/Talk instance, which is working perfectly.
I simply had to configure my coturn server’s IP Address (the Public IP Address, that is mapped on the firewall to the local IP Address) instance, and “off we go”. I could monitor the turnserver traffic in the coturn server logfile.

How ever I am not able to get Jitsi-Meet to work with that coturn server. In fact, when I establish a 2 or more conference, all traffic is sent through port 10000 on my firewall.
This will work for many cases except for those, when port 10000 is blocked outgoing on the guest’s firewall.
I don’t see any client-traffic (nor within the LAN nor external guests) ever contact or route it’s traffic through the coturn server.

Here’s my topology (IP Addresses are altered for security):

Public IP: 11.22.33.44
LAN Network: 192.168.0.0/24
Coturn Server: 192.168.0.101
Jitsi-Meet Server : 192.168.0.194

My Coturn Server is available to the Internet on Port 80 (tls-listening-port)
My Jitsi-Meet Server is not directly natted thorough the firewall to it’s LAN Address.
As I have some other Webservices like Webmail, but only 1 available external IP Address, the Webtraffic (nginx) from jitsi-meet is proxied via an apache2 Server that runs on port 443 on the same Server as the Coturn runs.

My Firewall’s NAT config is approx. like this: TCP443, TCP/UDP80 are mapped to the Coturn’s LAN Address, UDP10000 is mapped to Jitsi-Meet’s LAN Address.

My prosody config (relevant parts):
turncredentials_secret = “my-super-secret”;
turncredentials_port = 80;
turncredentials_ttl = 86400;
turncredentials = {
{ type = “stun”, host = “11.22.33.44”, port = “80” },
{ type = “turn”, host = “11.22.33.44”, port = “80”, transport = “udp” },
{ type = “turns”, host = “11.22.33.44”, port = “80”, transport = “tcp” }
};

In jitsi/meet/meet*****.config.js I have set
useStunTurn: true; (global and in p2p)
and under p2p I have
stunServers: [
{ urls: ‘stun:11.22.33.44:80’}
],

In jitsi/videobridge/sip-communicator.properties I have set:
org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true

Most of the tutorials recommend to use
#org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=stun:meet-jit-si-turnrelay.jitsi.net:443
or using the own coturn instance. But as long as I use this setting, I don’t get any connection at all.

So I played around with various settings.
Disabled STUN_MAPPING_HARVESTER_ADDRESS and enabling

org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=11.22.33.44
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.168.0.194

finally got me a working conference - how ever - not using my coturn server!

Conclusion:
From this configuration I would expect Jitsi-Meet to fall back to my coturn server, as soon as no communication through UDP/10000 is impossible.
Instead I suffer from no Audio/Video - which makes perfectly sense to me, as no p2p connection can’t be established.

So my question is: What am I doing wrong? How do I literaly force jitsi-meet to mandatory route traffic through my coturn server?

any help is appreciated!
regards,
Felix

We had seen reports that webrtc is not able to use port 80 for turnserver, it was a year or two ago, but maybe that is the case, try running it on some other port. Try 5349.

Hi!
Yes, I could do that, but then again, strict firewalls which filter outgoing traffic would prevent a connection, so it would be the same problem as with UDP10000.
Nextcloud/Talk is also WebRTC and is using the same Coturn server.
How ever, I will try your suggestion and return to you how it went.

For the time being: Can you please clarify for me: Which turnserver settings are advertised to the client:
Settings set in /etc/prosody/conf.d/meet****.cfg.lua or those
in /etc/jitsi/meet/meet****config.js

I’m missing out the “big picture” about how all the Jitsi-Meet parts are connected to!

thanks,
Felix

The prosody one. Those Are retrieved by the xmpp client and used when creating the peer connection.
The config.js one are used only for stun in p2p mode but those coming from prosody can also be used for those. So they all can be controlled from prosody

Thank you for clarifying that.
Meanwhile I was able to free up an other public IP-Address, which allowed me, to setup a dedicated virtual machine (behind nat) with coturn and route that second public IP Address to that virtual machine.
I am now running coturn tls-listening-port 443.
What I forgot to mention: Either running on Port 80 (prior) or now on Port 443 (each UDP and TCP) I was able to successfully test it via https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

My remaining question is still the same: If prosody should propagate turnserver-settings to the Client, why am I stuck with no Audio/Video for clients, that cannot connect via UDP/10000 ?
From what I understand, in case, a P2P connection via UDP/10000 cannot be established, the connection should get routed via the turnserver. How ever, I see no traffic on the turnserver from either connecting side.
BTW: I have double-checked IP Addresses/hostnames, Turncredential settings in prosody. They are accurate.
Is there an way I can debug this issue any further?

regards,
Felix

I debugged the issue now with about:webrtc (in Firefox).
It seams to me, as if prosody is not sending turnserver properties to the client.
I only see entries in the table “external candidates” like this: 11.22.33.44:10000/udp(srflx) whereas I would expect (due to the new external IP Address and Port-change) 11.22.33.55:443/udp/srflx.
Any suggestion appreciated!
regards,
Felix

@thesuliban1980 did you manage to resolve your issue ? I am actually facing a simlar issue and I am running my coturn server on port 443, but I am never seeing my turn server IP in the candidates.
What settings do you have in videobridge/sip-communicator.properties ?

Continuing the discussion from Jitsi and Coturn both behind NAT:

Hi Bakie,
no, unfortunately, I ended up on opening udp/10000 on the perimeter firewall and added some nat rules so that udp/10000 traffic can flow… but I am not happy with that solution. I am also wondering, that no one else (except for you) has that problem and that no maintainer/developer/poweradmin etc… can help…

But for now, I am happy, that it works, despite the fact, now, that it’s running productive, some disadvantages compared to other solutions like zoom, webex, etc… pop up such as:

  • you can’t schedule a meeting in advance and preconfigure it with a password or so…
  • You are forced to login as meeting-organizer 1st and set the password you have sent out to your meeting members…
  • and the lack of a waiting room also is annoying as every member simply pop’s in similar to when a physical conference is hosted in a room, unannounced the big wooden swing-doors open while people are coming in.

But I can live with all that, knowing, that the conference is self-hosted and there for more secure than zoom and webex ever will be!

So for now, if you find a solution for your/our problem, please share as I’d love to close the whole in my firewall and stick to standard ports such as 80 or 443!

regards,
Felix

Hello @thesuliban1980 I got a working TURN server using port 80/443. The setup and config is described in this post. You can compare it with your setup/config and give it a try.
If you have any questions about it, just ask it and I will try to help you :slight_smile:

1 Like