Loading learning content...
How does your home network—with its phones, laptops, tablets, smart TVs, gaming consoles, and IoT devices—connect to the Internet using a single public IP address issued by your ISP? How can a corporate network with thousands of workstations browse the web through one or a handful of public addresses?
The answer is Port Address Translation (PAT), also known as NAT Overload, NAPT (Network Address and Port Translation), or IP Masquerading. PAT is the most widely deployed NAT mechanism on the Internet, enabling billions of devices to share a limited pool of IPv4 addresses.
PAT extends NAT from simple address translation to address-plus-port translation. By assigning unique source port numbers to each connection, PAT differentiates among thousands of simultaneous connections from different internal hosts—all appearing to come from a single public IP address. This page provides comprehensive coverage of PAT's operation, configuration, capabilities, and limitations.
By the end of this page, you will understand how PAT uses port numbers to multiplex connections, the translation mechanics for TCP and UDP, the theoretical and practical limits of PAT, configuration across different platforms, port forwarding for inbound access, PAT's interaction with various protocols, and troubleshooting common PAT issues.
Port Address Translation (PAT) translates both the IP address AND the transport layer port number, creating unique (address:port) tuples that allow multiple internal hosts to share a single external IP address.
The Key Insight:
While an IP address identifies a host, a transport layer port identifies a specific connection on that host. By combining these:
This means a single public IP can theoretically support tens of thousands of concurrent connections from different internal hosts.
PAT Terminology:
| Term | Context/Vendor | Meaning |
|---|---|---|
| PAT | General/Cisco | Port Address Translation |
| NAT Overload | Cisco IOS | PAT configured with 'overload' keyword |
| NAPT | RFC 3022 | Network Address Port Translation |
| IP Masquerading | Linux/iptables | PAT using outgoing interface address |
| Hide NAT | Check Point | Many-to-one NAT (PAT) |
| Source NAT (many-to-one) | Juniper | PAT-style translation |
How PAT Differs from Basic NAT:
Basic NAT (Static/Dynamic):
Translation: IP Address only
Mapping: One internal IP → One external IP
Uniqueness: IP address provides uniqueness
PAT:
Translation: IP Address + Port
Mapping: Many internal IP:Ports → One external IP:Different Ports
Uniqueness: IP:Port combination provides uniqueness
Virtually every home router, small business router, and enterprise edge device uses PAT by default. When you configure 'NAT' on a consumer device, you're configuring PAT. It's so ubiquitous that many network engineers use 'NAT' and 'PAT' interchangeably when referring to consumer/SOHO scenarios.
Understanding PAT requires tracing the complete translation of both address and port for outbound and return traffic.
Scenario: Two internal hosts access the same external web server simultaneously.
Initial Request - Host A:
Inside Local: 192.168.1.10:50000 → 198.51.100.10:80
After PAT: 203.0.113.5:10001 → 198.51.100.10:80
Initial Request - Host B (concurrent):
Inside Local: 192.168.1.20:50000 → 198.51.100.10:80
After PAT: 203.0.113.5:10002 → 198.51.100.10:80
The NAT/PAT Table:
PAT Translation Table (Extended NAT Table)============================================ | Proto | Inside Local | Inside Global | Outside Global ||-------|---------------------|---------------------|----------------------|| TCP | 192.168.1.10:50000 | 203.0.113.5:10001 | 198.51.100.10:80 || TCP | 192.168.1.20:50000 | 203.0.113.5:10002 | 198.51.100.10:80 || TCP | 192.168.1.10:50001 | 203.0.113.5:10003 | 142.250.80.46:443 || UDP | 192.168.1.30:53421 | 203.0.113.5:53421 | 8.8.8.8:53 | Note: The "Inside Global" column shows the translated source IP:Port The PAT router assigns unique external ports to differentiate connections Port Assignment Strategy:- Attempt to preserve source port when possible (53421 → 53421)- If port already in use, assign from pool (50000 → 10001, 10002, ...)- Ports 1-1023 typically avoided (reserved/privileged)- Dynamic range: 1024-65535 available (64,512 ports)Step-by-Step Translation Process:
Outbound (Inside to Outside):
Inbound (Return Traffic):
The magic of PAT lies in the external port number. When responses return, the router doesn't know the internal host from the IP (it's shared). It knows FROM THE PORT. Port 10001 → Host A. Port 10002 → Host B. This is why the PAT table records the complete (inside IP:port, outside IP:port, external IP:port, protocol) tuple.
How many connections can a single public IP support via PAT? The answer involves both theoretical limits and practical constraints.
Theoretical Maximum:
Transport layer ports are 16-bit numbers (0-65535). However, the actual limits are more nuanced:
Total ports: 65,536 (0-65535)
Reserved ports: 0 (unusable) = 1
Well-known ports: 1-1023 (typically avoided)
Registered ports: 1024-49151 (available)
Dynamic/private ports: 49152-65535 (preferred for PAT)
Typical usable range: 1024-65535 = 64,512 ports
But wait, there's more!
The PAT table key is actually a 5-tuple:
This means connections to DIFFERENT external servers can reuse the same translated source port:
PAT Port Reuse Through Destination Differentiation=================================================== These translations can coexist (same source port, different destinations): | Proto | Inside Local | Inside Global | Outside Global ||-------|--------------------|--------------------|----------------------|| TCP | 192.168.1.10:50000 | 203.0.113.5:10001 | 198.51.100.10:80 || TCP | 192.168.1.20:50000 | 203.0.113.5:10001 | 142.250.80.46:443 | ^^^^^ ^^^^^^^^^^^^^^ Same port! Different server! Why this works:- Return packet from 198.51.100.10:80 to 203.0.113.5:10001 → Host A- Return packet from 142.250.80.46:443 to 203.0.113.5:10001 → Host B The FULL 5-tuple (protocol, src IP:port, dst IP:port, direction) is unique. Theoretical maximum with full 5-tuple optimization:~65,000 ports × unlimited unique destinations = millions of connections However, most implementations don't fully optimize this way.Practical Constraints:
In real deployments, the limit is rarely the port count. Other factors constrain first:
| Constraint | Typical Limit | Impact |
|---|---|---|
| Connection Table Memory | ~200-400 bytes/entry | 1M connections = 200-400 MB RAM |
| CPU for Translation | Varies by hardware | Software NAT slower than ASIC-based |
| Port Pool Size | ~64,000 per destination IP | High fan-out to same server is limited |
| Conntrack Table Size | Linux default: 65536 | Must be tuned for high-scale NAT |
| TCP Timeout | 5 days default | Long-lived connections consume ports |
12345678910111213141516171819202122
# Linux Conntrack Tuning for High-Scale PAT# ========================================== # View current connection count and limitcat /proc/sys/net/netfilter/nf_conntrack_count # Current connectionscat /proc/sys/net/netfilter/nf_conntrack_max # Maximum (default: 65536) # Increase maximum connections for high-scale NATsysctl -w net.netfilter.nf_conntrack_max=262144 # 256K connectionssysctl -w net.nf_conntrack_max=262144 # Alternative location # Reduce timeouts to recycle ports fastersysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600 # 1 hoursysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30 # 30 secsysctl -w net.netfilter.nf_conntrack_udp_timeout=30 # 30 secsysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=60 # 60 sec # Memory impact: each entry ~300 bytes# 262144 entries × 300 bytes ≈ 75 MB RAM for connection tracking # Monitor conntrack healthconntrack -S # Show statistics including drops/failuresIf many internal hosts connect to the SAME external server, they compete for the ~64K available source ports to that single destination. This is common with CDNs, API endpoints, or busy services. Solutions include: multiple PAT IPs, shorter timeouts, or load balancing across destination IPs. This limit is often hit before reaching general PAT capacity.
PAT configuration is straightforward—it's often the default behavior for consumer routers. Let's examine configurations across different platforms.
12345678910111213141516171819202122232425262728293031323334
! Cisco IOS PAT Configuration! ============================ ! Option 1: PAT using interface address (most common)! All internal traffic translated to outside interface IPinterface GigabitEthernet0/0 ip address 192.168.1.1 255.255.255.0 ip nat inside!interface GigabitEthernet0/1 ip address 203.0.113.5 255.255.255.0 ip nat outside!! Define internal hosts that can use NATaccess-list 1 permit 192.168.1.0 0.0.0.255!! Enable PAT with 'overload' keyword (critical!)ip nat inside source list 1 interface GigabitEthernet0/1 overload ! Option 2: PAT using a pool of addresses (multiple IPs)ip nat pool PAT_POOL 203.0.113.10 203.0.113.15 netmask 255.255.255.0ip nat inside source list 1 pool PAT_POOL overload ! Verification:! show ip nat translations! Pro Inside global Inside local Outside local Outside global! tcp 203.0.113.5:1024 192.168.1.10:5000 198.51.100.1:80 198.51.100.1:80! tcp 203.0.113.5:1025 192.168.1.20:5000 198.51.100.1:80 198.51.100.1:80! udp 203.0.113.5:53411 192.168.1.30:5511 8.8.8.8:53 8.8.8.8:53 ! show ip nat statistics! Total active translations: 1523 (0 static, 1523 dynamic; 1523 extended)! Peak translations: 2847! (extended indicates PAT entries with ports)On Linux, use MASQUERADE when your external IP may change (DHCP from ISP)—it automatically detects the current IP. Use SNAT when your external IP is static—it's slightly more efficient since it doesn't need to check the interface address for each packet. For most home/SOHO setups, MASQUERADE is simpler and just works.
PAT, like Dynamic NAT, does not inherently allow inbound connections. Since translations only exist for outbound-initiated sessions, external hosts cannot reach internal servers by default.
Port Forwarding (also called Port Mapping or Destination NAT) solves this by creating static mappings for specific ports:
Static Port Forward:
External 203.0.113.5:80 → Internal 192.168.1.100:80
External 203.0.113.5:443 → Internal 192.168.1.100:443
External 203.0.113.5:22 → Internal 192.168.1.200:22
This allows specific services on internal hosts to be reachable from the Internet while still using PAT for general outbound traffic.
12345678910111213141516171819202122232425262728
! Cisco IOS Port Forwarding! ========================== ! Static NAT for specific port (port forwarding)! Syntax: ip nat inside source static <proto> <local-ip> <local-port> <global-ip> <global-port> ! Forward external port 80 to internal web serverip nat inside source static tcp 192.168.1.100 80 203.0.113.5 80 ! Forward external port 443 (HTTPS)ip nat inside source static tcp 192.168.1.100 443 203.0.113.5 443 ! Forward external port 2222 to internal SSH on non-standard portip nat inside source static tcp 192.168.1.200 22 203.0.113.5 2222 ! Forward UDP for game serverip nat inside source static udp 192.168.1.150 27015 203.0.113.5 27015 ! These coexist with PAT - outbound still uses overload, inbound uses static entries ! Verification:! show ip nat translations! Pro Inside global Inside local Outside local Outside global! tcp 203.0.113.5:80 192.168.1.100:80 --- ---! tcp 203.0.113.5:443 192.168.1.100:443 --- ---! tcp 203.0.113.5:2222 192.168.1.200:22 --- ---! udp 203.0.113.5:27015 192.168.1.150:27015 --- ---! tcp 203.0.113.5:10001 192.168.1.50:5000 198.51.100.1:80 198.51.100.1:80 (dynamic PAT)Every port forward exposes an internal service to the Internet. Only forward ports for services that: • Are designed for Internet exposure • Are kept patched and updated • Have proper authentication • Are monitored for attacks
Never forward RDP (3389), SMB (445), or database ports unless through a VPN. These are prime attack targets.
PAT works transparently with most protocols, but some require special handling due to how they use addresses and ports.
Protocols That Work Well with PAT:
| Protocol | PAT Behavior | Notes |
|---|---|---|
| HTTP/HTTPS | ✓ Works perfectly | Standard client-initiated request-response |
| DNS | ✓ Works perfectly | Simple UDP query-response |
| SMTP/IMAP/POP3 | ✓ Works well | Outbound email clients work; servers need port forward |
| SSH/Telnet | ✓ Works perfectly | Single TCP connection |
| FTP (Passive) | ✓ Works well | Data connections initiated outbound |
Protocols That Struggle with PAT:
| Protocol | Problem | Solution |
|---|---|---|
| FTP (Active) | Server initiates data connection to client's IP/port embedded in PORT command | FTP ALG or use Passive mode |
| SIP/VoIP | RTP media streams use IPs embedded in SDP; dynamic port ranges | SIP ALG (often buggy), STUN/TURN, or session border controller |
| IPsec (AH mode) | Authentication covers IP header including addresses | Use ESP mode with NAT-T (UDP encapsulation) |
| ICMP | No port numbers; uses ID field for tracking | NAT uses ICMP ID as pseudo-port; works but limited |
| GRE/IP-in-IP | No port numbers at all | One GRE tunnel per external IP; use GRE over UDP |
NAT-T (NAT Traversal) for IPsec:
IPsec ESP can work behind NAT using NAT-Traversal (RFC 3947), which encapsulates ESP packets in UDP (port 4500):
Without NAT-T:
[IP Header][ESP Header][Encrypted Payload]
↑ NAT changes IP, but ESP authentication may fail
With NAT-T:
[IP Header][UDP 4500][ESP Header][Encrypted Payload]
↑ NAT changes IP/port, UDP provides port for translation
↑ This gives NAT a port to work with
STUN/TURN/ICE for WebRTC and VoIP:
Modern real-time communication uses these NAT traversal protocols:
These allow VoIP and video calling to work behind most NAT configurations without relying on buggy ALGs.
Application Layer Gateways (ALGs) built into routers (SIP ALG, FTP ALG) are often buggy and cause more problems than they solve. Modern applications typically handle NAT traversal themselves using STUN/TURN. If you experience VoIP or conferencing issues, try disabling SIP ALG in your router settings.
When PAT doesn't work as expected, systematic troubleshooting narrows down the cause. Here are common issues and diagnostic approaches.
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657
# PAT Troubleshooting Checklist# ============================== # ---- Step 1: Verify IP forwarding is enabled ----# Linux:cat /proc/sys/net/ipv4/ip_forward # Should be: 1# Cisco: Enabled by default when NAT configured # ---- Step 2: Verify NAT rules exist ----# Linux:iptables -t nat -L -v -n# Look for MASQUERADE or SNAT in POSTROUTING chain # Cisco:show ip nat translations # View active translationsshow running-config | include ip nat # View NAT config # ---- Step 3: Check connection tracking / NAT table ----# Linux:conntrack -L # View all tracked connectionsconntrack -C # Count connectionsconntrack -S # Statistics - look for drops # Cisco:show ip nat statistics # Look for 'misses' (failures)show ip nat translations verbose # Detailed translation info # ---- Step 4: Test with packet capture ----# Capture on inside interface:tcpdump -i eth0 -n host 192.168.1.100 # Capture on outside interface:tcpdump -i eth1 -n host 203.0.113.5 # Compare: packets should appear on both, with different source IPs # ---- Step 5: Test specific translation ----# From internal host, access external resourcecurl -v http://ifconfig.me # Shows your public IP # If this shows your NAT IP, PAT is working# If it shows internal IP or fails, PAT is not working # ---- Step 6: Check for port exhaustion ----# Linux:conntrack -L | wc -l # Current connections# If approaching nf_conntrack_max, exhaustion possible # Check errors:dmesg | grep conntrack # Look for "table full" errors # ---- Step 7: Verify port forward (if applicable) ----# Test from external host:nc -zv <public-ip> <forwarded-port> # TCP port test # Check that DNAT rule exists:iptables -t nat -L PREROUTING -v -nOn Linux, the dreaded 'nf_conntrack: table full, dropping packet' message in dmesg indicates connection tracking exhaustion. This causes random connection failures. Solutions:
We've comprehensively covered Port Address Translation, the NAT mechanism that underpins most Internet connectivity for end-users and organizations worldwide.
Module Complete:
You have now completed the comprehensive NAT module, covering:
With this knowledge, you can design, configure, troubleshoot, and secure NAT implementations across enterprise, cloud, and consumer environments. You understand not just how NAT works, but when each type is appropriate and what limitations to expect.
Congratulations! You now have comprehensive mastery of Network Address Translation. From understanding the IPv4 exhaustion crisis that motivated NAT, through the private address spaces it relies upon, to the three major NAT types (Static, Dynamic, PAT) and their configurations—you possess the knowledge to work with NAT at an expert level.