About the GlobalProtect Components

GlobalProtect provides a complete infrastructure for managing your mobile workforce to enable secure access for all your users, regardless of what endpoints they are using or where they are located. This infrastructure includes the following components:

GlobalProtect Portal

The GlobalProtect portal provides the management functions for your GlobalProtect infrastructure. Every endpoint that participates in the GlobalProtect network receives configuration information from the portal, including information about available gateways as well as any client certificates that may be required to connect to the GlobalProtect gateway. In addition, the portal controls the behavior and distribution of the GlobalProtect app software to both macOS and Windows endpoints. On mobile endpoints, the GlobalProtect app is distributed through the Apple App Store for iOS endpoints, Google Play for Android endpoints and Chromebooks, and the Microsoft Store for Windows 10 UWP endpoints. If you're using the Host Information Profile (HIP) feature, the portal also defines what information to collect from the host, including any custom information you require. You can Set Up Access to the GlobalProtect Portal on an interface on any Palo Alto Networks Next-Generation Firewall.

GlobalProtect Gateways

GlobalProtect gateways provide security enforcement for traffic from GlobalProtect apps. Additionally, if the HIP feature is enabled, the gateway generates a HIP report from the raw host data the apps submit and can use this information in policy enforcement. You can configure different Types of Gateways to provide security enforcement and virtual private network (VPN) access for your remote users, or to apply security policy for access to internal resources.

You can Configure a GlobalProtect Gateway on an interface on any Palo Alto Networks Next-Generation Firewall. You can run both a gateway and a portal on the same firewall, or you can have multiple distributed gateways throughout your enterprise.

GlobalProtect App

The GlobalProtect app software runs on endpoints and enables access to your network resources through the GlobalProtect portals and gateways that you have deployed.

The GlobalProtect app for Windows and macOS endpoints is deployed from the GlobalProtect portal. You can configure the behavior of the app—for example, which tabs the users can see—in the client configurations that you define on the portal. See Define the GlobalProtect Agent Configurations, Customize the GlobalProtect App, and Deploy the GlobalProtect App Software for details.

The GlobalProtect app for mobile endpoints (iOS, Android, and Windows UWP) is available through the official store for the endpoint—the Apple App Store for iOS, Google Play for Android, and the Microsoft Store for Windows UWP. You can alternatively deploy the GlobalProtect Mobile App Using Workspace ONE or other supported third-party mobile endpoint management systems.

See What OS Versions are Supported with GlobalProtect? for more details.

The following diagram illustrates how the GlobalProtect portals, gateways, and apps work together to enable secure access for all your users, regardless of what endpoints they are using or where they are located.

Diagram illustrating the interaction between GlobalProtect Portal, Gateways, and App on various endpoints.

GlobalProtect app features operate as intended only when the integrity of the endpoints and end users is intact. If malicious end users or malware compromise these elements, they may undermine the proper functioning of these features.

About GlobalProtect Licenses

If you want to use GlobalProtect to provide a secure remote access or VPN solution via single or multiple internal/external gateways, you don't need any GlobalProtect licenses. However, to use some of the more advanced features (such as HIP checks and associated content updates, support for the GlobalProtect mobile app , or IPv6 support ) you must purchase an annual GlobalProtect Gateway license . This license must be installed on each firewall running a gateway that:

• Performs HIP checks
• Supports the GlobalProtect app for mobile endpoints
• Supports the GlobalProtect app for Linux endpoints
• Supports the GlobalProtect app for IoT endpoints
• Provides IPv6 connections
• Split tunnels traffic based on the destination domain, application process name, or HTTP/HTTPS video streaming application
• Supports adding a compromised device to the quarantine list.
• Supports identification of managed devices using the endpoint's serial number on gateways
• Enforces GlobalProtect connections with FQDN exclusions

For GlobalProtect Clientless VPN , you must also install a GlobalProtect gateway license on the firewall that hosts the Clientless VPN from the GlobalProtect portal. You also need the GlobalProtect Clientless VPN dynamic updates to use this feature.

Similarly, for any firewall or GlobalProtect gateway which is acting as HIP redistribution agent or client and collector requires a GlobalProtect Gateway license. The only exception is Panorama.

Table summarizing GlobalProtect features and whether a Gateway License is required.

See Activate Licenses for information on installing licenses on the firewall.

In order for GlobalProtect™ to run, you must set up the infrastructure that allows all components to communicate. At a basic level, this means setting up the interfaces and zones to which the GlobalProtect end users connect to access the portal and the gateways to the network. Because the GlobalProtect components communicate over secure channels, you must acquire and deploy the required SSL certificates to the various components. The following sections guide you through the GlobalProtect infrastructure setup:

Create Interfaces and Zones for GlobalProtect

You must configure the following interfaces and zones for your GlobalProtect infrastructure:

• 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 .
• 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 untrust 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.

For tips on how to use a loopback interface to provide access to GlobalProtect on different ports and addresses, refer to Can GlobalProtect Portal Page be Configured to be Accessed on any Port?

For more information about portals and gateways, see About the GlobalProtect Components.

1. Configure a Layer 3 interface for each portal and/or gateway you plan to deploy.

If the gateway and portal are on the same firewall, you can use a single interface for both.

As a best practice, use static IP addresses for the portal and gateway.

Don't attach an interface management profile that allows HTTP, HTTPS, Telnet, or SSH on the interface where you have configured a GlobalProtect portal or gateway because this enables access to your management interface from the internet. Follow the Adminstrative Access Best Practices to ensure that you're securing administrative access to your firewalls in a way that will prevent successful attacks.

1. Select Network > Interfaces > Ethernet or Network > Interfaces > Loopback , and then select the interface you want to configure for GlobalProtect. In this example, we are configuring ethernet1/1 as the portal interface.
2. ( Ethernet only ) Set the Interface Type to Layer3 .
3. On the Config tab, select the Security Zone to which the portal or gateway interface belongs, as follows:
• Place portals and external gateways in an untrust zone for access by hosts outside your network, such as l3-untrust .
• Place internal gateways in an internal zone , such as l3-trust .
• If you have not yet created the zone, add a New Zone . In the Zone dialog, define a Name for the new zone and then click OK .
4. Select the default Virtual Router .
5. Assign an IP address to the interface:
• For an IPv4 address, select IPv4 and Add the IP address and network mask to assign to the interface, for example 203.0.11.100/24 .
• For an IPv6 address, select IPv6 , Enable IPv6 on the interface , and Add the IP address and network mask to assign to the interface, for example 2001:1890:12f2:11::10.1.8.160/80 .
6. Click OK to save the interface configuration.
1. On the firewall(s) hosting GlobalProtect gateway(s), configure the logical tunnel interface that will terminate VPN tunnels established by the GlobalProtect apps.

IP addresses are not required on the tunnel interface unless you require dynamic routing. In addition, assigning an IP address to the tunnel interface can be useful for troubleshooting connectivity issues.

Be sure you enable User-ID in the zone where the VPN tunnels terminate.

1. Select Network > Interfaces > Tunnel , and Add a tunnel interface.
2. In the Interface Name field, enter a numeric suffix, such as .2 .
3. On the Config tab, select the Security Zone for VPN tunnel termination, as follows:
• To use your trust zone as the termination point for the tunnel, select the zone from the drop-down.
• ( Recommended ) To create a separate zone for VPN tunnel termination, add a New Zone . In the Zone dialog, define a Name for new zone (for example, corp-vpn ), Enable User Identification , and then click OK .
4. Set the Virtual Router to None .
5. Assign an IP address to the interface:
• For an IPv4 address, select IPv4 and Add the IP address and network mask to assign to the interface, for example 203.0.11.100/24 .
• For an IPv6 address, select IPv6 , Enable IPv6 on the interface , and Add the IP address and network mask to assign to the interface, for example 2001:1890:12f2:11::10.1.8.160/80 .
6. Click OK to save the interface configuration.
2. If you created a separate zone for tunnel termination of VPN connections, create a security policy to enable traffic flow between the VPN zone and your trust zone.

For example, the following policy rule enables traffic between the corp-vpn zone and the l3-trust zone.

Example Security Policy allowing traffic between the VPN zone (corp-vpn) and the trusted zone (l3-trust).

4. Commit the configuration.

Enable SSL Between GlobalProtect Components: About Deployment

All interaction between the GlobalProtect components occurs over an SSL/TLS connection. Therefore, you must generate and install the required certificates before configuring each component so that you can reference the appropriate certificate in the configurations. The following sections describe the supported methods of certificate deployment, descriptions and best practice guidelines for the various GlobalProtect certificates, and provide instructions for generating and deploying the required certificates:

There are three basic approaches to Deploy Server Certificates to the GlobalProtect Components:

• ( Recommended ) Combination of third-party certificates and self-signed certificates —Because the GlobalProtect app will be accessing the portal prior to GlobalProtect configuration, the app must trust the certificate to establish an HTTPS connection.
• Enterprise CA —If you already have your own enterprise CA, you can use this internal CA to issue certificates for each of the GlobalProtect components and then import them onto the firewalls hosting your portal and gateway. In this case, you must also ensure that the endpoints trust the root CA certificate used to issue the certificates for the GlobalProtect services to which they must connect.
• Self-Signed Certificates —You can generate a self-signed CA certificate on the portal and use it to issue certificates for all the GlobalProtect components. However, this solution is not recommended since it's less secure than the other options. If you do choose this option, end users will see a certificate error the first time they connect to the portal. To prevent this, you can deploy the self-signed root CA certificate to all endpoints manually or using some sort of centralized deployment, such as an Active Directory Group Policy Object (GPO).

Certificate Deployment Options Flow

graph LR
    A[Certificate Deployment Options] --> B(Recommended: Third-Party + Self-Signed);
    A --> C(Enterprise CA);
    A --> D(Self-Signed);
    B --> B1(Third-Party Cert for Portal);
    B --> B2(Self-Signed Certs for Gateways);
    C --> C1(Internal CA issues Certs);
    C1 --> C2(Deploy CA Root to Endpoints);
    D --> D1(Generate CA Root on Firewall/Portal);
    D1 --> D2(Issue Certs for Portal/Gateways);
    D2 --> D3(Manually Deploy CA Root to Endpoints);
             

Flowchart illustrating the three main approaches for deploying GlobalProtect certificates.

Enable SSL Between GlobalProtect Components: Best Practices

The GlobalProtect components must have valid certificates to establish connection using SSL/TLS. The connection fails if you have invalid or expired certificates.

The following table summarizes the SSL/TLS certificates you will need, depending on which features you plan to use:

Table outlining various GlobalProtect certificates, their usage, and best practices.

For details about the types of keys for secure communication between the GlobalProtect endpoint and the portals and gateways, see Reference: GlobalProtect App Cryptographic Functions.

Enable SSL Between GlobalProtect Components: Deploy Server Certificates

The GlobalProtect components must have valid certificates to establish connection using SSL/TLS. The connection fails if you have invalid or expired certificates.

The following are the best practice steps for deploying SSL/TLS certificates to the GlobalProtect components:

Import a Server Certificate from a Well-known, Third-party CA

Use a server certificate from a well-known, third-party CA for the GlobalProtect portal. This practice ensures that the end users are able to establish an HTTPS connection without seeing warnings about untrusted certificates.

The CN and, if applicable, the SAN fields of the certificate must match the FQDN or IP address of the interface where you plan to configure the portal or the device check-in interface on a third-party mobile endpoint management system. Wildcard matches are supported.

Before you import a certificate, make sure the certificate and key files are accessible from your management system and that you have the passphrase to decrypt the private key.

1. Select Device > Certificate Management > Certificates > Device Certificates and Import a new certificate.
2. Use the Local certificate type (default).
3. Enter a Certificate Name .
4. Enter the path and name to the Certificate File received from the CA, or Browse to find the file.
5. Set the File Format to Encrypted Private Key and Certificate (PKCS12) .
6. Enter the path and name to the PKCS#12 file in the Key File field or Browse to find it.
7. Enter and reenter the Passphrase that was used to encrypt the private key.
8. Click OK to import the certificate and key.

Create Root CA Certificate for Issuing Self-signed Certificates for GlobalProtect Components

Create the root CA certificate on the portal and use it to issue server certificates for the gateways and, optionally, for clients.

Before deploying self-signed certificates, you must create the root CA certificate that signs the certificates for the GlobalProtect components:

1. Select Device > Certificate Management > Certificates > Device Certificates and Generate a new certificate.
2. Use the Local certificate type (default).
3. Enter a Certificate Name , such as GlobalProtect_CA . The certificate name can't contain spaces.
4. Don't select a value in the Signed By field. Without a selection for Signed By , the certificate is self-signed.
5. Enable the Certificate Authority option.
6. Click OK to generate the certificate.

Use Root CA on the Portal to Generate a Self-signed Server Certificate

Generate server certificates for each gateway you plan to deploy and optionally for the management interface of the third-party mobile endpoint management system (if this interface is where the gateways retrieve HIP reports).

In the gateway server certificates, the values in the CN and SAN fields must be identical. If the values differ, the GlobalProtect agent detects the mismatch and does not trust the certificate. Self-signed certificates contain a SAN field only if you add a Host Name attribute.

Alternatively, you can use the Simple Certificate Enrollment Protocol (SCEP) to request a server certificate from your enterprise CA.

1. Select Device > Certificate Management > Certificates > Device Certificates and Generate a new certificate.
2. Use the Local certificate type (default).
3. Enter a Certificate Name . This name can't contain spaces.
4. In the Common Name field, enter the FQDN ( recommended ) or IP address of the interface where you plan to configure the gateway.
5. In the Signed By field, select the GlobalProtect_CA you created.
6. In the Certificate Attributes area, Add and define the attributes that uniquely identify the gateway. Keep in mind that if you add a Host Name attribute (which populates the SAN field of the certificate), it must be the same as the value you defined for the Common Name .
7. Configure cryptographic settings for the server certificate, including the encryption Algorithm , key length ( Number of Bits ), Digest algorithm, and Expiration (days).
8. Click OK to generate the certificate.

Use Simple Certificate Enrollment Protocol (SCEP) to Request a Server Certificate from Your Enterprise CA

Configure separate SCEP profiles for each portal and gateway you plan to deploy. Then use the specific SCEP profile to generate the server certificate for each GlobalProtect component.

In portal and gateway server certificates, the value of the CN field must include the FQDN ( recommended ) or IP address of the interface where you plan to configure the portal or gateway and must be identical to the SAN field.

To comply with the U.S. Federal Information Processing Standard (FIPS), you must also enable mutual SSL authentication between the SCEP server and the GlobalProtect portal. (FIPS-CC operation is indicated on the firewall login page and in its status bar.)

After you commit the configuration, the portal attempts to request a CA certificate using the settings in the SCEP profile. If successful, the firewall hosting the portal saves the CA certificate and displays it in the list of Device Certificates .

1. Configure a SCEP Profile for each GlobalProtect portal or gateway:
1. Enter a Name that identifies the SCEP profile and the component to which you deploy the server certificate. If this profile is for a firewall with multiple virtual systems capability, select a virtual system or Shared as the Location where the profile is available.
2. ( Optional ) Configure a SCEP Challenge , which is a response mechanism between the PKI and portal for each certificate request. Use either a Fixed challenge password that you obtain from the SCEP server or a Dynamic password where the portal-client submits a username and OTP of your choice to the SCEP Server. For a Dynamic SCEP challenge, this can be the credentials of the PKI administrator.
3. Configure the Server URL that the portal uses to reach the SCEP server in the PKI (for example, http://10.200.101.1/certsrv/mscep/ ).
4. Enter a string (up to 255 characters in length) in the CA-IDENT Name field to identify the SCEP server.
5. Enter the Subject name to use in the certificates generated by the SCEP server. The subject must include a common name (CN) key in the format CN=<value> where <value> is the FQDN or IP address of the portal or gateway.
6. Select the Subject Alternative Name Type . To enter the email name in a certificate’s subject or Subject Alternative Name extension, select RFC 822 Name . You can also enter the DNS Name to use to evaluate certificates, or the Uniform Resource Identifier to identify the resource from which the client will obtain the certificate.
7. Configure additional cryptographic settings, including the key length ( Number of Bits ), and the Digest algorithm for the certificate signing request.
8. Configure the permitted uses of the certificate, either for signing ( Use as digital signature ) or encryption ( Use for key encipherment ).
9. To ensure that the portal is connecting to the correct SCEP server, enter the CA Certificate Fingerprint . Obtain this fingerprint from the SCEP server interface in the Thumbprint field.
10. Enable mutual SSL authentication between the SCEP server and the GlobalProtect portal.
11. Click OK and then Commit the configuration.
2. Select Device > Certificate Management > Certificates > Device Certificates and then click Generate .
3. Enter a Certificate Name . This name can't contain spaces.
4. Select the SCEP Profile to use to automate the process of issuing a server certificate that is signed by the enterprise CA to a portal or gateway, and then click OK to generate the certificate. The GlobalProtect portal uses the settings in the SCEP profile to submit a CSR to your enterprise PKI.

Assign Server Certificate You Imported or Generated to a SSL/TLS Service Profile

Table summarizing requirements for using TLSv1.3 with GlobalProtect.

GlobalProtect supports SSL/TLS service profiles with a maximum TLS version as TLSv1.3. You can create SSL/TLS service profiles on the firewall that is hosting the portal or gateway by specifying the range of supported SSL/TLS versions (from minimum supported version to maximum supported version) for communication between GlobalProtect components.

Configure SSL/TLS service profiles with TLSv1.3 to provide enhanced security and faster TLS handshake while establishing connection between GlobalProtect components. TLSv1.3 is the maximum version supported and, when used, delivers increased security by removing the weak ciphers supported in the earlier TLS versions and adding more secure cipher suites.

1. To enable SSL connection between GlobalProtect components, you need to generate or import a certificate.
2. On the firewall that is hosting the GlobalProtect portal and gateway, select Device > Certificate Management > SSL/TLS Service Profile and Add a new SSL/TLS service profile.
3. Specify a Name for the new profile.
4. Select the Certificate you imported.
5. In Protocol Settings, define the range of SSL/TLS versions ( Min Version to Max Version ) for communication between GlobalProtect components. The maximum supported TLS version is TLSv1.3.

To provide the strongest security, set both the Min Version and the Max Version as TLSv1.3.

The Encryption Algorithms and Authentication Algorithms are populated automatically from the available ciphers based on your TLS protocol settings.

The TLSv1.3 aes-chacha20-poly1305 cipher isn't enabled by default on devices running Windows 11. You must manually enable the cipher on GlobalProtect endpoints running Windows 11.

6. Optional Modify the ciphers in the Encryption Algorithms and Authentication Algorithms section as needed.

Screenshot showing the configuration options for an SSL/TLS Service Profile.

7. Click OK and Commit your changes.

Deploy the Self-Signed Server Certificates

• Export the self-signed server certificates issued by the root CA on the portal and import them onto the gateways.
• Be sure to issue a unique server certificate for each gateway.
• If specifying self-signed certificates, you must distribute the root CA certificate to the end clients in the portal client configurations.

1. Export the certificate from the portal:
1. Select Device > Certificate Management > Certificates > Device Certificates .
2. Select the gateway certificate you want to deploy, and then click Export Certificate .
3. Set the File Format to Encrypted Private Key and Certificate (PKCS12) .
4. Enter and confirm a Passphrase to encrypt the private key.
5. Click OK to download the PKCS12 file to a location of your choice.
2. Import the certificate on the gateway:
1. Select Device > Certificate Management > Certificates > Device Certificates and Import the certificate.
2. Enter a Certificate Name .
3. Browse to find and select the Certificate File you downloaded in the previous step.
4. Set the File Format to Encrypted Private Key and Certificate (PKCS12) .
5. Enter and confirm the Passphrase you used to encrypt the private key when you exported it from the portal.
6. Click OK to import the certificate and key.
7. Commit the changes for the gateway.

Enable SSL Between GlobalProtect Components: Replace Expired Certificates

If your GlobalProtect portal or gateway certificate has expired or is about to expire, you have several options to replace it.

For Prisma Access deployments, the portal and gateway certificates and their renewals are managed automatically as part of the infrastructure, so you don't have to do anything to replace an expired certificate.

If you're using third-party certificates for your portal or gateway, you will need to manage and renew your certificates when they expire.

If the firewall is the certificate authority (CA) that issued the certificate for your portal and gateways, the firewall replaces the expired certificate with a new certificate that has the same attributes as the old certificate but with a different serial number. From the web interface that is hosting the portal or gateway, Renew the Certificate, and commit the changes to push the certificate to the portal or the gateway.

For on-premises deployments that use third party CA-issued SSL certificates, you must import the renewed certificate that you downloaded from your CA using the following procedure:

1. Note the name and expiration date of the portal or gateway certificate.
1. From the firewall that is hosting the gateway or portal with the expiring certificate, log on to the web interface.
2. Select Device > Certificate Management > Certificates .
3. Locate the certificate in the Device Certificates tab and note the name of the certificate and expiration date.

Screenshot showing how to locate Device Certificates in the Palo Alto Networks firewall WebUI.

2. Download the renewed certificate from your third-party CA. As an example, the following steps show how to download the renewed certificate from GoDaddy:
1. Log in to the godaddy.com portal.
2. Go to the Certificates tab.
3. Select the certificate and click Download .

Screenshot showing the option to download a certificate from the GoDaddy portal.

4. In the Download Certificate window, for Server type , select Other and download the certificate in .crt format.

The certificate is saved to your downloads folder.

3. Import the downloaded certificate on the firewall that is hosting your portal or gateway.

If you deployed two firewalls in an HA pair in an active/passive deployment, you must import the certificate on each firewall.

1. From the web interface, go to Device > Certificate Management > Certificates > Device Certificates > Import .
2. Enter the exact Certificate Name for the portal or gateway certificate that you're replacing.
3. For the Certificate File , browse to and select the certificate that you downloaded from the CA.
4. For the File Format , select Base64 Encoded Certificate (PEM) .

Screenshot showing the options for importing a Device Certificate into the Palo Alto Networks firewall WebUI.

5. Click OK .

After the certificate has been imported, you will see the new expiration date for the certificate.

6. Commit your changes to push the certificate to the portal or gateway.

Interactive Quiz

Test your knowledge on GlobalProtect components and certificate management.