Mastering NAT Traversal: Direct Peer-to-Peer Connections Across Firewalls

Introduction

Assume two machines in Beijing and Shanghai each behind NAT have private IPs but can reach the public Internet. The simplest solution is a relay server, but that adds latency and becomes a bottleneck.

We explore how to achieve direct communication without a relay, using NAT traversal techniques as described in Tailscale's extensive article.

Background: IPv4 address shortage and NAT

IPv4 addresses are scarce, so NAT (Network Address Translation) is used to map many private addresses to a few public ones. Outbound traffic is SNATed, inbound traffic is reverse‑translated.

Goal: Peer‑to‑peer connection through NAT

We aim to establish a bidirectional UDP connection between two NATed hosts, which is the basis for protocols like WireGuard, WebRTC, and others.

Prerequisites for NAT traversal

Use UDP.

Have direct control over the socket (send and receive extra packets).

Fallback: Relay

If direct traversal is impossible, a local proxy or relay can be used, though it adds latency.

Traversing Stateful Firewalls

Most firewalls allow all outbound connections and block inbound ones unless they match an existing outbound flow. By sending outbound packets first, the firewall opens a hole for the corresponding inbound packets.

Both peers must send packets simultaneously to open holes on each side.

STUN (Session Traversal Utilities for NAT)

STUN servers tell a client the public IP:port seen by the server. Clients exchange this information to know where to send packets.

STUN works for many NAT types but fails with symmetric NATs and some enterprise gateways.

Handling Different NAT Types

NAT behavior is classified as Endpoint‑Independent Mapping (EIM) or Endpoint‑Dependent Mapping (EDM). Symmetric NATs are EDM and require additional techniques.

Port‑mapping protocols (UPnP IGD, NAT‑PMP, PCP) can request a public mapping, simplifying traversal.

Hard NAT Traversal

When both sides are behind symmetric NATs, brute‑force port scanning or birthday‑paradox‑based probing can be used, though it may take minutes and generate many sessions.

Carrier‑Grade NAT (CGNAT)

ISPs often place an additional NAT layer (CGNAT). Direct traversal may still work if the NAT supports hairpinning; otherwise a relay is needed.

IPv6 and NAT64/DNS64

IPv6 eliminates NAT, but firewalls still exist. In IPv6‑only networks, NAT64/DNS64 may be present; CLAT can provide IPv4 compatibility.

ICE (Interactive Connectivity Establishment)

ICE gathers all possible local and server‑reflexive candidates (IPv4, IPv6, port‑mapped addresses) and tests each pair. The best working path is selected, with fallback to relays (DERP) and continuous probing for upgrades.

Security Considerations

Higher‑level protocols should provide encryption and authentication (e.g., TLS, WireGuard). Path‑discovery packets should also be protected.

Conclusion

By combining UDP, socket control, side‑channel coordination, STUN, port‑mapping, NAT64 handling, and ICE, a robust NAT traversal solution can achieve direct peer‑to‑peer connections in most environments, falling back to relays only when necessary.