networks//NAT//NAT traversal

NAT traversal is the set of techniques that let two devices, each behind its own NAT, exchange packets directly without opening a port on either router. Peer-to-peer calls, games and mesh VPNs such as Tailscale use it so that traffic between two of your devices goes the short way instead of through a server.

NAT traversal is the set of techniques that let two devices, each behind its own NAT, exchange packets directly without opening a port on either router. Peer-to-peer calls, games and mesh VPNs such as Tailscale use it so that traffic between two of your devices goes the short way instead of through a server.

The usual method over UDP is hole punching, and it works in three moves. Each device first asks a public server what address and port its packets come from; the protocol for that question is STUN, and the answer is the outside half of the NAT entry the question itself just created. The two devices then swap those answers through a channel they can both already reach (a coordination server). Finally both send packets to each other's outside address at about the same time. The first packet from each side may be dropped by the far NAT, but it leaves an entry in its own NAT that matches the other side's packets, so the next ones get through in both directions.

Each side opens its own door by knocking on the other's.

A NAT admits a packet only from an address its inside has already written to. When both sides write to each other, both NATs hold the entry the other needs, and no router was configured.

It depends on endpoint-independent mapping: the outside port learned from the STUN server must be the same one the NAT uses towards the peer. A symmetric NAT assigns a new outside port per destination, so the learned address is wrong for the peer and the packets never meet. Some implementations then guess nearby ports; the reliable answer is a relay.

The relay is the fallback that always works, because both devices dial out to it over ordinary outbound connections. Tailscale's relays (DERP) carry traffic over HTTPS on port 443, so they pass even networks that block UDP; the cost is latency and the relay's bandwidth, never confidentiality, since the packets inside are still end-to-end encrypted.

The mapping has to stay alive. NAT entries for UDP expire after a short silence, so a traversed path is kept open with small periodic packets while it is in use and rediscovered after it lapses.

The canonical description of the method is Ford, Srisuresh and Kegel's 2005 paper on peer-to-peer communication across NATs; the NAT behaviours it depends on are classified in RFC 4787.