Docker-jitsi-meet and firewalls

I’m documenting my tests for the ports that need to be opened for the jitsi configured with docker-jitsi-meet to work. The purpose is to understand configurations where participation in a videoconference could fail for the participants and why they fail.

Setup: I’m using docker-jitsi-meet modified to enable multiplexing as of the docs and turn (based mostly docker-jitsi-meet PR 667 but adding turncredentials and turncredentials_secret). I describe the setup for the multiplexing in this comment

I will only test simple firewall configurations (those that only block based on port number). What I’m doing to simulate participant firewalls is placing a firewall in front the server and blocking different sets of ports.

BASE CONFIGURATION

The initial configuration from which I start the tests is as follows:

Outbound ports (inbound for the client) Firewall only allows:
80 and 443 and 53 (dns)
Inbound ports (outbound for the client) Firewall only allows:
4443 (jvb rtp over tcp), 5339 (connect port for turn over both tcp and udp), 10_000 (jvb rtp over udp) and 16_000-17_000 (rtp for turn over udp).

With this setup the videoconferences work.

RESTRICTING FURTHER

When closing additional ports apart from those described in the base configuration, the results are:

Closing only 4443: The videoconference works
Closing all TURN ports 5349 tcp and udp and 16_000-17_000 udp: The videoconference works
Closing 4443, 5349 and 16_000-17_000: The videoconference works

Problems arise if I close 10_000 inbound (oubound for client), in that case the videoconference fails, this error shows in the browser console

[modules/RTC/BridgeChannel.js] <l._send>:  Bridge Channel send: no opened channel.
[conference.js] <te._onConferenceFailed>:  CONFERENCE FAILED: conference.iceFailed
[modules/RTC/BridgeChannel.js] <RTCDataChannel.e.onerror>:  Channel error: undefined

CONCLUSIONS

As far as I can see in this configuration the videoconferences work with no problem with:

Outbound ports (inbound for the client) Firewall only allow:
80, 443 and 53 (dns)
Inbound ports (outbound for the client) ports closed except
80, 443, 10_000

As far as I understand this is the most restrictive firewall configuration (taking into account ports only) under which jitsi can operate.

I wonder also whether it would be possible to configure jitsi so it would also work with 10_000 blocked both inbound and outbound by multiplexing on protocol instead of server name.

We have a setup where only port 80 & 443 are used (by using TURN) AND we have everything hosted on 1 and the same subdomain, in Kubernetes.

I will share something about this soon. I like the setup especially as it allows us to spin up individual shards of Jitsi installations on demand, using a wildcard DNS-01 certificate & wildcard DNS record.

The fact that your system fails to work if port 10_000 is closed might be because the clients are still using port 10000, and not TURN.

I had a hard time figuring this out, but in the end the problem was with the mod_turncredentials.lua & config.js, which in combination didn’t use TURN when doing non-p2p (regular).

Thank you very much for the feedback!

I’ll be trying different combinations of mod_turncredentials.lua turncredentials and config.js configurations over the weekend :slight_smile: . Do you remember the parameters of config.js that did it for you?

I’ve put up the mod turn that I use in a GitHub Gist, see below.

Also, I couldn’t get it working with the Jitsi Docker repo to overwrite the mod_turncredentials.lua of the image. So I used a different filename (‘mod_turn.lua’) and enabled ‘turn’ instead of ‘turncredentials’.

I tried with that configuration and some variations of it but it did not work. However I’ve managed to improve things by adding a letsencrypt certificate for the coturn. I now have different errors and the videoconference does not hang, only the video does not work.

I detailed this new setup and the problems I still have here Firewalls allowing only ports 80 and 443 with docker-jitsi-meet