Relay Media Traffic Over Port 443 Instead of UDP Port Range (49152-65535)?

[AceThreeTech]

I have deployed eturnal on a server that is behind a corporate firewall. The challenge I’m facing is that my organization only allows opening port 443 and does not permit opening the UDP port range 49152-65535.

Is it possible to relay the actual media traffic over port 443 instead of the standard UDP port range? If so, what configurations would be required in eturnal.yml file?

[sando38]

That is possible, but not in the way you would think of. The TURN server would relay the traffic to itself. It would look like:

• Client A connects via TLS/port 443 to eturnal
• Client B connects via TLS/port 443 to eturnal

Client A > eturnal (relay_ipv4_addr: 10.0.1.1) > eturnal (relay_ipv4_addr: 10.0.1.1) > Client B (and vice versa)

relay_ipv4_addr: 10.0.1.1 ==> this assumes, that this is the internal IP eturnal is accessible with

@weiss probably can probably provide better guidance on how to achieve it

[sando38]

@AceThreeTech Can you please set in your eturnal.yml

eturnal:
  relay_ipv4_addr: "10.0.1.1" # Your server's local IPv4 address.
  whitelist_peers:
    - "10.0.1.1" # Your server's local IPv4 address.
  [...] # rest of your config

and then try to connect with both clients. It should work if both clients are configured to use the same TURN server.

[AceThreeTech]

Thanks @sando38 , it's working fine after updating it to the local IP address of the server. Appreciate the help.

I’d like to understand why it works with the local IP but not with the NAT IP of the server (without opening the udp port range). Could you explain what’s happening in the background? Also, will this approach add any additional latency to the A/V streams?

[sando38]

Thanks for the feedback. Glad it works.

It does not work the other way with the public NAT IP address being specified, because clients connecting from the internet can reach the public NAT IP address and will try to connect via the public relay_ipv4_addr and advertised relay port. Which fails.

With setting the relay_ipv4_addr to the private/local IP address we "enforce" implicitly that clients only have one valid "candidate", namely they can connect to TURN on port 443/TLS, with the difference, that the TURN server now "expects" a connecting pair coming to its local IP address. This succeeds, because the other connecting client will connect to the same TURN server on port 443/TLS the can speak both over the "internal - TURN server speaks to/ relays through itself" as the relay candidate is internal.

Probably we need a graphic to explain this better.

We plan to gather some FAQs about TURN and how certain scenarios work. This case here will then also be explained more thoroughly. 😆

[weiss]

I could imagine our description of how TURN works might help with understanding these effects as well. Your case is mentioned in the last paragraph (the TURN server ends up talking UDP to itself).

If things are still unclear please feel free to ask. The TURN protocol is pretty unique and unintuitive in many ways, I'm still unsure how to best explain the details :smile: