How Does NAT Traversal Connect Devices Behind Routers?

NAT Traversal Explainer

NAT traversal is the set of techniques that helps two devices communicate when one or both sit behind a network address translator. A home or office router commonly gives local devices private addresses and creates temporary public address-and-port mappings for outbound traffic. That conserves public addresses and hides internal addressing, but it also means a remote device cannot simply send a new packet to the private address. Real-time applications such as voice calls, video meetings, and peer-to-peer data transfer must discover usable paths through those mappings or fall back to a relay.

Interactive Connectivity Establishment, or ICE, organizes this process. Each endpoint gathers candidate addresses that might receive traffic. Host candidates represent local interfaces. Server-reflexive candidates describe public mappings learned through a STUN server. Relayed candidates come from a TURN server that is prepared to forward traffic. The endpoints exchange candidate information through the application’s signaling channel, form candidate pairs, and run authenticated connectivity checks. A successful pair proves that packets can travel over that route under the current network conditions.

STUN supplies the public view. An endpoint sends a binding request to a STUN server on the Internet, and the response reports the source address and port that the server observed. That server-reflexive address reflects the router’s current mapping, not a permanent identity or a tunnel. STUN by itself does not guarantee that another endpoint can use the mapping, because translators and firewalls differ in how they create, filter, and expire state. ICE therefore treats STUN as one tool and verifies each proposed path rather than assuming a discovered address will work.

Connectivity checks also coordinate which path the two endpoints should select. Both sides send STUN-based checks over candidate pairs, follow ICE priorities and roles, and nominate a working pair. The traffic used for checking helps create or refresh the necessary NAT state. When a direct path works, media or data can flow between endpoints without passing through an application relay. The connection must still keep mappings alive as needed and react if the network changes—for example, when a phone moves from Wi-Fi to cellular service or a router replaces its mapping.

Some networks will not permit a dependable direct path. A symmetric mapping policy, restrictive firewall, incompatible address family, or blocked UDP can defeat otherwise valid candidates. TURN handles that case by allocating an address on a reachable relay server. Each endpoint communicates with the relay, which forwards packets between them. Relaying adds bandwidth cost, latency, and an additional service dependency, but it provides a predictable route when direct traversal fails. Well-designed applications gather relay candidates early enough that failure of direct checks does not cause a long, confusing pause.

NAT traversal is not a way to ignore security policy. ICE checks must be authenticated as specified so an attacker cannot casually redirect traffic, and the application still needs encryption, identity checks, consent, rate limits, and abuse protection. Candidate exchange usually travels through a separately authenticated signaling service, but that service does not carry the media simply because it introduced the endpoints. Privacy settings may limit which local addresses are exposed, so implementations balance path discovery with unnecessary network disclosure. Mappings can expire, enterprise networks can require proxies, and IPv6 may reduce address translation without eliminating firewalls or path discovery. Implementations also protect STUN and TURN infrastructure against amplification, credential theft, and relay abuse. Applications monitor the selected path and can restart ICE when connectivity is lost or the network interface changes. The enduring lesson is that endpoints cannot infer reachability from an address alone. ICE combines candidate discovery, verified connectivity checks, prioritized path selection, and a relay fallback to turn uncertain network boundaries into a connection that applications can actually use.