Known Issues in the Panorama Plugin for Azure 3.0.0

The following list describes known issues in the Panorama plugin for Azure 3.0.0.


Panorama plugin for Azure only supports general access releases:
Fixed in the Panorama plugin for Azure, version 3.0.1. With this fix, the plugin supports other release types.


Azure deployment fails in United Arab Emirate regions with the error:
Failed to get zones for entered region
Fixed in the Panorama plugin for Azure, version 3.0.1. With this fix, the plugin detects the valid instance types for a region before the deployment.


Some parts of the user interface use the terms
Egress Private IP
Egress Public IP
terminology, while documentation and other parts of the UI use Hub Private IP and Hub Public IP.
Fixed in the Panorama plugin for Azure, version 3.0.1.With this fix, the user interface replaces “Egress” with “Hub”.


After a successful deployment using the PAN-OS 10.0.1 image, if you add a front end with a new public IP type and add related load balancing rules, the new front end functions, however, updating to PAN-OS 10.0.2, deletes the new public IP and load balancing rules.
Fixed in the Panorama plugin for Azure, version 3.0.1. This plugin fix works with PAN-OS 10.0.1 and later.


In a configuration where a service principal is valid for both Azure monitoring and deployments, the user interface incorrectly displays the following error for monitoring:
Failed to process subscription <subscription-id> with exception: local variable ‘service_tag_response’ referenced before assignment
Fixed in the Panorama plugin for Azure, version 3.0.1.


If you create an Azure deployment with a hub stack only, launch the deployment, and edit the deployment configuration to add an inbound stack, the plugin UI does not allow you to choose a device group and a VM size.
Fixed in the Panorama plugin for Azure, version 3.0.1.


Deployment update fails when the minimum number of firewalls count is changed.
Fixed in the Panorama plugin for Azure, version 3.0.1.


If an authcode, device certificate PIN ID, device certificate PIN value, or jumbo frame configuration is changed and a deployment update is done, an automatic rolling update is not triggered. These new changes will only apply to newly deployed firewalls.
: Because rolling updates do not support authcodes, device certificate information, or jumbo frame configuration, you must manually delete the firewalls in the VMSS one by one. The changes will be applied to the new firewalls that come up.


When deploying or updating multiple deployments, the Panorama plugin for Azure might fail to commit your changes when too many commits have been issued by the plugin. This occurs because Panorama allows a maximum of 10 administrator-initiated commits. See Panorama Commit, Validation, and Preview Operations for more information.
: To resolve this issue, perform a manual commit.


Dynamic address groups that include the resource group tag retrieves the IP addresses for application gateways and load balancers but not the IP addresses of VM instances in the resource group. This occurs because the Azure API sometimes returns the resource group tag string in all capital letters and sometimes in all lower case letters.
: When creating a dynamic address group with a resource group tag, add the all-capital tag and all-lower case tag separated by the OR operator.


The VM-Series firewall on Azure can only handle traffic that originated in the same region where the firewall is deployed. Traffic originating from a different region is not seen by the firewall.


When a deployment is first added on Panorama, the status displays Commit Changes directing you to perform a commit. However, when you make a change to the deployment configuration, the status does not change although a commit is required before your Azure stack is updated.
: Perform a commit on Panorama.


In an Azure deployment orchestrated from Panorama, outbound ICMP traffic cannot be handled by the VM-Series firewall due to a limitation in the Azure load balancer.

Recommended For You