How NAT uses state, and why it breaks assumptions

IPv4 uses 32-bit addresses, providing approximately 4.3 billion unique addresses. That sounded sufficient in 1981. By the early 1990s, it was clear it would not be enough for the growing internet. NAT (Network Address Translation) was one solution: allow many devices to share a single public IP address.

RFC 3022 defines traditional NAT. The idea is straightforward. An organisation with one public IP address can have hundreds of internal devices using private address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 as defined in RFC 1918). The NAT device rewrites source addresses on outgoing packets and reverses the process for incoming traffic.

The rewriting creates an obligation: the NAT device must track every active translation so it knows where to send the return traffic. This is the state requirement. NAT is not stateless translation. It is translation plus a per-connection mapping table.

That mapping is created and read differently depending on which way the packet is travelling and on whether ports are rewritten alongside addresses. Those two questions are what separate the three forms of NAT you will meet by name.

SNAT (Source NAT) rewrites the source address of outgoing packets. A device at 192.168.1.5 sends a packet; the NAT device rewrites the source to 203.0.113.1 (the public IP) before forwarding it. Return traffic to 203.0.113.1 is rewritten back to 192.168.1.5.

DNAT (Destination NAT) rewrites the destination address of incoming packets. Traffic arriving for 203.0.113.1:80 is rewritten to 192.168.1.10:80 to reach a web server on the internal network. Port forwarding is DNAT. Load balancers often use DNAT to distribute traffic across backend servers.

PAT (Port Address Translation), also called NAPT (Network Address Port Translation), allows many internal addresses to share one public IP by using different source port numbers to distinguish connections. This is what home routers do. Device A at 192.168.1.2 and Device B at 192.168.1.3 both reach the internet from the same public IP, but their connections use different source port numbers so the NAT device can tell return traffic apart.

SNAT, DNAT and PAT all depend on the same record. Nothing in a returning packet says which internal host it belongs to, so unless the device wrote down the translation when the connection started, the reply has nowhere to go.

That record is the state table. For every active connection through the NAT device, an entry holds the original source IP and port, the translated source IP and port, and the destination IP and port. Return traffic is matched against this table: incoming packets with a destination matching a translated entry are rewritten back to the original source.

Each entry has a timer. When no matching traffic is seen for the timeout period, the entry is removed. The timeout varies by protocol. TCP connections have longer timeouts than UDP flows. This creates intermittent failures: a long-lived TCP connection that is idle for longer than the NAT timeout will have its state entry removed. When the connection becomes active again, return traffic has no entry to match and is dropped.

This is why applications that maintain long-lived idle connections, such as SSH sessions, sometimes drop silently after a period of inactivity. The connection appears open on both ends but the NAT state has expired. TCP keepalives or application-level heartbeats prevent this by sending periodic small packets to refresh the NAT entry.

Keepalives treat the symptom. The deeper consequence of holding the mapping is that an inside device has no address the outside world can use on its own initiative, and that changes what the network as a whole promises.

The end-to-end principle (described in the original internet architecture work by Saltzer, Reed, and Clark in 1984) holds that intelligence should be placed at the endpoints of a network, not in the middle. Each device should be directly addressable and reachable. The network should move packets, not make decisions about them.

NAT violates this. An internal device's address is not globally routable. It cannot receive unsolicited connections. Two devices behind different NATs cannot directly communicate without one initiating to the other's public address, or without a third-party relay.

Peer-to-peer applications (video calls, file sharing, gaming) break under NAT because both peers may be behind NAT and neither can directly receive a connection from the other. This is the NAT traversal problem.

STUN (Session Traversal Utilities for NAT), defined in RFC 8489, which obsoleted the earlier RFC 5389, is a protocol that allows a client to discover its public IP address and port as seen from outside its NAT. The client sends a request to a public STUN server; the response tells the client what source IP and port the server observed. The client can then share this "reflexive" address with peers.

TURN (Traversal Using Relays around NAT) is a fallback when direct connection is impossible. When both peers are behind NATs that block hole-punching, a TURN server relays all traffic between them. TURN works in every NAT configuration but adds latency and bandwidth cost.

ICE (Interactive Connectivity Establishment), defined in RFC 8445, is the framework that coordinates candidate gathering and connectivity checks. An ICE agent gathers multiple candidate addresses (local, STUN-discovered, TURN relay), shares them with the peer, then tests each pair to find the best working path. WebRTC, which powers most web-based video calling, uses ICE.

One case catches people out. When two devices behind the same NAT reach each other using the public address, their traffic has to leave for the NAT, turn around and come straight back in. That is hairpinning, and RFC 4787 requires a NAT to support it. A device that does not breaks peer-to-peer applications only between users on the same office or home network, which is why the fault report tends to arrive as "it works with everyone except the person next to me".

NAT is address sharing. An unsolicited inbound packet is dropped because there is no state entry telling the device which internal host it belongs to, not because a policy examined it and decided against it. The drop is a consequence of how translation works.

RFC 4787 is where that behaviour is specified, and it is a behavioural document rather than a protective one. It sets requirements for how mappings and filtering behave for unicast UDP so that applications can predict them, and it is explicit that the mapping choices it defines make no difference to the security properties of the NAT, which are settled by which packets the device allows in. Citing it as evidence that NAT protects you inverts what it says.

What NAT withholds is as important as what it does. It authenticates nobody, it carries no policy you can read or review, and it inspects nothing inside the connections it does permit, including the outbound connection that malware on an inside host opens for itself. On a typical home gateway the same box also runs a stateful firewall, and that firewall is doing the work people credit to NAT.

IPv6 reaches the same default-deny position with no translation at all: every device holds a globally routable address, and a stateful firewall at the edge admits inbound packets belonging to a connection that started inside and drops everything else. The security property is identical, the addresses stay end-to-end, and the policy is now something an operator can read, log against and change deliberately.