GlobalProtect and Prisma Access Best Practices: Configuration and Troubleshooting

Overview

GlobalProtect and Prisma Access are Palo Alto's remote access solutions — GlobalProtect for on-premise NGFW-hosted VPN, and Prisma Access for cloud-delivered ZTNA/VPN. Both use the same agent but the infrastructure behind them is fundamentally different. GlobalProtect terminates tunnels on a firewall you manage; Prisma Access terminates on Palo Alto's cloud infrastructure and applies policy through Panorama-managed configuration. When either breaks, the symptoms look the same to the user — the client connects but traffic doesn't flow, or the client fails to connect at all. This guide covers the architecture, configuration best practices, and a systematic troubleshooting workflow for both platforms.

Prisma Access Service Connection

The service connection is the tunnel between Prisma Access cloud and your on-premise data center. Without it, GP users on Prisma can reach the internet but cannot reach internal resources.

# Prisma Access service connection requirements:
#   1. IPSec tunnel from on-prem firewall to Prisma Access infrastructure IP
#   2. BGP session over the tunnel to advertise internal prefixes into Prisma
#   3. Return traffic: Prisma advertises GP client pool IPs to on-prem
#
# On-prem firewall (service connection termination):
#   IKE gateway → Prisma infrastructure IP (provided in SCM/Panorama)
#   IPSec tunnel → pre-shared key or certificate
#   BGP: advertise 10.0.0.0/8 (or specific internal subnets) to Prisma
#   BGP: receive GP client pool subnet from Prisma (e.g., 100.64.0.0/10)
#
# Common mistake: NAT on the service connection tunnel
# Do NOT NAT traffic going over the service connection
# Internal servers see GP client IPs — ensure return route exists

Part 5 — Troubleshooting: Step-by-Step

Step 1 — Agent Cannot Connect to Portal

# Agent error: "Unable to connect to the portal"
# or: "Portal not responding" / "Certificate error"
#
# Check 1: DNS resolution from client
C:\> nslookup portal.corp.com
# Must resolve to the portal external IP

# Check 2: TCP 443 reachability from client
C:\> Test-NetConnection portal.corp.com -Port 443
# TcpTestSucceeded must be True

# Check 3: Certificate — GP agent checks portal cert CN/SAN
# Portal cert must match the FQDN the agent is connecting to
# Self-signed certs cause "certificate error" unless pre-trusted by agent

# Check 4: On the firewall — is the management profile allowing GP?
# Network > Interfaces > [interface] > Advanced > Management Profile
# GlobalProtect must be checked

# Check 5: Firewall logs
admin@FW> show log system direction equal forward | match globalprotect
admin@FW> show log traffic dst-addr equal [portal-IP] proto equal 6 dport equal 443

Step 2 — Authentication Failures

# Agent error: "Authentication failed" / "Invalid credentials" / "MFA timeout"
#
# Check 1: Test the auth profile directly on the firewall
admin@FW> test authentication authentication-profile [PROFILE-NAME] username [user] password

# Check 2: LDAP/RADIUS server connectivity
admin@FW> show user server-monitor state all
# All configured auth servers must show "connected"

# Check 3: SAML (if using Azure AD / Okta)
# Verify IdP metadata is current in Device > Server Profiles > SAML Identity Provider
# Check certificate expiry on the IdP metadata
# Verify ACS URL matches exactly: https://portal.corp.com/SAML20/SP/ACS

# Check 4: User-ID mapping (if using domain auth)
admin@FW> show user ip-user-mapping all
admin@FW> show user group-mapping state all

# Check 5: GP system logs
admin@FW> show log system subtype equal globalprotect direction equal backward

Step 3 — Tunnel Connects but No Traffic Flows

This is the most common issue — the agent shows "Connected" but users cannot reach internal resources.

# Check 1: Verify tunnel is actually up and IP was assigned
# On client — check GP agent "Connection Details"
# Should show: virtual IP, gateway name, tunnel type (IPSec preferred)
C:\> ipconfig /all
# Look for "PANGP Virtual Ethernet Adapter" with a valid IP in the GP pool range

# Check 2: Routing — is traffic actually going into the tunnel?
C:\> route print
# For full tunnel: 0.0.0.0 route should point to GP adapter
# For split tunnel: internal subnets should route via GP adapter

# Check 3: On the firewall — is the GP session visible?
admin@FW> show globalprotect-gateway current-user
admin@FW> show globalprotect-gateway current-user user [username]

# Check 4: Security policy — is traffic hitting the right rule?
admin@FW> show log traffic from-zone GP-Zone action equal deny | last 20
# If traffic is being denied — identify the rule and fix

# Check 5: HIP — is the device failing posture check?
admin@FW> show globalprotect-gateway current-user | match hip
# HIP-compliant: yes = device passed posture
# HIP-compliant: no  = device is being blocked by HIP policy

# Check 6: DNS — can the client resolve internal names?
C:\> nslookup internal-server.corp.com
# Must use internal DNS server (assigned by gateway)
# If resolving via public DNS — DNS suffix or DNS proxy config issue

Step 4 — IPSec vs SSL Fallback Issues

# GP tries IPSec (UDP 4501/4500) first, falls back to SSL (TCP 443) if blocked
# SSL-only connections work but are slower — identify why IPSec is failing
#
# On client — check GP connection details for tunnel type
# Tunnel Type: IPSec = good
# Tunnel Type: SSL  = IPSec blocked, investigate
#
# Check UDP 4501 from client to gateway
C:\> Test-NetConnection gateway.corp.com -Port 4501
# If TcpTestSucceeded = False: hotel/ISP firewall blocking IPSec
# Solution: ensure SSL fallback is enabled in gateway config
# Or: use IPSec over TCP 443 (IPSec-over-SSL) for captive portal compatibility

Step 5 — Prisma Access Specific Issues

# Prisma: user connects to cloud but cannot reach internal resources
# Root cause: service connection issue between Prisma cloud and on-prem DC
#
# Check 1: Service connection tunnel status (Panorama / Strata Cloud Manager)
# Prisma Access > Service Connections > [connection name]
# Tunnel should show: Active, BGP: Established
#
# Check 2: On-prem firewall service connection tunnel
admin@FW> show vpn ike-sa gateway [prisma-ike-gw]
admin@FW> show vpn ipsec-sa tunnel [prisma-tunnel]
# Both should show active/established
#
# Check 3: BGP over service connection
admin@FW> show routing protocol bgp peer
# Prisma BGP peer must be Established
# Received prefixes: should include GP client pool (100.64.x.x or configured range)
# Advertised prefixes: should include internal subnets
#
# Check 4: Security policy — traffic from Prisma GP users
# Source zone: trust (arrives via service connection tunnel)
# Source IP: GP client pool IP (100.64.x.x)
# Ensure policy allows this source to reach internal destinations

Step 6 — GP Logs and Packet Capture

# Firewall — GlobalProtect system logs (most useful for auth/connection issues)
admin@FW> show log system subtype equal globalprotect
admin@FW> show log system subtype equal globalprotect severity equal critical

# Active GP users and their stats
admin@FW> show globalprotect-gateway current-user
admin@FW> show globalprotect-portal current-user

# Detailed user info including HIP, IP, tunnel type
admin@FW> show globalprotect-gateway current-user user [username] detail

# Client-side GP logs — critical for diagnosing connection failures
# Windows: C:\Program Files\Palo Alto Networks\GlobalProtect\PanGPS.log
# Mac:     /Library/Logs/PaloAltoNetworks/GlobalProtect/PanGPS.log
# Enable debug level: GP agent > Settings > Enable Debug Logging
# Key strings to search: "portal", "gateway", "hip", "ipsec", "error"

# Packet capture on the firewall (if traffic path unclear)
admin@FW> debug dataplane packet-diag set filter match source [client-GP-IP] destination [internal-server]
admin@FW> debug dataplane packet-diag set log on
admin@FW> debug dataplane packet-diag show setting
admin@FW> debug dataplane packet-diag show log

Quick Reference — Common GP Issues

GlobalProtect / Prisma Hardening Checklist

• Portal and gateway use a valid CA-signed certificate — not self-signed — matching the FQDN
• Certificate expiry monitoring in place — alert at 30 days before expiry
• Authentication uses MFA — password-only auth is not acceptable for remote access
• HIP profiles enforce minimum AV, patch level, and disk encryption before granting access
• Security policy has an explicit deny + log rule for HIP non-compliant devices (do not rely on implicit deny)
• Split tunnel is configured for SaaS exclusions — O365, Zoom, Webex bypass the tunnel
• GP IP pool does not overlap with any internal subnet — overlaps cause silent routing failures
• Internal DNS servers are pushed via gateway — without this, split tunnel users cannot resolve internal FQDNs
• pre-logon is enabled for domain-joined Windows machines — ensures machine cert auth before user login
• Prisma service connection has redundant tunnels — primary and secondary to different on-prem firewalls
• All GP/Prisma events are forwarded to SIEM — failed auth, HIP failures, and disconnects are alerting

Part 7 — Deep Client-Side Troubleshooting

Client-side issues are the hardest to diagnose remotely because you can't run commands on the firewall that directly show what the client is experiencing. This section covers systematic client-side diagnosis across Windows and macOS, log collection, network-level debugging, and common client OS problems.

Client Diagnostic Flow — Start Here

Before diving into logs, collect these facts from the user:

## Windows — collect all at once
C:\> ipconfig /all                      # Check PANGP adapter IP, DNS servers
C:\> route print                        # Check routing table for GP routes
C:\> nslookup corp-server.corp.com      # Does internal DNS resolve?
C:\> ping 10.0.1.1                      # Can you reach internal gateway?
C:\> tracert 10.0.1.1                   # How many hops? Which interface?
C:\> netstat -an | findstr 4501         # Is IPSec UDP socket open?
C:\> netstat -an | findstr 443          # Is SSL connection active?

## macOS — equivalent commands
$ ifconfig | grep -A5 utun             # GP tunnel interface (utun0, utun1, etc.)
$ netstat -rn                          # Routing table
$ scutil --dns                         # DNS resolver configuration
$ ping -c4 10.0.1.1                    # Internal reachability
$ traceroute 10.0.1.1                  # Path check

Reading the PanGPS Client Log

The GP agent log is the primary diagnostic tool for client-side issues. Know where to find it and what to search for:

## Log locations
# Windows: C:\Program Files\Palo Alto Networks\GlobalProtect\PanGPS.log
# macOS:   /Library/Logs/PaloAltoNetworks/GlobalProtect/PanGPS.log
# Linux:   /var/log/PanGPS.log

## Enable debug logging (do this BEFORE reproducing the issue)
# Windows: GP agent > Settings icon > Enable Debug Logging (checkbox)
# macOS:   Same location in GP agent settings
# Note: debug log is verbose — disable after collection

## Key strings to search in PanGPS.log:
#
# "Portal auth"        — portal authentication attempts and results
# "SSL connection"     — SSL handshake to portal/gateway
# "IKE"               — IPSec IKE negotiation
# "HIP report"        — HIP data collection (what was sent to firewall)
# "HIP match"         — result of HIP profile evaluation
# "Tunnel mode"       — which tunnel type was established (IPSec vs SSL)
# "disconnect"        — why the session ended
# "error"             — any error conditions
# "certificate"       — cert validation results

## Quick grep commands to find the important lines fast:
$ grep -i "error\|fail\|disconnect\|denied" PanGPS.log | tail -50
$ grep -i "hip" PanGPS.log | tail -20
$ grep -i "tunnel\|ipsec\|ssl" PanGPS.log | tail -20

Client Issue: "Connecting..." Spinner That Never Resolves

## This means the agent sent the auth request and is waiting for a response
# Most common causes: MFA timeout, SSO/SAML redirect issue, captive portal

## Check 1: Is a captive portal blocking the initial HTTPS connection?
C:\> curl -v https://portal.corp.com/global-protect/prelogin.esp
# Expected: HTTP 200 with XML response
# If redirected to hotel/airport login page: captive portal is intercepting
# Fix: connect to hotspot login page first, then re-connect GP
# GP has a built-in captive portal detection (opens browser automatically on newer versions)

## Check 2: SAML authentication spinning
# GP opens an embedded browser for SAML — if IdP is slow or MFA times out, spinner hangs
# PanGPS.log will show: "SAML auth started" but no "SAML auth complete"
# Fix: Check if user completed MFA within the timeout window
# Firewall fix: increase SAML authentication timeout in auth profile
# Network > GlobalProtect > Portals > [portal] > Authentication > Timeout

## Check 3: DNS not resolving the portal FQDN
C:\> nslookup portal.corp.com 8.8.8.8
# If NXDOMAIN or wrong IP: DNS issue (split-DNS, DNS filtering, ISP interference)
# Try: GP agent > Settings > enter portal IP address directly instead of FQDN

Client Issue: "Agent Disconnects After a Few Minutes"

## PanGPS.log will show disconnect reason — find it first
$ grep -i "disconnect\|reconnect\|keepalive\|DPD\|timeout" PanGPS.log | tail -30

## Cause A: NAT keepalive timeout (most common in hotel/home networks)
# NAT device times out idle UDP 4501 entries after 30–60 seconds
# Symptom: PanGPS.log shows "DPD timeout", session dies after ~30-60s of inactivity
# Fix on firewall: reduce IPSec keepalive interval
# Network > GlobalProtect > Gateways > [gw] > Agent > Tunnel Settings
# IPSec keepalive: set to 10 seconds (default is 30 — too long for aggressive NATs)

## Cause B: MTU mismatch causing IPSec tunnel blackhole
# Large packets get dropped silently — agent reconnects, works briefly, drops again
# Test: ping with large payload through tunnel
C:\> ping 10.0.1.1 -f -l 1400        # -f = don't fragment, -l = size
# If this fails but ping without -f works: MTU issue confirmed
# Fix on firewall: set tunnel MTU to 1350 in gateway config
# Or: enable TCP MSS clamping on the gateway interface
$ ping -c4 -M do -s 1400 10.0.1.1    # macOS/Linux equivalent

## Cause C: SSO token expiry forcing re-auth
# SAML/Kerberos token expires mid-session → gateway terminates tunnel
# PanGPS.log shows: "authentication cookie expired" or "re-authentication required"
# Fix: increase authentication cookie lifetime in portal config
# Network > GlobalProtect > Portals > [portal] > Agent > Authentication
# Cookie lifetime: 24 hours for corporate devices (default is often 3 hours)

Client Issue: Connected but Can't Access Specific Internal Resources

## This is the most nuanced client-side issue — isolate layer by layer

## Layer 1: Is the route to the resource in the client routing table?
C:\> route print | findstr 10.10.5      # look for specific subnet
# If missing: resource is in a subnet not covered by GP split tunnel config
# Fix: add missing subnet to gateway split tunnel include routes

## Layer 2: Does DNS resolve the resource hostname?
C:\> nslookup app-server.corp.com
# Should resolve to an internal IP via internal DNS
# If "can't find server" or resolves to public IP: DNS suffix or DNS server issue
# Check what DNS server is in use:
C:\> ipconfig /all | findstr "DNS Servers"
# GP adapter should show internal DNS (e.g., 10.0.0.53)
# If showing 8.8.8.8 or ISP DNS: gateway is not pushing DNS config

## Layer 3: Can you reach the IP directly (bypass DNS)?
C:\> ping 10.10.5.25                    # use raw IP of resource
# If ping to IP works but FQDN fails: DNS-only issue (see Layer 2)
# If ping to IP also fails: routing or firewall policy issue

## Layer 4: Traceroute to see where packets stop
C:\> tracert 10.10.5.25
# Hop 1 should be the GP gateway (internal IP in your tunnel))
# If packets stop at gateway: firewall policy blocking traffic
# If packets reach wrong hop: routing issue on firewall or internal network

## Layer 5: On the firewall — find the actual deny
admin@FW> show log traffic from-zone GP-Zone dst-addr 10.10.5.25 action equal deny
# Identify which rule is blocking and why (zone, HIP, user-group)

Client Issue: HIP Check Failures — Deep Dive

## The HIP report is what the GP agent sends to the gateway about device health
# View the raw HIP report the agent is sending:
# Windows: C:\Users\{user}\AppData\Local\Temp\hip-report.xml
# macOS:   /tmp/hip-report.xml
# This XML shows exactly what AV product, version, definition date, etc. was detected

## Common HIP failure: AV product name mismatch
# The HIP object on the firewall must match the exact product name GP detects
# Check hip-report.xml for the detected AV product name
# Example: Firewall HIP says "Windows Defender" but XML shows "Microsoft Defender Antivirus"
# Fix: match exact product name from XML in the HIP object definition

## Common HIP failure: AV definitions too old
# Check hip-report.xml for: <real-time-protection> and <last-full-update> timestamps
# Compare to HIP object threshold
# Fix: update AV definitions on client, or relax the age threshold in HIP object

## Check HIP match result on the firewall for a specific user
admin@FW> show globalprotect-gateway current-user user jsmith
# Shows: HIP-compliant: yes/no, and which HIP profile matched

## Check what HIP data was received from the client
admin@FW> show globalprotect-gateway hip-report user jsmith
# Full HIP report as received from this specific client

## Windows: Force HIP re-check without reconnecting
# GP agent > Settings > ... > Resubmit Host Profile
# Or: disconnect and reconnect — HIP is checked at tunnel establishment

## macOS: Force GP restart (clears cached HIP state)
$ sudo launchctl stop com.paloaltonetworks.gp.pangps
$ sudo launchctl start com.paloaltonetworks.gp.pangps

Client Issue: Certificate Errors

## Error: "SSL certificate verification failed" or "Certificate error"

## Cause A: Portal/gateway cert signed by internal CA not trusted by client
# Fix: deploy internal CA root cert via GPO (Windows) or MDM (macOS/mobile)
# The root CA that signed the portal/gateway cert must be in the client's trusted store

## Cause B: Certificate CN/SAN mismatch
# The cert must have a SAN matching exactly what the agent connects to
# Example: agent configured with "vpn.corp.com" but cert only has CN=portal.corp.com
# Fix: reissue cert with correct SAN entry

## Cause C: Expired certificate
# Check cert expiry on Windows:
C:\> certutil -verify -urlfetch portal.corp.com
# Or: open browser to portal URL, click padlock → Certificate → Expiry date
# Check cert expiry on macOS:
$ echo | openssl s_client -connect portal.corp.com:443 2>/dev/null | openssl x509 -noout -dates

## Cause D: Machine certificate for pre-logon not found
# Pre-logon uses a machine certificate — if cert is missing or expired, pre-logon fails
# Windows: check cert store
C:\> certutil -store LocalMachine My | findstr "corp.com"
# Must show a valid machine certificate issued by your internal CA
# If missing: run GPO to re-enroll, or manually re-enroll via certmgr.msc

Client Issue: GP Agent Reinstall / Reset Procedure

When all else fails, a clean reinstall often resolves persistent client-side issues caused by corrupted config, stale certificates, or broken driver state.

## Windows — clean reinstall procedure
# 1. Disconnect GP and close the agent
# 2. Uninstall GlobalProtect from Add/Remove Programs
# 3. Delete residual files and registry:
C:\> rmdir /s /q "C:\Program Files\Palo Alto Networks\GlobalProtect"
C:\> rmdir /s /q "C:\ProgramData\Palo Alto Networks"
C:\> rmdir /s /q "%APPDATA%\Palo Alto Networks"
# 4. Delete PANGP virtual adapter if still present:
C:\> devmgmt.msc → Network adapters → PANGP Virtual Ethernet → Uninstall
# 5. Reboot, then reinstall GP agent MSI

## macOS — clean reinstall procedure
$ sudo /Applications/GlobalProtect.app/Contents/Resources/uninstall_gp.sh
$ sudo rm -rf /Library/Application\ Support/PaloAlto
$ sudo rm -rf /Library/Logs/PaloAltoNetworks
$ sudo rm -rf /var/log/PanGP*
# Reboot, then reinstall from portal download page:
# https://portal.corp.com/global-protect/getmsi.esp (Windows MSI)
# https://portal.corp.com/global-protect/getpkg.esp (macOS PKG)

## Reset GP config only (without reinstall) — Windows
# Clears saved credentials and config cache
C:\> del /f /q "%APPDATA%\Palo Alto Networks\GlobalProtect\*"
# Then relaunch GP agent — it will re-download config from portal

Client-Side Quick Reference