NAT Traversal Explained: STUN, TURN, and ICE

Updated on Oct 7, 2026

10 min read

When two browsers or devices try to exchange live audio, video, or data, their network addresses may not be reachable from the public internet. NAT traversal is the set of techniques that helps those endpoints discover usable paths through address translation and firewalls. This guide explains how STUN, TURN, and ICE work together, why a direct connection is not always possible, and how to configure and troubleshoot the process in a real-time application.

What Is NAT Traversal?

Network Address Translation (NAT) lets multiple devices use private addresses while sharing one or more public addresses. A home router, for example, can translate traffic from a laptop at 192.168.1.20 to the router’s public address. When the laptop sends an outbound packet, the router records a mapping between the private address and port and the public-facing address and port. Replies matching that state can return to the laptop.

That behavior makes ordinary web browsing work, but it complicates a direct connection initiated from outside. Another device generally cannot send a packet to the laptop’s private address, and it may not know the public address-and-port mapping the router created. A firewall can also reject unsolicited inbound traffic even when a public mapping is known.

NAT traversal helps endpoints discover and test candidate network paths. It is not a way to guarantee that every pair of devices can connect directly. In WebRTC, STUN helps discover a mapped address, TURN provides a relay when direct paths fail, and ICE coordinates the candidates and tests which paths actually work. The WebRTC project uses this system as part of browser real-time communication; its protocol overview describes the surrounding transport protocols.

The Problem NAT Traversal Solves

An IP address alone is not enough to make a device reachable. A peer behind NAT may have a private address that is meaningful only inside its local network. Its public address is usually shared with other devices, and the router chooses a port mapping based on outgoing traffic. The remote peer needs a working public endpoint, and the NAT or firewall must permit packets to that endpoint.

The exact behavior varies by router and network policy. Some mappings accept traffic from a range of remote addresses; others are restricted to the address and port that the device contacted. Enterprise firewalls, carrier-grade NAT, hotel Wi-Fi, and VPNs add further constraints. Therefore, learning a mapped address does not prove that another peer can send packets through to it.

Without a traversal process, an application might fall back to sending all media through its own servers or fail to establish a session. NAT traversal gives the endpoints a structured way to try direct paths first while retaining a relay option for networks where direct connectivity is blocked.

How STUN, TURN, and ICE Work Together

The ICE standard, RFC 8445, defines a procedure for finding and checking candidate paths. It does not replace application signaling: the two endpoints still need a signaling channel to exchange session descriptions and ICE candidates. A typical setup proceeds as follows:

Each endpoint gathers local and server-assisted candidate addresses.
The application exchanges session descriptions and candidates through its signaling channel.
ICE forms candidate pairs and sends connectivity checks to test them.
The endpoints select a working pair. If direct pairs fail, a pair using a TURN relay can carry the traffic.

The steps can overlap. With trickle ICE, candidates are sent as they are discovered rather than waiting for all gathering to finish. ICE checks use STUN messages, including when checking a path that uses a TURN relay.

Mechanism	What it does	Typical traffic path	Main limitation
STUN	Reports the public-facing address and port observed by a server	Peer to peer after candidate exchange	A mapped address may not be reachable from the other peer
TURN	Allocates a public relay address and forwards traffic between peers	Peer to TURN server to peer	Adds relay bandwidth, cost, and a network hop
ICE	Gathers candidates, tests pairs, and selects a usable path	Direct or relayed, based on successful checks	Needs signaling and valid server configuration

STUN: Discovering a Server-Reflexive Address

The STUN specification, RFC 8489, defines a request-response protocol for discovering the address and port a server sees for a client. A browser can use that mapped address as a server-reflexive candidate. This is useful when the endpoint’s local address is private but the NAT mapping can also be reached by its peer.

STUN does not reserve a universal public port, authenticate the remote peer, or carry the call’s media. A mapping can depend on the destination, change over time, or be filtered by a firewall. STUN reveals a possible address; ICE connectivity checks determine whether the path works.

TURN: Relaying When a Direct Path Fails

The TURN specification, RFC 8656, defines a relay service. A client requests an allocation from a TURN server and receives a relayed candidate. The peer sends traffic to that public relay address, and the server forwards permitted packets to the client. The other endpoint uses its own candidate and connectivity checks to establish the corresponding path.

Because media or data crosses the relay, TURN consumes server bandwidth and adds a network hop. It is nevertheless necessary for reliability: symmetric NAT behavior, restrictive firewalls, or blocked UDP can make direct paths fail. A deployment can offer UDP TURN and TCP or TLS-based TURN transports to fit different network policies, provided the server and client support those options.

ICE: Choosing a Working Candidate Pair

ICE collects several kinds of candidates: host candidates from local interfaces, server-reflexive candidates discovered with STUN, peer-reflexive candidates learned during connectivity checks, and relay candidates supplied by TURN. It forms candidate pairs, prioritizes them, and tests connectivity. A successful check shows that packets can travel on that path; ICE then nominates a pair for use.

This is why configuring a STUN server alone is not a complete connectivity strategy. ICE may find a direct path on one network and need a TURN candidate on another. The chosen pair can also change as connectivity changes, and an application may restart ICE to gather and test candidates again.

Components and Key Concepts

Signaling: Application-defined exchange of offers, answers, and ICE candidates. WebRTC does not prescribe whether signaling uses WebSockets, HTTPS, or another mechanism.
Candidate gathering: Collecting local, STUN-derived, peer-reflexive, and TURN-relay addresses.
Connectivity checks: ICE probes candidate pairs to verify actual reachability through the current network path.
Nomination: Selecting a successful candidate pair for the session.
Trickle ICE: Sending candidates as they become available to reduce connection setup delay.
Relay allocation and permissions: TURN creates a relayed address and applies permissions controlling which peer traffic can use it.

NAT behavior is often described in terms of mapping and filtering behavior, but real networks do not always fit a simple taxonomy. The practical question for an application is whether a candidate pair passes ICE checks, not whether a router has a particular label.

Real-World Use Cases

Video and voice calls use ICE to attempt direct media delivery and TURN when a peer’s network blocks a usable direct route. A relay is a normal fallback, not necessarily a sign that the application is misconfigured.

Peer-to-peer data channels use the same connection establishment system for collaboration, file transfer, or sharing small real-time state updates. The signaling channel still exchanges the connection metadata; it does not have to carry the data-channel payload.

Interactive games and remote-device tools may use UDP-based peer connectivity to reduce latency or connect endpoints behind home routers. Some products instead use dedicated servers for gameplay or device access, which can simplify routing and centralize control. NAT traversal is one architectural choice, not a universal replacement for server-mediated traffic.

Getting Started and Troubleshooting

For a browser application, provide ICE server configuration when creating an RTCPeerConnection. Replace the example hostnames with servers you operate or are authorized to use. TURN credentials should be generated by a trusted application server with a short lifetime; do not embed a permanent relay password in public client code.

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.example.net:3478' },
    {
      urls: [
        'turn:turn.example.net:3478?transport=udp',
        'turns:turn.example.net:5349?transport=tcp',
      ],
      username: 'temporary-username-from-your-server',
      credential: 'temporary-credential-from-your-server',
    },
  ],
});

pc.addEventListener('icecandidate', ({ candidate }) => {
  if (candidate) {
    // Send this candidate to the other endpoint using your signaling channel.
    sendCandidateToPeer(candidate.toJSON());
  }
});

pc.addEventListener('iceconnectionstatechange', () => {
  console.log('ICE state:', pc.iceConnectionState);
});

The sendCandidateToPeer function represents application-specific signaling, not a WebRTC browser API. The receiving endpoint must add remote candidates to its peer connection after applying the corresponding remote description. For a local test, both endpoints need access to the configured STUN and TURN services; a public STUN server without TURN is not a dependable production setup.

When a connection fails, check the state at both endpoints and verify that candidates are actually exchanged. Inspect the selected candidate pair and gathering results with browser diagnostics such as chrome://webrtc-internals or Firefox’s about:webrtc. If direct candidates fail but relay candidates succeed, investigate NAT or firewall restrictions and relay performance. If relay candidates are missing or checks fail, verify TURN DNS, listening ports, credentials, certificate validity for TLS, allocation limits, and server permissions. Review firewall rules in both directions and confirm that the application is not using a relay policy that excludes TURN.

Treat relay capacity as an operational requirement. Estimate concurrent sessions and expected media bitrates, monitor allocation failures and bandwidth, and deploy relays close enough to users to avoid unnecessary latency. Configure rate limits and access controls so an unauthenticated party cannot turn the service into an open relay.

Common Misconceptions

“STUN opens a port through any NAT.” STUN reveals the mapping observed by a server. It does not make that mapping reachable through every NAT or firewall. ICE checks are still required, and TURN may be needed.

“ICE is another name for STUN.” STUN is one protocol used for address discovery and checks. ICE is the broader procedure that gathers candidates, forms pairs, tests connectivity, and selects a path; TURN supplies a relay candidate.

“Peer-to-peer means traffic never touches a server.” Signaling usually goes through an application service, and a TURN relay may carry the entire media or data flow. Even a direct WebRTC transport uses separate security mechanisms for the connection; traversal itself does not encrypt application media.

WebRTC video conferencing implementation covers peer connections, signaling, and a practical browser call.
Chat and voice communication protocols compares WebRTC with SIP and WebSocket.
Linux network troubleshooting explains commands and workflows for investigating network reachability and firewall issues.

Changelog

Initial publication.

Last updated: 2026-10-07