Corporate participants shown as internal IP on JVB

We have some participants behind a corporate proxy. They’re able to join the meeting without audio and video.

I set up an external Coturn server on a separate machine. I can see the difference in the web-internals ICE candidate grid but still when a corp user joins. No audio and video and the JVB is trying to send the streams to their local IP instead of the public one.

Anyone has any idea how to solve this?

The path should be the following:

client → turn server port 443 or 5349 → jvb public address & port (udp 10000) → jvb

If you see the jvb trying to reach their internal address … that means UDP packets have reached jvb, and probably turnserver is not needed. What do you have configured in config.js for stun servers?

Thanks @damencho.
Do we have to do this even if we have P2P disabled?

Good question … yeah, actually for the media to the bridge the stun server is not needed.

Well… how are these users being identified with their local IP? The JVB is sending the streams to the endpoints local IP.
Here’s a screenshot

On the CoTurn we set up we see the user’s external IP

This means the bridge is trying (and failing) to establish a connection using the private address. It’s therefore not using it to send media.

1 Like

Did you use for turn config our template: jitsi-meet/turnserver.conf at master · jitsi/jitsi-meet · GitHub

Maybe share the coturn configuration

Here is our coturn config.

# /etc/turnserver.conf

# STUN server port is 3478 for UDP and TCP, and 5349 for TLS.
# Allow connection on the UDP port 3478
# and 5349 for TLS (secure)

# External IP-Address of the TURN server

# Require authentication

# We will use the longterm authentication mechanism, but if
# you want to use the auth-secret mechanism, comment lt-cred-mech and
# uncomment use-auth-secret
# Check:
#The static auth secret needs to be changed, in this tutorial
# we'll generate a token using OpenSSL
# use-auth-secret
# ----
# If you decide to use use-auth-secret, After saving the changes, change the auth-secret using the following command:
# sed -i "s//$(openssl rand -hex 32)/" /etc/turnserver.conf
# This will replace the 65bf303f069496b35bc4fa4157e268a2e5d2a61aa3e666a5c2d70b206428b39e text on the file with the generated token using openssl.

# Specify the server name and the realm that will be used
# if is your first time configuring, just use the domain as name


# Path to the SSL certificate and private key. In this example we will use
# the letsencrypt generated certificate files.

# and 5349 for TLS (secure)

# Specify the allowed OpenSSL cipher list for TLS/DTLS connections

# Specify the process user and group

This is not correct. Drop that and make sure turn server can connect to port 10000 on public IP address of jvb.

Also, make sure you add the denied rules from our template to avoid exposing your internal network to the outside world.

We made the modifications (including the denied-peers) and still the JVB log show the JVB is trying to establish connection on the private IP.

On the users can connect without an issue.

Any other ideas?

Yes I can connect from coturn to jvb using port 10000

That is expected and not a problem.

What about the certificates the coturn is using, are those valid? With full chain?

Are you testing with browsers or mobile clients?

Looking into that now. Thanks

Doesn’t matter when behind a corp proxy

Well, I’m asking cause at some point there was a known problem with mobile clients, turnserver and let’s encrypt certificates.

Not sure in which version is fixed, and whether that fix is already out.

No we just tried with web browser that connected to
The certs and keys are verified.

Yeah, is not using let’s encrypt, so that’s one difference and that’s why I was asking what you are using and are you testing with browsers.
Check that you have the full chain

We aren’t either. We have an EV SSL certificate in place.