The "-server-relay" option

204 views
Skip to first unread message

Terence Darwen

unread,
Aug 20, 2020, 6:16:08 PM8/20/20
to TURN Server (Open-Source project)
Hi, the danger of using the server-relay option is not entirely clear to me and I'm hoping someone can explain a bit more.  In the README.turnserver file, it states:

-server-relay
    Server relay. NON-STANDARD AND DANGEROUS OPTION.
    Only for those applications when we want to run
    server applications on the relay endpoints.
    This option eliminates the IP permissions check
    on the packets incoming to the relay endpoints.
    See http://tools.ietf.org/search/rfc5766#section-17.2.3 .  


Can anyone provide more clarity on the above explanation?  My setup has coturn running on a cloud VM.  A video streaming software service is also running on this cloud VM delivering video streams to internet users.  I'm guessing the video streaming software service qualifies as a "server application", agree?  ...In this case am I exposing myself (the clound VM, etc) to risk by enabling the -server-relay option?

The link given above states:

 17.2.3. Running Servers on Well-Known Ports 
    A malicious client behind a firewall might try to 
    connect to a TURN server and obtain an allocation 
    which it then uses to run a server.  For example, 
    a client might try to run a DNS server or FTP server.
    
    This is not possible in TURN. A TURN server will 
    never accept traffic from a peer for which the client 
    has not installed a permission. Thus, peers cannot 
    just connect to the allocated port in order to obtain 
    the service.

So, it sounds as though enabling the -server-relay option *will* allow the TURN server to accept traffic from a peer which has not been given permission.  Is that correct?

Any additional explanation would be much appreciated.  Thank you.

Terence Darwen

unread,
Dec 15, 2020, 12:47:48 PM12/15/20
to TURN Server (Open-Source project)
Hi - My team is still stumped on this one.  Any thoughts anyone might have would be very much appreciated.  Specifically, we've been using coturn with Kurento and OpenVidu and are running into problems relaying WebRTC from Kurento into OpenVidu and then to a web browser for viewing.  Web cams into OpenVidu to web browsers work fine, but once we add Kurento to the mix as a source the stream will only appear at the endpoint with the server-relay option enabled.

Giacomo Vacca

unread,
Jul 26, 2021, 10:59:13 AM7/26/21
to TURN Server (Open-Source project)
In normal conditions, a TURN server would only accept packets on the relay side from sources that have been granted a Permission.

This means that a TURN client must have knowledge about the source of packets from a peer (which typically is gathered by exchanging ICE candidates over a PeerConnection).

When "server-relay" is set, then coturn doesn't verify the existence of a permission for the source of a packet, before relaying it on the TURN side.
This is where the configuration is dangerous: packets from any source, received on the relayed transport address already allocated, will be relayed to the TURN client that performed the Allocation.

If only having "server-relay" set makes a configuration work, then it's possible that the real source transport address (IP address and port) of one participant is different than the one provided during ICE candidate exchange.
In other words, the TURN client in that case doesn't know to what the Permission has to be created, and so a Permission does not exist. With "server-relay" off, coturn would discard the incoming packets. With "server-relay" on, coturn would accept them and perform relay.

Giacomo
Reply all
Reply to author
Forward
0 new messages