GlobalProtect says Connected, but an internal website still times out. Start with one failing application, one endpoint and one timestamp—not a blanket allow rule. The useful question is: where does this application's request stop: name resolution, endpoint steering, firewall policy, return routing or the application itself?
This guide provides a reusable troubleshooting matrix, Windows evidence commands and an acceptance checklist. Scope: an external GlobalProtect gateway on a Palo Alto Networks firewall, with Windows examples. Prisma Access and other endpoint platforms need their own management paths and version-specific checks. All example names and addresses below are synthetic; commands are unexecuted templates, not results from a customer environment.
First separate tunnel status from application access
A GlobalProtect gateway provides VPN connectivity and enforces security policy; establishing the tunnel is not the same task as allowing an application's traffic.[1] Treat the connected icon as a starting point, not an application acceptance test.
Record the GlobalProtect app and PAN-OS versions, endpoint OS, connected gateway, assigned tunnel address, matched client settings, username and the time of the attempt. Choose a single application FQDN and destination port. If possible, compare with a working endpoint using the same gateway and entitlement—not an administrator with broader access.
Safety boundary: use approved test destinations, limit captures to the relevant flow, and handle exported logs as sensitive data. Do not disable endpoint protection, certificate validation, HIP enforcement or security inspection as a first diagnostic step. Do not publish real logs or user identifiers in a support forum.
The two paths you must prove
Split DNS can send selected domains to VPN-assigned resolvers and other domains to local resolvers.[5] That makes two separate questions important: which resolver answered the name, and which path carried traffic to the returned address?
For route-based split tunneling, Palo Alto documents behavior driven by the endpoint routing table; domain-based splitting uses a Windows filter driver or macOS network extensions.[3] Therefore a route-table screenshot alone is not sufficient evidence of the final path for a domain-based policy.
Use the matrix below as an investigation aid, not as proof that any one symptom has only one cause.
GlobalProtect connected but no access: troubleshooting matrix
| Symptom | Evidence to collect first | Next bounded test | Change only after proof |
|---|---|---|---|
| Internal FQDN fails to resolve | A and AAAA answers, selected resolver, DNS error and query time | Compare normal resolution with an explicit query to the approved corporate resolver | Correct resolver assignment, suffix or split-DNS domain scope |
| Corporate resolver answers, normal lookup fails | Resolver list on physical and tunnel interfaces; relevant client logs | Compare effective DNS policy and query path with a working endpoint | Correct mismatched DNS steering; do not replace corporate DNS with a public resolver |
| Name resolves, TCP connection fails | Returned address, selected endpoint route, firewall session/log evidence | Test the same destination and port; determine whether the gateway sees it | Correct the missing route, unintended exclusion or matched security rule |
| Firewall allows traffic, server never sees request | Session egress, next hop, translation and server-side capture | Follow a narrowly filtered flow from tunnel zone toward application | Correct downstream path or translation only where the design requires it |
| Server receives request, client gets no response | Server reply, return route to the actual source address, firewall receive evidence | Trace the return path independently | Restore return routing or repair the documented NAT design |
| TCP succeeds, browser still fails | TLS error, HTTP status, proxy path and application redirect destinations | Make a hostname-preserving HTTPS request | Repair certificate chain, proxy or application dependencies, not an unrelated access route |
| Only some home networks fail | Home prefix, tunnel pool, internal destination prefix and selected route | Compare the same device on another approved connection | Resolve demonstrated address overlap or conflicting steering |
| Only one OS/app release fails | Exact versions, effective configuration and reproducible steps | Compare a supported known-good client in a pilot group | Use release-specific vendor guidance; avoid fleet-wide speculative changes |
For firewall-side policy investigation, pair this process with the existing Palo Alto App-ID migration checklist. For translation questions, use the Palo Alto NAT troubleshooting guide.
Step 1: capture DNS evidence before changing anything
Windows PowerShell templates: replace the documentation-only values with approved values. 192.0.2.53 and 198.51.100.20 are illustrative placeholders, not public test services. Do not run them unchanged expecting a response.
Get-NetIPConfiguration
Get-DnsClientServerAddress
Resolve-DnsName app.example.com -Type A
Resolve-DnsName app.example.com -Type AAAA
Resolve-DnsName app.example.com -Server 192.0.2.53 -Type A
Save the normal lookup result before trying the explicit resolver. Ask whether the returned address is the one the application owner expects, whether the normal query uses the intended resolver and whether an IPv6 answer introduces a second destination path to test.
An explicit-resolver test is a comparison, not a complete simulation of browser behavior. Keep browser proxy and encrypted-DNS configuration in the evidence bundle if the browser behaves differently from the operating-system lookup. Use a fully qualified name initially; test short-name behavior separately rather than mixing suffix-search problems into the first result.
A specific split-DNS failure worth checking
Palo Alto documents a Windows scenario with Both Network Traffic and DNS, configured domain inclusion/exclusion lists, and identical DNS servers on the local and tunnel interfaces, where split DNS does not work correctly.[2] The article also describes a related case in which no gateway DNS servers are configured and the app uses the local interface's servers.[2]
In that documented scenario, a query arriving on an interface inconsistent with the domain rule can receive NXDOMAIN from GlobalProtect; the vendor's resolution is to configure gateway DNS servers different from the local DNS servers.[2] Do not generalize this into “every NXDOMAIN is a VPN bug.” Compare your exact settings and client environment with the article before adopting its remedy.
Split-DNS support has platform and release prerequisites, including separate requirements for Windows/macOS and iOS; check the vendor support table for your deployed combination rather than copying a setting from another endpoint platform.[5]
Step 2: prove endpoint steering, not just the presence of a route
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6
Find-NetRoute -RemoteIPAddress 198.51.100.20
Test-NetConnection -ComputerName 198.51.100.20 -Port 443 -InformationLevel Detailed
Record the selected source address, interface and next hop. Compare the destination with the gateway's effective split-tunnel settings, including domain/application entries where used. Confirm the endpoint actually received the intended client configuration; a correct-looking setting in a different client profile is not evidence for this user.
Palo Alto's documented route-based examples distinguish these cases: with include access routes only, included destinations use the tunnel and the remaining traffic uses the external path; with exclude routes only, excluded destinations use the external path while a tunnel default handles the remainder.[3] Treat those as documented examples with stated assumptions, not a substitute for inspecting your effective configuration.
A particularly useful trap: configuring only include domains or applications does not necessarily mean that everything else goes directly to the internet—the vendor's example still has an implicit tunnel default route.[3] Avoid adding a broad default-route exclusion as a reflex; first write down the intended full-tunnel or split-tunnel security policy and verify how the installed client implements it.
Evidence rule: if application/domain steering is configured, corroborate route output with a controlled connection and endpoint/gateway observations. If the gateway sees nothing, absence of a traffic log alone is inconclusive: check capture scope, log settings and whether the request actually left the endpoint before blaming routing.
Step 3: follow the firewall session and its reply
For the same timestamp and application flow, investigate these checkpoints in order:
- Ingress: does the request arrive from the expected tunnel source and zone?
- Policy: which rule matches the actual user, destination, application and service? Check identity and HIP-related conditions where configured.
- Forwarding: which route, egress interface and next hop carry the request toward the server?
- Translation: what source and destination addresses exist on each side? Record the actual transformation instead of assuming NAT is present or absent.
- Return: does the server or its gateway know how to return traffic to the source address it sees?
- Completion: does the client receive a response, and does the application transaction finish?
Keep separate columns for observations and hypotheses in the incident record. “Allow rule matched” is an observation. “The server must be dropping it” is still a hypothesis until the server-side path is checked.
If the session shows an unexpected rule or application, use a controlled pilot correction rather than an any/any rule. If there is an unexpected translation, consult the existing NAT design before introducing another rule to conceal the routing problem. Preserve the original failure evidence before reconnecting, flushing caches or clearing sessions.
Step 4: preserve the hostname when testing HTTPS
A raw TCP test isolates port reachability; it does not exercise the entire HTTPS transaction. The following unexecuted Windows template pins one destination while keeping the URL hostname for the request:
curl.exe --verbose --connect-timeout 10 --max-time 20 --resolve app.example.com:443:198.51.100.20 https://app.example.com/
Use this only for an approved target and confirm proxy settings before interpreting it as a direct-path test. Keep normal certificate verification enabled: a trust failure is useful evidence, not something to hide with --insecure. Redact verbose output before sharing because headers and connection details can be sensitive.
Interpret the result narrowly. A successful request with this override, combined with failed ordinary name resolution, directs attention toward DNS. A TLS alert or HTTP error means the investigation has reached a different layer; it is not proof that all redirects, authentication endpoints or application APIs work. Retest the normal browser workflow after the underlying change.
Reusable acceptance and rollback checklist
Copy this into the change record. These are proposed acceptance tests, not claimed lab results.
| Test | Record as evidence | Pass criterion |
|---|---|---|
| Internal DNS | Normal lookup, approved resolver and expected answer | Name resolves through the intended DNS path |
| Internal HTTPS | User-visible transaction plus correlated flow | Approved user completes the target application task |
| Unauthorized access | Approved negative test account/destination | Access remains denied by the intended control |
| Internet/SaaS | Actual egress and DNS path | Matches the approved full/split-tunnel policy |
| IPv4 and IPv6 | Results for each enabled address family | No unexplained alternate-path failure or policy bypass |
| Alternate home connection | Same device and app on an approved alternative link | No unexplained home-network-specific regression |
| Reconnect and restart | Fresh connection after configuration delivery | Intended settings survive a fresh connection |
| Rollback | Saved configuration, owner and trigger | Previous approved policy can be restored within the change window |
Define rollback triggers before the change: loss of corporate DNS, failure of a critical application, unintended direct internet egress, or an unauthorized destination becoming reachable. Pilot the smallest relevant user group. Revert the changed configuration through the normal control process if those triggers occur, then collect fresh evidence rather than stacking speculative fixes.
Practical takeaways
Diagnose one transaction end to end. Separate name resolution from application steering, and separate forward delivery from the return path. Use the matrix to choose the next test, not to guess the fix. Preserve hostname and certificate checks for HTTPS, verify a negative access case, and close the incident only after the user's real workflow works under the intended security policy.
For related runbooks, browse Start Here and the networking resources hub.
Sources
- [1] https://docs.paloaltonetworks.com/globalprotect/administration/globalprotect-gateways/configure-a-globalprotect-gateway
- [2] https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000Cq90CAC&lang=en_US
- [3] https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000oM3WCAU
- [5] https://docs.paloaltonetworks.com/globalprotect/administration/globalprotect-gateways/split-tunnel-traffic-on-globalprotect-gateways/split-dns
Post a Comment