Determine the management approach. Do you plan to use Panorama to centrally configure and manage the policies, to centrally administer software, content and license updates, and/or centralize logging and reporting across the managed firewalls in the network?
If you already deployed and configured the Palo Alto Networks firewalls on your network, determine whether to transition the firewalls to centralized management. This process requires a migration of all configuration and policies from your firewalls to Panorama. For details, see
Transition a Firewall to Panorama Management.
Verify the Panorama and firewall software versions. Panorama can manage firewalls running PAN-OS versions that match the Panorama version or are earlier than the Panorama version. The exception is that Panorama 6.1 and later versions cannot push configurations to firewalls running PAN-OS 6.0.0 through 6.0.3. Panorama cannot manage firewalls that run a later PAN-OS version than the Panorama version. For example, Panorama 6.0 cannot manage firewalls running PAN-OS 7.0. For versions within the same feature release, although Panorama can manage firewalls running a later version of PAN-OS, we recommend that Panorama run the same version or a later version. For example, if Panorama runs 7.0.3, it is recommended that all managed firewalls run PAN-OS 7.0.3 or earlier versions.
Plan to use the same URL filtering database (BrightCloud or PAN-DB) across all managed firewalls. If some firewalls are using the BrightCloud database and others are using PAN-DB, Panorama can only manage security rules for one or the other URL filtering database. URL filtering rules for the other database must be managed locally on the firewalls that use that database.
Plan to use Panorama in a high availability configuration; set it up as an active/passive high availability pair. See
Panorama High Availability.
Estimate the log storage capacity your network needs to meet security and compliance requirements. Consider such factors as the network topology, number of firewalls sending logs, type of log traffic (for example, URL Filtering and Threat logs versus Traffic logs), the rate at which firewalls generate logs, and the number of days for which you want to store logs on Panorama. For details, see
Determine Panorama Log Storage Requirements.
For meaningful reports on network activity, plan a logging solution:
Do you need to forward logs to a syslog server, in addition to Panorama?
If you need a long-term storage solution, do you have a Security Information and Event Management (SIEM) solution, such as Splunk or ArcSight, to which you can forward logs?
Do you need redundancy in logging?
With Panorama virtual appliances in HA, each peer can log to its virtual disk. The managed firewalls can send logs to both peers in the HA pair. This option provides redundancy in logging. Panorama running on VMware vCloud Air or ESXi 5.5 and later versions can support a virtual disk of up to 8TB. Earlier versions of the ESXi server support a virtual disk of up to 2TB.
If you use Dedicated Log Collectors (M-Series appliances in Log Collector mode), you can enable redundancy to ensure that no logs are lost if any one Log Collector in the Collector Group becomes unavailable. Each log will have two copies and each copy will reside on a different Log Collector.
Will you log to a Network File System (NFS)? Only the Panorama virtual appliance supports NFS. Consider using NFS if Panorama requires more than 8TB of log storage capacity and but doesn’t manage Dedicated Log Collectors. If using NFS, note that the managed firewalls can send logs only to the primary peer in the HA pair, and only the active-primary Panorama is mounted to the NFS and can write to it.
If your logging solution includes M-Series appliances, by default they use the management (MGT) interface for configuration, log collection, and Collector Group communication. However, it is a best practice to use the Eth1 or Eth2 interfaces for log collection and Collector Group communication to improve security, control traffic prioritization, performance, and scalability. Determine whether your solution would benefit from using separate interfaces for these functions. For details, see
Set Up the M-Series Appliance.
Determine what access privileges, roles, and permissions administrators require to access to the managed firewalls and Panorama. See
Set Up Administrative Access to Panorama.
Plan the required
Device Groups. Consider whether to group firewalls based on function, security policy, geographic location, or network segmentation. An example of a function-based device group is one that contains all the firewalls that a Research and Development team uses. Consider whether to create smaller device groups based on commonality, larger device groups to scale more easily, or a
Device Group Hierarchy to simplify complex layers of administration.
Plan a layering strategy for administering policies. Consider how firewalls inherit and evaluate policy rules within the
Device Group Hierarchy, and how to best implement shared rules, device-group rules, and firewall-specific rules to meet your network needs. For visibility and centralized policy management, consider using Panorama for administering rules even if you need firewall-specific exceptions for shared or device group rules. If necessary, you can
Push a Policy Rule to a Subset of Firewalls within a device group.
Plan the organization of your firewalls based on how they inherit network configuration settings from
Templates and Template Stacks. For example, consider assigning firewalls to templates based on hardware models, geographic proximity, and similar network needs for time zones, a DNS server, and interface settings.