Palo Alto NAT Policy Rules: Source, Destination and DIPP

NAT on PAN-OS is a separate policy table from security policy, evaluated before it, and
it matches on source zone, destination zone, addresses and service — the same first-match-wins
logic. Two failure modes account for most broken rules: a NAT rule whose translated packet
sends return traffic out of an interface the firewall does not own, and a missing proxy-ARP or
return route for the public address. This guide covers source NAT (including DIPP), destination
NAT, U-turn NAT for internal clients reaching an internal server via its public address, and
the verification steps that prove the translation is happening.

How NAT Policy Is Structured

Every NAT rule has three parts:

• Original Packet — ingress zone, egress zone, source/destination address,
  service, and optionally the inbound interface
• Translated Packet — Source Translation and/or Destination Translation
• Binding — for active/active HA, which device performs the translation

The zone pair in the Original Packet tab is both the ingress and egress zone of the packet
before translation. Getting the destination zone wrong (using the internal server
zone instead of the untrust zone) is the classic mistake that leaves a rule permanently
unmatched.

Because NAT is applied before the security policy lookup for the translated flow, the
security rule must permit the translated addresses. This is the single most
misunderstood interaction in PAN-OS: you need both a NAT rule and a security rule, and they
must describe the same traffic from different points of view.

Source NAT: Outbound Internet Access (DIPP)

Dynamic IP and Port is the right choice for internal users reaching the internet: many
inside addresses share one public address, distinguished by source port.

Policies > NAT > Add
   Original Packet
     Source Zone:        trust
     Destination Zone:   untrust
     Destination Address: any
   Translated Packet
     Source Translation: Dynamic IP And Port
     Translated Address: 203.0.113.10
     (optional) Translated Service: none

# Equivalent values:
#   Translation Type: Dynamic IP And Port (DIPP)
#   Address Type:     Interface Address  -- or Translated Address (pool / single IP)

Using Interface Address instead of an explicit IP is convenient when the WAN address
changes, but it silently couples the NAT rule to whatever address the interface holds. In
multi-ISP designs, anchor your rules on named address objects.

Oversubscription is the ratio of inside hosts to translated ports. Raise it only when you
have hit the default limit and have checked the dataplane NAT memory statistics first — the
counters are the only reliable way to know whether you are actually running out of ports.

Destination NAT: Publishing an Internal Server

Inbound access to an internal web server uses destination translation. Note that the
Original Packet destination zone is untrust and the destination address is the
public address — but the security policy that permits it must reference the
post-NAT (internal) destination, or use a NAT-aware rule that allows the untrust zone with the
public address depending on your rule design.

Policies > NAT > Add
   Original Packet
     Source Zone:         untrust
     Destination Zone:    untrust
     Destination Address: 203.0.113.20        (public VIP)
     Service:             tcp-443
   Translated Packet
     Destination Translation
       Translated Address: 10.10.5.50        (real server)
       Translated Port:    8443

# Then a matching security rule:
Policies > Security > Add
   Source Zone:         untrust
   Destination Zone:    dmz
   Destination Address: 10.10.5.50
   Application:         ssl
   Action:              Allow  (+ profiles)

Two prerequisites are easy to forget:

• Return routing — the internal server must route traffic for the public
  address range back to the firewall, or use the firewall as its default gateway. Without it, the
  request arrives and the reply leaves by the wrong path.
• Proxy ARP — if the public address is not an interface address, the firewall
  must answer ARP for it on the untrust segment, or the upstream router will never deliver the
  packet. Enable Enable Proxy ARP in the NAT rule or on the interface.

U-Turn NAT: Internal Clients Using the Public Address

When an internal user types the public hostname, the traffic arrives on the trust interface
but the destination is the public address. A single NAT rule can handle it if the rule matches
both the external and internal source zones and translates the destination inward, with a
security rule permitting trust-to-dmz traffic to the internal address.

Original Packet
  Source Zone:         any (or trust + untrust)
  Destination Zone:    untrust
  Destination Address: 203.0.113.20
Translated Packet
  Destination Translation > Translated Address: 10.10.5.50

U-turn NAT is the reason your hairpin test from the internal network must be done from a
host that actually resolves to the public address, not the internal one. Split-horizon DNS
hides this scenario entirely and then it breaks the day someone travels.

Verifying NAT

show session all filter destination 203.0.113.20
show session id <id>                 # shows pre- and post-NAT tuples
show running nat-policy
show counter global filter aspect nat
test nat-policy-match from trust to untrust source 10.10.1.5 destination 8.8.8.8 protocol 17 destination-port 53

test nat-policy-match is the fastest way to answer "which NAT rule would this
packet hit" without sending traffic. Use it before you commit, not after the user complains.

Operational Notes

• Keep a screenshot or export of the NAT table in your change record. The translated packet
  is invisible in a packet capture taken outside the firewall, and future-you will need it.
• Do not mix U-turn NAT with a security rule that only permits untrust-sourced traffic; the
  internal client will be dropped after translation.
• NAT and IPSec were designed to be mutually annoying. If you are building site-to-site
  tunnels, read IPsec VTI vs policy-based VPN with GRE before you decide where the translation sits.
• Junos SRX uses the same source/destination model with different syntax; Junos SRX source and destination NAT configuration is a useful cross-reference when you run both platforms.

原文链接：https://docs.paloaltonetworks.com/ngfw/networking/nat/nat-policy-rules