Jitsi behind NAT works without “Advanced Configuration”. Is it due to some changes on last revisions?

First of all, congrats for the great job: about development, and support !

I have a jitsi-meet server up and running, based the last revision.

It’s NATted (behind the router).

It has been configured (on a clean Ubuntu 18.04) following the “Quick-install” guide … but without adding the Advance Configuration step.

At client side, I use both browser (FF, Crome) and Jitsi-meet app (Android, IOS) …

Port forwarding is only active on “443" (tcp) and on “10000” (udp) ports.

“Surprise” …
Clients - acting both from internal side (LAN) and external side (WAN) - can connect the server as usual (via “https://mydomain.xx”).

Q1.: May I ask you (positively) … why ?

I’ve been banging my head for weeks, while trying to understand why configuring the server step by step before making any test … it has never been working.
Now, avoiding to implement the Advanced configuration it works “better” than expected.

It means that NGINS is properly acting as proxy ? Involving the right process for “http” and for “https” ?

So it means that now we don’t need anymore to add new lines, like here below, to the file /etc/jitsi/videobridge/sip-communicator.properties:
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<Local.IP.Address>
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address>
Or these (not suggested in the advanced config section)
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443

Great.

Last though: in the /etc/turnserver.conf file … there is a reference to the <Public.IP.Address> of the server.
My <Public.IP.Address> is dynamic (not fix).

Q2.: Is it possible to have it automatically updated, instead of reporting the IP detected during installation ?

many tnx

I thought that 80/tcp is also mandatory for the letsencrypt certificate - otherwise the certbot will fail?

Franky1 yes, you’re right … but it’s mandatory only for the time necessary to obtain certificates.

After install, and after having run:

/usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

you can freely “close” port “80” for Jitsi.
Optionally, you can still forward it but only if you have “http” service running.

Ok, but still you have to open 80/tcp at least once during installation.
The statement “only 443/tcp and 10000/udp” might otherwise confuse some people or cause errors?

And what happens when the certificate has to be renewed after 90 days?
I do not know the certbot in detail.
Does the renewal run over 443/https or 80/http ?

Yes, you are right: https://github.com/jitsi/jitsi-videobridge/blob/master/debian/postinst#L102

Who is right?
I’m sorry, I don’t understand what you’re trying to say about line 102 in the postinstall script… :thinking:

I mean “Jitsi behind NAT works without “Advanced Configuration”. Is it due to some changes on last revisions?”: Yes you are right.

I had pasted the link to the code, so we had put the bridge to auto-discover its public address and no need to adding NAT_HARVESTER_LOCAL_ADDRESS and NAT_HARVESTER_PUBLIC_ADDRESS. But we left the doc, just in case, as we were seeing people still having problems …
One day we will change the doc to be accurate and having some of the parts in a FAQ or something …

1 Like

Great !

This is a very useful "value-added”.
Thank you damencho and thank also to the developer team.

damencho, starting from here I’ve opened a new topic for trying to solve the issue “ No Voice & Video behind NAT (DynDNS) ” very common.

I’ve found that one condition is due to the lack of update for the external-IP registered in the /etc/turnserver.conf.

It seems I’ve partially solved the issue (at least for my server) but … need some help for last step. Could be enough being pointed to the right direction.

Pls, only when you can, could you give a look at it ?

thanks for all of your support !