GlobalProtect Deployment
Last updated
Last updated
Portal - Provides management functions to your GP infrastructure. The portal is responsible for giving out configuration information about available gateways as well as client certificates that are required. The portal is also used to control the distribution of the GlobalProtect app to endpoints such as Windows and Mac. Finally, if you are using HIP (Host Information Profile) you can define what information to collect from the host.
Gateway - Provides security enforcement for traffic from GP. If HIP checks are enabled the gateway generates a raw report of the host and submits it for policy enforcement. There are two different types of gateways: External and Internal. We will learn more about this later on.
App - Client software that runs on the endpoint host and controls other features like if the user can turn GP on/off, change gateways, etc.
GP has a free license for use on all NGFW firewalls. However, to use more advanced features (such as HIP checks, support for mobile devices, and IPv6 support) you must purchase a GP Gateway license. For a more detailed explanation of the difference between free and paid versions check out this article to learn more.
GlobalProtect portal—Requires a Layer 3 or loopback interface for the GlobalProtect apps’ connection. If the portal and gateway are on the same firewall, they can use the same interface. The portal must be in a zone that is accessible from outside your network, such as a DMZ. You can only have one Portal and Gateway configured on an interface.
GlobalProtect gateways—The interface and zone requirements for the gateway depend on whether the gateway you're configuring is external or internal, as follows:
External gateways—Requires a Layer 3 or loopback interface and a logical tunnel interface for the app to establish a connection. The Layer 3/loopback interface must be in an external zone, such as a DMZ. A tunnel interface can be in the same zone as the interface connecting to your internal resources (for example, trust). For added security and better visibility, you can create a separate zone, such as corp-vpn. If you create a separate zone for your tunnel interface, you must create security policies that enable traffic to flow between the VPN zone and the trust zone.
Internal gateways—Requires a Layer 3 or loopback interface in your trust zone. You can also create a tunnel interface for access to your internal gateways, but this isn't required. The main use case for internal gateways is either for User-ID collection or adding an extra layer of authentication before users can access an internal resource.
Portal Service Certificate:
This certificate is identified in an SSL/TLS Service Profile. You assign the portal server certificate by selecting its associated service profile in a portal configuration.
If you don't use a well-known, public CA, you should export the root CA certificate used to generate the portal server certificate to all endpoints that run the GlobalProtect app. Exporting this certificate prevents the end users from seeing certificate warnings during the initial portal login.
The Common Name (CN) and Subject Alternative Name (SAN) fields of the certificate must match the IP address or FQDN of the interface that hosts the portal.
In general, a portal must have its own server certificate. However, if you're deploying a single gateway and portal on the same interface, you must use the same certificate for both the gateway and the portal.
If you configure a gateway and portal on the same interface, we recommend that you use the same certificate profile and SSL/TLS Service Profile for both the gateway and portal. If they don't use the same certificate profile and SSL/TLS Service Profile, the gateway configuration takes precedence over the portal configuration during the SSL handshake.
Gateway Server Certificate:
This certificate is identified in an SSL/TLS Service Profile. You assign the gateway server certificate by selecting its associated service profile in a gateway configuration.
The CN and the SAN fields of the certificate must match the FQDN or IP address of the interface where you plan to configure the gateway.
The portal can distribute the gateway root CA certificate to the GlobalProtect app based on the configuration (Trusted Root CA list in the Portal configuration Agent tab). However, it's not mandatory for the gateway root CA certificate to be preinstalled in the user's trusted certificate store or for the gateway certificate to be issued by a public CA.
In general, each gateway must have its own server certificate. However, if you're deploying a single gateway and portal on the same interface for basic VPN access, you must use a single server certificate for both components. As a best practice, use a certificate signed by a public CA.
If you configure a gateway and portal on the same interface, we recommend that you use the same certificate profile and SSL/TLS Service Profile for both the gateway and portal. If they don't use the same certificate profile and SSL/TLS Service Profile, the gateway configuration takes precedence over the portal configuration during the SSL handshake.
(Optional) Client Certificate:
For simplified deployment of client certificates, configure the portal to deploy the client certificate to the apps upon successful login using either of the following methods:
Use a single client certificate across all GlobalProtect apps that receive the same configuration. Assign the Local client certificate by uploading the certificate to the portal, and then selecting it in a portal agent configuration.
Use simple certificate enrollment protocol (SCEP) to enable the GlobalProtect portal to deploy unique client certificates to your GlobalProtect apps. Enable this by configuring a SCEP profile, and then selecting that profile in a portal agent configuration.
Use one of the following digest algorithms when you generate client certificates for GlobalProtect endpoints: sha1, sha256, sha384, or sha512.
Consider testing your configuration without the client certificate first, and then add the client certificate after you're sure that all other configuration.
(Optional) Machine Certificate:
If you plan on using the pre-login feature, use your own PKI infrastructure to deploy machine certificates to each endpoint before enabling GlobalProtect access. This approach is important for ensuring security. For more information, see Remote Access VPN with Pre-Logon.
I am using an enterprise CA which is served by my active directory server. The domain is byos.reversethrottle.com
I created a root cert specifically for all my GP-related certs called GP_Root_Cert. All other certs will be signed by this root cert which is signed by my CA.
In this lab, I've gone ahead and created 3 different certificates. One for the Portal, One for the external gateway, and one for the internal gateway. Ensure the Common Name (CN) and Subject Alternative Name (SAN) fields of the certificate match the IP address or FQDN of the interface that hosts the portal. For example, my certificates are configured as follows:
GP External Portal Certificate
Certificate Name: gpvpn portal (Descriptive name for yourself to remember)
Common Name: gpvpn.reversethrottle.com > This resolves to my external interface IP which is hosting my GP Portal.
IP: 192.168.1.11 > The IP that will be resolved from the hostname.
SAN: gpvpn.reversethrottle.com
GP External Gateway Certificate
Certificate Name: gpgw external gateway
Common Name: gpgw.reversethrottle.com > This resolves to my external interface IP which is hosting my GP Gateway
IP: 192.168.1.10 > The IP that will be resolved from the hostname.
SAN: gpgw.reversethrottle.com
GP Internal Gateway Certificate
Certificate Name: gpgw internal gw
Common Name: internal.byos.reversethrottle.com > This resolves to my internal interface IP which is hosting my GP Gateway
IP: 10.2.0.1 > The IP that will be resolved from the hostname.
SAN: internal.byos.reversethrottle.com
You use an SSL/TLS Service Profile to define which versions of TLS are supported and the different key algorithms.
Below you can see an example of a Service profile I created for this lab:
Make sure that for every certificate you create, you also create an SSL/TLS Service profile. These profiles will be referenced later on when we configure the portal and gateways. For this example, we'll need to configure 3 different SSL/TLS Service Profiles based on the certificates we created above.
By default, the GlobalProtect app attempts to use the same login credentials for the gateway that it used for portal login. In the simplest case, where the gateway and the portal use the same authentication profile or certificate profile, the app connects to the gateway transparently.
On a per-app configuration basis, you can also customize which GlobalProtect portal and gateways—internal, external, or manual only—require different credentials (such as unique OTPs). This enables the GlobalProtect portal or gateway to prompt for the unique OTP without first prompting for the credentials specified in the authentication profile.
Cookie authentication simplifies the authentication process for end users because they will no longer be required to login to both the portal and the gateway in succession or enter multiple OTPs for authenticating to each.
This improves the user experience by minimizing the number of times that users must enter credentials. In addition, cookies enable the use of a temporary password to re-enable VPN access after the user’s password expires. You can configure cookie authentication settings independently for the portal and for individual gateways (for example, you can impose a shorter cookie lifetime on gateways that protect sensitive resources).
After the portal or gateways deploy an authentication cookie to the endpoint, the portal and gateways both rely on the same cookie to authenticate the user. When the app presents the cookie, the portal or gateway evaluates whether the cookie is valid based on the configured cookie lifetime. If the cookie expires, GlobalProtect automatically prompts the user to authenticate with the portal or gateway. When authentication is successful, the portal or gateway issues the replacement authentication cookie to the endpoint, and the validity period starts over.
With two-factor authentication, you can specify the portal and types of gateways (internal or external) that prompt for their own set of credentials. This option speeds up the authentication process when the portal and the gateway require different credentials (either different OTPs or different login credentials entirely). For each portal or gateway that you select, the app does not forward credentials, allowing you to customize the security for different GlobalProtect components. For example, you can have the same security on your portals and internal gateways, while requiring a second factor OTP or a different password for access to those gateways that provide access to your most sensitive resources.
I am not going to go into detail on setting up server profiles for authentication but you can check out the below documents on setting up different Authentication Profiles:
When you configure GlobalProtect to use client certificates for authentication on macOS or Windows endpoints, GlobalProtect must present a valid client certificate to authenticate with the portal and gateways. For a client certificate to be valid, it must meet the following requirements:
The certificate is issued by the certificate authority (CA) you defined in the Certificate Profile of your portal and gateway configurations.
The certificate specifies the client authentication purpose, which the certificate administrator specifies when creating the certificate.
The certificate is located in the certificate store, as configured in the GlobalProtect portal agent configuration. By default, the GlobalProtect app first looks for a valid certificate in the user store. If none exist, the app then looks in the machine store. If the GlobalProtect app locates a certificate in the user store, it won't look in the machine store because the user store takes precedence. To force the GlobalProtect app to look for certificates in only one certificate store, configure the Client Certificate Store Lookup option in the appropriate GlobalProtect portal agent configuration.
When only one client certificate meets the requirements above, the app automatically uses that client certificate for authentication. However, when multiple client certificates meet these requirements, GlobalProtect prompts the user to select the client certificate from a list of valid client certificates on the endpoint. While GlobalProtect requires users to select the client certificate only when they first connect, users might not know which certificate to select. In this case, we recommend you to narrow the list of available client certificates by certificate purpose (as indicated by the OID) and certificate store.
With the optional client certificate authentication, the user presents a client certificate along with a connection request to the GlobalProtect portal or gateway. The portal or gateway can use either a shared or unique client certificate to validate that the user or endpoint belongs to your organization.
To authenticate the user, one of the certificate fields, such as the Subject Name field, must identify the username.
To authenticate the endpoint, the Subject field of the certificate must identify the device type instead of the username. (With the pre-logon connect methods, the portal or gateway authenticates the endpoint before the user logs in.)
For an agent configuration profile that specifies client certificates, each user receives a client certificate. The mechanism for providing the certificates determines whether a certificate is unique to each user or the same for all users under that agent configuration:
To deploy client certificates that are unique to each user and endpoint, use SCEP. When a user first logs in, the portal requests a certificate from the enterprise’s PKI. The portal obtains a unique certificate and deploys it to the endpoint.
To deploy the same client certificate to all users that receive an agent configuration, deploy a certificate that is Local to the firewall.
Use an optional certificate profile to verify the client certificate that the endpoint presents with a connection request. The certificate profile specifies the contents of the username and user domain fields; lists CA certificates; criteria for blocking a session; and offers ways to determine the revocation status of CA certificates. Because the certificate is part of the authentication of the endpoint or user for a new session, you must pre-deploy certificates used in certificate profiles to the endpoints before the users’ initial portal login. The certificate profile specifies which certificate field contains the username. If the certificate profile specifies Subject in the Username Field, the certificate presented by the endpoint must contain a common-name for the endpoint to connect. If the certificate profile specifies a Subject-Alt with an Email or Principal Name as the Username Field, the certificate from the endpoint must contain the corresponding fields, which will be used as the username when the GlobalProtect app authenticates to the portal or gateway.
To configure a Gateway navigate to Network > GlobalProtect > Gateways.
Define the interface you want the gateway to reside on along with the IP address of the interface. (You can also create a loopback address on the firewall if you choose not to use the interface IP address).
Select the Authentication Tab
Define the SSL/TLS Service Profile for your gateway that we defined earlier.
Next, we need to define how the client will authenticate to the gateway. Select Add.
Select an Authentication Profile you created earlier (LDAP, SAML, RADIUS, etc).
At the bottom, is where we can define if the client also needs a certificate to authenticate or just a password.
Click on the Agent tab > Tunnel Settings
Since this is an external gateway we need to enable Tunnel Mode and also select a tunnel. (How to create a tunnel - Link)
Click Client Settings > Add
This is where we can define different criteria that must be met before the client can connect. We can define user information, OS, and IP addresses.
Click the Authentication Override tab
This allows the portal and gateway to generate auth cookies to allow end users a seamless login experience.
Click IP Pools. We can define the IPs that will be assigned to remote VPN users.
We also have Split Tunnel and Network Services, however we will not be configuring those today.
The Internal Gateway configuration is very similar to the External Gateway. On the General tab we define our private/internal interface and IP address.
Under Authentication we define our SSL/TLS Service Profile we created for the internal gateway and add our authentication profile.
Under the Agent tab. We can essentially leave black. We don't want users to establish a tunnel using the internal gateway which means we also don't need to define an IP address pool.
Now that we have our gateways configured. We can configure our Portal and assign our gateways to the Portal.
Navigate to Network > GlobalProtect > Portal
Define the interface and IP address that you want the Portal assigned to, ensuring that the Portal is accessible from outside our network. In the example, I created a Loopback address so I could assign my Portal to a different IP address than is configured on my physical internet-facing interface.
Click on the Authentication tab and define your Authentication Profile and SSL/TLS Service Profile.
Click on the Agent tab > Select Add to define agent configurations.
Authentication:
Define how users authenticate to the Portal and whether or not a session cookie should be generated.
Config Selection Criteria:
We then define which endpoints/users can access the portal based on user information, OS, or HIP profiles. For this example, I left everything as Any.
Internal:
This is where we can enable Internal Host Detection. We need to define an IP address and a hostname that GP will use. When Internal Host Detection is configured the agent will first try to resolve your hostname using the IP address if the IP is resolved GP knows it's on an internal network if the IP doesn't resolve GP thinks it's external and will try and connect to the best available gateway configured.
External:
Finally, we define our external gateway. Select Add and define the IP or FQDN of your gateway.
We can also define our GP app behaviors on endpoints. However, I will not be covering that.
I have a user sitting on my internal zone which has the subnet 10.2.0.0/24 and the default gateway being my firewall with the IP address of 10.2.0.1. If you remember this is the IP address we configured GP to use to determine if the user was on an internal network. After I authenticate to the Portal the GP agent automatically detects I'm on an internal network and connects me to the internal gateway.
If you are having issues with your internal users accessing the external portal check out this article here. In short, we need to make sure traffic is allowed from the internal to the external zone and we also need to create a No-NAT policy to ensure our traffic isn't NAT'ed.
We can validate this by checking the logs. We can see our user is coming from the Users Zone which is expected since no tunnel is being formed. We can also see that we have User-ID information populated because after the user authenticates GP now has a mapping for that IP-to-User
Finally, we have a remote user that is external. After authenticating to the Portal and validating that the end device cannot resolve the hostname it will then present the user with any available external gateways.
We can validate this again by looking at the logs. We can see that our user is coming from the VPN zone which we created. We can also see User-ID information that has been populated by GP.
