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 |
|---|---|---|
| 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. | |
| 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 |