Panorama and PAN-OS Trivia Collection
Assigning Firewalls to Panorama Device Groups
-
Core Concept:
Assigning a firewall to a Device Group determines which Policies and Objects are pushed, while assignment to a Template Stack determines Network and Device configurations.
-
Critical Limitation:
A firewall can belong to
only one Device Group
and be assigned
only one Template Stack
at any given time.
-
Best Practice - Onboarding:
It's common to assign newly managed firewalls to a dedicated "staging" or "onboarding" Device Group and Template Stack initially for basic configuration and verification before moving to production groups.
-
Important Caveat:
Moving a firewall between Device Groups can result in a significant configuration change being pushed. This should be done during a planned maintenance window and thoroughly tested.
-
PCNSE Focus:
Understand that firewalls must be assigned to a Device Group for policies/objects and typically receive Network/Device settings via a Template Stack assigned to their Device Group. Know the impact of moving devices and the "one DG, one Stack" rule.
-
Gotcha - Configuration Overwrite:
Pushing from Panorama will overwrite most local configurations on the firewall.
-
Gotcha - Accidental Misassignment:
Assigning to the wrong group/stack can push incorrect configurations, potentially causing outages.
Panorama Automatic Commit Recovery
-
Purpose:
Prevents losing management connectivity between a firewall and Panorama due to a bad configuration push from Panorama.
-
Mechanism:
If a firewall loses Panorama connectivity shortly after a config push, it automatically reverts to its previous known-good configuration and reboots.
-
Timer:
This recovery check happens within an approximate
10-minute window
after the new configuration is active on the firewall.
-
Scope Limitation:
Recovery ONLY triggers on loss of Panorama connectivity. It does NOT revert commits that break user traffic or other services if the firewall can still talk to Panorama.
-
Impact:
The recovery process
always involves a firewall reboot
, causing a temporary outage for transit traffic.
-
Not Covered:
This feature does not apply to configuration changes committed locally on the firewall's GUI/CLI.
-
PCNSE Focus:
Understand its purpose, trigger (loss of Panorama connectivity within ~10 mins), result (revert + reboot), and that it's an automatic feature for Panorama-initiated commits, not local commits.
-
Quiz Trivia - Initiating Event:
The recovery timer starts after the firewall successfully applies the configuration received from a Panorama push.
-
Quiz Trivia - Incorrect Cause for Recovery:
A NAT policy change causing user application issues but not losing Panorama connectivity will NOT trigger recovery.
-
Quiz Trivia - Feature Enablement:
It's an inherent, automatic behavior, not a setting to be explicitly enabled.
-
Quiz Trivia - Identifying Problematic Config:
If recovery occurs, the problematic configuration is still present as the candidate or last committed configuration on the Panorama server.
Panorama Commit Type Options
-
Candidate Configuration:
Changes being worked on, not active until committed.
-
Running Configuration:
Active configuration on Panorama or a managed device.
-
"Commit" (Local Panorama Commit):
Validates and saves the candidate config as Panorama's running config. Does NOT push to firewalls. Creates a new configuration version on Panorama.
-
"Commit All" (Commit and Push):
Performs a local Panorama commit AND then initiates a push of relevant configurations (Device Group & Template) to managed firewalls. This is the most direct way.
-
Push Scope in "Commit All":
Options include "Commit and Push" (all applicable changes), "Push Device Group Config", and "Push Template Config".
-
"Push to Devices":
Pushes Panorama's *already committed running configuration* to selected devices. Does NOT perform a local commit first. Used for retries or selective pushes.
-
"Load Configuration Version":
Reverts Panorama's *candidate configuration* to a previously committed version. Requires a subsequent "Commit" or "Commit All" to activate.
-
Best Practice - Comments:
Always add clear, concise comments describing changes made during commits.
-
Best Practice - Validate:
Use "Validate Commit" frequently to catch errors early.
-
Gotcha - Commit Failures:
Can occur due to syntax errors, dependency issues, licensing, connectivity, or device limitations. Check Task Manager.
-
PCNSE Focus:
Differentiate Commit, Commit All, Push to Devices, and Load Configuration Version. Understand their scope and impact on Panorama and firewalls. Know where to check status (Task Manager).
Panorama Commit Types and Scheduling
-
"Commit" (or Commit to Panorama):
Saves candidate config to running config ONLY on Panorama server. No impact on firewalls.
-
"Commit and Push":
Commits to Panorama, then merges and pushes the config to selected firewalls. This *does* impact firewalls.
-
Commit Scope:
Can commit "All Changes," changes by "Selected Administrators," or "Changes in Selected Device Groups and Templates."
-
Push Scope Selection:
Appears after a successful "Commit and Push" to Panorama, allowing selection of target Device Groups/Firewalls.
-
Validation & Preview:
Always "Validate Commit" and "Preview Changes" before a "Commit and Push."
-
Primary Use of Scheduling:
For automatically checking, downloading, and installing Dynamic Content Updates (Apps & Threats, Antivirus, etc.).
-
Content Update Schedules:
Configured under
Device > Dynamic Updates
within a Template. Panorama can also be scheduled to download updates via
Panorama > Device Deployment > Dynamic Updates
.
-
Scheduled Configuration Push:
Found under
Panorama > Scheduled Config Push
. Allows scheduling a "Commit and Push" for specific Device Groups/Templates, often for off-peak hours. Use cautiously.
-
Gotcha - Overwriting Local Changes:
A Panorama push overwrites most configurations made locally on the firewall.
-
PCNSE Focus:
Differentiate "Commit" vs. "Commit and Push," understand commit/push scopes, validation/preview tools, and that scheduling is primarily for Content Updates (configured via Templates).
-
Quiz Trivia - Push Scope Selection:
Appears during "Commit and Push" after the initial commit to Panorama succeeds.
-
Quiz Trivia - Content Update Schedule Location:
Typically configured within a Template under
Device > Dynamic Updates
.
Panorama Templates & Template Stacks
-
Templates:
Reusable blocks for
Network
and
Device
tab configurations (e.g., interfaces, zones, server profiles, management settings).
-
Template Stacks:
Ordered collections of Templates. Assigned to Device Groups to apply combined configurations. Settings in later templates in a stack override earlier ones.
-
Hierarchy Note:
Settings pushed from Panorama (Device Groups, Templates/Stacks) generally override local firewall configurations.
-
Network Tab Components in Templates:
Interfaces (Physical, Tunnel, AE, VLAN, Loopback), Zones, VLANs, Virtual Routers (including Static Routes & Dynamic Routing Protocols), IPSec Tunnels, GlobalProtect Portal/Gateway, Network Profiles (Interface Mgmt, LLDP, QoS Interface bandwidth), DHCP, DNS Proxy, NetFlow.
-
Device Tab Components in Templates:
Management Interface Settings, Services (DNS, NTP, Service Routes), Session Settings, HA, Log Settings, Server Profiles (Syslog, Email, SNMP, RADIUS, LDAP, etc.), Certificate Management (Profiles, SSL/TLS Service Profiles), Schedules, Dynamic Update schedules.
-
NOT in Templates:
Policies (Security, NAT, QoS rules, PBF, Decryption, etc.) and most Objects (Addresses, Services, Applications, Security Profiles, Log Forwarding Profiles). These are in Device Groups.
-
PCNSE 4.1.1 Focus:
Identify components configured in a template (Network and Device settings).
-
Quiz Trivia - Primary Config Tabs in Templates:
Network and Device.
-
Quiz Trivia - Example Component in Template:
Interface Management Profile.
-
Quiz Trivia - Example Component NOT in Template:
NAT Policy Rule.
-
Quiz Trivia - Applying Multiple Templates:
Use a Template Stack assigned to a Device Group.
-
Quiz Trivia - Static Routes:
Can be configured within a Virtual Router setting in a Template.
Panorama Configuration Backups
-
Importance:
Crucial for recovery from hardware/software failures, disaster recovery, and testing.
-
Running Configuration Snapshot:
Captures the currently active configuration on Panorama. Most common for recovery.
-
Candidate Configuration Snapshot:
Captures the configuration being edited (before commit).
-
Manual Backup:
Via
Panorama > Setup > Operations
. Can save snapshots locally on Panorama or export them as XML.
-
Scheduled Configuration Export (Recommended):
Via
Panorama > Scheduled Config Export
. Automatically exports running config to a remote SCP (preferred) or FTP server.
-
Tech Support File (TSF):
Contains running config plus logs and diagnostics. Primarily for support, not a primary backup method.
-
Best Practice:
Schedule regular exports to an external, secure SCP/FTP server. Store backups off-box. Test restore procedures.
-
Gotcha - Local Snapshots Only:
Insufficient for full disaster recovery if Panorama itself fails. Always export externally.
-
Gotcha - Restore Version Compatibility:
Generally restore to the same PAN-OS version.
-
What's NOT Backed Up:
Firewall runtime data, logs on Panorama, software images/content files.
-
PCNSE Focus:
Importance of backups, running vs. candidate snapshots, manual vs. scheduled exports (SCP/FTP preferred), storing off-box, version compatibility for restore.
-
Quiz Trivia - Scheduled Backup Location:
Panorama > Scheduled Config Export
.
-
Quiz Trivia - Preferred Protocol for Scheduled Export:
SCP for security.
Components Configured in Panorama Device Groups
-
Primary Purpose:
Manage
Policies
(Security, NAT, QoS, PBF, Decryption, Authentication, App Override, DoS Protection) and
Objects
(Addresses, Services, Applications, Security Profiles, Custom Objects, Log Forwarding Profiles).
-
Policies Tab:
Defines rule-sets for various policy types, including Pre-rules and Post-rules.
-
Objects Tab:
Defines reusable building blocks referenced by policy rules (e.g., Address Groups, Service Groups, Antivirus Profiles, URL Filtering Profiles).
-
NOT in Device Groups:
Network settings (Interfaces, Zones, Virtual Routers, VLANs, IPSec Tunnels, GP Portal/Gateway setup) and Device settings (Management interface, HA, Server Profiles like Syslog/RADIUS). These are in Templates.
-
PCNSE Focus:
Identify that Device Groups manage Policies and Objects. Differentiate from Template components.
-
Quiz Trivia - Main Config Tabs in DGs:
Policies and Objects.
-
Quiz Trivia - Example in DG:
Security Policy Rule.
-
Quiz Trivia - Example NOT in DG (but in Template):
Zone Definition.
-
Quiz Trivia - Antivirus Profile Location:
Device Group under Objects (Security Profiles).
-
Quiz Trivia - PBF Rules Location:
Device Group (Policies Tab).
Panorama Device Group Hierarchies
-
Hierarchy:
Device Groups can be organized in a tree-like structure (up to
4 levels deep
below 'Shared').
-
Inheritance:
Child Device Groups inherit all policies and objects from parent Device Groups and the 'Shared' scope.
-
Membership:
Firewalls can only be members of
one Device Group
at the lowest level of their branch.
-
Pre-rules:
Evaluated FIRST. Used for global blocks, universal infrastructure allows, or high-priority policies.
-
Post-rules:
Evaluated LAST (before default rules). Used for cleanup/default deny rules or broad allow rules.
-
Firewall Policy Evaluation Order:
Shared Pre-rules -> Parent DG Pre-rules (top-down) -> Child DG Pre-rules -> Local Firewall Rules -> Child DG Post-rules -> Parent DG Post-rules (bottom-up) -> Shared Post-rules -> Default Security Rules.
-
Benefit - Reusability:
Define common policies once at a higher level.
-
Gotcha - Object Scope:
Objects generally need to be defined at the same level or higher than the policy referencing them.
-
PCNSE 4.2.1 Focus:
Understand hierarchy purpose, inheritance, Pre/Post rules, overall evaluation order, and benefits.
-
Quiz Trivia - Max Hierarchy Depth:
4 levels below Shared.
-
Quiz Trivia - Object Override:
An object defined in a Child DG overrides one with the same name from a Parent DG for policies in that Child DG.
-
Quiz Trivia - Typical Use of Post-Rules:
For default deny / cleanup rules that should be evaluated last.
Differentiating Pre-Rules, Local Rules, Default Rules, and Post-Rules
-
Overall Evaluation Order on Firewall:
(1) Shared Pre-rules -> (2) Parent DG Pre-rules -> (3) Child DG Pre-rules -> (4)
Local Firewall Rules
-> (5) Child DG Post-rules -> (6) Parent DG Post-rules -> (7) Shared Post-rules -> (8)
Default Security Rules
(Security Policy only). The first rule matched wins.
-
Pre-Rules (Panorama):
Evaluated FIRST. Use for global enforcement, universal blocks (e.g., malicious IPs via EDL in Shared Pre-rules), or universal infrastructure allows.
-
Local Firewall Rules:
Evaluated in the MIDDLE (after all Pre-rules, before all Post-rules). Use for temporary troubleshooting, device-specific exceptions (with caution). Generally discouraged in Panorama environments.
-
Default Security Rules (Security Policy Only):
Evaluated ABSOLUTE LAST.
-
intrazone-default
: Source and destination zones are the SAME. Action:
Allow
.
-
interzone-default
: Source and destination zones are DIFFERENT. Action:
Deny
.
-
Logging is disabled by default for these. Best practice is to create explicit cleanup rules in Post-rules with logging.
-
Post-Rules (Panorama):
Evaluated LATE (after Local rules, before Default Security rules). Use for cleanup rules (explicit "deny any any" with logging), or broad/fallback allow rules.
-
PCNSE Focus:
Know the exact order of evaluation, typical use cases for each, how inheritance works, and the specifics of the Default Security rules (actions, scope, logging).
-
Quiz Trivia -
interzone-default
Action:
Deny.
-
Quiz Trivia - Local Rule vs. DG Post-Rule:
A DG Post-Rule "Deny" will block traffic allowed by a Local Firewall "Allow" rule because Post-rules are evaluated after Local rules.
-
Quiz Trivia - Logging Default Rules:
Best practice is to enable logging on an explicit "deny any any" Post-rule because default rules do not log by default.
Checking Firewall Health and Status from Panorama (Version 11.0)
-
Primary Overview:
Panorama > Managed Devices > Summary
. Shows connection status, shared policy status, device config status, content/PAN-OS versions, HA state.
-
Resource Monitoring:
Panorama > Managed Devices > Health
. Displays near real-time and historical metrics like CPU, memory, session count, and disk usage for selected firewalls.
-
Key Connection Statuses:
-
Connected:
Healthy management connection.
-
Disconnected:
No management connection. Causes: network issue, device off, certificate issue.
-
Connection status mismatch:
Connected, but potential secure channel issue.
-
Key Config Sync Statuses:
-
In sync:
Firewall config matches Panorama's intended config for that scope (DG/Template).
-
Out of sync:
Firewall config differs. Causes: failed push, local firewall changes. Fix: Commit & Push from Panorama.
-
Pending:
Panorama has unpushed changes committed locally for this device. Fix: Commit & Push or Push to Devices.
-
Commit Required:
Panorama has uncommitted changes affecting this device. Fix: Commit on Panorama.
-
Dashboard Widgets:
Can show summaries of managed devices, sync status, content/software versions, and HA status.
-
Task Manager (
Panorama > Task Manager
):
Shows status (Success, Fail, Pending) of recent Panorama jobs like commits and pushes. Essential for diagnosing failures.
-
System Logs:
Check Panorama's local System logs and forwarded firewall System logs for detailed troubleshooting.
-
Best Practice - Disconnects:
Treat disconnected devices as high priority.
-
Gotcha - Status Update Latency:
There can be a slight delay in status updates in Panorama.
-
PCNSE Focus:
Know where to find Summary and Health views, understand key status indicators (Connected, Disconnected, In sync, Out of sync, Pending, Commit Required), and the role of Task Manager and System Logs.