End users who are remote (outside the corporate network) connect to one of the gateways in AWS or Azure. When you configure the GlobalProtect portal client configuration, assign equal priority to the gateways. With this configuration, the gateway to which users connect depends on the SSL response time of each gateway measured on the endpoint during tunnel setup.

For example, a user in Australia would typically connect to the AWS-Sydney gateway. After the user is connected to AWS-Sydney, the GlobalProtect app tunnels all traffic from the endpoint to the AWS-Sydney firewall for inspection. GlobalProtect sends traffic to public internet sites directly via the AWS-Sydney gateway and tunnels traffic to corporate resources through a site-to-site tunnel between the AWS-Sydney gateway and the Santa Clara gateway, and then through an IPsec site-to-site tunnel to the corporate headquarters. This architecture is designed to reduce any latency the user may experience when accessing the internet. If the AWS-Sydney gateway (or any gateway closer to Sydney) was unreachable, the GlobalProtect app would back-haul the internet traffic to the firewall in the corporate headquarters and cause latency issues.

Active Directory servers reside inside the corporate network. When remote users authenticate, the GlobalProtect app sends authentication requests through the site-to-site tunnel in AWS/Azure to the Santa Clara gateway. The gateway then forwards the request through an IPsec site-to-site tunnel to the Active Directory Server in corporate headquarters.

End users inside the corporate network authenticate to the three internal gateways immediately after they log in. The GlobalProtect app sends the HIP report to these internal gateways. Users that are inside the office on the corporate network must meet the User-ID and HIP requirements to access any resource at work.