WebRTC/AppRTC - is unable to work when a user using Proxy server to browse Internet

[SProgrammer]

User is in a location, where he have to use in his web browser Proxy server settings to browse to the internet 

or without Proxy server settings on his browser the main internet is using Proxy server by network admins.

Now this is what happening while trying AppRTC and Turnserver with relay:

1- A connects AppRTC server on port 443, gets selfview (this user network is critical, either have to use Proxy server settings to go to internet or network admin has to set it up)

2- B connects AppRTC server on port 443, gets selfview (has no problem connecting signaling, turn servers)

3- A and B both see that they are "Connecting..." 

4- B to turn-server is working and turn-server log says he is connected and waiting for A to hand shake

5- A to turn-server is never happening, there is no connection at all coming from A to turn-server

Connection fail over and over and over....

C another person who do not belong to that network (of A) connects with B, in that case B and C works but not A and B.

What is happening here with A and B and How to resolve this? Is it something that proxy server is killing some webRTC/appRTC signalling to initiate the turnserver request over websocket?

Thank you

reg

Shamun

[Warren McDonald]

Hi Shamun,

1. are A and B using the same type of web proxy and configuration? 

2. Is the port being used to connect to the TURN server configured for CONNECT method in the proxy (like SSL)

3. Are you using TLS to the TURN server or at least TCP.   

4. Is any advanced SSL protocol support (SSL Accelerator or protocol inspection) being used at A

In my testing, the only successful config was to use port 443 or another port configured to support proxy CONNECT. (Forcing TCP transport is mandatory) 

Where SSL support is in place, TLS must be used as the devices often just assume traffic on 443 is SSL and will break/block non TLS.

Also the web proxy will only be used if all other methods to reach the TURN server fail. So if A could reach the TURN server via TCP or UDP, the web proxy would not be used. In practise this could mean that a slightly more open egress would cause the connection to fail. I have seen instances where even though the TURN transport was set to TCP, a UDP connection check was sent to the TURN server, if this succeeded, the TCP transport would not be used properly. I think that behaviour is buggy in Chrome but have not had resources to follow up completely. 

Warren   

.   

[SProgrammer]

Hello Warren,

Thank you for your feedback, please find my reply as below:

1. are A and B using the same type of web proxy and configuration? 

> NO

> A is the problem (Enterprise users, restricted network, Skype works, Google hangout works, AppRTC/Turnserver do not work) 

> B has no problem (me, without any proxy / no firewall/ no packets filtering at all, sitting in no natted public IP with my Laptop)

2. Is the port being used to connect to the TURN server configured for CONNECT method in the proxy (like SSL)

> i have auxiliary listening mode enabled (TCP 80, 3478)

> but not exactly like SSL

3. Are you using TLS to the TURN server or at least TCP.   

> TCP only 

> no TLS

> no DTLS

4. Is any advanced SSL protocol support (SSL Accelerator or protocol inspection) being used at A

> Location A is Enterprise network maintained by other network admin, i am not sure exactly what they are doing. 

But my experience tells that they are filtering what protocol is used etc

In my testing, the only successful config was to use port 443 or another port configured to support proxy CONNECT. (Forcing TCP transport is mandatory) 

Where SSL support is in place, TLS must be used as the devices often just assume traffic on 443 is SSL and will break/block non TLS.

> i have used port 80 (not 443), so no TLS and no SSL for Turnserver interconnect

Also the web proxy will only be used if all other methods to reach the TURN server fail. 

So if A could reach the TURN server via TCP or UDP, the web proxy would not be used. 

> OK - port 80 TCP basically reachable via proxy or without proxy from A (while using telnet or netcat ) but general AppRTC call unable to reach port 80 TCP (by following the calling flow)

In practise this could mean that a slightly more open egress would cause the connection to fail. I have seen instances where even though the TURN transport was set to TCP, a UDP connection check was sent to the TURN server, if this succeeded, the TCP transport would not be used properly. I think that behaviour is buggy in Chrome but have not had resources to follow up completely.

> i think this could be a BUG from Chrome (while using Proxy server in Chrome it does not behave properly)

> let me explain why it is BUG. When Chrome browser using Proxy parameters you can still browse or telnet the turnserver via port 80 TCP and Chrome reads normal ASCII reply "Turn server" , in the turnserver log, also i can see "A" was connected in port 80 . But having same Proxy parameters, when AppRTC/WebRTC is used then "A" is not sending any single packets to turn-server on TCP 80 , which should not happen and nothing related to SSL/TLS i pressume, because without AppRTC/WebRTC it was able to telnet/crawl TCP port 80

 

> tested in M34, M36

Reg

Shamun

[Warren McDonald]

OK So from you answers it is likely that there are 2 reasons why this is not working.

1. TCP port (80) you are using for TURN is open to the browser with using the proxy

If this is the case the WebRTC ICE process TURN connection to port 80 will likely test OK. If it does, it will not use the web proxy. To tell if this is the case you need to know the external addresses of the web proxy and the default router at network A. Then check the TURN logs to see if any connection attempt came.   

2. The web proxy is not configured to support CONNECT on port 80

This is most likely the case. If the connection to TURN has no path other than through the web proxy, the browser will try to set up a tunnel to the TURN server through web proxy. This requires the connect method. Most proxies would not have that enabled for port 80. 

In Squid for example the default config is to only support CONNECT on ports defined as SSL. Other proxies are similar.  

Don't be fooled by the browser being able to just load the TURN server default page on port 80 through the proxy. That is a standard HTTP request, not the type used to connect to TURN.

Warren  

[Warren McDonald]

See my post in this thread https://groups.google.com/forum/#!topic/turn-server-project-rfc5766-turn-server/CZI4yQffqvI

[Shamun Toha Md]

OK - Thank you very much. I understand now i have to use 443 CONNECT method with SSL/TLS (and drop the use case of 80 in such environment, because there only CONNECT method should work)

Reg

Shamun

[Warren McDonald]

You could probably get away with using port 443 TCP to TURN, without the TLS, which is still buggy.

The important thing is to be using a target port which the proxy can use CONNECT method.   See http://wiki.squid-cache.org/Features/HTTPS

 for brief explanation of CONNECT Method.

Warren 

[SProgrammer]

Excellent. Many many thanks