What is the difference between NAT, PAT, static NAT and DNAT? They describe different aspects of translation, not four mutually exclusive features: NAT is the umbrella, PAT includes transport-port mapping, static NAT fixes an address mapping, and DNAT changes a packet's destination.[1][2][3]
Short answer: Basic NAT translates IP addresses; PAT (called NAPT in RFC 3022) lets multiple internal endpoints share an external address using transport identifiers.[1] Static one-to-one NAT describes how the address mapping is assigned, while SNAT and DNAT describe whether the source or destination is rewritten.[2][3]
NAT vs PAT vs static NAT vs DNAT
This guide focuses on ordinary IPv4 TCP/UDP examples. Separate three questions: what is translated, how is the mapping assigned, and which side of the packet changes?[1][2][3]
| Term | What it describes | Typical example | Interview distinction |
|---|---|---|---|
| Basic NAT | IP address translation without TCP/UDP port translation | One internal address mapped to one external address | Does not by itself provide many-to-one port multiplexing.[1] |
| PAT / NAPT | Address and transport-identifier translation | Many clients sharing one external IPv4 address | Uses address/port mappings to distinguish sessions.[1] |
| Static one-to-one NAT | A fixed address binding | A server always mapped to the same external address | Static describes assignment, not packet direction.[2] |
| Dynamic basic NAT | Address binding allocated from a pool | An active host receives an available external address | The available pool limits simultaneous address bindings.[1][2] |
| SNAT | Source translation | An outbound client uses the gateway's external address | Source address changes in that packet direction.[3] |
| DNAT | Destination translation | An incoming connection is redirected to an internal server | May be used for publishing a service.[3] |
A static address mapping can therefore translate the source on an outbound packet and the destination on the corresponding inbound packet.[1][2] Calling it static does not mean “destination NAT only.”[1][2]
Packet flow: two clients sharing one address with PAT
The following is an original hypothetical example, not a packet capture or executed lab. The external-side addresses are documentation placeholders; do not deploy them as real Internet addresses.
Assume two clients open TCP connections to the same HTTPS destination, both using local source port 51000:
Before translation:
Client A: 10.20.0.10:51000 -> 203.0.113.80:443
Client B: 10.20.0.11:51000 -> 203.0.113.80:443
After translation (one possible allocation):
Client A: 198.51.100.10:40001 -> 203.0.113.80:443
Client B: 198.51.100.10:40002 -> 203.0.113.80:443
Replies on the external side:
203.0.113.80:443 -> 198.51.100.10:40001
203.0.113.80:443 -> 198.51.100.10:40002
After reverse translation:
203.0.113.80:443 -> 10.20.0.10:51000
203.0.113.80:443 -> 10.20.0.11:51000
The external address is shared, but the translated TCP source ports distinguish these two connections to the same destination.[1] The displayed ports are illustrative allocations, not a claim about any product's allocation algorithm.
The translator retains the mapping needed to turn returning traffic back into the correct internal destination.[1] For traditional stateful NAT, the two directions must encounter the relevant translation state; an independent gateway without that state is not an interchangeable return path.[1]
Do not memorize “PAT always changes the port number.” Think in terms of an address/port binding instead: RFC 3022 defines translation of endpoint tuples, not a requirement that the resulting port number differ from the original on every connection.[1]
Packet flow: publishing a server with DNAT
Now consider a separate hypothetical service: an external client connects to 198.51.100.20:443, and the translator forwards that connection to 10.20.10.20:443. This is a destination-translation use case, like the incoming web-service redirection documented by nftables.[3]
Incoming packet before DNAT:
203.0.113.50:52000 -> 198.51.100.20:443
Incoming packet after DNAT:
203.0.113.50:52000 -> 10.20.10.20:443
Server reply before reverse translation:
10.20.10.20:443 -> 203.0.113.50:52000
Reply after reverse translation:
198.51.100.20:443 -> 203.0.113.50:52000
Assume no additional source translation and a stateful mapping with a valid return path. In this example the server sees the original client source address, while the external client sees replies from the published address.[1][3]
Notice the distinction: the connection was introduced as DNAT, but the reverse packet has its source restored to the published address.[1][3] Describing a rule's forward direction is not the same as describing every packet in both directions.[2]
A full static one-to-one address mapping is broader than publishing one TCP service through a fixed port mapping: RFC 3022 separately describes static host mappings and inbound access using service-port mappings.[1] Ask the interviewer whether “static NAT” means an entire address binding or a specific static port forward.
A practical troubleshooting checklist
Use this as a proposed investigation order, not as a universal vendor packet-processing pipeline. Check product documentation before deciding whether a particular policy field refers to the original or translated address.
| Check | What to record | What it helps isolate |
|---|---|---|
| Original flow | Protocol, source IP/port, destination IP/port | Whether you are testing the intended service |
| Translation match | Selected rule and its counters | Wrong match criteria or an earlier competing rule |
| Actual binding | Original and translated endpoint tuples | Whether the intended mapping was created |
| Routing | Forward route and server return path | Delivery or return-path failure |
| Security policy | Relevant allow/deny decision and logs | Authorization independently of translation |
| Endpoint | Listener, local firewall and response capture | A server-side failure mistaken for NAT failure |
| Resources | Available address/port allocations and session state | Pool exhaustion or state-related failure |
For a controlled test, capture one new connection on both sides of the translator and write its endpoint tuples next to each other. Then follow the reply in reverse. Avoid changing routing, security policy and translation simultaneously: change one variable and retest.
For a Linux/nftables lab, these are read-only inspection examples; they were not executed against a router for this article:
sudo nft list ruleset
sudo conntrack -L -p tcp
The second command requires the conntrack userspace tool and can produce a large listing. Filter or narrow collection appropriately in your own environment, and do not paste production session tables into public troubleshooting threads.
With nftables stateful NAT, the first packet establishes the NAT binding; later packets use that binding rather than repeating NAT rule lookup.[3] Therefore, when evaluating a rule edit, test with a genuinely new connection and inspect its state rather than assuming an existing session will demonstrate the new rule.[3] Do not flush production connection state just to make a test easier.
For high-availability designs, verify state handling explicitly: RFC 3022 warns that rerouted sessions can fail after a NAT-router switchover unless the necessary configuration and state are shared.[1]
Common interview pitfalls
- Treating NAT and PAT as unrelated alternatives. PAT/NAPT is a form of address-and-transport translation within the broader NAT discussion.[1]
- Confusing dynamic NAT with PAT. Dynamic basic NAT can allocate whole addresses from a pool without port multiplexing.[1][2]
- Calling every DNAT rule a one-to-one NAT. A service-specific destination translation is not necessarily a full address mapping.[1][3]
- Forgetting the reply. A convincing explanation shows both the forward translation and its reverse.[1]
- Assuming a rule match proves end-to-end success. As an operational rule, verify translation, routing, policy and the endpoint separately.
- Assuming static mapping means stateless processing. nftables documents both stateful NAT and a separate stateless one-to-one approach; fixed mapping and connection tracking are different questions.[3]
A concise interview answer
NAT is the general translation mechanism. Basic NAT changes IP addresses, while PAT, or NAPT, also maps transport identifiers so multiple clients can share an external address.[1]
Static NAT describes a fixed mapping; dynamic basic NAT allocates an address binding when needed.[2]
SNAT and DNAT describe which packet address changes. An incoming connection can be destination-translated to a server, and the reply undergoes reverse translation so the client sees the published endpoint.[1][3]
When troubleshooting, I draw the original and translated tuples in both directions, inspect the mapping, and verify routing, policy and the server response independently.
Related reading
- Palo Alto NAT troubleshooting: why the rule matches but traffic still fails — apply the packet-flow method to a product-specific investigation.
- Palo Alto firewall HA failover test plan — validate continuity rather than assuming a standby device preserves sessions.
- Administrative distance vs metric vs longest prefix match — keep translation problems separate from route selection.
Summary
NAT is the umbrella, PAT adds transport mapping, static describes a fixed binding, and DNAT identifies a destination rewrite. These terms overlap because they classify different aspects of translation.[1][2][3]
Preparing for a network engineering interview? Draw one outbound PAT connection and one inbound DNAT connection, then explain every address and port on the return path without looking at your notes.
Post a Comment