How does a TURN server send data to peers behind a NAT?

Refresh

February 2019

Views

0 time

1

I understand in TURN there is a client, a TURN server, and peer(s). The client itself creates an Allocation on the TURN server, after which a relayed transport address is returned back to the client in order to send data to one or many peers.

I understand how the client can get around its NAT, however I didn't see anything in the RFC5766 about how the peers themselves are able to accept the UDP through their NAT's from the TURN server (otherwise through TURN or not, it would be unsolicited UDP). The peers would have to reach out to the TURN server first.

Is there a step I'm missing? Is the relayed transport address sent to the peer so that UDP hole punching can begin before communication can flow between the TURN Server and its peer(s)?

1 answers

1

The client creates an allocation on a TURN server e.g. running at 8.8.8.8 port 3478. To do so, it sends STUN packets from a local socket to that address. All NATs (ignoring networks that block UDP) will allow the TURN server to send UDP data back over that connection (sometimes referred to as a NAT binding). The TURN server can also send any other data it wants over that connection.

The peer does not know about this allocation. It only knows the relay address that the TURN server tells the client, e.g. 8.8.8.8 port 61468. The client must send this address to the peer, for example as part of signaling in the ICE process (see https://tools.ietf.org/html/rfc5245).

The peer can then send 8.8.8.8 port 61468 (sometimes the client must also tell the TURN server the ips the peer can send on; see the Permissions in https://tools.ietf.org/html/rfc5766). The TURN server will then forward any traffic it receives on that port as a STUN data indication (or via a channel binding, see RFC 5766). The NAT is ok with that since it is coming from 8.8.8.8 port 3478.

The client can also send data to the peer via a STUN send indication. The TURN server will unwrap this data and send it from the relayed address (8.8.8.8 port 61468)

As far as the NATs on both sides are concerned, they only see communication with ips and ports where their client has sent packets first.