Jitsi in a restricted network with NAT and non-NAT clients - no video/audio

I’m trying to use jitsi-meet in a restricted corporate LAN, where:

  1. The jitsi server will be in a network (e.g. 192.168.168.0/24), where there can be one or two clients in the same network.
  2. This network will be part of a bigger corporate network (e.g. 10.0.0.0/8). The 192.168.168.0/24 subnetwork will be behind a NAT (which will be on 10.0.12.10 externally and 192.168.168.1 internally). The NAT port-forwards the 8443/tcp and 10000/udp to the jitsi server machine (192.168.168.5). There will be typically 2-3 clients from the 10.0.0.0/8 network.

We want to be able to hold conferencing with users both “inside” and “outside” the NAT. All of these networks don’t have internet access and we won’t need to be able to use this jitsi from the public internet.

I’m using the docker install method.
I’ve worked it out and works perfectly when tested locally (where we don’t have the NAT complications).
Testing on the corporate network, if I use DOCKER_HOST_ADDRESS=192.168.168.5, and try accessing the server from outside the NAT, we can open the HTTPS, and chat works, but there’s no audio/video. I believe if we change DOCKER_HOST_ADDRESS to 10.0.12.10, then it will start working for clients outside the NAT, but not for the ones inside it.

The question is - how to achieve both?
I’ve seen this question and tried setting

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.168.168.5
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=10.0.12.10

but it doesn’t seem to help. As for the turnserver changes - I don’t see where to apply them, as they seem to be missing from my install.

I’m not sure I get the hang of STUN/TURN servers completely, I’m new to these. For what is worth, we can route all traffic through jvb, we don’t need to worry about efficiency, as it is an internal gigabit network and there will be 3-5 clients connected simultaneously at most.

Is it possible to add a NAT rule for 192.168.168.0/24 network which redirects (10.0.12.10, UDP/10000) traffic to 192.168.168.5?

If 192.168.168.0/24 network communicates with Jitsi over 10.0.12.10, I think it should work.
Same rule for TCP/443 too…

Many thanks, this is a very good idea. We’ll try it out and post our findings.