If the internet had stuck rigidly to the original design of IPv4, it would have ground to a halt decades ago. With only 4.29 billion addresses available, we technically ran out of space in the early 2010s. The technology that saved the internet, and remains a cornerstone of network architecture today, is Network Address Translation (NAT).
Table of contents
NAT (Network Address Translation) is a method a router or firewall uses to map private IP addresses inside your network to public IP addresses on the internet, allowing many devices to share a single public IP while keeping internal addresses hidden.
More precisely, NAT modifies IP address (and sometimes port) information in packet headers as traffic traverses a NAT device. It maps private addresses used inside a network (for example, 192.168.1.10) to one or more public addresses used outside (for example, 203.0.113.10), and tracks these mappings in a translation table.
A simple home example:
192.168.0.10 or 192.168.0.20.This combination of address conservation, abstraction, and basic isolation is why NAT is still a core concept in networking.
While IPv6 was designed to render NAT obsolete by providing a virtually infinite address space, NAT remains ubiquitous in IPv4 environments and is even finding new life in IPv6 transition mechanisms (NAT64).
For the modern network engineer, NAT is not just about IP conservation. It is a critical tool for:
NAT sits between an "inside" (usually private) network and an "outside" (usually public or upstream) network.
When a router performs NAT, it creates an entry in a table (the NAT table) linking the internal IP address to the external IP address. This "state" allows the router to know where to send the return traffic. If a packet arrives from the internet that doesn't match an active session in the translation table, the router drops it (a feature often confused with firewalling).
A simplified NAT translation table might look like this:
|
Inside IP |
Inside Port |
Outside IP |
Outside Port |
Protocol |
|---|---|---|---|---|
|
192.168.1.100 |
1050 |
203.0.113.10 |
50005 |
TCP |
|
192.168.1.120 |
1100 |
203.0.113.10 |
50006 |
TCP |
From the internal host's perspective, this process is transparent. The host sends and receives packets as usual; only the NAT device modifies headers and maintains state.
A host with a private IP (for example, 192.168.1.100) sends a packet to an internet destination. The packet reaches the NAT device, which creates or reuses a translation entry, replacing the source IP and often the source port with a public IP and port. The packet is forwarded toward the destination with the translated source values.
In this case note these terms
Outside Global: The IP address of the destination host as it appears to the outside world (e.g., Google’s DNS 8.8.8.8).
Outside Local: The IP address of the destination host as it appears to the inside host. (In most standard NAT scenarios, this is identical to the Outside Global address, unless you are doing advanced Destination NAT).
The external server replies to the translated public IP and port. The NAT device looks up the entry in its translation table, rewrites the destination IP and port back to the internal values, and forwards the packet to the original host.
In this case note these terms
Inside Local: The actual IP address assigned to a host on the private network (e.g., 192.168.1.10).
Inside Global: The IP address of the inside host as it appears to the outside world (e.g., 203.0.113.5). This is usually the public IP after translation.
NAT doesn't just swap IP addresses.
Layer 3 (Network): The router recalculates the header checksum because the Source IP (and potentially Destination IP) has changed.
Layer 4 (Transport): If Port Address Translation (PAT) is being used, the router modifies the Source Port in the TCP/UDP header. Consequently, the TCP/UDP checksum must also be recalculated.
NAT behavior varies by how many addresses are mapped and how dynamic those mappings are. The main patterns you'll work with are:
Static NAT creates a permanent, fixed mapping between one Inside Local address and one Inside Global address.
Use cases:
Pros / Cons: Static NAT is straightforward to understand and troubleshoot, but it consumes one public IP address for each internal host you publish.
A simple static NAT concept:
192.168.10.10192.168.10.10 ↔ 203.0.113.10Cisco IOS configuration example:
interface GigabitEthernet0/0 ip address 203.0.113.1 255.255.255.0 ip nat outside ! interface GigabitEthernet0/1 ip address 192.168.10.1 255.255.255.0 ip nat inside ! ip nat inside source static 192.168.10.10 203.0.113.10
Dynamic NAT maps a private IP to a public IP from a pool of available public addresses.
You own a pool of 5 public IPs. When user A wants to go online, they grab the first available IP. When user B connects, they grab the second. When user A logs off and the timeout expires, that IP returns to the pool.
Use cases:
Pros / Cons: Scales better than one-to-one, but still limited by pool size. If your pool runs out, new connections fail. And this is something you definitely want to discover in a lab, not during a production cutover. More secure than Static NAT (internal IPs change).
Cisco IOS configuration example (Dynamic NAT with a pool):
R1(config)# ip nat pool MYPOOL 203.0.113.20 203.0.113.30 netmask 255.255.255.0 R1(config)# access-list 10 permit 192.168.10.0 0.0.0.255 R1(config)# ip nat inside source list 10 pool MYPOOL
This is what most people mean when they say "NAT." Port Address Translation (PAT), also known as NAT Overload, allows thousands of private hosts to share a single public IP address.
The router uses unique Source Port numbers to distinguish between different "conversations."
203.0.113.5:1024.203.0.113.5:1025.Use cases:
Pros / Cons: Extremely scalable, but it requires careful troubleshooting when many flows share one address. Ever tried debugging why one specific session is failing when 500 others are working fine through the same NAT? It's about as fun as it sounds.
Cisco IOS configuration example (PAT / NAT overload):
interface GigabitEthernet0/0 ip address 203.0.113.1 255.255.255.0 ip nat outside ! interface GigabitEthernet0/1 ip address 192.168.10.1 255.255.255.0 ip nat inside ! ip nat inside source list 10 interface GigabitEthernet0/0 overload access-list 10 permit 192.168.10.0 0.0.0.255
These are NAT decisions based on policy, ACLs, route-maps, zones, or other criteria beyond just source/destination.
Use cases:
Pros / Cons: Flexible but more complex. This is the kind of setup you definitely want to practice in a lab before deployment, because troubleshooting policy NAT in production at 2 AM is nobody's idea of a good time.
Cisco IOS configuration example (policy-based NAT with route-maps):
R1(config)# access-list 101 permit ip 192.168.10.0 0.0.0.255 any R1(config)# access-list 102 permit ip 192.168.20.0 0.0.0.255 any R1(config)# route-map NAT-MAP-10 permit 10 R1(config-route-map)# match ip address 101 R1(config-route-map)# set interface GigabitEthernet0/0 R1(config)# route-map NAT-MAP-20 permit 10 R1(config-route-map)# match ip address 102 R1(config-route-map)# set interface GigabitEthernet0/1 R1(config)# ip nat inside source route-map NAT-MAP-10 interface GigabitEthernet0/0 overload R1(config)# ip nat inside source route-map NAT-MAP-20 interface GigabitEthernet0/1 overload
ISPs faced the IPv4 exhaustion crisis long before enterprises did. To cope, they implemented Carrier Grade NAT (CGNAT), often referred to as NAT444.
In a standard residential setup, the customer's router holds a public IP. In a CGNAT architecture, the ISP’s router holds the public IP.
192.168.x.x).100.64.x.x - Reserved specifically for Shared Address Space).The Engineering Challenge:
CGNAT breaks the end-to-end principle of the internet even more severely than standard NAT.
This is the translation between IPv6-only and IPv4-only networks (for example, IPv6 clients reaching IPv4 servers).
Use cases:
Pros / Cons: Important in service provider and large enterprise networks. A good candidate for advanced labs if you're working on IPv6 migration strategies.
Cisco IOS configuration example (NAT64 IPv6–IPv4 translation)
R1(config)# ipv6 nat v4 pool V4POOL 203.0.113.100 203.0.113.110 prefix-length 32 R1(config)# ipv6 nat64 source list V6-ACL pool V4POOL overload R1(config)# ipv6 access-list V6-ACL R1(config-ipv6-acl)# permit ipv6 2001:db8:1::/64 any
Let's clear up a common confusion: NAT and routing are not the same thing, even though they often happen on the same device.
Key points you need to understand:
NAT is often colocated with a firewall, which leads to the persistent myth that NAT is a security feature. It isn't.
What NAT does:
What NAT does not do:
A clear security model treats NAT as address translation, and the firewall or NGFW as policy enforcement. They work together, but they're not interchangeable.
One of the most notorious headaches in networking is passing IPSec VPN traffic through a NAT device.
IPSec (specifically the ESP protocol) relies on checksums to verify data integrity. Standard NAT modifies IP headers and ports. When the receiving VPN gateway sees that the packet header was modified in transit (by the NAT device), it assumes the packet was tampered with and drops it.
NAT-Traversal (NAT-T) encapsulates the IPSec ESP packets inside a UDP wrapper (typically on port 4500). This allows the NAT device to translate the outer UDP header without breaking the inner encrypted payload.
For troubleshooting and incident response, translation visibility is critical, and often overlooked until something breaks.
NAT translation tables map internal addresses/ports to external ones. You need to know how to read these, because they're your first stop when debugging connectivity issues.
Logs (syslog, flow logs, firewall logs) may include both pre- and post-NAT values. Understanding which value you're looking at is essential for correlating events.
Packet captures at inside and outside interfaces let you see translations in practice. This is where you catch the "it works from here but not from there" issues.
These are all ideal activities to run in controlled NAT labs before you're troubleshooting production incidents under time pressure.
Cloud platforms frequently embed NAT into egress and connectivity services, which can make things either beautifully simple or frustratingly opaque (depending on how well you understand what's happening under the hood).
NAT gateways / egress NAT: Instances in private subnets reach the internet using a NAT gateway or instance. This is similar to on-prem PAT, but typically fully managed by the provider, which means less control, but also less operational overhead.
When you lift and shift to the cloud, the concept of a physical "interface" blurs.
In AWS or Azure, you typically don't configure ip nat inside on a virtual router interface. Instead, you deploy a NAT Gateway. This is a highly available, managed service that scales bandwidth automatically.
You can still run a Linux or Cisco CSR1000v instance as a NAT router, but this is generally discouraged for production due to the lack of inherent redundancy.
Cloud NAT gateways generally do not support security groups in the same way a firewall does; they are purely for outbound connectivity for private subnets.
Hybrid designs (on-prem + cloud): On-prem edges perform NAT toward cloud connections (VPN, Direct Connect, ExpressRoute, etc.). The cloud side may also apply NAT, especially for internet-facing services. Overlapping private address space between sites or regions often requires additional NAT layers, and this is where things get interesting (i.e. complicated).
For proofs-of-concept, it's valuable to:
CloudMyLab's hosted network emulators can approximate these hybrid scenarios, letting you test NAT and routing interactions across multiple segments without touching production.
Theory is essential, but muscle memory means, to truly understand NAT, you need to build it.
This is the bread-and-butter configuration for any branch office connecting to the internet.
1. Define the Interfaces:
First, tell the router which interface is trusted (Inside) and which faces the internet (Outside).
Router(config)# interface GigabitEthernet0/0 Router(config-if)# ip address 192.168.10.1 255.255.255.0 Router(config-if)# ip nat inside Router(config-if)# exit Router(config)# interface GigabitEthernet0/1 Router(config-if)# ip address 203.0.113.2 255.255.255.252 Router(config-if)# ip nat outside Router(config-if)# exit
2. Identify Interesting Traffic:
Create an Access Control List (ACL) to define who is allowed to be translated.
Router(config)# access-list 10 permit 192.168.10.0 0.0.0.255
3. Apply the Translation (Overload):
Link the ACL to the outside interface and enable the "overload" keyword to activate PAT (Port Address Translation).
Router(config)# ip nat inside source list 10 interface GigabitEthernet0/1 overload
If you have a web server inside your LAN (192.168.10.50) that needs to be reachable from the outside world on port 80.
Router(config)# ip nat inside source static tcp 192.168.10.50 80 203.0.113.2 80
Validation and Troubleshooting
Once configured, you need to verify the translation is occurring.
The "Truth" Table
Router# show ip nat translations Pro Inside global Inside local Outside local Outside global icmp 203.0.113.2:1024 192.168.10.5:1 8.8.8.8:1 8.8.8.8:1024
Interpretation: The internal host 192.168.10.5 (inside local) has been translated to 203.0.113.2 (inside global) using ICMP identifier 1024.
Real-Time Debugging
If translations aren't building, use debugs carefully (ensure you are in a lab environment like CloudMyLab, as this can crash a production router under load):
Router# debug ip nat
NAT-related issues often show up as "it works from here but not from there". One of the most frustrating phrases in networking. Common patterns include:
Overlapping private address spaces: Mergers, acquisitions, and multi-tenant environments often bring multiple 10.0.0.0/8 or 192.168.0.0/16 spaces together. NAT on one or both sides can resolve overlaps, but it must be thoroughly documented and tested. (Documentation is the part everyone skips, which is why overlapping address troubleshooting is always such a mess.)
NAT Pool Exhaustion
When using Dynamic NAT (without PAT), you have a finite number of public IPs. If you have a pool of 5 IPs and the 6th user attempts to connect, the router has no public ID to assign them.
Symptoms: Intermittent connectivity for users; some get out, others don't.
Check the pool usage statistics. You likely need to migrate to PAT (Overload) or request a larger block from your ISP.
Asymmetric Routing
This is the classic "packets go out, but don't come back" scenario, common in multi-ISP setups. Traffic leaves via ISP A (Router A performs NAT). The return traffic comes back via ISP B.
Router B has no entry in its NAT translation table for that specific session. It sees a packet destined for an internal private IP (which it can't route) or a public IP it doesn't own, and drops it.
NAT requires symmetric traffic flows. The device that translates the outbound packet must process the inbound return packet.
Limited public IP space shared across many sites: Branch offices share a small pool of public addresses. CGNAT in ISPs adds another layer of translation upstream. Each layer of NAT is another potential failure point and another layer of complexity when you're trying to track down where packets are getting dropped.
Order of Operations
Does the router route the packet first, or translate it first?
If your ACLs are blocking traffic based on IP addresses, you need to know whether to match the private or the public IP based on where the ACL is applied.
NAT traversal issues with VPNs: IPsec and other VPNs may require NAT-T support when devices sit behind NAT. Double-NAT scenarios can break expectations unless carefully designed. This is one of those areas where lab testing pays massive dividends.
Application protocols that embed IPs/ports: Some protocols carry IP information in the payload, not just in headers. NAT devices may need ALG (Application Layer Gateway) support, or the application itself may need changes. FTP, SIP, and H.323 are classic examples, they work fine until they suddenly don't, and then you're reading RFCs at midnight.
Here's a repeatable troubleshooting workflow you can rehearse in a lab:
show ip nat translations, firewall NAT views, etc.)Running this workflow first in a CloudMyLab NAT lab makes production troubleshooting faster and way less error-prone. You've already made the mistakes and fixed them in a safe environment.
NAT concepts become much clearer when you see translations happening in real time. This is where labs, PoCs, and repeatable topologies are especially useful. Because reading about NAT and doing NAT are completely different experiences.
Goal: Allow an internal subnet to access the internet using a single public IP.
Topology:
192.168.10.0/24)Validation:
In CloudMyLab, you can model this with Hosted Emulators (enterprise routers/firewalls) connected to a simple simulated ISP cloud. Build it, break it, fix it, repeat.
Goal: Publish an internal server (web, SSH, or VPN) via a static public IP.
Topology:
Validation:
Goal: Understand how NAT interacts with site-to-site VPNs and NAT-T.
Topology:
Validation:
Goal: See how provider NAT affects inbound access and logging.
Topology:
Validation:
NAT is foundational for network engineers working on enterprise edges, ISPs, and cloud or hybrid designs. Understanding how translations interact with routing, security, VPNs, and application behavior is much easier after you've seen the packets and translation tables in action. Preferably multiple times, with different configurations, and at least a few spectacular failures along the way.
CloudMyLab provides:
For teams, universities, and training centers, standardizing on repeatable NAT lab blueprints in CloudMyLab helps align theory, configuration skills, and troubleshooting practice in one place. You learn by doing, not just by reading. And when you inevitably break something, you're breaking it in an environment where nobody gets paged.
NAT translates a private IP address (for example, 192.168.1.100) to a public IP (for example, 203.0.113.10) when traffic leaves the network, and uses a translation table to map return traffic back to the original host. It's like having a company phone system where everyone inside has an extension, but outside callers only see the main number.
Traditional NAT focuses on translating IP addresses, often one-to-one or using a pool. PAT (Port Address Translation) also translates source ports, allowing many internal hosts to share a single public IP by assigning unique port mappings. PAT is what most people are actually using when they say "NAT."
To conserve IP addresses, protect internal networks, and simplify network setup.
NAT hides internal addresses and blocks unsolicited inbound sessions in common configurations, but it does not inspect traffic or enforce detailed security policies. Proper firewalls and security controls are still required. Think of NAT as obscurity, not security.
Yes, NAT can be configured to simulate real-world scenarios on virtual routers/firewalls.
NAT is primarily for IPv4; NAT64 supports translation between IPv6 and IPv4.
NAT tables track private-public address mappings; routing tables determine forwarding based on destination IPs.
When VPN endpoints sit behind NAT, features like NAT-T encapsulate VPN traffic so it can traverse translation devices. Multiple NAT layers and overlapping address space can complicate design. These scenarios are best tested in a lab before deployment (preferably several times).
Yes, and you should practice it in a lab. NAT is ideal for lab work because you can build edge, DMZ, ISP, and cloud-like topologies, generate traffic, and observe translations without risking production networks. The mistakes you make in the lab are the mistakes you won't make in production.
No. While NAT provides a degree of security by hiding internal IP addresses, it is not a security feature. NAT does not inspect traffic for malware, block specific applications, or prevent intrusion attempts. A stateful firewall is required for true network security. NAT hides the door number; a firewall locks the door.
Technically, yes, but usually negligibly. Because the router must modify the IP header and recalculate the checksum for every packet, there is a processing cost. However, modern enterprise routers use hardware acceleration (like Cisco CEF) to perform these translations at wire speed. Latency is rarely noticeable unless the router's CPU is overwhelmed.
Yes, if it is a Layer 3 switch (Multilayer Switch). High-end switches (like Cisco Catalyst 9000 series) support NAT, but they often have smaller translation table limits compared to dedicated edge routers. Layer 2 switches cannot perform NAT as they do not process IP headers.