NAT

Internal servers and PCs usually use private IP ranges, but those addresses are not routable on the public internet. Giving every device its own public IPv4 address is expensive and often impossible because the address space is limited. There needs to be a boundary function that keeps private addressing internally while still letting traffic reach the outside world.

The early internet assumed that every device could hold a public address, but IPv4 exhaustion became severe as PCs and mobile devices exploded in number. At the same time, operators wanted internal networks to stay structurally separate from the public internet. NAT became one of the key techniques that extended IPv4's lifespan while preserving that private-public boundary.

When an internal host sends traffic outward, a NAT device rewrites the private source IP and port into a public IP and an externally visible port, then records that mapping in a table. When the response comes back, the NAT device uses that table to reverse the translation and forward the packet to the original internal host. Externally, many private hosts appear behind one public address, but their sessions remain distinct.

NAT and firewalls often appear together at the network edge, but they solve different problems. NAT rewrites addresses so private and public networks can connect, while a firewall decides which traffic should be allowed or blocked. NAT creates the path outward; a firewall governs who is allowed to use that path.

NAT fits internal networks whose servers need outbound access to package repositories or external APIs, and it is the standard pattern in home and office gateways. It does not by itself create a clean public path for inbound traffic to an internal host, so separate exposure design is still needed. Because one more translation layer exists, troubleshooting often requires checking the mapping state in addition to the application itself.