NAT, how your home network shares one IP

Field note. Most of your players are behind NAT. Most home self-hosts are behind NAT. NAT is why 'works on LAN but not over internet' is the single most common self-hosting failure.

Your home has one public IP address. Your home network has 20+ devices on it (phones, laptops, tablets, smart bulbs, the TV). Each of those devices appears to have its own IP and its own internet connection. How?

The answer is NAT (Network Address Translation). It's the invisible plumbing that lets 30 devices share one address. It also breaks specific things (like hosting a game server) in specific ways. This article explains how it works and what to do about it.

The basic mechanism

Inside your home, your devices have private addresses (192.168.1.x or similar). These addresses are not routable on the internet. Outside your home, your router has a single public address assigned by your ISP.

When your phone makes a request to a website:

1. Phone sends a TCP packet to 198.51.100.10:443 with source 192.168.1.42:51234.
2. Router intercepts this packet. The source is a private address, can't go onto the internet as-is.
3. Router rewrites the source to its own public IP (say 203.0.113.50) and picks a random external port (say 54321).
4. Router remembers the translation: "external port 54321 = internal phone:51234."
5. Router sends the packet onto the internet with source 203.0.113.50:54321.

The website's server sees a request from 203.0.113.50:54321. It sends a response there.

When the response arrives:

1. Router looks up port 54321 in its translation table.
2. Finds: "this maps to internal phone:51234."
3. Rewrites the destination back to 192.168.1.42:51234.
4. Forwards to the phone.

The phone has no idea this happened. From its perspective, it just sent a packet and got a response. The translation is invisible.

Why this works

Each NAT translation entry is bound to a specific connection (source IP, source port, dest IP, dest port). Different connections get different external ports.

The router's translation table is finite (typically thousands to tens of thousands of entries) but plenty for a home network. When a connection ends (TCP FIN, or idle timeout), the entry is removed.

The asymmetry that breaks things

Here's the catch: NAT works fine for outbound connections initiated from inside. The router learns the translation when the first packet goes out and applies it for the response.

For inbound connections initiated from outside, there's no entry. A packet from the internet arrives at your public IP with destination 203.0.113.50:25565. The router looks up port 25565 in its translation table. Nothing. The router has no idea which internal device this packet is for, so it drops it.

This is why hosting a server from home requires port forwarding. You manually tell the router: "incoming connections to port 25565 should go to my computer at 192.168.1.5 port 25565."

After port forwarding, the router has a static entry. Inbound packets to that port go to the specified inside host.

NAT types

Not all NATs are the same. The distinctions matter for game connectivity.

Full Cone NAT. Any external host can connect to the public IP:port and the router routes the connection to the matching inside host. Friendly to P2P; rare.

Restricted Cone NAT. External hosts can connect if the inside host previously sent a packet to them. Slightly more restrictive.

Port-Restricted Cone NAT. External hosts can connect only from the specific IP:port the inside host sent to. More restrictive.

Symmetric NAT. The external port assigned depends on the destination. Different destinations get different external ports. Most restrictive. Breaks many P2P protocols.

Modern home routers vary, but many are "Port-Restricted Cone" or "Symmetric." Game consoles often report a "NAT type" in their settings:

• NAT Type 1 / Open: roughly Full Cone.
• NAT Type 2 / Moderate: roughly Restricted or Port-Restricted Cone.
• NAT Type 3 / Strict: roughly Symmetric, or fully blocked.

Strict NAT is what causes "I can't host" or "we can't connect to each other in multiplayer" issues.

STUN, TURN, ICE

For protocols that need to traverse NAT (voice chat, peer-to-peer games, video calls), several techniques exist:

STUN (Session Traversal Utilities for NAT). A simple server tells you "I see your packet coming from external IP:port X." With this info, you can tell another party how to reach you. Works through Cone NATs.

TURN (Traversal Using Relays around NAT). A relay server that both sides connect outbound to. The relay forwards traffic between them. Adds latency but always works.

ICE (Interactive Connectivity Establishment). A framework that combines STUN and TURN, trying methods in order of preference. Used by WebRTC and many modern P2P protocols.

Most consumer apps with "real-time" features (Discord voice, Zoom, FaceTime) use ICE behind the scenes. It's why they "just work" even on weird NAT setups.

For dedicated game servers, none of this is needed: the client connects outbound to a public server, which traverses NAT naturally.

UPnP and auto port forwarding

Some routers support UPnP (Universal Plug and Play). It lets applications inside the network programmatically ask the router to open ports.

When UPnP works:

• A game console says "please forward port 27015 to me."
• The router does it.
• Other players can now connect.

When UPnP doesn't work:

• Router doesn't support UPnP, or has it disabled.
• The user has to manually port forward.

UPnP is convenient but has security history. A malicious app inside your network can request port forwards too. Default-on UPnP is a small risk increase. Many security-conscious users disable it.

Carrier-grade NAT (CGNAT)

A growing problem: your ISP may be running NAT, not just you.

In CGNAT, multiple customers share one public IP. The ISP has its own NAT layer, sitting between customers and the internet. Each customer has a "public" IP that's actually a different shared private address.

Effect:

• You can't port forward to your home. Even if you do, the ISP's NAT layer blocks inbound.
• Multiple homes share an IP from the internet's perspective.
• Hosting a public service from home is impossible without ISP cooperation (rare).
• "Get my public IP" returns the shared IP, useful for reaching content servers but not for being reachable.

CGNAT is increasingly common, especially on mobile networks and budget broadband. It's IPv4 scarcity's price, paid by users.

Workarounds:

• Use IPv6 if your ISP supports it. IPv6 has enough addresses that no NAT is needed.
• Use a VPN or tunneling service that gives you a real public IP.
• Move to an ISP that doesn't use CGNAT for your tier.
• Host elsewhere (paid hosting, VPS).

NAT and IPv6

In IPv6, there's enough address space that no one needs NAT for conservation. Many networks still use a NAT-like feature (NAT66 / NPTv6) for other reasons (privacy, simpler renumbering), but it's not driven by address shortage.

If your home network has IPv6 enabled, your devices typically each have their own globally-routable IPv6 address. No NAT in between. Inbound connections work without port forwarding (assuming your router's firewall allows them).

This is one of the underrated benefits of IPv6 adoption. Hosting from home becomes simpler on the IPv6 side.

Port forwarding, in practice

For self-hosting a game server, the typical port forwarding process:

1. Give your server a stable internal IP. Either set a static IP on the server itself, or configure your router's DHCP to always assign the same IP to that device (DHCP reservation).

2. Log into your router's admin panel. Usually 192.168.1.1 or 192.168.0.1 in a browser. Credentials on the bottom of the router or in its manual.

3. Find "port forwarding" (or "virtual server," "NAT forwarding," "applications"). Different brands, same feature.

4. Add a rule. External port → internal IP → internal port. Protocol (TCP/UDP/both). Enable.

5. Save and apply.

6. Test. From outside your network (your phone on cellular, a friend's house), try connecting to your public IP on the forwarded port.

If it works, you're set. If it doesn't, common issues:

• ISP is CGNAT'd. You can't port forward through your router's NAT if there's another one upstream.
• Wrong internal IP. Server's IP might have changed via DHCP.
• Firewall on the server itself is blocking. Open the port in the OS firewall.
• Router needs a reboot.

NAT's costs and benefits

NAT served the internet through IPv4 scarcity. Its costs:

• Breaks symmetric end-to-end connectivity (the original internet design principle).
• Makes hosting from home harder.
• Complicates P2P protocols.
• Hides individual devices behind shared IPs (sometimes a benefit, often a tracking issue).

Its benefits:

• Slowed IPv4 exhaustion by decades.
• Acts as a basic firewall (inbound connections must be explicitly enabled).
• Lets a single ISP-assigned IP serve a whole household.

In retrospect, NAT was the pragmatic answer to a hard problem. The internet would have run out of IPv4 in the late 1990s without it. The cost was a partial loss of the end-to-end principle, which IPv6 will eventually restore.

A summary for the curious admin

If you're hosting from home and dealing with NAT:

• Know your NAT type. Test with a tool like nat-test.com.
• Set static internal IPs for any device you want to be reachable.
• Open the right ports (TCP, UDP, or both) for your specific game.
• If on CGNAT, you'll need a workaround (cloud proxy, VPN, paid hosting).
• Consider IPv6 if your ISP supports it; some games work over IPv6 cleanly without NAT.

If you're hosting on paid infrastructure (a VPS or game host), NAT typically isn't your problem. The host gives you a public IP, you bind your service to it, and the world reaches you directly.

Coming up

NAT, in part, made the internet less direct than the original architects intended. The next article shifts to the security layer: HTTPS and TLS, which makes the slightly-tangled internet at least private and trustworthy for web traffic.