9.3 NAT, NAPT, and Traversal Boundaries
When devices share one public IPv4 address, the gateway must remember where replies belong. 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
This diagram shows two connections to the same remote service:
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:62002Both internal endpoints use port 51000, but distinct external ports separate their replies. A reply addressed to 203.0.113.5:62001 is rewritten for 192.168.1.10:51000. The translator updates affected IPv4/TCP/UDP checksums and quoted original packets in ICMP errors. An IPv4 UDP checksum of zero means checksumming is disabled; the translator preserves that zero instead of adjusting it. RFC 3022 §4.1
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 packets from any remote endpoint or restrict them to addresses or ports that the internal endpoint previously contacted. A single label such as cone or symmetric NAT does not describe both mapping and filtering behavior. RFC 4787
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 reclaims idle state using 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.
For example, configure a lab gateway with a 120-second UDP idle timeout. If an application stays silent for 180 seconds, replies to the old external port may be dropped. Sending outbound traffic again may allocate a different port. The 120-second value is an example configuration, not a universal timeout.
Long-lived applications must account for NAT, firewall, and load-balancer idle timeouts. They should use protocol-appropriate keepalive mechanisms and reconnect, rather than relying on frequent, meaningless packets to maintain mappings. Leave timing margin for jitter and consider mobile power costs. If reconnecting after idle periods is acceptable, frequent keepalives may be unnecessary.
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. Inspect active mappings, allocation failures, per-destination port pressure, and timeout distributions. Ten thousand available ports do not directly translate into ten thousand users.
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 and firewalls perform different operations
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. Effects:
- Public source IP alone cannot identify a subscriber; external source port, protocol, time, and the provider’s mapping records are also needed;
- 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.
Mapping records need to associate external source address, port, protocol, and time with an internal subscriber identifier. Destination addresses and ports are not required for every attribution lookup; RFC 6888 recommends avoiding their collection at CGNs except for administrative needs. RFC 6888 §4
6. STUN, TURN, and ICE each solve part of traversal
- STUN observes the mapping visible to a server and supplies request/response mechanisms used in ICE connectivity checks.
- TURN provides relay addresses and forwards data when direct connectivity fails or policy requires relaying, consuming relay bandwidth and capacity.
- ICE gathers host, server-reflexive, and relayed candidates, checks candidate pairs, and chooses a path using priorities and nomination.
ICE selects a usable path; it does not continuously measure the globally lowest latency. Connectivity checks are not all directed to a public STUN server: candidate endpoints check each other directly. Real-time systems aiming to cover restricted networks usually need TURN fallback, with credential expiry, relay capacity, abuse prevention, and consent freshness handled explicitly.
One STUN query reveals only the external endpoint that one server observed at that time. A different destination, multiple NATs, network changes, or filtering can change the result. Learning the public address does not make the network open the door. RFC 8445
7. IPv6 addressing does not depend on NAT44-style sharing
The 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.
Some architectures use IPv6 prefix translation (NPTv6) or other translation mechanisms. IPv6 does not need port-sharing NAT to work around IPv4 address exhaustion. Evaluate translation separately against multihoming, provider independence, literal-address use, and operational policy.
8. Acceptance Questions
- What do basic NAT, NAPT, and stateful firewalls each change?
- Why can the internal endpoints in the diagram use the same port, and why must their external mappings remain distinguishable?
- What can happen to replies sent to an old UDP port after the mapping expires?
- Why is public source IP insufficient to identify a CGNAT subscriber?
- What do STUN, TURN, and ICE each provide?
- Why does IPv6 still need firewall policy without NAT44-style port sharing?
Next lesson: 9.4 The Routing Control Plane: RIP, OSPF and BGP