GlobalProtect end-to-end — portal first, then prove the tunnel

1. Why portal ≠ gateway

Mixing the two roles is the first conceptual miss on every PCNSE whiteboard and every Monday outage. One chassis can host both. They still do different jobs.

The portal is the management function: it distributes agent configuration, the list of available gateways, optional client certificates, and (on Windows/macOS) the app software. No user application traffic flows through the portal. The gateway is where security is enforced. If HIP is enabled, the gateway builds a HIP report from the raw host data the app submitted and uses that report in policy.

Hero · who talks to whom

Three gateway types, from the Administrator’s Guide:

• Internal — an interface on the corporate LAN configured as a gateway. Used with User-ID and/or HIP so office traffic is identified and posture-checked. Tunnel mode or non-tunnel mode. The app reaches it after Internal Host Detection succeeds.
• External (auto discovery) — outside the LAN. The app picks Best Available from priority, source region, and response time.
• External (manual) — also outside, but the user must initiate that gateway. You mark it Manual in the portal agent config. Different authentication is allowed.

2. Mental model

Memorize two planes. The portal plane answers “who is this, and what config do they get?” The gateway plane answers “may this session use this app, given user + HIP?”

3. Login + HIP flowchart

From café Wi-Fi to “apps work,” seven stages fire. Each fails in a recognisable log. Flow first, then words.

Decision · inside or outside

4. How to choose connect method and tunnel

Connect Method lives on the portal agent, not the gateway: Network → GlobalProtect → Portals → (portal) → Agent → (config) → App.

Source: Always On VPN Configuration, Remote Access VPN with Pre-Logon, Internal HIP checking.

5. Runbook · Side A Entra, Side B PAN-OS, Side C HIP

Lab story (placeholder only): portal and external gateway share gp.example.com on untrust. Users live in Entra. Corp prefixes are 10.0.0.0/8. You want Always-On, Entra MFA, HIP = disk encryption + anti-malware, and split-tunnel Include for the corp range.

Primary sources: Microsoft Entra — GlobalProtect tutorial and Set Up SAML Authentication.

Side A — Microsoft Entra ID (IdP)

1. Add the gallery app

   Entra admin center → Enterprise applications → New application → search Palo Alto Networks - GlobalProtect → Create. Open Single sign-on → SAML.

2. Basic SAML Configuration — include :443

   Microsoft’s pattern (and the Palo Alto KB) requires the port on Entity ID and ACS:

   Entra Basic SAML (replace the FQDN)

   Identifier (Entity ID):
   https://gp.example.com:443/SAML20/SP
   
   Reply URL (ACS):
   https://gp.example.com:443/SAML20/SP/ACS
   
   Sign-on URL:
   https://gp.example.com

   If portal and gateway use different FQDNs, add both Entity IDs and both ACS URLs. Prisma Access docs say the same: every gateway name in https://<name>:443/SAML20/SP plus the matching /ACS.

3. Assign users and download metadata

   Users and groups → assign the pilot group. Then download the Federation Metadata XML (and note the current signing certificate). You will re-import this XML when Entra rotates the cert — that is the “signature could not be verified” ticket.

Side B — PAN-OS portal and gateway

1. Import the IdP

   Device → Server Profiles → SAML Identity Provider → Import. Profile Name e.g. entra-gp. Browse the metadata XML. Leave Validate Identity Provider Certificate checked. Maximum Clock Skew default is 60 seconds (range 1–900). Fix NTP; do not “solve” drift by opening the replay window to 900.

2. Authentication Profile

   Device → Authentication Profile → Add. Type = SAML. IdP Server Profile = entra-gp. Set Username Attribute (usually username or the claim Entra sends). Advanced → Allow List: add the users/groups, or all. An empty Allow List means nobody can authenticate — that is a documented default, not a UI bug.

3. Portal

   Network → GlobalProtect → Portals → Add. Interface + IPv4 of the untrust address. SSL/TLS Service Profile with a server cert whose CN/SAN is gp.example.com. Authentication → Client Authentication → Add → Authentication Profile = the SAML profile. Then Agent → Add:

   • App tab: Connect Method = User-logon (Always On).
   • Internal tab: enable Internal Host Detection (IPv4 IP + hostname that only internal DNS can reverse-resolve). Add the Internal Gateway if you have one.
   • External tab: add the external gateway FQDN, priority Highest for the local region.
   • HIP Data Collection: Collect HIP Data = enabled.

4. Gateway

   Network → GlobalProtect → Gateways → Add. Same interface/cert is fine on a single box. Authentication Profile = same SAML profile (portal and gateway both need it). Agent → Tunnel Settings: Tunnel Mode on, Tunnel Interface = tunnel.2 in a corp-vpn zone with Enable User Identification. Agent → Client Settings → Add → Config Selection Criteria (user/group any for the lab) → IP Pools → Split Tunnel → Access Route → Include 10.0.0.0/8 (or an address object of type IP Netmask). Commit.

Side C — HIP objects, profile, policy, proof

HIP needs a GlobalProtect subscription on every gateway that will evaluate HIP. Check Device → Licenses before you debug empty HIP Match logs.

1. HIP Objects

   Objects → GlobalProtect → HIP Objects → Add. Keep objects simple. Example: hip-disk-enc on the Disk Encryption tab (encrypted = yes). Example: hip-av-rtp on Anti-Malware (Real Time Protection = yes, virus def age ≤ 5 days). Official guidance: one concern per object so profiles stay composable.

2. HIP Profile

   Objects → GlobalProtect → HIP Profiles → Add. Name hip-corp-compliant. Add Match Criteria: hip-disk-enc AND hip-av-rtp. Parentheses if you mix AND/OR. Max 2048 characters.

3. User-ID on the source zone

   Network → Zones → corp-vpn → Enable User Identification. Palo Alto is explicit: you must enable User-ID on the source zone of HIP-controlled traffic, even if you are not using user-based rules, or the firewall cannot generate HIP Match log entries.

4. Security rule

   Write and test the allow on zones/addresses first (see the Security policy lesson). Then Policies → Security → (rule) → Source → Source Device → Add the HIP profile (up to 63 per rule). Add a lower quarantine allow (remediation VLAN / update sites only) whose HIP profile is NOT hip-corp-compliant, plus a HIP Notification on the gateway: Network → GlobalProtect → Gateways → Agent → HIP Notification.

5. Prove it

   Pilot laptop connects. Monitor → Logs → GlobalProtect shows portal then gateway success. Monitor → Logs → HIP Match lists every object/profile that matched — it does not list misses. If hip-corp-compliant is absent, the endpoint did not match. Monitor → Logs → Traffic Rule Name must be the HIP-tagged allow, not interzone-default.

6. Runtime path after commit

Always-On at user login: IHD first. Miss → portal TLS → Entra challenge (embedded or default browser) → assertion to /SAML20/SP/ACS → portal validates signature and NotBefore / NotOnOrAfter against firewall time ± Maximum Clock Skew → config XML → gateway selection → tunnel + IP pool → HIP report (≈20 s cutoff, partial allowed) → Security policy with user + HIP → Access Routes installed.

Journey · detect, auth, tunnel, posture

Pre-logon changes only the first identity. The machine certificate (Local Computer store on Windows, System Keychain on macOS) brings the tunnel up as user pre-logon. After interactive login, Windows renames the tunnel to the user; macOS tears it down and builds a new one. Your pre-logon Security rules must stay tiny — DHCP, DNS, specific AD, antivirus, OS updates — and a deny must sit under them. Put the pre-logon agent config first in the portal list (User/User Group = pre-logon) if that population should use a different gateway before login.

7. Traps + proof checklist

Ops · prove it in logs

Sources

• GlobalProtect Portals — portal distributes agent config, gateway list, client certs; not the data plane.
• GlobalProtect Gateways — internal / external auto / external manual; HIP report generated on the gateway.
• Portals Agent App tab — Connect Method: On-demand, User-logon (Always On), Pre-logon.
• Always On VPN Configuration — Network → GlobalProtect → Portals → Agent → App → User-logon (Always On).
• Remote Access VPN with Pre-Logon — machine cert, user pre-logon, tight Security rules, Windows rename vs macOS rebuild.
• Internal HIP checking and user-based access — Internal Gateway requires Always On.
• Set Up SAML Authentication — Device → Server Profiles → SAML Identity Provider; Maximum Clock Skew default 60 s (1–900); Authentication Profile Allow List.
• Microsoft Entra — Palo Alto Networks GlobalProtect — Entity ID https://<FQDN>:443/SAML20/SP, ACS …/SAML20/SP/ACS.
• How to setup Azure SAML authentication with GlobalProtect — same URL pattern; include :443.
• Configure HIP-Based Policy Enforcement — HIP Objects / Profiles paths; User-ID required on the zone; Source Device HIP; HIP Notification; HIP Match logs.
• Would GlobalProtect VPN be disconnected if HIP check failed? — HIP never disconnects the VPN.
• How Does the HIP Mechanism Work in GlobalProtect? — ~20 s client cutoff; partial report; HIP Match shows matches only.
• Configure a Split Tunnel Based on the Access Route — Include / Exclude; empty = full tunnel; No direct access to local network.

Related: PAN-OS Security policy · PAN-OS session factory · IPSec site-to-site · Azure ↔ Palo Alto IPsec · Palo Alto interview hub · Palo Alto course