UDP port 10000 blocked behind corporate firewall - possible approaches

Hi,
I’m setting up a jitsi instance for access behind a corporate firewall. Port 10000 UDP is blocked there, so a user can access a room but has no audio video.

I see two approaches:

  1. Moving UDP traffic from 10000 to 443. For this, videobridge and nginx would run on different machines, so nginx would not occupy port 443 for videobridge

Does anyone had the same issue or has experience with that setup?

  1. Using a TURN-server as relay
    Does anyone has managed to get coturn working with jitsi? Or another TURN-Server?

Any help would be appreciated
thanks!

If you install lastes jitsi-meet on a clean environment you will get nginx with coturn. Recommended way of dealing with those kind of firewalls is using the turnserver, but mind that it will use TCP and quality will suffer.
It will have nginx fronting tcp traffic on 443 port and multiplexing web and media traffic.

1 Like

Does this mean that with the version from today there is no more conflict between nginx and jvb on port 443? As you know most of the corporates are blocking not only udp/10000 but also the fallback option tcp/4443.

Yes, but we found few bugs in the package hours after releasing the stable :frowning: probably will push new versions tomorrow, sorry about that.
There is no conflict, jvb2 uses just 10000 udp, where only nginx uses 443 and recognises web traffic and serves the web and the rest forwards to the turn server.

thanks for the great work.
Hopefully the new release enables the scenario where nginx uses 443 and handles web and media (tcp) traffic.
Currently, with the latest release it is not possible to do a fresh ubuntu/debian install with coexisting nginx and coturn.

thank you for this explanation, I didn’t know that the new stable release directly installs nginx, I always installed nginx before installing jitsi

I tried to use the (co)turn server, I enabled useStunTurn 2x in the config (1x for p2p and 1x for general) but I didn’t succeed in getting Audio/Video to the clients. Webrtc-Internals says that the traffic should go over turn:
{ iceServers: [turns:meet.mydomain.com:443?transport=tcp]

probably this is because of the bugs you mentioned?

As a workaround, I tried to forward the traffic to my own coturn server, but had no luck. I did the following steps:

  1. setting UseStunTurn to True (2x)

  2. Setting up my own coturn server according to the conf-file in /blob/master/doc/debian/jitsi-meet-turn/turnserver.conf

  3. adjust the parameters for my turn-server in prosody (in the meet.mydomain.com cfg.lua, not in the general cfg.lua)

  4. restarting all services (including coturn on the other server after changing coturn-config)

Unfortunately it doesn’t work, no Audio, Video.
Js-Console has the following error:
[modules/RTC/BridgeChannel.js] <e.value>: Bridge Channel send: no opened channel.

Do you have an idea of the error causing this problem?
Thanks for the support and the very good work on jitsi!

update:
I’ve managed to get coturn working along jitsi on the same server. In my test scenario at home, everything works fine, if I block udp10000 on my firewall the traffic goes via TURN server, Audio/Video passes even with more than 3 participants.

I tested it behind the coporate firewall - The user can access the room but no audio/video passes. The firewall policy seems to be very strict.
Does anyone has an idea how to get that working?

Interesting: Whereby (Uses TURN and only port443 is needed - as cited on their website) works without problems

Would be great if someone has an idea of a workaround

Is opening port 3478 still required? I see it in ufw rules.

I also have the same problem, everything works fine (with 2, 3 and more than 3 participants) except when someone tries to connect behind a corporate (protected) network, this user can join the room, but no audio/video.
And the user sees and hears himself but not us.

Any help is welcome, thank you.

@Dragan what is your setup? Do you have a running turnserver?

I try to set up turnserver from one of your instructions, in sub.domain.cfg.lua, I set:

turncredentials = {
{ type = “stun”, host = “sub.domain”, port = “443” },
{ type = “turn”, host = “sub.domain”, port = “443”, transport = “udp” },
{ type = “turns”, host = “sub.domain”, port = “443”, transport = “tcp” }
};

cross_domain_bosh = false;

In sub.domain.config.js I put useStunTurn: true,

Turnserver is on the same subdomain and the same server as videobridge and other jitsi apps.

Is that correct setup?

is your turnserver up and running?
do you see turn in webrtc-internals?

not sure exactly how to check it?

I found this in webrtc-internals:

https://sub.domain/test, { iceServers: [stun:stun.l.google.com:19302, stun:stun1.l.google.com:19302, stun:stun2.l.google.com:19302], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: “plan-b” }, {advanced: [{googHighStartBitrate: {exact: 0}}, {googPayloadPadding: {exact: true}}, {googScreencastMinBitrate: {exact: 100}}, {googCpuOveruseDetection: {exact: true}}, {googCpuOveruseEncodeUsage: {exact: true}}, {googCpuUnderuseThreshold: {exact: 55}}, {googCpuOveruseThreshold: {exact: 85}}]}

Did you install a TURN-server? It is not automatically installed with jitsi per default.

in case you installed coturn, you can check the status with “service coturn status” and then you see if it is running

Thanks.

> "I did not install the coturn server.
*> *
> Is it good to install it on the same server or on separate ones?
*> *
> I read somewhere that it is good that coturn server is on port 443, but on this server jitsi and videobridge already use port 443?"

I installed dedicated coturn server on coturn.domain port 443

When I run “service coturn status”, I get active run, everything works fine.

I set the settings for server:

  • lt-cred-mech

  • use-auth-secret

  • static-auth-secret=SomeSecretSharedBetweenProsodyAnbCoturn

  • realm=coturn.domain

  • listening-port=443

  • cert=some_valid_cert.crt

  • pkey=some_valid_cert.key

In prosody I have installed module mod_turncredentials.lua

And in domain.cfg.lua I set:

turncredentials_secret = “secret”;

turncredentials = {

{ type = “stun”, host = “coturn.domain”, port = “443” },

{ type = “turn”, host = “coturn.domain”, port = “443”, transport = “udp” },

{ type = “turns”, host = “coturn.domain”, port = “443”, transport = “tcp” }

};

I still don’t see my turn server in webrtc-internals.

What about the module turncredentials is it loaded? Are you using secure-domain to request username and password for your deployment? If that is the case, make sure you enable the module and under the guest domain.

Thanks,
that’s it.

I put turncredentials in to guest virtual host, and it works now.

https://domain/test, { iceServers: [turns:coturn.domain:443?transport=tcp], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: “plan-b” }, {advanced: [{googHighStartBitrate: {exact: 0}}, {googPayloadPadding: {exact: true}}, {googScreencastMinBitrate: {exact: 100}}, {googCpuOveruseDetection: {exact: true}}, {googCpuOveruseEncodeUsage: {exact: true}}, {googCpuUnderuseThreshold: {exact: 55}}, {googCpuOveruseThreshold: {exact: 85}}]}

Thank you very much

I have to pick this issue up again.

We have the same problem here: everything works fine except with guests who want to join behind a corporate firewall (only TCP 80/443 outgoing is allowed).

We are running the latest stable version of jitsi-meet and use a simple default installation (everything on one server: meet, jvb, nginx, turnserver). We also use secure domains and added the turncredentials modules to the guest virtual host in the prosody configuration.

chrome://webrtc-internals on the client behind the firewall looks fine (as far as I can tell)

https://host.domain.tld/room, { iceServers: [turns:host.domain.tld:443?transport=tcp], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: "plan-b" }, {advanced: [{googHighStartBitrate: {exact: 0}}, {googPayloadPadding: {exact: true}}, {googScreencastMinBitrate: {exact: 100}}, {googCpuOveruseDetection: {exact: true}}, {googCpuOveruseEncodeUsage: {exact: true}}, {googCpuUnderuseThreshold: {exact: 55}}, {googCpuOveruseThreshold: {exact: 85}}]}

Nevertheless there is no audio/video from the guest.

Check turrnserver logs did it correctly loaded the certificates?
Have you tried with those clients to use meet.jit.si does it work?