TTechclick All lessons
Palo Alto · NGFW Core Security · NATInteractive · L1 / L2

Palo Alto NAT — Watch It, Click It, Get It in 12 Minutes

Source NAT. Destination NAT. U-Turn. DIPP. Skip the wall of text — pick a NAT type below, watch the packet headers actually transform live, ask the in-page AI tutor anything, and you're done.

📅 2026-05-25 · ⏱ 12 min · 4 interactive demos · 🏷 10-Q assessment + AI Tutor inline

Pick a NAT — jump straight to it

1

Source NAT

Many private IPs → one public IP. The default rule on 80% of corporate networks.

2

Destination NAT

Publish an internal server to the world on a public IP + port.

3

U-Turn / Hairpin

Internal users reaching their own server's public IP. The classic puzzle.

4

Troubleshoot

"NAT not working" → 4-step playbook + DIPP port exhaustion fix.

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.

📨
Pre-NAT IP
tap to flip

Security policy matches the original source/dest IP — what the client really sent. The translation hasn't happened yet.

🗺
Post-NAT zone
tap to flip

The destination zone is decided by the route lookup, which already knows the real egress interface. So policy uses the FINAL zone.

🔁
NAT then translate
tap to flip

The NAT rule is identified early but the actual address swap happens at egress — just before the packet leaves the firewall.

🧱
Implicit pairing
tap to flip

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.

① INGRESS 192.168.10.50:512348.8.8.8:443
From Sneha's laptop in zone trust-lan
② ROUTE Egress interface = ethernet1/2 · destination zone = untrust-wan
③ NAT MATCH Rule "SNAT-Internet-Outbound" matches src=trust-lan, dst=untrust-wan
④ SEC POLICY Pre-NAT IPs 192.168.10.508.8.8.8 + post-NAT zone = untrust-wan → rule "Allow-Web-Out" matches
⑤ TRANSLATE 203.0.113.5:621178.8.8.8:443
Source IP becomes the firewall's public IP. Source port re-mapped from the DIPP pool.
⑥ EGRESS Packet leaves ethernet1/2 with new source IP + port. Internet sees only 203.0.113.5.
Press Play to step through what the firewall actually does. Each press of Next advances one stage.

The four Source-NAT translation types

🔢
DIPP
tap

Dynamic IP & Port — the default. Many hosts share one public IP; port numbers de-multiplex sessions. Pool: ~64K ports per public IP.

🎯
Dynamic IP
tap

Each internal host gets a unique public IP from a pool. No port translation. Used when remote systems demand fixed source IP.

📌
Static IP
tap

Fixed 1-to-1 mapping — host X always becomes public IP Y. Symmetric; great for inbound replies from partners.

🚫
None
tap

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).

Quick check · Q1 of 10

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?

Correct: a. DIPP multiplexes sessions using the source port — roughly 64K ports per public IP minus reserved ports. With a single public IP that's your ceiling. Hit it and you get the dreaded "no source port available" drops. Fix: add IPs to the pool, enable DIPP oversubscription, or split with multiple NAT rules.

② 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.

① INGRESS 198.51.100.42:55012203.0.113.10:443
External user from zone untrust-wan
② ROUTE FIB looks up 10.50.5.10 (the post-NAT destination) → egress = ethernet1/3, zone = dmz
③ NAT MATCH Rule "DNAT-Web-Pub": dst-IP = 203.0.113.10 → translate to 10.50.5.10
④ SEC POLICY Pre-NAT dst 203.0.113.10, post-NAT zone dmz → rule "Allow-Web-Public" matches
⚠ Top mistake: writing the rule with destination = 10.50.5.10. That's POST-NAT IP — won't match.
⑤ TRANSLATE 198.51.100.42:5501210.50.5.10:443
⑥ EGRESS Packet exits ethernet1/3 into DMZ. Web server replies; firewall reverses the NAT on the return path.
Watch where the zone is calculated (stage 2 — route lookup) vs where IP swap happens (stage 5 — egress).
The #1 Dest-NAT trap

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.

Quick check · Q2 of 10

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?

Correct: b. Pre-NAT IP, post-NAT zone. Security policy must see the destination as it arrived (203.0.113.10) because translation hasn't happened yet at policy-evaluation time. Change the rule's destination-IP to the public IP, keep destination-zone = dmz. Traffic flows.

③ 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.

① CLIENT Karthik's laptop in zone trust-lanhttps://webapp.techclick.in
② INGRESS 10.10.10.42:51012203.0.113.10:443
Destination is firewall's own public IP — without U-Turn, no Dest-NAT rule matches trust→untrust direction.
③ U-TURN NAT Rule: src-zone=trust, dst-IP=203.0.113.10 → translate dst to 10.50.5.10 AND src to firewall IP 10.50.5.1 (or interface IP)
④ SEC POLICY Pre-NAT dst 203.0.113.10, post-NAT zone dmz → "Allow-U-Turn-Web" matches
⑤ TRANSLATE 10.50.5.1:6200210.50.5.10:443
Both source AND destination translated — that's the "two-leg" hairpin.
⑥ EGRESS Server replies to firewall (not Karthik's laptop) → firewall reverses the NAT → reply lands on Karthik's laptop.
Without the source-NAT half, server would reply directly to Karthik's IP — asymmetric, broken.
U-Turn = Dest-NAT + Source-NAT in one rule. The source half is what prevents asymmetric return.
Quick check · Q3 of 10

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?

Correct: a. Server is on the same internal network as the client. If the source IP wasn't translated, the server replies directly to the client (intra-DMZ-to-trust routing or even L2 ARP). The firewall never sees the return, gets out-of-sync, drops it. Adding source-NAT to the firewall's IP forces the return through the firewall — symmetry restored.

④ 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.

test nat-policy-match
tap

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.

test sec-policy-match
tap

Remember pre-NAT IP, post-NAT zone. Pass the ORIGINAL source/dest IP. Confirms the security rule is the one you expect.

show session all filter nat-rule
tap

Check if real sessions are being created against the rule. Zero = rule never fires. High count near port-limit = DIPP exhaustion.

show counter global
tap

Look for nat_dyn_port_xlat_full, flow_no_session_match, flow_policy_deny. Each tells you exactly which stage killed the packet.

CLI — settle the argument in 5 seconds
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
Expected output
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.

Three fixes for DIPP exhaustion

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.

Quick check · Q4 of 10

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?

Correct: d. DIPP oversubscription lets the firewall reuse a (translated-IP, port) combination across DIFFERENT destination IPs. Default is 2x; bump to 4x or 8x. Reboot wastes outage time. Disabling App-ID breaks the whole security model. Aggressive TCP timeouts cause connection drops on legitimate idle sessions.

🤖 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.

Q5 · Apply

In a PAN-OS Destination NAT rule, the destination-zone field should be set to which value?

Correct: a — PRE-NAT zone. NAT rules use PRE-NAT zones in both src and dst (matching where the packet actually arrives). Security policy uses pre-NAT IPs + post-NAT zone. Don't conflate the two — NAT and Security have different zone-evaluation rules.
Q6 · Analyze

A Bi-Directional Source NAT rule is enabled for 10.50.5.10 → 203.0.113.10. What does the "bi-directional" flag actually do that a normal Source NAT rule doesn't?

Correct: c — auto-creates the mirror Dest-NAT rule. When you tick "bi-directional" on a Static Source NAT rule, PAN-OS implicitly creates the inverse Destination NAT — saving a config step but also creating an invisible rule new admins don't see in the GUI. Useful for public-facing servers; auditors hate it. Document the bi-directional flag clearly when used.
Q7 · Analyze

A site has dual-WAN (ISP1 + ISP2). Source NAT to ISP1's public IP works. After enabling Destination NAT for incoming traffic on ISP2, return traffic for the inbound flow breaks — sessions get torn down. Why?

Correct: b — Symmetric Return required. Default route prefers one ISP for outbound. Inbound came in via the other ISP, but the firewall's default route sends the reply via ISP1 — asymmetric, drops follow. The fix is Policy-Based Forwarding (PBF) with the Symmetric Return action, which makes return traffic exit through the SAME interface it arrived on. We'll deep-dive PBF in Blog 12.
Q8 · Analyze

A Source NAT rule using DIPP has the "Translated Address" set to "Interface Address". The interface IP changes from 203.0.113.5 to 203.0.113.7 after a DHCP renewal. What happens to existing NAT'd sessions and to new ones?

Correct: d. "Interface Address" mode auto-updates to whatever IP the interface currently holds — no commit needed for new sessions. BUT existing sessions are translated to the OLD IP; their return packets land on the old IP (which the interface no longer owns) and are dropped. In production, this is why people prefer pinned public IPs over interface-address mode for DIPP. Schedule DHCP renewals after-hours, or use a static IP.
Q9 · Evaluate

A team is planning to add VoIP for 800 employees behind a single public IP using DIPP. VoIP uses STUN, which expects consistent (source-IP, source-port) per call session. Which NAT design is right?

Correct: c — Persistent DIPP scoped to VoIP rule. STUN and other peer-to-peer / NAT-traversal apps rely on source-port stability — they advertise their NAT'd port and expect it to stay constant. Standard DIPP can re-allocate ports across different destinations, breaking STUN. Persistent DIPP keeps (src-IP → translated-port) consistent per src-IP-dest-IP pair. Scope it to the VoIP-only rule so you don't waste persistent-DIPP pool space on regular web traffic.
Q10 · Evaluate

An auditor proposes "to simplify, replace all 12 individual Destination NAT rules with a single bi-directional Source NAT rule that handles both directions". The 12 rules currently publish 12 different internal servers on 12 different public IPs. Is this proposal sound?

Correct: b. Bi-directional NAT is a per-rule flag that creates the reverse rule for that ONE static IP pair. You can't fold 12 different (internal IP → public IP) mappings into one bi-directional rule. The proposal misunderstands what bi-directional does. The legitimate simplification is to use address objects + groups so the 12 rules at least share consistent zones, services, and naming — keeping rule count low while preserving 1-to-1 mappings.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the section that tripped you up and tap "Try again".

📚 Sources

  1. Palo Alto Docs — Source NAT and Destination NAT (PAN-OS 11.1). docs.paloaltonetworks.com
  2. Palo Alto Docs — U-Turn NAT (Enable Clients on Internal Network to Access Public Servers). docs.paloaltonetworks.com
  3. Palo Alto Docs — Create a Source NAT Rule with Persistent DIPP (PAN-OS 11.1.1+). docs.paloaltonetworks.com
  4. Palo Alto Docs — Dynamic IP and Port NAT Oversubscription.
  5. LIVECommunity — DotW: U-Turn NAT Issue. knowledgebase.paloaltonetworks.com
  6. 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.