skip to content

On an IPv4 NAT router, why is a destination address rewritten before the routing decision and a source address rewritten after it?

level: middleimportance: should knowfreq 22%

answer

  1. the route lookup reads the destination
  2. egress decides which public address
  3. the rule follows the field, not the direction
  4. replies obey the same order

basics

~20 s

An IPv4 router chooses the next hop from the destination address, so a destination rewrite must happen first or the lookup uses the wrong address. A source rewrite waits until the outgoing interface is known, because that decides which public address to use.

solid answer

~50 s

Forwarding is a **lookup on the destination address**. For destination NAT, a packet to public `203.0.113.10` must become `10.20.5.10` **before** the lookup, or the router routes the public address, which points at itself or back out, instead of the inside server. Source addresses do not steer forwarding, but the **egress interface** decides whether and how to translate: only packets leaving through an outside interface get source NAT, and on a router with two uplinks the public address must belong to the uplink the lookup chose. So source rewriting happens **after** routing. The rule follows the field, not the direction of the session: a reply to a source-NAT session has its *destination* restored before routing, and a reply from a destination-NAT server has its *source* restored after. The RFCs specify which fields change; this ordering is the model implementations follow because of that dependency.

go deeper

for a junior

Remember that routers forward on the destination address, so anything that changes the destination has to happen before the router decides where the packet goes.

for a middle

Walk through both directions of a destination-NAT and a source-NAT session and show that the rule follows the field being changed, not the direction of the session.

for a senior

Use the model when diagnosing: a published service routed back out, inside traffic wrongly translated, or a second uplink using the wrong public address all point at ordering or egress assumptions.

for a principal

With multiple uplinks or translators, the egress decision and the source address must be designed together, since the provider routes replies only to addresses it owns.

## Forwarding reads the destination An IPv4 router decides where to send a packet by looking up its **destination address** in the forwarding table and choosing the most specific matching route, which gives an outgoing interface and a next hop (RFC 1812). The source address plays no part in ordinary forwarding. That single fact fixes where each NAT rewrite must sit relative to the lookup. The NAT RFCs, RFC 2663 and RFC 3022, specify which fields are rewritten in which direction; they do not prescribe a processing pipeline. The ordering below is the logical model that follows from forwarding being destination-based, and translating implementations generally follow it. ## Destination rewrites go first An office edge router publishes inside server `10.20.5.10` on public address `203.0.113.10`. A client at `198.51.100.7` connects. 1. The packet arrives on the outside interface with destination `203.0.113.10`. 2. The translator finds the static mapping and rewrites the destination to `10.20.5.10`. 3. The route lookup on `10.20.5.10` selects the inside interface toward `10.20.0.0/16`. 4. The packet leaves on the inside interface. If the lookup ran before the rewrite, it would match `203.0.113.10`: an address of the router itself, or a route out the uplink. The packet would be delivered to the router or sent back toward the provider, and the later rewrite would come too late. ## Source rewrites go last Now the inside workstation `10.20.4.31` calls out to `198.51.100.7`. 1. The lookup on `198.51.100.7` selects an outside interface, the default route. 2. Because the packet leaves through an outside interface, the translator rewrites its source to a public address of that interface, say `203.0.113.17`. 3. The packet is transmitted. Two reasons put source translation after the lookup: - **Whether to translate depends on the egress.** A packet from `10.20.4.31` to another inside subnet stays inside and must keep its private source. Only after the lookup does the router know which case it has. - **Which address to use depends on the egress.** On a router with a second uplink numbered from `192.0.2.0/24`, a packet leaving through it must take a source from that block, or the second provider would deliver replies elsewhere. The lookup decides the uplink, so it must come first. ## The rule is per field, and replies follow it too Un-translating a reply is just another rewrite, so the same rule applies. | Packet | Field rewritten | Relative to the lookup | Why | |---|---|---|---| | First packet of a source-NAT session, outbound | source | after | egress chooses whether and which public address | | Reply to that session, inbound | destination, public back to private | before | the lookup must find the inside host | | First packet of a destination-NAT session, inbound | destination | before | the lookup must find the inside server | | Server's reply, outbound | source, private back to public | after | forwarding is on the client's address, unaffected | So it is not "inbound first, outbound last". Any change to a destination precedes the lookup; any change to a source follows it. A **Twice NAT** (RFC 2663), which rewrites both fields of one packet, does the destination half before the lookup and the source half after it. ## Consequences worth knowing - Anything evaluated at the lookup sees the **inside** destination of a destination-NAT packet and the **original** source of a source-NAT packet. Policy that depends on addresses has to be written with that in mind; how a given product stages its policy checks is its own design. - Traffic from inside to an address the router publishes on its outside, such as an inside client using `203.0.113.10`, needs both rewrites on one packet; that reflection case has its own rules. - The ordering is about one router's processing. The session entry that records the translation is the same whichever stage created it. ## Mistakes this model catches - **A published server that answers nobody.** If the destination rewrite is effectively applied after forwarding, inbound packets are routed on the public address and never reach the inside server. - **Inside traffic leaving with a public source.** Translating every forwarded packet, instead of only those leaving through an outside interface, gives inside peers a public address they then reply to. - **The wrong address on a second uplink.** A source address taken from the first provider's block on packets sent through the second provider means replies return through the first provider, if at all. - **Thinking in directions instead of fields.** Asking whether a packet is inbound or outbound gives the wrong answer for replies; asking which field changes gives the right one.

  • Where does a Twice NAT apply its two rewrites relative to the route lookup?
    Twice NAT, defined in RFC 2663, changes both the source and the destination of one packet. The destination change happens before the lookup, so the packet is routed toward the address that is valid in the destination realm; the source change happens after, once the egress interface is known. Replies are handled by the same per-field rule.
  • Why must a NAT router leave the source address alone on traffic between two inside subnets?
    Both hosts are in the same address realm, so their private addresses are valid end to end and the replies route directly. Translating the source would hide the real peer, and its replies would come back to the router instead. Because source translation sits after the lookup, the router knows the egress is an inside interface and skips it.

saying these in an interview costs you the question

  • IPv4 routers choose the next hop from the source address, so it must be rewritten first.
  • Inbound packets are always translated before routing and outbound packets always after.
  • A reply to a source-NAT session has its source restored after routing.
  • The NAT RFCs mandate the exact stage in the forwarding pipeline for each rewrite.
  • Source NAT applies to every forwarded packet, whichever interface it leaves on.