PAN-OS: Differentiating Pre-Rules, Local Rules, Default Rules, and Post-Rules

PCNSE Objective Focus (Domain 4 - 18%)

4.2 Configure device groups

• 4.2.1 Device group hierarchies
• (Implicit) Understanding Rule Evaluation Order

Introduction: Policy Evaluation Order Matters

When managing firewalls with Panorama, understanding the precise order in which different types of policy rules are evaluated is absolutely critical for ensuring correct traffic handling and security enforcement. A firewall managed by Panorama effectively combines rules from multiple sources:

• Rules inherited from the Shared scope in Panorama.
• Rules inherited from parent Device Groups .
• Rules defined within the specific Device Group the firewall belongs to.
• Rules potentially configured Locally on the firewall itself.
• Built-in Default Security rules.

Panorama provides structure through Pre-rules and Post-rules within Device Groups and Shared scope to control precedence. This guide differentiates the use cases for each rule type within this evaluation hierarchy.

When a packet requiring a policy decision hits a Panorama-managed firewall, the rules are checked in this strict order across *all applicable policy types* (Security, NAT, Decryption, QoS, PBF, etc., although Default rules are specific to Security Policy):

    graph TD
        Start[Packet Arrives] --> SharedPre(Shared Pre-Rules);
        SharedPre --> ParentPre(Parent DG Pre-Rules
Top-down in Hierarchy);
        ParentPre --> ChildPre(Child DG Pre-Rules);
        ChildPre --> LocalFW(Local Firewall Rules);
        LocalFW --> ChildPost(Child DG Post-Rules);
        ChildPost --> ParentPost(Parent DG Post-Rules
Bottom-up in Hierarchy);
        ParentPost --> SharedPost(Shared Post-Rules);
        SharedPost --> DefaultSec(Default Security Rules
Intra/Interzone - For Security Policy ONLY);
        DefaultSec --> FinalAction[Final Action Determined];
        LocalFW -- First Match --> FinalAction;
        ChildPre -- First Match --> FinalAction;
        ParentPre -- First Match --> FinalAction;
        SharedPre -- First Match --> FinalAction;
        ChildPost -- First Match --> FinalAction;
        ParentPost -- First Match --> FinalAction;
        SharedPost -- First Match --> FinalAction;


        style Start fill:#e9ecef,stroke:#adb5bd
        style FinalAction fill:#e9ecef,stroke:#adb5bd
        style LocalFW fill:#fdebd0,stroke:#f5b041,stroke-width:2px
        style DefaultSec fill:#eaf2f8,stroke:#aed6f1,stroke-width:2px
     

1. Shared Pre-rules
2. Parent Device Group Pre-rules (processed from highest ancestor down to immediate parent)
3. Child Device Group Pre-rules (the specific group the firewall belongs to)
4. Local Firewall Rules (if any exist and are not overridden)
5. Child Device Group Post-rules
6. Parent Device Group Post-rules (processed from immediate parent up to highest ancestor)
7. Shared Post-rules
8. Default Security Rules (ONLY for Security Policy lookup if no prior rule matched)

The first rule in this sequence that matches the traffic determines the action taken. No further rules *in that specific policy type* (e.g., Security) are evaluated for that session.

Definition:

Rules configured in the "Pre Rules" section within Panorama's Shared scope or any Device Group.

Evaluation Point:

FIRST - Before any Local Firewall rules and before any Post-rules.

Primary Use Cases:

• Global Enforcement / Universal Blocks: Defining rules that MUST apply to all inheriting devices and should take precedence over more specific rules defined later. Examples:
  • Blocking known malicious IP addresses or ranges using EDLs (in Shared Pre-rules).
  • Blocking specific high-risk applications or URL categories globally.
  • Mandatory compliance rules.
• Universal Infrastructure Allows: Allowing critical infrastructure traffic that should always be permitted early in the evaluation. Examples:
  • Allowing traffic required for firewall management (Panorama connectivity, DNS for firewall services, NTP) if not handled by Service Routes or Management Interface.
  • Allowing traffic between essential security infrastructure components.
• Setting High-Priority QoS: Applying initial QoS classification for highly critical traffic.

Characteristics:

• Highest precedence within the Panorama-pushed configuration.
• Ideal for broad enforcement or foundational rules.
• Can be overridden by Pre-rules defined in lower-level (child) Device Groups if designed carefully, but generally intended for top-down enforcement.

Definition:

Policy rules configured directly on the individual firewall's GUI or CLI, *not* pushed from Panorama Templates or Device Groups.

Evaluation Point:

MIDDLE - After ALL Pre-rules (from Shared down to the Child DG) have been evaluated, but before ANY Post-rules are evaluated.

Primary Use Cases:

• Troubleshooting: Temporarily adding specific allow/deny rules to diagnose connectivity issues without modifying Panorama configuration.
• Exceptions & Urgent Changes: Implementing device-specific exceptions or urgent rules that cannot wait for a full Panorama push cycle (use with extreme caution and clear documentation).
• Non-Panorama Managed Firewalls: This is the standard rule location if a firewall isn't managed by Panorama.
• Staging/Testing: Sometimes used for testing rules locally before adding them to Panorama (though testing via Panorama commit previews is often better).

Characteristics:

• Can override the *outcome* of inherited Pre-rules (e.g., if a Pre-rule *allows* traffic, a more specific Local rule can *deny* it).
• Will be overridden by matching inherited Post-rules (e.g., a Local 'allow' will be blocked by a broader DG Post-rule 'deny').
• Generally discouraged in centrally managed Panorama environments as they break consistency and centralized control. Panorama RBAC can be used to prevent local rule creation.
• Not visible within the Panorama Device Group policy view.

Definition:

Two implicit, non-configurable rules that exist at the very bottom of the Security Policy rulebase only.

Evaluation Point:

ABSOLUTE LAST (for Security Policy) - Only evaluated if NO other Security Policy rule (Shared Pre, DG Pre, Local, Child DG Post, Parent DG Post, Shared Post) matches the traffic.

Rules & Actions:

• intrazone-default : Matches traffic where the source and destination zones are the same . Action: Allow .
• interzone-default : Matches traffic where the source and destination zones are different . Action: Deny .

Primary Use Cases:

• Implicit Safety Net: Provides a default behavior for traffic not explicitly addressed by administrator-defined rules.
• Baseline Security: Ensures traffic between different security zones is denied by default, enforcing segmentation unless explicitly permitted. Allows basic communication within the same zone unless explicitly blocked.

Characteristics:

• Cannot be edited or disabled directly.
• Can be effectively overridden by placing explicit allow/deny rules (especially Post-rules acting as clean-up) above them in the evaluation order.
• Logging is disabled by default. Best practice is to create explicit "cleanup" rules in Post-rules (e.g., deny any any) with logging enabled, placed just above these defaults, rather than relying on the default rule logs.
• Apply ONLY to Security Policy, not NAT, Decryption, QoS etc.

Definition:

Rules configured in the "Post Rules" section within Panorama's Shared scope or any Device Group.

Evaluation Point:

LATE - After all Pre-rules and Local Firewall rules, but before the Default Security rules.

Primary Use Cases:

• Cleanup Rules / Default Deny: Defining explicit "deny any any" rules with logging enabled. This provides better visibility than relying on the silent `interzone-default` deny. Placed in Post-rules ensures they don't block specific allows defined in Pre or Local rules.
• Broad Allow Rules (Least Specific): Rules that should only apply if no specific rules higher up matched. Example: A general `web-browsing` allow rule placed in Post-rules after more specific application allow/deny rules in the main section or Pre-rules.
• Fallback Policies: Defining baseline acceptable traffic if more specific policies aren't met.

Characteristics:

• Lower precedence than Pre-rules and Local Firewall rules within the same hierarchy level.
• Evaluated before the implicit Default Security rules.
• Ideal for setting default actions and ensuring traffic doesn't fall through unintentionally to the implicit defaults without logging.
• Inheritance works bottom-up (Child DG Post -> Parent DG(s) Post -> Shared Post).

Rule Type Use Case Comparison

For the PCNSE exam, make sure you can:

• List the correct order of evaluation for Pre-rules, Local rules, Post-rules, and Default rules.
• Describe the typical use case for each rule type (e.g., Pre for global blocks, Post for cleanup).
• Explain how inheritance affects Pre-rules and Post-rules in a Device Group hierarchy.
• Identify the actions and scope of the two Default Security rules (`intrazone-default` and `interzone-default`).
• Understand why configuring explicit cleanup rules in Post-rules (with logging) is preferred over relying on the default rules.
• Recognize that Local rules can override Pre-rules but are processed before Post-rules.
• Know that this evaluation order applies generally across different policy types (except the Default rules which are Security-specific).

References

• Panorama Admin Guide: Panorama Configuration Hierarchy
• PAN-OS Admin Guide: Policy Rule Management (Includes Pre/Post Rules)
• Knowledge Base: Security Policy Rule Evaluation Order
• PAN-OS Admin Guide: Security Policy Rules (Mentions Default Rules)
• Palo Alto Networks Certified Network Security Engineer (PCNSE) Exam Blueprint (Domain 4)