1202451 - Allocating TURN candidates fails with HTTP Proxy and no DNS server

Status: NEW

(Core :: WebRTC: Networking, defect, P3)

Description

[Rob]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36

Steps to reproduce:

1) Set up an environment where the restricted device (PC with Windows 7):
- can only use a HTTP Proxy to access the web (any attempt to connect without the Proxy is blocked by firewall rules)
- has no or non-working DNS servers configured for lookups.

2) Deploy a TURN server (we use coturn) that is configured so that "HTTPS Tunneling" works (the TURN server is reachable externally and listens on TCP/443).

3) On the restricted device, create a PeerConnection with a TURN server using a domain name (i.e. my.turn.com) and try to make a connection with another device which is in an external, non-restricted network environment (i.e. typical consumer internet access, no firewall, only NAT).


Actual results:

The connection cannot be established. It bails out with the "ICE failed" console message. 

about:webrtc log show entries like:

(ice/WARNING) ICE(PC:1441274189008000 (id=74 url=https://my.app.com): failed to resolve candidate relay(IP4:1.2.3.4:53786/TCP|my.turn.com:443).

(redacted URLs and IPs)

And finally fails with:

Trickle grace period is over; marking every component with only failed pairs as failed.



Expected results:

The PeerConnection should have been established. In the presence of a HTTP Proxy, being able to resolve DNS names or not should be irrelevant as this is handled by the Proxy. Being forced to go through the Proxy and having no DNS resolution capabilities is a typical scenario enforced by IT departments. 

As a workaround, if the TURN server is specified per its IP address, the connection is successful. 

P.S. For the same scenario, Chrome has a similar bug where it takes them about 10 seconds to realize that DNS resolution is futile.

Comment 1

[Rob Swain]

As a note I was testing this scenario over the past few days at it is still present in both ff 54 and mozilla-central master code from yesterday.

I had two VirtualBox VMs, one with only an 'internal network' interface configured with a static LAN IP and the other with both an 'internal network' interface with static LAN IP and a NAT interface. On the second I installed a squid proxy that allowed HTTP and HTTPS tunnelling via HTTP CONNECT requests. I configured the Firefox on the first to use that squid proxy on the LAN IP of the proxy VM. As such, the Firefox VM did not have any DNS.

My observation was that when trying to use the TURN server via a domain name was that DNS failed which caused the candidate to be discarded. Looking in the code it looks like the code paths for resolution failure bail out before initialising the candidate. This would need to be changed but it looked a bit non-trivial as the initialisation uses information from a socket address structure which is populated only when knowing the IP of the remote candidate I think.

I added the domain and its IP into /etc/hosts as a quick test. In that case, the HTTP CONNECT was sent to the proxy and eventually Firefox could connect out to the TURN server but there was some credentials error which could have been my fault or could be a legitimate bug - noting it here in case it provides a lead during later investigations. The code also seemed to get stuck in a strange state whereby it would repeatedly log a call to one of the getaddr functions. I don't remember if it was nr_socket_wrapped_getaddr or nr_socket_proxy_tunnel_getaddr but I think it was one of those two.

Comment 2

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 3

[Pascal BORSCHNECK]

Hi,

I think this is linked with/dup of
https://bugzilla.mozilla.org/show_bug.cgi?id=1385030
and
https://bugzilla.mozilla.org/show_bug.cgi?id=1239006

How to have updates from developers on these bugs ?

I confirm adding the TRUN server in the /etc/hosts resolved the problem, BUT Firefox, if proxy is set, should ask the proxy to do the DNS resolution and not try it locally !