skip to content

NAT Traversal

3 roadmaps6 questions

Getting two peers behind translators to talk directly: binding discovery to learn your public mapping, hole punching to open it, and a relay when the far NAT is too strict.

on this pageshow

explore

questions

6

Why can two peers behind different NATs not open a direct connection to each other, and what do STUN, TURN and ICE each contribute?

level: juniorimportance: must knowfreq 46%

answer

  1. who must speak first
  2. no mapping for unsolicited packets
  3. the public port is unknown
  4. learn your own mapping, relay as fallback
  5. endpoints test every pairing

basics

~20 s

A NAT creates a mapping only when an inside host sends first, so each peer's NAT drops the other's unsolicited packets. STUN reveals a peer's public address and port, ICE tests the candidate paths, and TURN relays when none works.

solid answer

~50 s

A NAT translates an inside host's private address and port to a public one only after that host sends a packet out; an unsolicited packet from outside matches no mapping, or fails the NAT's filtering, and is dropped. Two peers behind different NATs are both inside, so neither can be the first to reach the other, and neither even knows which public port its own NAT chose. **STUN** (RFC 8489) lets a peer ask a public server which address and port its packets appear to come from: the *server-reflexive* address. **TURN** (RFC 8656) gives a peer a relayed address on a public server that forwards traffic for it. It is the fallback that almost always works but costs the operator bandwidth. **ICE** (RFC 8445) is the procedure that ties them together: gather host, server-reflexive and relayed candidates, exchange them, run connectivity checks on every pairing, and use the best pair that works.

go deeper

for a junior

Recall that a NAT admits inbound packets only for mappings an inside host created by sending first, then name the three pieces: STUN learns the public mapping, TURN relays, ICE tries the paths.

for a middle

Explain both gaps, the unknown public port and the closed filter, and show that STUN and TURN are protocols with servers while ICE is a procedure the two endpoints run.

for a senior

Show that the outcome depends on the pairing of both NATs' behaviours, that a relay is the only universal fallback, and that its bandwidth cost is why ICE tries direct paths first.

for a principal

Frame traversal as a budget decision: how much relay capacity to provision for the share of sessions that can never go direct, and what users experience while ICE is still testing paths.

## The problem: a NAT opens only from the inside A **Network Address Translator (NAT)** rewrites the private source address and port of an outgoing packet to a public address and port, and records that pairing as a **mapping** so it can translate the replies back. In the vocabulary of RFC 4787, a packet arriving from outside is delivered only if it matches an existing mapping *and* passes the NAT's **filtering** rule for that mapping. A packet that no inside host asked for has no mapping and is dropped. That rule is harmless for client-server traffic, because the client always speaks first. It is fatal for two **peers** that are both inside: - Peer A at `10.0.0.5:4000` sits behind NAT A, whose public address is `203.0.113.10`. - Peer B at `10.1.1.7:5000` sits behind NAT B, whose public address is `198.51.100.20`. - A packet from A to `198.51.100.20` reaches NAT B with no mapping behind it, and NAT B discards it. The same happens in the other direction. ## Why knowing the public IP is not enough Suppose each peer somehow learned the other's public IP address. Two gaps remain: 1. **The port is unknown.** NAT B chose some public port for B's traffic, and B itself does not know which one, because the translation happened after the packet left B. 2. **The filter is closed.** Unless NAT B uses *endpoint-independent filtering*, it admits packets on that port only from addresses B has already sent to. Private addresses do not help either: they are not routed across the public internet. Port forwarding would work, but it needs someone to configure each NAT by hand, which peers on networks they do not control cannot do. ## Three tools and one procedure | Piece | Specification | What it contributes | |---|---|---| | **STUN** | RFC 8489, which obsoletes RFC 5389, which obsoleted RFC 3489 | A peer sends a **Binding request** to a public server; the response reports the address and port the server saw, the peer's **server-reflexive** address. The same exchange can keep a mapping alive. | | **TURN** | RFC 8656, which obsoletes RFC 5766 | An extension of STUN: the server allocates a **relayed transport address** and forwards packets between the client and the peers it has permitted. It almost always works and costs the server's bandwidth. | | **ICE** | RFC 8445, which obsoletes RFC 5245 | The procedure that uses both: gather candidates, exchange them, run connectivity checks on every pairing, and use the best pair that works. | The difference in kind matters. STUN and TURN are protocols with servers; ICE is not a server at all, it is what each endpoint's **ICE agent** does. RFC 8489 says plainly that STUN is not a NAT traversal solution by itself, only a tool that a complete solution such as ICE uses. ## How the pieces combine 1. Each peer gathers **candidates**: its local (host) addresses, its server-reflexive address from a STUN server, and a relayed address from a TURN server. 2. The peers swap candidate lists through some **rendezvous** channel both can already reach. That signalling path is the application's own business and a separate subject from the traversal itself. 3. Each peer sends STUN connectivity checks from its candidates to the other's. An outbound check also creates the sender's own NAT mapping toward the peer, which is what **hole punching** means. 4. Pairs that complete a request and response in both directions become valid; one of them is nominated and carries the data. 5. If no direct pair works, typically because a NAT hands out a fresh public port for every new destination, the pairs that go through the TURN relay are what remain. ICE ranks direct paths first. RFC 8445's recommended type preferences put host candidates at 126 and relayed candidates at 0, so the relay is the last resort rather than the default. ## Where explanations go wrong - **Treating the STUN server as a relay.** It answers one question per request and carries no application data. - **Assuming a public IP is enough.** Without the right port and an open filter, the packet still dies at the far NAT. - **Assuming traversal needs router configuration.** ICE works with NATs as they are; port forwarding and router-side mapping protocols are a different approach. - **Assuming a direct path always exists.** Some pairings of NAT behaviours defeat hole punching, which is exactly why TURN exists. - **Assuming ICE is a fourth server to deploy.** It runs inside the two endpoints.

  • Is STUN on its own enough to connect two peers that are both behind NATs?
    No. RFC 8489 calls STUN a tool, not a NAT traversal solution by itself. A Binding response tells a peer the mapping its NAT chose toward the STUN server; whether the NAT reuses that mapping toward the peer, and whether the peer's NAT admits the packets, depends on both NATs' behaviour. RFC 5389 dropped RFC 3489's attempt to use STUN alone for exactly this reason. ICE adds the connectivity checks and the TURN fallback.
  • What changes when only one of the two peers is behind a NAT?
    The inside peer can simply connect out to the public one. When the public peer wants to start, it can ask the inside peer, through the rendezvous server, to connect outward instead; RFC 5128 calls this connection reversal. No hole punching or relay is needed for that pairing, and ICE finds the same path through its ordinary checks.

saying these in an interview costs you the question

  • If each peer knows the other's public IP address, they can simply connect.
  • The STUN server relays the traffic between the two peers.
  • TURN is just another name for a STUN server.
  • Peer-to-peer traffic needs both users to set up port forwarding on their routers.
  • ICE is a separate server you deploy next to STUN and TURN.
open as a page

How does UDP hole punching open a direct path between two peers behind different NATs, and why does endpoint-dependent ('symmetric') mapping defeat it?

level: seniorimportance: must knowfreq 37%

basics

~20 s

A rendezvous server tells each peer the other's public mapping, then both send at once, so each NAT sees an outbound session and admits replies. Endpoint-dependent mapping uses a new public port toward the peer, so the advertised address fails.

open as a page

In ICE (RFC 8445), what are host, server-reflexive, peer-reflexive and relayed candidates, and how do connectivity checks choose the pair that is used?

level: middleimportance: should knowfreq 29%

basics

~20 s

Host candidates are local addresses, server-reflexive ones are NAT mappings learned from STUN, relayed ones are TURN addresses, and peer-reflexive ones appear during checks. Agents test candidate pairs with STUN requests by priority; the controlling agent nominates one.

open as a page

How does a STUN Binding request let a host behind a NAT learn its server-reflexive address, and why does the response XOR-encode that address?

level: middleimportance: should knowfreq 31%

basics

~20 s

The STUN server copies the source address and port it saw on the Binding request, the NAT's public mapping, into XOR-MAPPED-ADDRESS. XOR-encoding hides that value from NAT ALGs that would otherwise rewrite it inside the payload.

open as a page

How does RFC 4787 describe a NAT's mapping and filtering behaviour, and why did it retire RFC 3489's full-cone, restricted-cone and symmetric labels?

level: seniorimportance: should knowfreq 27%

basics

~20 s

RFC 4787 splits NAT behaviour into mapping (when a public port is reused across destinations) and filtering (which outside senders may reach it), each endpoint-independent, address-dependent or address-and-port-dependent. RFC 3489's four labels mixed both axes and misdescribed real NATs.

open as a page

When does a TURN relay become unavoidable for two peers behind NATs, and what does relaying through a TURN server cost compared with a direct path?

level: seniorimportance: should knowfreq 24%

basics

~20 s

A TURN relay is unavoidable when no direct candidate pair passes ICE checks, typically because both NATs allocate per-destination ports and filter by port, or UDP is blocked. It costs server bandwidth, latency, per-packet overhead and credentialed state.

open as a page