Palo Alto Networks NetSec-Pro: GlobalProtect Architecture Choices
GlobalProtect architecture is easier to design when the portal, gateways, tunnel interfaces, identity mappings, and policy zones are treated as separate roles instead of one “VPN box.” The portal distributes client configuration and tells the app which gateways are available. Gateways authenticate endpoints, establish tunnels when required, collect host information, create user mappings, and become enforcement points for traffic that crosses them. The architecture decision is therefore about where those functions should live and how users move between internal and external networks.
For teams working across the current Palo Alto Networks portfolio, GlobalProtect sits inside a larger network security platform. The remote-access design has to line up with routing, zones, User-ID, security policy, endpoint posture, authentication, and availability. A topology that connects successfully but produces ambiguous identity or unpredictable traffic paths is not a finished architecture.
Separate the portal from the enforcement role
The portal is the starting point for the GlobalProtect app. It provides the client configuration, available gateways, authentication settings, and behavior such as internal host detection or connection method. It does not have to be the same firewall or interface that handles every user tunnel. Keeping that distinction clear makes multi-site and hybrid designs easier to reason about.
External gateways are the normal termination points for remote tunnels. Internal gateways can be used on the trusted network for user identification and host-information checks without necessarily creating a tunnel. That distinction is important because an internal gateway can improve identity-aware policy inside the office even when local traffic should continue to use the physical network rather than hairpin through a VPN tunnel.
Use internal host detection to change behavior by location
A mixed internal and external design relies on the app determining whether the endpoint is inside the enterprise network. Internal host detection gives the client a location signal so it can choose the appropriate gateway behavior. On an external network, the app can establish a tunnel to an external gateway. On an internal network, it can authenticate to an internal gateway for User-ID and host posture while local traffic follows the campus or data-center path.
This is more than a convenience feature. It affects which IP address represents the user, where HIP information is evaluated, and which firewall creates the identity mapping used by policy. The companion article on User-ID deployment should be read as part of the same design problem because a remote-access architecture is only as useful as the identity context that reaches the enforcing firewalls.
Give tunnel traffic its own security boundary
An external GlobalProtect gateway needs a tunnel interface, and the tunnel interface belongs to a security zone. Placing remote-access traffic in a dedicated zone such as a corporate VPN zone can make policy and logging easier to understand than blending the tunnel directly into the same zone used by ordinary internal interfaces.
A separate zone makes the trust transition explicit. Rules can describe which remote users may reach internal applications, which services are denied, and which security profiles apply. It also prevents a successful VPN login from becoming an implicit assumption that the endpoint is equivalent to an internal workstation. The broader PAN-OS policy order still applies: the tunnel zone, destination zone, users, applications, services, and rule order determine what actually passes.
Choose the connection method around risk and user experience
GlobalProtect can support different connection models, including always-on approaches and user-initiated access. The architecture should choose that behavior based on the control objective. If the organization expects security policy and endpoint posture to apply whenever a managed device is online, an always-on model provides a stronger default than relying on a user to remember to connect. If the use case is limited access to a small set of internal resources, an on-demand model may be appropriate.
Pre-logon designs add another decision point because they can establish connectivity before the user signs in, which is useful for device management and domain-related workflows but requires careful certificate, machine identity, and access-policy design. The important principle is to decide what must work before user authentication, what requires the user identity, and how the session transitions between those states.
Treat split tunneling as a policy decision
Split tunneling changes which traffic crosses the GlobalProtect tunnel and which traffic leaves through the endpoint’s local network. It can reduce backhaul and improve performance for approved traffic, but it also changes where inspection, logging, DNS resolution, and access controls occur. The design should therefore start with traffic classes and security outcomes rather than with a blanket goal to “save bandwidth.”
When traffic is excluded from the tunnel, document which control replaces the inspection that would otherwise have occurred at the gateway. When traffic is included, verify that routes, DNS, SaaS access, and private application paths behave as intended. In internal-gateway scenarios, split-tunnel settings can also keep internal subnet traffic off an external tunnel so that local resources remain reachable through the physical network.
Use multiple external gateways for resilience and locality
Large deployments often provide more than one external gateway so clients can choose an appropriate location and still connect when one site is unavailable. Gateway priority and response behavior influence which location the app selects. The network architecture behind those gateways must also be redundant; publishing two gateway names does not help if both terminate on the same failed upstream path.
Availability should be tested from the endpoint perspective. Confirm what happens when a gateway is unreachable, when DNS returns a site that has lost internal routing, when authentication is unavailable in one region, and when a tunnel is established but application routes fail. These tests connect GlobalProtect design with the broader firewall HA and disaster-recovery strategy.
Keep authentication, identity, and HIP aligned
The portal and gateways can use authentication profiles, certificates, and other controls in different combinations. The architecture should make those choices deliberate. A user identity that authenticates successfully but is mapped inconsistently across enforcement points can create policy surprises, especially when internal and external gateways are both present.
Host Information Profile data adds another layer. HIP can support policy based on endpoint posture, such as patch status or security controls, but only where the relevant gateway receives and evaluates the report. A mixed design should define which gateway is authoritative for tunneled traffic and which internal gateways need the same posture context for local traffic. The objective is consistent policy evidence, not simply collecting more endpoint attributes.
Decide whether the external gateway belongs on-prem or in Prisma Access
An external GlobalProtect architecture can terminate on organization-managed firewalls or use Prisma Access mobile-user infrastructure. Prisma Access changes the placement of the enforcement point, but it does not remove the need to design private-resource connectivity, routing, identity, and policy. Service connections may be needed when mobile users must reach headquarters or data-center resources, and they are also used for certain mobile-user-to-remote-network communication patterns.
The separate comparison of Prisma Access choices goes deeper into that tradeoff. For GlobalProtect, the key question is where users should enter the security architecture. Distributed users may benefit from cloud-delivered access close to them, while applications and trust boundaries that remain concentrated in a data center may still require strong on-premises enforcement.
Validate the design with packet paths and user mappings
Before rollout, trace representative sessions from the endpoint through portal discovery, gateway authentication, tunnel establishment, route selection, security policy, NAT where relevant, and the return path. Verify the user mapping on the actual firewall that enforces the session. A “connected” status in the client is not evidence that the intended application path or identity-aware policy is working.
Gateway placement should also be tested against route ownership and return-path behavior. A portal may successfully direct a user to a gateway while the protected application still returns through a different edge, producing asymmetric paths or unexpected policy enforcement. In multi-region designs, engineers should document which gateways advertise or own which routes, how internal DNS directs users and applications, and what happens when a preferred region is unavailable. The access design is complete only when the tunnel and the application path agree about where the session enters and exits.
This is where the existing traffic troubleshooting discipline becomes useful. GlobalProtect problems frequently sit at boundaries: DNS works but the wrong gateway is chosen, authentication works but the tunnel route is missing, the tunnel is established but the source zone is wrong, or the user is mapped on one firewall while another firewall makes the policy decision.
A strong GlobalProtect architecture makes those boundaries visible. The portal distributes intent, gateways establish trust and enforce access, zones define packet transitions, and User-ID and HIP provide context. Once those roles are explicit, decisions about internal gateways, external gateways, split tunneling, multiple regions, and Prisma Access become engineering choices instead of configuration folklore.
The design should ultimately be judged by what happens when users change locations and when components fail. If identity remains accurate, traffic follows the expected path, policy remains understandable, and failover behavior is tested, GlobalProtect becomes a dependable access layer rather than another isolated VPN service.