Palo Alto NAT and Security Rules: Pre-NAT IP, Post-NAT Zone, Worked Through
Why a Palo Alto security rule for a NATed server uses the public address but the inside zone. Three flows (outbound DIPP, inbound destination NAT and U-turn NAT), the order the firewall checks things in, the test commands that prove it, and the five mistakes that break it.
Every Palo Alto admin hits this once. You publish a web server with destination NAT, write a security rule with the server’s real inside address, and nothing works. Change the rule to the public address and the outside zone, and it still fails. The fix is one sentence that sounds backwards the first time you read it:
A security rule uses the pre-NAT IP addresses and the post-NAT destination zone.
This post shows why, on three real flows, so you never have to memorize it.
The mental model: two lookups, two questions
A PAN-OS firewall asks two separate questions about a new session:
- NAT policy: should I change the addresses? It answers using the packet as it arrived (the original, pre-NAT packet).
- Security policy: am I allowed to send this anywhere? It answers using the original addresses, but it needs to know where the packet will really go, and that is the zone after NAT.
The firewall only rewrites the addresses when the packet leaves. So while it makes both decisions, the packet still carries the address the client typed. That is the whole trick.
The order inside the firewall for a new session:
| Step | What happens | Gives you |
|---|---|---|
| 1 | Route lookup on the original destination | The zone for the NAT match |
| 2 | NAT policy, top down, first match only | The translation to apply |
| 3 | If the destination changed, a second route lookup on the new destination | The post-NAT zone |
| 4 | Security policy with the pre-NAT addresses and the post-NAT zone | Allow or deny |
| 5 | The packet leaves, translated |
The lab
One firewall, three zones:
| Zone | Interface | Network |
|---|---|---|
| Outside | ethernet1/1 | 203.0.113.0/24, default route to the ISP |
| Inside | ethernet1/2 | 10.1.1.0/24, users |
| DMZ | ethernet1/3 | 172.16.1.0/24, DMZ-Web is 172.16.1.10 |
DMZ-Web is published on the public address 203.0.113.66.
Flow 1: users browse the Internet (DIPP)
Source NAT only. The destination does not change, so the zones do not change either.
| NAT rule | Security rule | |
|---|---|---|
| From / to | Inside to Outside | Inside to Outside |
| Source | 10.1.1.0/24 | 10.1.1.0/24 |
| Translation | Dynamic IP and Port, interface address of ethernet1/1 | |
| Application / service | web-browsing, ssl / application-default |
For source NAT the two rules look the same, which is why most people never notice the rule until they publish a server.
Flow 2: the Internet reaches DMZ-Web (destination NAT)
Ext-Host types http://203.0.113.66. Walk the steps:
- Route lookup for 203.0.113.66: it is on the outside network, so the egress is ethernet1/1, zone Outside. The NAT rule must be from Outside to Outside. Yes, Outside to Outside.
- The NAT rule changes the destination to 172.16.1.10.
- Second route lookup for 172.16.1.10: ethernet1/3, zone DMZ. That is the post-NAT zone.
- Security rule: from Outside to DMZ, destination 203.0.113.66.
set rulebase nat rules Web-DNAT from Outside to Outside source any destination 203.0.113.66 service any
set rulebase nat rules Web-DNAT destination-translation translated-address 172.16.1.10
set rulebase security rules Allow-Web from Outside to DMZ source any destination 203.0.113.66 application web-browsing service application-default action allow
The address in the security rule is the one the client typed. The zone is the one the packet really goes to.
Flow 3: users open the company site by its public name (U-turn NAT)
Client-PC, inside, connects to 203.0.113.66 too, because DNS returns the public address.
- Route lookup for 203.0.113.66: zone Outside. The NAT match is from Inside to Outside.
- A NAT rule from Inside to Outside, destination 203.0.113.66, translates to 172.16.1.10. Post-NAT zone: DMZ.
- Security rule: from Inside to DMZ, destination 203.0.113.66.
Put this NAT rule above the broad DIPP rule from Flow 1. NAT rules are checked top down and only the first match is used, so a DIPP rule “Inside to Outside, any destination” above it would catch the traffic first and the server would never be reached.
Prove it before users do
PAN-OS can tell you which rule a session will hit without sending a single packet:
test nat-policy-match from Outside to Outside source 198.51.100.20 destination 203.0.113.66 destination-port 80 protocol 6
test security-policy-match from Outside to DMZ source 198.51.100.20 destination 203.0.113.66 destination-port 80 protocol 6
If the first command returns Web-DNAT and the second returns Allow-Web, the design is right. Then check a live session:
show session all filter destination 203.0.113.66
The five mistakes that break it
| Mistake | What you see | Fix |
|---|---|---|
| Security rule uses the inside address 172.16.1.10 | Traffic hits the interzone default deny | Use the pre-NAT address 203.0.113.66 |
| Security rule from Outside to Outside | Denied, or matched by the wrong rule | Use the post-NAT zone: Outside to DMZ |
| NAT rule from Outside to DMZ | NAT never matches | NAT uses the zone of the original destination: Outside to Outside |
| Broad DIPP rule above the U-turn rule | Inside users can’t reach the site by name | Move the specific rule above the broad one |
| Port forward with the service set to the inside port | Denied | The security rule checks the original packet, so use the original port |
The one line to keep
The security rule uses the address the client typed and the zone the packet really goes to.
Practice it
- The Palo Alto Network Security Analyst program builds all three flows on your own EVE-NG PA-VM, with the test commands above.
- The free PAN-OS console lets you practice the command syntax in your browser.
- New to NAT terms? Start with inside local vs inside global, then the security library.
Need a hand with your CCNA?
Free 20 minute 1:1 planning call with a senior network engineer. No card. No sales pitch. We walk your situation, map a realistic path, and you decide what to do next.
- 20 minutes, 1:1 with a Cisco NetAcad instructor
- No card, no obligation, no sales pitch
- You pick the slot that fits your week
Get your study plan in a free 20-minute call
- ✓ 1:1 with a senior network engineer, by video
- ✓ You leave with a written study plan and a realistic exam date
- ✓ No card, no sign-up, no sales pitch