Course contents

Lesson

NAT, PAT and the Complete Internet Packet Journey

Estimated time: 30–40 min · Full lesson access · Sign in to save your progress

Learning objective

Trace IPv4 address and port translation in both directions, read translation state, and diagnose failed return paths.

Learning objective

Trace an IPv4 packet through NAT and PAT in both directions, read its translation state, and identify where failed return traffic breaks.

The IPv4 translation boundary

RFC 1918 reserves 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for private networks. Those addresses are not globally routed on the public Internet, so an edge device translates a private endpoint into a usable public identity. NAT64 and NPTv6 are IPv6 mechanisms and are deliberately outside this IPv4 lesson.

NAT vocabulary and address realms

For client 10.0.0.25 using public address 203.0.113.10 to reach 198.51.100.20, the inside local value is the client's private address and the inside global value is its translated public identity. The outside global value is the remote server as globally known. The outside local value is how that outside endpoint appears inside; in ordinary examples it equals the outside global value.

NAT changes an address. PAT—also called NAT overload—changes an address and transport port so multiple sockets can share one public IPv4 address.

Static NAT and port forwarding

Static NAT maintains a predictable one-to-one address mapping. A port-forward rule is destination NAT: a packet for 203.0.113.10:443 can be rewritten toward 10.0.0.50:443. Unsolicited inbound traffic normally has no dynamic mapping, so it needs an explicit publication rule. The rule exposes only the configured tuple; routing and security policy still make separate decisions.

Dynamic NAT and address pools

Dynamic NAT temporarily selects an available public address from a pool. It remains one-to-one while allocated, and new sessions fail when no address is free. The mapping has state and a lifetime; it is not a permanent ownership record.

PAT and translation-table state

PAT distinguishes flows with protocol plus source/destination addresses and ports. For example, 10.0.0.25:51514 can become 203.0.113.10:62001. The table records the inside local, inside global, outside local, outside global, protocol, and state. A second client receives a different translated port so its tuple remains unique.

Complete Internet packet journey

DNS supplies the remote IPv4 destination 198.51.100.20.
The client opens TCP from 10.0.0.25:51514 to HTTPS port 443.
The gateway creates PAT state and emits 203.0.113.10:62001 → 198.51.100.20:443.
The server responds to that public tuple.
The gateway performs reverse translation and restores destination 10.0.0.25:51514.

The source changes outbound and the destination changes on return. The TCP peers remain logically consistent because both directions use the same stored mapping.

Return traffic, timeouts, and failure modes

A reply must match live state by protocol and tuple. Missing state, an expired timeout, a wrong port-forward target, exhausted addresses or ports, and asymmetric routing can all break the reverse lookup. Translators must also update affected checksums and handle ICMP errors and fragments carefully. Protocols that embed addresses in payload data may require limited application-aware handling.

NAT conserves public IPv4 space and hides internal addressing details, but it adds state and complicates troubleshooting. NAT is not a firewall: translation and traffic authorization are different functions.

Check the packet path

Before opening the account practice, trace these two questions using the tuple examples above: Which value identifies the private client before translation? What makes each PAT flow unique when many clients share one public IPv4 address?

Account practice: control the complete PAT journey

Advance one packet at a time and keep the active link, packet tuple, and translation-table entry synchronized.

Interactive packet journey

PAT Internet journey

Internal client

NAT gateway

Active path: Internal client → NAT gateway

Playback speed

Step 1 of 4: The private HTTPS tuple reaches the NAT boundary unchanged.

Packet tuple

Protocol: TCP
Source: 10.0.0.25:51514
Destination: 198.51.100.20:443

No fields changed at this step.

Translation state

No active translation exists yet.

Account practice: classify and reverse mappings

Read the mapping

One public address uses port 62001 for the private socket 10.0.0.25:51514.

Classify or reverse the mappingStatic NATDynamic NATPAT203.0.113.10:62001 maps to 10.0.0.25:51514

How confident are you?UnderconfidentConfident

Account practice: diagnose NAT failures

Diagnose the translation failure

Incident

Observed evidence: WAN capture shows the HTTPS reply; the translation table has no matching public port.

Best diagnosisMissing translation stateA DNS lookup failureA Layer 2 loop

Account knowledge checks

Knowledge check: Which value identifies the private client before translation?

Inside localInside globalOutside global

Knowledge check: Why can many PAT sessions share one public IPv4 address?

Each flow receives a unique translated transport tupleEvery client uses the same source portPAT removes TCP state

Knowledge check: A return packet arrives after its dynamic entry expired. What happens first?

The gateway has no matching reverse ownerThe gateway recreates the old port automaticallyThe server changes the destination

Knowledge check: What prevents two PAT flows from owning an identical public tuple?

Unique translated port allocationDuplicate private IP addressesDisabling transport checksums

Knowledge check: Why can asymmetric routing break stateful translation?

The return gateway may not own the forward mappingRouters cannot forward private addressesDNS always changes the service port

Pro packet analysis with Wireshark evidence

Correlate both interfaces by TCP sequence, flags, timing, and destination. The before/after views show which tuple fields the translator changed rather than treating two captures as unrelated conversations.

Correlate an HTTPS flow across a PAT boundary

Capture scenario

Multi-interface Wireshark evidence
Interface	Direction	Tuple	Flags/type	Evidence
LAN	egress toward gateway	`10.0.0.25:51514 → 198.51.100.20:443`	SYN	Private source tuple before translation
WAN	egress toward Internet	`203.0.113.10:62001 → 198.51.100.20:443`	SYN	Public source tuple after PAT

What changed?The gateway translated the client source tupleThe server changed its certificateDNS selected a different server

Pro RFC-level validation

Validate terminology and behavior against RFC 2663, RFC 3022, RFC 4787, RFC 5382, RFC 5508, and RFC 7857. The checks cover TCP, UDP, ICMP, checksum repair, fragments, and ALG limitations.

Validate translator behavior against RFC guidance

Check

What source should a hairpinned packet expose?Use the NAT external address and portPreserve the internal source tuple

Pro U-Turn NAT lab

An internal client opens 10.0.0.25:51514 → 203.0.113.10:443, although the HTTPS service is actually 10.0.0.50:443. In the broken path, DNAT delivers the request but preserves the private client source. The server recognizes a directly reachable local peer and replies from 10.0.0.50:443, producing a mismatched peer tuple for the session opened to the public address.

The working path uses paired DNAT and SNAT. DNAT selects the internal server, while SNAT makes the server return through the gateway. The gateway then reverses both translations so the client receives the response from 203.0.113.10:443. Vendors may call this U-Turn NAT, hairpin NAT, NAT loopback, or NAT reflection.