New instances of CNGW Azure fail to forward logs to a dedicated log collector post scale-out. When a new firewall joins Panorama, its serial number is added to the device list. However, unlike when Panorama acts as a log collector, a dedicated log collector doesn't automatically receive this new device information. Consequently, it rejects connection requests from the new instances.

Other workarounds are:

• Use Panorama as Local Log-Collector
• Use SLS (Strata Logging Service).
• Use Azure Log Analytics Workspace.

In the Azure portal, health checks from an internal load balancer are not received which causes the Cloud NGFW resource to reach an unhealthy state; a gateway with a Deny All rule blocks communication between the load balancer performing the health check to the firewall. To resolve this issue, allow list the health probe IP address.

After overriding the default intrazone security policy from Panorama, the change may not apply correctly on the Cloud NGFW. The firewall continues to use its local intrazone-default deny policy, which takes precedence and results in unexpected denial of same-zone traffic. Additionally, traffic logs for this denied traffic are not visible.

When multilogging destination is enabled, the logs are seen on Panorama and syslog server, but no logs are seen on the log analytics workspace.

Workaround: If you want to use syslog along with log analytics workspace, change the service route to destination based instead of a service-based route.

For Destination Based Routing configuration, select the destination, add your syslog server private IP, and then select loopback.3 as the source interface.

Default rules in Panorama are overridden by the Cloud NGFW resource. Parameters such as Profile and Action are not retained. For example, if you configure an action to Allow, it reverts to Deny; if you configure a logging profile, it reverts to None.

A self-signed certificate can erroneously be associated with a rulestack, despite the absence of a resource name.

Panorama does not always automatically push content and antivirus updates to newly created Cloud NGFW for Azure resources.

QoS Profiles (provided by a device template) are not removed when displayed in the Panorama virtual appliance.

Creating a large number of local rules can cause an HTTP error (503 Server Error: Service Unavailable).

Deployment status information in the Azure portal is truncated without displaying complete information.

Firewall creation fails when you enable non-RFC 1918 addresses without enabling a DNS Proxy.

When a Cloud NGFW for Azure resource connects to Panorama for the first time, the template stack associated with the resource's Cloud Device Group is out of sync.

Cloud NGFW resources managed by a Panorama HA pair might be listed in the cloud device group by its serial number (instead of device name) on the secondary Panorama. However, on the primary Panorama, the Cloud NGFW resource is listed by its device name.

Configured Dynamic Address Group tags and IP addresses are not listed in child Cloud Device Groups when the parent device group does not have a Dynamic Address Group configured.