Understanding Network Address Translation: SNAT, DNAT, CGNAT, and NAT Traversal

In modern computer networking, Network Address Translation (NAT) is one of the foundational mechanisms enabling private IP networks to communicate across the public internet. First described in RFC 1631 and later standardized and updated in RFC 3022, NAT was introduced primarily as a mitigation strategy against IPv4 address space exhaustion.

Today, NAT operates across millions of enterprise firewalls, cloud provider NAT Gateways, Kubernetes node masquerading rules, edge load balancers, and Internet Service Provider (ISP) networks.

Understanding how NAT manipulates packet headers, tracks connection state, and impacts peer-to-peer protocols is essential for software engineers, cloud architects, and systems administrators debugging cross-network connectivity, microservice egress, and WebRTC streaming.

---

Why NAT Exists: The IPv4 Scarcity Problem

The IPv4 address space is bounded by 32 bits, yielding a theoretical maximum of (2^{32}) or approximately 4.29 billion distinct addresses. With tens of billions of connected mobile devices, cloud virtual machines, and IoT endpoints globally, assigning a unique public IPv4 address to every device is no longer practical.

To resolve this, RFC 1918 designated three private IPv4 address ranges:

• 10.0.0.0/8 (16,777,216 private hosts)
• 172.16.0.0/12 (1,048,576 private hosts)
• 192.168.0.0/16 (65,536 private hosts)

To learn how CIDR bitmasks and host boundaries are mathematically calculated across private VPCs, read our guide on Demystifying Subnetting, CIDR Notation, and IP Addressing.

Because RFC 1918 prefixes are deliberately excluded from the global Internet routing table (BGP), packets with private addresses cannot be routed across the public internet. A router or firewall sitting at the boundary between a private LAN and the public internet must perform real-time header rewriting.

---

Core NAT Variations: SNAT, DNAT, and PAT

NAT operates primarily by modifying IP header fields at OSI Layer 3 and TCP/UDP port headers at Layer 4. Because NAT rewrites packet headers, both the IPv4 header checksum and TCP/UDP pseudo-header checksums must be recalculated before forwarding to prevent packet corruption drops by downstream nodes.

1. Source Network Address Translation (SNAT)

SNAT rewrites the Source IP Address (and optionally the source port) of an outbound packet as it exits a private network boundary.

Typical Use Case

A private host (192.168.1.50) inside an enterprise network or Kubernetes cluster initiates an HTTPS request to an external server (198.51.100.25:443).

Header Transformation

• Outbound Packet (Before SNAT):
  • Source: 192.168.1.50:52100
  • Destination: 198.51.100.25:443
• Outbound Packet (After SNAT at Gateway 203.0.113.1):
  • Source: 203.0.113.1:61001
  • Destination: 198.51.100.25:443

When the external server responds, it replies to 203.0.113.1:61001. The NAT gateway consults its connection state table, replaces the destination IP and port back to 192.168.1.50:52100, and forwards the packet into the private LAN.

2. Destination Network Address Translation (DNAT)

DNAT rewrites the Destination IP Address (and optionally destination port) of an inbound packet arriving at a public edge interface.

Typical Use Case

External clients send web traffic to a public gateway address (203.0.113.1:80 or :443). The gateway rewrites the destination header to forward traffic to an internal private server (10.0.0.15:8080).

Header Transformation

• Inbound Packet (Before DNAT at Gateway 203.0.113.1):
  • Source: 198.51.100.50:41230
  • Destination: 203.0.113.1:80
• Inbound Packet (After DNAT):
  • Source: 198.51.100.50:41230
  • Destination: 10.0.0.15:8080

DNAT underpins port forwarding, reverse proxy frontends, Kubernetes kube-proxy implementations (operating in iptables, IPVS, or nftables modes), virtual IP address mapping, and many ingress architectures across private application clusters.

3. Port Address Translation (PAT) / N-to-1 Masquerade

In consumer home routers and corporate egress gateways, hundreds or thousands of internal hosts share a single public IPv4 address. Plain 1-to-1 NAT cannot scale in these environments.

Port Address Translation (PAT)—often called N-to-1 NAT, Many-to-One NAT, or IP Masquerading—multiplexes multiple internal IP addresses onto a single public IP address by assigning unique source port numbers to each outgoing active socket. PAT allocates available source ports, with operating systems typically drawing from configurable ephemeral port ranges (for example, Linux commonly defaults to 32768–60999 and Windows commonly uses 49152–65535), while dedicated NAT gateways may allocate from a broader range (such as 1024–65535).

Ephemeral Port Allocation and Capacity

Because Layer 4 port fields are 16 bits wide, a single public IP address supports up to 65,535 transport ports per protocol (TCP/UDP). Available port mappings are finite for each translated public IP, and port reuse depends on the translation tuple (protocol, source IP, source port, destination IP, and destination port) and the gateway’s NAT mapping behavior.

If (N_{\text{hosts}}) internal hosts establish (S) concurrent TCP flows, the required egress ports must satisfy available port capacity:

$$\text{Total Active Flows} = \sum_{i=1}^{N_{\text{hosts}}} S_i$$

When internal hosts generate high volumes of concurrent outbound flows that exhaust available ephemeral port mappings for a given gateway or destination, new outbound connections may fail or time out (a condition known as “SNAT Port Exhaustion”).

---

Linux Kernel Connection Tracking: Conntrack Mechanics

Underneath Linux firewalls (iptables and nftables), NAT is stateful and relies on the netfilter connection tracking module (netfilter conntrack / nf_conntrack).

Conntrack Tuple State

For every active network flow, conntrack stores a tracking entry containing both original and reply 5-tuples, along with protocol state (e.g., TCP state machines), timeout counters, and NAT metadata:

Flow Phase	Source IP	Source Port	Destination IP	Destination Port	Protocol
Original Direction	192.168.1.50	52100	198.51.100.25	443	TCP
Reply Direction	198.51.100.25	443	203.0.113.1	61001	TCP

When a packet traverses the Linux netfilter stack:

1. PREROUTING: Inbound packets are checked against conntrack state tables and destination NAT rules (DNAT) before routing decisions occur.
2. Routing Decision: The kernel evaluates destination IP addresses to decide whether to route the packet locally or forward it to another interface.
3. FORWARD: Packets being routed between different network interfaces pass through filtering rules in the FORWARD chain.
4. POSTROUTING: Outbound forwarded packets undergo source NAT (SNAT / MASQUERADE) processing immediately before departing the egress interface.

Example Configuration

Note on Modern Tooling: While iptables remains widely supported (often through the iptables-nft compatibility layer on top of nftables), modern Linux distributions are transitioning to nftables as the primary firewall framework. Additionally, for a Linux host to act as a NAT router, IP forwarding must be enabled in the kernel (sysctl -w net.ipv4.ip_forward=1, which applies temporarily until reboot, or permanently via /etc/sysctl.conf / /etc/sysctl.d/) and appropriate FORWARD chain rules must permit the traffic.

# Enable IP forwarding in the Linux kernel (runtime setting)
sysctl -w net.ipv4.ip_forward=1

# Enable SNAT for outbound traffic on eth0 using a fixed public IP
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j SNAT --to-source 203.0.113.1

# Enable IP Masquerading for dynamic WAN IPs
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Enable DNAT / Port Forwarding for inbound web traffic to an internal container
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.15:8080

# Allow forwarded traffic for established connections and new DNAT flows using modern conntrack match
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp -d 10.0.0.15 --dport 8080 -j ACCEPT

To explore how Layer 4 load balancers leverage NAT and Direct Server Return (DSR) to route million-RPS traffic, see our guide on Layer 4 vs Layer 7 Load Balancing.

---

Carrier-Grade NAT (CGNAT) & Dual-Stack Lite

As IPv4 addresses became critically scarce, mobile operators and consumer ISPs implemented Carrier-Grade NAT (CGNAT)—also known as Large-Scale NAT (LSN) or RFC 6598 NAT.

The RFC 6598 Shared Address Space (100.64.0.0/10)

Instead of assigning a globally unique public IP to subscriber modems or mobile devices, ISPs allocate addresses from the dedicated RFC 6598 Shared Address Space (100.64.0.0/10, spanning 100.64.0.0 through 100.127.255.255). This address space is distinct from RFC 1918 private IP space and is intended specifically for service provider infrastructure.

Challenges Introduced by Double NAT / CGNAT

1. Inaccessible Inbound Services: Inbound services, self-hosted VPNs, and standard port forwarding are generally unavailable without additional mechanisms such as reverse tunnels (e.g., WireGuard/Tailscale relays or SSH reverse tunnels), third-party relay services, or requesting a dedicated static public IP from the ISP.
2. Reputation Collateral Damage: If one compromised device behind a shared CGNAT public IP engages in malicious activity or spamming, security filters block the shared IP, impacting thousands of innocent subscribers behind the same CGNAT pool.
3. P2P Degradation: Peer-to-peer applications, VoIP (SIP), multiplayer gaming, and WebRTC streaming suffer severe latency or connection setup failures.

---

NAT Traversal Techniques: STUN, TURN, and ICE

Because hosts behind symmetric NATs or CGNAT cannot receive unsolicited inbound packets, peer-to-peer protocols require specialized NAT Traversal protocols to negotiate direct media streams.

1. STUN (Session Traversal Utilities for NAT)

STUN (RFC 5389) allows a client behind a NAT to discover its server-reflexive transport address (its public IP and port binding as seen by external hosts) by querying an external STUN server.

1. Client sends a binding request to a public STUN server (stun.l.google.com:19302).
2. STUN server inspects the incoming packet header and returns a response containing the client’s server-reflexive address in an XOR-MAPPED-ADDRESS attribute (203.0.113.1:61001).
3. Client uses this discovered server-reflexive address to coordinate P2P connections with remote peers.

2. TURN (Traversal Using Relays around NAT)

When clients sit behind restrictive Symmetric NATs (where each destination host receives a distinct port mapping), direct P2P connections fail.

TURN (RFC 5766) serves as a fallback relay mechanism. Both clients connect to a mutually accessible cloud relay server. All encrypted media packets flow through the TURN server, sacrificing direct P2P latency guarantees to maximize connectivity when direct peer-to-peer communication is not possible.

3. ICE (Interactive Connectivity Establishment)

ICE (RFC 8445) systematically evaluates candidate connection paths (Local Host, STUN Server-Reflexive, and TURN Relay) in order of preference, selecting the most direct and efficient route available between two communicating peers.

---

Summary Comparison Matrix

Feature / Attribute	Source NAT (SNAT)	Destination NAT (DNAT)	Port Address Translation (PAT)	Carrier-Grade NAT (CGNAT)
Header Rewritten	Source IP Address	Destination IP Address	Source IP + Source Port	Large-scale Source NAT (IP & Port)
Primary Direction	Outbound (LAN -> WAN)	Inbound (WAN -> LAN)	Outbound Multiplexed	Outbound (Subscriber -> Internet)
Primary Purpose	Egress masking / routing	Port forwarding / Ingress	Single public IP sharing	ISP IPv4 address conservation
Address Space	Private -> Public	Public -> Private	Many Private -> 1 Public	100.64.0.0/10 -> Public
Common Use Cases	Cloud NAT Gateways, VPC Egress	Web Servers, Ingress VIPs	Home Routers, Office Firewalls	Cellular 4G/5G, Fiber ISPs

---

Conclusion

Network Address Translation remains an indispensable component of global internet infrastructure, bridging the gap between IPv4 address constraints and modern high-density cloud networks.

By understanding SNAT egress rules, DNAT port forwarding, Linux kernel conntrack state management, and WebRTC STUN/TURN traversal algorithms, developers and infrastructure engineers can effectively diagnose connectivity bottlenecks, secure cloud VPC perimeters, and architect high-performance distributed systems.