STUN and TURN: traverse NAT and firewalls in WebRTC
Short answer
STUN (Session Traversal Utilities for NAT) lets a WebRTC client discover its public address and attempt a direct connection. TURN (Traversal Using Relays around NAT) relays media streams when direct connection fails — common behind corporate firewalls or symmetric NAT. Together they power ICE (Interactive Connectivity Establishment), which automatically picks the best network path.
Why NAT and firewalls break WebRTC
WebRTC targets direct connections between browsers or to an SFU. Most enterprise workstations sit behind NAT or a firewall that blocks inbound connections.
Without traversal mechanisms, demos fail in production: “works at home, not at the client site”. STUN and TURN solve this at different levels.
What is STUN?
STUN is a lightweight server answering: “what is my public IP and port?”. The WebRTC client uses this to negotiate a direct connection with the peer or SFU.
- Server load: minimal (short requests, no media);
- Does not carry video or audio;
- Enough when both sides have permissive NAT;
- Insufficient alone in corporate environments.
What is TURN?
TURN is a media relay: when direct connection fails, audio and video pass through the TURN server.
- Consumes bandwidth (upstream + downstream per participant);
- Essential in B2B for external guests, remote workers, corporate networks;
- Must support UDP and TCP/TLS;
- Critical for sovereignty: streams transit the relay.
→ See video architecture.
STUN vs TURN comparison
| STUN | TURN | |
|---|---|---|
| Role | Public address discovery | Media relay |
| Carries video | No | Yes |
| Server bandwidth | Negligible | High in relay mode |
| Added latency | None | 1 server hop |
| Required in B2B prod | Recommended | Nearly mandatory |
| Location critical | No | Yes (data residency) |
How ICE uses STUN and TURN
ICE tests candidates in priority order:
- Host: local LAN address;
- Server reflexive (via STUN): discovered public address;
- Relay (via TURN): server relay when direct fails.
Network requirements for IT
A vendor must provide a complete firewall guide:
- FQDN and IP ranges for STUN and TURN;
- UDP ports (3478, dynamic RTP ranges) and TCP fallback (443, 5349);
- Connectivity test procedure (corporate workstation, 4G, VPN);
- TURN relay location (France, on-premise);
- TURN capacity sized for relay session volume.
TURN and sovereignty
TURN streams transit the relay server — critical for data residency and GDPR framing.
- Contractually define TURN relays in the DPA;
- Do not confuse “web page hosted in France” with “media relay in France”;
- Document the subprocessors chain for the DPO.
See France hosting and sovereign video cloud.
How does Leagora document STUN/TURN?
Leagora provides architecture diagrams, firewall guides, and relay location for France or on-premise deployments. The business video platform combines STUN, TURN, SFU and video API.
FAQ
Is STUN enough in enterprise?
Rarely alone. In B2B, TURN is nearly mandatory for guests behind firewalls and symmetric NAT.
Does TURN consume a lot of bandwidth?
Yes in relay mode: the server receives and forwards every packet. Size TURN separately from SFU.
Must UDP be allowed?
Ideally yes for optimal latency. If UDP is blocked, TURN must support TCP/TLS.
Where to host TURN servers?
Same policy as SFU: France, on-premise, or sovereign cloud per your DPA.
Key takeaways
- STUN = address discovery; TURN = essential B2B fallback relay.
- ICE combines both automatically.
- Require a firewall guide, documented location, and real network tests in pilot.
Contact for firewall, TURN, and SFU scoping.