1. Home
3. Guides
5. Privacy & security
7. NAT and firewall traversal

Navigating a corporate or restrictive network

Corporate companies deploy firewalls at the boundary between the company's internal network and the external network, typically the internet. These firewalls inspect incoming and outgoing network traffic, acting as a filter to allow or block packets based on predefined rules. To assist our customers that work with companies with restrictive firewalls, we offer three solutions:

1. IP allow list: Specify a list of hostnames that a network administrator should not block access to
2. IP proxy: Route the signaling traffic via a self-hosted transparent IP proxy
3. Self-hosted TURN: Override Daily's default TURN URLs with a self-hosted TURN server URL

IP allow list

Daily uses a variety of domains, IP addresses, ports, and protocols to connect participants in a call. If you're trying to make calls to and from a network behind a corporate firewall, or through a corporate's Virtual Private Network (VPN), you'll need to make sure to configure the corporate network to allow a set of domains and IP addresses.

IP proxy for signaling and self-hosted TURN for media

If Daily domains are blocked by a corporate security policy, you can fall back to routing Daily's traffic through your own web and media proxy. In this case, you must install your own HTTP and Websocket Proxy (IP Proxy) to proxy the signalling traffic and your own TURN server to proxy the media. Further, the IT administrator of the corporate network would need to allow traffic through to the self-hosted IP Proxy and TURN server.

Daily offers the ability to easily configure these workarounds via daily-js:

• setProxyUrl() lets you route requests for Daily endpoints through your proxy server.
• setIceConfig() lets you add to, or override, the list of TURN servers used.

Advanced troubleshooting: More about the WebRTC protocol

If your end user is having trouble connecting to calls over a complex network configuration, it may help to understand what's happening at a lower level so you can make appropriate configuration changes.

WebRTC calls use at least two network connections. The first is to a signaling server (usually using HTTP or WebSockets) to exchange session information. The second is a direct connection between particpants (peer-to-peer) or a Selective Forwarding Unit (SFU) server. All of the media (audio and video) between the particpants flows over that second connection.

On peer-to-peer calls, you'll observe a separate, direct connection to each person for sending and receiving media. In SFU mode, calls still use those same connections. But instead of connecting directly to each participant, the participant’s device creates a peer-to-peer connection with a central server that in turn distributes the media to the other participants. You can read more details about WebRTC call topology and our global architecture in our guide on video call architecture.

To establish a media connection, the clients use the framework called Interactive Connectivity Establishment (ICE) to find the most appropriate connection path. ICE is a suite of protocols that help with discovering, checking, and establishing the connection between clients. There are two protocols that make up the ICE framework:

• Session Traversal Utilities for NAT (STUN)
• Traversal Using Relays around NAT (TURN)

The STUN protocol discovers available IP addresses by connecting to a publicly-addressable STUN server and asking the STUN server to echo back the source IP address. This is known as a binding request. The STUN server's response to the request is known as a binding response. The binding response contains the public-facing IP address of the requesting client. The clients then exchange those public-facing addresses and try to open a direct connection to each other or to the SFU, depending on the call mode.

Sometimes, the STUN procedure of checking IP addresses does not result in a successful connection establishment. This is typically due to a restrictive firewall or NAT that blocks the connection to the other client or the SFU. In this case, the media needs to be routed via a Traversal Using Relays around NAT (TURN) server. The TURN servers are also publicly addressable, however, unlike STUN servers which mainly respond to pings, TURN servers are bidirectional media forwarding units. A TURN server is effectively a tunnel between the client that is behind the firewall and the outside world. This means that the TURN server's IP address masquerades as the public IP address for the firewalled client and the TURN server takes full responsibility for routing packets back and forth between the firewalled client and the other clients.

For example, If Alice and Bob cannot connect to each other because of firewalls or NATs, their clients each select a TURN server. Then, both Alice and Bob attempt to establish a connection to each other via their respective TURN servers. The first TURN connection that succeeds is then used for sending and receiving media. Any media Alice sends will get forwarded along to Bob. Any data that Bob sends to the server is also routed through that TURN server connection to Alice.

When dealing with restrictive firewalls, as long as the behavior is consistent, connectivity should be established successfully. Even if STUN fails to identify a direct connection, and TURN over UDP isn't possible, a TURN connection over TCP/TLS on port 443 should work. Such networks are unable to filter traffic running over port 443 becasue it is essentially indistinguishable from normal web traffic. While TCP is not preferred because it adds a small amount of latency on the TCP leg of the connection, but sometimes it is the only way to get media from end users behind a symmetric NAT or a stateful firewall.

To summarize, the TURN server infrastructure is hosted by Daily by default. However, if you are unable to unblock traffic to Daily domains, you can choose to host the TURN server on your own (or your customer's) infrastructure.