To use ZTNA Connector on a Panorama Managed Prisma Access tenant you must file a support ticket to get the feature enabled. The feature is enabled by default on

Prisma Access (Managed by Strata Cloud Manager)

tenants that have been upgraded to Prisma Access 4.0.

If you use RFC 6598 addresses in your environment and want to set up ZTNA Connector on a

Prisma Access (Managed by Strata Cloud Manager)

tenant, you must file a ticket to enable the functionality to define IP pools to reserve for Prisma Access to enable connectivity to your connector VMs and your apps.

Workaround

: Use remote network names that are 31 characters or less in ZTNA Connector deployments.

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

.

You cannot create two dedicated links and then perform a commit and push operation.

Workaround

: When creating dedicated links, commit and push after creating each link.

Workaround

: Reach out to your Palo Alto Networks account team to open an SRE case to upgrade the 4.1 Prisma Access dataplane matrix.

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

Monitor

Data Centers

ZTNA Connectors

Connectors

<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

Commit

Commit 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

: 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

: This functionality is not available on Panorama appliances in FIPS mode until your Prisma Access dataplane is upgraded to 10.2.4.