Join conference with lan and wan

Hi everyone.
I have successfully installed Jitsi on my server reachable from mydomain.com with nat. I want my colleagues to join the conference via lan, but no video appears (preview only).
There is no error in the Jitsi logs.

In console:
"2020-12-31T11: 11: 34.597Z [JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>: UnhandledError: null Script: null Line: null Column: null StackTrace: Error: Strophe: request id 1.1 error 0 happened
at Object.r.Strophe.log (strophe.util.js: 89)
at Object.error (strophe.umd.js: 1392)
at O.Bosh._onRequestStateChange (strophe.umd.js: 5017) "

“Logger.js: 154 2020-12-31T11: 13: 12.381Z [modules / xmpp / strophe.util.js] <Object.r.Strophe.log>: Strophe: request id 1.1 error 0 happened”

“2020-12-31T11: 17: 02.768Z [modules / xmpp / strophe.util.js] <Object.r.Strophe.log>: Strophe: request errored, status: 0, number of errors: 1”

I use nginx.

Go slow in the comments. Ubuntu practically turned it on yesterday for the first time.

Trasanda.

P.S. forgive my school english.

Enable STUN_MAPPING_HARVESTER_ADDRESSES and add NAT_HARVESTER_LOCAL_ADDRESS and NAT_HARVESTER_PUBLIC_ADDRESS for local IP on the /etc/jitsi/videobridge/sip-communicator.properties file

Hi emrah.
does not work.
my configuration is this:

org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER = true
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES = LAN_IP: 443
org.jitsi.videobridge.ENABLE_STATISTICS = true
org.jitsi.videobridge.STATISTICS_TRANSPORT = muc
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME = localhost
org.jitsi.videobridge.xmpp.user.shard.DOMAIN = auth.mydomain.net
org.jitsi.videobridge.xmpp.user.shard.USERNAME = jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=fFutd@1
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.mydomanin.net
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME = 1c9c4f9e-cffa-404a-935a-9eda839167d7
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS = LAN_IP
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS = PUBLIC_IP

it’s OK?

Thanks.

Trasanda

if your connection is not secure (usually a green lock) it’s normal your video don’t work (webrtc requirement). If this is the case, you need a correct certificate.

This is wrong.
My connection on wan is secure on lan no (you cannot install a certificate in lan).
On the same server, with another instance, my room works even without certificate if you accept the request.

you can (and should) use the same certificate by using split DNS (a private dns server that serves your internal client with the private IP when asked for the public address) - or just stuff the hosts file with the info for all your clients if it’s faster.

can you give me an example of correct host file?
The first option I did not understand.

Trasanda

if your internal IP address is 192.168.1.1 and the public host name is example.com, you should add a line with

192.168.1.1 example.com

in the hosts file on the workstation you want to use. It’s the same format for all OS as far as I know.

Ok, so that’s it already, but it doesn’t work.

org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443

Do your colleagues use the same host address while connecting or the local IP address?

Colleagues in the company use the LAN

The address must be the same for the external and the internal participans

The internal server does not have a private IP. Is it possible that there is no way to merge users in LAN with users in wan?

I have trouble parsing this sentence. To the best of my knowledge, an ‘internal’ server (behind a NAT) has a private IP address (one in the private ranges 192.168.x, 172.16.x, 10.x) and can be used on Internet through a redirection that masquerades it with the public IP address of the gateway.
An internal server has not directly a public IP address - that’s why it’s necessary to get some special applications like Jitsi-meet this additional information either with a Stun server or a configuration file.
Can you elaborate ?

My company has the IP network 192.168.x.x / 23 and Jitsi (VM) has the same IP network. My domain is on Aruba.it and requests end up on my private IP address 2.x.x.x. Jitsi is ok with private IP, and ko with local IP.

you seem to mean by ‘private IP address’ as ‘the IP address that I don’t want you to know’. Well, that’s not the usual meaning in information technology. A private IP adress is an address that can’t be routed (used) on the Internet. If you say me that the address of your computer is 10.14.12.36, it don’t allow anyone on the Internet to access it because 10.x.x.x addresses are private (non routable - if my computer try to access this address, the Internet router, that is, my ISP box, will to transmit it anywhere) . If your computer’s address is 2.112.1.1, even if you don’t communicate to anyone, it can be found and addressed on the Internet (and will be attacked by hackers because all addresses on the Internet are scanned and attacked). So it’s a public IP address.
Anyway, what I and @emrah are trying to make you to understand, is that the clients should all (internal and external) access your server by its NAME, example.com, and external clients will get the public IP address (2.x.x.x) from the public DNS Internet system, and the internal clients will get the private IP address (192.168.x.x) from your host files. It’s necessary that people use the server name because it’s how the certificate system is supposed to work for TLS (web secure), and webrtc (the technology used by Jitsi-meet) needs secure Web (TLS). Capito ?

Yes, as you say, Jitsi can be reached from the outside with public IP. The hosts file is correct (192.168.x.x 2.x.x.x), but I repeat, from the outside everything is ok, from the inside it is ko.

is there a green lock when the initial screen is displayed ?

If you talk about the security certificate, it is valid only from the outside or not from the inside.

a certificate’s validity does not depend on the IP address, it depends only on the name used to access the IP address. When the browser is asked for example.com, and it connects to 192.168.1.1 it is asking for the name example.com. If the server presents a certificate with the name ‘example.com’ on it, it’s good. If your users connect using https://192.168.1.1 or https;//myinternalserver, in the first case the browser will not even ask for a certificate, and in the second case the web server will present ‘example.com’ on its certificate, the browser will see that it does not match ‘myinternalserver’ and in both cases you will get an insecure connection (and no webrtc, no media peripherals accesible from the browser).