Network Address Translation: Sharing Public IP Addresses

The limited supply of public IPv4 addresses made it impossible for every device worldwide to have its own globally unique address, and Network Address Translation solved this by letting many private devices share a small number of public addresses. This article explains the three main NAT types, walks through configuring static NAT, dynamic NAT, and PAT on a Cisco router, and covers the essential commands for verifying active translations.

NAT ConfigurationPATStatic NAT

~5 دقیقه مطالعه · آخرین به‌روزرسانی ۱۸ شهریور ۱۴۰۵

Why NAT Became Necessary

IPv4 provides roughly 4.3 billion possible addresses, a number that seemed enormous decades ago but proved far too small once the internet grew to billions of connected devices. The private address ranges discussed earlier in this series regarding IPv4 addressing solve part of this problem by allowing internal networks to reuse the same address ranges, but a device using a private address cannot communicate directly with the public internet, since private addresses are not globally routable. NAT (Network Address Translation) solves this final piece by translating private addresses into public ones as traffic crosses the boundary between an internal network and the internet.

Static NAT: A Fixed One-to-One Mapping

Static NAT creates a permanent, unchanging mapping between one specific private address and one specific public address — commonly used for internal servers that need to be consistently reachable from the internet, such as a web server or mail server.

Router(config)# ip nat inside source static 192.168.1.10 203.0.113.10

Router(config)# interface gigabitethernet 0/1
Router(config-if)# ip nat inside
Router(config-if)# exit

Router(config)# interface gigabitethernet 0/0
Router(config-if)# ip nat outside

Every NAT configuration requires designating which interfaces are inside (facing the private network) and which are outside (facing the public internet) — without this designation, the router has no way of knowing which direction translation should apply to.

Dynamic NAT: Mapping from a Pool of Addresses

Dynamic NAT maps private addresses to public addresses drawn from a defined pool, assigned on a first-come, first-served basis rather than a fixed one-to-one relationship.

Router(config)# ip nat pool PUBLIC-POOL 203.0.113.20 203.0.113.30 netmask 255.255.255.0

Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255

Router(config)# ip nat inside source list 1 pool PUBLIC-POOL

-- The access list identifies which internal addresses
-- are eligible for translation, discussed earlier in
-- this series regarding standard ACLs

Dynamic NAT still requires one public address per simultaneously active internal device, since it is still fundamentally a one-to-one mapping — just with the specific pairing determined dynamically rather than statically configured for each device. This makes it a middle ground: more scalable than static NAT for many devices, but still limited by the size of the public address pool.

PAT: The Solution That Actually Scales

PAT (Port Address Translation), also called NAT Overload, solves the scaling limitation of both static and dynamic NAT by allowing many internal devices to share a single public IP address simultaneously, distinguishing between them using different source port numbers.

Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255

Router(config)# ip nat inside source list 1 interface gigabitethernet 0/0 overload

-- "overload" is the keyword that enables PAT,
-- using the outside interface's own IP address
-- as the shared public address for all
-- translated internal devices

This is by far the most common NAT configuration in real-world networks, including nearly every home router, since it allows an entire network of potentially hundreds of devices to share the single public IP address typically assigned by an internet service provider.

How PAT distinguishes between internal devices:

Internal device A: 192.168.1.11:52001 → 203.0.113.5:40001
Internal device B: 192.168.1.12:52001 → 203.0.113.5:40002

Both devices use the same private port number
locally, but the router assigns each a different
translated port on the shared public address,
allowing return traffic to be correctly routed
back to the originating internal device

Verifying Active NAT Translations

Router# show ip nat translations

Pro  Inside global      Inside local       Outside local      Outside global
tcp  203.0.113.5:40001  192.168.1.11:52001 93.184.216.34:443  93.184.216.34:443
tcp  203.0.113.5:40002  192.168.1.12:52001 93.184.216.34:443  93.184.216.34:443

Router# show ip nat statistics
Total active translations: 2 (0 static, 2 dynamic; 2 extended)

The four-column output of show ip nat translations reflects NAT's own terminology: Inside Local is the original private address, Inside Global is the translated public address, and the outside columns show the corresponding addresses for the external destination — this table is the primary tool for confirming exactly which internal device a specific piece of translated traffic actually belongs to.

A Common Troubleshooting Pattern: Missing Inside/Outside Designation

-- Symptom: NAT rules are configured correctly,
-- but translation simply never happens

-- Common cause: an interface was never marked
-- with "ip nat inside" or "ip nat outside"

Router# show ip interface gigabitethernet 0/1 | include NAT
  NAT: not enabled  ← this interface is missing its designation

Forgetting to apply ip nat inside or ip nat outside to the relevant interfaces is one of the most common NAT misconfigurations — the translation rules themselves can be perfectly correct, yet nothing happens because the router does not know which interfaces represent the private and public sides of the translation boundary.

Why NAT Remains Relevant Despite IPv6

Even as IPv6 adoption, covered later in this series, gradually reduces the pressure that originally motivated NAT's creation, NAT remains extremely common in IPv4 networks and continues to serve a secondary purpose beyond address conservation: since internal private addresses are never directly exposed to the internet, NAT provides a degree of security-through-obscurity, making internal network structure invisible to external observers. Understanding all three NAT types, and being able to quickly identify a missing inside/outside designation as a common cause of translation failure, remains an essential practical skill in nearly every real-world network deployment.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Systematic Network Troubleshooting: A Methodology Tying Everything Together

Every protocol and technology covered throughout this series is only useful if a problem involving it can actually be diagnosed and fixed efficiently under real-world pressure. This article presents a systematic troubleshooting methodology built around the OSI layers, walks through applying it to a realistic connectivity problem, and shows how the specific verification commands covered throughout this entire series fit into a structured diagnostic process.

ادامه

NETCONF, YANG, and Python: Programmatic Network Configuration at Scale

The REST APIs and JSON/YAML formats covered earlier in this series represent one approach to network automation, but NETCONF and YANG provide a more structured, standards-based alternative purpose-built for network device configuration. This article explains what distinguishes NETCONF from a simple REST API, covers how YANG models define exactly what configuration data looks like, and walks through using Python to programmatically interact with network devices.

ادامه

IPsec VPN Fundamentals: Securing Traffic Across Untrusted Networks

Connecting two sites across the public internet exposes traffic to interception unless it is properly encrypted, and IPsec provides the standard framework for building secure, authenticated tunnels between sites. This article explains the two-phase IKE negotiation process, covers the distinction between AH and ESP protocols, walks through configuring a basic site-to-site IPsec VPN, and covers essential verification commands.

ادامه

MPLS Fundamentals: Label Switching Explained

Traditional IP routing requires every router along a path to perform a full routing table lookup on every packet, but MPLS takes a fundamentally different approach by making that forwarding decision once and attaching a simple label that every subsequent router can use instead. This article explains the core label-switching concept, walks through how the Label Distribution Protocol builds the label forwarding tables that make this possible, and covers the practical benefits MPLS provides in real provider networks.

ادامه

BGP Route Reflectors and Confederations: Scaling iBGP Beyond Full Mesh

The iBGP full-mesh requirement, briefly mentioned earlier in this series, becomes a serious scaling problem as an autonomous system grows, requiring a number of sessions that increases quadratically with router count. This article explains exactly why full mesh does not scale, walks through how route reflectors solve this by relaxing BGP's normal route-propagation rules, and covers confederations as an alternative approach that divides a single AS into smaller sub-autonomous systems.

ادامه

OSPF Area Types Deep Dive: Stub, Totally Stubby, and NSSA

Multi-area OSPF, covered earlier in this series, already reduces database size by separating a network into areas, but OSPF offers further specialized area types that reduce routing table size even more aggressively by filtering out unnecessary external routes entirely. This article explains the LSA types that must be suppressed to create each specialized area type, walks through configuring stub, totally stubby, and not-so-stubby areas, and covers the specific trade-offs each design choice involves.

ادامه