How Two Devices Behind NAT Find Each Other – STUN / TURN / ICE

Modern collaborative drawing apps, video/audio calling platforms, and multiplayer games rely heavily on WebRTC (Web Real-Time Communication) to enable low-latency peer-to-peer data streams. However, because most personal devices sit behind private networks and routers, they do not inherently know their own public-facing IP addresses or whether they can accept direct inbound traffic.

This chapter explores the underlying mechanisms—STUN, TURN, and ICE—that allow devices behind Network Address Translation (NAT) barriers to discover each other, negotiate paths, and successfully establish a connection.

1. Why Do We Need STUN, TURN, and ICE? (The Problem Statement)

In a standard home or enterprise network, multiple devices (laptops, smartphones, tablets, smart TVs) share a single public IP address assigned to the local router.

The Core Communication Challenge

When Peer A (e.g., User X's iPad) wants to establish a direct WebRTC connection with Peer B (e.g., User Y's iPhone):

• Neither device knows its own public-facing IP address and port assigned by the router.
• Local private IP addresses (such as 192.168.1.15) are meaningless across the wider internet.
• Routers and firewalls block unknown incoming traffic by default, preventing direct peer-to-peer handshakes.

2. Understanding NAT (Network Address Translation)

Before examining traversal servers, it is essential to understand how Network Address Translation operates at the edge of private networks.

• Private Addressing: Devices inside a home Wi-Fi network hold local private IP addresses.
• The Router as a Translator: When a device accesses the internet, outgoing data packets pass through the router. The router replaces the device's private source IP with its own external public IP address and assigns a specific external port.
• Address Sharing: Due to IPv4 address exhaustion, thousands of individual home routers might share limited pools of public IP addresses, making incoming connections from the outside world ambiguous without helper utilities.

3. STUN: Session Traversal Utilities for NAT

What is a STUN Server?

A STUN server is an independently running external server (such as Google’s public STUN server, stun.l.google.com) deployed on the public internet.

Step-by-Step STUN Workflow

Peer A (Behind Home Router)
   |
   | 1. Sends UDP request to STUN Server
   v
Home Router (NAT Device)
   |
   | 2. Replaces private IP with Public IP:Port
   v
STUN Server on Public Internet
   |
   | 3. Inspects incoming packet source IP & Port
   v
STUN Server replies to Peer A: "From the internet's perspective, you are Public IP X, Port Y"

1. The Request: A device behind a NAT router sends a lightweight request packet to an external STUN server.
2. The Observation: The STUN server inspects the incoming packet, noting the source IP address and port as seen from the outside world.
3. The Response: The STUN server sends this public IP and port information back to the device.
4. The Outcome: The device now discovers its public-facing identity, which it can share via the signaling server to initiate an SDP (Session Description Protocol) offer.

Note: STUN servers are inexpensive to operate because they perform a single, lightweight task: echoing back the requester's external network coordinates. Large tech companies provide free public STUN servers primarily to support their own real-time communication ecosystems (e.g., Google Meet).

4. TURN: Traversal Using Relays (The Fallback Plan)

Sometimes, network configurations are too restrictive. Highly locked-down corporate networks, secure university Wi-Fi, public hotspots, and strict government firewalls may successfully yield a public address via STUN, but still block all direct inbound peer-to-peer traffic.

What is a TURN Server?

When direct peer-to-peer traversal fails completely, WebRTC falls back to a TURN (Traversal Using Relays around NAT) server.

Peer A (Strict Firewall)
   ^
   | (Relayed Stream)
   |
TURN Server (Centralized Relay in Cloud)
   |
   | (Relayed Stream)
   v
Peer B (Strict Firewall)

Operational Characteristics of TURN

• Relay Mechanism: Instead of connecting directly, both peers send their data streams to a centralized TURN server, which relays the information back and forth between them.
• Sacrificing P2P Benefits: Because data routes through a centralized cloud server, some benefits of WebRTC (such as absolute lowest latency and direct edge-to-edge routing) are diminished.
• Performance vs. Connectivity: Even though a TURN server acts like a centralized relay (similar to WebSockets), it remains optimized for real-time streaming and is still faster for video calling than traditional WebSocket relay architectures under duress.
• Resource Intensity: Unlike STUN servers, TURN servers are expensive to run and maintain because they handle heavy bandwidth loads, stream relaying, and require robust backup infrastructure.

5. ICE: Interactive Connectivity Establishment

With multiple potential paths available (direct connection, STUN-assisted connection, or TURN relay), an orchestration framework is required to test and select the optimal route. This framework is ICE.

How ICE Works

ICE is the decision-making coordinator embedded in WebRTC that systematically tests every possible network path between two peers:

1. Candidate Gathering: ICE gathers all possible addresses (local IPs, STUN-discovered public IPs/ports, and TURN relay addresses).
2. Connectivity Checks: ICE sends test packets across all gathered candidates simultaneously to determine which paths succeed.
3. Path Selection: ICE picks the fastest, lowest-latency working path—prioritizing direct peer-to-peer connections whenever possible, and falling back to TURN only when restrictive firewalls demand it.

6. Comparative Synthesis: STUN vs. TURN vs. ICE

Summary and Key Takeaways

• WebRTC Foundation: WebRTC powers modern real-time applications such as video/audio calling, collaborative tools, and multiplayer gaming.
• The NAT Barrier: Private home and corporate networks hide internal device IP addresses behind routers using Network Address Translation (NAT).
• STUN Discovery: STUN servers allow devices behind NAT routers to discover their external public IP addresses and assigned ports.
• STUN Efficiency: STUN servers are cheap to run because they merely inspect and echo back the source socket coordinates of incoming requests.
• TURN as Plan B: When strict corporate, institutional, or public firewalls block direct inbound traffic entirely, TURN servers step in as relays.
• TURN Trade-offs: TURN servers introduce higher latency, additional network hops, and considerable operating costs due to heavy data relaying.
• ICE Orchestration: ICE acts as the smart controller that gathers local, STUN, and TURN candidates, tests connectivity, and selects the optimal communication path.