PAN-OS: Panorama Device Group Hierarchies & Policy Evaluation (PCNSE 4.2.1)

Introduction: Organizing Policies and Objects

In Panorama, Device Groups are fundamental organizational containers used to manage Policies (Security, NAT, QoS, Decryption, etc.) and related Objects (Addresses, Services, Security Profiles, etc.) that are pushed to groups of managed firewalls.

Just as firewalls often have varying network configurations (handled by Templates/Template Stacks), they also frequently require different sets of policies based on their function, location, or trust level. Panorama allows administrators to create a hierarchy of Device Groups to manage these policy sets efficiently through inheritance.

Understanding Device Group hierarchies and the resulting policy evaluation order on the firewall is crucial for scalable, maintainable, and logically structured policy management in Panorama.

Device Group Hierarchy Concept

Parent-Child Relationships

Device Groups can be organized into a tree-like structure with parent-child relationships, extending up to four levels deep below the top-level 'Shared' scope (i.e., Shared -> DG1 -> DG1.1 -> DG1.1.1 -> DG1.1.1.1).
A child Device Group inherits all policies and objects configured in its parent Device Group (and any ancestors up the chain, including 'Shared').
Firewalls can only be members of one Device Group at the lowest level of their respective hierarchy branch. This Device Group is often referred to as the firewall's "primary" or "target" Device Group.

Configuration Inheritance for Policies and Objects

When Panorama pushes the configuration to a firewall belonging to a child Device Group, it merges the policies and objects from:
1. The 'Shared' scope (if used).
2. The top-level parent Device Group in that firewall's hierarchy.
3. Any intermediate parent Device Groups in that firewall's hierarchy.
4. The child Device Group the firewall is directly a member of.
This allows for defining common, base policies and objects at higher levels (e.g., parent DGs or Shared) and more specific policies/objects at lower, more granular levels (child DGs).
Object Overriding: If an object (e.g., Address Object, Service Object) with the exact same name exists at multiple levels of the hierarchy that apply to a firewall, the definition from the lowest level (most specific, closest to the firewall's own Device Group) takes precedence and overrides definitions from higher levels for that firewall.

      graph TD
          Shared[Shared Scope\nGlobal Objects/Policies] --> DG_Corp(DG: Corporate-Base\nCommon Policies/Objects)
          DG_Corp --> DG_Region(DG: Region-NA\nNA-Specific Policies)
          DG_Region --> DG_Branch(DG: Branch-Type-A\nBranch-Specific Policies)
          DG_Region --> DG_DC(DG: DC-Primary\nDC-Specific Policies)
          DG_Branch --> FW1[FW1 - Branch A]
          DG_Branch --> FW2[FW2 - Branch A]
          DG_DC --> FW3[FW3 - DC Primary]

          style Shared fill:#eaf2f8,stroke:#aed6f1,stroke-width:2px
          style DG_Corp fill:#d5f5e3,stroke:#58d68d,stroke-width:1px
          style DG_Region fill:#d5f5e3,stroke:#58d68d,stroke-width:1px
          style DG_Branch fill:#fdebd0,stroke:#f5b041,stroke-width:1px
          style DG_DC fill:#fdebd0,stroke:#f5b041,stroke-width:1px
          style FW1 fill:#e9ecef,stroke:#adb5bd
          style FW2 fill:#e9ecef,stroke:#adb5bd
          style FW3 fill:#e9ecef,stroke:#adb5bd

          linkStyle 0 stroke-dasharray: 5 5
          linkStyle 1 stroke-width:2px
          linkStyle 2 stroke-width:2px
          linkStyle 3 stroke-width:2px
          linkStyle 4 stroke-width:2px

Example Device Group Hierarchy. FW1 inherits policies and objects from Shared, Corporate-Base, Region-NA, and Branch-Type-A.

Policy Evaluation Order (Pre- and Post-Rules)

Within each Device Group (including 'Shared'), policies are further divided into Pre-rules and Post-rules . These designations, along with the Device Group hierarchy and any local firewall rules, dictate the final sequence in which security policies are evaluated by the firewall.

Pre-rules: Evaluated first within their respective scope (Shared, Parent DG, Child DG). They are typically used for global block rules, universal allow rules for infrastructure services, or policies that must take precedence over more specific rules defined later in the evaluation sequence.
Post-rules: Evaluated last within their respective scope. They are typically used for default deny/cleanup rules or broad allow rules that should only match if no specific rules higher up in the full evaluation order (including local firewall rules and rules from the firewall's own Device Group) match.

Comprehensive Firewall Policy Evaluation Order:

When Panorama pushes the merged policy configuration, the firewall evaluates Security Policy rules in this strict order:

Panorama 'Shared' Scope Pre-rules
Parent Device Group(s) Pre-rules (Evaluated top-down in the hierarchy, from the highest-level parent DG down to the parent DG just above the firewall's own DG)
(Local Firewall Pre-rules - if manually configured on the firewall before its own DG's rule block. This is generally not a Panorama-managed practice and is discouraged.)
Child Device Group Pre-rules (Pre-rules from the specific Device Group the firewall is a direct member of)
Child Device Group "Local" Rules (These are the main body of rules, not designated as Pre or Post, within the Device Group the firewall is a direct member of. They are evaluated top-down as they appear in that Device Group's rulebase.)
(Local Firewall Rules - if manually configured directly on the firewall's GUI, their evaluation point relative to the Child DG Local Rules depends on where they were inserted by the local admin. This practice is generally discouraged in a Panorama-managed environment for maintaining consistency and can be overridden by Panorama pushes.)
Child Device Group Post-rules (Post-rules from the specific Device Group the firewall is a direct member of)
(Local Firewall Post-rules - if manually configured on the firewall after its own DG's rule block. Also discouraged.)
Parent Device Group(s) Post-rules (Evaluated bottom-up in the hierarchy, from the parent DG just above the firewall's own DG up to the highest-level parent DG)
Panorama 'Shared' Scope Post-rules
Firewall Default Security Rules (e.g., intrazone-default which defaults to 'allow', and interzone-default which defaults to 'deny'. These apply only if no explicit rule above has matched the traffic.)

This explicit order ensures that broader, inherited rules (especially cleanup rules in Post-rules) don't inadvertently override more specific rules defined closer to the device (Child DG or potentially Local FW rules if permitted). Template Stacks, which manage Network and Device settings, operate distinctly from this policy evaluation order.

Policy Reusability and Inheritance: Define common security policies (e.g., block known bad IPs, allow DNS) once at a higher level (parent DG or Shared) and have them automatically apply to all child groups.
Role-Based Administration: Different administrative teams can potentially manage policies within specific device groups relevant to their responsibilities (though Panorama RBAC is the primary tool for admin control).
Scalability: Easily apply baseline policies to hundreds of firewalls by placing them in appropriate device groups within the hierarchy.
Logical Organization: Structure policies based on geography, function (e.g., Datacenter, Branch, Perimeter), or compliance requirements (e.g., PCI-DSS zone firewalls).
Simplified Changes: Update a common policy once in a parent DG, and the change propagates to all inheriting child DGs and their firewalls upon push.

Best Practices

Plan Your Hierarchy: Design the hierarchy logically based on your organization's structure, security requirements, and administrative domains before creating groups. Consider geography, function, risk level, etc.
Use Shared Sparingly: Reserve the 'Shared' scope for truly global objects and potentially universal block/allow policies that apply absolutely everywhere. Overuse can make troubleshooting harder.
Leverage Inheritance: Place common policies and objects at the highest appropriate level in the hierarchy to maximize reuse and minimize duplication.
Use Pre/Post Rules Intentionally: Understand the evaluation order. Use Pre-rules for global enforcement/blocks and Post-rules for cleanup/default actions. Place most standard security policies between Pre and Post rules within the appropriate DG level (these become the "Child Device Group Local Rules" in the evaluation order).
Consistent Naming Conventions: Use clear, descriptive names for Device Groups that reflect their position in the hierarchy and purpose (e.g., `DG-NA-Branches`, `DG-EU-Datacenters`).
Combine with Templates/Stacks: Use Device Groups primarily for Policies/Objects and Template Stacks (assigned to DGs or individual devices) for Network/Device settings. These are separate but complementary.
Limit Hierarchy Depth: While four levels below Shared are possible, overly deep hierarchies can become complex to manage and troubleshoot. Aim for clarity.
Regular Audits: Periodically review the hierarchy, group membership, and inherited policies to ensure they remain accurate and effective.

Caveats and Gotchas

Complexity: Deep or poorly planned hierarchies can become difficult to understand, making it hard to determine the exact policy set applied to a firewall.
Accidental Overrides/Shadowing: Misplacing rules (e.g., a broad 'allow' in a high-level Pre-rule) can unintentionally override or shadow specific rules defined later in the evaluation sequence.
Troubleshooting: Diagnosing policy issues requires understanding the full inheritance path (Shared -> Parent DGs -> Child DG) and the complete Pre/Post rule evaluation order, including any local rules and default rules. Panorama's policy lookup tools are helpful.
Object Scope and Overriding: An object defined in a child DG cannot typically be referenced by a policy in a parent DG. Objects generally need to be defined at the same level or higher than the policy referencing them. If an object with the same name is defined at multiple levels, the lowest-level definition overrides higher ones for that DG's context.
Moving Devices: Moving a firewall between device groups can significantly change its applied policy set. Plan and test carefully.

PCNSE Exam Focus

For the PCNSE exam, concerning Device Group Hierarchies:

Understand the purpose of Device Groups: Managing Policies and Objects.
Know that Device Groups can be arranged in a hierarchy (up to 4 levels below Shared).
Understand the concept of inheritance : Child groups inherit policies/objects from parents and Shared. Object definitions at lower levels override those from higher levels if names are identical.
Know the difference between Pre-rules (evaluated first within their scope) and Post-rules (evaluated last within their scope).
Understand the overall policy evaluation order on the firewall, including the interaction between Shared, Parent DGs, Child DG, Local Firewall rules, and Default rules.
Differentiate Device Groups (Policies/Objects) from Templates/Stacks (Network/Device settings). They manage different aspects of the configuration.
Recognize the benefits of using hierarchies for organization and scalability of policies.