GlobalProtect for Mixed Employees and Contractors
A retail group has 4,200 corporate laptops and 900 contractor laptops, plus 1,200 users at HQ behind a PA-3220 pair. It is replacing a legacy VPN concentrator with GlobalProtect. Requirements: contractors must never reach HR systems on 10.20.0.0/16; corporate laptops must send internet traffic through HQ so URL filtering and threat inspection apply; Teams and Zoom must go direct to protect the 500 Mbps HQ internet link; internal applications live in 10.0.0.0/8 and 172.16.0.0/12 across HQ and two regional offices; internal DNS (10.10.5.5, 10.10.5.6) must resolve only over the tunnel. Certificates come from a public CA for servers and from an internal AD CS for user and machine certificates. Travellers report that IPsec is blocked in some countries, so SSL on 443 must work.
1. Where do the portal and gateways go, and what does each firewall need licensed and configured so users can reach resources at HQ and both regional offices?
Read the worked answer
- Portal: on the HQ pair's untrust interface behind a public FQDN, with a public-CA certificate whose SANs cover both the portal and gateway names (or issue one certificate per name). Portal config requires a server certificate; do not use the internal AD CS here or off-network clients will fail.
- Licensing: GlobalProtect portal subscription on the HQ pair, GlobalProtect gateway subscription on every firewall that terminates tunnels (HQ external gateway, and each regional office if users are to terminate locally).
- Gateways: an external gateway at HQ for internet-bound and HQ-bound traffic, plus internal gateways at each regional office so local users land locally rather than tromboning. Use access routes so a client connected to one gateway can reach 10.0.0.0/8 and 172.16.0.0/12 prefixes that sit behind the other gateways, or ensure HQ routes those prefixes toward the regionals.
- Delivery: portal and gateway settings in Panorama templates per region; client configs (split tunnel, DNS, access routes) pushed from the portal so 5,100 clients pick them up without a reinstall.
- Connectivity: allow SSL on 443 as well as IPsec/UDP 4501 so travellers on networks that block ESP or UDP still connect.
2. Design split tunnelling so Teams and Zoom go direct while everything else is inspected. What breaks, and how do you keep internal DNS working?
Read the worked answer
- Split tunnel is one list, include or exclude, not both. Because the majority of traffic must be inspected, use exclude mode containing the collaboration vendors' published address ranges/domains. 10.0.0.0/8 and 172.16.0.0/12 stay in the tunnel implicitly.
- What breaks: excluded traffic is not inspected by the firewall at all. URL filtering, threat and WildFire profiles no longer see it, so the compensating control has to be the endpoint (agent-based protection, application control on the endpoint) or a narrower exclusion (media ports to specific ranges rather than whole CIDRs).
- Domain vs IP excludes: domain-based entries depend on client-side resolution and refresh; IP ranges are more reliable but drift as vendors add ranges. Prefer ranges plus a documented refresh owner.
- DNS: configure split DNS with the corporate domains pointed at 10.10.5.5/10.10.5.6 so those lookups travel the tunnel, and let everything else use the local resolver. Without it you get hairpinned or public-resolved internal names and half-broken sessions.
- Note: "no direct access to local network" is a different control (it blocks the client's own LAN) and should not be confused with split tunnelling when scoping contractor laptops.
3. How do you enforce "contractors never reach HR" and add a HIP gate without derailing a 5,100-laptop rollout?
Read the worked answer
- Identity is the control point, not the tunnel. Authenticate users through SAML/IdP (or LDAP) so User-ID carries group membership, then place a deny rule for the contractor group to 10.20.0.0/16 above the general internal allow. Verify group mapping refresh and test with the User-ID lookup tool before rollout. A separate contractor gateway does not, by itself, enforce anything.
- HIP in stages: publish the HIP profile at the portal so clients can self-remediate, enable the agent via MDM, run in monitor mode (log-only HIP match) for two to four weeks, then flip to enforcement for patches/AV/disk encryption. Keep a break-glass group exempt so an executive laptop bricking is not a rollback.
- Certificates: do not require machine certificates for authentication on day one unless the AD CS enrolment path is already proven at scale; SAML plus MFA delivers the requirement, and machine certs can be added later as an additional factor.
- Watch the bottleneck: 900 contractors enrolling in the same week will show up as portal load and support tickets, so stagger by department and pre-stage the client.