NAT Overload Simulator

A home router shares one public address between two clients — start connections from the inside and watch it rewrite every packet and fill its NAT table, knock from the outside and watch it drop the packet, and set the idle timeout that decides when an entry is gone.

A home or café router gives its clients private addresses and has a single public address of its own, so it rewrites every packet that crosses it: the source on the way out, the destination on the way back. The simulator shows that rewrite on each packet and the NAT table that drives it. The background is in NAT - One-to-many .

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, so it handed out these addresses from the private range 192.168.1.0/24.
The home router, with two interfaces: LAN, 192.168.1.1, and WAN, 203.0.113.7. The WAN address is the only public one the home has; the ISP gave it to the router by DHCP. Hover over an interface in the drawing to see its address.
Two servers on the Internet, each in a network of its own: Server 1 is a web server at 52.84.20.14, on TCP port 443, and Server 2 a DNS server at 81.218.40.53, on UDP port 53. The addresses are made up for the example.

Outgoing packets: the source rewritten

A packet from a client carries the client's private address as its source, which no one on the Internet can send a reply to. The router replaces it:

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 therefore sees only 203.0.113.7, one address with many ports, as if the whole home were a single 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. The router finds the entry with that port, checks that the sender is the peer the entry was made for, and rewrites the destination back to the client's private address and port. Every packet that uses an entry, in either direction, restarts its idle timer.

Single packets: building the reply yourself

Packet out and Packet in send one packet whose fields you choose, and nobody answers it automatically: the reply is yours to build.

Send a packet out. The router creates an entry, and the server's box lists the public address and port the packet arrived from.
Build the reply under Packet in. It gets in only if every field matches the entry: the protocol, the server's address and port as the source, and the entry's public port as the destination. Any other packet is dropped, and the caption says which field was wrong.
Send from both clients with the same source port. Both use 5000 inside; the table gives them two different public ports, and those are what tell their replies apart.

Connections from the outside

A connection started from the Internet finds no entry, and the router drops it without a reply: nothing in the packet says which client it is for. A packet sent to a port that is in the table is dropped as well, unless it comes from the entry's own peer. This is why a server behind a home router is unreachable until someone configures a port forward, a static entry that the simulator does not have.

Closing a connection

Disconnect closes a TCP connection: the client sends a FIN, the server answers with its own, and the table marks the entry closed. The entry stays until its idle timer runs out, and until then it still admits packets from the server; press the server's sends button to see one get in. Many routers shorten the timer once they have seen both FINs. UDP has no close at all: an entry for UDP 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 connection. Press Go idle on a connection to watch it happen: the client stops sending without closing anything.

A late reply is dropped. Press the server's sends button after the entry has gone.
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 it answers with a reset. This is why programs that keep a connection open while idle send keepalives more often than the router's timeout.

Real routers use timeouts of minutes for UDP and up to hours for an established TCP connection; 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, and 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.