Private And Public Ip - Learning Module

Loading content...

0/228

NAT Relationship

The Bridge Between Private and Public

Network Address Translation (NAT) is the technology that makes private addressing practical. Without NAT, devices using RFC 1918 addresses would be completely isolated from the Internet—capable of internal communication only. NAT bridges this gap, enabling billions of privately-addressed devices to access Internet resources while conserving the scarce public IPv4 address space.

Understanding NAT is not optional for modern network professionals. Every home router, enterprise firewall, cloud VPC, and mobile carrier deploys NAT. The technology appears deceptively simple—just rewrite IP addresses in packet headers—but its implications ripple through protocol design, application architecture, security models, and troubleshooting practices.

What You Will Learn

This page provides comprehensive coverage of NAT: its operational mechanics, the distinction between static NAT, dynamic NAT, and PAT (NAPT), connection tracking and state management, NAT's impact on protocols and applications, traversal techniques, and the architectural tradeoffs NAT introduces to network design.

NAT Fundamentals

At its core, NAT modifies IP packet headers as they traverse a network boundary, replacing source or destination addresses (and often ports) to enable communication between differently-addressed networks.

Basic SNAT (Source NAT) operation:

When an internal host initiates a connection to the Internet:

┌─────────────────────────────────────────────────────────────────┐
│                    OUTBOUND PACKET FLOW                          │
└─────────────────────────────────────────────────────────────────┘

  Internal Host            NAT Router              Internet Server
   10.0.1.50                                         93.184.216.34
      │                        │                          │
      │  Src: 10.0.1.50:45678  │                          │
      │  Dst: 93.184.216.34:80 ├─────────────────────────┤
      ├───────────────────────►│                          │
      │                        │  Src: 203.0.113.1:12345  │
      │                        │  Dst: 93.184.216.34:80   │
      │                        ├─────────────────────────►│
      │                        │                          │

┌─────────────────────────────────────────────────────────────────┐
│                    RESPONSE PACKET FLOW                          │
└─────────────────────────────────────────────────────────────────┘

      │                        │  Src: 93.184.216.34:80   │
      │                        │  Dst: 203.0.113.1:12345  │
      │                        │◄─────────────────────────┤
      │  Src: 93.184.216.34:80 │                          │
      │  Dst: 10.0.1.50:45678  │                          │
      │◄───────────────────────┤                          │

What the NAT router does:

Receives outbound packet with private source IP (10.0.1.50)
Records translation mapping in NAT table: 10.0.1.50:45678 ↔ 203.0.113.1:12345
Rewrites source address to public IP (203.0.113.1) and possibly port
Recalculates checksums (IP and TCP/UDP) to reflect modified headers
Forwards packet to the Internet
When response arrives, uses NAT table to reverse the translation

Stateful Operation

NAT introduces state into network devices. Unlike traditional routing (which is stateless—each packet handled independently), NAT routers must track active connections to correctly translate return traffic. This state has memory implications, timeout behaviors, and failure mode considerations that pure routing doesn't have.

Static NAT: One-to-One Mapping

Static NAT creates a permanent, bidirectional mapping between one private IP address and one public IP address. The mapping exists regardless of whether any connections are active.

Configuration example (conceptual):

Static NAT Rule:
  Inside: 10.0.1.100 (Web Server)
  Outside: 203.0.113.10
  
Result:
- Outbound from 10.0.1.100 → appears as 203.0.113.10
- Inbound to 203.0.113.10 → forwarded to 10.0.1.100

Static NAT characteristics:

Aspect	Static NAT Behavior
Mapping persistence	Permanent—exists without active connections
Directionality	Bidirectional—inbound connections work
Address ratio	1:1 (one public per private)
Address conservation	None—consumes public IPs
Use case	Servers requiring inbound connectivity

Static NAT Use Cases

•Web servers — External users must initiate connections to server's public address
•Mail servers — SMTP requires predictable inbound connectivity for mail reception
•VPN concentrators — Remote users connect to static public endpoint
•DNS servers — Authoritative DNS must be reachable at stable addresses
•Load balancer frontends — Virtual IPs mapped to internal load balancer clusters

Address mapping table visualization:

┌────────────────────────────────────────────────────────────┐
│                    STATIC NAT TABLE                         │
├─────────────────────┬──────────────────────┬───────────────┤
│    Private IP       │     Public IP        │   Purpose     │
├─────────────────────┼──────────────────────┼───────────────┤
│    10.0.1.100       │    203.0.113.10      │  Web Server   │
│    10.0.1.101       │    203.0.113.11      │  Mail Server  │
│    10.0.1.102       │    203.0.113.12      │  VPN Gateway  │
│    10.0.1.103       │    203.0.113.13      │  DNS Server   │
└─────────────────────┴──────────────────────┴───────────────┘

Each static mapping consumes one public IP, making this approach unsuitable for large-scale deployments where address conservation is needed.

When to Use Static NAT

Choose static NAT when the internal device must accept unsolicited inbound connections and when address consumption is acceptable. If only client-initiated outbound access is needed, PAT/dynamic NAT is more appropriate.

Dynamic NAT: Pool-Based Mapping

Dynamic NAT allocates public addresses from a pool on-demand when internal hosts initiate connections. Unlike static NAT, mappings are temporary—they exist only while connections are active and are released after idle timeout.

Dynamic NAT operation:

Configuration:
  Inside network: 10.0.1.0/24 (254 potential hosts)
  Outside pool: 203.0.113.16/28 (14 usable public IPs)

Connection flow:
  10.0.1.50 initiates connection → assigned 203.0.113.17 (first available)
  10.0.1.51 initiates connection → assigned 203.0.113.18 (next available)
  10.0.1.52 initiates connection → assigned 203.0.113.19
  ...
  10.0.1.65 initiates connection → BLOCKED! Pool exhausted (all 14 in use)

After timeout:
  10.0.1.50's connections close → 203.0.113.17 returns to pool
  10.0.1.65 retries → now receives 203.0.113.17

Dynamic NAT vs Static NAT Comparison
Characteristic	Static NAT	Dynamic NAT
Mapping creation	Manual configuration	On-demand allocation
Mapping lifetime	Permanent	Temporary (connection-based)
Address pool	One IP per host	Shared pool among hosts
Inbound connections	Supported (always mapped)	Not supported (no pre-existing mapping)
Address conservation	None	Moderate (pool sharing)
Scalability	Limited by public IPs	Limited by pool size

Pool Exhaustion

Dynamic NAT's critical weakness is pool exhaustion. If more internal hosts attempt simultaneous connections than available public IPs in the pool, excess connections fail. This creates unpredictable outages under load and is why pure dynamic NAT (without PAT) is rarely deployed in modern networks.

Practical limitations:

Dynamic NAT still maintains a 1:1 ratio between active connections and public addresses. An organization with 1,000 users would need a pool of 1,000 public IPs to guarantee simultaneous connectivity—hardly conservation.

This limitation led to the development of PAT (Port Address Translation), which enables many internal hosts to share a single public IP by differentiating connections via port numbers.

PAT/NAPT: The Dominant NAT Variant

Port Address Translation (PAT), also called NAPT (Network Address and Port Translation) or IP Masquerading, is the NAT variant deployed in virtually every home router, enterprise firewall, and cloud NAT gateway. PAT achieves massive address conservation by translating both addresses and ports.

How PAT works:

Multiple internal hosts share a single public IP. Each connection is distinguished by a unique source port on the public side:

┌──────────────────────────────────────────────────────────────────┐
│                        PAT TRANSLATION                            │
├──────────────────────────────────────────────────────────────────┤
│                                                                   │
│  Internal                    Public                  Destination  │
│  10.0.1.50:45678  ────►  203.0.113.1:10001  ────►  93.184.1.34:80│
│  10.0.1.51:45678  ────►  203.0.113.1:10002  ────►  93.184.1.34:80│
│  10.0.1.50:45679  ────►  203.0.113.1:10003  ────►  8.8.8.8:53    │
│  10.0.1.52:33000  ────►  203.0.113.1:10004  ────►  1.1.1.1:443   │
│                                                                   │
│  Same public IP ─────────────────┘                                │
│  Different public ports distinguish connections                   │
└──────────────────────────────────────────────────────────────────┘

PAT Translation Table:

┌───────────────────────────────────────────────────────────────────────┐
│                         PAT STATE TABLE                                │
├────────────────────┬─────────────────────┬────────────────────┬───────┤
│ Inside Local       │ Inside Global       │ Outside Global     │ Timer │
├────────────────────┼─────────────────────┼────────────────────┼───────┤
│ 10.0.1.50:45678    │ 203.0.113.1:10001   │ 93.184.216.34:80   │ 120s  │
│ 10.0.1.51:45678    │ 203.0.113.1:10002   │ 93.184.216.34:80   │ 45s   │
│ 10.0.1.50:45679    │ 203.0.113.1:10003   │ 8.8.8.8:53         │ 30s   │
│ 10.0.1.52:33000    │ 203.0.113.1:10004   │ 1.1.1.1:443        │ 300s  │
│ 10.0.1.53:22345    │ 203.0.113.1:10005   │ 142.250.80.46:443  │ 180s  │
└────────────────────┴─────────────────────┴────────────────────┴───────┘

Port Space Limits

TCP and UDP port numbers are 16-bit values (1-65535). A single public IP can theoretically support ~65,000 concurrent connections via PAT. In practice, operating systems reserve some port ranges, and connection churn requires headroom, so practical limits are typically 30,000-50,000 concurrent connections per public IP.

PAT Characteristics

•Massive conservation — Thousands of hosts share one public IP (theoretical 65K:1, practical 10K-30K:1)
•Outbound-only by default — Internal hosts can initiate connections; inbound requires explicit port forwarding
•Connection tracking mandatory — Router must maintain state for every active connection to translate return traffic
•Protocol awareness required — Special handling needed for protocols embedding addresses in payloads (SIP, FTP, H.323)
•Transparent to most applications — Standard client software (browsers, email clients) works without modification

Connection Tracking and State Management

NAT devices must track every active connection to correctly translate return traffic. This connection tracking (or session tracking) is the stateful component that distinguishes NAT from stateless routing.

Connection state lifecycle:

┌────────────────────────────────────────────────────────────────────┐
│               TCP CONNECTION TRACKING STATES                        │
└────────────────────────────────────────────────────────────────────┘

              SYN sent                SYN-ACK received
    ○ ─────────────────► NEW ─────────────────────────► ESTABLISHED
                          │                                   │
                          │ Timeout                           │ FIN/RST
                          ▼                                   ▼
                       DELETED                          TIME_WAIT
                                                              │
                                                              │ Timeout
                                                              ▼
                                                           DELETED

┌────────────────────────────────────────────────────────────────────┐
│               UDP CONNECTION TRACKING STATES                        │
└────────────────────────────────────────────────────────────────────┘

              First packet               Reply received
    ○ ─────────────────► NEW ────────────────────────► ESTABLISHED
                          │                                   │
                          │ Timeout (30s typically)           │ Timeout (180s)
                          ▼                                   ▼
                       DELETED                             DELETED

Typical Connection Tracking Timeouts
Protocol/State	Typical Timeout	Purpose
TCP ESTABLISHED	5 days	Long-lived connections (SSH, database)
TCP TIME_WAIT	120 seconds	Cleanup after connection close
TCP SYN_SENT	60 seconds	Half-open connections
UDP Established	180 seconds	Active UDP flows
UDP New	30 seconds	Awaiting reply
ICMP	30 seconds	Ping/traceroute

Memory Exhaustion Risk

Each connection entry consumes memory (typically 300-500 bytes). A device handling 100,000 concurrent connections needs 30-50MB just for the connection table. DDoS attacks often target this limit—flooding with SYN packets creates entries faster than they expire, eventually exhausting table space and blocking legitimate connections.

Connection table entry structure:

Struct connection_entry {
  // 5-tuple identifying the connection
  uint8_t   protocol;        // TCP=6, UDP=17
  uint32_t  src_ip_inside;   // 10.0.1.50
  uint16_t  src_port_inside; // 45678
  uint32_t  dst_ip;          // 93.184.216.34
  uint16_t  dst_port;        // 80
  
  // Translation information
  uint32_t  src_ip_outside;  // 203.0.113.1
  uint16_t  src_port_outside;// 10001 (assigned by NAT)
  
  // State tracking
  uint8_t   state;           // NEW, ESTABLISHED, etc.
  uint32_t  timeout;         // Seconds until expiration
  uint64_t  packets_in;      // Statistics
  uint64_t  packets_out;
  uint64_t  bytes_in;
  uint64_t  bytes_out;
}

High-performance NAT devices use hash tables indexed by the 5-tuple for O(1) lookups on every packet.

NAT's Impact on Protocols and Applications

NAT fundamentally breaks the Internet's original end-to-end principle, where any host could directly communicate with any other host. This breakage has profound implications for protocols and applications.

The end-to-end principle violation:

Original Internet Model (pre-NAT):

  Host A ◄───────────────────────────────────────────────► Host B
  1.2.3.4                    Direct path                   5.6.7.8
  
  - Either host can initiate
  - Addresses are globally unique
  - No intermediary state required

NAT Model:

  Host A ◄─────► NAT ◄───────────────────────────────────► Host B
  10.0.1.5     Router            Public Internet            5.6.7.8
  
  - Host A can initiate to B ✓
  - Host B cannot initiate to A ✗ (no public address for A)
  - NAT maintains state; failure = disconnection

NAT Impact on Common Protocols
Protocol	Problem	Solution
FTP (Active mode)	Server opens data connection to client's private IP	ALG rewrites PORT command; use passive mode
SIP/VoIP	SDP payloads contain private IP for media	SIP ALG or STUN/TURN for media relay
H.323	Complex payload address embedding	H.323 ALG or tunnel-based solutions
IPsec (AH)	AH checksum includes IP header—NAT breaks it	Use ESP with NAT-T (UDP encapsulation)
PPTP	GRE protocol lacks ports for PAT	PPTP ALG or use alternatives (L2TP/IPsec)
BitTorrent	Peers can't connect to client behind NAT	UPnP, NAT-PMP, or relay through trackers
Online Gaming	P2P elements require inbound connectivity	UPnP or manual port forwarding

Application Layer Gateways (ALGs)

NAT devices include protocol-specific helpers called ALGs that inspect and rewrite payloads containing embedded addresses. While necessary, ALGs add complexity, may have security vulnerabilities, and can't handle encrypted protocols (since they can't read encrypted payloads). Modern best practice is to minimize ALG use and design applications for NAT-awareness.

Protocols Most Affected by NAT

•Peer-to-peer protocols — Both endpoints may be behind NAT; neither can accept inbound connections without traversal techniques
•Real-time communication — VoIP, video conferencing require low-latency bidirectional media streams
•Multi-channel protocols — FTP, SIP separate control and data; data channels need special handling
•Embedded address protocols — Any protocol including IP addresses in payloads (not just headers)
•Non-TCP/UDP protocols — ICMP, GRE, SCTP lack port numbers, requiring special NAT handling

NAT Traversal Techniques

Since NAT prevents inbound connections to privately-addressed hosts, various NAT traversal techniques enable peer-to-peer connectivity despite this limitation.

Major traversal approaches:

NAT Traversal Methods

•Port Forwarding — Manual NAT configuration creating static inbound mappings. Reliable but requires admin access to NAT device
•UPnP (Universal Plug and Play) — Applications request port mappings from NAT device automatically. Convenient but security-risky if exposed
•NAT-PMP / PCP — Apple's NAT Port Mapping Protocol and its successor (Port Control Protocol) for dynamic port mapping requests
•STUN (Session Traversal Utilities for NAT) — Discovers public IP/port and NAT type; enables direct connectivity if NAT permits
•TURN (Traversal Using Relays around NAT) — Relays all traffic through server when direct connectivity fails; always works but adds latency
•ICE (Interactive Connectivity Establishment) — Framework combining STUN, TURN, and local candidates to find best available path

STUN Operation:

┌─────────────────────────────────────────────────────────────────────┐
│                         STUN DISCOVERY                               │
└─────────────────────────────────────────────────────────────────────┘

   Client                    NAT                     STUN Server
   10.0.1.50                Router                   stun.example.com
      │                        │                          │
      │ Bind Request           │                          │
      │ (from 10.0.1.50:3478)  │                          │
      ├───────────────────────►│                          │
      │                        │ Bind Request             │
      │                        │ (from 203.0.113.1:45678) │
      │                        ├─────────────────────────►│
      │                        │                          │
      │                        │ Bind Response:           │
      │                        │ "You appear as           │
      │                        │  203.0.113.1:45678"      │
      │                        │◄─────────────────────────┤
      │ Bind Response          │                          │
      │◄───────────────────────┤                          │
      │                                                   │
      │  ✓ Client now knows:                              │
      │    Public IP: 203.0.113.1                         │
      │    Public Port: 45678                             │
      │    Can share this with peers for direct connection│
      │

NAT Types and Traversal Success:

NAT Type	Also Known As	Direct P2P Possible
Full Cone	EIM/EIF (Endpoint-Independent Mapping/Filtering)	Yes—any external host can reach mapping
Address-Restricted Cone	EIM/ADF (Address-Dependent Filtering)	Yes—if client contacted that address first
Port-Restricted Cone	EIM/APDF	Usually yes—with hole-punching
Symmetric	APDM (Address-Port-Dependent Mapping)	Difficult—different mapping per destination

ICE: The Modern Standard

WebRTC and modern VoIP systems use ICE to negotiate connectivity. ICE gathers all possible connection candidates (local, server-reflexive via STUN, and relayed via TURN), then tests connectivity through each path, selecting the best available. This ensures connectivity even between hosts behind restrictive NATs.

NAT's Architectural Implications

NAT's ubiquity has fundamentally reshaped Internet architecture and application design patterns.

NAT Benefits

•Address conservation — Primary benefit; enabled Internet growth beyond IPv4 limits
•Implicit security — Inbound connections blocked by default; provides rudimentary firewall
•Topology hiding — Internal network structure invisible to external observers
•Addressing flexibility — Renumber internal networks without coordinating with ISP
•Multi-homing enablement — Easier to connect to multiple ISPs with PAT

NAT Drawbacks

•End-to-end connectivity broken — Peer-to-peer inherently difficult
•State and failure modes — NAT device failure drops all connections
•Application complexity — Must handle traversal, ALGs, hole-punching
•Protocol ossification — New transport protocols hard to deploy through NAT
•Troubleshooting complexity — Address translation obscures actual endpoints

Architectural patterns NAT created:

Client-server dominance — Since clients can reach servers but not vice versa, Internet architecture shifted toward centralized services rather than peer-to-peer
Cloud/SaaS models — Applications moved to public-IP infrastructure (cloud) rather than on-premises, partly because reaching internal servers became complex
WebSocket/long-polling — Web applications use persistent outbound connections to receive 'pushed' updates (since servers can't initiate to browsers behind NAT)
Relay-based communication — Services like Slack, Discord, Teams route messages through central servers even when users are on the same network
Mobile dependency on push services — APNS/FCM exist partly because mobile devices behind carrier NAT can't receive inbound connections

IPv6's NAT-less Promise

IPv6 was designed explicitly to eliminate NAT by providing abundant addresses. In theory, every device can have a globally-routable IPv6 address, restoring end-to-end connectivity. In practice, some organizations still deploy IPv6 NAT (NAT66) for policy reasons despite this being contrary to IPv6's design philosophy.

Summary: NAT Relationship

Network Address Translation bridges the private and public addressing domains, enabling billions of devices to access the Internet while consuming minimal public IPv4 addresses. Understanding NAT is essential for anyone working with modern networks.

Key Takeaways

•Static NAT provides permanent 1:1 mappings for servers requiring inbound connectivity, but offers no address conservation.
•Dynamic NAT allocates from pools on-demand but still maintains 1:1 ratios and suffers pool exhaustion under load.
•PAT/NAPT is the dominant NAT variant — thousands of hosts share single public IPs through port differentiation.
•Connection tracking is fundamental — NAT devices maintain state for every active connection, with memory and timeout implications.
•NAT breaks end-to-end connectivity — inbound connections require explicit configuration; many protocols need special handling.
•NAT traversal techniques (STUN, TURN, ICE) enable peer-to-peer connectivity despite NAT's default blocking of inbound connections.

What's next:

The final page of this module examines IPv6 implications—how the transition to IPv6 addresses the problems that NAT was designed to solve, and what the future holds for private and public addressing as the Internet evolves toward its next-generation protocol stack.

Page Complete

You now possess comprehensive knowledge of how NAT enables private addresses to communicate with the public Internet, the variations of NAT, and its profound impact on protocol and application design. This understanding is essential for troubleshooting connectivity issues and designing modern network architectures.