NAT/PAT Implementation

Network Address Translation (NAT) solves one of the internet's most critical problems: IPv4 address exhaustion. With only 4.3 billion possible IPv4 addresses and billions of internet-connected devices, organizations cannot obtain sufficient public IP addresses for every device. NAT enables networks to use private RFC 1918 addresses internally (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) while sharing a smaller pool of public addresses for internet communication. Understanding NAT terminology, operation, and configuration is essential for CCNA certification and modern network design. NAT terminology uses four key concepts that describe address perspectives. Inside Local addresses are private IP addresses used on the internal network before translation—the actual addresses assigned to internal devices like 192.168.1.10. Inside Global addresses are public IP addresses representing internal devices on the internet after translation—what the outside world sees, like 203.0.113.5. Outside Local addresses represent how external hosts appear to the internal network (usually unchanged). Outside Global addresses are the actual public addresses of external hosts on the internet. Most NAT discussions focus on Inside Local to Inside Global translation. NAT provides several critical benefits beyond address conservation. Security through obscurity results from hiding internal IP addressing schemes—external attackers see only public NAT addresses, not internal topology. This isn't true security (proper firewalls and ACLs provide real protection), but it adds a layer of difficulty for reconnaissance. Flexibility in addressing allows organizations to use any private address scheme internally regardless of ISP requirements or public address availability. Migration between ISPs becomes easier since internal addresses remain unchanged—only NAT configuration updates. Protocol support enables private networks to access internet services that would otherwise be impossible without globally unique addresses. The NAT translation process involves examining packets as they traverse the NAT device (router), modifying source or destination IP addresses in packet headers, and maintaining a translation table to track active sessions. For outbound traffic (inside to outside), NAT replaces the inside local source address with an inside global address. Return traffic reverses the process—NAT recognizes the inside global destination address and translates it back to the inside local address before forwarding internally. This translation must be stateful, tracking connections to ensure return packets reach the correct internal host. NAT variations include Static NAT (one-to-one permanent mappings for servers), Dynamic NAT (many-to-many temporary mappings from an address pool), and PAT/NAT Overload (many-to-one using port numbers, most common). Each serves different use cases and has distinct configuration requirements. NAT operates primarily at Layer 3 (IP addresses) but PAT extends to Layer 4 (port numbers), technically making it a Layer 4 technology. Understanding NAT fundamentals enables effective implementation of address translation in networks requiring internet connectivity with limited public IP addresses.

Static NAT provides permanent one-to-one mappings between inside local and inside global addresses, making specific internal hosts consistently accessible from the internet using predictable public IP addresses. This permanence makes static NAT ideal for servers, mail systems, web applications, VPN concentrators, and any device requiring inbound connections from external networks. Understanding static NAT configuration and appropriate use cases is essential for CCNA certification and hosting services in private address space. Static NAT configuration requires three coordinated steps. First, create the translation mapping using 'ip nat inside source static [inside-local-IP] [inside-global-IP]' in global configuration mode. For example, 'ip nat inside source static 192.168.1.10 203.0.113.5' creates a permanent mapping where internal server 192.168.1.10 is always represented as 203.0.113.5 on the internet. This command alone doesn't activate NAT—you must also designate interfaces as inside or outside. Second, mark the interface connected to your internal network with 'ip nat inside' in interface configuration mode. This designates the interface as the inside NAT boundary where inside local addresses exist. Typically, this is your LAN interface like GigabitEthernet0/0. Third, mark the interface connected to the internet or external network with 'ip nat outside' in interface configuration mode. This is usually your WAN interface connecting to the ISP. NAT only processes packets crossing between inside and outside interfaces—packets staying within inside interfaces or between outside interfaces aren't translated. Static NAT use cases include web servers requiring consistent public addresses for DNS resolution, mail servers needing fixed addresses for SPF records and mail reputation, database servers accessed remotely by partners, VPN concentrators with published endpoints, security camera systems accessed externally, and any device hosting services that external clients initiate connections toward. The key characteristic is inbound connection requirements—services that external users must reach need static NAT or port forwarding. Verification commands help confirm proper static NAT operation. 'show ip nat translations' displays the NAT translation table showing all active mappings. Static entries persist in this table always (until manually removed), displaying 'inside global', 'inside local', 'outside local', and 'outside global' addresses. 'show ip nat statistics' shows NAT hit counts, active translations, pool utilization, and configuration summary. This command helps troubleshoot—if hit counts aren't incrementing, traffic isn't matching NAT rules or interfaces aren't properly designated. Common static NAT problems include interfaces not marked inside/outside (NAT won't process traffic), incorrect IP addresses in mapping (translation points to wrong internal host or uses wrong public IP), routing problems (return traffic must route to the NAT device's outside interface), and ACLs blocking traffic either before or after NAT. Remember that inbound ACLs see pre-translation addresses while outbound ACLs see post-translation addresses, which affects ACL design. Understanding static NAT enables hosting services in private address space with public accessibility.

Dynamic NAT provides temporary many-to-many address translation using a pool of public IP addresses allocated on a first-come, first-served basis to internal hosts requiring internet access. Unlike static NAT's permanent mappings, dynamic NAT creates temporary translations that exist only while connections are active, then releases public addresses back to the pool for reuse. This approach conserves public addresses better than static NAT but less efficiently than PAT. Understanding dynamic NAT configuration and its limitations is important for CCNA certification, though PAT has largely superseded dynamic NAT in production networks. Dynamic NAT configuration involves four coordinated steps. First, define which inside local addresses are eligible for NAT using a standard access list: 'access-list 1 permit 192.168.1.0 0.0.0.255' allows the entire 192.168.1.0/24 subnet to use NAT. The ACL can include multiple entries permitting different subnets or denying specific hosts within permitted subnets. This ACL doesn't filter traffic—it identifies addresses eligible for translation. Second, create a pool of inside global addresses available for translation: 'ip nat pool MYPOOL 203.0.113.10 203.0.113.20 netmask 255.255.255.0' creates a pool named MYPOOL containing 11 public addresses (.10 through .20). The netmask specifies the subnet mask for these public addresses. Pool names are locally significant and referenced in the next step. Third, associate the ACL with the pool: 'ip nat inside source list 1 pool MYPOOL' connects ACL 1 (defining eligible inside addresses) with pool MYPOOL (providing available public addresses). When inside hosts matching ACL 1 initiate connections, they receive public addresses from MYPOOL. Fourth, designate inside and outside interfaces using 'ip nat inside' and 'ip nat outside' commands as with static NAT. Without properly designated interfaces, NAT won't function. Dynamic NAT only processes packets crossing from inside to outside interfaces or vice versa. The direction matters—connections must initiate from inside to create dynamic translations. External hosts cannot initiate connections to inside hosts via dynamic NAT since no permanent mapping exists. Dynamic NAT's primary limitation is pool exhaustion. If 11 public addresses exist in the pool but 12 internal hosts simultaneously need internet access, the 12th host's connection fails until another host releases an address. Pool exhaustion makes dynamic NAT unsuitable for networks where simultaneous external connections exceed available public addresses. The 'show ip nat statistics' command displays pool utilization—'allocated' shows used addresses, 'total addresses' shows pool size. Translations timeout and return addresses to the pool after inactivity. Default timeout for TCP is 24 hours, UDP is 5 minutes, though configurable. Active connections maintain their translations. The 'clear ip nat translation *' command forcibly removes all dynamic translations (static translations remain), returning addresses to the pool—useful when the pool is exhausted but some translations are stale. Dynamic NAT sees limited modern deployment because PAT (NAT overload) solves pool exhaustion by using port numbers to multiplex thousands of inside addresses through a single public IP. However, some legacy applications incompatible with port translation require dynamic NAT's one-to-one addressing. Understanding dynamic NAT provides foundational knowledge for comprehending PAT's improvements and is tested on CCNA exams despite limited practical use.

Port Address Translation (PAT), also called NAT overload, represents the most widely deployed NAT variant, enabling thousands of internal hosts to share a single public IP address by using source port numbers to distinguish connections. PAT solves dynamic NAT's pool exhaustion problem and minimizes public IP address consumption, making it the standard solution for SOHO networks, branch offices, and even large enterprises with limited public addresses. Understanding PAT operation and configuration is critical for CCNA certification and modern network implementation. PAT extends NAT by tracking not just IP addresses but also Layer 4 port numbers. When an internal host initiates a connection, PAT translates the inside local IP address to the inside global IP address (often the router's outside interface IP) and modifies the source port to a unique value. The PAT device maintains a translation table mapping {inside local IP + inside local port} to {inside global IP + unique global port}. Return traffic uses the global port to identify which internal host should receive the packet. This port multiplexing allows thousands of internal connections to share one public address since TCP/UDP support 65,535 port numbers. PAT configuration simplifies compared to dynamic NAT. First, define eligible inside addresses with an ACL: 'access-list 1 permit 192.168.0.0 0.0.255.255' allows the entire 192.168.0.0/16 network. Second, configure PAT using 'ip nat inside source list 1 interface [outside-interface] overload'. The 'overload' keyword activates PAT mode. The 'interface' keyword specifies using the outside interface's IP address as the inside global address—this is typical for SOHO where only one public IP (the ISP-assigned interface address) exists. Alternatively, specify a pool if multiple public IPs are available, though this is less common. Third, designate inside and outside interfaces as with other NAT types. PAT is directional—inside hosts can initiate connections outbound (translated via PAT), but external hosts cannot initiate inbound connections since no permanent port mapping exists. For inbound services, combine static NAT or static PAT (port forwarding) with PAT for outbound traffic. PAT's primary advantage is scalability—a single public IP theoretically supports 65,535 simultaneous connections (practical limits are lower due to timeout tracking and router performance). This makes PAT ideal for environments with many users but few public addresses. Nearly all home and small office routers implement PAT, allowing entire households to share the ISP-provided single public address. PAT is transparent to most applications, though some protocols (FTP active mode, SIP, H.323, IPsec) require special handling via Application Layer Gateways (ALGs) to work through PAT. Verification uses the same commands as other NAT types. 'show ip nat translations' displays active PAT entries showing inside local address:port translating to inside global address:port. Thousands of entries may exist in busy networks. Understanding PAT enables implementing efficient address translation in networks with limited public IP availability.

Effective NAT troubleshooting requires systematic verification of configuration elements, translation table status, interface designations, routing, and traffic flow. NAT problems manifest as complete connectivity loss, intermittent failures, or one-way communication, making methodical diagnosis essential. Understanding common NAT issues and verification commands is critical for CCNA certification and maintaining reliable network operations. Start troubleshooting with 'show ip nat translations' to verify the translation table. For static NAT, entries should exist permanently showing configured mappings. Missing static entries indicate configuration errors—verify the 'ip nat inside source static' command. For dynamic NAT and PAT, entries appear when inside hosts initiate connections. No entries appearing when traffic should be flowing suggests interfaces aren't marked inside/outside, ACLs don't permit source addresses, pools are exhausted (dynamic NAT), or traffic isn't actually reaching the router. Next, verify interface designation with 'show ip interface brief | include NAT' or 'show ip interface [interface]'. Each interface should display 'NAT inside' or 'NAT outside' if properly configured. Missing designations are extremely common configuration oversights—NAT requires both inside and outside interfaces designated. If interfaces lack NAT designation, enter interface configuration and add 'ip nat inside' or 'ip nat outside' as appropriate. 'show ip nat statistics' provides comprehensive NAT status: total active translations, hit counts (packets translated), miss counts (packets not matching NAT rules), pool information and utilization. Zero hit counts when traffic should flow indicates traffic isn't matching NAT configuration—verify ACLs, check that source addresses fall within permitted ranges. High miss counts suggest unwanted traffic attempting NAT or ACL misconfigurations. Pool exhaustion shows allocated addresses equal to total addresses in dynamic NAT scenarios. Common problems include ACLs that are too restrictive (excluding addresses that should translate), wrong direction (NAT ACLs identify inside addresses, not filter traffic), routing issues (return traffic must route to NAT router's outside interface—verify ISP routes translated addresses back), overlapping address pools and inside networks (creates ambiguity), and the implicit deny in ACLs blocking legitimate traffic. Clearing translations helps in troubleshooting: 'clear ip nat translation *' removes all dynamic entries, 'clear ip nat translation inside [global-IP] [local-IP]' removes specific mappings. Static translations cannot be cleared—only removed via configuration. 'debug ip nat' shows real-time NAT translations but generates significant output—use cautiously in production. Understanding NAT troubleshooting enables rapid diagnosis and resolution of translation issues in production networks.