How NAT Traversal Really Works: A Practical Guide to Reaching Devices Behind the Scenes

Source: Dev.to

Introduction

If the internet looks like a giant connected graph, the reality is much more fragmented. Most devices today sit inside private networks, separated from the public internet by routers performing Network Address Translation (NAT). NAT solved the IPv4 address shortage, but it also broke the original design idea that any two hosts should be able to talk directly without extra machinery.

NAT Basics

• Original model – Every device had a globally routable IPv4 address.
• Problem – Four billion addresses proved insufficient.
• Solution – NAT lets many private devices share a single public IP by tracking connections and rewriting packets.
• Result – Private ranges such as 10.0.0.0/8 or 192.168.0.0/16 became the norm, and home routers act as stateful firewalls.

How NAT Works

When a packet leaves the local network, the NAT router:

1. Records a flow entry (the five‑part identifier):
   • Source IP
   • Source Port
   • Destination IP
   • Destination Port
   • Transport Protocol (TCP/UDP)
2. Rewrites the source IP and port to the router’s public address and a chosen public port.

Returning packets that match an existing entry are allowed through; everything else is dropped.

Types of NAT Mapping

Filtering rules also vary: some NATs allow packets from any source once a mapping exists, while others restrict traffic to the original remote IP/port.

Hole Punching

A timing‑based trick that creates matching outbound entries on both NATs:

1. Each peer contacts a STUN server to discover its public IP and port.
2. A signaling channel exchanges these addresses.
3. Both peers simultaneously send packets toward each other.

If the packets arrive while the NATs still have the outbound state, the inbound packets are considered part of an existing flow and are let through.

• UDP works best because it is connectionless.
• TCP can use simultaneous open, but many NATs do not handle it well.

Hairpinning (NAT Loopback)

When two devices behind the same router try to communicate using their public addresses, the router must translate the traffic and loop it back inside. Not all consumer routers support hairpinning, which is why frameworks like ICE first test local addresses before falling back to public ones.

STUN – Session Traversal Utilities for NAT

STUN servers answer questions such as:

• “What is my public IP and port?”
• “How does my NAT behave?”

STUN also helps keep NAT mappings alive by sending periodic keep‑alive requests.

TURN – Traversal Using Relays around NAT

If direct communication fails, TURN provides a relay:

• Allocates a public address on the TURN server.
• Forwards packets between peers.

This adds latency but guarantees connectivity, especially in restrictive corporate or mobile networks.

ICE – Interactive Connectivity Establishment

ICE orchestrates the whole process:

1. Gather candidates – local addresses, STUN‑derived public addresses, TURN relay addresses.
2. Connectivity checks – test each pair of candidates.
3. Selection – choose the best route (local → hole‑punched → relay).

The goal is to try the cheapest, lowest‑latency path first and fall back only when necessary.

Port‑Mapping Protocols

Some routers expose APIs that let applications request inbound mappings directly:

• UPnP IGD
• NAT‑PMP
• PCP

These work only when the user’s router is the sole NAT in the path. In ISP‑managed environments, an upstream NAT often blocks them.

Carrier‑Grade NAT (CGN)

ISPs place entire neighborhoods or buildings behind a single public IP (CGN). In such setups:

• Home routers cannot expose services because the ISP’s NAT blocks unsolicited traffic before it reaches the customer premises.
• Traversal success depends on the carrier’s handling of mapping and hairpinning, which is far less predictable.

IPv6 Considerations

IPv6 eliminates address scarcity, giving each device a globally reachable address. In theory, this restores end‑to‑end connectivity, but:

• Firewalls still filter inbound traffic.
• Peer‑to‑peer systems still need a way to request inbound permission.

IPv6 adoption is uneven, so IPv4‑based workarounds will remain for years.

Building a Robust NAT‑Traversal Implementation

A typical implementation includes:

• UDP‑based communication as the primary transport.
• Access to STUN servers for public address discovery.
• A TURN relay fallback for unrecoverable cases.
• A signaling channel (WebSocket, SIP, etc.) to exchange candidates.
• A strategy for keeping NAT ports alive (periodic keep‑alives).
• Regular connectivity checks to adapt to network changes.
• End‑to‑end encryption for data safety.

Applications usually start with the slowest but guaranteed method (TURN) and upgrade to direct paths as better routes become available.

Real‑World Usage

• WebRTC embeds ICE in browsers, enabling peer‑to‑peer video, audio, and data.
• Mesh networking tools use similar logic to connect devices without manual configuration.
• Some tunneling utilities create a secure path around the NAT instead of through it.

Conclusion

NAT traversal is a response to a problem created by necessity. IPv4 exhaustion forced the internet to adopt NAT, which broke the original end‑to‑end model. Traversal techniques restore the illusion of a globally connected network by using clever timing, discovery, and fallback mechanisms. Until IPv6 dominates, these mechanisms remain essential for every smooth video call, multiplayer game, or peer‑to‑peer transfer.

How does NAT traversal work? – By discovering public endpoints, creating temporary NAT state through coordinated outbound traffic, and, when needed, falling back to relays, all orchestrated by protocols such as STUN, TURN, and ICE.