aaron.axvig/firewallissues
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add Prisma Access Agent known and addressed issues

Browse Source
This commit is contained in:
aaron.axvig
2026-03-16 21:35:47 -05:00
parent f1e49c5830
commit 70dcd896be
25 changed files with 1054 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
web/data/issues/Prisma Access Agent/known/25.1_2026-03-17.md
+26
View File
@@ -0,0 +1,26 @@
---
type: Known
product: Prisma Access Agent
version: 25.1
---
## EPM-4848
As ring mappings for Prisma Access Agents are calculated during
configuration time, the ring mappings might not always be accurate.
Some potential causes are new agent enrollments, changes in
directory binding, or host operating system updates.
Workaround: Before initiating a staged upgrade rollout of the
agent, perform a commit push. This action ensures all agents are
correctly mapped to their designated upgrade rings. If new agents
are enrolled after you run the commit push, the new agents are
always mapped to the default ring until the next commit push.
## EPM-4821
The ConnectPre-logon option is present in the Prisma Access Agent Settings
page for Panorama Managed Prisma Access and NGFW deployments, even
though it's not functional.
Workaround: Ignore this option as it won’t work.
web/data/issues/Prisma Access Agent/known/25.3.0-iOS_2026-03-17.md
+39
View File
@@ -0,0 +1,39 @@
---
type: Known
product: Prisma Access Agent
version: 25.3.0-iOS
---
## PANG-8284
An issue exists where the Prisma Access Agent on Android and iOS
devices does not enforce the session timeout settings configured in
the Agent configuration. When you configure specific session timeout
values in your Agent settings, the Android and iOS agents fail to
apply these predetermined timeout intervals and will use the default
timeout value.
## PANG-8283
An issue exists where the embedded browser cookies are not cleared
when users sign out of the Prisma Access Agent on Android devices
that use the embedded browser for SAML authentication. When a user
signs out of the agent, the system fails to properly clear the
stored authentication cookies within the embedded browser,
potentially leaving residual session data.
## PANG-8282
Prisma Access Agent on Android does not support IPSec connectivity
when deployed in NGFW deployments. The agent will automatically detect
this unsupported configuration and fall back to SSL connectivity to
maintain proper functionality.
## PANG-8223
An issue exists where the Prisma Access Agent on iOS and Android
allows users to sign out even when the Allow User to Sign
Out Agent Setting is disabled. When you configure
the agent to prevent users from signing out through the agent
settings, the Prisma Access Agent app continues to display an active
sign-out option that successfully logs the user out when selected.
web/data/issues/Prisma Access Agent/known/25.3.0.11-Android_2026-03-17.md
+39
View File
@@ -0,0 +1,39 @@
---
type: Known
product: Prisma Access Agent
version: 25.3.0.11-Android
---
## PANG-8284
An issue exists where the Prisma Access Agent on Android and iOS
devices does not enforce the session timeout settings configured in
the Agent configuration. When you configure specific session timeout
values in your Agent settings, the Android and iOS agents fail to
apply these predetermined timeout intervals and will use the default
timeout value.
## PANG-8283
An issue exists where the embedded browser cookies are not cleared
when users sign out of the Prisma Access Agent on Android devices
that use the embedded browser for SAML authentication. When a user
signs out of the agent, the system fails to properly clear the
stored authentication cookies within the embedded browser,
potentially leaving residual session data.
## PANG-8282
Prisma Access Agent on Android does not support IPSec connectivity
when deployed in NGFW deployments. The agent will automatically detect
this unsupported configuration and fall back to SSL connectivity to
maintain proper functionality.
## PANG-8223
An issue exists where the Prisma Access Agent on iOS and Android
allows users to sign out even when the Allow User to Sign
Out Agent Setting is disabled. When you configure
the agent to prevent users from signing out through the agent
settings, the Prisma Access Agent app continues to display an active
sign-out option that successfully logs the user out when selected.
web/data/issues/Prisma Access Agent/known/25.3.1_2026-03-17.md
+94
View File
@@ -0,0 +1,94 @@
---
type: Known
product: Prisma Access Agent
version: 25.3.1
---
## PANG-8200
```resolved
Resolved in Prisma Access Agent 25.6
```
An issue exists where the Prisma Access Agent app interface displays
inconsistent behavior between Windows and Mac platforms when users
execute the pacli epm signout command without
the --keep parameter. When users run the
./pacli epm signout command on Mac
systems, the app correctly resets the login view and displays
Select Server Name in the
Server Name field instead of showing the
previously connected server. However, on Windows systems, the app
continues to display the previously connected server FQDN rather
than resetting to the default Select Server
Name prompt.
The app sign-out function and the pacli epm signout
--keep command both maintain consistent behavior
across both Windows and Mac platforms by preserving the previously
connected server information.
## PANG-8053
An issue exists where the Prisma Access Agent on Windows fails to
establish a pre-logon tunnel when the forwarding profile's default
behavior is configured to Best Available - Fail
Safe. The fail-safe configuration prevents the
pre-logon tunnel creation process from completing successfully,
disrupting the expected connectivity sequence during the Windows
pre-logon phase. When the forwarding profile is set to
Best Available - Fail Open as the default
behavior, the pre-logon tunnel establishes without issue, indicating
that the fail-safe mechanism is incorrectly interfering with the
tunnel establishment process. This behavior contradicts the expected
functionality where pre-logon tunnels should be created regardless
of whether the forwarding profile default is configured for
fail-safe or fail-open operations.
## PANG-7960
```resolved
Resolved in Prisma Access Agent 25.4
```
An issue exists where the Prisma Access Agent on Windows blocks
authentication in the embedded browser due to the Best
Available - Fail Safe mechanism in the forwarding
profile triggering during the initial connection attempt.
When the agent is configured to run in on-demand mode and the user
launches the agent after a reboot, the authentication process
encounters interference from the fail-safe mechanism. Users
experience authentication failures in the default browser as
expected when fail-safe triggers, but when they switch to the
embedded browser, the first authentication attempt also gets blocked
by the fail-safe mechanism. The authentication only succeeds when
users cancel the initial embedded browser attempt and retry the
process. The embedded browser should bypass or properly handle the
fail-safe mechanism to enable successful authentication on the first
attempt without requiring users to cancel and retry the
authentication process.
## PANG-7309
```resolved
Resolved in Prisma Access Agent 25.4
```
An issue exists where the Prisma Access Agent on Windows fails to
automatically switch from an external gateway to an internal gateway
when the user's device wakes from sleep mode. This occurs when the
user connects the agent to an external network and then puts the
device to sleep for an extended period before waking it on an
internal network. The agent remains connected to the external
gateway instead of automatically detecting and switching to the
appropriate internal gateway. Attempting to sign out and sign back
in through the Prisma Access Agent app does not resolve the
connection issue, as the agent continues to maintain its connection
to the external gateway.
Workaround: The user needs to sign out using the
pacli epm signout command and then sign
back in using the Prisma Access Agent app, after which the agent
will successfully establish a connection to the internal gateway as
expected.
web/data/issues/Prisma Access Agent/known/25.3_2026-03-17.md
+38
View File
@@ -0,0 +1,38 @@
---
type: Known
product: Prisma Access Agent
version: 25.3
---
## PANG-7865
```resolved
Resolved in Prisma Access Agent 25.4
```
An issue exists where the Prisma Access Agent on Windows does not
properly honor updated session timers after a user extends their
session through the embedded browser.
When a user clicks on the session expiry banner displayed in the
Prisma Access Agent app, the embedded browser opens and enables the
user to authenticate, successfully extending the Prisma Access Agent
Manager (EPM) session with a new expiration time. However, the
Prisma Access Agent continues to use the original session expiration
timer instead of adopting the newly extended session duration.
As a result, when the original session timer expires, Prisma Access
Agent incorrectly terminates the EPM session despite the successful
extension. Additionally, the Prisma Access Agent icon becomes
unresponsive in the system tray after this occurs.
## PANG-7012
```resolved
Resolved in Prisma Access Agent 25.3.1
```
An issue exists where the embedded browser for Prisma Access Agent
does not reuse the Windows Hello token for reauthentication. As a
result, users are required to manually enter their credentials even
when Windows Hello is enabled on their devices.
web/data/issues/Prisma Access Agent/known/25.4_2026-03-17.md
+78
View File
@@ -0,0 +1,78 @@
---
type: Known
product: Prisma Access Agent
version: 25.4
---
## PANG-8945
```resolved
Resolved in Prisma Access Agent 25.7
```
When you upgrade to the latest Prisma Access Agent Manager (EPM), the
default for Block Non-TCP and Non-UDP based traffic when
connected to tunnel is disabled. An issue exists
where the pacli traffic show command output
incorrectly shows Allow non-tunnel outbound ICMP when
connected to tunnel as true.
When the Block Non-TCP and Non-UDP based traffic when
connected to tunnel option is disabled, the
Allow ICMP for troubleshooting value
should be passed as true. Currently, the Allow ICMP for
troubleshooting value is incorrectly being passed as
false (disabled), which should block ICMP traffic that goes out of
the tunnel. However, ICMP traffic is actually being allowed through
the physical adapter, creating a discrepancy between the
configuration and actual traffic behavior.
This results in inconsistent ICMP traffic handling where the
configuration indicates ICMP should be blocked, but the traffic is
actually permitted.
## PANG-8864
```resolved
Resolved in Prisma Access Agent 25.6
```
An issue exists where the Prisma Access Agent might incorrectly
remain bound to port 0 when switching between Prisma Access Agent
Manager (EPM) configurations with different proxy settings, causing
endpoint traffic to Explicit Proxy (EP) to fail.
When the Prisma Access Agent initially connects to an EPM without
agent proxy configured, it binds to port 0 after a system restart on
the endpoint. If the system subsequently switches to a different EPM
that has a proxy port configured, the agent might fail to update its
port binding and incorrectly remain bound to port 0. This results in
endpoint traffic destined for the Explicit Proxy failing to function
properly.
Workaround: To resolve this issue, restart the endpoint, and
then run the pacli proxy disable command,
followed by the pacli proxy enable command.
This forces the agent to properly initialize with the correct proxy
port configuration from the new EPM.
## PANG-8863
An issue exists where the embedded browser intermittently displays as
blank or empty after installing Prisma Access Agent version 25.4 on
Windows 11 systems. The embedded browser window appears but shows no
content, preventing users from completing authentication or
accessing websites through the agent's built-in browser
component.
Workaround: Restart the endpoint.
## PANG-8646
An issue exists where the reasoning for blocked non-TCP, non-UDP, and
ICMP traffic is not logged in the PACli logs or network manager
logs. When Prisma Access Agent forwarding profiles block this type
of traffic, administrators cannot view the verdict reasoning or
decision details through either the PACli command-line interface or
network manager logs, making it difficult to audit and troubleshoot
blocked traffic for these protocol types.
web/data/issues/Prisma Access Agent/known/25.6.1_2026-03-17.md
+59
View File
@@ -0,0 +1,59 @@
---
type: Known
product: Prisma Access Agent
version: 25.6.1
---
## PANG-9362
```resolved
Resolved in Prisma Access Agent 26.1.2 (PANG-11395)
```
An issue exists where Prisma Access Agent fails to trigger internal
gateway authentication and update IP-user mapping when transitioning
between networks while multiple Ethernet interfaces remain active
simultaneously. This occurs specifically when a Windows 11 laptop,
connected to LAN via Prisma Access Agent to an NGFW firewall,
reconnects the LAN cable after switching to Wi-Fi, resulting in both
network interfaces being active for several seconds during the
transition.
While Prisma Access Agent successfully reauthenticates to the Prisma
Access Agent Manager and updates IP-user mapping when switching from
LAN to Wi-Fi with a single active interface, it fails to perform the
same authentication process when reconnecting to LAN while Wi-Fi
remains connected. This causes traffic impact as the source user/IP
becomes unknown to the internal gateway due to the outdated IP-user
mapping.
Workaround: Enable the Windows 11
Prevent Wi-Fi when on Ethernet setting,
which prevents both interfaces from remaining connected
simultaneously during network transitions.
## PANG-9011
An issue exists where the Prisma Access Service (PASrv) continues to
attempt authentication even when Prisma Access Agent is explicitly
disabled. This behavior has been observed in staging environments
where users have disabled agent due to Prisma Access Agent Manager
(EPM) login issues and switched to GlobalProtect as an alternative
solution. Despite the agent being confirmed as disabled through the
pacli switchto status command, which
shows Prisma Access Agent: Disabled and
GlobalProtect: Enabled, the PASrv
service continues to periodically attempt login operations in the
background.
## PANG-9001
An issue exists where Prisma Access Agent incorrectly reuses SAML
authentication requests between different Windows user sessions on
the same device. When a user logs off from Windows and a different
user logs in, the SAML authentication request carries the same SAML
request data from the previous session, causing the agent to
maintain connectivity to the gateway using the original user's
credentials rather than authenticating the new user. When the
original user logs back in following an OS reboot, the agent
continues to use the cached authentication from the first session.
web/data/issues/Prisma Access Agent/known/25.6.2_2026-03-17.md
+13
View File
@@ -0,0 +1,13 @@
---
type: Known
product: Prisma Access Agent
version: 25.6.2
---
## PANG-9739
An issue exists where Prisma Access Agent portal (LDAP) authentication on Strata Cloud Manager requires the use of certificates from the **Global** configuration scope exclusively for cookie encryption and decryption operations.
When configuring portal authentication for Prisma Access Agent, you must select certificates from the **Global** scope (**NGFW and Prisma Access** > **Configuration Scope** > **Global** > **Objects** > **Certificate Management**) for this purpose and must avoid using certificates that share the same name across different scopes.
Specifically, if a certificate is selected from the **Global** scope for portal authentication, you must verify that no certificate with an identical name exists under the **Prisma Access** or **Access Agent** scopes, as any naming conflict can cause authentication issues. This scope restriction is necessary to prevent certificate conflicts and ensure proper cookie handling during the LDAP authentication process for Prisma Access Agent users.
web/data/issues/Prisma Access Agent/known/25.6_2026-03-17.md
+98
View File
@@ -0,0 +1,98 @@
---
type: Known
product: Prisma Access Agent
version: 25.6
---
## PANG-9334
An issue exists where the Prisma Access Agent user interface is cut
off or displayed incorrectly on macOS 26 (Tahoe). Users running the
this macOS version may experience visual rendering problems with the
Prisma Access Agent application, where portions of the interface
elements, menus, or dialog boxes are truncated or not properly
displayed within the application window. This display issue can
impact user interaction with the agent's configuration settings,
status information, and other UI components, potentially making it
difficult to use the Prisma Access Agent functionality.
## PANG-9282
An issue exists where the Prisma Access Agent's embedded browser
throws a "Server Error" dialog when users attempt to sign into the
Prisma Access Agent Manager (EPM) server using Windows Hello PRT
(Primary Refresh Token) authentication. This problem occurs
specifically on Windows machines that are Active Directory-joined
and have Windows Hello PIN configured. When users successfully
authenticate to their laptop using Windows Hello PIN and
subsequently try to access the EPM server through the Prisma Access
Agent, the embedded browser fails to properly handle the Primary
Refresh Token authentication flow, resulting in a "Server Error"
dialog instead of successful authentication.
## PANG-9242
```resolved
Resolved in Prisma Access Agent 25.7
```
An issue exists where the Prisma Access Agent fails to remove the
tunnel interface from the routing table when executing the
pacli epm signout command after the
gateway has been shut down and the agent is in a
Disconnected state. This issue affects
Prisma Access Agents on macOS and Windows, and occurs when the agent
was previously connected to a tenant but transitions to a
disconnected state due to gateway shutdowns.
When users attempt to sign out using the pacli
command, the signout appears successful and the EPM status shows as
Down with Not
Enrolled authentication status, however the tunnel
interface and associated routing table entries remain active in the
system. This results in orphaned network routes that should have
been cleaned up during the signout process, potentially causing
network connectivity issues.
## PANG-8929
```resolved
Resolved in Prisma Access Agent 25.7
```
An issue exists where the Prisma Access Agent on Windows reports
error: 513 - PASrv is unreachable, please confirm
it's running when executing the pacli epm
status command, even though the PASrv service is
confirmed to be running in both Task Manager and service control
manager queries.
This issue occurs specifically during a reinstallation scenario where
the agent is first installed and connects successfully, then
uninstalled, and subsequently reinstalled. After the second
installation, while the agent appears to connect normally, the
pacli command line interface fails to
communicate with the PASrv service, generating the unreachable
service error. Additionally, when users attempt to sign out from the
UI and reconnect, the embedded browser successfully completes
authentication with the identity provider, but the agent becomes
stuck in a "connecting" state and fails to establish a proper
connection.
Workaround: Manually restarting the PASrv service, which
restores normal agent functionality and allows proper communication
between the pacli interface and the
service.
## ADI-49478
An issue exists where the Strata Cloud Manager displays an
ADNS option under the forwarding profiles
setup in the connectivity object configuration, even though ADNS
support is not available in current Prisma Access Agent releases.
The ADNS option appears as disabled by default in the user
interface, but since the underlying functionality is not yet
implemented in the agent software, this configuration option should
not be used. Administrators encountering this option in Strata Cloud
Manager should ignore it until proper agent support is implemented
in future releases.
web/data/issues/Prisma Access Agent/known/25.7-Linux_2026-03-17.md
+46
View File
@@ -0,0 +1,46 @@
---
type: Known
product: Prisma Access Agent
version: 25.7-Linux
---
## PANG-10159
On a Linux device, when Prisma Access Agent 25.7.0.10 establishes a tunnel connection to a gateway, SSH connections initiated from a different subnet to a remote host are lost or cannot be established.
## PANG-10022
An issue exists with Prisma Access Agent on Arch Linux ARM where HIP reports are not sent to gateways after successful Prisma Access Agent Manager (endpoint manager) authentication and gateway connection. The agent shows empty HIP status despite active gateway and websocket connections. This occurs because outbound TCP SYN packets are blocked due to missing source application configuration in firewall rules on Arch Linux. The issue can block users if previous HIP reports don't match policy requirements.
**Workaround:** Add the destination domain (e.g., gpcloudservice.com) to the firewall allow list to resolve the SYN packet blockage and enable proper HIP report transmission.
## PANG-10020
An issue exists with Prisma Access Agent for Linux on Arch Linux ARM where the websocket connection to the Prisma Access Agent Manager (or endpoint manager) goes down after authentication, causing HIP and keepalive failures. The agent cannot obtain source application information on this platform, resulting in endpoint manager traffic being incorrectly routed through the tunnel instead of direct connection.
**Workaround**: For single Prisma Access tenant deployments without enforcer mode, administrators must add Prisma Access Agent endpoint manager FQDN rules for both DATA and DNS traffic to go via DIRECT in the forwarding profiles. In enforcer scenarios where users switch between tenants, administrators need to configure DATA and DNS destination rules for all essential domains to go via DIRECT:
- *.epm.gpcloudservice.com (endpoint manager domain)
- *.gw.gpcloudservice.com (gateway domain)
## PANG-9990
An issue exists with Prisma Access Agent for Linux where SSH incoming connections do not work. When attempting to SSH into an endpoint that has the Prisma Access Agent installed, the connection fails. This prevents remote SSH access to devices running the agent, blocking workflows that rely on SSH connectivity.
## PANG-9870
An issue exists with Prisma Access Agent for Linux where application filtering does not work on Arch Linux ARM due to eBPF failing to load. Traffic steering according to forwarding profiles fails when the tunnel is disconnected, causing traffic to hit default rules instead of configured policies.
## PANG-9351
An issue exists with Prisma Access Agent for Linux where root users can delete nftable rules, resulting in all traffic bypassing the network filtering module.
## PANG-9349
```caveat
PANG-9331
```
Prisma Access Agent for Linux does not currently support Docker traffic for system updates or package installations within containers. When you run Docker containers on a Linux device with Prisma Access Agent active, all outgoing traffic from Docker is routed through the secure tunnel by default, which causes system updates and package installations to fail within the container environment.
**Workaround**: For agents running in on-demand mode, temporarily disconnect the Prisma Access Agent tunnel to perform container updates or install packages, then reconnect the tunnel after completing these operations.
web/data/issues/Prisma Access Agent/known/25.7.1_2026-03-17.md
+25
View File
@@ -0,0 +1,25 @@
---
type: Known
product: Prisma Access Agent
version: 25.7.1
---
## PANG-10158
When attempting to install Prisma Access Agent on an Ubuntu 24 virtual machine (VM) via SSH or RDP, the installation fails with an error indicating that the user environment was not preserved, even when the `sudo -E` option is used.
## PANG-10342
An issue exists where the Prisma Access Agent on Debian Linux experiences intermittent SSL tunnel disconnection and automatic reconnection due to health keepalive timeouts. When using the agent with an SSL tunnel configuration on Debian, the tunnel repeatedly disconnects and reconnects without any manual intervention from the user. This behavior disrupts the stability of the connection, potentially affecting user productivity and network reliability.
## PANG-10309
An issue exists where the Prisma Access Agent on Linux fails to perform HIP updates when using the PACLI command. When administrators attempt to execute the `pacli hip update` command while the agent is connected, the operation fails because HIP updates are not supported yet.
## PANG-10271
When upgrading Prisma Access Agent from version 25.7.1.1 to 25.7.1.2 on a Debian ARM system, a crash file is automatically generated upon launching or using Prisma Access Agent.
## PANG-10019
After installing Prisma Access Agent 25.6.0.10 on an Arch Linux x86 system, a coredump occurs when attempting to connect to an endpoint management (EPM) system and a gateway.
web/data/issues/Prisma Access Agent/known/25.7_2026-03-17.md
+19
View File
@@ -0,0 +1,19 @@
---
type: Known
product: Prisma Access Agent
version: 25.7
---
## PANG-10092
An issue exists where Prisma Access Agent incorrectly displays a success message when the user issue reporting functionality fails to upload diagnostic logs to the server. When users attempt to report an issue through the Prisma Access Agent app, the system shows a message indicating that the report was sent successfully, even when the underlying log upload process has actually failed due to connectivity or server issues.
## PANG-10057
An issue exists where the user consent dialog box remains visible on an endpoint even after the diagnostic collection request has timed out due to lack of user response. When an administrator initiates a diagnostic collection process that requires user consent, a pop-up window appears on the endpoint asking the user to approve or deny the request. If the user does not respond to this consent dialog within the designated time period, the administrative job times out, but the consent pop-up window continues to display on the user's screen indefinitely.
## PANG-10005
An issue exists where Prisma Access Agent cannot maintain simultaneous connections for both tunnels when a third-party VPN solution adds a default route to the device. This problem occurs specifically when third-party VPN clients, such as AnyConnect, are configured to modify the system's default routing table, resulting in only one tunnel being able to remain active at any given time. Since Prisma Access Agent does not control how third-party VPN clients operate or influence the underlying system routing, conflicts arise when both solutions attempt to manage network traffic routing simultaneously.
**Workaround**: Modify the third-party VPN configuration to remove the default route setting, which will allow the Prisma Access Agent bypass functionality to operate correctly and maintain both tunnel connections as intended.
web/data/issues/Prisma Access Agent/known/26.1-Linux_2026-03-17.md
+45
View File
@@ -0,0 +1,45 @@
---
type: Known
product: Prisma Access Agent
version: 26.1-Linux
---
## PANG-11201
```resolved
Resolved in Prisma Access Agent 26.1.1
```
On Prisma Access Agents for Linux, when NetworkManager is configured not to manage the tunnel interface, the Prisma Access Agent connection profile becomes stuck in an "activating" state, resulting in a tunnel connect and disconnect loop that prevents successful establishment of the tunnel.
## PANG-11153
```resolved
Resolved in Prisma Access Agent 26.1.1
```
On Linux, the Prisma Access Agent may experience recurring PASrv process crashes approximately every 20 seconds due to abnormal termination, causing the agent to become unresponsive and preventing log collection. This issue occurs primarily during agent upgrade operations.
## PANG-10947
When Prisma Access Agent is configured in on-demand mode on Arch Linux and the network connection is interrupted and then restored, the agent fails to automatically reconnect to the gateway. As a result, the agent remains in a disconnected state.
## PANG-10865
On Prisma Access Agent for Linux systems, the Prisma Access Agent user interface exhibits minor cosmetic and usability inconsistencies. The Location list lacks a line separator between entries and is not sorted alphabetically, with the exception of the "Best Location" option.
## PANG-10801
During a Host Information Profile (HIP) check on Prisma Access Agent for Linux, the system incorrectly validates certificates based solely on the issuer's Common Name (CN). This results in expired or revoked certificates being considered valid if their issuer's CN matches the configured criteria, potentially allowing non-compliant endpoints to pass HIP checks.
## PANG-10668
After upgrading to Prisma Access Agent version 26.1.0.25 on Arch Linux with KDE Plasma desktop environments, the settings page in the Prisma Access Agent app might appear partially blank when the operating system's dark theme is enabled. This prevents the display of relevant information on the settings page.
## PANG-9501
When using Prisma Access Agent on a system running Fedora 42 (GNOME), running the `pacli traffic log <n>` command does not show the log details.
## PANG-9196
When Prisma Access Agent is installed on a Linux virtual machine (VM) running on an ESXi host, and the VM undergoes network changes (such as connecting or disconnecting from gateways) or experiences a sleep/wake cycle, the entire VM and the ESXi host might become unresponsive. Access to the ESXi host is lost, and the system hangs for approximately 5 minutes before access is regained.
web/data/issues/Prisma Access Agent/known/26.1.1_2026-03-17.md
+41
View File
@@ -0,0 +1,41 @@
---
type: Known
product: Prisma Access Agent
version: 26.1.1
---
## PANG-11346
When Prisma Access Agent is connected on a Linux host system, Docker containers running on that host are unable to perform network communication using `curl` commands. Attempts to send `curl` traffic from inside a container result in a "Network is unreachable" error, even though the host system itself retains full network connectivity.
## PANG-11254
```resolved
Fixed in Prisma Access Agent 26.1.2 (PANG-11311)
```
When the Dynamic Privilege Access-enabled Prisma Access Agent is in the notify-before-re-authentication period displaying a countdown timer banner and **Aggressive Authentication** is not enabled, switching projects in the Prisma Access Agent app triggers re-authentication and updates the User Refresh Token expiry time. However, the countdown timer banner continues to display the previous timer value until it expires, despite the successful re-authentication. Once the original timer completes, the banner disappears.
## PANG-11199
For Panorama Managed NGFW deployments, Prisma Access Agent ignores the IPv6 address field in external gateway configurations received from Endpoint Manager get-config responses. When an IPv6 address is configured for an external gateway in the Edit External Gateway window in Strata Cloud Manager, Prisma Access Agent fails to process it. For dual-stack gateways configured with both IPv4 and IPv6 addresses, only the IPv4 address is recognized and the IPv6 address is completely ignored. For IPv6-only gateways, Prisma Access Agent throws an invalid configuration error and the gateway cannot be established.
**Workaround**: Configure the gateway using a Fully Qualified Domain Name (FQDN) instead of an IPv6 address.
## PANG-11178
When Prisma Access Agent is configured with portal authentication and the **Save User Credentials** option disabled, and the user clicks on the re-authentication banner in the agent app when the session is about to expire, an "Authentication Failed" error notification is displayed instead of prompting the user to enter their credentials. The user is not given the opportunity to re-authenticate as expected.
## PANG-11141
When Prisma Access Agent is configured with client certificate authentication or portal authentication, the User Refresh Token does not automatically refresh at the end of its expiry period. The agent fails to attempt token renewal, which can result in authentication expiration and loss of user access once the User Refresh Token expires.
## PANG-11103
When Prisma Access agent is actively connected to a gateway and the IPv6 pool is disabled on the tenant, the agent retains a stale IPv6 tunnel IP address. This stale IP persists on the specific gateway that was connected during the configuration change, even after the agent signs out and signs back in. The gateway address and IPv4 tunnel IP correctly update to reflect the new configuration, but the IPv6 tunnel field incorrectly displays the old IPv6 pool IP instead of "N/A". Gateways that were not actively connected during the configuration change correctly show no IPv6 tunnel IP.
Users may incorrectly believe they still have IPv6 connectivity when they do not. This stale data complicates troubleshooting and causes automated tests to receive incorrect state information.
## PANG-10925
When a device with Prisma Access Agent configured for Dynamic Privilege Access wakes up from sleep mode, the agent reconnects without enforcing re-authentication, even when **Aggressive Authentication** is enabled. The agent establishes connectivity without requiring the user to provide credentials again, bypassing the expected authentication enforcement.
web/data/issues/Prisma Access Agent/known/26.1.2_2026-03-17.md
+9
View File
@@ -0,0 +1,9 @@
---
type: Known
product: Prisma Access Agent
version: 26.1.2
---
## PANG-11429
When a Host Information Profile (HIP) report is generated by a Prisma Access Agent connected via an IPSec/SSL tunnel to a gateway with an IPv6 address, the report fails to be sent to the gateway. The HIP report is successfully sent to Endpoint Manager but fails to reach the gateway due to a connection error.