What Is NAT? How One Address Serves Every Device at Home

Count the things in your house with an internet connection. Phones, laptops, a television, a console, a doorbell, a couple of speakers. Now look at the single address the internet sees when any of them loads a page. Something has to reconcile the many with the one, and it happens inside your router, continuously, in a table nobody ever shows you.

That table is network address translation. Almost every domestic connection in the world runs on it, and most of the things people find baffling about home networking fall out of how it works.

The problem it was built to solve

Your devices do not have internet addresses. They have addresses that mean something only inside your own network, drawn from three blocks that RFC 1918 reserved back in February 1996: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. The document is blunt about what that costs you. Private hosts “cannot have IP connectivity to any host outside of the enterprise”, and routing information about those addresses “shall not be propagated on inter-enterprise links”. Your laptop’s 192.168.1.42 is not a lesser address. It is not an address the internet will carry at all. Where that number came from in the first place is a separate negotiation with your router, and how DHCP hands out an address follows it message by message. If the split between the two kinds is new to you, public and private IP addresses covers the ground underneath this article.

So something has to stand at the boundary and translate. RFC 3022 describes two ways of doing it. Basic NAT swaps one address for another, which works only if you have as many public addresses as devices, and almost nobody does. NAPT, network address and port translation, swaps the address and the port number together, which is how a single address can serve everything at once. Translation in Basic NAT, the RFC says, “is limited to IP addresses alone”, whereas NAPT extends it to the transport identifier as well. A later standard, RFC 4787, records which of the two won: NAPT “is by far the most commonly deployed NAT device”. When people say NAT in a domestic context, this is the thing they mean.

What actually happens to one packet

Take the worked example from RFC 3022 itself. A machine at 10.0.0.10 opens a connection from its port 3017. The router rewrites the source address to its own public one, 138.76.28.4, and rewrites the source port to something it has picked, say 1024. It writes that pairing into its table and sends the packet on. The reply comes back addressed to 138.76.28.4 port 1024, the router looks up the row, reverses the substitution, and delivers it to 10.0.0.10 port 3017.

The port is the part that matters. Your phone and your laptop can both be talking to the same server on the same port at the same time, because the router has given each of them a different external port and can tell the replies apart. Ports are what turn one address into tens of thousands of simultaneous conversations.

This is more work than it sounds. Address and port fields sit inside checksums that cover them, so the router has to correct those on every packet in both directions, which RFC 3022 describes as something that “can be very compute intensive”. Neither end knows any of it is happening. In the RFC’s words, “the translation is completely transparent”. Your laptop believes it is talking to the world directly. The server believes it is talking to your router.

The table expires, and that is why things drop

The table is the whole product. Lose a row and the conversation it described is over, because a reply arriving for a mapping that no longer exists has nowhere to go.

So the rows have timers, and the standards set floors rather than values. For UDP, RFC 4787 says a mapping timer “MUST NOT expire in less than two minutes” and recommends a default of five minutes or more. For TCP, RFC 5382 is stricter: an established connection that has gone quiet “MUST NOT” be dropped in less than 2 hours 4 minutes, while a connection still opening or closing gets four minutes.

That odd figure is worth unpicking, because it explains a whole class of symptom. The two hours is the default interval for TCP keep-alive packets on hosts configured to send them at all. The extra four minutes, in RFC 5382’s own words, “allows time for in-flight packets to cross the NAT”. A router that waits slightly longer than the keep-alive interval can tell a live but silent connection from a dead one without having to ask. Applications that ping a server on a timer for no visible reason are often doing nothing more than keeping a row alive in a table you cannot see. When a terminal session dies over a long lunch, the timer is usually the answer.

Nothing outside can start a conversation with you

Here is the consequence people actually feel. RFC 3022 states the direction of travel plainly: with traditional NAT, “sessions are uni-directional, outbound from the private network”. The table only ever gets a row when something inside your network sends the first packet. An unsolicited packet arriving from the internet matches no row, and the router has no way to know which of your devices it was meant for, so it goes nowhere.

The RFC allows one exception, and you already know its high-street name. Sessions in the other direction “may be allowed on an exceptional basis using static address maps for pre-selected hosts”. That is port forwarding: a row you write by hand, in advance, saying that anything arriving on this external port belongs to that device. It is the reason running a game server or a security camera at home needs a visit to the router’s admin page, and it is worth understanding what an open port actually is before you create one.

One caveat matters before you go looking for the settings page. If your address is translated a second time inside your provider’s network, a forwarding rule can be written perfectly and still be unreachable, because the address it forwards to is not one the internet can deliver to in the first place. That is a different problem with a different answer, and it is the subject of CGNAT explained.

The protection is real, but it is not the translation

NAT gets credited with keeping the internet off your devices, and the standards are careful about where that protection actually comes from. RFC 4787 separates two behaviours that are easy to conflate. Mapping behaviour decides how the router assigns external ports. Filtering behaviour decides which arriving packets it lets through. On the mapping side, the document says the available choices “make no difference to the security properties of the NAT. The security properties are fully determined by which packets the NAT allows in and which it does not.”

The filtering half is where the shielding lives, and it comes in grades. The loosest, endpoint-independent filtering, means that once your device has sent a packet anywhere, packets arriving back at that port are forwarded “regardless of the external IP address and port source”. Stricter behaviour requires that your device sent to that specific address first. All of that lapses the moment you forward a port, because a static map carries no such condition. RFC 4787 also puts firewall behaviour outside its own scope, describing it as something a device provides in addition to translating, which is the honest way to read the shielding: a by-product of how the table works, not a security policy anyone wrote for you.

Why video calls work anyway

If nothing can reach you first, a video call between two households behind two routers should be impossible. It works because of the mapping side.

RFC 4787’s first requirement is that a router “MUST have an Endpoint-Independent Mapping behavior”, meaning the same internal port gets the same external port whatever it is talking to. That stability is what lets two devices discover their own external addresses, tell each other, and then send outbound packets at the same moment so each router opens a row for the other’s traffic. The RFC is explicit that the alternative is worse for everyone: failure to meet that requirement “will force the use of a UDP relay, which is very often impractical”, meaning your call gets routed through somebody else’s server rather than directly.

Seeing it on your own connection

Start inside. Your device’s own address, the one beginning 192.168 or 10., is the left-hand column of the table. The address the internet actually sees is the right-hand column. Everything in this article lives in the gap between those two, and holding both on screen at once makes the rest of it concrete.

The inbound half needs a test rather than a description, because a forwarding rule that is wrong and a forwarding rule that is right look identical on the router’s settings page. A port checker knocks on your address from outside, which settles it. A port that reports closed after you have forwarded it has two plausible explanations worth separating: the rule points at the wrong device or the wrong protocol, or there is a second translation upstream that the rule was never going to survive.

Translation was a way of buying time. RFC 1918 put the goal as lengthening “the lifetime of the IP address space”, which it has done for thirty years now, quietly, in a table on a box in your hallway that you have probably never logged into.