NAT and PAT
NAT rewrites IP addresses in flight so many private hosts can share a few public ones. The form everyone actually runs is PAT — port address translation, also called NAT overload or masquerading — which rewrites the source port as well as the address, multiplexing an entire network behind one public IP and keeping the flows apart with a translation table keyed on the connection's 5-tuple.
NAT saved IPv4 and broke end-to-end addressing in the same stroke. It let the internet keep growing past the point IPv4 ran out, but it also means a host behind NAT has no globally reachable address — it can start conversations outward, but nothing can reach in without an explicit forward. Almost every problem with peer-to-peer apps, inbound services, and certain protocols traces back to that one consequence.
Source NAT and Masquerading
The common case is outbound, many-to-one: hosts on 192.168.1.0/24 all leave through a router holding one public address, say 203.0.113.7. As each packet exits, the router rewrites the source address from the private host's to its own public one, and records the mapping so it can reverse it on the reply. This is source NAT; when the public address is the router's own dynamic interface address, it is called masquerading.
The reply comes back addressed to 203.0.113.7, and the router consults its table to learn which inside host it really belongs to, rewrites the destination back to the private address, and forwards it. The inside host never knows its packets were altered. The whole scheme depends on the router seeing both directions of every flow — which is why NAT and asymmetric routing fight each other.
Port Address Translation
One public address is not enough to tell two inside hosts apart if they both talk to the same server on the same port — the replies would be identical. PAT solves this by also rewriting the source port, so each outbound flow gets a unique public port. The translation table is keyed on the full 5-tuple: source IP, source port, destination IP, destination port, and protocol. Two inside hosts hitting 93.184.216.34:443 are distinguished by the different public source ports the router assigns.
# conntrack shows the PAT table: original tuple -> translated tuple conntrack -L # tcp src=192.168.1.10 sport=51200 dst=93.184.216.34 dport=443 # [translated] src=203.0.113.7 sport=61001 <- host A # tcp src=192.168.1.11 sport=51200 dst=93.184.216.34 dport=443 # [translated] src=203.0.113.7 sport=61002 <- host B, same dst # same dst:443, distinguished only by the rewritten source port
Destination NAT and Port Forwarding
Source NAT lets inside hosts out; destination NAT lets outside clients in. You publish a public address and port — say 203.0.113.7:443 — and the router rewrites the destination to an inside host, 192.168.1.20:8443, on the way in. This is what a port forward on a home router does, and what a load balancer does at scale: take traffic for one front-end address and steer it to a back-end that holds a private address.
DNAT is the only way an inbound connection reaches a NATed host, and it is explicit by construction — you forward exactly the ports you choose and nothing else. That is a real security property, but it is a side effect, not the design: NAT hides addresses, it does not inspect or filter traffic the way a firewall does.
Why NAT Breaks Things
Three failure modes recur. First, no inbound reachability — a host behind PAT cannot be connected to from outside without a forward, which is why two peers both behind NAT need a relay or hole-punching to talk directly. Second, hairpinning: an inside host trying to reach its own public address has to have its traffic turned back around by the NAT, and many cheap routers get this wrong, so the service is reachable from the internet but not from the LAN.
Third, protocols that embed IP addresses in their payload — FTP in active mode, SIP for voice — break, because NAT rewrites the headers but not the address buried in the application data. The inside host advertises its private 192.168.x.x in the payload, the far end tries to connect to it, and fails. An application-level gateway (ALG) has to reach into the payload and fix the embedded address, which is fragile and a frequent source of mysterious one-protocol-only outages.
Source NAT rewrites the source address (and, as PAT, the source port) of outbound packets, letting many inside hosts share one public IP. The translation is created by the inside host's first outbound packet, and replies are matched back automatically. Reach for SNAT whenever private hosts need to initiate connections to the internet.
Destination NAT rewrites the destination of inbound packets, steering traffic for a public address and port to an inside host. It must be configured explicitly per forwarded service, because there is no inside-initiated flow to learn the mapping from. A load balancer typically does both — DNAT to pick a back-end, SNAT so the back-end's reply returns through it.
- Treating NAT as a firewall. NAT hides addresses but inspects nothing; once you add a port forward, the exposed service is as reachable as any other, and only an actual firewall policy controls what is allowed in.
- Ignoring NAT-table exhaustion under high connection churn. A single public IP has roughly 64 000 ports per protocol; a host opening thousands of short-lived connections can exhaust the table, and new connections silently fail until entries time out.
- Running address-embedding protocols without an ALG. Active-mode FTP and SIP carry inside IPs in the payload, so without a gateway rewriting them the control channel connects but the data or media channel never establishes.
- Expecting inbound connections to a NATed host to just work. Without an explicit DNAT forward, nothing outside can reach an inside host — peer-to-peer between two NATed endpoints needs a relay or hole-punching, not a direct connect.
- Overlooking hairpin NAT on internal clients. A host on the LAN reaching the service by its public address fails on routers that do not hairpin, producing the baffling "works from the internet, not from the office" symptom.
- Pair every NAT with an explicit firewall policy and never rely on translation alone for security, because a single forward turns the hidden host into a fully exposed one with no other control in front of it.
- Size the public-IP pool or add addresses for workloads with high connection churn, since one IP caps out near 64 000 ports per protocol and table exhaustion shows up as intermittent, hard-to-trace connection failures.
- Prefer protocols that do not embed L3 addresses, and where you must run FTP or SIP behind NAT, enable the matching ALG so the embedded private address gets rewritten in the payload.
- Use destination NAT or a load balancer with an explicit per-service forward to expose inside services, rather than putting the host on a public IP directly, so only the chosen ports are reachable.
- Move public-facing, peer-to-peer, and inbound-heavy workloads to IPv6 where you can, since a globally routable address removes the NAT layer and the whole class of reachability and ALG problems with it.
Knowledge Check
Two inside hosts both open a connection to 93.184.216.34:443 through the same PAT router. How does the router keep the replies straight?
- It rewrites each flow's source port to a unique value, so the two differ in the 5-tuple
- It gives each inside host its own separate public IP address so that their inbound replies can never collide
- It inserts a per-host identifier into the HTTP payload to label each stream
- It changes the destination port for one host so the two no longer match
Why is it a mistake to treat NAT as a security firewall?
- It only hides addresses and inspects nothing, so any port forward exposes the service fully
- It inspects packet payloads, but only against the known attack signatures it happens to ship with by default
- It encrypts outbound traffic, which protects confidentiality but not availability
- It authenticates every inbound connection but cannot rate-limit them
Why does active-mode FTP often break behind NAT without an ALG?
- It carries the client's private IP inside the payload, which NAT rewrites in headers but not in the data
- FTP requires IPv6 end to end, which NAT cannot provide for legacy clients
- Its control channel cannot traverse NAT at all, so the session never even manages to start in the first place
- It opens too many ports at once and immediately exhausts the NAT table
You got correct