9.3 NAT, NAPT, and Penetration Boundaries
A border outpost has a limited number of public IP addresses but must allow numerous internal connections to originate simultaneously. As a result, IP addresses and ports are repeatedly rewritten.
NAT modifies the IP address in a packet; NAPT (or PAT) further alters the TCP/UDP port, enabling multiple internal flows to share a small pool of external IPv4 addresses. The term "NAT" commonly used in home routers typically refers to stateful NAPT in practice.
1. Outbound NAPT Mapping
inside local outside-visible
192.168.1.10:51000 --TCP--> 203.0.113.5:62001
192.168.1.11:51000 --TCP--> 203.0.113.5:62002The translator preserves the mapping and state, ensuring that replies are translated back from 203.0.113.5:62001 to 192.168.1.10:51000. It also performs incremental updates or recalculations of IP/TCP/UDP checksums and translates the quoted original packet in ICMP error messages accordingly.
The mapping key and inbound filtering behavior are not uniform across all NAT implementations. UDP NAT can reuse the same external mapping for different remote endpoints originating from the same internal endpoint, or it can create distinct mappings. Filtering can allow responses from any remote endpoint or restrict them to only those that originated from previously sent addresses and ports. Protocols designed for traversal cannot assume a single model such as "all NATs are full cone or symmetric."
2. State Has Both Timeout and Capacity Limits
NAPT mapping requires an external port and a state-table entry. UDP lacks a connection handshake, so the translator recovers state via idle timers. TCP can track state using SYN/FIN/RST signals and timers, but crashes or asymmetric paths may leave behind half-open or stale entries.
Long-lived applications must be aware of NAT, firewall, or load balancer idle timeouts. They should use protocol-appropriate keepalive mechanisms and reconnect, rather than relying on frequent, meaningless packets to maintain mappings. The keepalive interval must be shorter than the shortest idle timeout and include jitter, while also considering mobile power and network costs.
Both external address/port assignments and the state table can become exhausted. High fan-out proxies, CGNAT, or large volumes of short-lived connections can fail due to source-port pressure, even when CPU and bandwidth are sufficient. Monitoring active mappings, allocation failures, per-destination tuple pressure, and timeout distributions is essential.
3. Unsolicited Inbound Traffic and Port Forwarding
Without dynamic mapping or filtering permissions, packets arriving from the external side at a shared address:port lack a clear internal destination and are typically dropped. However, the claim that "inbound traffic is absolutely impossible after NAT" is incorrect:
- Static one-to-one mappings
- Static port forwarding
- Reply paths for dynamic mappings
- Mapping control protocols such as PCP, NAT-PMP, and UPnP IGD
- Application-level relaying or reverse tunneling
Automatic port opening via UPnP expands the attack surface of compromised local devices and must be disabled, restricted, or audited according to trust boundaries. Port forwarding must include explicit destination service authentication, regular patching, and comprehensive logging.
Hairpin NAT or NAT loopback enables internal clients to access an internal service via the NAT's external address. Not all devices or configurations support this feature, and failures may manifest as "external access works, but internal access using the public name fails." Split-horizon DNS offers an alternative design, though it introduces additional operational complexity due to differing internal and external DNS responses.
4. NAT Is Not a Firewall
The primary function of NAT is address/port translation, while a firewall's core operation is enforcing traffic based on security policies, allowing or denying connections. Home gateways often combine a stateful firewall with NAPT (Network Address Port Translation) in a single device, leading to the mistaken belief that these two functions are equivalent.
Address translation can obscure the internal network topology, but it does not authenticate traffic, prevent internal hosts from establishing malicious connections, or replace ingress/egress filtering policies. In fact, static mappings can directly route external traffic to internal services. Security reviews must maintain separate records for NAT rules and firewall rules.
5. CGNAT Expands the Shared Identity Problem
Carrier-grade NAT enables multiple subscribers to share a provider's public IPv4 address, typically using 100.64.0.0/10 shared address space. Consequence:
- The public source IP cannot uniquely identify a subscriber; a timestamp combined with source/destination address, port, and protocol is required to look up the mapping in logs;
- IP-based rate limiting and reputation systems may inadvertently affect a large number of users;
- Inbound hosting and peer-to-peer connections become significantly more difficult;
- Port allocation and logging become concerns for provider capacity and privacy;
- Subscribers may experience double NAT, passing through both home NAT and CGNAT.
6. The Problems Solved by STUN, TURN, and ICE Are Different
- STUN: The client queries a STUN server to discover its server-reflexive address or mapping, which is then used for connectivity checks;
- TURN: When direct candidate connections fail, media or data is relayed through a relay server, resulting in higher cost but improved reachability;
- ICE: Collects host, server-reflexive, and relayed candidates, performs connectivity checks, and selects the optimal candidate pair.
STUN does not mean "once you find your public IP, you can penetrate any NAT": mapping and filtering behaviors, multiple NATs, firewalls, IPv4/IPv6 differences, and network changes all influence the resulting candidate. Production real-time systems require TURN fallback due to concerns such as credential expiration, relay capacity limits, abuse prevention, and consent freshness.
7. IPv6 Does Not Require NAT44 to Address Address Scarcity
The vast global address space of IPv6 enables end-to-end addressing. However, inbound reachability still depends on stateful firewalls or host-level policies. The notion that "no NAT means no security" conflates address translation with packet filtering.
IPv6 prefix translation (NPTv6) and other translation mechanisms may exist in certain architectures, but they do not alter the fundamental truth that "IPv6 does not require port-sharing NAT to address 32-bit address exhaustion." Whether translation is necessary must be evaluated independently based on factors such as multihoming, provider independence, application use of literal addresses, and operational policy.
8. Acceptance Questions
- Distinguish between basic NAT, NAPT, and stateful firewall.
- Why can't the public source IP address uniquely identify a subscriber after CGNAT?
- How does UDP mapping timeout affect long-idle real-time sessions?
- What capabilities do STUN, TURN, and ICE each provide?
- Why does IPv6 still require firewall policies, even though it doesn't need NAT44-style address sharing?
Next lesson: 9.4 Routing Control Plane: RIP, OSPF, and BGP
References:
- RFC 3022: NAT and the Internet's Address Space
- RFC 5389: STUN Protocol
- RFC 5766: ICE: Interactive Connectivity Establishment
- RFC 4443: UDP Hole Punching and NAT Traversal
- IETF IPv6 Firewall Policy Guidelines