Hello Forums,
I’m interested in testing Jitsi Meet from our small office. But some of our workstations are locked down form Internet access. I’m attempting to add a firewall rule to allow access. Pinging meet.jit.si I get the IP: 13.248.156.98. Do I need just port 443 opened to this IP to allow for video conferencing and screenshare through Jitsi Meet?
Are there any other ports I need to have opened and any other IP’s?
Thank you in advance for any help you can provide me.
That will not work, as that ip rotates. You need to also allow all traffic to udp 10000, these are the videobridges which also rotate.
Thanks very much @damencho for this reply. I’ve done a bit more research and found I can allow access to host meet.jit.si in my firewall rule for port 443. This should cover the ip rotation.
Would the same hostname be used for port 10000/UDP?
Thank you.
Nope all ip addresses for web and bridges rotate.
@
But wouldn’t using host meet.jit.si cover all rotating IP addresses?
Nope, behind meet.jit.si are the addresses you will use for signalling, but bridges come as an ip-address later from jicofo signalling.
Is there a hostname I can use in my firewall rules to cover the IP addresses that could be used from jicofo signaling or bridge?
I can’t be the first person asking for the hostname and ports to allow through a firewall when using jitsi? 
Nope, sorry there is no such optionn for meet.jit.si. This is normally a requirement for corporate networks and this is available for 8x8.vc deployment.
I am also having problems with access for clients in various government offices currently.
As a solution for the OP I presume they would need a self-hosted version of Jitsi Meet to have a predictable IP address of Jicofo and the videobridge?
We currently have Jitsi installed on an AWS EC2 in every AWS global region, so we have a predictable list of domain names that are client browsers need access to. However, I’m still unsure what else our clients need to “allow” in their corporate firewalls.
I believe their browser would need to access my-london-jitsi.ourdomain.com:443, but is it still correct that it will also need to access port 10000 via UDP? I thought this was optional and it would cope if UDP wasn’t available? The handbook says that port 4443 will be used instead? And isn’t it any port in the range 10000 - 20000 for UDP?
What about port 4444? I’ve seen this port mentioned in the standard installation nginx configuration.
We have not edited the ports section in a while, I just did it.
So in the current stable default jitsi-meet install you will have jvb listening on port 10000 UDP(preferred for optimal quality) and coturn listening on port 3478 UDP and 5349 TCP. When UDP is blocked clients will try to connect to the standard turns port 5349 and reach jvb using that relay.
If you want you can run the coturn server on the same machine using a second domain and multiplexing by hostname and you will need a second DNS or you can have a different machine for coturn or second ip-address for it on the same machine so nginx will use 443 on one interface and coturn will use the same port on another interface.
Wow, thanks for the quick response. Thanks @damencho for updating the handbook. I think Google often takes us to parts of the forum which may be out of date, so the handbook is becoming even more important for up to date info.
So for the server I’ve obviously got full control over what ports to open up, so if I need to open up 3478 UDP and 5349 TCP for optimum configuration, that’s fine. I haven’t had to open up those ports before though? But our servers are on version 2.0.4857-1, and we generally don’t use Jitsi for any 1-on-1 calls so this might be why we haven’t had any issues. Or we’ve been lucky that the WebRTC has been able to perform without TURN. (Sidenote: If it can’t use WebRTC for a 1-on-1 call does it revert to communication via the JVB?)
Anyway, my main issue at the moment is that I have clients that can’t connect, and I think it’s because their firewalls (or suchlike) are not allowing communication with UDP port 10000 of the server. Should I recommend to their system administrators to ensure that all client browsers can connect to the following ports of our servers: TCP 443, 4443, 5349 and UDP 10000, 3478? Are these all essential?
Yes.
4443 is not used. UDP 10000 and TCP 443 are the main ones. 5349 will be used if 10000 is blocked or all udp is blocked, but media over TCP is not optimal.
Hi @damencho,
I found out from the client’s system architect that they are using a proxy server for all system-wide web-based traffic. He has offered to configure traffic for UDP 10000 differently on the network if Jitsi is not able to go via the proxy. But I would prefer a solution that doesn’t require him to have to do that, as I suspect the other organisation we are dealing with is having the same problem.
I got as far as this line in setting up the TURN server:
cp /usr/share/jitsi-meet-turnserver/coturn-certbot-deploy.sh $TURN_HOOK
but for my installation (which is quite recent… 2.0.5142-1) that jitsi-meet-turnserver directory does not exist?
I finally have this working.
I didn’t have jitsi-meet-turnserver installed (dpkg -l jitsi* showed “rc” next to it) so I installed that (sudo apt install -y jitsi-meet-turnserver) and was able to follow the rest of your instructions to grab letsencrypt certificates for it.
I still couldn’t connect to it so I went through the excellent detail provided by @randomguy here:
… to get a turn server working on TCP port 5349.
One thing that particularly held me back with this was a line in the /etc/turnserver.conf:
denied-peer-ip=172.16.0.0-172.31.255.255
I could see in sudo service coturn status that I was getting the error:
Oct 30 12:16:08 ip-172-31-20-155 turnserver[957]: 32: A peer IP 172.31.20.155 denied in the range: 172.16.0.0-172.31.255.255
(172.31.20.155 being the local/private IP of my instance)
I didn’t have the same issues as @randomguy as I am not using any guest/alternative domains.
Yep this solves a security issue. Basically the turnserver is denied to use any network class c, to avoid sending traffic to internal addresses. So it does not communicate with the bridge using the internal network.
What it does though is contacting jvb using the jvb public IP address and sending the media to port 10000 UDP as normal clients.
I think I understand. But I did have to comment out that line (# denied-peer-ip=172.16.0.0-172.31.255.255) in my /etc/turnserver.conf to get it to work. Was I incorrect to do that? I can’t see anywhere any configuration to direct traffic from coturn to the JVB. Where is that configured?
Also, in case it is useful for anyone else to aid testing, I changed this this in my /etc/nginx/modules-available/multiplex.conf…
upstream turn_backend {
server __public-ip__:5349;
}
to be…
upstream turn_backend {
server 127.0.0.1:5349;
}
…as I am currently running coturn on the same machine, and it meant I could disable port 5349 in the server firewall to check that Jitsi works without having access to that port.
Thank you for your help with this excellent product. I will go back to our clients with a videoconferencing service that works solely using TCP 443. I presume the tradeoff from not using UDP is degraded performance, or more load on the machine/network?
This is not configured.
Do you have the externIP setting in the turnconfig? In order this to work turnconfig to use the jvb external IP address to connect to it, you need a firewall rule making sure this is possible and that extern IP in turnconfig is not set.
It is more of degraded quality.
No, I don’t have an external IP set in the turnserver config. I just have the default turnserver config that seems to come with a fresh install of jitsi-meet. I did a fresh install today, set up the turnserver on port 443 and /etc/turnserver.conf now looks like this:
# jitsi-meet coturn config. Do not modify this line
use-auth-secret
keep-address-family
static-auth-secret=Onke0rYQMruOHoXU
realm=myjitsidomain.com
cert=/etc/coturn/certs/turn-myjitsidomain.com.fullchain.pem
pkey=/etc/coturn/certs/turn-myjitsidomain.com.privkey.pem
no-multicast-peers
no-cli
no-loopback-peers
no-tcp-relay
no-tcp
listening-port=3478
tls-listening-port=5349
no-tlsv1
no-tlsv1_1
# https://ssl-config.mozilla.org/#server=haproxy&version=2.1&config=intermediate&openssl=1.1.0g&guideline=5.4
cipher-list=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHA$
# jitsi-meet coturn relay disable config. Do not modify this line
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=100.64.0.0-100.127.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
# denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.0.0.0-192.0.0.255
denied-peer-ip=192.0.2.0-192.0.2.255
denied-peer-ip=192.88.99.0-192.88.99.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=198.18.0.0-198.19.255.255
denied-peer-ip=198.51.100.0-198.51.100.255
denied-peer-ip=203.0.113.0-203.0.113.255
denied-peer-ip=240.0.0.0-255.255.255.255
syslog
Note that I’ve commented out the denied 172.x.x.x IPs. That was the only direct change I had to make. The private IP address of the server is 172.31.2.147.
For all other configuration, I followed your Setting up TURN instructions linked above, except:
server 127.0.0.1:5349; in my nginx module as mentioned previously, andsudo nano /etc/jitsi/videobridge/sip-communicator.properties) as follows:org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=turn-myjitsidomain.com:443
sudo service jitsi-videobridge2 restart)I deleted UDP:10000 from the server security group and started a 3-way call to test.
I think this is not correct, as contacting the turnserver using localhost confuses it or the deny peer was playing a role, not sure where was the problem … but🐼 there is a reason to communicate using the public address.
If your jvb is in the same network as the stun/turnserver this is not correct.
This is also not correct. If the line is not commented denied-peer-ip=172.16.0.0-172.31.255.255 the turnserver will try to contact jvb on the public address udp port 10000 and if that is not allowed (when removed from security group) it will fail.
Maybe I should have clarified at the end of my last post, but it was all working with the configuration I described 
O[quote=“damencho, post:19, topic:73443”]
I think this is not correct, as contacting the turnserver using localhost confuses it or the deny peer was playing a role, not sure where was the problem … but🐼 there is a reason to communicate using the public address.
[/quote]
OK, I have changed this to be server __PUBLIC_IP__:5349. It’s all still fine.
In that case I don’t know what value I should have for STUN_MAPPING_HARVESTER_ADDRESSES? I can’t seem to find a good explainer for it. It was previously set to meet-jit-si-turnrelay.jitsi.net:443 so I thought changing it to my new turn server address turn-myjitsidomain:443 was a good fit.
OK, I’ve now enabled UDP:10000 in the security group and instead I’ve blocked communication to that port from my machine using the windows firewall. I still have problems if I uncomment that line; i.e. if I deny access to that 172.16.0.0/12 range, but it works otherwise.
Here’s the coturn log with censored values, demonstrating the error I get if access to 172.16.0.0/12 is denied:
Nov 03 13:28:12 ip-172-31-19-74 turnserver[24060]: 1302: session 006000000000000019: delete: realm=<turn-myjitsidomain.com>, username=<1604496407>
Nov 03 13:28:13 ip-172-31-19-74 turnserver[24060]: 1303: IPv4. tcp or tls connected to: __PUBLIC_IP__:46338
Nov 03 13:28:13 ip-172-31-19-74 turnserver[24060]: 1303: session 003000000000000023: realm <turn-myjitsidomain.com> user <>: incoming packet message processed, error 401: Unauthorized
Nov 03 13:28:14 ip-172-31-19-74 turnserver[24060]: 1304: IPv4. Local relay addr: 172.31.19.74:62947
Nov 03 13:28:14 ip-172-31-19-74 turnserver[24060]: 1304: session 003000000000000023: new, realm=<turn-myjitsidomain.com>, username=<1604496395>, lifetime=600, cipher=TLS_AES_256_GCM_SHA384, method=UNKNOWN
Nov 03 13:28:14 ip-172-31-19-74 turnserver[24060]: 1304: session 003000000000000023: realm <turn-myjitsidomain.com> user <1604496395>: incoming packet ALLOCATE processed, success
Nov 03 13:28:14 ip-172-31-19-74 turnserver[24060]: 1304: A peer IP 172.31.19.74 denied in the range: 172.16.0.0-172.31.255.255
Nov 03 13:28:14 ip-172-31-19-74 turnserver[24060]: 1304: session 003000000000000023: realm <turn-myjitsidomain.com> user <1604496395>: incoming packet CREATE_PERMISSION processed, error 403: Forbidden IP
Nov 03 13:28:14 ip-172-31-19-74 turnserver[24060]: 1304: session 003000000000000023: realm <turn-myjitsidomain.com> user <1604496395>: incoming packet message processed, error 403: Forbidden IP
Nov 03 13:28:15 ip-172-31-19-74 turnserver[24060]: 1305: IPv4. tcp or tls connected to: __PUBLIC_IP__:46342
and here’s my log when I comment out the denied-peer-ip=172.16… line and all appears to be working:
Nov 03 13:41:44 ip-172-31-19-74 turnserver[24507]: 674: session 000000000000000002: usage: realm=<turn-myjitsidomain.com>, username=<1604497269>, rp=1297, rb=1121581, sp=751, sb=510352
Nov 03 13:41:46 ip-172-31-19-74 turnserver[24507]: 676: session 004000000000000002: usage: realm=<turn-myjitsidomain.com>, username=<1604497198>, rp=1091, rb=805099, sp=957, sb=698004
Nov 03 13:41:48 ip-172-31-19-74 turnserver[24507]: 678: session 000000000000000002: usage: realm=<turn-myjitsidomain.com>, username=<1604497269>, rp=1090, rb=805753, sp=958, sb=706508
Nov 03 13:41:51 ip-172-31-19-74 turnserver[24507]: 680: session 004000000000000002: usage: realm=<turn-myjitsidomain.com>, username=<1604497198>, rp=1064, rb=752886, sp=984, sb=696732
Nov 03 13:41:51 ip-172-31-19-74 turnserver[24507]: 681: IPv4. tcp or tls connected to: __PUBLIC_IP__:47410
Nov 03 13:41:51 ip-172-31-19-74 turnserver[24507]: 681: session 004000000000000004: realm <turn-myjitsidomain.com> user <>: incoming packet message processed, error 401: Unauthorized
Nov 03 13:41:52 ip-172-31-19-74 turnserver[24507]: 681: IPv4. Local relay addr: 172.31.19.74:64551
Nov 03 13:41:52 ip-172-31-19-74 turnserver[24507]: 681: session 004000000000000004: new, realm=<turn-myjitsidomain.com>, username=<1604497269>, lifetime=600, cipher=TLS_AES_256_GCM_SHA384, method=UNKNOWN
Nov 03 13:41:52 ip-172-31-19-74 turnserver[24507]: 681: session 004000000000000004: realm <turn-myjitsidomain.com> user <1604497269>: incoming packet ALLOCATE processed, success
Nov 03 13:41:53 ip-172-31-19-74 turnserver[24507]: 682: IPv4. tcp or tls connected to: __PUBLIC_IP__:47430
Many thanks for your advice