IP address will bypass restricted access

I configured my jitsi server to restrict access when creating a room. It worked fine when connecting to the server with the fqdn of the jitsi server. When connecting with the ip address this authentication mechanism is bypassed. So the first step was to redirect http:// to the https://. This worked. But if connecting with https:// it is still possible to create a room without login.

any help will be appreciated

1 Like

Confirmed. This is bad… I’ll try to find a solution, but if someone already has one, please share.

I found a solution.
NOTE: This is NOT thoroughly tested. I don’t know if there is some undocumented reason that jitsi deploys with the configuration that they use.

First, the description of what is happening:
Port 80 is a basic web service. It redirects to HTTPS on 443.
Port 443 is configured as a dual-purpose service. Depending on the protocol, it either redirects to the web server or redirects to the turn server. This redirection is what is bypassing the service_name parameter.

Solution: Don’t dual-purpose port 443.

Here’s how I did it:

  1. Edit /etc/nginx/modules-enabled/60-jitsi-meet.conf. Comment everything out. (I’m not a big fan of deleting files; just insert a “#” at the beginning of every line.) This file handles the dual-purpose mapping and we won’t need it anymore.
  2. Edit /etc/nginx/sites-enabled/mydomain.conf. Make a backup, then change the server configuration on port 4444 to use port 443. Remove the proxy_protocol. And if you have any $proxy_protocol_addr then change it to $remote_addr. This makes it a direct web server instead of an redirected proxied server from a shared stream.
  3. Edit /etc/nginx/sites-enabled/default and add a basic server for port 443. This is the catch-all that will handle the ip-address url. My example:

server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
access_log /var/log/nginx/access.log combined;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;

add_header Strict-Transport-Security "max-age=31536000";

ssl_certificate /etc/mycert/fullchain.pem;
ssl_certificate_key /etc/mycert/privkey.pem;

    root /var/www/html;

    # Add index.php to the list if you are using PHP
    index index.html index.htm;

    server_name _;

    location / {
            # First attempt to serve request as file, then
            # as directory, then fall back to displaying a 404.
            try_files $uri $uri/ =404;


My default index.html is blank. Accessing hostname:443 returns the jitsi server, but accessing ipaddress:443 returns a blank page.

But we’re not done yet. We still need a turn server (the other half of the old shared port 443)…

  1. Edit “/etc/jitsi/meet/mydomain-config.js”. Scroll down to the p2p segment. Under stunServers, add your own: urls: ‘stun:mydomain:4446’.

  2. Edit “/etc/prosody/conf.d/mydomain.cfg.lua” and set the turncredentials (near the top of the file) to be your server on port 4446.

  3. Open your firewall so port 4446 tcp and udp are permitted. Now your stun and turn go directly rather than entering via port 443 and being redirected.

Restart everything:

sudo systemctl restart prosody.service
sudo systemctl restart jicofo.service
sudo systemctl restart jitsi-videobridge2.service
sudo systemctl restart jibri.service
sudo service nginx reload

Assuming all of the changes work, you now have ipaddr:443 going nowhere, hostname:443 going to jitsi, and hostname:4446 being your stun and turn servers.

Well for me the solution was quite simple I just configured nginx to not allow conections without the FQDN.
Just editting the site-available configuration of my jitsi site and adding these lines to de server section just after ssl certificates:
Server {
if ($host != “myjitsidomain.com”) {
return 404;
} }

Thanks for the hint.