Some users disconnecting when accessing Jitsi behind Organisation Firewall

Hello all

I’m not sure if I am posting in the correct category so please correct me there if I’m wrong.

I’ve installed Jitsi meet and have successfully used it for my meetings with hundreds of different users. But there are some users accessing our Meet platform from their organisation, supposedly behind some corporate firewall that is causing them to immediately disconnect when they load Jitsi on their Chrome browser.

This isn’t an issue where 2 or more people get disconnected. My team (3 of us) are in the Jitsi meet room, and when 1 or more people from these organisations join the room, all of them get disconnected.

Me and my team, remain connected and can use Jitsi normally.

Has anyone else encountered this before and can you please share some potential solutions?

Thanks in advance!
Felix

Is there the same issue when they connect via Firefox?

Is your turnserver working? What is the output of the following command?

netstat -taunp | grep turnserver

As these are potential clients, it’s a little difficult for me to ask them to test with Firefox if there are other solutions to check this, I trust you understand!

Here’s what I get:

root@meet:~# netstat -taunp | grep turnserver
tcp 0 0 10.148.0.2:4445 0.0.0.0:* LISTEN 448/turnserver
tcp 0 0 127.0.0.1:4445 0.0.0.0:* LISTEN 448/turnserver
tcp 0 0 10.148.0.2:4445 0.0.0.0:* LISTEN 448/turnserver
tcp 0 0 127.0.0.1:4445 0.0.0.0:* LISTEN 448/turnserver
tcp6 0 0 ::1:4445 :::* LISTEN 448/turnserver
tcp6 0 0 ::1:4445 :::* LISTEN 448/turnserver
udp 0 0 10.148.0.2:4445 0.0.0.0:* 448/turnserver
udp 0 0 10.148.0.2:4445 0.0.0.0:* 448/turnserver
udp 0 0 127.0.0.1:4445 0.0.0.0:* 448/turnserver
udp 0 0 127.0.0.1:4445 0.0.0.0:* 448/turnserver
udp 0 0 10.148.0.2:4446 0.0.0.0:* 448/turnserver
udp 0 0 10.148.0.2:4446 0.0.0.0:* 448/turnserver
udp 0 0 127.0.0.1:4446 0.0.0.0:* 448/turnserver
udp 0 0 127.0.0.1:4446 0.0.0.0:* 448/turnserver
udp6 0 0 ::1:4445 :::* 448/turnserver
udp6 0 0 ::1:4445 :::* 448/turnserver
udp6 0 0 ::1:4446 :::* 448/turnserver
udp6 0 0 ::1:4446 :::* 448/turnserver

quite easy, these installations are typically blocking UDP/10000. So install a firewall on any computer and block output UDP/10000 it should reproduce the issue.

coturn works like this: nginx config in default jitsi sits in /etc/nginx/modules-enabled/60-jitsi-meet.conf; ALPS (stream) protocols listen on port 443 and dispatch TLS trafic labelled with http to nginx standard web processing (jitsi file serving and bosh/websocket signaling) on port 4444, and the rest (that is UDP/DTLS) to coturn on port 4445. Coturn then redirect it to jvb on port 10000/UDP. That’s the idea at least.
Al this has been bashed to death on this forum in many threads, although somehow it has never been documented either in the doc nor in the wiki.

Thanks.

So changing the UDP port would probably work, you think?

I know they allow WebEx and Zoom and I’ve checked that WebEx uses UDP port 9000 while Zoom uses a range of UDP ports 3478, 3479, 8801 - 8810

Is there a way we can open a range of UDP ports on Jitsi and on our server’s firewall to allow more people access?

I was really hoping that this was the solution. But I blocked port 10000 on UDP and was still able to access Jitsi meet on my server. Just to be sure my firewall was turned on, I changed the port to 443 TCP for the same rule, and I was immediately not able to load the page.

Screenshot 2020-07-06 at 6.42.45 PM

Does this mean the UDP port 10000 block isn’t the issue?

Oh wait… I think I spoke too soon…
The video was working fine for about a few seconds… then I got this message on the device with Port 10000 UDP blocked:

I disabled the rule, and after reconnecting this device did not get disconnected.

I wonder if changing the UDP port on Jitsi fixes this issue?

since typically such firewall will block all udp traffic, this will not bring you very far I’m afraid. Coturn allows people suffering from this kind of corporate disease to connect with port 443 that is never blocked. It’s of course slower.

So basically this tutorial?

When you say slower, do you mean significantly slower? Does it affect all users, or only users who have got their UDP ports blocked?

According to your output, your coturn server seems OK. When you block the UDP/10000, the newly opened clients should communicate. Maybe there is something wrong with the configuration or with the TURN traffic.

It didn’t - they just stayed for maybe 2-3 seconds then got disconnected as per my screenshot above

I have never seen a benchmark about this. Maybe because it affects only users behind such firewalls and in the usual case it’s a small minority. Also come to think of it, such users are likely to benefit from over average connectivity.

I see - thanks for raising these valid points!

Btw, @emrah above mentioned that it seems my coturn server seems OK. But from your posts, it seems I’m lacking a coturn server.

I’m now more confused than when I first posted :smiley:

I agree entirely that your coturn server is running. That it is effective is another thing. If you setup a web server and don’t plug the RJ45 to the router, it runs but no one can use it. For Jitsi-meet if you do a quick install it’s supposed to run out the box, but quick install assumes that you have a dedicated server with its own domain. If you have a more complex setup, it’s more difficult to setup correctly and you have to actually understand how it works.

Haha that’s a fair point.

I actually have this, and yes, I did the quick install as well. Again, everything works and I’ve had calls with over a hundred different people. Just these particular groups of people behind the corporate firewall frustrates me… but they’re the ones who will eventually pay the bills :frowning:

then it ‘should’ work. I’d advise to enable telnet - edit /etc/turnserver.conf to add cli-password=yourlongpassword
to /etc/turnserver.conf
systemctl restart coturn
telnet localhost 5766

then run pc to see if anything looks strange (listeners, ip, certificates) in the configuration.