Cloud NGFW for AWS
Cloud NGFW for AWS Known Issues and Limitations
Table of Contents
Expand All
|
Collapse All
Cloud NGFW for AWS Docs
Cloud NGFW for AWS Known Issues and Limitations
Cloud NGFW for AWS known issues.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
|
The following known issues have been identified in the Cloud NGFW for
AWS.
| ID | Description | Workaround |
|---|---|---|
| PAN-158748 | In Panorama High Availability (HA) configurations where
multiple plugins are installed, a synchronization issue may occur
between the management plane and the plugin metadata. While the
active Panorama node may successfully receive external updates (such
as tags or IP address mapping notifications from NSX-T, AWS, or
other cloud providers), these updates fail to populate in the
Panorama Web Interface under Device Group >
Objects. Because the management plane (Web UI) does not reflect
these dynamic objects, they cannot be selected as Match Criteria
for Dynamic Address Groups (DAGs). Consequently, the associated IP
addresses are not pushed to the Cloud NGFW or managed firewalls. |
This behavior is specifically tied to how the Panorama
management plane handles multi-plugin support for device groups in
an HA state. If you encounter this synchronization failure in an HA
pair, ensure that the plugins are not blocked from pushing updates.
Use the following CLI commands on both Panorama nodes to ensure the
plugins can properly update the device group objects:
request plugins dau plugin-name cloud_services
unblock-device-push yes
request plugins dau plugin-name cloudconnector
unblock-device-push yes
request plugins dau plugin-name vm_series
unblock-device-push yes
request plugins dau plugin-name aws
unblock-device-push yes
|
| PAN-234015 |
When XFF is enabled for Security Policy (configured via Strata
Cloud Manager or Panorama), the firewall uses the XFF
IP for policy enforcement. However, Traffic logs do not
populate the XFF client IP column for an overwhelming majority of
sessions.
| None |
| FWAAS-16601 |
On Cloud NGFW tenants, firewalls managed by Panorama may appear in
SCM when both systems share a strata tenant also known as Tenant
service group (TSG). SCM permits policy push attempts to these
firewalls, but the commits will fail. This failure does not affect
deployed instances but will block configuration commits for
autoscaling instances.
| Use only the Panorama console to manage all configuration and policy for these devices. If a policy push is inadvertently attempted from SCM, it will fail. To recover from this state, push the configuration from Panorama again. After the successful push from Panorama, a commitall operation will succeed and resolve the issue. |
|
FWAAS-16644
AIP-1216
|
When unlinking a Panorama from a Cloud NGFW tenant, the
Panorama may incorrectly display Device Groups that belong to other
Panoramas and remain associated with the same strata tenant (also
known as a Tenant Service Group or TSG).
| To prevent this issue, it is recommended to associate only one standalone Panorama instance or one high-availability (HA) Panorama pair with a single strata tenant (TSG). Avoid associating multiple, independent Panorama instances or HA pairs with the same TSG. |
|
Cloud NGFW does not support dynamically adding new CIDRs to an IP
address pool that is already in use. If you add a new CIDR block to
an existing, associated pool, the Cloud NGFW resource will not
recognize or use the new IP addresses.
| You must create a new IP address pool containing the new CIDRs and associate that new pool with the Cloud NGFW resource. | |
|
During the initial registration with SCM, Cloud NGFW resources (for
example, the resource ID) may fail to display. These resources will
appear after a few moments if there are no underlying connection
issues.
| ||
| DIT-40385 |
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.
| To allow intra-zone traffic, customers should create a specific security policy rule for the desired behavior and place it in the pre-rule or post-rule sections. This new rule will take precedence over the default deny policy, ensuring traffic processing matches your intent. |
| FWAAS-16331 |
After a new V2 subscription in the three opt-in AWS regions
(af-south-1, ap east-1, and me-south-1), creating a firewall may
cause a delay for a few hours. This issue can also cause a delay in
the delivery of the latest content and threat intelligence updates
to the existing firewalls in these regions.
| After subscribing, proceed to create your firewall. If this process fails or returns an error, wait for a few hours from the time of that failed attempt. You can then retry the firewall creation. |
| DIT-40616 | In some cases, validating a rulestack change and then committing it could cause your Cloud NGFW resource to apply an incorrect configuration. This issue can also cause an auto-scaled firewall to apply an incorrect configuration file at boot up. | None |
| FWAAS-1501 | Cloud NGFW uses the native AWS Route 53 Resolver for resolving FQDNs you configure in your rules. When used, the AWS Route 53 Resolver may resolve an FQDN to an IP address, different than what you may see when you use the Route 53 Resolver in your VPCs. | None |
| FWAAS-2589 |
When you onboard an AWS account to your Cloud NGFW tenant,
you choose one of these two endpoint creation modes -
customer-managed vs. service-managed. Cloud NGFW will not allow you
to switch modes after completing the account onboarding process.
| None |
| FWAAS-5817 | The Panorama UI does not display any error message when cloud manager or cloud NGFW service push fails. You will only know about push failure when the firewall commit fails. | None |
| FWAAS-5823 | When creating a new cloud device group in Panorama, you cannot select which certificates are used for forward trust or forward untrust. | None |
| FWAAS-6380 | An error message may appear when pushing an uncommitted change to a cloud device group. Commit your changes before pushing. | None |
| FWAAS-6540 | An existing Panorama device group erroneously allows you to apply a different template stack after creating it. You cannot associate a different template stack for the same device group across tenants. | None |
| FWAAS-6542 | Panorama Template stack fails to update when applying it to a different device group. | None |
| FWAAS-6961 |
On the Panorama AWS Plugin for Cloud NGFW service, the
first time tenant linked to Panorama will not be able to see any
VPCs under the Discovered VPC tab.
| None |
| FWAAS-7721 | In a scaled environment, the AWS plugin user interface crashes when displaying IP address-to-tags payload in the Monitoring Definition dashboard. | Use the Panorama CLI to run command: show plugins aws details-dashboard. |
| FWAAS-7766 | The Discovered VPC page on Cloud NGFW UI does not show the failure reason if the Monitoring Status is Failed for a discovered VPC. | None |
| FWAAS-10971 | Issuing the reset command with invalid firewall resource IDs does not reset the rule usage counters. This behavior is expected. | None |