Most home and small-office networks have several devices using private IPv4 addresses such as 192.168.1.10, 192.168.1.11, and 192.168.1.12, yet the entire network may reach the internet through a single public IPv4 address. The router keeps those conversations separate with Network Address Translation and, more commonly for many-to-one sharing, Network Address and Port Translation.

The important hidden mechanism is a NAT translation table. It records which internal address and transport-layer port correspond to which translated public address and port. When reply traffic arrives, the router consults that state and sends each packet back to the correct device instead of guessing.

One Public IP, Many Private Connections

Imagine a laptop at 192.168.1.10 opens an HTTPS connection from source port 51514. A phone at 192.168.1.11 opens another connection from port 49822. Both devices are behind a router whose public address is 203.0.113.5.

The router can translate those connections into different public-side ports, for example:

192.168.1.10:51514  →  203.0.113.5:62001
192.168.1.11:49822  →  203.0.113.5:62002
192.168.1.12:60233  →  203.0.113.5:62003

That many-to-one technique is commonly called PAT, NAPT, or NAT overload. RFC 3022 describes NAPT as translating both the network address and the TCP or UDP transport identifier so many private addresses can share a globally unique address.

Why the Router Needs a Table

When an outbound packet crosses the router, the router changes selected address or port fields and records enough state to reverse that translation later. If a web server sends a reply to 203.0.113.5:62001, the router can map that traffic back to 192.168.1.10:51514. A reply to public port 62002 can be returned to the phone instead.

The exact implementation varies. Some systems speak of a NAT table, some expose a connection table, and Linux commonly ties translation behavior to connection tracking. The core idea is the same: translation is stateful enough for the device performing NAT to associate return traffic with an existing mapping.

Private IPv4 Addresses Are Reusable

Private IPv4 ranges such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are reserved for private internets by RFC 1918. They are not globally unique, so two unrelated homes can both have a device named 192.168.1.10 without conflict.

The public internet cannot route those private addresses directly. The border router therefore substitutes its public-side address before sending traffic outward. This connects directly to router fundamentals: the router is not merely forwarding packets between interfaces; when NAT is enabled, it may also rewrite packet headers while maintaining translation state.

Ports Make Many-to-One Sharing Practical

An IPv4 address alone would not be enough to distinguish thousands of simultaneous flows sharing one public address. TCP and UDP ports provide another identifier. The combination of protocol, addresses, ports, destination and connection state gives a NAT/PAT implementation enough information to keep flows separate.

This is why understanding TCP and UDP ports matters. A browser may create many short-lived connections. Phones, consoles, streaming devices, smart TVs and servers can all communicate at once. The router can assign different translated source ports even though the traffic shares the same public IPv4 address.

It is also why the common statement that a NAT device can support “only 65,535 connections” is too simplistic. Port numbers are finite, but real implementations can reuse ports across different destination tuples, protocols and public addresses, and they reclaim entries as sessions expire. Practical limits depend on the router’s software, memory, timeout policy and available public address space.

Dynamic Entries Eventually Expire

A translation created for ordinary outbound traffic does not normally remain forever. Routers age out idle state according to protocol-specific timers and implementation policy. TCP state can often be tracked more precisely because TCP has connection establishment and teardown. UDP has no equivalent connection handshake, so NAT devices usually rely more heavily on inactivity timers.

If the translation disappears before delayed return traffic arrives, the router may no longer know which private host should receive that packet. This is one reason long-idle applications, VPNs and real-time services sometimes use keepalives or NAT-traversal techniques.

Port Forwarding Is the Reverse Direction

Ordinary home NAT usually creates mappings because an internal device starts an outbound session. Port forwarding creates a deliberate inbound mapping. A rule might say that traffic arriving at the router’s public TCP port 8333 should be translated and sent to a particular internal machine.

That concept appears in Bitcoin networking as well. Bitcoin port 8333 is used for peer-to-peer node traffic, and a node behind NAT may require an inbound forwarding rule if unsolicited inbound peers need to reach it through an IPv4 NAT boundary.

Help me understand port-forwarding & PAT
byu/Coconut_Cove innetworking

NAT Is Not the Same Thing as a Firewall

NAT changes addresses and, with PAT, ports. A firewall applies a security policy that permits or denies traffic. Consumer routers commonly perform both jobs in the same device, which makes them easy to confuse.

An unsolicited inbound packet may fail because there is no matching translation, because a firewall policy rejects it, or both. Treating NAT itself as a complete security control hides the distinction between address translation and traffic filtering.

How to Inspect NAT State

Home routers often expose only a simplified connection-status page, while enterprise firewalls and routers usually provide richer session or translation tables. On Linux systems that perform NAT, the connection-tracking subsystem can expose live state with tools such as conntrack:

sudo conntrack -L

Rules and live state are different. Commands such as nft list ruleset show configured nftables policy, while connection-tracking output shows active flows known to the kernel. The exact troubleshooting command depends on the operating system and network platform.

This also connects to the role of a network interface card: the endpoint generates packets with its own local addresses and ports, while the NAT-capable router modifies selected fields as those packets cross the network boundary.

The Simple Mental Model

A NAT/PAT table can be thought of as the router’s temporary return-address ledger. Internal devices start conversations using private IP addresses and ports. The router translates those identifiers, remembers the mapping, and reverses the translation when matching replies come back.

That small piece of state is one of the reasons an entire house, office or lab can share a single public IPv4 address while dozens or hundreds of simultaneous connections continue to reach the correct device.

BitcoinVersus.Tech Editor’s Note: NAT behavior varies by implementation. Translation tables, firewall state tables and connection-tracking tables can overlap in function without being identical concepts.

Support independent BitcoinVersus.Tech reporting with Bitcoin: 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb

BitcoinVersus.Tech is not a financial advisor. This article is for informational and educational purposes.