Firewalls and appliances perform a software integrity check periodically when they are running and when they reboot. If you simultaneously boot up multiple instances of a VM-Series firewall on a host or you enable CPU over-subscription on a VM-Series firewall, the firewall boots in to maintenance mode when a processing delay results in a response timeout during the integrity check. If your firewall goes in to maintenance mode, please check the error and warnings in the fips.log file.

A reboot always occurs during an upgrade so if you enabled CPU over-subscription on your VM-Series firewall, consider upgrading your firewall during a maintenance window.

Up to 100,000 daily summary logs can be processed for Scheduled and Run Now custom reports (MonitorManage Custom Reports) when configured for the last calendar day. This can result in the generated report not displaying all relevant log data generated in the last calendar day.

When a Certificate Profile (Device > Certificate Management > Certificate Profile) is configured to Block session if certificate status cannot be retrieved within timeout, the firewall allows client certificate validation to go through even if the CRL Distribution Point or OCSP Responder is unreachable.

Workaround: You must also enable Block session if certificate status is unknown to ensure Block session if certificate status cannot be retrieved within timeout is effective.

On the Panorama management server, forwarded logs (MonitorLogsTraffic) do not display if the latency between the Log Collectors exceeds 10ms when the Log Collectors in a Collector Group (PanoramaCollector Groups) are located on different Local Area Networks (LANs).

Workaround: When deploying your Log Collectors in a Collector Group, ensure they are both deployed on the same LAN or that the latency between Log Collectors in the Collector Group does not exceed 10ms.

On the Panorama management server, scheduled email PDF reports (MonitorPDF Reports) fail if a GIF image is used in the header of footer.

You must Contact Palo Alto Networks Support before you downgrade a Panorama management server, PA-7000 Series firewall, and PA-5200 Series firewall to avoid commit failures on successful downgrade from PAN-OS 9.1 to PAN-OS 9.0.

On the Panorama management server, scheduled content updates (PanoramaDevice DeploymentDynamic Updates) for managed VM-Series firewalls configured to Download Only cause commit failures for the VM-Series firewalls.

Workaround: Configure scheduled content updates for VM-Series firewalls to Download and Install.

If an admin user password is changed but no commit is performed afterward, the new password does not persistent after a reboot. Instead, the admin user can still use the old password to log in, and the calculation of expiry days is incorrect based on the password change timestamp in the database.

After adding a new virtual system from the CLI, you must log out and log back in to see the new virtual system within the CLI.

After upgrading the Panorama management server to PAN-OS 8.1 or a later release, predefined reports do not display a list of top attackers.

Workaround: Create new threat summary reports (MonitorPDF ReportsManage PDF Summary) containing the top attackers to mimic the predefined reports.

On Panorama™, the number of Apps Seen on a Security policy rule depends on whether you created the rule in a Shared context or in the context of a particular device group.

For rules created in the Shared context, Apps Seen displays the total number of unique applications seen on each rule in all of the device groups in the Shared context so a Shared context that includes two device groups—DG1 and DG2—displays the combined number of unique applications seen on the rule in both groups. For example, if DG1 saw two unique applications on the rule and DG2 saw eight unique applications on the rule, Apps Seen shows ten applications seen on the rule, which is the aggregate number of unique applications seen in both device groups; it does not show the number of unique applications in each individual group.

For rules created in a specific device group context, Apps Seen displays the total number of unique applications seen on each rule in that particular device group. For example, if DG2 saw eight unique applications on a rule, Apps Seen shows eight applications seen on the rule.

To get an accurate count of the Apps Seen on a rule for a device group, change the context to the device group in which you created the rule.

After an HA firewall fails over to its HA peer, sessions established before the failover might not undergo the following actions in a reliable manner:

(Affects only PA-7000 Series firewalls that do not use second-generation PA-7050-SMC-B or PA-7080-SMC-B Switch Management Cards) When you deploy the firewall in a network that uses Dynamic IP and Port (DIPP) NAT translation with PPTP, client systems are limited to using a translated IP address-and-port pair for only one connection. This issue occurs because the PPTP protocol uses a TCP signaling (control) protocol that exchanges data using Generic Routing Encapsulation (GRE) version 1 and the hardware cannot correlate the call-id in the GRE version 1 header with the correct dataplane (the one that owns the predict session of GRE). This issue occurs even if you configure the Dynamic IP and Port (DIPP) NAT Oversubscription Rate to allow multiple connections (DeviceSetupSessionSession SettingsNAT Oversubscription).

Workaround: Upgrade to a second-generation SMC-B card.

The commit all job is executed from Panorama to the firewall only if the newly added firewall is running PAN-OS 8.1 or a later release with Auto Push on 1st Connect enabled.

When performing destination NAT to a translated address that is Dynamic IP (with session distribution), the firewall does not remove duplicate IP addresses from the list of destination IP addresses before the firewall distributes sessions. The firewall distributes sessions to the duplicate addresses in the same way it distributes sessions to non-duplicate addresses.

If you use the Panorama management server to manage the configuration of firewalls in an HA active/active configuration, you must set the Device ID for each firewall in the HA pair before you upgrade Panorama. If you upgrade without setting the Device IDs (which determine which peer is the active-primary peer), you cannot commit configuration changes to Panorama.

You cannot form an HA pair of Panorama management servers on AWS instances when the management interface on one HA peer is assigned an Elastic Public IP address or when the HA peers are in different Virtual Private Clouds (VPCs).