NAT — the silent killer of firewall policies
NAT is the silent killer of firewall policies.
- #engineer-series
- #paloaltonetworks
- #nat
- #networksecurity
- #firewallengineer
- #cybersecurity
By Mrugesh Patel, Senior Network Security Engineer
Originally posted on LinkedIn — Engineer Series · 2026-06-08
NAT is the silent killer of firewall policies.
More working policies have been broken by misunderstanding NAT than by any other single concept.
Here’s the core confusion: where does NAT happen relative to security policy?
On Palo Alto, security policy is evaluated using:
✅ Pre-NAT IP addresses
✅ Post-NAT zones
Let that sink in. Most engineers reverse it the first time.
The traps that get everyone:
🔴 Building a rule with the post-NAT IP as the destination
→ It will never match. Ever.
🔴 Forgetting that the firewall does NAT after policy lookup
→ Your debug logs look right. Traffic still fails.
🔴 Using “any” for source NAT zones in DIPP
→ You just opened up sessions you didn’t intend to allow.
🔴 U-Turn NAT (hairpinning) without proper zone planning
→ Internal users hit your public IP. Now they’re traversing the firewall in unexpected ways.
The mental model that fixes it:
SECURITY POLICY: Pre-NAT addresses, post-NAT zones
NAT POLICY: Pre-NAT zones, pre-NAT addresses
Draw it on a whiteboard. Tape it to your monitor. Reference it every time.
One more thing: Always test NAT with packet captures. Logs lie about what actually translates.
What’s the most painful NAT lesson you’ve learned in production?
Found this useful?
Share it on LinkedIn — it tells me what to write about next, and helps other engineers find it.