Planning Checklist for GlobalProtect on Prisma Access

• Pre-Installation checklist:
  • IP address pool—To configure Prisma Access for users, you need to provide an IP address pool that does not overlap with other IP addresses you use internally or with the IP address pool you designated for the Infrastructure Subnet.
    We recommend using an RFC 1918-compliant IP address pool. While the use of non-RFC 1918-compliant (public) IP addresses is supported, we do not recommend it because of possible conflicts with internet public IP address space.
    Do not specify any subnets that overlap with the following IP addresses and subnets, because Prisma Access reserves those IP addresses and subnets for its internal use:
    169.254.0.0/16 and 100.64.0.0/10
    Prisma Access uses this IP address pool to assign IP addresses to the virtual network adapters of endpoints when they connect to Prisma Access using the GlobalProtect app. Each device that connects to a Prisma Access mobile user gateway requires its own IP address. You specify these pools during the mobile user onboarding process.
    Palo Alto Networks recommends that the number of IP addresses in the pool is 2 times the number of mobile user devices that will connect to Prisma Access. If your organization has a bring your own device (BYOD) policy, or if a single user has multiple user accounts, make sure that you take those extra devices and accounts into consideration when you allocate your IP pools. If the IP address pool reaches its limit, additional mobile user devices will not be able to connect.
    When mobile user devices connect to a gateway, Prisma Access takes IP addresses from the pools you specified and allocates them to the gateway in /24 blocks. When a /24 block reaches its limit as more user devices log in, Prisma Access allocates more /24 blocks from the pool to the gateway. Prisma Access advertises these /24 subnets into its backbone as they are allocated based on their gateway assignments.
  • Template—The Prisma Access GlobalProtect deployment automatically creates a template stack and a top-level template. If you are already running GlobalProtect on premise and you want to leverage your existing configuration, you can add additional templates to the stack to push existing GlobalProtect portal, GlobalProtect gateway, User-ID, server profile (for example, for connecting to your authentication service), certificate, and SSL/TLS service profile configurations to Prisma Access for users. If you do not have templates with existing configuration settings, you can manually enter the required configuration settings when you set up GlobalProtect on . Additionally, any template(s) you add to the stack must contain the zone configuration for the zones you use to enforce Security policy for your mobile users.
  • Parent Device Group—When you configure Prisma Access for users, you must specify a parent device group to use when you push your address groups and Security policy, Security profiles, other policy objects (such as application groups and objects), HIP objects and profiles, and authentication policy that the service requires to enforce consistent policy for your remote users.
  • Locations to Onboard—Prisma Access provides you with worldwide locations where you can set up GlobalProtect on . Before you onboard your locations, view this list to determine which locations you should onboard for your mobile users deployment.
    Choose locations that are closest to your users or in the same country as your users. If a location is not available in the country where your mobile users reside, you can pick a location that uses the same language as your mobile users.
    You can also divide the locations by geographical region. Keeping all locations in a single region allows you to specify and IP address pool for that region only, which can be useful if you have a limited number of IP addresses that you can allocate to the pool. A single regional IP address pool also provides more granular control over deployed regions and allows you to exclude regions as required by your policy or industry regulations.
    If you have a Local license for Prisma Access for Users and you have a GlobalProtect deployment as well as an Explicit Proxy deployment, you can deploy a maximum of five locations for both deployments combined. You need to allocate the five locations between both deployments (for example, two locations for Mobile Users—GlobalProtect and three locations for Mobile Users—Explicit Proxy). If you have a Worldwide license, there are no restrictions for the maximum number of locations.
  • Portal Hostname—Prisma Access for users enables you to quickly and easily set up the portal hostname using a default domain name (.gpcloudservice.com). In this case, the cloud service automatically publishes the hostname to public DNS servers and handles all certificate generation. However, you can opt to use your own company domain name in the portal hostname. If you plan to use your company domain name, you must obtain your own certificates for the portal and configure an SSL/TLS service profile to point to the certificate before you configure the service. Additionally, if you use your own domain name in the portal hostname, you also need to configure your DNS servers to point to the portal DNS CNAME, which is provided during the configuration process.
  • Service Connection—You must create and configure a service connection if you want to enable your mobile users to access resources, such as authentication servers, on your internal network (for example, an authentication server in your data center or HQ location) or enable your mobile users to access your remote network locations.
    Even if you don’t plan to use the connection to provide access to your internal resources, you must configure at least one service connection with placeholder values if you want your mobile users to be able to connect to your remote network locations or if you have mobile users in different geographical areas who need direct access to each other’s endpoints.
  • IPv6 Usage in Your Network—Determine whether you want to perform any mitigation for IPv6 traffic in your network to reduce the attack surface. In a dual stack endpoint that can process both IPv4 and IPv6 traffic, mobile user IPv6 traffic is not sent to Prisma Access by default and is sent to the local network adapter on the endpoint instead. For this reason, Palo Alto Networks recommends that you configure Prisma Access to sinkhole IPv6 traffic.
  • Logging for GlobalProtect Endpoints—You have two options to collect logs from mobile users who use the GlobalProtect app:
    • Manual Log Collection from GlobalProtect Endpoints—Have the mobile users collect the logs from the GlobalProtect app for Windows, macOS, and Linux devices. This option requires no additional configuration.
    • GlobalProtect App Log Collection for Troubleshooting—Allow the GlobalProtect app to perform end-to-end diagnostic tests to resolve connection, performance, and access issues, and generate troubleshooting and diagnostic logs to be sent to Strata Logging Service for further analysis. You need to generate a certificate so that the GlobalProtect app can authenticate with Strata Logging Service to collect the troubleshooting logs. With Prisma Access (Managed by Strata Cloud Manager), you can enable the GlobalProtect app to collect logs from . For Prisma Access (Managed by Panorama), this functionality is under PanoramaCloud ServicesConfigurationService SetupGenerate Certificate for GlobalProtect App Log Collection and Autonomous DEM. See GlobalProtect App Log Collection for Troubleshooting for configuration details.
• Post-Installation checklist:
  • Add the Public IP Addresses to an allow list in Your Network—After you onboard your locations, you need to the public and IP addresses used by each location and add these locations’ IP addresses to an allow list in your network to allow mobile users access to SaaS or public applications. If you add more locations, you will also need to retrieve the new IP addresses that Prisma Access allocates for the newly-added location or locations.
  • Gateway Naming Consistency—If you have an existing Mobile Users—GlobalProtect deployment and your organization has a merger and acquisition (M&A) activity, you might have a need for existing gateways to either not reference an earlier brand name or reference a new brand name. In this case, reach out to your Palo Alto Networks account team, who will open an SRE case to accommodate the request. Palo Alto Networks recommends that you schedule this change during a maintenance window or during off-peak hours. Palo Alto Networks upgrades all gateways in your deployment that require the name change during the maintenance window.