NAT — why, how, types (SNAT, DNAT, PAT): Question bank

Before we start, one shared vocabulary reminder so no term below is used unearned:

True or false — justify

Every item is Statement ::: verdict + the reasoning that makes it true or false.

NAT gives you a firewall's protection for free.

False. The inability of outsiders to initiate is a side effect of having no reverse mapping yet — not a policy. NAT inspects no payloads and blocks nothing you started outbound; see Firewalls vs NAT.

Every PAT deployment is also a form of SNAT.

True. PAT rewrites the source IP and the source port, so it does everything SNAT does plus port muxing. PAT is a strict superset of source rewriting.

Every SNAT deployment is also PAT.

False. Plain SNAT can map one private IP to one public IP (1:1) without touching ports. Only when you add port rewriting to share one IP among many do you have PAT.

Two hosts behind the same PAT box can safely use the same internal source port at the same time.

True. PAT hands each flow a distinct translated source port on the public IP, so the outside 4-tuples differ even when the inside ports collide — that is the whole point of PAT.

DNAT is used when your inside laptop opens a website.

False. That is SNAT/PAT: your laptop initiates outbound, so the source is hidden. DNAT rewrites the destination of inbound traffic to expose an internal server.

Private addresses like 192.168.0.10 can appear as the source of a packet on the public internet.

False. RFC 1918 ranges are non-routable; NAT rewrites them to a public IP before the packet leaves. Seeing one on the public internet means something is misconfigured. See RFC 1918 Private Addresses.

If two different homes both use 192.168.0.10, their packets will collide on the internet.

False. Each home's NAT strips the private source and substitutes its own public IP, so the internet only ever sees public, unique addresses — the private numbers never meet.

A single public IP under PAT can support roughly 4 billion simultaneous flows.

False. The source port is 16 bits → about 64000 values per protocol per destination, so the practical limit is tens of thousands, not billions. The 4-billion figure (

2^{32}

) is the IPv4 address space, a different thing.

NAT only rewrites the IP address and never the port.

False. PAT specifically rewrites the source port too; that port rewrite is what makes many-to-one sharing possible.

Turning on IPv6 makes NAT strictly mandatory everywhere.

False. IPv6 has such a huge address space that every device can hold a globally unique address, which reduces the address-conservation reason for NAT. NAT becomes optional rather than required.

Spot the error

Each item quotes a plausible-but-wrong claim; the answer names the exact broken assumption.

"A /8 network has

8

host addresses."

Error: confusing prefix length with host count. /8 fixes the first 8 bits, leaving

32 - 8 = 24

host bits, so

2^{24}

addresses — not

8

. See IPv4 Addressing & Subnetting.

"NAT breaks nothing; browsing always works, so all protocols are fine."

Error: overgeneralizing from HTTP. Protocols that embed IPs/ports inside the payload (FTP active, SIP/VoIP) break, because header-only rewriting leaves stale addresses in the body; they need ALGs or STUN, TURN & NAT Traversal.

"After rewriting the source IP, NAT can forward the packet as-is."

Error: forgotten checksum. Changing an address field invalidates the IP and TCP/UDP checksums; NAT must recompute them or the receiver will discard the packet as corrupt.

"Port forwarding is a kind of SNAT because it involves ports."

Error: wrong direction. Port forwarding is DNAT — it rewrites the destination of inbound packets to reach an internal server. The presence of a port does not make it source-NAT. See Port Forwarding & DMZ.

"To let 30 devices share one public IP you assign each device its own public IP internally."

Error: that's not sharing. Thirty public IPs defeats the goal entirely; PAT lets all 30 share one public IP by distinguishing flows via unique source ports.

"NAT stores a mapping only for the destination, so replies find their way home."

Error: the key is the reverse of what NAT rewrote. For PAT the table maps the translated public 4-tuple back to the original private 4-tuple; the return lookup is keyed on what the outside sees, not on the destination alone. See Ports & TCP-UDP Headers.

Why questions

Why does PAT rewrite the port instead of only the IP?

Because if only the IP changed, two inside hosts using the same internal port would produce identical outside 4-tuples, and replies couldn't be demultiplexed. A unique port makes each flow's tuple unique.

Why are RFC 1918 ranges specifically chosen to be non-routable?

So they can be reused in millions of private networks without collision — public routers deliberately drop them, guaranteeing they never leak or clash on the internet.

Why must NAT keep a translation table rather than a single fixed rule?

Because return traffic must be reversed to the correct inside host/port; a stateful table records each live flow so replies map back to exactly the originator, not a random device.

Why does NAT "hiding" not count as real security?

It offers no payload inspection, no policy against outbound-initiated malware, and DNAT/port-forwarding intentionally punches holes — protection is an accidental byproduct, not enforcement. Contrast in Firewalls vs NAT.

Why does peer-to-peer (P2P) traffic struggle under NAT?

Both peers sit behind NATs with no pre-existing inbound mapping, so neither can initiate to the other's private address; they need hole-punching or a relay via STUN, TURN & NAT Traversal.

Why does a /16 private block (

192.168.0.0/16

) hold

2^{16}

hosts?

The /16 fixes 16 bits, leaving

32 - 16 = 16

host bits, so

2^{16}

addresses. Same rule as /8 and /12.

Edge cases

What happens under PAT when all ~64000 source ports for a given public IP are exhausted?

New outbound flows can't get a unique port and are dropped or stalled until entries free up; this is why very busy NATs need multiple public IPs or shorter idle timeouts.

What happens to a NAT table entry when a flow goes idle for a long time?

NAT ages out idle mappings after a timeout to reclaim ports; if a "silent" long-lived connection has no keep-alives, its entry can be evicted and later packets are then dropped as unmapped.

What if an outside host tries to start a brand-new connection to an inside PAT client?

There is no matching table entry (no inside host initiated it), so NAT has nowhere to send it and drops it — this is the accidental "hiding" effect, and it's why you need explicit DNAT/port-forwarding to accept inbound.

Can NAT translate ICMP (ping), which has no ports?

Yes, but not via ports — NAT uses the ICMP query identifier field as the demultiplexing key instead, playing the role a port would for TCP/UDP.

What if an inside host sends to a destination that is itself a private address (e.g., another LAN)?

NAT should not translate/forward it onto the public internet — private-to-private routing is handled internally; leaking a private destination outward would be non-routable and dropped.

Connections

Parent: NAT topic
IPv4 Addressing & Subnetting — the /8 /12 /16 host-count math
RFC 1918 Private Addresses — why private ranges never collide
Ports & TCP-UDP Headers — the port field that powers PAT
Firewalls vs NAT — the security-vs-side-effect distinction
STUN, TURN & NAT Traversal — fixing P2P under NAT
IPv6 — why abundance reduces NAT's reason to exist
Port Forwarding & DMZ — DNAT in practice