Network Address Translation (NAT): What it is, and how it works

Q: Network Address Translation (NAT): What it is, and how it works

NAT translates IP addresses, often including port numbers, to let multiple devices share one public address. It works by tracking active connections and creating temporary mappings for traffic direction and return packets. NAT changes how peers reach you, so protocols needing inbound connections or strict IP handling can fail. Configuration and troubleshooting focus on connection state, port forwarding, and how replies are matched to mappings.

Network Address Translation (NAT) in plain terms

Network Address Translation (NAT) is a technique used by a router (or other gateway) to modify network address information for IP traffic as it passes between two networks—for example, between a private LAN and the public Internet. The most common reason is address sharing: multiple private devices can access the Internet while using a smaller number of public IP addresses.

NAT typically does not just change an IP address; it may also rewrite transport-layer ports (for example, TCP/UDP ports). That extra rewriting lets the gateway distinguish multiple simultaneous connections from different internal devices using the same outward public address.

A simple model of how NAT works

A helpful mental model is: “NAT is a connection bookkeeper.” When an internal device starts a connection to an external destination, NAT creates a temporary mapping.

Outbound traffic begins from inside (private IP) to outside (public IP).
NAT replaces the source address (and often the source port) with the gateway’s public address (and a chosen external port).
NAT records the mapping so it knows how to translate return traffic back to the correct internal device.
When the response comes back from the Internet, NAT uses the stored mapping to rewrite the destination address (and port) to the original internal host.

Because the mapping is typically based on an active connection, NAT behavior depends on whether the gateway can correctly maintain state and match replies.

NAT components: addresses, ports, and state

NAT implementations usually operate at the gateway and may rely on connection tracking.

Address rewriting: the internal source address becomes a public address on the outbound path.
Port rewriting (common): internal source ports are mapped to different external ports to avoid collisions.
State tracking: the gateway keeps temporary records so that reverse traffic is delivered to the right internal client.

This “stateful mapping” is a key reason NAT can work well for typical outbound web browsing, but can complicate scenarios that require stable inbound reachability.

Differences and limits that matter in practice

The biggest practical limit is that inbound connectivity is constrained unless the NAT device is configured to allow it.

Outbound-initiated connections usually work because NAT created the mapping.
Inbound-initiated connections (where an external system tries to start the session toward a private device) generally do not have a pre-existing mapping, so the gateway may drop or not route the traffic.

Certain applications also rely on embedded addressing or protocols that assume end-to-end reachability. In those cases, NAT may interfere unless the application (or NAT) supports appropriate behavior. This includes protocols that carry IP addresses inside the payload, or applications that expect peers to initiate connections.

Because NAT types and features vary by device and network design, exact behavior can differ. If you are troubleshooting, treat NAT as “address/port rewriting plus stateful matching,” then verify which connections are being mapped and how.

Practical checks you can do

To validate how NAT is affecting your connectivity, focus on observable symptoms rather than assumptions.

Check whether the traffic starts from inside vs. inside-to-outside only; inbound-only failures often point to missing inbound reachability.
Look for port-related issues: if one internal service works but another doesn’t, port handling and mappings are likely involved.
When debugging, confirm that replies return to the gateway and are consistent with an existing mapping; otherwise, the gateway has no matching state.
If an application requires inbound access to an internal host, verify whether your network design includes an explicit mechanism for that use case; NAT alone is not enough to make private hosts directly reachable.

If outcomes are inconsistent, it can help to capture connection details on both sides (where permitted) and compare which external source/port the client sees versus what the server replies to. That comparison often reveals whether NAT rewriting and state tracking are functioning as expected.