>
    Strata Copilot
    Cloud NGFW for AWS Known Issues and Limitations
    Focus
    Download PDF
    Focus
    1. Home
    2. Cloud NGFW for AWS
    3. Cloud NGFW for AWS Known Issues and Limitations
    Download PDF
    Cloud NGFW for AWS

    Cloud NGFW for AWS Known Issues and Limitations

    Table of Contents

    Cloud NGFW for AWS Known Issues and Limitations

    Cloud NGFW for AWS known issues.
    Where Can I Use This?What Do I Need?
    • Cloud NGFW for AWS
    • Cloud NGFW subscription
    • Palo Alto Networks Customer Support Account (CSP)
    • AWS Marketplace account
    • User role (either tenant or administrator)
    The following known issues have been identified in the Cloud NGFW for AWS.
    IDDescriptionWorkaround
    Cloud NGFW for AWS supports NAT64 to enable IPv6-only workloads to communicate with external IPv4 destinations. Traditional source-based NAT (SNAT/NAT66) is not supported for IPv6 traffic.
    		None
    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

    © 2026 Palo Alto Networks, Inc. All rights reserved.