Add Prisma Access Agent known and addressed issues

2026-03-16 21:35:47 -05:00
parent f1e49c5830
commit 70dcd896be
25 changed files with 1054 additions and 0 deletions
@@ -0,0 +1,14 @@
+---
+type: Addressed
+product: Prisma Access Agent
+version: 25.3.1
+---
+
+## PANG-7012
+
+Fixed an issue where the embedded browser for Prisma Access Agent
+did not reuse the Windows Hello token for reauthentication, forcing
+users to manually enter their credentials despite having Windows
+Hello enabled on their devices. The embedded browser now properly
+leverages existing Windows Hello authentication tokens for seamless
+reauthentication without requiring manual credential entry.
@@ -0,0 +1,26 @@
+---
+type: Addressed
+product: Prisma Access Agent
+version: 25.3
+---
+
+## PANG-6738
+
+Fixed an issue where certificate authentication failed on Windows
+devices when certificates were stored in the machine certificate
+store, preventing the Prisma Access Agent from properly
+authenticating users with machine-level certificates. The agent now
+correctly accesses and utilizes client certificates from the machine
+certificate store, eliminating the need to manually import
+certificates to the user's personal certificate store as a
+workaround.
+
+## EPM-4616
+
+Fixed an issue where newly added internal gateways weren’t
+visible in existing Prisma Access Agent settings, preventing
+administrators from updating agent configurations with recently
+added internal gateways. The agent settings now automatically
+refresh to display all available internal gateways, including those
+added after the initial configuration, eliminating the need to
+create new agent settings to access newly added gateways.
@@ -0,0 +1,51 @@
+---
+type: Addressed
+product: Prisma Access Agent
+version: 25.4
+---
+
+## PANG-7949
+
+Fixed an issue where the Dynamic Privilege Access enabled Prisma
+Access Agent was unable to connect to a gateway after upgrading an
+endpoint to Windows 11 24H2. Following the Windows upgrade, the
+Prisma Access Agent would lose the ability to establish gateway
+connections, even though the Endpoint Manager (EPM) connection
+remained functional. This issue occurred consistently across systems
+that had undergone the Windows 11 24H2 upgrade, affecting the
+agent's ability to connect to any configured gateways while
+maintaining normal endpoint manager connectivity.
+
+## PANG-7865
+
+Fixed an issue where the Prisma Access Agent on Windows did not
+properly honor updated session timers after a user extended their
+session through the embedded browser. The agent now correctly adopts
+the newly extended session duration when users authenticate through
+the session expiry banner, preventing premature session termination
+and ensuring the Prisma Access Agent icon remains responsive in the
+system tray throughout the extended session period.
+
+## PANG-7960
+
+Fixed an issue where the Prisma Access Agent on Windows blocked
+authentication in the embedded browser due to the
+Best Available - Fail Safe mechanism
+in the forwarding profile triggering during the initial
+connection attempt. The embedded browser now properly bypasses
+the fail-safe mechanism when the agent is configured to run in
+on-demand mode, enabling successful authentication on the first
+attempt without requiring users to cancel and retry the
+authentication process after a reboot.
+
+## PANG-7309
+
+Fixed an issue where the Prisma Access Agent on Windows failed to
+automatically switch from an external gateway to an internal gateway
+when the user's device woke from sleep mode after being connected to
+different network environments. The agent now properly detects
+network changes upon waking from sleep. It also automatically
+switches to the appropriate internal gateway without requiring
+manual sign-out via the pacli epm signout
+command and subsequent reauthentication through the Prisma Access
+Agent app.
@@ -0,0 +1,84 @@
+---
+type: Addressed
+product: Prisma Access Agent
+version: 25.6.2
+---
+
+## PANG-9620
+
+Fixed an issue where the Prisma Access Agent would automatically
+disconnect and remain disconnected without attempting to
+reconnect, leaving users without network protection. The problem
+occurred when the agent lost its connection to the endpoint
+management server and failed to re-establish the connection
+automatically as expected.
+
+This occurred due to a DNS resolution timing conflict in certain
+network environments where the primary DNS server was
+unresponsive while the secondary DNS server was functioning
+properly. The fix adjusts the DNS resolution process to ensure
+proper failover occurs when the primary DNS server is
+unavailable, allowing the agent to maintain connectivity and
+automatically reconnect when network issues are resolved.
+
+## PANG-9630
+
+Fixed an issue where the Prisma Access Agent would become stuck
+in a "Connecting" state after a network switch when attempting
+to connect to an internal gateway. This problem occurred when
+users experienced a network change that caused them to be logged
+out from the tunnel, and while the Prisma Access Agent endpoint
+manager web-socket would successfully reconnect, the Prisma
+Access Agent app would remain stuck displaying "Connecting"
+indefinitely.
+
+## PANG-9276
+
+Fixed an issue where the Spyder application would display
+"Permission denied" errors and fail to work properly when Prisma
+Access Agent was installed on the same computer. Users found
+that Spyder would only function normally after completely
+removing the Prisma Access Agent from their system, creating a
+conflict between the two programs. The fix ensures that the
+Prisma Access Agent no longer interferes with Spyder, allowing
+both programs to run simultaneously without conflicts while
+maintaining the agent's security protection for other
+applications on the system.
+
+## PANG-9220
+
+Fixed an issue where users encountered "Server Enrollment
+failure" errors after installing Prisma Access Agent version
+25.4.0.29, preventing them from successfully connecting to their
+organization's network. The problem occurred during the initial
+setup process when the agent attempted to register with the
+endpoint management server but failed with messages indicating
+an invalid enrollment secret. This occurred due to a
+compatibility issue between the agent's security enrollment
+method and certain Windows system security components. When the
+agent tried to use the primary secure enrollment process, some
+Windows systems would reject the connection due to unsupported
+security protocols, causing the entire enrollment to fail.
+
+## PANG-9092
+
+Fixed an issue where the Prisma Access Agent would freeze and
+become stuck in a non-responding state. The problem occurred
+when the application attempted to update multiple settings at
+the same time from different parts of the program, causing
+conflicts that would lock up the entire application. This
+resulted in users being unable to interact with Prisma Access
+Agent, as the interface would stop responding and the agent
+would appear to hang indefinitely. The fix ensures that all
+setting updates are now processed in a controlled, sequential
+manner to prevent these conflicts and maintain application
+responsiveness.
+
+## PANG-9067
+
+Fixed an issue where the Prisma Access Agent on macOS 15.6.1 failed to connect to external gateways when selecting Best Location and incorrectly switched to internal connectivity. This issue manifested in two specific scenarios:
+
+1. After upgrading the operating system from macOS 15.6 to 15.6.1, Prisma Access Agent would incorrectly connect to an on-premises gateway instead of maintaining its connection to the external Prisma Access gateway that it was using prior to the OS upgrade.
+2. When users selected Best Location from the Prisma Access Agent app, the agent would search through all available Prisma Access gateways but then inappropriately switch to Internal mode, even when connected to a home WiFi network where Internal Host Detection should not be triggered.
+
+This occurred due to the improper cleanup of the on-premises tunnel routes during the Best Location selection process, which caused the system to incorrectly determine that it was on an internal network and activate the Internal Host Detection functionality. This resulted in users being unable to establish proper external gateway connections through Prisma Access Agent on the updated macOS version, forcing the agent into internal mode when external connectivity was required and available.
@@ -0,0 +1,33 @@
+---
+type: Addressed
+product: Prisma Access Agent
+version: 25.6
+---
+
+## PANG-8845
+
+Fixed an issue where the Prisma Access Agent would incorrectly
+remain bound to port 0 when switching between Prisma Access
+Agent endpoint manager configurations with different proxy
+settings, causing endpoint traffic to Explicit Proxy (EP) to
+fail. This problem occurred when the agent initially connected
+to an endpoint manager without agent proxy configured, then
+switched to a different endpoint manager that had a proxy port
+configured, but failed to update its port binding from port 0 to
+the new proxy port. The agent now correctly updates its port
+binding when switching between endpoint manager configurations
+with different proxy settings, eliminating traffic routing
+disruptions.
+
+## PANG-8200
+
+Fixed an issue where the Prisma Access Agent on Windows devices
+would incorrectly display the previously connected server FQDN in
+the Server Name field after executing the pacli epm
+signout command without the --keep
+parameter, instead of properly resetting to show Select
+Server Name as expected. This inconsistency between
+Windows and Mac platforms has been resolved, ensuring that both
+operating systems now consistently reset the login view and display
+the default Select Server Name prompt when
+signing out without preserving server information.
@@ -0,0 +1,14 @@
+---
+type: Addressed
+product: Prisma Access Agent
+version: 25.7.1
+---
+
+## PANG-9876
+
+Fixed an issue where the PASrv service would crash and generate
+crash files on a newly installed Prisma Access Agent running in
+Always On mode on Linux systems. The crash occurred after user
+sign-in during the tunnel connection process while the agent was
+operating in Always On mode. This issue affected Linux environments,
+particularly Ubuntu 22 x86 systems.
@@ -0,0 +1,42 @@
+---
+type: Addressed
+product: Prisma Access Agent
+version: 25.7
+---
+
+## PANG-9242
+
+Fixed an issue where the Prisma Access Agent on macOS and Windows
+would fail to properly clean up tunnel interface routing table
+entries when executing the pacli epm
+signout command after a gateway shutdown had
+left the agent in a Disconnected state. This problem occurred
+when agents that were previously connected to a tenant became
+disconnected due to gateway shutdowns, and users subsequently
+attempted to sign out using the pacli
+command.
+
+## PANG-8945
+
+Fixed an issue where the Prisma Access Agent Manager would
+incorrectly handle ICMP traffic configuration after upgrading to
+the latest version. When the Block Non-TCP and
+Non-UDP based traffic when connected to tunnel
+option was disabled by default following an upgrade, the
+pacli traffic show command would
+inaccurately display Allow non-tunnel outbound ICMP
+when connected to tunnel as true, while the
+underlying Allow ICMP for troubleshooting
+value was incorrectly being passed as false instead of the
+expected true value.
+
+The agent now properly synchronizes the ICMP traffic
+configuration values to ensure consistent behavior between the
+configuration display and actual traffic routing.
+
+## PANG-8929
+
+Fixed an issue where the Prisma Access Agent on Windows would
+incorrectly report "error: 513 - PASrv is unreachable, please
+confirm it's running" when executing the pacli epm
+status command during reinstallation scenarios.
@@ -0,0 +1,29 @@
+---
+type: Addressed
+product: Prisma Access Agent
+version: 26.1.1
+---
+
+## PANG-11201
+
+Fixed an issue on Prisma Access Agents for Linux where the Prisma
+Access Agent connection profile became stuck in an "activating"
+state when NetworkManager was configured not to manage the
+tunnel interface, resulting in a tunnel connect and disconnect
+loop that prevented successful establishment of the tunnel.
+
+## PANG-11153
+
+Fixed an issue where the Prisma Access Agent on Linux experienced
+recurring PASrv process crashes approximately every 20 seconds
+due to abnormal termination during agent upgrade operations,
+causing the agent to become unresponsive and preventing log
+collection.
+
+## PANG-10723
+
+Fixed an issue where the Prisma Access Agent installer script on
+Linux incorrectly modified permissions of the entire
+/opt installation directory. The
+installer script now only modifies
+/opt/paloaltonetworks.
@@ -0,0 +1,54 @@
+---
+type: Addressed
+product: Prisma Access Agent
+version: 26.1.2
+---
+
+## PANG-11395
+
+Fixed an issue where the Prisma Access Agent on Windows 11
+laptops did not reauthenticate with the internal gateway when
+transitioning between network interfaces (for example, from
+Wi-Fi to LAN) and temporarily having more than one active
+network interface. This prevented the IP-user mapping from being
+updated on the NGFW firewall, causing traffic from the user's IP
+to be unrecognized.
+
+## PANG-11328
+
+Fixed an issue where DNS resolution failed for Microsoft 365
+services (MS Teams and Outlook) running Prisma Access Agents on
+dual-stack Windows devices.
+
+## PANG-11311
+
+Fixed an issue where the Prisma Access Agent displayed an
+erroneous "Your connectivity might be affected. Please try again
+or contact your administrator" error notification when a user
+manually disconnected from an on-demand connection.
+
+## PANG-11293
+
+Fixed an issue where Prisma Access Agent version 26.1 was unable
+to retrieve the status of disk encryption for Host Information
+Profile (HIP) reports, causing HIP checks to fail and denying
+access to private applications.
+
+## PANG-11284
+
+Fixed an issue where, after upgrading to Prisma Access Agent
+version 26.1.1.10 on Windows, users attempting to log in with
+Microsoft Entra SSO experienced login failures and HIP check
+compliance errors (Error 53000) because the embedded browser
+incorrectly prompted for a plugin installation."
+
+## PANG-11274
+
+Fixed an issue on macOS devices where gateway connections would
+fail or experience significant delays after waking from sleep.
+This occurred because the Prisma Access Agent service (daemon)
+attempted to access client certificates in the login keychain
+through the user interface (UI) while the UI was still asleep.
+These requests would queue up and process sequentially once the
+UI woke, causing older requests to time out and preventing
+timely gateway connections.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.