Closed Bug 1264674 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: WebRTC: Networking, defect)

46 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1259842

People

(Reporter: matthias.schertler, Unassigned)

Details

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.
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.
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core
Nils - is the RFC 1918 issue?
Flags: needinfo?(drno)
Yes it is a dupe of bug 1259842
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(drno)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.