NAT Overload Simulator

A home router shares one public address between two clients — it rewrites every packet from the inside and records the pair in its NAT table, drops a connection started from the outside, and deletes an entry once its idle timeout runs out. With what NAT overload is called and the private address ranges it serves.

A home or café router has one public address and gives its clients private ones, so it rewrites every packet that crosses it.

On the way out, it rewrites the source.
On the way back, it rewrites the destination.
The NAT table, in the pane on the right, is what drives both.
Step runs the clock to the next event, through eight scenes that follow the sections below. Each scene starts from an empty table.
A outgoing packet, B outgoing packet and Incoming packet take the story our own way; the scene picker or Restart brings it back.

NAT overload and its other names

The kind of NAT a home router does, many private addresses behind one public one, goes by several names:

one-to-many NAT;
PAT, Port Address Translation;
NAPT, Network Address Port Translation, the name in Cisco's documentation;
NAT overload, after the overload keyword that turns it on in a Cisco router's configuration, and the name this page uses.

Other kinds of NAT map addresses one to one. The public IPv4 address of an AWS EC2 instance is one: the instance itself holds only its private address, and AWS translates between the two ( the EC2 documentation).

Private addresses (RFC 1918)

RFC 1918 sets aside three ranges that anyone may use inside a network, with no one's permission:

10.0.0.0/8, from 10.0.0.0 to 10.255.255.255;
172.16.0.0/12, from 172.16.0.0 to 172.31.255.255;
192.168.0.0/16, from 192.168.0.0 to 192.168.255.255.

Because every network may use them, they cannot be used on the Internet:

A private destination is ambiguous: thousands of homes have a 192.168.1.10, so the Internet's routers have no route to it.
A private source cannot be answered, for the same reason, and ISPs drop such packets at their edge.

So a computer with an RFC 1918 address that can browse the Internet is behind a NAT: something on the way between it and the Internet rewrites its address. In a home, that is the router this page simulates.

The network in the simulator

Two clients on the inside, 192.168.1.10 and 192.168.1.11, joined by a switch to the router's one LAN interface. The router is their DHCP server, which gave each of them:
- its address, from 192.168.1.0/24;
- its default gateway, the router's own 192.168.1.1;
- its DNS server.
The home router, with two interfaces, whose addresses show on hover:
- LAN, 192.168.1.1;
- WAN, 203.0.113.7, the only public address the home has, given to the router by the ISP's DHCP.
Two servers on the Internet, each in a network of its own. The addresses are made up for the example:
- Server 1, a web server at 52.84.20.14, on TCP port 443;
- Server 2, a DNS server at 81.218.40.53, on UDP port 53.

Outgoing packets: the source rewritten

A packet from a client carries a private source, so the router replaces it with its own public address and a port of its choosing:

It looks the packet up in the NAT table, by protocol, inside address and port, and outside address and port.
When no entry matches, it creates one: it picks a free port on its public address and writes the pair into the table.
It rewrites the source to 203.0.113.7 and that port, and leaves the destination alone.

The server sees only 203.0.113.7, one address with many ports, as if the whole home were one computer running many programs. The table's port column is what tells the two clients apart.

Replies: the destination rewritten

A reply arrives addressed to 203.0.113.7 and a port the router picked, and the entry with that port says where it goes:

The router finds the entry with that public port.
It checks the sender: the reply must come from the peer the entry was made for.
It rewrites the destination back to the client's private address and port.

Every packet that uses an entry, in either direction, restarts the entry's idle timer.

Packets, not connections

The router sees one UDP packet or one TCP segment at a time, and a connection is none of its business:

The connection belongs to its two ends: the client and the server keep its state, and the router only rewrites an address and a port in each segment.
The entry is per address pair: protocol, inside address and port, outside address and port.
For TCP, the router notes the flags it sees, SYN, FIN and RST, only to decide how long the entry lives.

ICMP: the identifier as a port

ICMP has no ports, so the router needs something else in the packet to tell two clients apart. For a ping it uses the echo's identifier; for an ICMP error, the copy of a header the error carries.

The identifier is what matches a ping to its replies. RFC 792 gives an echo request an identifier and a sequence number, and the echo reply carries both back unchanged, so the sender can tell which ping, and which of its requests, a reply answers.
The sender chooses it, and two senders often choose the same one:
- Linux's ping has used its process ID, and a ping sent through an unprivileged ICMP socket gets one the kernel picks, as it picks a free port;
- Windows's ping uses a fixed identifier, the same on every machine of a version.
A NAT treats the identifier as a port ( RFC 5508):
- the entry pairs the inside address and identifier with the public address and an identifier the router picks;
- the reply's identifier finds the entry, and the router rewrites the address and the identifier back;
- the entry lasts at least 60 seconds without use.
An ICMP error is found through the copy it carries. An error such as port unreachable, time exceeded (what traceroute reads) or fragmentation needed (what path MTU discovery reads) holds a copy of the header of the packet it answers, ports included:
- the router looks the copy up in the table, as if it were the original packet;
- it rewrites the outer destination to the client, and the copy's source back to the client's own address and port;
- without this, traceroute and path MTU discovery would fail behind every home router.

The simulator's tools

Each tool sends one packet whose fields we choose:

A outgoing packet and B outgoing packet send a UDP packet, a TCP segment with SYN, data or FIN, or an ICMP echo (a ping), from that client.
The servers answer as real ones do:
- Server 2 answers a DNS query, and a UDP packet to a port where nothing listens with an ICMP error;
- both servers answer a ping;
- Server 1 answers a SYN with a SYN-ACK and data with data, and resets a segment from an address and port it has no connection with.
Incoming packet sends one packet from a server to the router's public address, and gets in only if every field matches an entry:
- the protocol;
- the server's address and port, as the source;
- the entry's public port, as the destination.
Any other packet is dropped, and the caption names the field that was wrong.

Connections from the outside

Traffic going out is what lets traffic in: only a packet from the inside creates an entry. A connection started from the Internet finds none, so the router drops it without a reply, since nothing in the packet says which client it is for.

A packet to a port that is in the table is dropped as well, unless it comes from the entry's own peer.
So a server behind a home router is unreachable until someone configures a port forward: a static entry, which the simulator does not have.

Closing a connection

A FIN closes a TCP connection, and its entry stays until the idle timer runs out:

the client sends a FIN, the server answers with its own, and the table marks the entry closed;
until the timer runs out, the entry still admits packets from the server;
many routers shorten the timer once they have seen both FINs.

UDP has no close at all: a UDP entry ends only by timing out.

The idle timeout

An entry lives as long as packets use it. Once none has for the length of the idle timeout, the router deletes it and the port is free for the next pair.

A late reply is dropped: it finds no entry.
A TCP connection that resumes after its entry expired is broken:
- the router creates a new entry, with a new public port;
- the server has never seen that port, and answers with a reset.
This is why programs that keep an idle connection open send keepalives more often than the router's timeout.

Each table card also says how long a real router keeps that kind of entry, which is far longer than the simulator's seconds. The minimums are set by RFCs:

an open TCP connection: 2 hours 4 minutes ( RFC 5382);
a TCP connection opening or closing: 4 minutes (RFC 5382);
UDP: 2 minutes ( RFC 4787);
a ping: 60 seconds (RFC 5508).

The router reads the TCP flags only for this: they tell it whether a connection is open, and so which timeout applies. The slider goes from 5 s to 2 minutes, so that the expiry can be watched.

Simplifications in the simulator

Time is slowed down: a packet takes about four seconds from client to server.
The router picks public ports in order from 40001. Many real routers keep the client's own port when it is free, and pick another only when two clients use the same one.
A TCP connection opens with a SYN and a SYN-ACK; the final ACK of the handshake travels with the first data, and the last ACK of the close is not drawn.
The router checks the peer on every reply. Some routers let any sender in through an entry once it exists, which is what some games and calling apps depend on.