Enterprise Firewall

[Matthew Robertson]

I am currently trying to enable webRTC for users that are behind an enterprise firewall that blocks all outgoing traffic on ports that are not 80 or 443. I wanted to know if it is possible to configure the rfc5766-turn-server to support this for Chrome's webRTC implementation. Any advice would be highly appreciated.

cheers,

Matthew

[Oleg Moskalenko]

Hi Matthew

You will need the following (see the README.turnserver or wiki Readme):

1) Use -p or --listening-port to set UDP and TCP client-side ports. Default is 3478, you will have to set 80 or 443.
2) Use --alt-listening-port to set TLS listening port, if you are using TLS feature.
3) If you are behind a NAT, then use -X option.
4) You will have to make sure that all clients are communicating through their relay endpoints:

  Client A connects to the TURN server at port 443 and the TURN server allocates a relay endpoint on the relay IP and port, say, 34567 (RA).
  Client B connects to the TURN server at port 443 and the TURN server allocates a relay endpoint on the relay IP and port, say, 45678 (RB).

The packets between A and B must follow the path:

A <==> TURN <==> RA <==> RB <==> TURN <==> B

See the TurnNetworks.pdf document.

RA must not send packets directly to B and RB must not send packets directly to A, RA and RB must communicate to each other. Then the scheme will work.
If your WebRTC setup can do that, then you are fine.

TURN server can just follow specs, TURN server is not a magic tool.

Oleg

[Oleg Moskalenko]

Hi Matthew

I realized that I really did not understand and did not answer your question, initially.

You are obviously talking about an "enterprise TURN server" to serve the "internal" enterprise users. To deploy such a server, you need:

1) A TURN server on the edge of the company network.
2) depending on your enterprise network and TURN server location, you may have to set the listening port as 80 or 443.
3) You will also have to set the WebRTC so that it ignores all non-TURN candidates. How to do that, you will have to consult WebRTC folks.

The TURN idea is pretty simple and flexible, so it can be figured out.

Regards,
Oleg

On Monday, June 10, 2013 8:21:15 PM UTC-7, Oleg Moskalenko wrote:

Hi Matthew

You will need the following (see the README.turnserver or wiki Readme):

1) Use -p or --listening-port to set UDP and TCP client-side ports. Default is 3478, you will have to set 80 or 443.
2) Use --alt-listening-port to set TLS listening port, if you are using TLS feature.
3) If you are behind a NAT, then use -X option.
4) You will have to make sure that all clients are communicating through their relay endpoints:

  Client A connects to the TURN server at port 443 and the TURN server allocates a relay endpoint on the relay IP and port, say, 34567 (RA).
  Client B connects to the TURN server at port 443 and the TURN server allocates a relay endpoint on the relay IP and port, say, 45678 (RB).

The packets between A and B must follow the path:

A <==> TURN <==> RA <==> RB <==> TURN <==> B

See the TurnNetworks.pdf document.

RA must not send packets directly to B and RB must not send packets directly to A, RA and RB must communicate to each other. Then the scheme will work.
If your WebRTC setup can do that, then you are fine.

TURN server can just follow specs, TURN server is not a magic tool.

Oleg


On Monday, June 10, 2013 7:09:11 PM UTC-7, Matthew Robertson wrote:

[Oleg Moskalenko]

The enterprise TURN requirements depend on what is really you would like to achieve, from the network topology point of view.

[Philipp Hancke]

3) You will also have to set the WebRTC so that it ignores all non-TURN candidates. How to do that, you will have to consult WebRTC folks.

There is currently no easy way to do this as chrome doesn't yet implement the constraint for this -- see https://code.google.com/p/webrtc/issues/detail?id=1179

Filtering out any non-relay candidates in the application is not that difficult however. Technically that is the job of the signalling edge server, so that internal users aren't forced to use the turn server whereas external users always communicate via the relay.

[Kenneth Thorman]

Hi

I have been struggling with this as well.

I have some users which are located behind a "paranoid enterprise firewall" on an enterprise network. 

They want to access our TURN/STUN server. Their firewall does not allow outbound UDP connections on port 3478, 5349 or any other ports for that matter.

So I thought that maybe I could use TCP over port 80. 

Their firewall is a "normal" stateful firewall and not a deep packet inspection firewall.

So I reconfigure my WebRTC code to something like (added text ":80" in bold)

    var STUN = {

        url: isChrome ? 'stun:turn.XXXX.XXX:80' : 'stun:23.21.150.121'

    };

    var TURN = {

        url: 'turn:h...@turn.XXXX.XXX:80',

        credential: 'XXXXXXX'

    };

    var iceServers = {

        iceServers: [STUN,TURN]

    };

...

I make sure that the firewall on the server running the rfc5766-turn-server is allowing connections on port 80 for UDP and TCP.

Then I proceed to test this setup from 2 non-restricted clients (not behind the "paranoid enterprise firewall" - so if I at least in wireshark can prove that it is using port 80 and TCP then we should try again at the clients location).

As far as I can see when sniffing the packets using Wireshark the packets still seem to be UDP packets. In other words I have not had luck forcing chrome to use TURN-TCP for relaying (various posts on the internet seem to indicate that this is not currently implemented but that this will come in the future?).

So I proceed with trying UDP on port 80 under the assumption that it might be easier to pursuade the FW admin to open for UDP outbound on port 80 that is already open for TCP outbound.

When verifying that the port 80 is indeed listening and accesible from the outside I test using Microsofts portqry.exe

=============================================

Starting portqry.exe -n turn.XXXXXXXX -e 80 -p BOTH ...

Querying target system called:

 turn.XXXX.XXX

Attempting to resolve name to IP address...

Name resolved to XXXXXXXXXXXX

querying...

TCP port 80 (http service): LISTENING

UDP port 80 (unknown service): LISTENING or FILTERED

portqry.exe -n turn.XXXXXXXXXX -e 80 -p BOTH exits with return code 0x00000002.

and the log on the turn server show

1375973894: IPv4. tcp or tls connected to: XXXXXX:7735

1375973898: TURN connection closed, user <>

So it seems like port is open and accepting connections.

Still when I try to establish a connection between 2 peers in WebRTC I do not see anything in the turnserver log.

I start the turnserver manually as root for testing purposes with the following command

turnserver -v -r XXXXX.com -X PUBLIC_IP -p 80 --no-tls --no-dtls -a -b /usr/local/etc/turnuserdb.conf -c /usr/local/etc/turnserver.conf -u XXXXXX

The log states

1375972074: RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server

1375972074: version Citrix-2.5.1.2 'Shivers'

1375972074: =====================================================

1375972074: Multithreading supported

1375972074: TLS supported

1375972074: DTLS supported

1375972074: Multithreaded relay supported

1375972074: Redis is not supported

1375972074: PostgreSQL is not supported

1375972074: MySQL supported

1375972074: OpenSSL multithreading supported

1375972074: OpenSSL version: fresh enough

1375972074: =====================================================

1375972074: ===========Discovering listener addresses: =========

1375972074: Listener address to use: 127.0.0.1

1375972074: Listener address to use: 10.36.0.16

1375972074: Listener address to use: ::1

1375972074: =====================================================

1375972074: ===========Discovering relay addresses: =============

1375972074: Relay address to use: 10.36.0.16

1375972074: =====================================================

1375972074: IO method (main listener thread): epoll

1375972074: IO method (udp listener/relay thread): epoll

1375972074: IO method (udp listener/relay thread): epoll

1375972074: IO method (udp listener/relay thread): epoll

1375972074: IO method (udp listener/relay thread): epoll

1375972074: IO method (udp listener/relay thread): epoll

1375972074: IO method (udp listener/relay thread): epoll

1375972074: IO method: epoll

1375972074: IPv4. UDP listener opened on : 127.0.0.1:80

1375972074: IO method: epoll

1375972074: IPv4. UDP listener opened on : 127.0.0.1:81

1375972074: IPv4. TCP listener opened on : 127.0.0.1:80

1375972074: IPv4. TCP listener opened on : 127.0.0.1:81

1375972074: IO method: epoll

1375972074: IPv4. UDP listener opened on : 10.36.0.16:80

1375972074: IO method: epoll

1375972074: IPv4. UDP listener opened on : 10.36.0.16:81

1375972074: IPv4. TCP listener opened on : 10.36.0.16:80

1375972074: IPv4. TCP listener opened on : 10.36.0.16:81

1375972074: IO method: epoll

1375972074: IPv6. UDP listener opened on : ::1:80

1375972074: IO method: epoll

1375972074: IPv6. UDP listener opened on : ::1:81

1375972074: IPv6. TCP listener opened on : ::1:80

1375972074: IPv6. TCP listener opened on : ::1:81

1375972074: IO method (auth thread): epoll

1375972074: IO method (nonudp relay thread): epoll

The webrtc connection/relaying never seems to be established, at least there is no activity  in the log and no video conference is established. 

If I instead omit the -p 80 parameter and then remove :80 in the webrtc code it works again.

Am I missing something obvious here?

Thank you in advance.

Regards

Kenneth Thorman

[Philipp Hancke]

chrome supports TURN/TCP in the upcoming M29 iirc. You need to add ?transport=tcp after the :80 in the TURN url.

[Oleg Moskalenko]

Hi Kenneth

everything looks fine in your configuration. But this output as the result of portqry.exe -p BOTH means that only TCP is reaching the port 80:

1375973894: IPv4. tcp or tls connected to: XXXXXX:7735

1375973898: TURN connection closed, user <>

If there would be a UDP packets from the fresh server start, then you would see extra lines like that:

1375976652: handle_relay_message: thrid=0x803809400: New amap 0x804030c40 for local addr XX.XX.XX.XX:80

You see, there is no UDP output. I suspect is something blocking port 80 on your server. For the TURN server, port 80 is equal to any other port, and if configured and if reachable - it will work.

By the way, an unrelated thing: parameters -b and -u must not be used together - one of them is redundant in your command line.

Regards,
Oleg

[Warren McDonald]

Not only TCP, but also the capability to use a Web proxy to tunnel connections out to a TURN server.

I just finished some testing on this today and found it to be very solid. 

On one machine, I first blocked all high UDP 49152 - 65535 in and out, and then also 3478-3479 UDP and TCP  out, so that I could be sure there was no normal communication with the TURN server, or the other PC browser.

I made sure I had ?transport=tcp on at least one TURN definition in iceServers   

I then tested without the web proxy set, and as expected the call setup failed.

The I set the Chrome browser proxy to point a squid proxy on the LAN.

This still failed, but then I did some reading on web proxies and tunnels for Websockets and similar. I found that Squid was denying the CONNECT method on all ports except those declared as SSL. This did not allow for tunneling to 3478 (or web-sockets to 8080 the signalling server)

So I removed that deny directive, restarted Squid, and calls then started working with all of the other blocks still in place.

I used tcpdump on both the Squid and TURN servers, to ensure that all was expected, and saw all packets from the blocked machine were being tunnel through the web proxy and out to 3478 TCP on the TURN server. The other end was communicating using standard TURN UDP relay ports returned in the ICE candidates.  

     

Without getting carried away, this made me very, very happy. I have been struggling with IT Depts in health environments for years to get the correct network setup in place to allow decent desktop video for clinicians to be able to do video consults from their regular PC equipment. This proxy solution, with good TCP support on the TURN server, thank you Oleg, now only requires very minor network adjustment to allow WebRTC communications in these domains.

Cred to Justin and crew for getting this pushed through.

Warren 

[Oleg Moskalenko]

That's a good experience to share, Warren.

As for the CONNECT blocked on all ports except the ones for SSL, the TURN server can listen on 443 port, too, if configured. In the 2.6.1.X versions, the TURN server can be configured with "auxiliary" listening endpoints. You can still use 3478 as the main default listening port, but you can additionally configure ports 80, 8080, 443 and whatever as auxiliary listening ports, in the same TURN server instance. It will treat them all equally (except for some balancing functionality and except for the CHANGE_REQUEST request for STUN 5780 / classic STUN functionality). So if you add 443 as auxiliary endpoint on the TURN server, and if you use 443 as the TURN server port in the WebRTC configuration, then you may not need to change the Squid setup.

Regards,
Oleg