Before NAT — the one rule that confuses everyone
Palo Alto evaluates packets in this order: route lookup → NAT match → security policy match → translate → forward. The translation itself happens last, but the NAT rule is identified before the security policy runs.
One sentence to memorise: "Pre-NAT IP, post-NAT zone." Security rules use the original (pre-NAT) IP addresses but the destination zone after the route lookup figures out where the packet is going. Drill this in — it's a top-5 PCNSE question every cycle.
Security policy matches the original source/dest IP — what the client really sent. The translation hasn't happened yet.
The destination zone is decided by the route lookup, which already knows the real egress interface. So policy uses the FINAL zone.
The NAT rule is identified early but the actual address swap happens at egress — just before the packet leaves the firewall.
You need both a NAT rule AND a security rule that allows the (pre-NAT IP, post-NAT zone) tuple. NAT alone doesn't allow traffic.
① Source NAT — many private IPs, one public face
Office mein 500 laptops sit behind one ISP link. They all share a single public IP 203.0.113.5. The firewall multiplexes them using port numbers — that's Dynamic IP and Port (DIPP), the most common NAT type on planet Earth.
▶ Watch a packet get Source-NAT'd
Click Play. Each stage lights up as the packet moves through the firewall.
trust-lan203.0.113.5.
The four Source-NAT translation types
Dynamic IP & Port — the default. Many hosts share one public IP; port numbers de-multiplex sessions. Pool: ~64K ports per public IP.
Each internal host gets a unique public IP from a pool. No port translation. Used when remote systems demand fixed source IP.
Fixed 1-to-1 mapping — host X always becomes public IP Y. Symmetric; great for inbound replies from partners.
No source translation. Used when you only need destination NAT, or when this rule is a NAT exemption (e.g. VPN traffic that must keep original IP).
Sneha at Infosys deploys Source NAT with DIPP on a single public IP 203.0.113.5. With one public IP, what's the theoretical maximum concurrent NAT'd sessions before port exhaustion?
② Destination NAT — publish an internal server
Reverse direction. The world types https://webapp.techclick.in, DNS resolves to 203.0.113.10, packet hits the firewall, firewall translates the destination to 10.50.5.10 on the DMZ.
▶ Destination NAT visualizer
A user from the internet reaches the company's DMZ-hosted web app.
untrust-wan10.50.5.10 (the post-NAT destination) → egress = ethernet1/3, zone = dmz
The security policy for inbound Dest-NAT must use the pre-NAT public IP (203.0.113.10) as destination, NOT the post-NAT private IP (10.50.5.10). The zone uses the post-NAT zone (dmz). Memorise: pre-NAT IP, post-NAT zone. Mess this up and the rule never matches, packet falls through to interzone-default-deny, and you spend 4 hours debugging.
Rahul writes a Dest-NAT rule that translates 203.0.113.10:443 to 10.50.5.10:443. He then writes a Security Policy: src=untrust-wan, dst=dmz, destination-IP=10.50.5.10. Inbound HTTPS doesn't flow. What's wrong?
③ U-Turn (Hairpin) NAT — the puzzle every L1 hits once
An employee at HQ types https://webapp.techclick.in (their own company's app, publicly published at 203.0.113.10). DNS resolves to the public IP. The packet leaves the laptop heading to the firewall. Without U-Turn NAT, the firewall sees source = inside (trust-lan), destination = its own public IP, no Dest-NAT rule for traffic-from-inside → goes haywire.
U-Turn fixes it by NAT'ing both the destination (public→private) AND the source (so the server sees the firewall as the originator, not the user's real IP — preserving symmetric return).
▶ U-Turn NAT — three-leg journey
Karthik at Flipkart office accesses the company's webapp using the public URL — without U-Turn, it breaks.
https://webapp.techclick.in
203.0.113.10, post-NAT zone dmz → "Allow-U-Turn-Web" matches
A U-Turn NAT rule is configured with destination-NAT only (public → private), but no source-NAT. Internal users can SEND the SYN, but never receive the SYN-ACK. Why?
④ Troubleshoot — "NAT not working" playbook
You've configured a NAT rule. Traffic doesn't pass. Here's the 4-step diagnosis ladder — runs in under 60 seconds.
CLI: test nat-policy-match from trust to untrust src 10.x dst 8.8.8.8. Confirms which NAT rule matches BEFORE you send a real packet.
Remember pre-NAT IP, post-NAT zone. Pass the ORIGINAL source/dest IP. Confirms the security rule is the one you expect.
Check if real sessions are being created against the rule. Zero = rule never fires. High count near port-limit = DIPP exhaustion.
Look for nat_dyn_port_xlat_full, flow_no_session_match, flow_policy_deny. Each tells you exactly which stage killed the packet.
test nat-policy-match from trust-lan to untrust-wan source 192.168.10.50 destination 8.8.8.8 protocol 6 destination-port 443
NAT-Internet-Outbound {
from trust-lan;
to untrust-wan;
source [ corp-clients ];
destination [ any ];
service any;
nat-type ipv4;
to-interface ethernet1/2;
source-translation: dynamic-ip-and-port (interface-address)
}
DIPP port exhaustion — the silent throughput killer
One public IP = ~64K ports available. 5,000 users with ~10 sessions each = 50,000 NAT'd flows = perilously close to the wall. Once you exhaust the port pool, new sessions get dropped with no clear error message. Counter to watch: nat_dyn_port_xlat_full.
1. Add IPs to the NAT pool — each public IP gives another ~64K ports. 2. Enable DIPP Oversubscription (Device → Setup → Session) — lets the firewall reuse a (translated-IP, port) combination across destination IPs. Default is 2x; bump to 4x or 8x on high-density networks. 3. For voice / video / STUN-using apps, configure Persistent DIPP on the specific NAT rule — keeps the same source-port mapping per (source-IP, destination-IP) so peer-to-peer protocols work. Per PAN-OS 11.1.1+, Persistent DIPP is per-rule, not global.
During a sudden user-growth spike, Priya sees new outbound sessions getting dropped. Counter nat_dyn_port_xlat_full is incrementing rapidly. What's the fastest mitigation that doesn't need new public IPs?
🤖 Ask the AI Tutor
Tap any question — instant context-aware answer. No login, no waiting.
Pre-curated answers from PAN-OS docs + community Q&A. For complex prod issues, paste your show counter global + show running nat-policy output into chat.techclick.in.
📝 Wrap-up — six more
You've already answered 4 inline. Six left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.
📚 Sources
- Palo Alto Docs — Source NAT and Destination NAT (PAN-OS 11.1). docs.paloaltonetworks.com
- Palo Alto Docs — U-Turn NAT (Enable Clients on Internal Network to Access Public Servers). docs.paloaltonetworks.com
- Palo Alto Docs — Create a Source NAT Rule with Persistent DIPP (PAN-OS 11.1.1+). docs.paloaltonetworks.com
- Palo Alto Docs — Dynamic IP and Port NAT Oversubscription.
- LIVECommunity — DotW: U-Turn NAT Issue. knowledgebase.paloaltonetworks.com
- LIVECommunity — NAT and Security Policies, PBF Failover and Symmetric Return — Dual ISP (thread 23158).
What's next?
Next we open up App-ID — how the firewall actually identifies an application from its bytes, why it can "shift" mid-flow, and how to write a custom App-ID for the in-house app your firewall doesn't know.