Panorama Overview

The Panorama™ management server provides centralized monitoring and management of multiple Palo Alto Networks next-generation firewalls and of WildFire appliances and appliance clusters. It provides a single location from which you can oversee all applications, users, and content traversing your network, and then use this knowledge to create application enablement policies that protect and control the network. Using Panorama for centralized policy and firewall management increases operational efficiency in managing and maintaining a distributed network of firewalls. Using Panorama for centralized WildFire appliance and WildFire appliance cluster management increases the number of firewalls a single network supports, provides high availability for fault tolerance, and increases management efficiency.

     Panorama simplifies management of a distributed network of firewalls by centralizing policy creation, log collection, and software/content updates. This is a core concept for managing multiple firewalls efficiently.
    

High-level view of Panorama managing multiple devices.

Key capabilities include:

Centralized Firewall Configuration and Update Management
Centralized Logging and Reporting
Role-Based Access Control

About Panorama

Panorama enables you to effectively configure, manage, and monitor your Palo Alto Networks firewalls with central oversight. The three main areas in which Panorama adds value are:

Centralized configuration and deployment —Use Panorama to pre-stage firewalls and WildFire appliances. Assemble firewalls into groups, create templates for base network/device configuration, and use device groups for policy rules.
Aggregated logging with central oversight —Collect logs from all managed firewalls for centralized analysis, investigation, and reporting.
Distributed administration —Delegate or restrict access to global and local firewall configurations and policies using Role-Based Access Control.

Panorama is available as a virtual appliance or physical M-Series appliances (M-200, M-300, M-500, M-600, M-700).

Panorama Centralized Management Diagram — Figure 1: Panorama Centralized Management with HA

     Understand the three core pillars of Panorama's value: Configuration, Logging, and Administration. These are fundamental to its purpose.
    

Panorama Models

Panorama is available as virtual or physical appliances, supporting various firewall management capacities.

Panorama Virtual Appliance

Deployable on various cloud platforms (Alibaba, AWS, Azure, GCP, OCI) and hypervisors (KVM, Hyper-V, VMware ESXi). It can function as a management server, include local log collection, or be a Dedicated Log Collector.

Deployment Modes for Virtual Appliance:

Panorama mode : Supports local Log Collector with up to 12 virtual logging disks (2TB each, max 24TB single, 48TB HA). Faster report generation. Does not support NFS storage.
Legacy mode (ESXi/vCloud Air only, not recommended for production): Stores logs locally without a Log Collector. Limited storage, can use NFS on ESXi. Once changed from Legacy mode, cannot revert.
Management Only mode : Dedicated management, no local log collection (except config/system logs). Requires Dedicated Log Collectors for traffic/threat logs. Can manage up to 2,500 firewalls with appropriate resources.
Log Collector mode : Functions as a Dedicated Log Collector. No web interface, managed via Panorama server or CLI.

     As a best practice, deploy the Panorama virtual appliance in
     
      Panorama mode
     
     to optimize log storage and report generation. Legacy mode is not recommended for production.

M-Series Appliance

Dedicated hardware (M-200, M-300, M-500, M-600, M-700) for large-scale deployments with high logging rates.

Common M-Series Attributes:

RAID drives for firewall logs, SSD for Panorama/Log Collector logs.
Redundant, hot-swappable power supplies.

M-500/M-600 additional: 10Gbps Eth4/Eth5 interfaces.

M-600/M-700 additional: Can manage up to 5,000 firewalls in Management Only mode.

Deployment Modes for M-Series:

Panorama mode (default): Functions as management server with local Log Collector.
Management Only mode : Dedicated management, no log collection capabilities (requires Dedicated Log Collectors).
Log Collector mode : Functions as a Dedicated Log Collector.

     Know the different Panorama modes (Panorama, Management Only, Log Collector) and their implications for log storage and management capacity. This is crucial for design and troubleshooting.
    

     Changing a Panorama virtual appliance from Legacy mode to another mode is a one-way operation. You cannot revert to Legacy mode.
    

Panorama Appliance Modes and Key Characteristics.

Centralized Firewall Configuration and Update Management

Panorama™ uses device groups and templates to group firewalls into logical sets that require similar configuration. You use device groups and templates to centrally manage all configuration elements, policies, and objects on the managed firewalls. Panorama also enables you to centrally manage licenses, software (PAN-OS®, GlobalProtect™ agent/app), and content updates (Applications, Threats, WildFire®, Antivirus).

     Uncommitted configuration changes in device groups and templates are preserved locally on Panorama if an unforeseen restart occurs. However, for HA configurations, these uncommitted changes do not automatically sync across peers.
    

Context Switch—Firewall or Panorama

The Panorama™ web interface allows toggling between a Panorama-centric view (for central management) and a firewall-centric view (for local configuration) using the Context drop-down. For HA firewalls, icons indicate state (Green: Active, Yellow: Passive/Initiating, Red: Non-functional/Suspended/Tentative).

Total Configuration Size for Panorama

Exceeding supported configuration file sizes can reduce performance.

Panorama mode (all models): Supports up to 80MB total configuration file size (templates, device groups, Panorama-specific).
Management Only mode: Maximum size varies by model/resources (e.g., M-200: 120MB, M-700: 180MB, highly resourced VM: 150MB).

     Be aware of the configuration size limits, especially distinguishing between Panorama mode and Management Only mode. This can affect performance and deployment planning.
    

Panorama Model	Virtual Resources Required	Max Config File Size (Mgmt Only Mode)	Max Config File Size (Panorama Mode)
M-200	N/A	120 MB	80 MB
M-300	N/A	150 MB	80 MB
M-500	N/A	120 MB	80 MB
M-600	N/A	150 MB	80 MB
M-700	N/A	180 MB	80 MB
Panorama Virtual Appliance	16 vCPU, 128GB memory	120 MB	80 MB
Panorama Virtual Appliance	56 vCPU, 256GB memory	150 MB	80 MB

Templates and Template Stacks

Templates configure Network and Device tab settings (interfaces, zones, server profiles, VPNs). Template stacks allow layering multiple templates for a combined configuration, with higher templates in the stack having priority.

Variables can be used in templates and template stacks as placeholders (e.g., IP addresses, Group IDs). Template variables are inherited by stacks and can be overridden.

Settings pushed by templates can be overridden locally on a firewall. Panorama can force template/stack configuration to restore overridden settings.

Template Stacks Example — Figure 2: Template Stacks for hierarchical configuration

     Templates are for Network and Device settings. Template Stacks allow for inheritance and overriding, with higher templates in the stack taking precedence. Variables add flexibility.
    

     Templates/stacks cannot set firewall modes (VPN, multi-vsys, operational modes like FIPS-CC).
    

Template Stack Inheritance and Priority. The firewall inherits idle_timeout=600 from the Data Center Template.

Device Groups

Device groups are logical units of firewalls for policy configuration (Security, NAT, QoS, PBF, Decryption, etc.) and objects. They can be organized hierarchically (up to 4 levels under "Shared").

Device Group Hierarchy

Lower-level groups inherit settings (rules and objects) from higher-level (ancestor) groups. All device groups inherit from the "Shared" location.

In a multiple Panorama plugin deployment, a device group containing firewalls deployed in a particular hypervisor cannot be the child or parent of a device group containing firewalls deployed in a different hypervisor.

Device Group Hypervisor Constraint — Constraints on Device Group Hierarchy with multiple hypervisors

Device Groups are for Policies and Objects. Hierarchies allow for inheritance. "Shared" is the top-most level for common policies/objects.

Device Group Hierarchy and Inheritance Flow.

Device Group Policies

Firewalls evaluate policy rules by layer and type in a specific order. The first matching rule is applied.

Policy Evaluation Order:

Shared pre-rules (Panorama-managed)
Device group pre-rules (Panorama-managed, highest to lowest in hierarchy)
Local firewall rules (Firewall-managed)
Device group post-rules (Panorama-managed, lowest to highest in hierarchy)
Shared post-rules (Panorama-managed)
Default rules (intrazone-default: allow, interzone-default: deny; can be overridden)

Policy Rule Evaluation Order — Visual representation of policy rule evaluation order.

      Memorize the policy evaluation order (Pre-Shared, Pre-DG, Local, Post-DG, Post-Shared, Default). This is critical for PCNSE troubleshooting and design. Pre-rules are evaluated top-down in DG hierarchy, Post-rules bottom-up.
     

      The evaluation order for pre-rules within a device group hierarchy is from highest-level ancestor to lowest-level descendant. For post-rules, it's the reverse: lowest-level descendant to highest-level ancestor.
     

Simplified Policy Evaluation Flowchart.

Device Group Objects

Objects (IPs, URLs, profiles, users, services, apps) can be shared or device group-specific. Rules reference these objects. Objects can be overridden in descendant device groups. By default, descendant object values take precedence, but this can be reversed.

Panorama Commit, Validation, and Preview Operations

To activate changes on Panorama or push to managed devices (firewalls, Log Collectors, WildFire), you can Preview , Validate , or Commit Configuration Changes.

Preview: Shows what changes a commit will activate.
Validate: Checks changes for errors or warnings without activating them. Useful to ensure a commit will succeed.
Commit: Activates changes, making them part of the running configuration.
- Commit to Panorama: Saves changes to Panorama's running configuration.
- Push to Devices: Sends Panorama's running configuration (selected device groups/templates) to managed firewalls. Requires a prior commit to Panorama.

Panorama queues commit requests. The Task Manager shows commit status.

Automated commit recovery is enabled by default. Managed firewalls test configurations pushed from Panorama. If a commit breaks the Panorama-firewall connection, the firewall reverts to its previous running configuration.

      Understand the difference between Commit (to Panorama) and Push (to devices). A Push requires a prior Commit to Panorama. Validation helps prevent commit failures. Automated commit recovery is a safety net.
     

      When pushing configurations, Panorama pushes its *running* configuration, not the candidate configuration. Always commit changes to Panorama first.
     

Centralized Logging and Reporting

Panorama aggregates logs from managed firewalls for network-wide visibility and reporting. It can also forward logs (SNMP, email, syslog, HTTP) to external servers. The cloud-based Strata Logging Service is an alternative or supplement to local Panorama logging.

The Application Command Center (ACC) on Panorama provides unified reporting and monitoring.

Managed Collectors and Collector Groups

Local Log Collector: Runs on the Panorama management server (M-Series or virtual appliance in Panorama mode).
Dedicated Log Collector: M-Series or virtual appliance in Log Collector mode. Managed by Panorama.

A Collector Group is 1 to 16 managed collectors acting as a single logical unit. Logs are distributed across collectors in a group. Log redundancy can be enabled by assigning multiple Log Collectors to a group (requires at least 3 for robust operation to avoid split-brain).

      Log redundancy in a Collector Group requires at least three Log Collectors to be fully operational and avoid issues if one collector goes down. Two collectors are supported but become non-operational if one fails.
     

      In a Collector Group with multiple collectors, all collectors must be the same Panorama model (e.g., all M-600s or all virtual appliances with similar resources).
     

Figure 4: Distributed Log Collection with Dedicated Log Collectors

Figure 5: Example - Typical Log Collector Group Setup

Log Collector Failure Example — Figure 6: Example - When a Log Collector Fails in a Group

Log Forwarding Options

Firewalls can forward logs to:

Panorama (Log Collectors)
Strata Logging Service
Both in parallel
External services (syslog, email, SNMP, HTTP) directly from firewalls or via Panorama.

Log Forwarding to Panorama then External Services — Figure 7: Log Forwarding to Panorama and then to External Services

Figure 8: Log Forwarding to External Services and Panorama in Parallel

graph TD FW[Firewall] -->|Option 1| PanoCollector[Panorama Log Collector / SLS] PanoCollector -->|Option 1| ExtSys[External Syslog/SIEM] FW -->|Option 2| PanoCollector2[Panorama Log Collector / SLS] FW -->|Option 2| ExtSys2[External Syslog/SIEM] subgraph SLS_Option SLS[Strata Logging Service] end PanoCollector -.-> SLS_Option PanoCollector2 -.-> SLS_Option click FW "Firewall generates logs" click PanoCollector "Panorama collects and can forward" click ExtSys "External systems for archiving/alerting"

Log Forwarding Options from Firewalls.

Data Redistribution Using Panorama

Panorama can redistribute data like User-ID mappings (username to IP) and IP-to-tag information to managed firewalls. This ensures consistent policy enforcement and reporting across firewalls that rely on this information.

Instead of direct firewall-to-firewall redistribution, firewalls send data to Panorama, which then redistributes it to other relevant firewalls. This scales better for large networks. Each firewall or Panorama can receive data from up to 100 redistribution points.

      Panorama acts as a central hub for redistributing User-ID and IP-tag information, crucial for consistent enforcement of dynamic policies.
     

sequenceDiagram participant UIDAgent as User-ID Agent participant FW_Source as Source Firewall participant Pano as Panorama participant FW_Dest1 as Destination Firewall 1 participant FW_Dest2 as Destination Firewall 2 UIDAgent->>Pano: Sends User-IP Mappings FW_Source->>Pano: Sends IP-Tag Mappings / Auth Timestamps Pano->>FW_Dest1: Redistributes Mappings/Tags Pano->>FW_Dest2: Redistributes Mappings/Tags

Data Redistribution via Panorama.

Plan Your Panorama Deployment

Key considerations before deploying Panorama:

Management Approach: Centralized policies, updates, logging?
Software Versions: Panorama can manage firewalls running the same or earlier PAN-OS versions.
Multi-vsys Firewalls: Recommended to manage all vsys configurations from Panorama.
Authentication: Between Panorama and managed devices (default certificates or custom PKI).
High Availability: Plan for an active/passive HA pair.
Network Segmentation: For M-Series, consider using dedicated interfaces for management, logging, etc., instead of just MGT.
Logging Solution:
- Estimate storage capacity needed.
- Local Panorama collectors, Dedicated Log Collectors, or Strata Logging Service?
- External forwarding (SIEM)?
- Log redundancy requirements.
Role-Based Access Control: Define administrator privileges.
Device Groups & Hierarchy: Group firewalls logically (function, location, policy).
Policy Layering: Strategy for shared, device-group, and local rules.
Templates & Stacks: Organize based on hardware, location, common network settings.

      Thorough planning is essential. Key areas include HA, logging strategy (including Strata Logging Service consideration), device group/template structure, and RBAC. Compatibility between Panorama and PAN-OS versions on firewalls is crucial.
     

Set Up Panorama

Deploy Panorama as a virtual appliance or a hardware M-Series appliance for centralized management.

Deployment Task Overview

(M-Series only) Rack mount the appliance.
Perform initial configuration (network access).
Register Panorama and Install Licenses.
Install Content and Software Updates for Panorama.
(Recommended) Set up Panorama in High Availability.
Add Firewalls as Managed Devices.
Configure Device Groups, Templates, and Template Stacks.
(Optional) Configure log forwarding.
Monitor Network Activity.

Further setup steps include determining log storage requirements, managing device certificates (for Panorama and Dedicated Log Collectors), and setting up administrative access with authentication.

      Setting up Panorama in a High Availability (HA) configuration is highly recommended for resiliency.
     

Role-Based Access Control (RBAC)

RBAC defines privileges for administrators. Each admin account has a role and authentication method.

Administrative Roles

Define access to Panorama and firewall contexts.

Dynamic Roles (built-in):
- Superuser: Full read-write access.
- Superuser (readonly): Read-only access.
- Panorama administrator: Full access except managing admins/roles and certain system operations.
Admin Role Profiles (custom): Granular control over web interface, CLI, XML API.
- Panorama Profile Type: For roles managing Panorama-wide settings, policies.
- Device Group and Template Profile Type: For roles managing specific device groups/templates. Can be combined with Access Domains. No CLI/XML API access.

      Distinguish between Dynamic Roles (predefined, auto-updated) and Admin Role Profiles (custom, require manual updates for new features). Understand the limitations of the "Panorama administrator" dynamic role and "Device Group and Template" admin role profiles.
     

Access Domains

Control administrative access to specific Device Groups, templates, and the ability to context-switch to managed firewalls. Apply only to admins with "Device Group and Template" roles. Mapped to roles to enforce separation of duties (e.g., regional admins). Can be assigned locally or via external SAML/TACACS+/RADIUS servers using VSAs/attributes.

      Access Domains are only applicable to administrators assigned a "Device Group and Template" custom admin role profile. They do not apply to Dynamic Roles or "Panorama" type custom roles.
     

graph TD Admin[Administrator] -- assigned to --> Role_DG_Template[Admin Role Profile (Device Group & Template Type)] Role_DG_Template -- associated with --> AccessDomain1[Access Domain A (e.g., DG_Sales, Tmpl_Sales)] Role_DG_Template -- associated with --> AccessDomain2[Access Domain B (e.g., DG_Eng, Tmpl_Eng)] AccessDomain1 --> DG_Sales[Device Group: Sales] AccessDomain1 --> Tmpl_Sales[Template: Sales] AccessDomain1 --> FW_Sales[Firewalls in Sales DG (via Context Switch)] AccessDomain2 --> DG_Eng[Device Group: Engineering] AccessDomain2 --> Tmpl_Eng[Template: Engineering] AdminLogin{Admin Logs In} AdminLogin -- Authenticates & Authorizes with Access Domain A --> Can_Manage_Sales[Manages Sales DG/Template] AdminLogin -- Authenticates & Authorizes with Access Domain A --> Cannot_Manage_Eng[Cannot Manage Engineering DG/Template] click Role_DG_Template "Defines *what* actions can be performed" click AccessDomain1 "Defines *where* (which DGs/Templates) actions can be performed"

Relationship between Admin Role Profiles, Access Domains, Device Groups, and Templates.

Administrative Authentication

An authentication profile defines the service (local, external) that validates admin login credentials.

Authentication Methods & Authorization:

Authentication Method	Authorization Method	Description
Local	Local	Credentials and roles/access domains local to Panorama.
SSH Keys	Local	Local accounts, CLI auth via SSH keys. Roles/access domains local.
Certificates	Local	Local accounts, web UI auth via client certs. Roles/access domains local.
External service (MFA, SAML, Kerberos, TACACS+, RADIUS, LDAP)	Local	External server authenticates. Panorama assigns roles/access domains.
External service (SAML, TACACS+, RADIUS)	External service	External server for both authentication and authorization (via VSAs/attributes mapped to Panorama roles/access domains).

Authentication Sequences: A ranked order of authentication profiles. Panorama tries each in sequence until one succeeds.

      Know which external authentication services can provide both authentication AND authorization (SAML, TACACS+, RADIUS). Understand how authentication sequences work.
     

Panorama Knowledge Quiz

1. What are the three main functional areas where Panorama adds value?

Configuration, Software Updates, Hardware Monitoring Logging, Reporting, Threat Prevention Centralized Configuration/Deployment, Aggregated Logging/Reporting, Distributed Administration Policy Management, User-ID, VPN Configuration

2. Which Panorama virtual appliance mode is recommended for optimal log storage and report generation?

Legacy mode Panorama mode Management Only mode Log Collector mode

3. What is the maximum total configuration file size supported by Panorama (M-Series or virtual) when operating in Panorama mode?

80 MB 120 MB 150 MB Unlimited, depends on disk space

4. What are Panorama Templates primarily used for?

Security policy rules and objects Log forwarding profiles Administrator accounts and roles Network and Device tab settings (e.g., interfaces, zones, server profiles)

5. In a Template Stack, if two templates define the same setting with different values, which value is applied?

The value from the template lower in the stack (later) The value from the template higher in the stack (earlier) Panorama merges the values The firewall prompts the administrator to choose

6. What are Panorama Device Groups primarily used for?

Policy rules (Security, NAT, etc.) and objects Network interface configurations Software and content updates schedules Panorama HA settings

7. What is the correct policy evaluation order on a firewall managed by Panorama?

Local, Shared Pre-rules, DG Pre-rules, Shared Post-rules, DG Post-rules, Default Shared Pre-rules, Local, DG Pre-rules, Shared Post-rules, DG Post-rules, Default Shared Pre-rules, DG Pre-rules, Local, DG Post-rules, Shared Post-rules, Default DG Pre-rules, Shared Pre-rules, DG Post-rules, Shared Post-rules, Local, Default

8. Before pushing configuration changes to managed firewalls, what must an administrator do on Panorama?

Validate the configuration on each firewall individually. Commit the changes to Panorama itself. Export the candidate configuration. Reboot Panorama.

9. Which of the following is NOT a mode a Panorama virtual appliance can operate in?

Panorama mode Management Only mode Log Collector mode Firewall Emulation mode

10. What is the minimum recommended number of Log Collectors in a Collector Group to ensure operational continuity and avoid split-brain scenarios if one collector fails?

Three Two One, if log redundancy is enabled Four

11. What type of information can Panorama redistribute to managed firewalls?

Software updates and content files only Threat logs and traffic logs User-ID mappings and IP-tag information Panorama's own system logs

12. Access Domains in Panorama are used to control administrative access to specific Device Groups and Templates. Which type of admin role profile must be used with Access Domains?

Superuser (dynamic role) Device Group and Template (custom admin role profile) Panorama administrator (dynamic role) Panorama (custom admin role profile)

13. Which external authentication services can be configured on Panorama to provide both authentication and authorization for administrators?

LDAP and Kerberos RADIUS and Local Database SAML and Kerberos SAML, TACACS+, and RADIUS

14. If you change a Panorama virtual appliance from Legacy mode to Panorama mode, can you revert it back to Legacy mode?

No, this is a one-way operation. Yes, by using a CLI command. Yes, but only if no logs have been collected in Panorama mode. Yes, by reverting to a previous configuration snapshot.

15. What is the function of the "Automated Commit Recovery" feature in Panorama?

It automatically commits Panorama's candidate configuration every hour. It recovers lost log data after a Log Collector failure. It allows managed firewalls to revert to a previous configuration if a pushed config breaks connectivity to Panorama. It automatically synchronizes uncommitted changes between Panorama HA peers.

16. When configuring Device Group hierarchy, how are post-rules evaluated on a firewall that inherits from multiple levels?

From highest-level ancestor to lowest-level descendant. From lowest-level descendant to highest-level ancestor. All post-rules are merged and evaluated alphabetically. Only post-rules from the direct parent device group are evaluated.

17. Which Panorama component is responsible for providing a unified view of network activity and generating reports from aggregated logs?

The Task Manager The Context Switcher The Log Forwarding Profile The Application Command Center (ACC)

18. Can templates or template stacks be used to set a firewall's operational mode (e.g., FIPS-CC mode)?

No, firewall modes cannot be set via templates or template stacks. Yes, operational mode is a standard Device tab setting configurable by templates. Only if the template variable feature is used. Yes, but only for virtual firewalls.

19. In a Panorama HA setup, if the active Panorama has uncommitted configuration changes and experiences an unexpected restart, what happens to those uncommitted changes regarding the passive peer?

They are automatically synced to the passive peer upon restart. They are lost permanently. They are preserved locally on the restarted Panorama but do not automatically sync to the passive peer. The passive peer takes over and discards any uncommitted changes from the former active.

20. What is a primary benefit of using Dedicated Log Collectors over a local Log Collector on the Panorama management server?

They are easier to initially configure. They enable the Panorama management server to use more resources for management functions and can provide higher logging rates/storage. They do not require licensing. They support direct integration with third-party SIEMs, which local collectors do not.