Corporate FW, UDP/10000, TURN and all these things

Hi :slight_smile:

I have a general question regarding connectivity.

Our setup:

We work inside our LAN without direct internet connection. Everything regarding internet have to use a proxy server which is allowed to connect to the internet.

The proxy can proxy HTTP/80 and CONNECT/443 (TLS/HTTPS or any other connection using the CONNECT method).

And we have a DMZ. Inside this, all servers dont have the permission to talk directly to the internet. Again a proxy is used for this. DMZ has a own private IP subnet. So between DMZ and internet NAT is applied.

So - now we installed Jitsi. I learned, that Jitsi uses Port 80/443 for the jitsi-meet webinterface. JVB uses TCP/4443 and UDP/10000. I also learned, that UDP/10000 is preferred, because it actual is a UDP connection (less CPU usage).

We opened a direct port UDP/1000 from LAN -> DMZ and Internet -> DMZ. So we are able to use Jitsi from inside AND with external users together.

So far so good.

Now we got a mail from an external contact, behind a corporate firewall. Their FW does not allow direct internet connection, such as ours. It is not proxy-able, because it is UDP.

Now I searched for the real problem and a possible solution. I want to ask, if I undersood it the right way:

  1. We split jitsi-meet and JVB, so they are 2 seperate servers. Jitsi-Meet is accessible via meet.out-tld:443 over HTTPS. JVB will then be accessible via jvb.our.tld:443. So almost everything should be able to access the Meeting without any special ports need to be open.
  2. We use a TURN server, which is accessible over turn.our.tld:443 (TLS) and which is used by our JVB. As I have learned, TURN would act as a relay, so the Video is transferred via TURN and not directly between the two participants, right?

And this is the fallback to relay media to jvb when udp is not available. Enable turn in prosody and enable this: to be used for the jvb connection.

we have the same setup. would be great if you can share you’re config after successful verification :slight_smile:

What is about:

  • Not using Coturn
  • Separate JVB and nginx
  • Setup JVB to listen TCP/443


In this setup, the web-UI is on server 1, JVB on server 2 and everything listens on TCP/443 which is a commonly already open port behind other corporate FWs. How does the change to TCP would decrease performance?

Actually, when I use a Coturn relay, it would be the same decrease, since it uses TCP/443 as well, right?

Correct me, If Iam wrong.

EDIT: I just reading, that the new setup (with coturn) is per default configured to let nginx decide which traffic is for web-ui and which traffic should be passed to the coturn. So 443 Media traffic should work now out-of-the-box?

Can you edit this post to show the new line and what option needs enabled to allow port 10000 to go through the turn server?

Quick update:

I setup a dedicated coturn server with NO encyrption enabled. On port 443. Changed Prosody config and set the STUN_MAPPING directive from JVB to this Host.

Now it is working sporadically with FF, too. Chrome is just happy as ever. But the thing that FF works sometimes only makes me sad… In about:webrtc I can see that there are 5 pairs of candidates (Remember: I sit behind a NAT):

Note also that any PRIVATE marked Jitsi IP is not callable. I test from the direct internet and not from my LAN, where the Jitsi is setup (Port 10000/UDP blocked)!

ICE-Status Nominated Selected Local candidate External candidate
failed false false My local PC-IP/udp The PRIVATE Jitsi-IP
suceeded false false The private TURN-IP The PRIVATE Jits-IP
failed false false My local PC-IP/udp The public Jitsi IP
inprogress & failed true false The public IP for TRUN private Jitsi IP
failed false false The public TURN IP The public Jitsi IP

I dont really know hat is going on here… Sometimes Firefox can connect, sometime snot.

@damencho: Can I control the candiates sent to any participant?

I don’t think so.