In Linux netfilter, what is the difference between SNAT, MASQUERADE and DNAT? At which hook must each be applied, and when is MASQUERADE the better choice than plain SNAT?

## Two directions, two hooks Network address translation on Linux comes in exactly two flavours, distinguished by which end of the packet is rewritten. **Destination NAT (DNAT)** rewrites the destination address and optionally the port. Its use case is publishing something: traffic arrives at an address the outside world can reach, and you redirect it to a machine or port that the outside world cannot. It must be applied in `PREROUTING`, because the routing decision runs immediately afterwards and has to see the new destination in order to choose the right interface and next hop. For traffic generated on the host itself there is an equivalent chain at `OUTPUT`; because that path has already been routed, applying a DNAT there causes the kernel to redo the routing lookup. **Source NAT (SNAT)** rewrites the source address and optionally the port. Its use case is hiding: many hosts behind one public address, or making traffic appear to originate from a specific address. It must be applied in `POSTROUTING`, because only after routing does the kernel know which interface the packet will leave by — and that usually determines which source address makes sense. `REDIRECT` is the degenerate case of DNAT: rewrite the destination to an address of the receiving machine itself, which is how transparent proxies capture traffic without naming the local address explicitly. ## MASQUERADE as a special SNAT `MASQUERADE` performs source NAT, but instead of you supplying the address, the kernel looks up the primary address configured on the outgoing interface at the moment the flow is translated. Two practical consequences follow. First, it is the correct tool when the address is not stable — a DHCP-assigned WAN interface, a PPP link, a laptop moving between networks. A static SNAT rule naming an address that has since changed silently produces packets nobody will route back. Second, it is slightly more expensive: the address lookup happens per new flow rather than being baked into the rule. It also has a deliberate side effect — when the interface goes down, connection-tracking entries associated with it are dropped, on the reasoning that after the address changes those flows are dead anyway and keeping them would let a stale mapping survive. With a static address on a busy gateway, plain SNAT is the better choice. ## The reverse direction is automatic The single most important thing to say in an interview here is that **you never write a rule for the return traffic**. When the first packet of a flow is translated, the kernel records both the original tuple and the translated tuple in the connection-tracking entry. Reply packets are matched against the reply tuple and un-translated automatically, and every subsequent packet in the forward direction is translated straight from the entry without re-entering any nat chain. This is also why the nat table is only consulted for packets in the NEW state. ## Port translation and collisions When many internal hosts share one external address, source ports must be rewritten too, otherwise two flows could collapse onto the same tuple. The kernel's NAT engine picks a free source port, preferring to keep the original where possible. Because port selection was historically predictable, iptables and nftables both offer a fully-random port selection option for cases where predictability is a security concern. The port space is the real scaling limit of a NAT gateway: one external address gives roughly 64k source ports *per destination tuple*, and a busy gateway with a single address will exhaust ports long before it exhausts bandwidth. The fix is more external addresses in the SNAT pool. ## Common failure shapes - **DNAT works inbound but replies never arrive.** The reply must come back through the same NAT box; if the internal server has a different route out, the client receives a packet from an address it never talked to and drops it. - **A NAT rule appears to be ignored.** The flow is already tracked, so its packets bypass the nat table entirely — new rules only take effect for new flows. - **MASQUERADE on a static-address gateway.** Works, but adds a per-flow lookup and unnecessary tracking-entry churn on interface events. - **Forgetting that translation is per flow, not per packet.** Rate limits, marks or logging placed in the nat table only ever see the first packet of each flow.