GlobalProtect turns remote access into a policy and identity problem rather than only a VPN tunnel problem. A deployment normally combines a portal that distributes client configuration with one or more gateways that authenticate endpoints, establish tunnels, assign network settings, and enforce access. The design maps naturally to the current Palo Alto Networks Certified Network Security Professional because it spans authentication, network security, remote connectivity, and operational troubleshooting.
Good remote-access architecture begins with user populations and application paths. Employees, contractors, administrators, and unmanaged devices may need different authentication methods, routes, endpoint checks, and security policy. Treating every remote user as one trusted subnet makes the tunnel easy to build but weakens the security model after the user connects.
GlobalProtect also depends on services outside the tunnel itself: DNS, certificates, identity providers, directory groups, MFA, routing, address pools, and firewall capacity. Many failures blamed on “the VPN” are actually authentication, name resolution, route selection, or certificate problems. Designing those dependencies explicitly makes both availability and troubleshooting better.
Before selecting portal and gateway settings, write down the remote-user experience from power-on to application access. Include DNS resolution, portal discovery, authentication, configuration retrieval, gateway selection, tunnel establishment, address assignment, internal DNS, application policy, and logout or timeout. This sequence becomes both an architecture checklist and a troubleshooting map. It also exposes circular dependencies, such as requiring internal DNS to reach the identity provider that must authenticate the user before the tunnel exists.
Remote access should be tested from networks the organization does not control. Home routers, hotel Wi-Fi, carrier networks, captive portals, and restrictive guest networks can all affect DNS, UDP, MTU, and tunnel establishment. A lab test from the corporate LAN misses these conditions. Maintain a small test matrix of common endpoint operating systems and external network types so changes to authentication, client software, or gateway settings are validated in realistic conditions.
Separate portal and gateway responsibilities
The portal is the configuration and discovery point for the GlobalProtect app. After the user authenticates, the portal can provide agent settings and the list of gateways the client may use. Gateways handle the protected connection itself and can apply authentication, address assignment, client settings, and access policy. Keeping those roles clear helps engineers locate failures quickly.
Use multiple gateways when geography, capacity, resilience, or distinct user populations justify them. Gateway selection should consider latency and service availability, but the security policy behind each gateway should remain consistent enough that a user does not receive materially different protection simply because a different gateway was selected.
A gateway is effectively a specialized VPN headend. It terminates remote sessions, but the surrounding firewall still needs routes, zones, policies, inspection, logging, and high availability. Capacity planning should account for concurrent users, authentication load, decryption, and the applications those users will reach.
Document the client bootstrap path for new devices. A user who has never connected may need public DNS to resolve the portal, network access to the portal certificate chain, a working authentication path, and permission to download the agent configuration before any corporate tunnel exists. If any dependency is reachable only through the VPN, onboarding becomes circular. Test from a clean device on an external network so administrators do not overlook trust or software that was preinstalled by corporate management.
Design authentication as a chain, not a checkbox
GlobalProtect can use external authentication such as SAML, LDAP, RADIUS, Kerberos, or TACACS+, as well as certificates and local authentication in smaller or special deployments. The strongest design identifies which system is authoritative for the user and how the portal and gateways will react when that system is unavailable.
Use multi-factor authentication for remote access where risk warrants it, especially for privileged users and access to sensitive applications. MFA should be tested for enrollment, expired tokens, recovery workflows, and failure scenarios. A policy that is secure only while the identity provider is healthy is not an operationally complete design.
Single sign-on can reduce repeated prompts and improve usability, but SSO also concentrates trust in the endpoint and identity session. Confirm how device login state, browser sessions, and authentication cookies interact with GlobalProtect, particularly when a user changes roles or a session must be revoked quickly.
Authentication cookies and reauthentication intervals should be chosen from risk, user experience, and incident-response requirements. Very long-lived authentication can reduce prompts but also prolong access after a credential or device is compromised. Very short intervals can create support load and MFA fatigue. Define how sessions are revoked when an account is disabled and test whether that revocation reaches both the identity provider and active GlobalProtect sessions within the expected time.
Use certificates to authenticate components and devices
Portals and gateways rely on TLS, and certificate errors are among the most common causes of deployment friction. The principles in an SSL certificate lifecycle apply directly: names must match, chains must be trusted, private keys must be protected, and renewal must happen before expiration.
Client certificates can provide a device or user authentication factor and can be combined with an authentication profile. If certificates are issued automatically, document enrollment, renewal, revocation, and replacement after device rebuilds. A certificate that cannot be revoked promptly can outlive the device it was meant to identify.
Test certificate trust from off-network endpoints, not only from corporate devices that may already have internal CA roots. If a portal certificate depends on an internal CA, remote devices must receive that trust before they can establish the first connection. Avoid designs that require the VPN to be up before the client can trust the VPN.
Certificate monitoring should include the portal, every gateway, client-certificate issuers, and any intermediate CA chains. Alert before expiration with enough lead time for change approval and deployment. During renewal, verify that endpoint trust stores contain the complete chain and that the configured certificate matches every hostname users may connect to. A certificate update that succeeds for managed corporate laptops can still fail for contractors or mobile devices with a different trust store.
Plan address pools, routes, and DNS together
Remote users need an address pool that does not overlap networks they commonly use at home, in hotels, or at partner sites. Overlap can create ambiguous routing and make local resources unreachable. Choose pools with future scale in mind and reserve enough addresses for concurrent sessions, reconnect behavior, and multiple gateways.
Access routes determine which corporate destinations are sent through the tunnel. DNS must align with those routes. If internal names resolve to private addresses, clients need a DNS path that can reach the correct resolvers. Split-horizon DNS and internal search domains should be tested under both full-tunnel and split-tunnel designs.
Routing on the firewall and upstream network must include return paths to the GlobalProtect client pools. Asymmetric return traffic can create failures that appear intermittent because some applications tolerate it better than others. Trace both directions and validate the source address seen by internal servers.
Routing tests should include overlapping home networks because they are a frequent source of remote-user problems. If an internal application uses a common private subnet such as 192.168.1.0/24, users at home may have an identical local network. Decide whether more-specific routes, application changes, translated addresses, or another access model is needed. Support documentation should teach engineers how to distinguish route overlap from DNS and policy failures because the symptoms can look similar.
Choose split tunneling from risk and performance needs
Split tunneling can reduce bandwidth and latency by sending selected traffic directly to the internet while corporate traffic traverses the gateway. The tradeoff is visibility and enforcement: traffic outside the tunnel may not receive the same firewall inspection, logging, or egress controls.
Decide whether split tunneling will be based on routes, domains, applications, or other supported criteria, and document exceptions. Collaboration and software-update services may be good candidates for direct access, but identity providers or sensitive SaaS applications may still need centralized policy depending on risk requirements.
Test local-network access explicitly. Users may need printers or home-network devices, but broad local access can also expose endpoints to untrusted networks. The client configuration should reflect organizational policy rather than inheriting accidental behavior from the operating system.
Split-tunnel decisions should be revisited when SaaS providers change endpoints or applications shift from browser traffic to local clients. A domain-based exclusion that once represented one collaboration service can start sending additional content outside the tunnel after a vendor architecture change. Monitor the actual destinations and applications using each exclusion. Treat the split-tunnel list as security policy with ownership and review dates rather than a performance tweak that is set once.
Apply identity-aware security after the tunnel is established
The tunnel should place users into a defined zone and address space so normal Security policy can govern access. Use User-ID and directory groups to restrict applications by role instead of allowing the entire client pool to reach every internal service. Remote access should preserve segmentation, not flatten it.
Administrators and high-risk roles often deserve separate rules, stronger authentication, and tighter application scope. Contractors may require access to only one application or subnet. These differences are easier to audit when they are expressed in separate role-based rules rather than in one broad VPN rule with many exceptions.
The current Palo Alto Networks Certified Next-Generation Firewall Engineer is a useful companion context because GlobalProtect ultimately relies on PAN-OS zones, routing, App-ID, User-ID, security profiles, and logging. Remote-access design is secure only when those controls continue after authentication.
Apply Security Profiles to remote-user traffic according to the same risk model used on campus. Remote users often connect from less trustworthy networks and may be more exposed to phishing or malware, so reducing inspection simply because traffic arrived through a VPN can be backwards. At the same time, avoid double inspection or routing that creates excessive latency. Test representative applications and measure user experience after enabling decryption or stronger threat prevention.
Engineer availability for remote users
Remote access often becomes most important during office closures, outages, travel events, or security incidents. Size gateways and internet links for surge usage rather than normal averages. Capacity should include encrypted throughput, concurrent tunnels, authentication requests, logging, and any decryption or threat inspection applied to tunneled traffic.
Use redundant gateways, resilient DNS, and highly available firewalls where the business impact justifies them. Test failover with established sessions and new connections because the user experience may differ. Document expected reconnect behavior so support teams know whether a brief interruption is normal or a sign of a wider failure.
Identity services are part of availability too. If SAML, RADIUS, or certificate-validation services are unreachable, users may be unable to connect even though the gateway is healthy. Monitor these dependencies from the same perspective as the remote client.
Capacity planning should consider software upgrades and maintenance when one gateway or firewall may temporarily carry the entire load. A pair sized so both members must be active at normal traffic levels has little maintenance margin. Review peak concurrent-user counts, encrypted throughput, authentication latency, and internet bandwidth. Run controlled load tests before seasonal peaks or large remote-work events instead of discovering a capacity limit during an emergency.
Troubleshoot by following the connection sequence
Start with reachability to the portal, then authentication, portal configuration download, gateway selection, gateway authentication, tunnel establishment, address assignment, routes, DNS, and finally application policy. This sequence prevents teams from changing firewall rules before proving the tunnel itself is correctly established.
Collect evidence from both client and gateway logs. Authentication failures, certificate errors, route problems, and application denials leave different traces. Record timestamps and test with a known user so events can be correlated across the identity provider, firewall, DNS, and application logs.
Compare a failing user with a working user from the same location and operating system. Differences in group membership, certificate state, agent version, local network overlap, or endpoint configuration often explain why one session fails while the service appears healthy overall.
Client logs are especially useful because they show what the endpoint believed happened: which portal was contacted, which gateway was selected, which authentication method failed, which routes were installed, and whether the tunnel changed state. Collect them before reinstalling the client or clearing settings. Destructive troubleshooting can remove the evidence needed to distinguish a software problem from an identity or network problem.
Review remote access as the workforce changes
Remote-access policy ages quickly because users move roles, contractors leave, SaaS applications replace internal systems, and office traffic patterns change. Review group membership, application usage, split-tunnel exclusions, stale gateways, certificate expirations, and unused access routes on a regular schedule.
Temporary emergency access should carry an expiration date and named owner. When a user needs one-time administrative access, do not solve the ticket by permanently broadening a general remote-user rule. Remove or narrow the exception after the event.
The wider Palo Alto Networks certification portfolio covers adjacent firewall, architecture, and operations roles, but the design standard is platform-independent: remote users should receive strong identity assurance, predictable connectivity, least-privilege application access, and consistent inspection wherever they work.
Include GlobalProtect in joiner, mover, and leaver processes. New users should receive the correct groups and device trust; role changes should remove obsolete application access; departing users should lose authentication and any client certificates or tokens. Remote access is often reachable from the public internet, so stale access has a different risk profile from an internal-only application account. Periodic entitlement reviews should compare active users with current employment and contract status.