Mastering NAT Traversal: From Firewalls to Peer‑to‑Peer Connections

Translator's Preface

Imagine two LAN machines in Beijing and Shanghai, each with private IPs but internet access—how can they communicate directly without a costly relay server?

If you understand basic networking and protocols, you’ll see this is possible; implementing the techniques described yields an enterprise‑grade NAT/firewall traversal tool.

1 Introduction

1.1 Background: IPv4 address shortage and NAT

IPv4 scarcity led to NAT, which translates private source IP+port to a public IP+port for outbound traffic and reverses the process for inbound traffic.

1.2 Requirement: Peer‑to‑peer connection through NAT

Two NATed machines need a direct connection; WireGuard tunnels are one solution, but the underlying techniques apply to WebRTC, VoIP, and games.

1.3 Solution: NAT traversal

1.3.1 Prerequisites: UDP + socket control

Designing your own traversal protocol requires UDP and direct socket control; TCP adds unnecessary complexity.

1.3.2 Fallback: Relay

If direct access is impossible, a local proxy can relay traffic, preserving NAT traversal while requiring no app changes.

2 Traversing Firewalls

2.1 Stateful firewalls

Most firewalls allow all outbound connections and block inbound ones, but they track state so a response to an outbound packet is permitted.

2.2 Firewall orientation and traversal strategies

When both sides have the same orientation, the client can connect directly to the server; when orientations differ, both sides must initiate connections simultaneously to open holes in their firewalls.

2.3 Considerations

Both sides must be alive and send packets nearly simultaneously.

Firewalls may drop inactive connections, so keepalive packets are needed.

3 The Essence of NAT

3.1 NAT devices as enhanced firewalls

NAT modifies packet addresses in addition to stateful filtering.

3.2 SNAT vs. DNAT

Only source NAT (SNAT) affects traversal; destination NAT (DNAT) does not.

3.3 SNAT purpose

SNAT allows many private devices to share a few public IPs, mitigating IPv4 scarcity.

3.4 SNAT process example

A laptop sends a UDP packet; the home router performs SNAT, mapping the private address to a public IP+port, and rewrites returning packets accordingly.

4 Traversing NAT + Firewalls: STUN

4.1 STUN principle

A client asks a STUN server what public IP:port it sees, then shares that information with its peer.

The STUN protocol includes additional features like obfuscation and authentication, but they are irrelevant for simple address discovery.

4.2 Sharing the same socket

Both the main protocol and NAT traversal must use the same socket so the NAT mapping applies to all traffic.

4.3 STUN limitations

STUN works for most home routers but fails with many enterprise‑grade NAT gateways.

5 NAT Terminology

5.1 Early terms

Full Cone

Restricted Cone

Port‑Restricted Cone

Symmetric NAT

5.2 Recent research

New terminology distinguishes Endpoint‑Independent Mapping (EIM) from Endpoint‑Dependent Mapping (EDM).

5.3 Cone classification

Combines NAT mapping behavior with stateful firewall behavior, yielding four cone types.

5.4 Simplified NAT classification for traversal

EIM vs. EDM (dst‑IP only)

Firewall yes / Easy NAT / Hard NAT

5.5 Further RFC references

RFC 4787 (UDP NAT behavior)

RFC 5382 (TCP NAT behavior)

RFC 5508 (ICMP NAT behavior)

6 Fallback to Relays When STUN Fails

6.1 Problem recap and relay fallback

If direct traversal fails (e.g., hard NAT), a relay (TURN or DERP) can guarantee connectivity, albeit with higher latency.

6.2 Relay protocols

TURN: classic relay protocol, not used by Tailscale.

DERP: Tailscale’s own HTTP‑based encrypted relay.

6.3 Summary

With relays, success rates rise to ~90% direct and ~10% via relay.

7 Enterprise‑grade NAT Traversal Enhancements

7.1 Bruteforce port scanning for hard NAT

By sending packets to many ports, a client can discover the correct mapping, though it may be slow and trigger IDS.

7.2 Birthday‑paradox improvement

Opening multiple sockets on the hard side and probing randomly reduces discovery time dramatically.

7.3 Dual hard NAT scenario

Both sides hard NAT dramatically increases the search space, requiring many probes for reasonable success.

7.4 Port‑mapping protocols (UPnP, NAT‑PMP, PCP)

If a NAT supports these, a client can request a public port mapping, simplifying traversal.

7.5 Multiple NAT negotiation

Multiple NAT layers are transparent; only the outermost layer matters for the peer.

7.6 Carrier‑grade NAT (CGNAT)

CGNAT adds another NAT layer beyond the home router; hairpinning and port‑mapping may or may not be available.

7.7 IPv6 networks

Even with IPv6, stateful firewalls still require traversal techniques; ICE still applies.

7.8 Integrating all methods into ICE

ICE gathers all possible candidate addresses (LAN, WAN, STUN, port‑mapping, relay) and probes them, selecting the best path based on latency and success.

7.9 Security

Upper‑layer protocols must provide encryption and authentication; traversal traffic should also be protected.

8 Conclusion

Implementing the described techniques yields a robust NAT traversal solution that achieves direct peer‑to‑peer connections in most scenarios, with relays as a reliable fallback.