2.3 Security Policy Enforcement & NAT Architecture

2.3 Security Policy Enforcement & NAT Architecture

Quick Answer: PAN-OS separates Network Address Translation (NAT) and Security Policy enforcement into distinct, modular functional engines that collaborate during packet processing. Security policies evaluate traffic sequentially using a top-to-bottom, first-match algorithm. Default rules (intrazone-default allow and interzone-default deny) must be overridden to log at session end for full network visibility. In Destination NAT (DNAT) environments, administrators must master the golden configuration rule: the Security Policy rule requires the post-NAT destination security zone (where the target server physically resides) combined with the pre-NAT public destination IP address. For internal clients accessing public-facing internal servers, U-Turn NAT requires dual translation (both DNAT and SNAT) to prevent fatal asymmetric routing drops.

---

Security Policy Structure & First-Match Evaluation Logic

In PAN-OS, Security Policies govern all transit traffic crossing the firewall dataplane. Unlike routers or basic firewalls that evaluate stateless access control lists, PAN-OS matches traffic against stateful, application-aware, and identity-aware security rules.

Rule Evaluation Order

Security rules are evaluated sequentially from top to bottom based on a strict first-match logic. When a packet initiates a new session, the firewall scans the rulebase in descending order. The moment a packet satisfies all criteria of a rule, PAN-OS executes that rule's configured action (allow, deny, drop, reset-client, reset-server, or reset-both) and immediately halts further rule evaluation. No subsequent rules are checked.

[ Ingress Packet ]
       │
       ▼
┌────────────────────────────────────────────────────────┐
│ Panorama Pre-Rules (Shared / Device Group Hierarchy)   │ ──> Evaluated First
└──────────────────────────┬─────────────────────────────┘
                           │ (No Match)
                           ▼
┌────────────────────────────────────────────────────────┐
│ Local Firewall Rules (Admin configured locally on FW)   │ ──> Evaluated Second
└──────────────────────────┬─────────────────────────────┘
                           │ (No Match)
                           ▼
┌────────────────────────────────────────────────────────┐
│ Panorama Post-Rules (Shared / Device Group Hierarchy)  │ ──> Evaluated Third
└──────────────────────────┬─────────────────────────────┘
                           │ (No Match)
                           ▼
┌────────────────────────────────────────────────────────┐
│ Default Rules:                                         │
│ • Intrazone-default  ──> Action: ALLOW (No Log by def) │
│ • Interzone-default  ──> Action: DENY  (No Log by def) │
└────────────────────────────────────────────────────────┘

Rule Types: Universal, Intrazone, and Interzone

When authoring security rules, administrators classify the rule's geographic scope:

• Universal (Default): Matches traffic both within a single zone (intrazone) and between different zones (interzone). Universal is the standard rule type for general traffic management.
• Intrazone: Matches traffic only when the source security zone and destination security zone are identical (e.g., traffic between two hosts within the Trust zone traversing the firewall).
• Interzone: Matches traffic strictly when the source zone and destination zone differ (e.g., traffic from Trust destined to Untrust).

Overriding Default Security Rules

Every PAN-OS firewall includes two immutable default rules displayed at the bottom of the rulebase:

1. intrazone-default: Permitted by default (action allow). Allows traffic between interfaces assigned to the exact same zone.
2. interzone-default: Denied by default (action deny). Drops traffic attempting to cross between different zones that failed to match any preceding rule.

[!CRITICAL] Security Best Practice & Exam Core: By default, neither intrazone-default nor interzone-default generates traffic logs! Unlogged interzone drops conceal reconnaissance scans, lateral movement, and misconfigured applications. Security best practice requires overriding both default rules in the WebUI or CLI to enable Log at Session End and attach a Log Forwarding Profile directing alerts to Cortex Data Lake or an enterprise SIEM.

---

The Golden Rule of PAN-OS Destination NAT & Security Policy Construction

One of the most heavily tested and operationally misunderstood concepts in PAN-OS network security is the architectural relationship between Destination NAT (DNAT) and Security Policy rule construction.

Packet Ingress from Internet:                     Firewall Processing Pipeline:
Source: 198.51.100.25                             1. Ingress Packet Arrives on Untrust Interface
Destination: 203.0.113.50 (Public IP)            2. NAT Policy Lookup determines Destination NAT to 10.2.2.100
                                                  3. Route Lookup determines Egress Interface sits in DMZ Zone
                                                  4. Security Policy Lookup executes:
                                                     • Source Zone:      UNTRUST
                                                     • Destination Zone: DMZ  <── (POST-NAT ZONE)
                                                     • Destination IP:   203.0.113.50 <── (PRE-NAT IP)

The Processing Pipeline Timeline

When an external packet arrives seeking an internal server:

1. Ingress Interface & Zone Identification: The packet enters the ingress interface (e.g., ethernet1/1 in zone Untrust).
2. NAT Policy Lookup: PAN-OS checks the NAT policy table first to determine if Destination NAT applies. It identifies that the public destination IP 203.0.113.50 translates to the private IP 10.2.2.100.
3. Route Lookup & Egress Zone Determination: The firewall performs a route lookup for the translated private IP 10.2.2.100 and discovers the egress interface resides in the DMZ security zone.
4. Security Policy Evaluation: The firewall now evaluates the Security Policy rulebase to decide whether the session is permitted.

The Golden Rule Formula

To successfully permit an inbound Destination NAT connection, the Security Policy rule must be constructed using:

• Source Zone: Ingress zone where the client resides (e.g., Untrust).
• Source Address: Client IP address or Any.
• Destination Zone: The POST-NAT ZONE (where the internal target server actually lives, e.g., DMZ).
• Destination Address: The PRE-NAT IP ADDRESS (the public IP requested by the client, e.g., 203.0.113.50).

[!WARNING] Exam Trap: Do not configure the Security Policy destination address as the private server IP (10.2.2.100), and do not configure the destination zone as Untrust. If the rule is configured with Destination Zone: Untrust or Destination Address: 10.2.2.100, the security policy evaluation will fail to match, and the packet will be dropped by the interzone-default deny rule.

---

Source NAT Mechanisms: DIPP, Dynamic IP & Static NAT

Source Network Address Translation (SNAT) translates the private IP addresses of internal clients into routable public IP addresses as traffic departs for the internet or external networks. PAN-OS offers three primary Source NAT mechanisms:

   DIPP Source NAT (Many-to-One with Port Oversubscription):

   Client A: 10.1.1.25:49152 ──┐
                               ├──> [ PAN-OS DIPP NAT: 203.0.113.10:25000 ] ──> Server X (198.51.100.1)
   Client B: 10.1.1.50:49152 ──┘    (Reuses port 25000 via Oversubscription) ──> Server Y (198.51.100.2)

Dynamic IP and Port (DIPP) & Port Oversubscription

Under standard DIPP, an outbound public IP address provides approximately 64,000 ephemeral source ports (ports 1024 to 65535). In large enterprise environments with thousands of concurrent users, a single IP address can quickly exhaust available ports, causing connection drops.

To solve this, PAN-OS provides Port Oversubscription (supporting factors of 2x, 4x, or 8x on enterprise hardware):

• Oversubscription allows the firewall to allocate the exact same translated source IP and source port to multiple concurrent outbound connections, provided that the destination IP addresses are different.
• Because the destination IP address differs, the resulting 5-tuple (Source IP, Source Port, Dest IP, Dest Port, Protocol) remains globally unique within the stateful session architecture.
• Administrators can configure Fallback Pools (such as translating to the firewall's egress interface IP) if the primary DIPP pool becomes exhausted.

Static IP & The Bidirectional Setting

A Static IP NAT rule maps an internal address to an external address on a permanent 1:1 basis. When the Bi-directional checkbox is enabled on a Static Source NAT rule, PAN-OS automatically synthesizes an implicit inbound Destination NAT rule. An external client initiating a connection to the public IP is automatically translated to the internal private IP, eliminating the operational requirement to manually author a separate matching DNAT rule.

---

Destination NAT, Port Forwarding & DNS Rewrite

Destination NAT translates incoming destination IP addresses and ports to redirect traffic to internal servers.

Port Forwarding (Port Translation)

In scenarios where an enterprise hosts multiple services behind a single public IP address, PAN-OS provides port forwarding by translating both the destination IP and the destination Layer 4 port:

• External Client connects to: 203.0.113.25:8443
• NAT Translation: Rewrites destination IP to 10.2.2.50 and destination port to 443.
• The server receives native HTTPS traffic on standard port 443.

DNS Rewrite (DNS Doctoring)

Organizations frequently host public-facing servers (e.g., portal.example.com) whose authoritative public DNS records resolve to an external public IP (203.0.113.50). However, internal clients inside the Trust zone must access the same server.

If an internal client queries an external public DNS server, the DNS response returns the public IP 203.0.113.50. If the client connects to this public IP without specialized routing, the traffic hairpins unnecessarily or fails.

DNS Rewrite resolves this split-horizon challenge directly within the NAT policy:

1. The firewall inspects DNS A and AAAA query response packets traversing the firewall from external DNS servers.
2. When enabled on a Destination NAT rule, PAN-OS rewrites the payload of the DNS response, replacing the public IP 203.0.113.50 with the internal private IP 10.2.2.100.
3. The internal client receives the private IP directly and communicates across local high-speed LAN routing.

---

U-Turn NAT: Architecture, Asymmetric Routing & Dual Translation

When internal clients must access an internal server using the server's public external IP address (for example, when split-horizon DNS is not deployed and clients must resolve the public FQDN), standard Destination NAT causes connection failure due to asymmetric routing.

   THE ASYMMETRIC ROUTING TRAP (Without Source NAT):

   Client (10.1.1.50) ─────────── Packet to 203.0.113.50 ──────────> [ PAN-OS Firewall ]
           ▲                                                              │ (DNAT to 10.2.2.100)
           │                                                              ▼
           │ Direct local reply                                 Server (10.2.2.100)
           │ from 10.2.2.100                                              │
           └──────────────────────────────────────────────────────────────┘
           (CLIENT SENDS TCP RST: Expected packet from 203.0.113.50!)

   THE U-TURN NAT SOLUTION (Dual Translation: DNAT + SNAT):

   Client (10.1.1.50) ─────────── Packet to 203.0.113.50 ──────────> [ PAN-OS Firewall ]
           ▲                                                              │ DNAT: Dest -> 10.2.2.100
           │                                                              │ SNAT: Src  -> 10.2.2.1 (FW)
           │                                                              ▼
           │ S2C Reply from 203.0.113.50                        Server (10.2.2.100)
           │ (Firewall un-translates both IPs)                            │ Reply to 10.2.2.1
           └───────────────────── [ PAN-OS Firewall ] <───────────────────┘

The Asymmetric Routing Failure Explained

1. An internal client (10.1.1.50 in Trust) sends a packet destined to the server's public IP (203.0.113.50).
2. The packet hits the firewall. Destination NAT translates the destination IP to 10.2.2.100 (in DMZ).
3. The firewall forwards the packet to the server. Notice the packet addresses:
   • Source IP: 10.1.1.50 (the client)
   • Destination IP: 10.2.2.100 (the server)
4. The server receives the packet and generates a SYN-ACK response. Because the source IP is an internal address (10.1.1.50), the server's local routing table sends the response directly across the internal switch/router to the client, completely bypassing the firewall!
5. The client receives a SYN-ACK originating from 10.2.2.100. The client immediately transmits a TCP RST and tears down the connection because it never initiated a session with 10.2.2.100 (it initiated a session with 203.0.113.50).

The U-Turn NAT Configuration Solution

To make U-Turn NAT succeed, the firewall must enforce Dual Translation by configuring both Destination NAT and Source NAT within the NAT policy rule:

• Destination NAT: Translates the public IP 203.0.113.50 to the private IP 10.2.2.100.
• Source NAT: Translates the client's source IP 10.1.1.50 to the firewall's DMZ interface IP (e.g., 10.2.2.1).

When the server replies, it sends the response to 10.2.2.1 (the firewall). The firewall reverses both the Source NAT and Destination NAT operations, returning the packet to the client with the source IP properly set to 203.0.113.50. The client receives the expected packet, and the stateful three-way handshake completes successfully.

---

Security Policy Criteria Ordering & Anatomy

Every PAN-OS security rule evaluates up to nine discrete criteria matching the packet flow:

┌────────────────────────────────────────────────────────────────────────┐
│                     PAN-OS Security Rule Anatomy                       │
├─────────────────┬──────────────────────────────────────────────────────┤
│ 1. Name         │ Descriptive identifier (e.g., 'Permit-DMZ-Web')      │
│ 2. Rule Type    │ Universal, Intrazone, or Interzone                   │
│ 3. Source       │ Source Zone, Source Address/FQDN, Source User/DUG,   │
│                 │ and Host Information Profile (HIP)                   │
│ 4. Destination  │ Destination Zone, Destination Address/FQDN           │
│ 5. Application  │ Specific App-IDs (e.g., ssl, web-browsing)           │
│ 6. Service/Port │ application-default or specific Layer 4 Port Objects │
│ 7. Action       │ Allow, Deny, Drop, Reset (Client/Server/Both)        │
│ 8. Profile Group│ Antivirus, Anti-Spyware, Vulnerability, URL Filtering,│
│                 │ File Blocking, WildFire Analysis, Decryption Broker  │
│ 9. Options      │ Log at Session Start, Log at Session End, Forwarding │
└─────────────────┴──────────────────────────────────────────────────────┘

---

CLI Diagnostics & Operational Verification

Security engineers troubleshoot Security Policy and NAT matching using dedicated diagnostic commands:

# Test which NAT policy rule matches a given traffic flow
admin@PA-5450> test nat-policy-match source 10.1.1.50 destination 203.0.113.50 protocol 6 to-port 443

NAT-Uturn-Web; index: 2 {
    source nat: 10.2.2.1 (d-ip);
    destination nat: 10.2.2.100:443;
}

# Test which Security Policy rule matches a post-NAT traffic flow
admin@PA-5450> test security-policy-match source 10.1.1.50 destination 203.0.113.50 protocol 6 port 443 from Trust to DMZ

"Permit-Internal-To-DMZ-Web; index: 4" {
    action allow;
    log-start no;
    log-end yes;
}

# View the active NAT rulebase running in dataplane memory
admin@PA-5450> show running nat-policy

# Filter active sessions to observe NAT translations in real time
admin@PA-5450> show session all filter source 10.1.1.50

Session 84129: [Trust] 10.1.1.50:51234 --> [DMZ] 203.0.113.50:443
               [DMZ] 10.2.2.1:51234   --> [DMZ] 10.2.2.100:443
               State: ACTIVE, App: web-browsing, Action: ALLOW