Prisma Access Troubleshooting practice questions

Run 'show system resources' to check CPU utilization of the Panorama VM.

Why it fails: Panorama resource utilization does not reflect data-plane connectivity over Service Connection tunnels.

SSH to the Prisma Access node or use the Panorama CLI to run 'test security-policy-match' for the LDAP traffic.

Why it fails: test security-policy-match evaluates policy rules, not active reachability or packet drop issues.

Use the CLI command 'ping source <service-connection-ip> <ldap-server-ip>' from the Panorama management plane.

Why it fails: Panorama management plane pings do not traverse the Prisma Access data plane Service Connection tunnels.

Disable SSL decryption on the Security Predefined Policy.

Why it fails: SSL decryption affects throughput inspection, not IPsec tunnel stability or IKE rekey storms.

Change the mobile user portal authentication profile.

Why it fails: Portal authentication does not impact established IPsec site-to-site tunnels.

Restart the GlobalProtect service on the remote user's endpoint.

Why it fails: GlobalProtect service restarts are irrelevant for site-to-site Remote Network IPsec tunnel issues.

Panorama > Cloud Services > Status > BGP Peers.

Why it fails: There is no specific standalone 'BGP Peers' sub-tab under Cloud Services Status; routing details are monitored via ACC or dynamic routing status interfaces.

Monitor > Dynamic Updates > BGP.

Why it fails: Dynamic Updates is used for applications, threats, and antivirus updates, not routing protocols.

Policies > NAT.

Why it fails: NAT policies handle IP translation, not routing table verification.

Panorama > Cloud Services > Setup > Dynamic Updates.

Why it fails: Dynamic updates are managed globally via Panorama's standard dynamic update workflows, pushed to Prisma Access cloud locations.

Prisma Access > Service Setup > Threat Prevention.

Why it fails: Service setup handles location provisioning, not signature schedule management.

Monitor > Dynamic Updates > Status.

Why it fails: Monitor dynamic updates show history, but scheduling and enforcement are configured under Device Deployment.

Objects > Custom Objects > URL Filtering.

Why it fails: URL filtering manages category blocking and credential enforcement, not proxy HTTP header insertion.

Network > GlobalProtect > Gateways > Agent > Client Settings.

Why it fails: GlobalProtect client settings control agent behavior, not explicit proxy HTTP header manipulation.

Policies > NAT.

Why it fails: NAT rules alter IP addresses and ports, not HTTP application headers.

Device > Setup > Content ID.

Why it fails: Content ID settings manage threat inspection parameters, not mobile user traffic steering routes.

Policies > Decryption.

Why it fails: Decryption rules determine whether to inspect TLS traffic, not application routing.

Objects > Custom Objects > URL Filtering.

Why it fails: URL filtering manages categorization, not application routing paths.

Verify the BGP routing table for Service Connection prefixes.

Why it fails: BGP routing controls IP packet forwarding, not TLS/SSL cryptographic certificate validation.

Check the GlobalProtect client version installed on mobile workstations.

Why it fails: GlobalProtect client versions do not directly govern SSL decryption certificate validation warnings.

Objects > Custom Objects > URL Filtering.

Why it fails: URL filtering objects manage web category rules.

Policies > NAT configuration view.

Why it fails: NAT configuration defines address translation rules, not connection health.

Device > Log Settings forwarding profiles.

Why it fails: Log forwarding profiles configure syslog/HTTPS export destinations.

Monitor > Logs > Threat.

Why it fails: Threat logs track security attacks and vulnerabilities.

Device > High Availability state monitor.

Why it fails: HA monitoring tracks node redundancy, not routing table entries.

Objects > Custom Objects > URL Filtering.

Why it fails: URL filtering manages web browsing categories.

Verify the BGP AS number on the Service Connection.

Why it fails: Service connections connect data centers, not mobile user endpoints to local printers.

Check the WildFire file analysis submission timeout settings.

Why it fails: WildFire submission settings manage malware analysis, not local VPN routing or printer access.

Verify the BGP ASN configured on the Service Connection.

Why it fails: BGP ASN settings control routing adjacencies, not threat intelligence feed retrieval.

Check the GlobalProtect portal certificate expiration date.

Why it fails: GlobalProtect certificates govern client SSL trust, not threat feed downloads.

traffic.log

Why it fails: Traffic logs record session initiation and termination, not the internal SAML token exchange details.

globalProtectPortal.log

Why it fails: This log covers portal connection requests and configurations, not detailed backend IdP SAML assertions.

threat.log

Why it fails: Threat logs record security violations like spyware or vulnerability exploits, not authentication flows.

Panorama > Setup > Operations

Why it fails: Panorama's Operations page shows commit status, tasks and system health, not per-application traffic from remote users. It is the right place to monitor configuration jobs and device state, whereas application usage is viewed in the Prisma Access app logs and dashboards.

Panorama > Managed Devices > Summary

Why it fails: Managed Devices Summary shows device connectivity, software version and configuration sync state, not live application usage. It is tempting as a central Panorama view of every managed firewall, but it carries no session or App-ID data, so it cannot confirm which cloud storage applications remote users are running.

Prisma Access > Cloud Services > Dashboard > Status

Why it fails: The Cloud Services Status page reports infrastructure health and licence status, not per-application traffic. It is tempting because it is the only Cloud Services dashboard entry, but application visibility for policy troubleshooting lives in the Monitor logs or App Scope views, which record which cloud storage apps remote users actually reached.

Data-plane packet capture (pcap) of HTTP/2 server streams

Why it fails: Data-plane packet captures of HTTP/2 are not the standard or most direct tool for diagnosing SAML token decoding issues.

Panorama ACC threat widget counters

Why it fails: ACC threat widgets display malware and exploit counts, not SAML authentication handshakes.

Use the Prisma Access CLI to ping the application from the mobile user's device.

Why it fails: Pinging from the mobile user's device tests end-to-end connectivity but does not isolate the routing issue within Prisma Access. The administrator needs to check the service connection's routing table to see if the route exists. A ping might fail due to the missing route, but it doesn't show where the route is missing.

Review the GlobalProtect logs for the user.

Why it fails: GlobalProtect logs show connection events, authentication, and HIP data, but they do not include routing information for internal applications. They can confirm that the user connected successfully but won't reveal why traffic to a specific subnet is failing. The issue is likely in the routing configuration, not the user's connection.

Check the service connection status in the Prisma Access dashboard.

Why it fails: The service connection status shows whether the connection is up and healthy, but it does not provide detailed routing information for specific remote networks. While useful for a high-level view, it cannot confirm if the route to the internal application is correctly advertised or learned. The administrator needs more granular routing details.

Prisma Access Dashboard

Why it fails: The Prisma Access Dashboard provides an overview of the deployment, including health and status, but it does not show per-user DNS settings. It is designed for monitoring and management, not for inspecting client-specific configurations. The administrator must look elsewhere for DNS suffix details.

GlobalProtect App Logs

Why it fails: GlobalProtect App Logs on the client record connection events, authentication, and errors, but they do not display the DNS suffix or search domains configured. While they might show DNS-related errors, they do not provide the actual DNS settings. The administrator needs a tool that shows the applied configuration.

Prisma Access CLI 'show dns-proxy' command

Why it fails: The 'show dns-proxy' command is not a valid command in Prisma Access CLI for viewing client DNS settings. Prisma Access does not have a DNS proxy configuration in the same way as a firewall. The administrator should not rely on non-existent commands.

URL Filtering logs in the Prisma Access platform

Why it fails: URL Filtering logs show the category assigned to a URL and the action taken, but they are not a lookup tool. They record past sessions and can be used to verify categorization after the fact, but for a quick, on-demand check of how a URL is classified, a dedicated lookup tool is more efficient.

GlobalProtect app logs on the user's endpoint

Why it fails: GlobalProtect app logs show connection and tunnel events on the endpoint, not URL categorization performed by Prisma Access. They cannot provide information about how a URL is classified in the cloud service, so they are not useful for this troubleshooting step.

Threat logs filtered by the application name

Why it fails: Threat logs record security events such as viruses, spyware, and vulnerabilities, not URL categorization. They will not show which URL category the SaaS application falls under. Using threat logs to find categorization would be ineffective and misleading.

show vpn flow name <tunnel-name>

Why it fails: This command displays VPN flow information such as packet counters and throughput, but it does not show the Phase 2 SA state or configuration mismatches. It can indicate that traffic is flowing, but if the tunnel is down due to a Phase 2 issue, there would be no flow. Thus, it is not the right choice for diagnosing the root cause.

show vpn ike-sa gateway <gateway-name> detail

Why it fails: Even with the detail keyword, this command still focuses on IKE Phase 1 SA details, such as vendor IDs and NAT-T status. It does not include Phase 2 child SA information. Since the problem is suspected at Phase 2, this command would not provide the necessary insight, making it incorrect for this scenario.

show vpn ike-sa gateway <gateway-name>

Why it fails: This command displays IKE Phase 1 security associations, including encryption and authentication algorithms, but it does not show Phase 2 child SA status or traffic selectors. A Phase 2 mismatch would not be visible here, so it fails to diagnose the suspected issue. The engineer needs to inspect the child SA state, which this command does not provide.

Change the GlobalProtect portal agent configuration to force all DNS traffic through the tunnel without regard to destination.

Why it fails: Forcing all DNS through the tunnel without matching the Service Connection domain list still leaves the endpoint without a path to the internal resolvers for those specific domains. The Service Connection must explicitly advertise or include the domains, otherwise the tunnel does not carry that query traffic, and public resolution continues regardless of the portal setting.

Add the internal DNS servers to the Remote Network's static route table so the branch routes DNS queries to them directly.

Why it fails: Static routes on the remote network control IP forwarding for tunnel traffic, not which resolver the endpoint selects for name resolution. Even with a route to the internal server, the client will still use the resolver it learned from its local network configuration unless the Service Connection domain list directs those queries into the tunnel.

Enable DNS Security on the Service Connection so that public resolvers are automatically overridden for internal domains.

Why it fails: DNS Security is a threat-prevention feature that inspects DNS queries against threat signatures; it does not redirect internal domain resolution to on-premises DNS servers. Enabling it changes inspection behavior, not the resolver selection logic, so internal names would still be answered by the public resolvers the endpoint learned from its local DHCP configuration.

Run a traceroute from the mobile user's device to the destination.

Why it fails: A traceroute from the user's device can show the network path, but it may not reveal the internal Prisma Access service connection routing because the user's traffic is encapsulated. It might show the public IP of the service connection, but not which service connection or its internal path. The administrator needs Prisma Access-specific tools.

Check the GlobalProtect logs for the user's connection details.

Why it fails: GlobalProtect logs show connection events, authentication, and the selected gateway, but they do not provide the full traffic path through service connections. They might indicate which gateway the user connected to, but not the subsequent routing to the internet. The administrator needs more detailed path information.

Review the mobile user's HIP profile for network location.

Why it fails: HIP profiles contain host information like OS, patch level, and security software, not network path or service connection details. They are used for security policy enforcement, not for troubleshooting traffic routing. The administrator should not rely on HIP data for path verification.