Unable to establish TURN connectivity on 443 via corporate firewalls

Hi,

I’ve self-hosted a Jitsi server via Quick Install instructions and then set up another instance with Coturn serving turns at 443. I then configured Prosody to publish this new server address by configuring turncredentials in Prosody config (I’m using 0.11 from Prosody’s Debian repo).

I have configured Jitsi Meet’s config.js to useStunTurn for P2P as well as Videobridge and set useTurnUdp=false. Also removed stun server list from config.js to force using turns via Prosody’s XEP-0215 via mod_turncredentials. I referred to https://meet.jit.si/config.js for these settings.

This has helped bypass almost every corporate firewall among my clients. However, very few clients are facing issues wherein they are able to access my Jitsi server but unable to establish p2p connectivity and thus unable to participate in calls. They get kicked out with a CONFERENCE FAILED: ICE Failed error in the logs.

I have observed that it typically happens when the TURN server is unreachable at its specified port. I understand that a lot of firewalls would restrict UDP traffic and/or non-standard ports. But in my case, TURN is set with turns (TCP) traffic on 443, so ideally it should work.

Has someone else encountered this issue? Is there something more that needs to be done, to let corporate clients establish ICE through their firewalls? Whitelisting may not be possible in every case. I’m looking for something that I can change in my setup to make this happen.

@damencho @saghul Requesting attention.

I know this is a beaten topic on the forum, and every post has benefited me in configuring my deployments. But there are these last bits remaining.

Also, do you think it would be useful to have a network diagnostics check introduced on the device settings screen? The one that’s present on the home page, where one can check camera and mic settings before joining or initiating a call? Something like https://remo.co/mic-cam-test/.

my best guess is that the the firewall (or antivirus) is doing some ssl inspection or ids/ips. It’s likely seeing that the traffic is not https, and then denying/dropping it.

Thanks for your response.

I just updated my setup with the latest Debian packages and found that Coturn is now being multiplexed via Nginx on port 443. Thus, with appropriate changes to the configuration, we no longer need a separate TURN server running on port 443.

I’m yet to test it against my client’s firewall. Do you think this would make the firewall see all turns connections as legit SSL connections as they are also being served via Nginx now?

That should already be the case when using turns tcp on port 443. Make sure your certs have the full chain.

Thanks @damencho. I’m generating my certs with certbot and using those generated certificates. Not having fullchain at the moment.

I recently saw this post by @emrah and I am going to update my certs to include fullchain. Also, multiplexing with ALPN did not work for some clients whose firewalls were being the MITM, downgrading connections, and stripping ALPN values. I’ll test switching to turndomain instead, as documented by @emrah and come back with my findings.

Thanks so much to this wonderful community!

Update

We just tested a single-server setup with Jitsi and Coturn multiplexed via Nginx and using ssl_preread_server_name instead of ssl_preread_alpn_protocols. I also set Coturn with fullchain.pem and verified it via openssl s_clients -showcerts against my TURN server domain. The server returned full chain of Let’s Encrypt certificate for my TURN domain.

Here’s what we observed:

  1. The client’s machine could access my Jitsi domain and even initiate/participate in calls but wasn’t able to establish TURN connectivity. Eventually, ICE failed and the client was kicked out.
  2. When we opened https://< turndomain > on our machine, Chrome responded with an ERR_EMPTY_RESPONSE and also showed insecure content warning (screenshot attached), but TURN relay worked fine.
  3. When the client tried opening https://< turndomain > on their Chrome browser, their browser showed their firewall message that said the server was unreachable.

What else are we possibly missing here?

@damencho @emrah