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
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
To reduce the time it takes for remote user
authentication and tunnel setup, consider replicating the Active
Directory Server and making it available in AWS.
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.