In network address translation, what is the difference between source NAT and destination NAT, and what happens to the reply packets in each case?
answer
- who opens the session
- which header field gets replaced
- replies get the mirror-image rewrite
- state created by the first packet
basics
~20 sSource NAT rewrites the source address of outbound packets so inside hosts appear as a public address; destination NAT rewrites the destination of inbound packets so a public address reaches an inside server. Replies get the mirror-image rewrite from the stored mapping.
solid answer
~50 sBoth apply one trick to opposite ends of a session, and the direction is set by **who opens it**. With source NAT, inside host `10.20.4.31` opens a connection outward and the edge router replaces the **source** address with a public one such as `203.0.113.17`; replies arrive addressed to `203.0.113.17`, and the router rewrites their **destination** back to `10.20.4.31`. With destination NAT, an outside client connects to public address `203.0.113.10` and the router replaces the **destination** with inside server `10.20.5.10`; the server's replies leave with source `10.20.5.10`, and the router rewrites their **source** back to `203.0.113.10`. The first packet creates a translation entry, and every later packet of the session, in either direction, is matched against it. The RFCs do not use the SNAT/DNAT labels: RFC 3022 calls the outbound case traditional NAT and admits inbound sessions through static mappings.
go deeper
Recall the two directions: source NAT changes the sender's address on the way out, destination NAT changes the receiver's address on the way in, and replies get the opposite field rewritten.
Walk through the table entry: what the first packet creates, how a reply is matched by its reversed tuple, and why an inbound session needs a mapping that exists before its first packet.
Show where the model leaks in production: destination NAT leaves the client address visible to the server, checksums and quoted ICMP packets must be fixed, and payload-embedded addresses need a gateway.
Frame translation as state in the network: every session depends on the translator's table, which shapes redundancy, logging and attribution choices for any edge design.
## Two directions of one mechanism **Network address translation (NAT)** rewrites addresses in IPv4 headers as packets cross the border between two **address realms**, typically an inside network numbered from the RFC 1918 private ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) and the public internet. RFC 2663 defines the vocabulary and RFC 3022 describes **traditional NAT**. The industry labels **source NAT** (SNAT) and **destination NAT** (DNAT) do not appear in those documents; they name which address of the *first packet* the translator replaces. | | Source NAT | Destination NAT | |---|---|---| | Who opens the session | an inside host | an outside client | | Field rewritten on the first packet | source address | destination address | | Field rewritten on replies | destination address | source address | | What the far end sees | a public address instead of the private one | the public address it dialled, never the private one | | Typical use | letting private hosts reach the internet | publishing an inside server on a public address | | How the binding exists | created dynamically by the first outbound packet, or fixed by a static mapping | must exist before the first inbound packet arrives, so it is configured | The last row is the asymmetry that matters in practice. An outbound session can create its own binding, because the translator sees the inside host's packet first. An inbound packet arrives at a public address, and the translator can only deliver it if a mapping already says which inside host owns that address. RFC 3022 describes traditional NAT as outbound by design, with inbound sessions allowed "on an exceptional basis using static address maps for pre-selected hosts". ## A trace at an office edge router Take an office whose inside network is `10.20.0.0/16`, an edge router with public addresses in `203.0.113.0/24` (a documentation block from RFC 5737), and an outside party at `198.51.100.7`. Source NAT, an inside workstation calling out: 1. `10.20.4.31` sends a TCP SYN to `198.51.100.7`. 2. The router binds `10.20.4.31` to `203.0.113.17`, records the session, and forwards the SYN with source `203.0.113.17`. 3. The SYN-ACK comes back to `203.0.113.17`. The router finds the session and rewrites the **destination** to `10.20.4.31`. Destination NAT, an outside client calling in: 1. `198.51.100.7` sends a SYN to `203.0.113.10`. 2. A configured mapping says `203.0.113.10` belongs to `10.20.5.10`; the router records the session and forwards the SYN with destination `10.20.5.10`. The source stays `198.51.100.7`, so the server sees the real client address. 3. The server's SYN-ACK leaves with source `10.20.5.10`; the router rewrites the **source** to `203.0.113.10`, the address the client expects to hear from. In both traces only one address of each packet changes, and which one alternates with direction. RFC 2663 names the case where both change **Twice NAT**. ## The table that un-translates replies What makes replies work is state, usually called the **translation table** or **connection-tracking table**: - RFC 2663 section 2.3 identifies a TCP or UDP session by source address, source port, target address and target port; an ICMP query session by source address, query identifier and target address. - The **first packet** of a session creates the entry; RFC 2663 recognises a TCP start by SYN set and ACK clear, and treats the first UDP packet with an unseen tuple as a new session. - A reply is matched by its **reversed** tuple, and the stored entry says which address to put back. - An inbound packet that matches no entry and no static mapping cannot be translated, because nothing says which inside host it is for. - Entries end when the session closes or after an idle timeout; RFC 4787 and RFC 5382 set floors on those timers. Port rewriting (NAPT, where many hosts share one public address by translating ports as well) builds on the same table but is a separate subject. ## What else the rewrite touches Changing an address invalidates the IPv4 header checksum and the TCP or UDP checksum (unless a UDP sender sent none), whose pseudo-header includes both addresses, so the translator adjusts them too (RFC 3022 section 4.1). ICMP error messages quote the offending packet, and RFC 5508 requires the translator to un-translate that quoted copy. Addresses written inside application payloads are invisible to this mechanism; protocols that carry them need an application-level gateway. ## Common confusions - Replies do not need a reverse rule: the session entry handles both directions. - Destination NAT alone does not hide the client; the inside server sees the client's real source address. - Dynamic source NAT does not block inbound traffic by policy; an unsolicited inbound packet simply has no mapping to follow.
- Can one NAT rewrite both the source and the destination address of the same packet?Yes. RFC 2663 calls it **Twice NAT**. It is needed when the inside and outside address spaces overlap, for example when a site numbered itself with addresses that belong to someone else: the translator gives the outside host a different address inside and the inside host a different address outside, rewriting both fields on every packet of the session.
- Why does destination NAT need configuration in advance when source NAT can work dynamically?A source NAT binding is created by the inside host's first outbound packet, which the translator sees before anything else. An inbound first packet arrives addressed to a public address, so the translator can only forward it if a mapping already names the inside host that owns it. RFC 3022 therefore admits inbound sessions only through static mappings for pre-selected hosts.
An office switchboard: outgoing calls show the main number instead of the desk extension (source NAT), calls to a published number are put through to one desk (destination NAT), and the operator's log of who rang whom lets each callback reach the right desk without anyone writing a separate rule for it.
saying these in an interview costs you the question
- Reply packets need their own NAT rule configured in the opposite direction.
- Destination NAT also hides the client, so the inside server sees the router's address.
- After source NAT, the remote server still sees the inside host's private address in the IP header.
- NAT changes only the address field; the checksums stay valid without adjustment.
- Source NAT and destination NAT are just two names for the same rewrite.