Prisma Access
Prisma Access Known Issues
Table of Contents
Expand All
|
Collapse All
Prisma Access Docs
-
-
- Prisma Access China
- 4.0 & Later
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
-
-
-
- 5.2 Preferred and Innovation
- 5.1 Preferred and Innovation
- 5.0 Preferred and Innovation
- 4.2 Preferred
- 4.1 Preferred
- 4.0 Preferred
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
Prisma Access Known Issues
Where Can I Use This? | What Do I Need? |
---|---|
|
|
Prisma Access has the following known issues.
Issue ID
|
Description
|
---|---|
AIOPS-8130 This issue is now resolved in plugin
version 5.0.1. See Prisma Access 5.0.1 Addressed Issues. |
Occasionally, the Top 5 Prisma Access Location widget shows
exorbitant and incorrect numbers for the Bandwidth in the Remote
Networks and Service Connections section.
|
CYR-42117 | IMDSv2 is not supported when onboarding a ZTNA Connector
using Amazon Web Services. Workaround: Enable IMDSv1 and v2
(token optional). |
CYR-41813 | ZTNA Connector onboarding is not supported in the Switzerland or France locations. There is no workaround. |
CYR-41740 | If there are more than 100 connectors onboarded in the same region in a short duration of time, private app access through some of the ZTNA connectors might not work. |
CYR-41067 | An incorrect Prisma Access version displays in the Prisma Access Version area of the UI. In Strata Cloud Manager, the version displays in ManageConfigurationNGFW and Prisma AccessOverviewPrisma Access Version; in Panorama Managed Prisma Access, the version displays in PanoramaCloud ServicesConfigurationService SetupPrisma Access Version. |
CYR-40404 |
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.
|
CYR-39930 | Cortex Data Lake logs are not exported from tenants that have the IP Optimization feature enabled. |
CYR-39907 | If you have enabled IP Optimization for a Panorama Managed Prisma Access deployment, EDL-related information in the Troubleshooting Commands area (PanoramaCloud ServicesConfigurationService SetupService OperationsTroubleshooting Commands) does not work. |
CYR-39795 |
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.
|
CYR-39599 This issue is now resolved in plugin
version 5.0.0-h22. See Prisma Access 5.0.0-h22 Addressed Issues. |
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.
|
CYR-39259 |
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.
|
CYR-39153 |
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.
|
CYR-39148 | When configuring Colo-Connect, Commit and
Push operations to Colo Connect Device Groups may
intermittently fail. Workaround: Retry the Commit
and Push operation to the Colo-Connect Device
Group. |
CYR-39028 |
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.
|
CYR-38619 | Tenants that are onboarded in Switzerland and France cannot use ZTNA Connector. |
CYR-38500 |
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.
|
CYR-38250 This issue is now resolved in plugin
version 5.0.1. See Prisma Access 5.0.1 Addressed Issues. |
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
|
CYR-38131 |
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.
|
CYR-38120 | All available locations do not show up in the list view
in the Mobile Users—Explicit Proxy setup page. Workaround: Use
the map view to select the missing locations. |
CYR-38076 |
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.
|
CYR-38034 This issue is now resolved in plugin
version 5.0.1. See Prisma Access 5.0.1 Addressed Issues. |
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.
|
CYR-37983 | If you have IPv6 enabled for a Mobile Users—GlobalProtect
user, retrieving the HIP report causes a crash. 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. |
CYR-37923 | After creating a new URL category or security rule or an EDL, a local Panorama commit is required before using that object in RBI security rule associations. |
CYR-37913 | If you disable traffic replication in a compute and re-enable it in the same compute, the traffic replication functionality is impacted, and you will not see any mobile user or remote network traffic replicated. There are no commit or configuration failures for this issue. |
CYR-37906 |
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.
|
CYR-37887 |
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.
|
CYR-37826 |
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.
|
CYR-37797 | The status page asks you for a one-time password (OTP)
after a plugin upgrade. 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. |
CYR-37755 |
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.
|
CYR-37706 |
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.
|
CYR-37673 | Clicking the Panorama Cloud ServicesStatusStatusRemote Browser IsolationActive Isolated Session link does not open the MonitorSubscription Usage page in Prisma Access Cloud Management or Strata Cloud Manager. |
CYR-37500 | If you have enabled IPv6 for remote networks, the public IPv6 Address is not displayed for edge locations. |
CYR-37466 | If you enable Colo-Connect, do not enable Bidirectional Forwarding Detection (BFD) on your VLAN. |
CYR-37356 |
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.
|
CYR-37290 | When onboarding a ZTNA Connector, you receive a
declaim requested by root error.
Workaround: Delete the connector that had the error
and create a new one. |
CYR-37227 |
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.
|
CYR-37208 | When using Prisma Access Clean Pipe, the Network Details page (PanoramaCloud ServicesStatusStatusNetwork Details) does not show Clean Pipe entries. |
CYR-36930 | If a GlobalProtect mobile user has dual stack (IPv4 and IPv6) enabled and they connect to a Prisma Access GlobalProtect location that had IPv6 enabled and it was later disabled, the dual-stack user cannot connect to that location. |
CYR-36749 | ZTNA connector flow logs related to netflow may not be visible in the Strata Cloud Manager Log Viewer. |
CYR-35506 | If you have enabled IPv6 for a tenant, deleting the
tenant does not free up the IPv6 prefixes that were allocated to it and
those prefixes are not usable again. Workaround: Do not delete
a tenant that has IPv6 enabled. |
CYR-34999 | For Panorama Prisma Access tenants, if ZTNA Connectors are onboarded, the Provision Progress for service connections (PanoramaCloud ServicesStatusStatusService ConnectionsProvision Progress) is showing provisioning progress for both ZTNA Connectors and Service Connections. |
CYR-34770 | If you configure multiple portals in Prisma Access for the Mobile Users—GlobalProtect deployment, you must configure authentication profile under Client Authentication on all portals. If you do not configure at least one auth profile, an authentication cookie will not generated and the multi portal feature will not work as desired. |
CYR-34720 | GlobalProtect DDNS functionality does not work when using a Panorama running 10.1.x to manage Prisma Access with the Cloud Services plugin. |
CYR-34173 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. | When configuring multiple GlobalProtect portals with Traffic Steering, do not configure Accept Default Routes over Service Connections (PanoramaCloud ServicesConfigurationTraffic SteeringSettingsAccept Default Route over Service Connection); if you do, mobile users cannot connect to the secondary portal. |
CYR-34078 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. |
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.
|
CYR-33877 | If, during Explicit Proxy setup, you select Skip authentication to skip authentication for an address object, and then later want to enable authentication by deselecting Skip authentication for that address object, it can take up to 24 hours for the change to take effect after you make the change and Commit and Push your changes. |
CYR-33815 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. | To enable Source IP based Visibility and Enforcement in Explicit Proxy, you must also enable Enable Agent Proxy (for Cloud Managed Prisma Access) or Use GlobalProtect Agent to Authenticate (for Panorama Managed Prisma Access), even if you have not enabled the Explicit Proxy-GlobalProtect agent functionality. |
CYR-33707 This issue is now resolved in plugin
version 5.0.1. See Prisma Access 5.0.1 Addressed Issues. |
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.
|
CYR-33695 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. | Traffic steering rules cannot be disabled or moved. In other cases, an No object to edit in move handler error is encountered and no changes can be applied to the traffic steering rule. |
CYR-33625 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. |
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.
|
CYR-33584 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. | In a multi-tenant deployment, if the first tenant's license expires, all sub-tenants license are also marked as expired. |
CYR-33553 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. |
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.
|
CYR-33471 |
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.
|
CYR-33454 |
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.
|
CYR-33199 | Current user counts and 90 day user counts are not correct for Kerberos authenticated users. |
CYR-33180 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. | In order to use the Prisma Access Explicit Proxy Connectivity in GlobalProtect for Always-On Internet Security feature, you must onboard at least one mobile user gateway. |
CYR-33145 |
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.
|
CYR-32782 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. | If you delete a Colo-Connect service connection and then Commit and Push your changes, wait at least five minutes after the Commit operation to delete Colo-Connect subnets, links, and VLANs. It can take some time to delete Colo-Connect service connections. |
CYR-32713This issue is now resolved in plugin version 5.0.1. See Prisma Access 5.0.1 Addressed Issues. |
ZTNA Connector can fail to retrieve the correct DNS configuration,
which causes ZTNA connector traffic to fail, when the following
conditions apply:
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.
|
/CYR-32687 | EDLs, Address objects of type IP Wildcard
Mask and FQDN, and Dynamic
Address Groups do not work on decryption policies when Agent or Kerberos
authentication is used with Explicit Proxy. Workaround: Use
Address objects of IP Netmask, IP Range, or Address groups in the
decryption policies. |
CYR-32666 | When importing a previously saved Panorama configuration
that included a Colo-Connect configuration, or reverting from a
previously-saved configuration, you receive errors if the following
conditions are present:
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. |
CYR-32661 | When GlobalProtect is connected in Proxy mode or Tunnel and Proxy mode, user logins will not count toward the number of current users or the number of users logged in over the past 90 days under Mobile Users—Explicit Proxy. |
CYR-32564 |
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:
|
CYR-32517 This issue is now resolved in plugin
version 4.1. See Prisma Access 4.1
Addressed Issues. |
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.
|
CYR-32511 | You can configure IPv6 DNS addresses even if IPv6 is disabled. |
CYR-32431 |
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.
|
CYR-32191 |
ZTNA Connector is not supported in multitenant environments.
|
CYR-32188 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. |
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.
|
CYR-32170 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. | When using ZTNA Connector, diagnostic tools such as ping, traceroute and nslookup that are accessible from the ZTNA Connector UI ConnectorsActionsDiagnostics icon are not functional. |
CYR-32006 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues. |
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.
|
CYR-32004 |
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.
|
CYR-31623 This issue is now resolved in plugin
version 5.0.0. See Prisma Access 5.0.0 Addressed Issues.
|
Only one Panorama HA pair can be associated with a CDL instance.
|
CYR-31603 | 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: ZTNA Connectors with two interfaces
are supported in Connector Groups that are not enabled for AWS Auto
Scale. Ensure that all ZTNA Connectors with two interfaces are contained
in a Connector Group that is not enabled for AWS Auto Scale. |
CYR-31465 | If you onboard a large number of apps in a short period
of time, the applications might not be successfully onboarded (for
example, they might display but be marked as Down). Workaround:
Retry the app configuration by clicking
Retry, or disable and enable the
app. |
CYR-31187 | In order to use the Prisma Access Explicit Proxy
Connectivity in GlobalProtect for Always-On Internet Security
functionality, the default PAC file URL does not populate properly
unless you do a commit and push to both Mobile Users—GlobalProtect and
Mobile Users—Explicit Proxy. 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. |
CYR-30414 | If you have enabled multiple portals in a multitenant
deployment that has only one tenant, and you then disable the multiple
portal functionality on that single tenant, you are able to see both
portals on the UI. 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 |
CYR-30044 |
Predefined EDLs aren't being populated in the Block Settings list in
a new Explicit Proxy deployment.
Workaround: Onboard your Explicit Proxy deployment, perform a
Commit and Push operation, and then go back and update the EDL in
your block Settings.
|
CYR-29964 |
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.
|
CYR-29933 |
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.
|
CYR-29700 |
If you configure multiple GlobalProtect portals in a multitenant
Prisma Access Panorama Managed multitenant deployment, committing
changes on a per-username basis fails with a
"global-protect-portal-8443 should have the value
"GlobalProtect_Portal_8443" but it is [None]"
error.
Workaround: If you have enabled multiple GlobalProtect portals
and have a Prisma Access multi-tenant deployment, perform Commit All
commit operations instead of committing on a per-user basis.
|
CYR-29160 | If the Panorama that manages Prisma Access is configured
in FIPS mode and you select Generate Certificate for
GlobalProtect App Log Collection and Autonomous DEM, the
certificate does not get
downloaded. Workaround: This functionality
is not available on Panorama appliances in FIPS mode until your
Prisma Access dataplane is upgraded to 10.2.4. |
CYR-26112 | If you do not have a Net Interconnect license, all Remote
Networks in a theater are fully meshed, but if you haven't onboarded a
Service Connection in a theater, the Remote Networks cannot be reached
from Remote Networks in other theaters. Workaround: Either
purchase a Net Interconnect license or onboard a service connection
in a theater to have the Remote Networks communicate with other
theaters. |