Every Palo Alto NAT type, and the ASA construct it maps from

"NAT" on PAN-OS is several distinct types, each with its own behavior and its own Cisco ASA equivalent. The full reference, with diagrams, source, destination, combined, U-turn, bidirectional, and no-NAT.

"NAT" on a Palo Alto firewall isn't one thing. There are several distinct translation types, each with a specific job, its own matching behavior, and, if you're coming from a Cisco ASA, a specific ASA construct it corresponds to. Get them straight and your design is clean. Blur them together and you'll build a firewall that exhausts port pools, breaks return traffic, or silently drops the sessions you cared about. This is the full reference, with the ASA mapping alongside each type.

First principle: NAT policy runs on the original packet

Before the types, the model, because every one of them depends on it. PAN-OS matches NAT policy against the original, pre-translation packet, and it does so at a specific point in the packet's journey through the firewall.

NAT is matched on the original packet (step 3) and evaluated before security policy, but the actual translation isn't applied until step 5.

Two consequences fall out of this order and account for most NAT confusion:

• The destination zone for both NAT and security policy comes from a forwarding lookup on the original destination address (step 2).
• Security policy is evaluated using the pre-NAT address but the post-NAT zone. The rule matches the original IP, but the destination zone is where the translated address routes. This single asymmetry is the source of most "the rule looks right but traffic drops" tickets.

Source NAT

Source NAT rewrites the source address of a session. It's what lets private hosts reach the internet, and PAN-OS offers three flavors that trade off address economy against session fidelity.

Dynamic IP and Port (DIPP)

The workhorse. DIPP maps many internal hosts onto one (or a few) translated addresses by multiplexing on port. This is PAT / "overload" in Cisco terms. Each internal session gets the shared public address and a unique source port, so thousands of hosts can share a single IP.

DIPP: many internal sources collapse onto one public address, distinguished by translated source port.

The translated address can be the egress interface's address (interface address) or an explicit IP/range. Port capacity is finite (roughly 64k per translated IP) and PAN-OS can oversubscribe (reusing the same port toward different destinations, at a configurable ratio up to 8x). On high-traffic edges, DIPP port exhaustion is a real failure mode: when the pool is spent, new sessions fail. Size the translated pool and watch the oversubscription ratio.

object network INSIDE_NET
 subnet 10.1.1.0 255.255.255.0
 nat (inside,outside) dynamic interface

set rulebase nat rules Outbound \
 from trust to untrust source 10.1.1.0/24 \
 source-translation dynamic-ip-and-port \
 interface-address interface ethernet1/1

The oversubscription ratio is a PAN-OS-only tuning knob, no ASA analogue.

Dynamic IP (DIP)

DIP is a one-to-one dynamic mapping with no port translation: each internal host draws a distinct translated address from a pool for the life of its sessions. Because ports are untouched, it suits protocols that break under PAT. The catch is arithmetic: the pool must hold at least as many addresses as there are concurrent internal hosts, or hosts beyond the pool size can't translate.

object network NAT_POOL
 range 203.0.113.20 203.0.113.40
object network INSIDE_NET
 subnet 10.1.1.0 255.255.255.0
 nat (inside,outside) dynamic NAT_POOL

set rulebase nat rules Outbound-DIP \
 from trust to untrust source 10.1.1.0/24 \
 source-translation dynamic-ip \
 translated-address 203.0.113.20-203.0.113.40

No port translation; the pool must be at least as large as the concurrent host count.

Static IP

A fixed, persistent one-to-one mapping. A given internal address always translates to the same external address, ports preserved. It can operate on whole subnets, translating the network portion while preserving host bits (a static subnet-to-subnet mapping). Static source NAT also carries an important option (bidirectional) covered below.

object network HOST_A
 host 10.1.1.50
 nat (inside,outside) static 203.0.113.50

set rulebase nat rules Static-A \
 from trust to untrust source 10.1.1.50 \
 source-translation static-ip \
 translated-address 203.0.113.50

ASA statics were inherently bidirectional; in PAN-OS that reverse is an explicit option (see below), don't assume it.

Destination NAT

Destination NAT rewrites the destination address, the mechanism for publishing an internal service on a public address.

Static destination NAT (and port forwarding)

Traffic to a public address is rewritten to a private one. Optionally the port is translated too (port forwarding) so public TCP/8080 can land on internal TCP/80. Recall the zone subtlety from the packet-flow model: the security rule that permits this traffic uses the public (pre-NAT) address but the internal (post-NAT) zone.

Static destination NAT: the public address is rewritten to the internal server; the security rule still matches the public address.

object network WEB_SRV
 host 10.1.1.100
 nat (inside,outside) static interface \
   service tcp 8080 80
! permits to the real IP (8.3+)
access-list OUT permit tcp any object WEB_SRV eq www

set rulebase nat rules Web-In from untrust to untrust \
 destination 203.0.113.10 service tcp-8080 \
 destination-translation translated-address 10.1.1.100 \
 translated-port 80
# security: pre-NAT addr, post-NAT zone
set rulebase security rules Allow-Web from untrust to trust \
 destination 203.0.113.10 application web-browsing

Note the security rule matches the public (pre-NAT) address but the internal (post-NAT) zone.

Dynamic destination NAT

Newer than the rest, dynamic destination NAT translates the destination to an address drawn from a set (an address group or a dynamic address object) and can distribute sessions across several servers using methods like round-robin, IP hash, or least-sessions. It's crude compared to a real load balancer, but useful for basic distribution or for pointing at a membership that changes dynamically.

Combined source + destination NAT

A single PAN-OS NAT rule can translate both source and destination at once, rewrite where a packet is going and where it appears to come from in one pass. This is common for inbound flows where you also want to force symmetric return through the firewall, and for the U-turn case below.

nat (inside,outside) source dynamic INSIDE PAT_IP \
  destination static DMZ_PUB DMZ_REAL

set rulebase nat rules Both from trust to dmz \
 source 10.1.1.0/24 destination 203.0.113.60 \
 source-translation dynamic-ip-and-port interface-address \
   interface ethernet1/2 \
 destination-translation translated-address 10.2.2.60

These twice-NAT rules are the ones whose ordering you must preserve most carefully when flattening into the single PAN-OS list.

U-turn (hairpin) NAT

The case that confuses everyone: an internal client reaching an internal server by its public address. The client resolves the public IP, sends traffic toward the firewall, and the firewall has to "u-turn" it back inside, translating the destination to the private server and, crucially, the source as well, so the server's replies return through the firewall instead of going direct and breaking the session.

U-turn NAT: traffic goes up to the firewall addressed to the public IP and comes back down to the internal server. Source NAT is applied too, so return traffic stays symmetric.

same-security-traffic permit intra-interface
object network WEB_SRV
 host 10.1.1.100
 nat (inside,inside) static interface

set rulebase nat rules U-Turn from trust to untrust \
 source 10.1.1.0/24 destination 203.0.113.10 \
 source-translation dynamic-ip-and-port interface-address \
   interface ethernet1/2 \
 destination-translation translated-address 10.1.1.100

No intra-interface toggle in PAN-OS, the zone model handles it, but the source-NAT half is just as mandatory as it was on ASA.

Bidirectional static NAT

On a static source NAT rule, the bidirectional option tells PAN-OS to automatically create the implied reverse destination-NAT, so the mapping works for sessions initiated from either side without you writing a second rule. It's a convenience, and a trap: it silently generates policy. Enable it only when you actually want the internal host reachable from outside, and remember that an inbound security rule is still required, bidirectional NAT creates the translation, not the permission.

No-NAT rules

Sometimes the correct translation is none, traffic that must bypass a broader NAT rule, classically site-to-site VPN traffic that has to keep its real addresses. In PAN-OS you write an explicit NAT rule with no translation, placed above the broader rule it exempts, since NAT is first-match top-down.

nat (inside,outside) source static LOCAL LOCAL \
  destination static REMOTE REMOTE \
  no-proxy-arp route-lookup

set rulebase nat rules No-NAT-VPN from trust to untrust \
 source 10.1.1.0/24 destination 10.99.0.0/16 \
 source-translation none
# must sit ABOVE the general outbound DIPP rule

If a no-NAT rule lands below the general PAT rule, VPN traffic gets translated and the tunnel breaks.

Getting it right on a migration

Pulling it together, the rules that keep a converted NAT policy faithful:

• Preserve ordering. ASA evaluates manual NAT, then object NAT, then after-object manual NAT. PAN-OS has one first-match list. No-NAT and twice-NAT rules must land above the general DIPP rule or they never match.
• Re-add the bidirectional half. Every ASA static implied a reverse; in PAN-OS that's an explicit option or a separate destination-NAT rule. This is the most common silent breakage.
• Mind the security rule, not just the NAT rule. Inbound rules match the pre-NAT (public) address and the post-NAT (internal) zone. A perfect NAT rule with the wrong security-rule zone still drops the traffic.
• Watch DIPP capacity. A migration that consolidates several ASA PAT pools onto one PAN-OS address can quietly walk into port exhaustion. Check the math and the oversubscription ratio.
• Don't carry no-NAT exemptions to the bottom. VPN and other identity-NAT flows belong near the top of the list.

None of the PAN-OS NAT types is complicated on its own. The trouble is always in the seams, the evaluation order, the reverse rule that used to be automatic, the security rule reaching for the wrong zone. Know which type maps to which ASA construct, respect the first-match ordering, and NAT stops being the part of the migration that pages you at 2 a.m.

Written by Roman Dmytriv, network security engineer (CISSP), two decades securing and modernizing enterprise networks. More writing at blog.dmytriv.com, and I'm on LinkedIn.