NAT and PAT Explained — How the IPv4 Internet Survives

Read as

Last updated: May 1, 2026

Network Address Translation maps private IPv4 addresses to public ones, allowing many devices to share a single public IP. PAT (Port Address Translation, often called NAPT or “NAT overload”) is the variant most home routers and enterprise edges use. NAT is the duct-tape that kept IPv4 alive past its 32-bit address-space exhaustion, but it broke end-to-end addressing, complicates protocols, and creates real security side-effects (some good, some bad). This module covers static NAT, dynamic NAT, PAT, hairpinning, NAT traversal (STUN/TURN), and what NAT does — and does not — give you in security.

Almost every device you have ever used to access the Internet sat behind NAT. Yet most engineers carry only a vague mental model of what NAT actually does, which is a problem because NAT-related issues are the cause of about a third of all “this app does not work” tickets. This module gives you the precise model: how the translation table works, what PAT does differently, why some protocols (FTP, SIP, IPsec) need helpers, and how the NAT-traversal techniques (STUN, TURN, ICE) you find in WebRTC work.

Why NAT exists — the address-exhaustion story

IPv4 has 32 bits — 4.3 billion addresses, of which roughly 3.7 billion are usable (excluding reserved blocks). The Internet has more devices than that. The exhaustion was projected as early as 1992; CIDR (1993) bought a decade; NAT (RFC 1631 in 1994, refined in RFC 3022) bought the rest. NAT lets a single public IP front for an arbitrary number of private hosts, multiplexing connections by source port.

The costend-to-end addressability is lost (a host behind NAT cannot be reached unless the NAT explicitly forwards a port), and any protocol that embeds IP addresses in payload (FTP PORT, SIP, H.323, SDP) needs application-aware translation. IPv6 was supposed to make NAT obsolete — and on IPv6 it largely is — but on the IPv4 Internet, NAT is everywhere and not going anywhere.

Static NAT, dynamic NAT, PAT — the three shapes

Static NAT1:1 mapping. Public IP 198.51.100.10 always maps to private 10.0.0.10. Used for “publish a server to the Internet” patterns.

Dynamic NAT1:1 from a pool. Several private hosts share a pool of N public IPs; first come first served. Increasingly rare.

PAT (Port Address Translation, NAPT)many-to-one. Multiple private hosts share a single public IP, distinguished by source port. This is what your home router does and what ~90% of enterprise edges do. The PAT translation table is keyed by (privateIP, privatePort, publicIP, publicPort, protocol), with timeouts (TCP idle ~24h, UDP ~30s, ICMP ~60s). Most “the connection dropped after 30 seconds” issues are PAT timeout for UDP (DNS, gaming, voice). Tune timeouts per protocol; do not set blanket 30-second timeouts.

Hairpinning, NAT loopback, and the trap

Hairpinning (also called NAT loopback): a host behind NAT tries to reach the public IP of another host behind the same NAT. Old NAT implementations dropped the packet (“you should know to use the private IP”). Modern NATs hairpin: the packet goes to the public IP, the NAT recognises both ends are inside, and routes the traffic back.

Why this matterssplit-horizon DNS is the workaround when hairpinning does not work — internal queries return the private IP. Cloud NAT gateways (AWS NAT Gateway, Azure NAT Gateway) handle this differently from on-prem; verify before deploying internal services that reference public hostnames.

NAT traversal — STUN, TURN, ICE, and why WebRTC works

A host behind NAT wants peer-to-peer connectivity (VoIP, video calls, peer-to-peer file transfer). Without help, no incoming connection can reach it. STUN (RFC 5389): the host queries a STUN server on the Internet, learns its own public IP+port mapping. TURN (RFC 8656): if STUN reveals symmetric NAT (port differs per destination), peer-to-peer is impossible — TURN relays the entire media stream through a server. ICE (RFC 8445): the candidate-gathering algorithm that probes both STUN-discovered and TURN-relay paths and picks the best. WebRTC (the browser API behind every video-call app) uses STUN+TURN+ICE under the hood.

Operationsenterprises that block UDP wholesale break VoIP and video calls. The right pattern: allow STUN/TURN to your authorised provider; use a corporate TURN server in your DMZ for sensitive comms.

Carrier-grade NAT (CGN) — when even the ISP runs out of IPs

CGN (RFC 6888): an ISP runs PAT for thousands of subscribers behind a shared pool of public IPs. Used widely in mobile (Jio, Airtel) and increasingly in fixed-line residential.

Implicationsthousands of subscribers share a public IP — geolocation, IP-based reputation, and abuse-handling all become noisy.

For service operatorsrate-limiting by source IP penalises everyone behind a CGN; X-Forwarded-For helps if you trust the proxy chain; CGN-shared subscribers cannot be uniquely identified by IP at all.

For investigatorscontacting an Indian mobile ISP for “subscriber behind 100.64.x.y at 14:32 IST” requires the ISP to have logged the inner port mapping. CERT-In’s 2022 directive specifically requires CGN providers to log enough state to attribute connections.

NAT is not a firewall (but it acts like one a little)

A common misconception: “NAT protects me.” Partial truth. NAT typically denies unsolicited inbound by default — there is no translation entry until an outbound flow creates one. So a passive attacker on the Internet cannot port-scan your private hosts.

What NAT does NOT protect againstoutbound C2 channels (NAT cheerfully translates these), application-layer exploits (an internal host connects to a malicious server, NAT-allowed), DNS rebinding (manipulates internal-looking DNS names), and any traffic that originates from inside.

The right framingNAT is connection-oriented allow-by-default-outbound; a stateful firewall is policy-controlled allow/deny in both directions. NAT is not a substitute for explicit firewall rules.

NAT in cloud — AWS, Azure, GCP differences

AWSNAT Gateway (managed, scales automatically, per-AZ, costs per GB processed); Internet Gateway (no NAT, requires public IPs); NAT Instance (legacy, self-managed).

AzureNAT Gateway (similar model); Public IPs on NICs (1:1); Standard Load Balancer outbound rules (legacy default; explicit NAT Gateway is preferred for new builds).

GCPCloud NAT (regional, automatic port allocation; tune dynamic-port-allocation if you have many concurrent connections); IAP for inbound.

Common operational pitfallsSNAT port exhaustion (a single NAT public IP supports ~64K simultaneous flows per destination, less in practice — large outbound bursts run out, manifest as connection failures). Solution: provision multiple public IPs on the NAT, or route a fraction of traffic via a separate NAT path.

Connection logscloud NAT logs are essential for forensics; ensure VPC flow logs + NAT logs are enabled and retained per your incident-response policy.

PAT / SNAT exhaustion — the silent production killer

A single public IP behind PAT supports approximately 64,512 simultaneous flows to the same destination IP+port pair (SNAT port range 1024-65535). Sounds like a lot until you have 1,000 hosts each opening 100 short-lived connections per minute to the same SaaS — which is exactly what modern web apps do. Symptoms: intermittent connection failures, “could not connect” errors, slow page loads, despite plenty of bandwidth. Diagnosis: NAT device counters showing port allocation near 100%; flow logs showing many SYNs without responses; conntrack -L showing a packed table on Linux NAT. Mitigations:

1Provision multiple public IPs on the NAT to multiply available ports.

2Tune timeouts shorter (TCP idle from 24h default to 1h reduces accumulation).

3Spread destination IPs (the per-IP-pair limit means many destinations help).

4Use proxy/CDN for outbound to consolidate. For cloud: AWS NAT Gateway scales automatically up to ~55K concurrent connections per destination IP per AZ; provision one per AZ. Azure: assign multiple public IPs to the NAT Gateway. GCP: tune dynamic-port-allocation.

NAT-T — making IPsec work through PAT

Classic IPsec ESP runs on IP protocol 50 — it has no port number. PAT, which depends on ports for demultiplexing, breaks ESP. NAT-T (NAT Traversal, RFC 3947) wraps ESP inside UDP/4500 so PAT can multiplex it like any UDP flow. NAT-T is auto-detected during IKE phase 1 (IKE on UDP/500 detects NAT and fails over to UDP/4500 for both IKE and ESP).

For deploymentsensure UDP/500 and UDP/4500 are both allowed; verify both peers support NAT-T (every modern stack does).

Symptom of missing NAT-Tphase 1 establishes; phase 2 establishes; ESP traffic does not flow. WireGuard sidesteps the issue entirely by being UDP-native.

The historical costNAT-T added an outer UDP header so MTU is more constrained; tune MSS clamp on the tunnel by 8 bytes when NAT-T is in play.

NAT in cloud-native architectures — the patterns that scale

Modern cloud architectures use NAT in specific predictable patterns:

1NAT Gateway per VPC for egress — private subnets reach internet via the NAT Gateway with assigned EIPs; well-known address that downstream services can allow-list.

2VPC Endpoints for AWS service access — bypasses NAT entirely for S3, DynamoDB, etc.; reduces NAT bandwidth costs and improves latency.

3PrivateLink / Private Service Connect for SaaS access — same idea as VPC Endpoints but for non-AWS services.

4Egress-only Internet Gateway — IPv6 equivalent of NAT (no actual translation, just stateful firewall behaviour).

5Hub-and-spoke with central NAT — Transit Gateway routes to a centralised NAT VPC for egress and inspection. Cost optimisation: AWS NAT Gateway is priced per GB processed; high-volume workloads benefit from VPC Endpoints. Operational note: log NAT Gateway flow logs the same as VPC flow logs; they are part of the audit trail under DPDP-aligned data perimeter.

CGN logging and the CERT-In 2022 directive

CERT-In’s April 2022 directive (under §70B of the IT Act) requires Indian VPN, data-centre, cloud, and ISP operators to maintain certain logs for 180 days, including subscriber-identification details for IP allocations. For CGN operators specifically, the spirit of the directive requires per-subscriber port-block traceability — given a public IP and source port at a timestamp, identify the originating subscriber.

How operators meet thisdeterministic NAT (each subscriber assigned a fixed port range; logging is one row per subscriber per day rather than per flow), or per-flow logging (full-fidelity but expensive). Most large Indian ISPs use deterministic NAT for the CERT-In compliance baseline.

For enterprises consuming CGN serviceunderstand the limits — some legitimate apps (gaming, VoIP, peer-to-peer file transfer) work poorly behind CGN due to port limits. For mission-critical systems, request a non-CGN public-IPv4 allocation or move to IPv6.

Diagrams

PAT — many-to-one, distinguished by source port

Inside (private)                                Outside
   10.0.0.5:54321  ───┐                      ┌──▶ web.example:443
                       \                    /
   10.0.0.6:54321  ──── NAT  198.51.100.1 ──┤   web.example:443
                       /                    \
   10.0.0.7:54321  ───┘                      └──▶ web.example:443

NAT translation table:
  10.0.0.5:54321 ↔ 198.51.100.1:60001 → web:443
  10.0.0.6:54321 ↔ 198.51.100.1:60002 → web:443
  10.0.0.7:54321 ↔ 198.51.100.1:60003 → web:443

Return traffic to public_ip:60002 → demuxed to 10.0.0.6:54321

STUN / TURN / ICE — how WebRTC traverses NAT

  Peer A behind NAT-A           Peer B behind NAT-B
     │                              │
     │  STUN → public mapping        STUN → public mapping
     │                              │
     │ ── ICE candidate exchange via signalling ──
     │                              │
  Try direct UDP between mappings — works if NAT is full-cone
  or address-restricted-cone.

  If symmetric NAT (port differs per destination):
     │ ── relay via TURN server ──▶ Peer B
     │ ◀── relay via TURN server ── Peer B

References & deeper reading

FAQ

Does NAT make me secure?

It blocks unsolicited inbound (which is something) but does nothing about outbound C2 or application-layer attacks. Treat NAT as a side effect of address scarcity, not a security control. Always pair NAT with a deliberate firewall policy.

Why does my SIP / VoIP call drop?

Almost always NAT timeout for UDP. Default UDP timeout on most NATs is 30 seconds; SIP keepalives need to be more frequent. Configure SIP ALG carefully (it often makes things worse) or use SIP over TCP/TLS.

Is CGN ever a problem for me?

Yes if you do IP-reputation, geolocation, or rate-limiting. A single CGN public IP serves thousands of subscribers; banning it bans innocents. Use device fingerprinting + behavioural signals; do not rely on IP alone for abuse decisions.

What about NAT in IPv6?

IPv6 was designed to eliminate NAT. NAT66 exists (RFC 6296) but is discouraged. The IPv6 design is end-to-end addressability + perimeter firewall. Most enterprise IPv6 designs use ULA + perimeter firewall for the same effective behaviour as NAT-with-RFC1918 — without the address translation.

How do I forensically attribute traffic from a NAT?

You need NAT translation logs (per-flow source-port mappings with timestamps). Enable connection logging on your NAT (cloud NAT logs, on-prem firewall conn-track export). Without these, “host behind NAT was at IP X port Y at 14:32” is unanswerable.

Why does my home VoIP work but my office VoIP does not?

Almost always NAT timeout differences. Home routers typically have generous UDP timeouts; corporate firewalls aggressive ones. SIP uses long-lived UDP flows that require keepalives; configure SIP keepalive shorter than firewall UDP idle timeout.

How do I plan IP allocation for a CGN deployment?

Roughly 1 public IP per 1000 subscribers as starting capacity; profile actual flow patterns and adjust. Allocate by service (a separate pool for different abuse-tolerance tiers). Always log per-subscriber port-block assignment for forensic attribution as required by the CERT-In 2022 directive.

⚖️ Legal: Use any techniques described here only on networks you own or have explicit written authorisation to test. In India, unauthorised access is punishable under IT Act §66 (up to 3 years + fine). Pair offensive testing with a signed Statement of Work / Rules of Engagement; pair forensic activity with §65B-aligned chain of custody.

Want this for your team?

Custom team training + practitioner advisory

Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.

Book team training call Replies in 4 working hrs · India-only · Senior consultants

NAT, PAT, and the IPv4 Internet’s Duct Tape