NAT Gateways & SNAT

The internet was designed to allow any device to seamlessly communicate with any other device. But by the late 1990s, we mathematically ran out of the 4.3 billion available IPv4 addresses. Network Address Translation (NAT) is the ultimate band-aid: a mechanism that allows thousands of private devices to hide behind a single public IP address, fundamentally altering the end-to-end transparency of the internet.

Part 1: The Port Address Translation (PAT) Table

Basic NAT Maps one Private IP to one Public IP. But the NAT you use at home (or in an AWS VPC) is technically PAT (Port Address Translation) or NAPT. It maps multiple IPs to a single Public IP by hijacking the Layer 4 (TCP/UDP) port numbers.

Imagine a home network with two laptops, both with the private IP 192.168.1.10 and 192.168.1.20. Both open a web browser and connect to facebook.com:443. Locally, both operating systems randomly assign "Source Port 5000" to the outbound packet.

When these two identical packets hit the router, it cannot forward them as-is. If it did, Facebook would reply to "Port 5000", and the router wouldn't know which laptop to send the reply back to. So, the Router rewrites the packet:

• Laptop 1: 192.168.1.10:5000 is rewritten as PublicIP:50001
• Laptop 2: 192.168.1.20:5000 is rewritten as PublicIP:50002

The router meticulously records these mappings in its NAT connection tracking state table (usually maintained by `conntrack` in the Linux kernel). When the replies arrive on port 5001 and 5002, it reverses the math and forwards them accurately.

Part 2: TCP State Tracking and Timeouts

Unlike a simple IP router, a NAT Gateway is deeply stateful. It must deeply inspect every packet to understand the TCP handshake (SYN, SYN-ACK, ACK) or the teardown (FIN, RST) to manage the lifecycle of its internal tracking table.

If the NAT table fills up, the router halts and drops all new connections. Therefore, NAT devices aggressively impose idle timeouts. If a TCP connection stays perfectly completely silent for a predefined period (often 10 minutes), the NAT device assumes the connection is dead and blindly deletes the mapping to save RAM.

This is why Long-Lived connections (like WebSockets or SSH) must implement TCP Keep-Alives. By sending invisible ping packets every 60 seconds, they continuously refresh the NAT table's timeout timer, preventing the connection from being abruptly severed by an overzealous firewall midway.

Part 3: SNAT Port Exhaustion

A single IPv4 address mathematically only possesses 65,535 TCP ports. The first 1024 are reserved, leaving approximately 64,500 ephemeral ports for NAT translation. This is an absolute, unavoidable mathematical ceiling.

In large Cloud architectures (AWS/GCP), if 1,000 Private Subnet instances all use the identical NAT Gateway to scrape the web simultaneously, that NAT Gateway can only support roughly 64,000 total concurrent outbound connections to the same destination IP. Once port #64,500 is mapped, the Gateway suffers SNAT Port Exhaustion.

Any further outbound requests are instantly forcefully dropped. To fix this at enterprise scale, teams must deploy NAT Gateways with Multiple Public IPs, expanding their mathematical port pool (e.g. 2 IPs = 129,000 simultaneous connections).

Part 4: The Unexpected Security Bonus

NAT was originally engineered entirely for IP address conservation, but it accidentally created a massive security boundary. Because private internet IPs (defined by RFC 1918) are unroutable on the public internet, no external malicious actor can proactively initiate a TCP connection into a private device. The NAT Gateway will simply drop the incoming packet, because there is no entry in the PAT table telling it where to forward the inbound request.