Palo AltoConfig1,123 downloads

Palo Alto NAT Rules

Source NAT (masquerade / IP pool), Destination NAT (DNAT/port-forwarding), and static NAT rules for Palo Alto PAN-OS firewalls.

↓ example.txt

What is it?

NAT (Network Address Translation) on Palo Alto rewrites IP addresses as packets traverse the firewall. Source NAT (SNAT) hides private internal IPs behind a public IP when users access the internet — the most common type is 'dynamic IP and port' (masquerade). Destination NAT (DNAT) redirects inbound traffic to an internal server — used for publishing web servers, exposing APIs, or port-forwarding. PAN-OS evaluates NAT rules before security policies — a packet is first matched to a NAT rule (translated), then the translated packet is matched to a security policy.

When to use

·Any time private RFC 1918 addresses (10.x, 172.16.x, 192.168.x) need to access the internet — requires source NAT
·Publishing internal servers to the internet (web server, mail server, VPN concentrator) — requires destination NAT
·Multi-ISP environments where you need to steer traffic through specific interfaces with different public IPs
·Moving servers to new IPs without changing external DNS — use static NAT as a transition

When NOT to use

·Site-to-site VPN traffic — VPN traffic must NOT be source-natted. Use a NAT exemption rule (no-nat) for VPN subnets.
·Internal server-to-server traffic within the same zone — NAT is only needed when crossing the firewall

How it compares

vs Cisco ASA NATASA uses 'nat' and 'static' commands with complex syntax. PAN-OS NAT rules are simpler and more readable. PAN-OS evaluates NAT top-down like security rules — the first match wins.

vs Fortinet NATFortiGate can apply NAT directly in security policy ('enable NAT' toggle) or via separate SNAT/DNAT policies. Palo Alto always uses separate NAT rule objects, which are easier to audit.

Prerequisites

→Security zones must be defined before NAT rules reference them
→Address objects for servers should be created first
→For DNAT (inbound): a corresponding security policy must also allow the traffic from untrust to trust/DMZ zone
→For VPN coexistence: create a 'no-nat' rule above the internet SNAT rule to exclude VPN subnets

Config Generator

Hostname *

Virtual System

Source NAT Rules

Destination NAT Rules (DNAT / Port-forward)

Verification commands

show running nat-policy

Show all active NAT rules in order

ExpectedLists all NAT rules with from/to zones, source, destination, and translation action

show session id <session-id>

Show NAT translation details for a specific session

ExpectedShows pre-NAT and post-NAT source/destination IPs for the session

Debug commands

test nat-policy-match source <ip> destination <ip> to untrust from trust protocol 6 destination-port 80

Test which NAT rule matches specific traffic

Common mistakes & fixes

SymptomUsers cannot access the internet after adding SNAT rule

CauseSNAT rule created but security policy is still denying the traffic

FixNAT and security policies are separate. Verify a security policy allows trust → untrust traffic for the applications needed.

SymptomVPN traffic getting source-natted — tunnel doesn't work

CauseSNAT rule matching VPN traffic before it enters the tunnel

FixAdd a 'no-nat' rule ABOVE the SNAT rule: from trust to untrust, source = local VPN subnet, destination = remote VPN subnet, action = no source translation.

SymptomDNAT (inbound) rule not working — traffic not reaching internal server

CauseDNAT rule translates destination IP, but security policy still checks original IP and zone mismatch

FixFor DNAT, the security policy must match the ORIGINAL destination (public IP or 'any') with from=untrust to=untrust (or the interface zone). After DNAT, security policy sees the translated destination.

Further learning

Recommended books to go deeper on this topic.

Palo Alto Networks Firewall Deployment and Administration

Tom Piens · Packt · PAN-OS NAT policies — source NAT, destination NAT, U-turn NAT

Kindle ↗Hardcover ↗Paperback ↗