When you write the firewall rule that permits a DNAT'd inbound connection on a Palo Alto, which address and which zone do you reference for the destination — the public (pre-NAT) one or the internal (post-NAT) one?
Reference the pre-NAT destination address (the public firewall IP the client actually sent to) but the post-NAT destination zone (the zone where the server physically lives, e.g. DMZ). This split trips up almost everyone: address = before translation, zone = after translation.
The three rules for DNAT firewall rules (Palo Alto):
| # | Rule | Why |
|---|---|---|
| 1 | Write the security rule from the perspective of the incoming packet from outside | NAT and security policy are separate stages; the FW rule still sees the original packet's fields for addressing |
| 2 | The destination address = the IP in the original packet, before NAT translation (the public firewall interface IP) | When the FW evaluates security policy, it hasn't rewritten the destination IP yet |
| 3 | The destination zone = the zone where the server physically sits, after NAT (e.g. DMZ) | Zone assignment is decided by a route lookup against the translated destination, so the FW already knows the real egress zone |
The mental model — why the asymmetry:
Palo Alto evaluates NAT and security policy in a specific order. The destination zone is computed using the post-NAT address (the firewall does a route lookup to figure out where the translated packet will exit), but the security rule is matched against the original, pre-NAT destination address. So you get: original IP, final zone.
Concrete example (publishing the DMZ web server):
External client → sends to 199.0.0.10 (firewall public IP) [pre-NAT dest]
DNAT rewrites destination → 10.0.0.10 (web server in DMZ) [post-NAT dest]
Firewall rule to allow it:
Source Zone: Outside
Source Address: any
Destination Zone: DMZ ← post-NAT (where server lives)
Destination Addr: 199.0.0.10 ← pre-NAT (public firewall IP)
Service: tcp/80
Why this matters: Get it wrong (e.g. put the internal IP as the destination address) and the rule silently never matches — the connection is denied even though DNAT itself is configured correctly. This is one of the most common "DNAT doesn't work" support cases.
Tip: Remember it as "address before, zone after." The packet is matched on what the client sent (public IP), but routed/zoned by where it's going (internal server's zone).
Go deeper:
Destination NAT example — one-to-one mapping (Palo Alto PAN-OS) — the authoritative doc: a worked example confirming "the addresses used in destination NAT rules always refer to the original IP address in the packet" (i.e. pre-NAT address), with the matching security rule alongside.