Issue with TURN and symmetric NAT behavior.

[mkm85]

I have discovered an issue when running the TURN test while the machine performing the test is behind symmetric NAT (wifi teethering from my phone) https://github.com/paullouisageneau/libjuice/blob/master/test/turn.c

I originally discovered the problem using LibDataChannel with libjuice but it can be reproduced with just libjuice.

It seems like libjuice wrongly filters out a packet coming from the TURN server because the port number does not match, because of the symmetric NAT.

I've tried to fix the filtering issue, but then the rendezvous still fails as the ip:port tupple is not added to the list of candidates and the rendezvous still fails.

[paullouisageneau]

Thank you for reporting. Could you please clarify two things:

• What port number does not match exactly? NATs translate the source address of outgoing packets and the destination address of corresponding incoming packets, so packets sent from the TURN server to an agent (i.e. incoming packets) can't have the source address changed.
• libjuice does not filter by port number. What have you fixed exactly?

[rsachetto]

I don't know exactly the problem but I think I am going throug the same issue. I am unable to establish a connection with a peer behind a symmetric NAT.

Some data:

Adding candidate: a=candidate:2 1 UDP 1686109951 xxx.xxx.xxx.xxx 36781 typ srflx raddr 0.0.0.0 rport 0
23:22:38 DEBUG agent.c:777: Received STUN datagram from xxx.xxx.xxx.xxx:63062 relayed via yyy.yyy.yyy.yyy:56882
23:22:38 DEBUG agent.c:1288: No STUN entry matching remote address, ignoring

I don't fully understand the protocol, but it seems to be a problem when the ports don't match.

When it works, the ports match:

Adding candidate: a=candidate:2 1 UDP 1686109951 xxx.xxx.xxx.xxx 29369 typ srflx raddr 0.0.0.0 rport 0
Received STUN datagram from 132.255.59.159:29369 relayed via yyy.yyy.yyy.yyy:58304

Just as a clarification, the ommited IP xxx.xxx.xxx.xxx are all the same.

[paullouisageneau]

Thank you for the details. The issue is not about filtering out a packet coming from the TURN server, instead it appears the corresponding peer reflexive candidate is not added when receiving a request over the relay, which is a bug. This can cause relaying to fail when the remote peer has no TURN server and is behind a symmetric NAT (endpoint-dependent).

[rsachetto]

Thanks for the quick fix. It worked in the symmetric NAT test.