Cannot establish a meeting with peers behind restrictive firewall

[olivluca]

@emrah

JVB uses it to learn its external IP.

I specify it in org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS

[olivluca]

@gpatel-fr

as a stopgap, if you specify no-tcp-relay in your coturn configuration, external systems can still send UDP packets to internal hosts, but it downgrades the threat from ‘intruder in the network, severe and immediate’ to far-fetched, no easy way to exploit.

Yes, no-tcp-relay is there, but that doesn’t worry me: this host is in the DMZ and cannot connect to the internal network (except for a few ports).
But if I understant it correctly, specifying allowed-peer-ip=172.16.69.25 will allow external hosts to send udp packets to any port at 172.16.69.25 (i.e. the internal ip of the jitsi/coturn server) and that does worry me. There are not many services listening on udp (coturn itself, dnsmasq, ntpd and systemd) but who knows what can be done by accessing those (especially systemd).

[olivluca]

@olivluca

Ouch, that could be it, but coturn didn’t complain (as it did fot 172.16.69.25)

No, it cannot be it: according to the manual page of coturn, its white/black lists are for addresses it can relay to, not the addresses it will accept connections from.

[gpatel-fr]

@olivluca

coturn itself, dnsmasq, ntpd and systemd)

about coturn and systemd, coturn does not by default relay to localhost. If systemd listens on the network on your server it’s not normal, by default it does not.

[olivluca]

@gpatel-fr

If systemd listens on the network on your server it’s not normal, by default it does not.

It was the rpcbind.socket listening on 0.0.0.0. I didn’t explicitly enabled it, so it must be active by default. I disabled it.