NAT & port translation

An IPv4 address is 32 bits long, so there can be at most 2³², or 4,294,967,296, of them. When the format was written down in RFC 791 in 1981, that looked like an absurd surplus: there were a few hundred hosts on the ARPANET. Not all of the space is usable, either. Big blocks are reserved for multicast, for private networks, for loopback and for documentation, which leaves roughly 3.7 billion addresses that can appear on the public internet.

By the early 1990s it was clear the supply would run out. The long-term fix was a bigger address, which became IPv6 (Chapter 3 covers both). The short-term fix, published in 1994 as RFC 1631, was to stop giving every machine its own public address at all. Give a whole site one address, number the machines inside with addresses nobody else will route, and have the box at the edge rewrite packets as they cross.

That box is a network address translator, and the address ranges it hides are the private blocks of RFC 1918: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Anyone may use them, as many times as they like, because routers on the public internet refuse to carry them. Millions of homes are all numbered 192.168.1.something at once, and none of them collide, because none of those addresses ever leave the house.

The short-term fix turned out to be very long-term. IANA handed out its last free blocks to the five regional registries on 3 February 2011. The registries then ran dry one after another: APNIC in 2011, RIPE NCC in 2012 (and finally completely in 2019), ARIN in 2015. Today a new ISP that wants IPv4 addresses has to buy them from someone who already has them. NAT is why that shortage is an inconvenience rather than a wall: almost every device you own is behind one, and many are behind two (Chapter 8).

The word NAT covers a few different machines. They all rewrite addresses; they differ in how many outside addresses they have to work with and whether they touch ports.

Static NAT is a fixed one-to-one pairing. Inside address 10.0.0.5 always appears outside as 203.0.113.5, and traffic to 203.0.113.5 always goes to 10.0.0.5. Nothing is shared and nothing is saved; it's used when a server must keep an internal address but be reachable at a public one.

Dynamic NAT keeps a pool of public addresses and lends one to each inside host while it is busy. Ten public addresses can serve fifty machines, as long as no more than ten talk at once.

NAPT, network address and port translation, is the one in your house. Cisco calls it PAT, port address translation; Linux calls it masquerading; most people just call it NAT. It shares a single public address among every inside device by rewriting the port as well as the address. The port is a 16-bit number in the TCP or UDP header that tells the receiving machine which conversation a packet belongs to. Port numbers exist for exactly this kind of multiplexing, and NAPT borrows them: each inside conversation gets its own public port, and that port is the key the router uses to send the replies home.

Everything a NAT knows lives in one table. Each row is a mapping, and a row is born the moment an inside device sends its first packet to somewhere outside.

Follow one. Your laptop, 192.168.1.10, opens a web page on 198.51.100.20. Its operating system picks a temporary source port, say 51000, and sends a TCP packet: from 192.168.1.10:51000 to 198.51.100.20:443. The router sees a source address that can't go out on the internet, so it looks for a row for (TCP, 192.168.1.10, 51000). There isn't one. It picks a public port, writes the row, rewrites the packet's source to 203.0.113.7:51000, fixes the checksums and sends it on.

The web server never learns the laptop exists. As far as it can tell, 203.0.113.7 opened a connection from port 51000, so that's where it sends the reply: to 203.0.113.7:51000. The router looks up port 51000 in its table, finds the laptop's row, rewrites the destination back to 192.168.1.10:51000, and the laptop receives a reply that looks exactly as if no translation had ever happened.

A connection is identified by five things: the protocol, the source address and port, and the destination address and port. That's the 5-tuple. A NAT's table is a map from inside 5-tuples to outside ones, and the replies are matched on the outside 5-tuple coming back the other way.

Most routers first try port preservation: keep the same number the device chose, if it's free. It often is, but not always. Every device picks its own source ports independently, so two devices on the same LAN can easily both pick 51000 for UDP. Ports are counted separately for TCP and UDP, so a TCP 51000 and a UDP 51000 don't clash, but two UDP 51000s do. The second one gets a different public port. Some routers pick the next free number, some pick at random; RFC 6056 recommends randomizing ports so an attacker can't guess them, and many NATs follow suit.

The table has to answer one more question: if the same inside port talks to a second destination, does it get the same public port again? A NAT that reuses it is said to have endpoint-independent mapping. One that hands out a new port per destination has endpoint-dependent mapping, the old "symmetric NAT". For browsing the difference is invisible. For two devices trying to reach each other directly, it's the whole game, and Chapter 9 is about exactly that.

A NAT can't keep rows forever; the table and the port supply are both finite. So each row carries an idle timer. Every packet that matches the row resets it. If the timer runs out, the row is deleted and its public port goes back on the shelf.

TCP gives the router help. Connections open with a SYN handshake and close with FIN or RST packets, so a router can see when a conversation is over and drop the row soon afterward. While a connection is established, the standard says to be patient: RFC 5382 says the idle timeout for an established TCP connection must not be shorter than 2 hours and 4 minutes. That number isn't arbitrary. TCP's own keepalive, when an application turns it on, waits two hours of silence before probing, so a NAT that waits slightly longer won't cut off a connection that is merely quiet. Half-open and closing connections, which the standard calls transitory, may be dropped after 4 minutes.

UDP gives no help at all. There's no handshake and no goodbye, just datagrams. A router can only guess from silence. RFC 4787 says a UDP mapping must not expire in less than 2 minutes, and recommends 5 minutes or more. Plenty of real routers are stingier, some as short as 30 seconds. That's why protocols that need to stay reachable over UDP send small keepalive packets on a timer. WireGuard's documentation suggests a persistent keepalive of 25 seconds when a peer sits behind NAT; it's chosen to be shorter than almost any router's UDP timeout.

When a row expires early, the symptom is distinctive. The connection doesn't fail at once; it fails the next time the far end tries to talk. The reply arrives at the public port, finds nothing there, and vanishes. Long SSH sessions that freeze after you walk away for lunch, and VoIP calls that go one-way after a pause, are often exactly this.

Now flip the direction. A packet arrives from the internet, from an address nobody inside has talked to, aimed at 203.0.113.7 port 3389. The router looks in its table for a row with public port 3389. There isn't one. It has a public address and a port number and no idea which of the devices behind it, if any, should get the packet. So it does the only thing it can: it throws the packet away.

That accident is what most people mean when they say NAT "protects" their home network. Unsolicited inbound connections simply have nowhere to go. A laptop with a file share wide open sits behind the router invisible to the internet, not because anything decided it should be safe, but because there's no row pointing at it.

Even an existing row doesn't necessarily let anyone in. When a packet arrives at a public port that does have a mapping, the router can apply a filter: accept it from anyone (endpoint-independent filtering), only from an address the inside device has already sent to (address-dependent), or only from that exact address and port (address- and port-dependent). The strict setting is common on home routers; the loose one turns every outbound connection into a small public doorway, which is exactly what makes peer-to-peer connections easy, and exactly why it is a security trade-off.

A firewall is a policy: rules about what may cross, written on purpose and enforced even when translation would happily deliver a packet. NAT has no such policy, and several everyday things go straight through the gap.

• Inside devices open doors. Any program can make an outbound connection, and once it has, replies flow freely. Malware calls home, and the NAT carries the conversation as faithfully as a video call.
• Devices ask for holes. UPnP and NAT-PMP let any program on the LAN ask the router to forward a port, usually with no password (Chapter 8).
• IPv6 has no NAT at home. Each device gets a real global address. If the router's IPv6 firewall weren't on by default, every device would be directly reachable. RFC 4864 makes the point that the protection people credit to NAT comes from stateful filtering, which works just as well without translation.
• The inside is wide open. NAT does nothing about other devices on your own Wi-Fi.

Most home routers do run a real stateful firewall alongside the NAT, with rules that drop unsolicited inbound traffic on purpose. The two travel together so often that people stop distinguishing them. The difference shows up the moment you add a port forward, enable IPv6 or join a network you don't control.

Sometimes you want strangers to get in. You run a game server, a security camera, or Remote Desktop on a machine at home. The fix is to write a row by hand: a port forward, also called a static mapping or virtual server. "TCP port 3389 on the public address goes to 192.168.1.10 port 3389." Now when the stranger's packet arrives, the router finds a row, rewrites the destination and delivers it. The forward never expires; it sits in the table permanently, waiting.

Two catches follow from how the table works. First, a public port can point at only one inside device. If two PCs both want Remote Desktop on 3389 from outside, one of them has to use a different public port, say 3390 forwarded to the second PC's 3389. Second, the inside device must have a stable address, so forwards usually go with a DHCP reservation. If the laptop's address changes from .10 to .14 after a reboot, the forward points at nothing.

A DMZ host setting is the blunt version: "anything that doesn't match a row, send to this one device." It's the same as forwarding every port. On a router facing the internet it's risky. On a router facing another router it's a standard fix for double NAT, which is the next chapter's subject.

Here is a puzzle. The forward works from outside. But at home, your phone, on the same Wi-Fi, tries to connect to 203.0.113.7:3389, because that's the address saved in the app. The packet goes to the router, since 203.0.113.7 isn't on the LAN. The router has to notice that the destination is its own public address, apply the forward, rewrite the destination to 192.168.1.10, and rewrite the source to its public address too. That last step matters: if the laptop saw the reply's destination as 192.168.1.11 (the phone's real address), it would answer directly over the LAN, and the phone would discard a reply from an address it never talked to.

This U-turn is called hairpinning, or NAT loopback. RFC 4787 says a NAT must support it for UDP, and RFC 5382 says the same for TCP. Plenty of consumer routers still don't. When they don't, the classic workaround is split DNS: a name that resolves to the public address outside and the private address inside.

NAT rewrites headers. Some protocols, though, write addresses into the payload, where a NAT normally never looks. The oldest example is FTP. In active mode the client tells the server, in plain text, "connect back to me at 192,168,1,10 port 200,24" (the PORT command; the port is 200×256+24 = 51224). The server dutifully tries to connect to 192.168.1.10, a private address on someone else's LAN, and fails.

An application-level gateway, or ALG, is protocol-specific code in the router that parses such messages and rewrites the addresses inside them, then opens a matching mapping so the server's connection back gets through. Routers have shipped ALGs for FTP, SIP (internet phone calls), PPTP and the IPsec family, among others.

ALGs are an uneasy fix. A rewrite can change the length of the payload, which then means adjusting TCP sequence numbers for the rest of the connection. They have to understand each protocol perfectly, and SIP ALGs in particular are notorious for mangling calls; "turn off SIP ALG" is the first line of many VoIP troubleshooting guides. And they can't work at all on encrypted traffic, which is now most traffic. Modern protocols take the opposite approach: they assume NAT exists and work around it from the endpoints, with passive-mode FTP, STUN and ICE (Chapter 9).