Occasionally, the Top 5 Prisma Access Location widget shows exorbitant and incorrect numbers for the Bandwidth in the Remote Networks and Service Connections section.

Workaround: Enable IMDSv1 and v2 (token optional).

An FQDN target matching a wildcard might not be discovered for a connector group if the application is not accessible from some of the ZTNA connectors in the connector group.

All connectors in a given group should be able to use DNS to resolve the application and access the application for the application to be auto-discovered in the group.

Workaround: Associate the application object to the required connector group from Strata Cloud Manager.

After installation of the Cloud Services plugin, an Explicit Proxy Kerberos server profile (default_server_profile) is installed by the __cloud_services user, even though Explicit Proxy is not enabled.

Workaround: Ignore the changes.

Some columns in the Egress IP Allowlist table display that are related to IPv6, even though the IPv6 feature has not been enabled.

Workaround: No workaround is required. There is no impact on IPv4-related allow listing functionality.

App Acceleration cannot be enabled or disabled at the same time as performing commit operations in Prisma Access.

Workaround: Use the slider during a time when you are not performing commits to enable or disable App Acceleration.

When performing an upgrade to a ZTNA Connector Group, there can be failures intermittently during the upgrade operation. For example, the upgrade status displays as partial_success or failed, even though some of the affected connectors are later upgraded successfully.

Workaround: Retry the Connector Group upgrade at a later time. ZTNA Connector rechecks and provides you with the appropriate status of the Connector Groups.

Workaround: Retry the Commit and Push operation to the Colo-Connect Device Group.

If you are upgrading your ZTNA Connector from 4.1 to a later Prisma Access version and the ZTNA connector application pools are configured within the RFC6598 address space (100.64.0.0/16 and 100.65.0.0/16), ZTNA connector traffic may be blocked on the MU-SPN.

Workaround: Contact your Prisma Access team to update the SaaS Agent version of all your Prisma Access tenants.

For Explicit Proxy Deployments, the France North location is not available, but it appears in the Prisma Access UI.

Workaround: Do not select the France North location when onboarding Explicit Proxy deployments.

The Mobile Users—Explicit Proxy Users (last 90 days) incorrectly displays the same users as Mobile Users—GlobalProtect.

Workaround: Log into a CLI session from the Panorama that manages Prisma Access and enter the following command: debug plugins cloud_services prisma-access query action getEPaaSLast90DaysUniqueUsers

If you have an existing Prisma Access deployment and upgrade your deployment to the 10.2.8 dataplane, you cannot use App Acceleration with existing IPSec termination nodes, which means that you cannot use App Acceleration with existing remote networks after a dataplane upgrade to 10.2.8.

Workaround: Onboard a new remote network with a new IPSec Termination Node to use App Acceleration with remote networks.

Workaround: Use the map view to select the missing locations.

The correct EBGP Router address does not display in the Remote Networks Network Details page (Remote Networks SetupRemote NetworksEBGP Router) and instead shows the Loopback IP address of the remote network.

If a ZTNA connector is rebooted and if the corresponding connector group contains applications with a Probing Type of icmp ping or none, there might be an impact on the traffic traversing the rebooted ZTNA Connectors.

Workaround: Disable and enable all the applications in the respective connector groups.

Workaround: If the GlobalProtect client is ipv6 enabled, run the HIP report using the client's IPv6 address. If the GlobalProtect client is IPv4 only, run the HIP report using the client's ipv4 address.

If, when updating the ports for an existing wildcard object, you put spaces between the ports, a 500 internal server error is displayed.

Workaround: Do not put spaces between the ports. For example, instead of 1-2, 80, 100-300, put 1-2,80,100-300.

If you are using ZTNA Connector as part of the 30-day trial and have not purchased a license, onboarding might fail with a message that Something went wrong when you click the Enable ZTNA Connector button.

Workaround: Refresh the UI to complete the onboarding of the ZTNA Connector feature.

If two or more ZTNA connector applications have the same FQDN, an Application Custom rule conflict message could display in the SD-WAN portal.

Workaround: This message is spurious and can be ignored.

Workaround: Delete the expired license keys, delete the Panorama certificate, and retrieve the licenses and verify if the license keys are valid after you retrieve them; then, generate the OTP to verify.

If you configure a Wildcard Target in ZTNA Connector, and if you try to change the port of an application that was discovered as a result of that target and was added to the FQDN Target, you receive an error that the name is too long.

Workaround: While application names can be a maximum of 32 characters long, changing the port number makes the name too long in the ZTNA Connector infrastructure. If you encounter this error, try to give the application a shorter name.

When using Explicit Proxy, an excessive amount of threat logs display.

Workaround: Ignore the threat logs. These logs have no impact on Explicit Proxy functionality.

If you renew the App Acceleration license after is has expired (including the grace period for the license), the renewal does not take effect immediately.

Workaround: Wait approximately one hour after license renewal before using App Acceleration.

Workaround: Delete the connector that had the error and create a new one.

The creation of the IP subnet-based Connector Group sometimes fails with a group already exists message, even though the group does not exist.

Workaround: Use another name for the IP subnet-based Connector Group.

Workaround: Do not delete a tenant that has IPv6 enabled.

If you configure a Colo-Connect subnet before configuring and performing a Commit and Push operation for the Infrastructure Subnet, Colo-Connect Commit and Push operations would fail.

Workaround: complete the following steps:

1. Configure the Infrastructure Subnet and perform a Commit and Push operation.

2. Configure the Colo-Connect subnet and perform a Commit and Push operation, making sure to select Colo-Connect in the Push Scope.

If you change Colo-Connect service connection roles (for example, from Active/Active to Active/Backup) and change the bandwidth on VLANs at the same time, an error displays after a Commit and Push operation.

Workaround: Perform bandwidth changes and service connection roles in different commit and push operations.

When configuring Colo-Connect for the first time and performing a partial commit, you receive a 'Colo_Connect_Device_Group' is invalid error.

Workaround: When configuring Colo-Connect for the first time, Commit all changes for the first commit and push operation and do not perform a partial commit, or the commit will fail.

The Connector availability graph shown under MonitorData CentersZTNA ConnectorsConnectors<connector-name>Device metric displays the graph in complete red color even when the connector IPSec tunnel has been continuously up for the last 24 hours.

If you enable multi-tenancy, create a new sub tenant, configure Mobile Users—GlobalProtect, Remote Networks, and Colo-Connect device groups, then configure Colo-Connect subnets and VLANs, and a partial commit fails with an Unable to retrieve last in-sync configuration for the device error.

Workaround: Perform a Commit and Push operation when configuring Colo-Connect for the first time instead of a partial commit.

If you configure Prisma Access in a in a multi-tenant deployment, perform a Commit and Push, then configure Colo-Connect, the choice to Commit and Push your changes is grayed out.

Workaround: Click CommitCommit to Panorama, then Commit Push to Devices, click Edit Selections and make sure that Colo-Connect is selected in the Push Scope; then, retry the commit and push operation.

When a Prisma Access license for any service type expires, any Commit All operation fails a generic Commit Failed error message.

Workaround: Make sure that your all your Prisma Access licenses have not expired before performing commits.

ZTNA Connector can fail to retrieve the correct DNS configuration, which causes ZTNA connector traffic to fail, when the following conditions apply:

• When the first application is onboarded in ZTNA connector
• When all applications are removed (deboarded) from ZTNA Connector

Workaround: Refresh the GlobalProtect connection to get correct DNS server configuration. In the case of all applications going down for a tenant, refresh the GlobalProtect again when some or all applications in ZTNA connector are back up.

Workaround: Use Address objects of IP Netmask, IP Range, or Address groups in the decryption policies.

Workaround: Colo-Connect service connections cannot be onboarded unless their corresponding VLANs are in an Active state. Delete any Colo-Connect service connections before exporting or reverting a Panorama image; then, re-create the Colo-Connect service connections after importing the new image.

ZTNA Connector app traffic is detected as a threat and dropped for Prisma Access Cloud Management if the default URL category is used.

Workaround: Perform one or more of the following steps as required:

If you deploy a mobile users location that already has a location deployed in the same compute location, you might receive only one public IP address for the newly-deployed location instead of two.

Workaround: Enable the IP Allow Listing feature to receive more than one IP address.

When configuring Explicit Proxy, when you add Trusted Source Address values under Authentication Settings, configure other settings, and then return to the Authentication Settings tab, the trusted source addresses might not display correctly.

Workaround: Refresh the Panorama that manages Prisma Access, then return to the Authentication Settings tab to see the addresses.

ZTNA Connector is not supported in multitenant environments.

In Prisma Access Insights, the Connector Availability graph for a given ZTNA Connector will not show up if the IPSec tunnel between the connector and the ZTNA Tunnel Terminator (ZTT) has been up without interruption for the last 24 hours. The Connector Availability graph shows up only if the tunnel has gone down at least once within the last 24 hours.

When using Dynamic DNS (DDNS) registration using the Cloud Services plugin 3.2, nsupdate commands are not working as expected, which causes issues with DDNS update queries.

Due to a limitation in the number of IPSec profiles currently supported in Prisma Access, when deploying ZTNA Connector you can onboard a maximum of 100 connector VMs per tenant.

ZTNA Connectors with two interfaces are not supported in a Connector Group enabled for AWS Auto Scale. This is due to an AWS Auto Scale group limitation that ties both interfaces to the same subnet. See this article for details.

Workaround: Retry the app configuration by clicking Retry, or disable and enable the app.

Workaround: When you Commit and Push, make sure that you choose both Mobile Users—GlobalProtect and Mobile Users—Explicit Proxy in the Push Scope when configuring Prisma Access Explicit Proxy connectivity in GlobalProtect.

Workaround: Open a CLI session on the Panorama that manages Prisma Access and enter the following commands, then perform a local commit on the Panorama:

set plugins cloud_services multi-tenant tenants <tenant_name> mobile-users multi-portal-multi-auth no

request plugins cloud_services gpcs multi-tenant tenant-name <tenant_name> multi_portal_on_off

Attempts to reuse a certificate signing request (CSR) to generate a certificate results in a "Requested entity already exists" error.

Workaround: Do not reuse CSRs.

Attempts to use the verdicts:all -X "DELETE" API call more than one time per hour result in the {"code" :8, "message" : "Too many requests" error.

Workaround: Do not use this API call more than one time per hour.

Workaround: Either purchase a Net Interconnect license or onboard a service connection in a theater to have the Remote Networks communicate with other theaters.