Known Issues in Panorama Plugin for Azure 2.0.0

In addition to the following known issues in the Panorama plugin for Azure version 2.0.0, refer to the PAN-OS Release Notes to learn about the known issues for PAN-OS 8.1.x or PAN-OS 9.0.x:

PLUG-3797

When upgrading the Panorama plugin for Azure on peers configured as an HA pair, if you upgrade the plugin on the secondary peer first and the peer becomes active, the primary (now passive) cannot function as an HA peer.
Workaround
—When upgrading the Panorama plugin for Azure on peers that are configured as an HA pair, you must install the plugin on the primary peer
first
and commit your changes
immediately
, and then install the same plugin version on the secondary peer and commit your changes immediately.
This issue is fixed in Panorama plugin for Azure version, 2.0.2.

PLUG-2074

After a VM Scale Set (VMSS) is deleted, wait until the resource group deletion is complete before you attempt to delicense the VMs. When the deletion is complete, issue the following command:
request plugins azure force-delicense-deleted-vms

PLUG-1876

On rare occasions, you see a message indicating the template configuration is out of sync. Check the syslog and push the configuration to your managed devices.

PLUG-1874

On rare occasions, the license server reuses the serial number of an active device, and Panorama deactivates the device. Remove the device from the auto scale group.

PLUG-1646

Azure plugin 2.0 does not support deployments with a proxy server.

PLUG-1613

Downgrade is not supported for plugin versions.

PLUG-1901

If the service name is not unique across namespaces (for example, Staging and Production) the IP addresses associated with both services are mapped to the same tag and policy enforcement is the same for the services across both namespaces.Instead of using the default tags on Panorama, use the label selector to filter tags based on namespace, and use the filter results as part of the address group.

PLUG-1766

On
Azure
AutoScaling Definition
it can take from three to five minutes to list the Protected Applications and Services.

PLUG-1711

VNET peering between AKS clusters and Inbound Resource Groups sometimes causes a delay in scheduling and pods are in the Pending, Terminating, or Unknown state. If this happens, restart the nodes.

Recommended For You