NAT Explained: How One Public IP Serves a Whole Network

Count the things in your home that reach the internet. A couple of phones, a laptop, a TV, maybe a speaker and a doorbell. Now open our IP lookup and read the address it reports back. That is one address, and every one of those devices is out there using it right now.

Network address translation is what makes that possible, and it has held IPv4 together since the mid-1990s. It is also why a game console asks you to open ports, why a video call needs a third server to get started, and why the address your laptop believes it has is not the one anyone else sees.

One address, many devices#

Inside a home or office network, devices use addresses from three blocks that RFC 1918 set aside for private use: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Anyone can use them, everyone does, and no router on the public internet will carry a packet addressed to one. They are local names, valid only inside the building. Our CIDR calculator expands any of those prefixes into its exact address range, and what are RFC 1918 private IP ranges covers why those blocks were chosen.

Your router straddles the two worlds. It holds a private address on the inside, usually something like 192.168.1.1, and a public one on the outside from your ISP. Everything leaving the network must be made to look as though it came from that single public address, because that is the only address the rest of the internet can reply to. Making it look that way is the translation.

What the router rewrites#

Say your laptop at 192.168.1.24 opens a connection to a web server on port 443. It picks an unused local port for itself, say 51793, and sends a packet with source 192.168.1.24:51793.

The router intercepts it on the way out and rewrites the source: the address becomes the public one, the port becomes whatever the router has free, say 40012. It records that pairing and forwards the packet. The server's reply arrives addressed to the public IP on port 40012, so the router looks 40012 up, finds 192.168.1.24:51793, rewrites the destination back, and delivers it. Neither end ever knows.

Rewriting the port alongside the address is what lets one public IP serve many devices, and it has its own name. RFC 3022 separates Basic NAT, which swaps addresses one-for-one and needs a pool of public addresses, from NAPT, network address port translation, defined there as translating many addresses and their TCP or UDP ports into a single address and its ports. Every home router does NAPT. Almost nobody calls it that.

The translation table is just memory#

Those pairings are state, held in RAM on a device that was probably cheap. That has consequences.

Entries expire. Each mapping carries an idle timer, and the standards set floors on how impatient it may be. For UDP, RFC 4787 requires that a mapping timer must not expire in less than two minutes, and recommends a default of five minutes or more. For TCP, RFC 5382 sets the floor for an established connection at two hours and four minutes, with a shorter four-minute floor for connections still opening or already closing.

That gap between two minutes and two hours explains a lot of everyday behaviour. A silent SSH session survives a lunch break because it is TCP and the NAT is patient with it. A VoIP call or a game using UDP has to keep sending something, or the mapping evaporates and the return path with it. That is why so many protocols have a keepalive. TCP vs UDP covers why the two transports get treated so differently.

The table also has a ceiling. A public address offers 65,535 usable ports per transport, which caps simultaneous mappings behind it. A household never approaches that. An ISP putting thousands of subscribers behind one address thinks about very little else.

Mapping and filtering are two questions#

NATs differ in behaviour, and older writing lumps those differences into single labels: full cone, restricted cone, symmetric. That vocabulary came from an early STUN specification, and it bundles together two things that are independent. RFC 4787 pulls them apart, and once you see them separately a stubborn router usually makes sense.

Mapping asks whether the same internal socket gets the same external port no matter who it is talking to. If your laptop's port 51793 shows up as public port 40012 to every destination, the mapping is endpoint-independent. If the router allocates a fresh external port per destination, nobody outside can predict where to find you. RFC 4787 requires the endpoint-independent behaviour in as many words.

Filtering asks a separate question: now that a mapping exists, whose packets will the router accept on it? Strictly, only packets from the exact address and port your device contacted. More loosely, anything from that address. Loosest of all, anything sent to that port.

A third behaviour is worth knowing by name because it fails so memorably. Hairpinning is two devices behind the same NAT reaching each other through the public address rather than directly. RFC 4787 requires support for it. Routers that lack it produce the classic symptom where a self-hosted service is reachable from anywhere in the world except the sofa in the same house.

How anything gets in from outside#

A mapping normally exists because something inside sent a packet out. An unsolicited packet from the internet matches nothing, so the router drops it. Four ways around that, roughly in order of bluntness:

• Port forwarding. A permanent hand-written rule: anything arriving on this external port goes to this internal address and port. Fine for a service you mean to publish, and worth being deliberate about, since a forwarded port is a genuinely reachable service. What open ports reveal about any IP covers which ones deserve a second thought.
• Automatic mapping. UPnP IGD, NAT-PMP, and its successor the Port Control Protocol (RFC 6887) let an application ask the router for a mapping without anyone touching the admin page. Convenient, and it means software can open a path inward without asking you first.
• Hole punching. Two peers each send outbound packets to create mappings, then use a server on the outside to tell each other what those mappings turned out to be. STUN (RFC 8489) handles the discovery step: the client asks a server what source address and port it appeared to come from, and the answer is its own NAT mapping. This is how most video calls connect directly.
• Relaying. When neither side's mapping can be predicted, the traffic goes through a relay server instead. It always works, and somebody has to pay for the bandwidth.

You can watch the STUN step happen in your own browser. Our WebRTC leak test runs the same probes a web page would, using your browser's own RTCPeerConnection, and lists every address it hands out: the public one your NAT is presenting, and any local candidates. Chrome-family browsers have replaced raw local addresses with random .local hostnames by default since 2019, so seeing those is the healthy result. WebRTC leaks explained covers what to do if raw private addresses appear instead.

Carrier-grade NAT, the second layer#

Many ISPs no longer give each customer a public address at all. They run a second NAT of their own, with hundreds or thousands of subscribers behind each public IP. Your router translates, and then the carrier translates again on the way out.

That second layer needs addresses for the link between the carrier's equipment and yours, and RFC 1918 space was unusable for it since customers already use those blocks internally. So RFC 6598 allocated 100.64.0.0/10 as Shared Address Space, a little over four million addresses reserved specifically for numbering the connection between a carrier-grade NAT and customer equipment. A router WAN address in that range means you are behind CGNAT.

Two consequences. Port forwarding stops working, because the port you forward on your own router is not the port the carrier's NAT presents to the world. And a shared address means shared reputation: if a neighbour behind the same carrier NAT annoys a mail server, you inherit the result. Our IP reputation checker reports the infrastructure classification for an address, and how to check if an IP is on a blacklist covers the mail side.

NAT is not a firewall#

NAT does block unsolicited inbound traffic, and that is genuinely useful. It is also a side effect rather than a policy. The router drops those packets because it has nowhere to send them, not because it decided they were unwelcome.

The difference shows up as soon as you push on it. Anything already inside the network can open outbound connections freely, and malware prefers to work that way. Automatic mapping can create inbound paths without a human approving one. A permissive filtering behaviour will accept packets from senders your device never contacted. Treat NAT as an addressing mechanism that happens to be quiet about inbound traffic, and put a real firewall policy in front of anything that matters.

What IPv6 changes#

IPv6 has enough addresses that every device can hold a globally routable one, which removes the reason NAT existed. Packets travel end to end, ports mean what they say, and hole punching stops being a prerequisite for a direct connection.

The inbound protection people liked does not disappear with it. It moves to where it belonged: a stateful firewall on the router that denies unsolicited inbound by default. Same outcome, stated as a rule rather than produced by accident.

One narrow IPv6 translation case does exist. RFC 6296 defines NPTv6, prefix translation for sites that want to change providers without renumbering internally. It is stateless, maps addresses one to one, and is explicitly forbidden from touching ports. It is also Experimental rather than a standard, and not something you will meet on a home connection.

Working out what your NAT does#

Three checks tell you most of what you need to know.

Compare your device's own address with what the internet sees. Your operating system's network settings show the local one, and our IP lookup shows the public address a server receives from you, plus the ISP behind it. If they differ, and they almost always will, there is a NAT between them. Public vs private IP addresses is the short version of why.

Then look at your router's WAN address on its status page. A public address means one layer of NAT. Something in 100.64.0.0/10 means CGNAT and no usable port forwarding. Another RFC 1918 address means a second router upstream, common on landlord-managed connections.

Finally, if peer-to-peer connections are what keeps failing, run the WebRTC leak test and look at what your browser discovered. A public candidate means STUN got through and the mapping is discoverable. Only local candidates suggests the path outward is blocked, which is where relays become the last option.