1264674 - WebRTC: Firefox does not check candidates in private networks using TURN

Status: RESOLVED DUPLICATE of bug 1259842

(Core :: WebRTC: Networking, defect)

Description

[Matthias Schertler]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160411042519

Steps to reproduce:

I have a scenario with endpoints in different private networks with no routing in between. For making WebRTC calls possible between that networks, there are transfer networks containing TURN servers.

It looks like this is not working, when the TURN servers are in private networks like 10.x.x.x or 192.168.x.x or 172.16.x.x. If the TURN servers have adresses that are not private like 11.x.x.x. everything works fine.

The actual flow when starting a call is like follows:
1. Firefox creates allocations on the TURN server and returns RELAY candidates in the 10.x.x.x network.
2. Firefox receives the remote SDP containing RELAY candidates in the 192.168.x.x network.


Actual results:

3. Firefox doesn't create permissions on the TURN server for the remote RELAY candidates. It also doesn't do ICE checks for the remote RELAY candidates. So ICE must fail.

(If the TURN server has a "public" address like 11.x.x.x Firefox creates the permissions, does checks and the call works)


Expected results:

3. Firefox should create permissions on the TURN server and do checks for all remote candidates. There should be no optimizations based on assumptions if the remote candidates are likely to work or not.

Comment 1

[Matthias Schertler]

Short version: Firefox only checks public IP addresses using TURN. 

This optimization causes problems in scenarios in which the remote TURN server is not in the public internet but in a private network. I recommend removing that optimization form your ICE logic.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Nils - is the RFC 1918 issue?

Comment 3

[Nils Ohlmeier [:drno]]

Yes it is a dupe of bug 1259842