Possible to disable STUN/TURN completely on jitsi videobridge?

I may be asking the wrong question, but I’m seeing behavior from my Jitsi-meet server that looks an awful lot like it’s somehow STUN/TURN related, and I’d appreciate any help.

I have a VPN (192.168.1.0/24) with several user hosts (192.168.1.x), and a Jitsi Meet server on a host with both a VPN ip address (192.168.1.100) and a public IP address (x.x.x.x).

The VPN is configured so that all traffic to non-VPN addresses exits the VPN from a gateway node (public IP y.y.y.y) where it is NATted.

When two users are connected, they are able to converse (I’m assuming because of the p2p stuff), but when a third joins in, suddenly no audio or video works.

The behavior I am seeing is that when the third user connects, suddenly I am seeing traffic go out the VPN’s external gateway, where it is NATted (to y.y.y.y), and then it’s coming back to my jitsi server on its public ip (x.x.x.x).

My speculation is that the Jitsi-meet server is using a STUN or TURN server to find out its actual public ip address, and is telling the clients that, so when they want to talk to the video bridge, they are trying to connect to that public address instead of the in-vpn address. Since the VPN is seeing x.x.x.x as external, the traffic is being routed out my VPN exit point and thence back to the Jitsi server’s public IP, where it’s being dropped at the firewall.

I’ve tried changing useStunTurn: to false in /usr/share/jitsi-meet-web-config/config.js and then restarting the service, but that has had no effect.

What am I doing wrong?

Well, it was my impression that this file was a mere sample, or maybe a template from which the true config file
/etc/jitsi/meet/<jitsi-host-url>-config.js
is generated

I believe that may have been it. I was looking in the wrong config file, like a knucklehead. Thank you.

Is ICE connecting to the bridge? It seems the issue you describe would prevent ICE from connecting as well.