TURN not shown as remote adress even though trafic goes through it

After many hours of troubleshooting we finally managed to get trafic going through the TURN to the JVB. The final piece of the puzzle was to allow UDP range trafic FROM jvb to TURN.

udp/5349
tcp/5349
tcp/443

In a 3+ particpants we get video and voice from each other. However, while looking at the remote/local adress in the Jitsi GUI or chrome://webrtc-internals it shows the JVB as the remote adress which is not possible as the trafic runs through the TURN server.

Due to us being a high security environment we are not allowed to disclose internal IPs of the infrastructur to external parties which means it is important for us that the remote adress is the publically available TURN server.

Are we missing something here? Or is this by design?

It is normal to see the jvb public address there. Are you seeing the the private one?

I am seeing the public adress(not local) of the JVB pod in the kluster that is fetched via stun_mapping_harvester_addresses.

However, from a network topolgy perspective it is not a internet public IP adress, it is the internal ip of the jvb that TURN connects to as we cannot expose the jvb directly to internet. So the IP should not be known to the outside world.

So basically we cannot do anything about this? Jitsi will always present the jvb public adress to the connecting clients even if we use TURN? Or can we configure prosody/turn to “force turn” to display turn-server a remote address?

There is no such thing.

We are not doing anything special other than showing the webrtc stats. So this is how it comes from webrtc.

If you are not connecting to the bridge using its public address … what does your turnserver config looks like?

It should be like this jitsi-meet/turnserver.conf at master · jitsi/jitsi-meet · GitHub
Notice all the denied-peer-ip, you need that to avoid exposing your internal network to the public through coturn.

Thanks, will have a look at the turnconfig. A quick glance tells me we are close to this config.

Regarding denied-peer-ip, we should not block the internal “public” adress of the jvb right? This is to prevent this hack: Details about CVE-2020-26262, bypass of Coturn's default access control protection

I just noticed that when we are only 2 participants the remote adress displays as (p2p)(turn). Shouldnt a similar display(turn) occur with 3+ participants even if STUN is not used?

Its strange that it would replace turn IP with jvb IP with more than 2 participants, it get the feeling TURN is not occuring?

OK, testet towards meet.jit.si and I get the exact same behavior

  • p2p shows the TURN adress/other peer IP (p2p)(turn)
  • 3 parties shows MY IP ADRESS:61359 <=> 141.147.42.29:10000 ← JVB of meet.jit.si?

So the bottom line is due to the nature of webRTC it will display the public IP of the service using webRTC(for Jitsi the jvb IP adress) even though the trafic is relayed via a TURN server.

Is this the correct conclusion? Or can it be configured with e.g denied-peer-ip etc?

This is correct.

Not relevant to your question.

I was pointing that out because of your description. I don’t have a clear picture of your topology, but in general, coturn is supposed to connect to jvb using its public address and should not use the internal network for that connection when both coturn and jvb are in the same internal network, as this is a security issue.
The configuration we use as a template (the link I shared earlier) is doing exactly that.

Much appreciated for the clarifications @damencho!

I did some testing with what public and local adress is being displayed in Jitsi GUI/webrtc-internals vs. org.ice4j.ice.harvest.StunMappingCandidateHarvester.discover from the jvb.log

It appears like the displayed public adress in Jitsi/webrtc-internals does not match what the org.ice4j.ice.harvest.StunMappingCandidateHarvester.discover finds.

E.g
MappingCandidateHarvesters.createStunHarvesters: Using JITSISTUNRELAY:443/udp for StunMappingCandidateHarvester (localAddress=JVBIPADRESS:0/udp)

org.ice4j.ice.harvest.StunMappingCandidateHarvester.discover: Discovered public address PUBLICADRESS:58390/udp from STUN server JITSISTUNRELAY:443/udp using local address org.ice4j.socket.IceUdpSocketWrapper

Outcome
jvb harvester public = 1.1.1.1 (internet public IP adress)
Jitsi/webrtc-internal remote = 2.2.2.2 (local adress of jvb)

jvb harvester local = 2.2.2.2 (local adress of jvb)
Jitsi/webrtc-internal local = CLIENT local adress

Does this mean that the jvb always announces the local adress and ignores the public adress? Can it be configured manually?

Or… is this a webrtc thing that cannot be adressed? :grimacing: