TURN Servers: How STUN, NAT Traversal, ICE, and Strict Firewalls Work

WebRTC is often described as peer-to-peer, but the internet is full of NAT devices, carrier-grade NAT, enterprise firewalls, VPNs, and deep packet inspection systems. TURN and STUN are the technologies that help browsers and real-time applications discover whether a direct media path is possible or whether media must be relayed through a TURN server.

Why TURN Exists

The original internet model assumed that devices could directly address each other. Modern networks are different. Home routers, mobile carriers, office firewalls, hotels, schools, and VPNs often hide devices behind NAT. A device may have a private address like 192.168.1.50, but the outside world only sees the router or firewall's public address.

Peer A
  |
Home NAT / Firewall
  |
Internet
  |
Enterprise NAT / Firewall
  |
Peer B

If both peers are hidden behind NAT, neither side may know how to reach the other directly. WebRTC solves this with ICE candidate gathering, STUN discovery, connectivity checks, and TURN relay fallback.

What Is NAT?

NAT, or Network Address Translation, maps a private internal address and port to a public address and port. This allows many devices to share one public IP address, but it also complicates incoming peer-to-peer connections.

Internal device:
192.168.1.100:5000

Public mapping:
203.0.113.20:62044

Common NAT Types

What Is STUN?

STUN stands for Session Traversal Utilities for NAT. It lets a client ask a STUN server, “What public IP and port do you see me using?” STUN is also used for connectivity checks and NAT binding keepalives.

Client
  |
STUN Binding Request
  |
STUN Server
  |
Returns public address:
203.0.113.20:62044

STUN does not relay media. It only helps the client discover and test possible paths. If a direct path works, STUN helps WebRTC avoid the cost and latency of relay traffic.

What Is TURN?

TURN stands for Traversal Using Relays around NAT. When direct connectivity fails, TURN provides a relay address on a public server. Both peers send media to the TURN server, and the TURN server forwards media between them.

Peer A
  |
TURN Relay
  |
Peer B

TURN is more reliable than direct peer-to-peer traversal, but it costs more because the relay server carries media ingress and egress traffic. For video applications, that bandwidth can become expensive quickly.

What Is ICE?

ICE, or Interactive Connectivity Establishment, is the WebRTC process that gathers candidates, exchanges them with the remote peer, tests connectivity pairs, and selects the best working path. ICE uses STUN and TURN together.

TURN Allocation: What Happens Under the Hood

1. Allocate: the client asks the TURN server for a relay address.
2. CreatePermission: the client authorizes traffic from a remote peer.
3. ChannelBind: the client can bind a channel for lower-overhead relay traffic.
4. Media relay: media packets flow through the TURN server.

Allocate
CreatePermission
ChannelBind
Media Relay

TURN Transport Options

How TURN Gets Through Strict Firewalls

Some corporate networks block UDP, STUN, DTLS, and unknown high ports. They may only allow TCP 443 for HTTPS-like traffic. In those environments, WebRTC may fail unless the application can fall back to TURN over TLS.

Client
  |
TCP 443 / TLS
  |
TURN Server
  |
Media Relay to remote side

TURN/TLS is often the last-resort path that allows media to work through hotels, airports, schools, hospitals, enterprise offices, and locked-down Wi-Fi networks.

Deep Packet Inspection and WebRTC

Some enterprise firewalls and security appliances do more than block ports. They inspect traffic behavior. DPI systems may attempt to classify STUN, TURN, DTLS, RTP, or WebRTC traffic. This can cause intermittent behavior: signaling works, the stream appears to start, but media fails or disconnects.

VPN Effects on WebRTC

VPNs can improve privacy, but they can also change WebRTC routing. A VPN may force all media through a different network path, increase latency, hide local candidates, block UDP, or cause relay-only behavior.

VPN ON:
relay-only path
higher RTT
possible packet loss

VPN OFF:
host + srflx candidates
lower latency
more direct path

TURN Capacity and Cost Planning

TURN is not free from an infrastructure perspective. Relayed media flows through the TURN server, so the server pays bandwidth in both directions.

100 viewers
2 Mbps each
= 200 Mbps outbound

TURN relay traffic:
ingress + egress

TURN Services and Providers

Real-World TURN and STUN Troubleshooting

Many WebRTC issues are not caused by the application itself. They are often the result of NAT behavior, firewall restrictions, VPN software, TURN misconfiguration, enterprise security appliances, or expired credentials.

Problem: No Relay Candidates Appear

Host Candidates: YES
Server Reflexive: YES
Relay Candidates: NO

Possible causes include expired TURN credentials, wrong username or password, unreachable TURN server, blocked TURN ports, DNS failure, TLS certificate problems, or an offline TURN service.

Problem: Only Host Candidates Appear

Host Candidates: YES
Server Reflexive: NO
Relay Candidates: NO

This usually means STUN cannot reach the public internet. UDP may be blocked, a VPN may be interfering, or the STUN server may not be reachable.

Problem: ICE Connection Failed

iceConnectionState = failed

Check whether any candidate pair succeeded. If both sides are behind symmetric NAT or the firewall blocks connectivity checks, the connection may fail unless TURN relay is working.

Problem: Works at Home but Fails on Corporate Wi-Fi

Corporate networks often block UDP media, STUN, unknown TLS, or DTLS. Try TURN/TLS over port 443 and compare results against a mobile hotspot or home network.

Problem: Stream Connects Then Disconnects

Look for expired credentials, firewall idle timeout, VPN reconnects, network handoff, NAT mapping expiration, or ICE restarts in chrome://webrtc-internals.

Problem: VPN Causes Artifacts or Packet Loss

VPNs may force relay-only paths, add latency, increase jitter, or block UDP. Compare candidate types and packet loss with VPN enabled and disabled.

Problem: TURN Works on TCP but Not UDP

TURN UDP = Fail
TURN TCP = Success
TURN TLS = Success

This usually means the TURN server is reachable, but the network is blocking or filtering UDP.

Problem: TURN/TLS Fails

Check DNS, certificate chain, hostname match, firewall policy, and whether the server is actually listening on the configured TLS port.

nslookup turn.example.com
openssl s_client -connect turn.example.com:5349

Problem: Stream Uses TURN When It Should Be Direct

Check whether the app is forcing relay mode. In WebRTC, iceTransportPolicy: "relay" forces TURN-only behavior, while iceTransportPolicy: "all" allows host, srflx, and relay candidates.

Chrome WebRTC Internals Quick Checklist

• Candidate types: host, srflx, and relay.
• ICE states: checking, connected, completed, failed.
• Selected candidate pair: local and remote candidate types.
• Packet loss: packetsLost and fractionLost.
• Jitter and round-trip time.
• Bytes sent and received.
• Frames decoded and dropped frames.

TURN Server Administrator Checklist

• UDP 3478 open.
• TCP 3478 open.
• TLS 5349 or TLS 443 available for strict firewalls.
• Valid TLS certificate for TURN/TLS.
• Authentication and credential TTL working.
• DNS resolving from test networks.
• Relay candidates generated in browser tests.
• Tested behind VPN, mobile network, and enterprise firewall.
• Bandwidth capacity sized for relay traffic.
• Monitoring and logging enabled.
• Abuse prevention and rate limits configured.

The Golden Rule of WebRTC Connectivity

Almost every WebRTC connectivity issue can be narrowed down by answering three questions:

1. Which ICE candidates were gathered?
2. Which candidate pair was selected?
3. Did media flow after ICE connected?

Sources and Further Reading

• RFC 8489 — Session Traversal Utilities for NAT (STUN)
• RFC 8656 — Traversal Using Relays around NAT (TURN)
• RFC 8445 — Interactive Connectivity Establishment (ICE)
• WebRTC official site
• Coturn open-source TURN/STUN server
• Twilio Network Traversal documentation
• Metered TURN server service
• Xirsys TURN service