sudo grep -rnw '/' -e 'rtcsec'

Changing the config in /run/turnserver in the container doesn't appear to work on restart. It resets the config.

https://www.rtcsec.com/2020/04/01-slack-webrtc-turn-compromise/

So for my use case, I had to remove those rules for the vulnerability to resolve the issue. My router and desktop IPs were on the list of local IPs blocked in that list.

Of course, I am looking for a better way to do this, but I temporarily changed the turnserver.conf.template file

Our meetings in NC:Talk work fine.
Our meetings in Kopano work fine.
Our meetings in GL/BBB fail at enabling the microphone. (using BBB from a second 3rd party server)

Our meetings in GL/BBB works fine now.

Backend firewall issue after an upgrade.

It tried to connect to the echo server... and fails.

One thing I noticed is that our TURN server is configured (per @nebulon) for a port range of 50000-51000 and BBB expects 32768-65535.

Required Ports (https://docs.bigbluebutton.org/2.2/setup-turn-server.html)

On the coturn server, you need to have the following ports (in addition port 22) available for BigBlueButton clients to connect (port 3478 and 443) and for coturn to connect to your BigBlueButton server (32768 - 65535).
Ports 	Protocol 	Description
3478 	TCP/UDP 	coturn listening port
443 	TCP/UDP 	TLS listening port
32768-65535 	UDP 	relay ports range

What's with port 22? (We use a diff port for ssh)

From .env in GL, I don't see these ports being specified, hence we may need to modify the GL / BBB configs for our more limited port range.

Also, since we're using a 3rd party BBB, we may need to specify the 3rd party TURN server as mentioned here.

Like it seems like it just keeps blocking people I try to talk to and I cannot for the life of me figure out why. I've had to resort to a BBB vps for meetings, but with discord's potential aquisition I would like to also use the voice and video chat in Matrix (Element) but I encounter the same issues.

Network-wise my port forwarding everything seems to be in order

Also, I should point out that I use Adguard Home on my router, which is also what connects to my cloudron. Would that cause any problems?

But its weird because it seems to work between my phone on data and my desktop (on the same network as my cloudron) but not between my someone in toronto and my desktop.

I remember there was a change related to this slated for a release @girish. Is this true? I'm really not sure what else I can do here O_O

EDIT: Seems like my investigations are going nowhere

I assumed it might have to do with this commit but if it works for Robi in the same scenario I've got nothing else I can think of trying: https://git.cloudron.io/cloudron/box/-/commit/6adf5772d8f871eae98ad5f5ffdbed7098bac214

@robi For your setup is your computer and server on the same network? I'm seeing 401s every time I try to connect with others.

listening-port=3478
tls-listening-port=5349
min-port=50000
max-port=51000

We have also included a section for preventing some attack, which I think is what you may hit?

# https://www.rtcsec.com/2020/04/01-slack-webrtc-turn-compromise/
no-multicast-peers
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=100.64.0.0-100.127.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.0.0.0-192.0.0.255
denied-peer-ip=192.0.2.0-192.0.2.255
denied-peer-ip=192.88.99.0-192.88.99.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=198.18.0.0-198.19.255.255
denied-peer-ip=198.51.100.0-198.51.100.255
denied-peer-ip=203.0.113.0-203.0.113.255
denied-peer-ip=240.0.0.0-255.255.255.255

Those IPs are anyways no public IPs and thus would not help you to achieve connectivity through it as far as I understand.

I have to run atm, but would dig into the CL TURN docs and see how or why they restrict the private networks if that's where it's blocked.