TTechclick All lessons
Palo Alto · NGFW VPN · GlobalProtectInteractive · L2 / L3

GlobalProtect — Watch a Client Log In, From Portal to Tunnel-Up

Portal versus Gateway. Internal versus external. HIP profile + HIP match. SAML SSO with Entra ID. Split-tunnel access routes. Pick a path, press Play on the GP login animator, and learn exactly why your laptop "connects then disconnects in 30 seconds" — and how to fix it in under a minute.

📅 2026-05-25 · ⏱ 12 min · 2 live demos · 🏷 10-Q assessment + AI Tutor inline

Pick your path — jump straight in

1

Portal vs Gateway

Two distinct roles. Mix them up and nothing works.

 2

Login State Machine

Watch a GP client go from open-app to tunnel-up, stage by stage.

 3

HIP + SAML SSO

Endpoint posture check + Entra ID single sign-on.

 4

Split-Tunnel & Trouble

Access routes, internal-host-detection, and the "drops in 30 sec" fix.

① Portal vs Gateway — two distinct roles, one chassis

GlobalProtect has two server-side components and they do completely different things. Confusing them is the single most common conceptual error of a new GP admin.

🏛
Portal
tap to flip

The "registration desk". Authenticates the user (PSK / cert / SAML), hands the GP client a config: which Gateway(s) to use, agent settings, HIP collection rules. No data flows through the portal. Typically just one portal per enterprise.

🚪
External Gateway
tap to flip

The actual VPN endpoint. Builds the IPSec/SSL tunnel, assigns the client a virtual IP, enforces security policy. Can be one or many (geographically distributed). Client picks one based on lowest-latency / priority.

🏢
Internal Gateway
tap to flip

For users already inside the corp network. No tunnel built — just a HIP check + User-ID mapping. Lets Security Policy enforce posture even on internal traffic. Requires Always-On connect method.

🔍
Internal Host Detection
tap to flip

Client checks DNS resolution / reverse-PTR of a configured internal hostname. If it resolves to a known internal IP → "I'm inside" → talk to internal gateway. If not → external. The decision happens on the client, not the server.

Portal cert ≠ Gateway cert (or, the day your laptops can't connect)

The Portal certificate is what users' GP clients trust the first time they connect — typically a public CA cert tied to your gp.company.in hostname. The Gateway certificate authenticates the IPSec/SSL tunnel — different file, different lifetime, but equally important. If either expires, GP breaks. Set calendar reminders for both, 30 days before expiry. Many "GP suddenly stopped working everywhere" Monday-morning incidents trace to a weekend cert expiry no one set a reminder for.

Quick check · Q1 of 10

Sneha at Infosys is setting up her first GP deployment. A new laptop opens the GP app for the first time, types her email and password. Which component does the GP app talk to FIRST?

Correct: d. Portal first. The Portal is the registration step — auth user, hand back gateway list + agent config + HIP rules. Only after that does the GP app pick an external (or internal) gateway from the returned list and build the actual data tunnel.

② The full GP login state machine — Play to watch

From the moment a remote employee opens the GP icon to the moment data starts flowing through the tunnel, 7 distinct things happen. Each can fail, each fails in a recognisable way.

▶ GP login state machine — corporate laptop scenario

Rahul at TCS opens the GP app on a corp laptop from a Bengaluru café. Watch the 7-stage login.

① INTERNAL HOST CHECK Client resolves internal.corp.local via local DNS · returns 192.168.X.X (private) NO → not on corp LAN
Decision logic happens on the CLIENT, not the gateway. Resolves with public DNS → "I'm outside" → use external gateway flow.
▼
② PORTAL CONNECT Client connects to https://gp.company.in · TLS handshake using Portal cert · prompts SAML login
Browser pop-up opens to Entra ID (or Okta / Ping). User authenticates with corp creds + MFA.
▼
③ SAML ASSERTION IdP returns SAML assertion signed by IdP cert · Portal validates signature + NotBefore / NotOnOrAfter timestamps
Maximum Clock Skew default = 60 sec. NTP-mismatched firewall = SAML "auth failed" with no obvious clue. Sync your NTP.
▼
④ CONFIG PUSH Portal returns client config: gateway list (priority-ranked by region), HIP-check policy, agent settings, certs to install
▼
⑤ GATEWAY SELECT Client pings each gateway in the returned list · picks lowest-latency one (Mumbai-GW)
If "Manual gateway selection" is enabled, user picks. Otherwise auto-fastest.
▼
⑥ TUNNEL UP + HIP Client builds IPSec/SSL tunnel to Mumbai-GW · receives virtual IP from address-pool · uploads HIP report (OS version, AV, patch level, disk encryption)
HIP collection happens AFTER tunnel-up — that's why a HIP mismatch shows as "connects then disconnects in 30 sec".
▼
⑦ SECURITY POLICY Gateway evaluates Security Policy with HIP match · "is laptop encrypted AND has AV?" → ALLOW · access routes pushed · traffic flows
HIP mismatch here = the tunnel stays up but security rule denies all traffic — looks like "tunnel up but nothing works".
Press Play to watch the entire GP login sequence — from app-open to traffic-flowing.
Quick check · Q2 of 10

Priya at HCL configures GP with SAML auth against Entra ID. Users get "authentication failed" intermittently. The firewall's NTP server is in a different region with ~120 sec drift. What's the cause?

Correct: b. SAML assertions carry NotBefore and NotOnOrAfter timestamps. PAN-OS validates them against its own clock, with a configurable Maximum Clock Skew tolerance (default 60 sec). 120-sec drift → some assertions land outside the tolerance → intermittent failures. The proper fix is NTP, not raising the skew. Raising the skew masks the symptom but increases replay-attack window. PCNSE tests this — it's a classic.

③ HIP — making the firewall care if the endpoint is healthy

HIP (Host Information Profile) is GlobalProtect's posture-check feature. The GP app on the endpoint collects facts about the device: OS version, patch level, disk encryption status, installed AV, firewall enabled, custom registry checks. The gateway evaluates those facts against HIP Objects (single criteria like "Windows 11" or "BitLocker enabled") and HIP Profiles (combinations like "Windows 11 AND BitLocker AND CrowdStrike running"). Security Policy can then match on HIP profile.

Result: the firewall can enforce "only encrypted laptops with current patches access the financial-app zone" — a control level identity-and-network rules alone can't reach. HIP is what bridges endpoint posture and network access in the PAN-OS world.

▶ HIP enforcement — Karthik's BYOD laptop hits a HIP-locked app

Karthik at Flipkart connects from his BYOD laptop. GP tunnel up. He tries to reach finance-app. HIP says no.

① TUNNEL UP GP tunnel established · Karthik gets virtual IP 10.99.5.42 from the GP IP pool
▼
② HIP COLLECT GP app on laptop scans local device · uploads HIP report
Report says: Windows 11, no disk encryption, Defender outdated definitions, no MDM enrollment.
▼
③ POSTURE CHECK Gateway evaluates report against HIP Profile "Corp-Compliant"
Profile requires: encryption=true, AV=current, MDM=enrolled. Karthik's laptop fails all three.
▼
④ HIP MATCH Karthik's session → HIP Profile = "Non-Compliant" (the catch-all match below Corp-Compliant)
HIP profiles are referenced in Security Policy just like User-ID groups — first-match wins, top-down.
▼
⑤ POLICY EVAL Rule "Allow-Finance-Compliant" requires HIP = Corp-Compliant → doesn't match for Karthik
Falls through to rule "BYOD-Web-Only" which only permits HTTPS to general web. Finance app denied.
▼
⑥ USER NOTIFY Karthik sees the "Notification page" from the firewall: "Your device doesn't meet corporate compliance"
Configurable via Response Page on Captive Portal. Better UX than silent block.
Press Play to see how HIP enforces compliance even after a successful tunnel-up.
"Connects then disconnects in 30 seconds" — almost always HIP

The most-Googled GP failure mode. Sequence: tunnel comes up cleanly → GP app starts collecting HIP → uploads report to gateway → gateway evaluates → if HIP doesn't match any required profile AND the gateway is configured with "HIP report required" enforcement, the gateway tears down the session ~30 seconds in. The user blames the network; the firewall is just refusing a non-compliant device. Fix: check show user ip-user-mapping all | match <user> + look at System log for HIP-related entries. Configure a fallback HIP profile (e.g. "Non-Compliant") that doesn't block — instead it routes the user to a remediation captive portal.

Quick check · Q3 of 10

Aditya at Wipro deploys HIP for the first time. Some users connect and immediately disconnect after ~30 sec. System logs mention HIP. What is the diagnostic next step?

Correct: a. HIP failures look like "connects then disconnects in 30 sec" because HIP is collected AFTER tunnel-up. The Monitor → HIP Match log shows the actual report the gateway received and which checks failed. From there, you decide: relax the profile (rare, security risk), fix the endpoint (correct but slow), or add a fallback HIP profile that lets non-compliant devices into a quarantine zone with remediation guidance.

④ Split-tunnel + Always-On + Pre-Logon

🛣
Split-Tunnel Routes
tap

Define Access Routes on the gateway. Only matching destinations go through the tunnel; everything else (Netflix, Zoom direct media) exits the laptop's local interface. Saves bandwidth, improves UX. Default behaviour for SaaS-heavy deployments.

🔒
Always-On
tap

Connect Method = User-logon (Always On). The GP tunnel auto-establishes the moment the user logs into Windows / macOS. Required for Internal Gateway use. Users can't easily disconnect — enforces consistent posture.

👤
Pre-Logon
tap

Tunnel comes up before the user logs into Windows — using a device-cert. Lets group policy / scripts / domain auth flow from day one. Essential for fully remote AD-joined laptops that never see a corporate LAN.

🌐
Internal Host Det.
tap

Configurable in agent settings. Client resolves a hostname; if the result matches the expected internal IP, switches to internal-gateway mode (no tunnel, just HIP). Mis-config → users get tunnel-mode on the corp LAN, duplicate IPs, performance pain.

Split-tunnel evaluation order — Application Exclude wins

When mixing access routes + domain include/exclude + application include/exclude (newer feature), the precedence is: Application Exclude beats Application Include beats Domain Exclude beats Domain Include beats Network Access Route. Memorise the ladder — when split-tunnel "isn't working", it's almost always because a broader exclude (further down the precedence chain) is winning. Verify the effective decision per destination with the GP app's "Traffic" tab or show global-protect-gateway current-user on the gateway.

Quick check · Q4 of 10

A team needs Internal Gateway to enforce HIP on users who walk into the office with their laptops. Connect Method is currently "On-Demand". What MUST change?

Correct: c. Internal Gateway depends on the GP app starting automatically at user-logon (Always-On). On-Demand means the GP app only activates if the user clicks Connect — which won't happen reliably on internal LAN where users assume they don't need a VPN. PAN-OS documentation makes this requirement explicit.

⑤ The 3 commands you'll actually run when GP breaks

① Who's connected, on which gateway? 
show global-protect-gateway current-user
show global-protect-gateway statistics
② What HIP did this specific user report? 
debug user-id dump hip-report user <username>
show user ip-user-mapping all | match <ip-or-user>
③ Why is SAML auth failing? 
less mp-log authd.log | match SAML
less mp-log saml.log
show clock
Watch for in saml.log 
NotBefore  : 2026-05-25T08:14:00Z
NotOnOrAfter: 2026-05-25T08:16:00Z
Local clock : 2026-05-25T08:11:32Z   ← 148 sec behind = SAML rejected
Quarterly drill: smoke-test every connect method

Every quarter, test (a) external on-demand from a coffee shop, (b) external always-on after Windows lockscreen unlock, (c) pre-logon from a freshly imaged laptop, (d) internal-gateway from a corp desk, (e) HIP-noncompliant laptop falls into the remediation portal. Five test cases. 30 minutes. Catches half the breakages before users do.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer.

Pre-curated from PAN-OS docs + LIVECommunity + Entra ID interop guides.

📝 Wrap-up — six more

You've already answered 4 inline. Six left. 70% (7 of 10) total marks the lesson complete.

Q5 · Apply

A new GP rollout uses Entra ID SAML. Users complete the IdP login but the GP client immediately says "authentication failed". On the firewall, saml.log shows the SAML response signature could not be verified. What is the most likely cause and the fix?

Correct: b. "Signature could not be verified" specifically means the cert the firewall has on file doesn't match the cert that signed the SAML response. Most common cause: Entra ID rotated its signing cert and the firewall is still using the old one. The Federation Metadata XML download contains the current cert — re-importing it refreshes the trust. Clock skew shows differently in logs ("NotBefore violated"), wrong password shows as "authentication failed" at the IdP not the firewall.
Q6 · Analyze

A user reports: "GP shows me connected to the corp network, but I can't reach internal apps. Pings to internal IPs fail. External browsing works." Tunnel is up. What is the most likely cause?

Correct: a. "Tunnel up but internal apps unreachable" = client doesn't know to route internal-destination traffic via the tunnel. Split-tunnel Access Routes define which destinations go through the tunnel; missing routes = traffic exits locally and never reaches the gateway. Either add the internal subnets to Access Routes or change the gateway to "Send everything through tunnel" (full-tunnel).
Q7 · Analyze

A laptop visits the corporate office. Internal Host Detection is misconfigured. The client tries to build an EXTERNAL tunnel from the corp LAN. What goes wrong?

Correct: d. Internal Host Detection IS the on-vs-off-corp-LAN decision. Mis-config = client thinks it's outside, builds an unnecessary external tunnel from inside the office. Tunnel works but causes IP overlap, double-routing, and bandwidth waste. The fix is to use a stable internal-only hostname (e.g. internal-detect.corp.local) that resolves correctly via internal DNS but fails to resolve externally — that gives the client a reliable "am I inside?" signal.
Q8 · Analyze

A Security Policy rule references HIP Profile "Corp-Compliant" in the source-user / HIP column. A user's GP session reports HIP that DOES match the profile, but the security rule still doesn't match. What is missing?

Correct: c. HIP matching in Security Policy requires User-ID enabled on the zone — the firewall needs the per-user context to apply the per-user HIP report. Without User-ID, HIP data exists but isn't bound to the session for policy evaluation. Tick "Enable User-ID" on the Zone (Network → Zones → <zone>) and commit.
Q9 · Evaluate

A team needs fully remote AD-joined laptops to receive Group Policy on day one (the laptop has never been on the corporate LAN). Which GP feature enables this?

Correct: b. Pre-Logon is the exact feature for this. The tunnel uses a machine certificate (typically deployed via MDM/Intune/SCCM during initial imaging) to come up before any user has logged in. That lets Windows reach Domain Controllers, pull Group Policy, and complete user logon. Internal Gateway only works after the user is logged in and on the corp LAN. On-Demand requires user interaction — defeats the purpose for first-boot.
Q10 · Evaluate

A site wants tighter HIP enforcement but is afraid of mass disconnects on rollout. A team proposes: "Add the new strict HIP profile to the security policy, set the default action when HIP doesn't match to permit but log instead of block for 30 days, then switch to block after observing logs." Is this a sound rollout plan?

Correct: a. Monitor-then-enforce is the standard safe rollout for any posture-based control (HIP, ZTNA, conditional access). Configure security rules so non-matching HIP devices are permitted but logged, collect 30 days of data, identify the non-compliant population, run a remediation campaign, then flip to enforce. Communicating clearly with users avoids the "GP just stopped working" Slack storm on enforcement day.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the section that tripped you up and tap "Try again".

📚 Sources

  1. Palo Alto Docs — Set Up SAML Authentication (GlobalProtect). docs.paloaltonetworks.com
  2. Palo Alto Docs — GlobalProtect for Internal HIP Checking and User-Based Access. docs.paloaltonetworks.com
  3. Palo Alto Docs — Mixed Internal and External Gateway Configuration. docs.paloaltonetworks.com
  4. Palo Alto Docs — Troubleshoot HIP Issues. docs.paloaltonetworks.com
  5. Microsoft Learn — Configure Palo Alto Networks GlobalProtect for Single Sign-On with Microsoft Entra ID. learn.microsoft.com/entra/identity/saas-apps/palo-alto-networks-globalprotect-tutorial
  6. LIVECommunity — GlobalProtect Troubleshooting / Split-Tunnel / Agent Options. live.paloaltonetworks.com/td-p/415420
  7. LIVECommunity — Global Protect Internal Host Detection & Internal Gateways — Lessons Learnt. packetswitch.co.uk
  8. LIVECommunity — Block access on HIP check failure — how? td-p/1231467

What's next?

You've finished the HA + Routing + VPN block (Blogs 11–14) of the Palo Alto NGFW Mastery series. Coming up: Troubleshooting Trio (15–17) — the 7-step diagnosis ladder, session-table mastery, and packet diagnostics. That's where this series turns into actual production muscle memory.

Blog 15 · Traffic Not Passing → ← Recap IPSec S2S