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