Network Address Translation changes addressing information as packets cross a translation boundary. In the most common IPv4 deployment, many private hosts share a smaller pool of public addresses, while Port Address Translation distinguishes simultaneous sessions by rewriting transport-layer port numbers.
OSNTC.015 continues the Open Source Networking Technician Certification after OSNTC.014: TCP and UDP Transport Basics. The prior lesson established source and destination ports, connection state, and endpoint troubleshooting. NAT and PAT add another stateful device between those endpoints, so technicians must understand what changes, what remains constant, and how return traffic is matched.
The routing foundation remains OSNTC.013: Router Basics. Routing selects the next path; NAT modifies packet addressing information as traffic crosses the device.
The NAT/PAT data path
private host creates TCP/UDP traffic → router receives packet on inside interface → translation policy matches → source address and sometimes source port are rewritten → translation state is stored → packet is routed to the public network → reply returns to the public address/translated port → translation state identifies the private destination → packet is rewritten back to the original inside address/port → private host receives the response
Why private IPv4 addresses exist
RFC 1918 reserves three IPv4 ranges for private internets:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
These addresses can be reused by independent organizations because they are not intended to be globally routed on the public Internet. A workstation using 192.168.1.20 inside one company does not conflict with a different workstation using the same address inside another company as long as those private routing domains remain separate.
NAT commonly sits at the boundary between a private IPv4 network and globally routable IPv4 space.
Practical Networking: why NAT conserves IPv4 space
NAT and PAT are related but not identical
NAT broadly means translating network-layer address information. PAT, or Port Address Translation, also changes transport-layer port numbers so multiple internal sessions can share the same translated IPv4 address.
A simple address-only translation might look like:
10.10.5.24 → 203.0.113.50
A PAT translation can look like:
10.10.5.24:51822 → 203.0.113.8:40117
In the PAT example, both the IPv4 source address and TCP source port changed.
Practical Networking: NAT versus PAT, static versus dynamic
Static NAT
Static NAT creates a fixed address mapping. An administrator explicitly defines the relationship between one address and another.
Example:
10.20.8.40 ↔ 203.0.113.40
Static NAT is commonly associated with devices that must consistently appear through a specific translated address. Because the mapping is persistent, the same translated address is used instead of being selected from a changing pool.
Static PAT and port forwarding
Static PAT creates a fixed mapping that includes transport ports. Consumer and small-business interfaces often describe this as port forwarding.
Example:
203.0.113.8:443 → 10.20.8.40:8443
Traffic arriving at the public address on TCP 443 is translated to the internal server and port defined by the rule.
A port-forward rule does not automatically prove that the service is secure. Access policy, host security, application authentication, and firewall rules remain separate controls.
Dynamic NAT
Dynamic NAT selects a translated address from an available pool rather than using a permanently assigned one-to-one mapping.
If a pool contains five public addresses, only the number of simultaneous translations supported by that address pool can exist unless another translation technique is also used.
Dynamic PAT and NAT overload
The most familiar enterprise and home-network form is dynamic PAT, often called NAT overload. Many internal hosts share one or a few public IPv4 addresses.
Suppose three clients open HTTPS connections:
10.10.5.24:51822 → 198.51.100.20:44310.10.5.31:53044 → 198.51.100.20:44310.10.5.40:54402 → 198.51.100.20:443
The NAT device can translate them to:
203.0.113.8:40117 → 198.51.100.20:443203.0.113.8:40118 → 198.51.100.20:443203.0.113.8:40119 → 198.51.100.20:443
The translated source ports keep the sessions distinguishable even though the public source address is the same.
Professor Messer: Network Address Translation
Translation state is the key to return traffic
A stateful NAT/PAT device records enough information to reverse the translation when response traffic returns.
A simplified state entry can contain:
- inside private address;
- inside source port;
- translated public address;
- translated public port;
- transport protocol;
- destination address and sometimes destination port;
- state or timeout information.
When a reply arrives for 203.0.113.8:40117, the NAT device consults the state table and determines that the packet belongs to 10.10.5.24:51822.
The transport protocol is part of the translation
TCP port 40117 and UDP port 40117 are different transport endpoints. NAT state therefore includes the transport protocol, not only the numeric port.
This directly extends the transport model from OSNTC.014: endpoint identity depends on addresses, ports, and protocol.
Checksums must remain valid after translation
Changing IP addresses or transport-layer ports changes packet-header values that can participate in checksums. NAT implementations must update the affected checksums so the translated packet remains valid.
RFC 3022: Traditional IP Network Address Translator describes traditional NAT behavior and the changes required as packets cross the translation boundary.
NAT state has a lifetime
Dynamic translations are normally temporary. Devices expire entries after connections close or after inactivity timers are reached.
TCP translations can use connection state such as SYN, established, FIN, and reset behavior to help manage lifetime. UDP has no TCP-style connection teardown, so UDP mappings rely more heavily on inactivity timers.
A stale or prematurely expired NAT entry can make application symptoms appear intermittent even when IP routing is otherwise correct.
Port exhaustion
PAT does not provide an unlimited number of simultaneous translations. The translated device has a finite set of usable source-port combinations for each translated address and protocol.
Large-scale NAT systems can experience port exhaustion when too many sessions compete for the available translation space.
- new connections may fail while existing sessions remain healthy;
- different destination tuples can change how ports are reused;
- adding public addresses can expand available translation capacity;
- aggressive connection churn can consume state rapidly;
- incorrect timeout settings can retain unused entries too long.
Carrier-Grade NAT
Internet providers can place subscribers behind another translation layer called Carrier-Grade NAT (CGNAT). The shared IPv4 block 100.64.0.0/10 is reserved for service-provider shared address space by RFC 6598.
A subscriber can therefore experience multiple NAT layers:
device private address → customer router translation → ISP CGNAT translation → public Internet
This can complicate inbound services, peer-to-peer applications, logging, geolocation, and troubleshooting.
Double NAT
Double NAT occurs when traffic crosses two independent NAT boundaries, such as a home router placed behind an ISP gateway that is also translating addresses.
Ordinary outbound web access can still work normally, but inbound port forwarding, VPNs, gaming, voice applications, and peer-to-peer connectivity can become more complicated because both translation layers may need compatible state or forwarding rules.
Hairpin NAT
Hairpin NAT, also called NAT loopback in some products, allows an internal client to reach another internal service by using that service’s external translated address.
Without hairpin support, a public hostname can work from the Internet but fail when used by clients on the same private network. Split-horizon DNS is another design that can solve the same operational problem by returning an internal address to internal clients.
NAT is not the same thing as a firewall
NAT changes addressing information. A firewall applies security policy. Many routers perform both functions in the same device, which makes the two easy to confuse.
A failed inbound connection can therefore be caused by:
- missing or incorrect NAT/PAT rule;
- firewall policy denying the connection;
- server not listening;
- wrong internal destination address;
- routing failure;
- upstream CGNAT or another translation layer;
- application failure.
NAT does not remove the need for routing
A translation can be correct while routing is wrong. The NAT device still needs a route toward the destination, and the translated return path must reach the device that owns the active translation state.
In redundant networks, asymmetric paths can become important. If outbound traffic creates NAT state on one firewall but the response returns through a different firewall that does not share that state, the reply can be dropped.
NAT and DNS
DNS and NAT solve different problems. The earlier OSNTC.006: DNS Basics lesson covers name resolution. DNS can point a hostname to a public translated address, but the NAT/PAT rule still determines where matching packets go after they reach the edge device.
If a public DNS record points to the wrong public address, changing the NAT rule alone will not fix the name-resolution problem.
NAT and IPv6
IPv6 greatly expands the address space and was designed to restore large-scale end-to-end addressing without relying on IPv4-style address conservation through NAT.
That does not mean IPv6 removes firewalls, security zones, or routing policy. Address translation and security policy remain separate concepts.
Technician troubleshooting workflow
- Confirm the client’s real inside IP address and subnet.
- Confirm the default gateway.
- Confirm the intended public or translated address.
- Confirm whether the design uses static NAT, static PAT, dynamic NAT, or dynamic PAT.
- Confirm TCP or UDP and the expected source/destination ports.
- Inspect the active translation table.
- Verify that the expected translation entry is created.
- Check translation counters and failure counters.
- Confirm routing before and after translation.
- Check firewall/security policy separately.
- Capture packets on inside and outside interfaces when possible.
- Compare pre-translation and post-translation tuples.
- Check for CGNAT or a second local NAT device.
- Check state and timeout behavior for intermittent failures.
- Preserve the observed tuple and translation entry in the ticket.
Fast fault-isolation patterns
Private host can ping gateway but cannot reach the Internet:
check default route → NAT policy → active translation creation → upstream reachability → firewall policy.
Outbound TCP SYN leaves inside but nothing appears outside:
check NAT match criteria → translation capacity → security policy → egress interface → routing.
Translated SYN leaves outside but reply never returns:
check public routing → remote service → upstream firewall → ISP path → whether the translated source address is valid.
Reply reaches outside interface but not inside host:
check NAT state → return-path symmetry → firewall state → internal routing → translation timeout.
Port forward works externally but not internally:
check hairpin NAT support or split-horizon DNS.
Exercises
- A workstation at 10.10.5.24:51822 is translated to 203.0.113.8:40117 while connecting to 198.51.100.20:443. Identify the inside local tuple, translated tuple, and remote service tuple.
- Explain why two private clients can simultaneously connect to the same web server through one public IPv4 address.
- Describe the difference between static NAT and dynamic PAT.
- Explain why a port-forward rule and a firewall rule are not the same control.
- List the RFC 1918 private address ranges from memory, then verify them against RFC 1918.
- Describe how a stale NAT timeout could create intermittent application symptoms.
- Explain how double NAT can interfere with inbound services.
- Build a troubleshooting sequence for a TCP connection whose outbound packet is translated correctly but whose reply never reaches the private host.
Knowledge check
What is NAT?
A process that changes network-layer addressing information as packets cross a translation boundary.
What is PAT?
Address translation that also changes transport-layer port information, allowing multiple sessions to share translated address space.
Which IPv4 blocks are reserved for private internets by RFC 1918?
10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
Why does dynamic PAT maintain a state table?
So returning traffic can be matched to the correct original private address and port.
Is NAT the same as a firewall?
No. NAT performs translation; a firewall applies security policy, even though one device can perform both functions.
What is port exhaustion?
A condition where the translation device cannot allocate enough usable translated port mappings for new sessions.
What is 100.64.0.0/10 used for?
Shared address space reserved by RFC 6598 for service-provider environments such as Carrier-Grade NAT.
What should be compared in a packet capture when troubleshooting NAT?
The pre-translation and post-translation source/destination addresses, ports, protocol, direction, and matching state-table entry.
Key takeaway
NAT changes addresses; PAT changes addresses and ports; state makes the translation reversible for return traffic. Correct troubleshooting therefore requires more than checking whether a public IP exists. A technician must identify the original tuple, translated tuple, protocol, active state entry, routing path, timeout behavior, firewall policy, and any additional NAT layer between the endpoints.
Technical note: NAT behavior varies by platform, protocol, topology, and implementation. Production changes must follow the device vendor’s documentation, routing/security design, change-control process, and application requirements.
Display note: this lesson uses standard Gutenberg paragraphs, headings, lists, code, and media embeds only. No decorative text-box or callout-box layout is used.
BitcoinVersus.Tech
Advertisement
Editor’s Note:
We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support our research initiatives, please donate here: 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb
BitcoinVersus.tech is not a financial advisor. This media platform reports on financial subjects purely for informational purposes.
Leave a comment