What NAT is
Network Address Translation (NAT) changes IP addressing information as traffic crosses a translation boundary. In the most familiar IPv4 Internet design, hosts use private addresses internally while an edge router or firewall translates those addresses to globally routable addresses.
NAT is not part of normal IP routing itself. Routing decides where the packet goes; NAT modifies addressing information at a defined point in the path and must maintain enough state or rules to translate return traffic consistently.
RFC 1918 private IPv4 address space
Private IPv4 networks commonly use 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. These prefixes are not globally routed on the public Internet. Organizations can reuse them internally, which helped reduce public-address consumption but also made address translation and overlapping private space common operational realities.
Private addressing and NAT are related but not identical. A private network can exist without Internet NAT, and translation can be used for other design reasons.
Basic one-to-one NAT
In a simple one-to-one model, one internal address is translated to one external address. The device maintains a predictable mapping between the two. This can be useful for exposing a server under a different address or joining networks with address conflicts.
One-to-one translation consumes one translated address per concurrent mapping and therefore does not solve public-address scarcity as efficiently as port translation.
PAT / NAPT: many hosts behind one address
Port Address Translation, also called NAPT, allows many internal flows to share one external IPv4 address by translating transport-layer port information as well as addresses. The translator distinguishes sessions using protocol, addresses, ports, and its own translation state.
This is the common home and small-office Internet pattern: dozens of private clients can open simultaneous outbound connections while appearing to the Internet as one public IPv4 address.
The translation table
Stateful NAT/PAT devices maintain a translation table that associates internal flows with their translated representation. Entries are created, refreshed, and removed according to protocol state and timeout rules.
When troubleshooting, this table is often as important as the routing table. A correct route with no matching translation state or an exhausted translation pool can still break connectivity.
Port forwarding and inbound services
Outbound PAT can create state automatically when an internal client starts a flow. Inbound services need a rule that tells the translator where unsolicited traffic should go. Port forwarding maps an external address and port to an internal destination.
That rule should be combined with explicit security policy. Publishing TCP/443 to an internal web server does not mean every other service on that server should be reachable.
NAT is not a firewall
NAT changes addresses and sometimes ports. A firewall enforces a traffic policy and may perform stateful inspection. The same appliance often provides both features, which is why the concepts are easily confused.
Do not treat address translation as a security policy. Design access control independently, log it clearly, and understand where the NAT stage occurs relative to filtering on the platform you operate.
NAT changes the end-to-end Internet model
Traditional IP assumes that endpoint addresses identify reachable endpoints directly. NAT inserts a middlebox that rewrites packet headers and keeps translation state. That can complicate peer-to-peer applications, protocols that embed addresses inside payloads, inbound connectivity, and troubleshooting.
Many modern applications are designed with NAT traversal in mind, but the operational consequence remains: the address seen by one side of a connection may not be the address used by the original host.
Checksums, ports, and fragments
When a translator changes IP or transport-layer fields, related checksums may also need to be updated. Fragmentation can complicate translation because later fragments may not carry the transport header that contains the ports used by PAT.
Modern implementations handle these details internally, but they matter when packet captures appear inconsistent or when unusual fragmentation breaks only selected applications.
NAT and IPv6
IPv6 was designed with a much larger address space, so the familiar IPv4 pressure that made address-conserving NAT widespread is not the same. IPv6 networks normally use globally unique addressing plus firewalls and policy rather than copying an IPv4 private-address-plus-PAT design by default.
Translation mechanisms do exist in IPv6 transition and interoperability scenarios, but “NAT is required for security” is not a good design principle.
Routing still matters before and after NAT
A translator must know how to route traffic on both sides of the translation boundary. NAT cannot repair a missing route. After translation, the packet still needs a valid path to the remote destination, and return traffic must arrive back at a translator that understands the session.
This is why NAT troubleshooting should always include routing-table checks rather than focusing only on translation rules.
NAT/PAT troubleshooting
Verify the original source and destination, the route toward the destination, and whether the traffic matches the expected NAT rule. Inspect active translations, available address pools or ports, and firewall policy. Then validate the return path through the same stateful device when the design requires it.
- Does the flow match the intended translation rule?
- Is a translation entry created?
- Is the external translated address actually routed back to this device?
- Is a firewall rule blocking the packet before or after translation?
- Is the translation pool or port space exhausted?
Hairpin NAT
Hairpin NAT describes a case where an internal client reaches another internal service using the service's external translated address. The traffic enters the translator and is translated back toward an internal destination.
Whether this works automatically depends on the platform and configuration. Split DNS is often an alternative that lets internal users resolve an internal address instead.
Scale and port exhaustion
PAT multiplexes many sessions through a limited number of external addresses and transport ports. Large carrier or enterprise translators therefore need capacity planning for session tables, port allocation, timeouts, logging, and failure recovery.
When port resources are exhausted, new outbound connections can fail even while existing sessions continue to work.
What to study next
After NAT/PAT, continue with supernetting and route summarization. NAT changes packet headers at a boundary; summarization changes how groups of destination prefixes are represented in routing. Keeping those two ideas separate will make routing design much easier to reason about.