Corporate firewall blocks UDP/10000


I’ve installed Jitsi meet following the guidelines on the quick-install for ubuntu 18.04 today, the 16th.

We’ve tested the system and it seems to work splendidly for us where there’s no firewall or issues connecting to it.

Unfortunately one of our clients seems to be behind a strict corporate firewall which seems to be blocking the UDP connections to 10000, at least so far that’s our assumption based on the following logs appearing when they connect:
2020-04-16 17:33:27.521 INFO: [52] [confId=5c99a07b5e058c87 gid=ff9ec7 stats_id=Kennith-0t7 conf_name=meeting ufrag=4pnlq1e620qsn3 epId=052079aa local_ufrag=4pnlq1e620qsn3] ConnectivityCheckClient$ Pair failed: -> (stream-052079aa.RTP)

The result is that they can’t see any video or audio from us, and we can’t see them either.

When trying the same on it all works flawlessly.

How can I get that same experience from our install? So far I have not changed anything as I was unable to find a targeted post that seems to properly document what to do in this scenario.


Are you using valid certificates?
Also is your nginx using some other virtual hosts listening on 443?
If not, you should be having turnserver installed and tcp media coming on port 443 and being multiplexed by nginx forwarded to coturn.

Hey Damian,

I’ve followed the quick-install documentation and generated the certificate using the command provided.

I’ve just read through the script and checked the configs it modifies, it seems that both the NGINX server it installed and the coturn have the correct certificates. (Should I check anything else?)

I’ve not added any additional virtual hosts or made any changes to the NGINX or coturn configuration so far.

The box it’s on has been rebooted a couple of times since the install already, so I expect any functionality issues as a result of a service needing a reload is taken care of.

I’ve checked the log files so far, the only thing that stands out to me (though I can provide all of them if you wish to take a look directly), is on the NGINX error log, showing:

2020/04/17 06:56:44 [error] 1161#1161: *5274 recv() failed (104: Connection reset by peer) while proxying and reading from upstream, client:, server:, upstream: “”, bytes from/to client:255/3621, bytes from/to upstream:3621/615

The odd bit here is that it only shows occasionally and not during my tests that show the call not working, if I telnet to the above location the connection establishes correctly, if I curl I get a reset, so perhaps this is random external bots hitting it by accident with HTTP?

Let me know what the next steps are for this, I’m happy to provide any logs/change any config file to see this issue resolved.

testing connections to https port should be done with a ssl tool like openssl (openssl s_client), not telnet.
Also is your corporatey thing doing deep packet inspection by any chance ? It’s known that it should be avoided on https port but somehow it’s still done.


I was unaware that endpoint was TLS enabled, if I run openssl s_client -showcerts -connect I get the correct certificates back and the connection seems to work also.

As I mentioned earlier, these errors being thrown by NGINX don’t reliably show up when I’m doing a test that shows the original problem, they seem more sporadic, which is a bit odd.

The client seems to be behind your typical outbound corporate firewall that blocks things their IT doesn’t know about, so UDP/10000 is being blocked there, but the rest of the site/functionality is perfectly accessible, they might have some further proxying, but to my knowledge, this doesn’t seem to interfere with it.

Further to that, I’ve been simulating it locally as well, by simply using a local firewall rule that prevents my browser from communicating on UDP/10000, and the results are identical, where the call can’t establish video or audio at all, so I’d like to take this one step at a time and get it working on here, then see if there’s any other issues that crop up on their devices.

Just adding to this conversation I have tried installing two clean instances of Jitsi today and neither have setup the TURN server correctly.

I am a colleague of Marco and have validated this with the test used (blocking port 10000 UDP). I’ve left the instances up at the following domains so that if you want to test anything against them you can:

Installed using the Digital Ocean Marketplace setup:

Installed using the Quick Install info on the GitHub:

During setup log messages did show the server installing and starting.

Screenshot 2020-04-20 11.00.57


I’ve attached the logs from coturn to this post, it looks like there might be some issues here.

I’ve noticed we’re not the only ones with similar issues, I found the following thread, however the resolution proposed there does not seem to work for us: UDP port 10000 blocked behind corporate firewall - possible approaches

Still a little confused as our understanding is that the quick install should work without any trouble. :confused:

logs.txt (7.4 KB)

1 Like

@damencho Do you have any further suggestions/ideas for this?

It looks like the default installer is broken somehow, but I haven’t been able to track down what the cause is, despite spending multiple days trying to reverse engineer and debug this system. :disappointed:

Hey @damencho - I’ve done some more poking, but so far no luck still, even with the latest update.

Any suggestions?

I’m having the same issue and there seems like there should be a tutorial for how to configure jitsi and jitsi-turnserver behind a corporate firewall.

The main point of jitsi is to have more than 2 participants and currently it doesn’t work like that.

Many others have the same issue with no simple resolution.

1 Like