Prisma Access Administrator’s Guide

(Panorama Managed)
Version 3.2 Preferred and Innovation

docs.paloaltonetworks.com
Contact Information
Corporate Headquarters:
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
www.paloaltonetworks.com/company/contact-support

About the Documentation

• For the most recent version of this guide or for access to related documentation, visit the Technical
Documentation portal docs.paloaltonetworks.com.
• To search for a specific topic, go to our search page docs.paloaltonetworks.com/search.html.
• Have feedback or questions for us? Leave a comment on any page in the portal, or write to us at
[email protected].

Copyright
Palo Alto Networks, Inc.
www.paloaltonetworks.com

© 2021-2023 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo
Alto Networks. A list of our trademarks can be found at www.paloaltonetworks.com/company/
trademarks.html. All other marks mentioned herein may be trademarks of their respective companies.

Last Revised
February 21, 2023

Prisma Access Administrator’s Guide (Panorama Managed) 2 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Table of Contents
Prisma Access Overview.................................................................................. 9
Prisma Access.............................................................................................................................10
Prisma Access Infrastructure Management........................................................................ 14
Releases and Upgrades............................................................................................................ 16
Prisma Access Release Types..................................................................................... 16
Prisma Access Upgrade Types................................................................................... 17
Cadence for Software and Content Updates for Prisma Access................................... 20
Prisma Access Dataplane Upgrades..................................................................................... 25
Dataplane Upgrade Overview.................................................................................... 25
Dataplane Upgrade Example.......................................................................................28
Use the Prisma Access App to Get Upgrade Alerts and Updates................................. 32
View Prisma Access Software Versions.............................................................................. 37
Prisma Access Licensing.......................................................................................................... 42
License Enforcement for Prisma Access Mobile User Deployments.................42
Other Required Prisma Access Licenses..................................................................43
Prisma Access Add-On Licenses................................................................................43
Determine Your Prisma Access License Type from Panorama........................... 43
Cheat Sheet: Integrate ADEM with Panorama Managed Prisma Access..........44
Cheat Sheet: Integrate IoT Security with Panorama Managed Prisma
Access............................................................................................................................... 45
Cheat Sheet: Enterprise DLP on Panorama Managed Prisma Access............... 46
Visibility and Monitoring Features in the Prisma Access App............................ 47
Monitor Your Prisma Access Data Transfer Usage............................................... 47
Plan for Prisma Access IP Address Changes...................................................................... 50
IP Address Allocation For Mobile Users on Prisma Access................................. 50
Remote Network IPSec Termination Nodes and Service IP Addresses on
Prisma Access................................................................................................................. 54
IP Address Changes For Remote Network Connections That Allocate
Bandwidth by Location................................................................................................ 55
Service IP and Egress IP Address Allocation for Remote Networks..................57
Retrieve the IP Addresses for Prisma Access.................................................................... 58
Run the API Script Used to Retrieve Prisma Access IP Addresses.................... 61
Prisma Access IP Address Retrieval Using the API Examples............................. 66
Pre-Allocate IP Addresses for Prisma Access Mobile User Locations...............68
Set Up Prisma Access IP Address Change Notifications......................................72
Use Legacy Scripts to Retrieve Loopback Addresses........................................... 73
Zone Mapping............................................................................................................................ 79
Prisma Access APIs...................................................................................................................80
Access the API Using the Browser and Web Interface........................................80

Prisma Access Administrator’s Guide (Panorama Managed) 3 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Table of Contents

Use curl Commands to Retrieve API Commands.................................................. 82

Use CLI Commands with Panorama Managed Prisma Access............................ 83
Prisma Access Deployment Progress and Status.............................................................. 84
Troubleshoot the Prisma Access Deployment................................................................... 88

Activate and Install the Prisma Access Components..............................95

Activate and Install Panorama Managed Prisma Access................................................. 96
Planning Checklist Before You Activate Panorama Managed Prisma
Access............................................................................................................................... 96
License Activation..........................................................................................................97
Verify Your Account Using the One-Time Password.................................................... 102
Transfer or Update Panorama Managed Prisma Access Licenses...............................103
Reset Your Panorama Managed Prisma Access License....................................104
Transfer or Update Prisma Access Licenses Between Panorama
Appliances..................................................................................................................... 106
Configure Panorama Appliances in High Availability for Panorama Managed Prisma
Access........................................................................................................................................ 109

Prepare the Prisma Access Infrastructure and Service

Connections.................................................................................................... 113
Set Up Panorama Managed Prisma Access......................................................................114
Prisma Access Service Infrastructure.................................................................................119
Service Infrastructure Requirements......................................................................119
Configure the Service Infrastructure......................................................................120
Prisma Access Service Connections...................................................................................127
Plan the Service Connections.................................................................................. 128
Create a Service Connection to Allow Access to Private Apps........................129
Create a Service Connection to Enable Access between Mobile Users and
Remote Networks....................................................................................................... 145
Prisma Access Locations....................................................................................................... 148
Prisma Access Locations by Compute Location.................................................. 148
Prisma Access Locations by Region........................................................................152
Map of North America Prisma Access Locations................................................ 157
Explicit Proxy Locations.............................................................................................158

Secure Mobile Users.....................................................................................161

Prisma Access Mobile User Deployments........................................................................ 162
GlobalProtect on Prisma Access......................................................................................... 163
Planning Checklist—GlobalProtect on Prisma Access.........................................163
IP Address Pools in a Mobile Users—GlobalProtect Deployment................... 166
Set Up GlobalProtect on Panorama Managed Prisma Access.......................... 167

Prisma Access Administrator’s Guide (Panorama Managed) 4 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Table of Contents

How the GlobalProtect App Selects a Prisma Access Location for Mobile
Users...........................................................................................................................................196
Explicit Proxy on Prisma Access......................................................................................... 198
How Explicit Proxy Works in Prisma Access........................................................198
How Explicit Proxy Identifies Users....................................................................... 199
Planning Checklist—Explicit Proxy.......................................................................... 200
Set Up Your Explicit Proxy PAC File......................................................................203
Secure Mobile Users with an Explicit Proxy.........................................................206
Monitor and Troubleshoot Explicit Proxy............................................................. 220
Monitor and Log Out GlobalProtect Users in Prisma Access...................................... 223
View GlobalProtect Mobile Users from the Status Tab.....................................223
View GlobalProtect Mobile Users from the Monitor Tab................................. 224
How Prisma Access Counts GlobalProtect Mobile Users..................................225
Manage GlobalProtect App Upgrades in Prisma Access...............................................229
Select the Active GlobalProtect App Version for Prisma Access.....................229
Manage User Access to GlobalProtect App Updates from Prisma Access.... 231
Perform Staged Updates of the GlobalProtect App on Prisma Access...........231
Deploy Explicit Proxy and GlobalProtect or a Third-Party VPN in Prisma
Access........................................................................................................................................ 235
Use Explicit Proxy with GlobalProtect and Third-Party VPNs Examples....... 235
How Explicit Proxy Works With GlobalProtect...................................................236
Requirements and Recommendations for Using Explicit Proxy with
GlobalProtect and Third-Party VPNs..................................................................... 239
Use Explicit Proxy with GlobalProtect...................................................................239
Use Explicit Proxy with Third-Party VPNs............................................................242
Integrate Prisma Access with On-Premises Gateways.................................................. 244
Manage Priorities for Prisma Access and On-Premises Gateways............................. 247
Set Equal Gateway Priorities for On-Premises and Prisma Access
Gateways....................................................................................................................... 247
Set a Higher Gateway Priority for an On-Premises Gateway...........................248
Set Higher Priorities for Multiple On-Premises Gateways................................249
Configure Priorities for Prisma Access and On-Premises Gateways...............250
Allow Mobile Users to Manually Select Specific Prisma Access
Gateways....................................................................................................................... 259
Allow Listing for Mobile Users—GlobalProtect Deployments..................................... 260
Manage Allow Listing for Existing Mobile User Deployments......................... 261
Manage Allow Listing for New Prisma Access Deployments........................... 262
Allow Listing Examples for Autoscale Events.......................................................264
Fields in the Egress IP Allow List table..................................................................265
Report Prisma Access Website Access Issues.................................................................269

Use Remote Networks to Secure Branches........................................... 271

Prisma Access Administrator’s Guide (Panorama Managed) 5 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Table of Contents

Prisma Access Remote Network Deployments...............................................................272

Planning Checklist—Prisma Access Remote Networks..................................................273
Onboard and Configure Remote Networks..................................................................... 276
Configure Prisma Access for Networks—Allocating Bandwidth by Compute
Location..........................................................................................................................276
Configure Prisma Access for Networks—Allocating Bandwidth by
Location..........................................................................................................................294
Verify Remote Network Connection Status......................................................... 314
Verify Remote Connection BGP Status................................................................. 318
Plan to Migrate to an Aggregate Bandwidth Remote Network Deployment........... 320
Bandwidth Allocation for a Migrated Aggregate Bandwidth Deployment.... 323
QoS Migration Guidelines......................................................................................... 325
Migrate to the Aggregate Bandwidth Model....................................................... 329
Remote Network Locations with Overlapping Subnets................................................ 332
Configure Remote Network and Service Connection Connected with a WAN
Link............................................................................................................................................. 334
Use Predefined IPSec Templates to Onboard Service and Remote Network
Connections..............................................................................................................................336
Onboard a Service Connection or Remote Network Connection Using
Predefined Templates................................................................................................ 337
Onboard Multiple Remote Network Connections of the Same Type............. 341
Supported IKE and IPSec Cryptographic Profiles for Common SD-WAN
Devices...........................................................................................................................342
Onboard Remote Networks with Configuration Import............................................... 343
Fields in Remote Networks Table........................................................................... 344

Configure User-ID and User-Based Policies with Prisma Access...... 355

Configure User-ID in Panorama Managed Prisma Access............................................ 356
Configure User-ID for Remote Network Deployments.................................................357
Get User and Group Information Using the Cloud Identity Engine............................360
Populate User and Group Names in Security Policy Rules...........................................363
Populate User Group Names in Security Policy Rules Using the Cloud Identity
Engine............................................................................................................................. 363
Populate User Group Names in Security Policy Rules Using a Master
Device.............................................................................................................................368
Use Long-Form DN Entries to Implement User- and Group-Based Policy.... 372
Redistribute User-ID Information Between Prisma Access and On-Premises
Firewalls.....................................................................................................................................373
Redistribute User-ID Information From Prisma Access to an On-Premise
Firewall........................................................................................................................... 373
Redistribute User-ID Information From an On-Premises Firewall to Prisma
Access.............................................................................................................................377

Prisma Access Administrator’s Guide (Panorama Managed) 6 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Table of Contents

Quality of Service in Prisma Access......................................................... 381

QoS Examples.......................................................................................................................... 382
Configure QoS in Prisma Access........................................................................................ 385
QoS for Remote Networks...................................................................................................386
QoS for Remote Networks Using Guaranteed Bandwidth and Bandwidth
Allocation Ratios..........................................................................................................386
Change the Guaranteed Bandwidth For Remote Networks............................. 387
Select QoS Profiles for Remote Networks........................................................... 390
Configure Quality of Service in Prisma Access............................................................... 392
Configure Quality of Service for Clean Pipe....................................................................405

Manage Multiple Tenants in Prisma Access........................................... 407

Multitenancy Overview......................................................................................................... 408
Multitenancy Configuration Overview.............................................................................. 409
Plan Your Multitenant Deployment................................................................................... 413
Create an All-New Multitenant Deployment...................................................................415
Enable Multitenancy and Migrate the First Tenant....................................................... 416
Add Tenants to Prisma Access............................................................................................422
Delete a Tenant.......................................................................................................................428
Create a Tenant-Level Administrative User..................................................................... 430
Control Role-Based Access for Tenant-Level Administrative Users...........................434
Remove Plugin Access for a Tenant-Level Administrative User...................... 435
Sort Logs by Device Group ID in a Multitenant Deployment......................................442

Prisma Access Advanced Deployments...................................................447

Advanced Deployments that Apply to All Prisma Access Types.................................448
Add a New Compute Location for a Deployed Prisma Access Location........ 448
IPv6 Support for Private App Access.....................................................................449
DNS Resolution for Mobile Users—GlobalProtect and Remote Network
Deployments.................................................................................................................464
How BGP Advertises Mobile User IP Address Pools for Service Connections
and Remote Network Connections........................................................................ 470
Proxy Support for Prisma Access and Cortex Data Lake.................................. 471
Prisma Access Service Connection Advanced Deployments....................................... 473
Service Connection Multi-Cloud Redundancy..................................................... 473
Use Traffic Steering to Forward Internet-Bound Traffic to Service
Connections.................................................................................................................. 485
Routing for Service Connection Traffic................................................................. 502
Create a High-Bandwidth Network Using Multiple Service Connections......515
Prisma Access Mobile Users—GlobalProtect Advanced Deployments...................... 527
Configure Multiple Portals in Prisma Access........................................................527

Prisma Access Administrator’s Guide (Panorama Managed) 7 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Table of Contents

Dynamic DNS Registration Support for Mobile Users—GlobalProtect.......... 533

Identification and Quarantine of Compromised Devices in a Prisma Access
GlobalProtect Deployment....................................................................................... 539
Sinkhole IPv6 Traffic In Mobile Users—GlobalProtect Deployments............. 552
Redistribute HIP Information with Prisma Access.............................................. 556
View HIP Reports from Panorama..........................................................................568
Support for Gzip Encoding in Clientless VPN...................................................... 570
Prisma Access Mobile Users—Explicit Proxy Advanced Deployments...................... 573
Secure Users and Devices at Remote Networks With an Explicit Proxy....... 573
Prisma Access Remote Network Advanced Deployments........................................... 578
Provide Secure Inbound Access to Remote Network Locations......................578
Create a High-Bandwidth Network for a Remote Site...................................... 601

Create and Configure Prisma Access for Clean Pipe............................611

Prisma Access for Clean Pipe Overview...........................................................................612
Clean Pipe Use Cases.................................................................................................612
Clean Pipe Examples.................................................................................................. 612
Clean Pipe and Partner Interconnect Requirements.......................................... 613
Configure Prisma Access for Clean Pipe...........................................................................616
Enable Multitenancy and Create a Tenant........................................................... 616
Complete the Clean Pipe Configuration................................................................623

Prisma Access Administrator’s Guide (Panorama Managed) 8 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview
Read the following sections to get an overview of what Prisma Access is, how it can secure your
organization’s resources, who owns and manages the infrastructure and network components,
and how to retrieve infrastructure and troubleshooting information.
• Prisma Access
• Prisma Access Infrastructure Management
• Releases and Upgrades
• Cadence for Software and Content Updates for Prisma Access
• Prisma Access Dataplane Upgrades
• Use the Prisma Access App to Get Upgrade Alerts and Updates
• View Prisma Access Software Versions
• Prisma Access Licensing
• Plan for Prisma Access IP Address Changes
• Retrieve the IP Addresses for Prisma Access
• Zone Mapping
• Prisma Access APIs
• Troubleshoot the Prisma Access Deployment
• Prisma Access Deployment Progress and Status

9
Prisma Access Overview

Prisma Access
As your business expands globally with new remote network locations popping up around the
globe and mobile users roaming the world, it can be challenging to ensure that your business
remains connected and always secure. Prisma Access uses a cloud-based infrastructure, allowing
you to avoid the challenges of sizing firewalls and compute resource allocation, minimizing
coverage gaps or inconsistencies associated with your distributed organization. The elasticity of
the cloud scales as demand shifts and traffic patterns change. The cloud service facilitates next-
generation security deployment to remote networks and mobile users by leveraging a cloud-based
security infrastructure managed by Palo Alto Networks. The security processing nodes deployed
within the service natively inspect all traffic in order to identify applications, threats, and content.
Prisma Access provides visibility into the use of SaaS applications and the ability to control which
SaaS applications are available to your users.

Prisma Access Administrator’s Guide (Panorama Managed) 10 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

With Prisma Access, Palo Alto Networks deploys and manages the security infrastructure
globally to secure your remote networks and mobile users. Prisma Access includes the following
components:
• Cloud Services Plugin—Panorama plugin that enables both Prisma Access and Cortex Data
Lake.
This plugin provides a simple and familiar interface for configuring and viewing the status of
Prisma Access. You can also create Panorama templates and device groups, or leverage the
templates and device groups you may have already created, to push configurations and quickly
enforce consistent security policy across all locations.

Prisma Access Administrator’s Guide (Panorama Managed) 11 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

• Service Infrastructure—Prisma Access uses an internal service infrastructure to secure your

organization’s network. You supply a subnet for the infrastructure, and Prisma Access uses
the IP addresses within this subnet to establish a network infrastructure between your
remote network locations and mobile users, and service connections to your internal network
resources (if applicable). Internal communication within the cloud is established using dynamic
routing.
• Service Connections—If your Prisma Access license includes it, you have the option to
establish IPSec tunnels to allow communication between internal resources in your network
and mobile users and users in your remote network locations. You could, for example, create a
service connection to an authentication server in your organization’s HQ or data center.
Even if you don’t require a service connection, we recommend that you create one with
placeholder values to allow network communication between mobile users and remote
network locations and between mobile users in different geographical locations.
• Prisma Access for Mobile Users—Provides consistent security for your mobile users whether
they are accessing applications at your data center, using SaaS applications, or browsing the
internet. You can enable your mobile users to connect to Prisma Access through:
• GlobalProtect
You can deploy the GlobalProtect app to your users (available for smartphones, tablets,
or laptops running Microsoft Windows, Apple macOS and iOS, Android, Google Chrome
OS, and Linux) so that they can tunnel the traffic to Prisma Access for policy enforcement
and threat prevention. The GlobalProtect app also provides host information profile (HIP)
reporting so that you can create granular policies based on device state to ensure that
endpoints adhere to your security standards—for example, they are equipped with the most
up-to-date patches, encryption, and virus definitions—in order to access your most sensitive
applications. Or, to enable secure access to users on unmanaged devices, you can enable
Clientless VPN. Prisma Access dynamically scales in and out per region based on where
your users are at the moment.
• Explicit Proxy
If your organization’s existing network already uses explicit proxies and deploys PAC files on
your client endpoints, you can smoothly migrate to Prisma Access to secure mobile users’
outbound internet traffic.
• Remote Networks—Use remote networks to secure remote network locations, such as
branches, and users in those branches with cloud-based next-generation firewalls. You can
enable access to the subnetworks at each remote network location using either static routes,
dynamic routing using BGP, or a combination of static and dynamic routes. All remote network
locations that you onboard are fully meshed.
• Multitenancy—If your organization requires that you manage multiple Prisma Access instances,
Prisma Access offers multitenancy, which enables you to create up to 200 instances (tenants)
on a single Panorama appliance (or 2 appliances in high availability (HA) mode), with each
tenant having their own separate templates and template stacks, device groups, and access
domains.

Prisma Access Administrator’s Guide (Panorama Managed) 12 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

• Prisma Access for Clean Pipe—The Prisma Access for Clean Pipe service allows organizations
that manage the IT infrastructure of other organizations, such as service providers, MSSPs, or
Telcos, to quickly and easily protect outbound internet traffic for their tenants.
Prisma Access for Clean Pipe has its own requirements; however, it requires the same
Panorama and Cortex Data Lake licenses as the other Prisma Access products described in this
section.
Prisma Access forwards all logs to Cortex Data Lake. You can view the logs, ACC, and reports
from Panorama for an aggregated view into your remote network and mobile user traffic. To
enable logging for Prisma Access, you must purchase a Cortex Data Lake license. Log traffic does
not use the licensed bandwidth you purchased for Prisma Access.

Prisma Access Administrator’s Guide (Panorama Managed) 13 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Prisma Access Infrastructure Management

Prisma Access uses a shared ownership model. Palo Alto Networks manages the underlying
security infrastructure, ensuring it is secure, resilient, up-to-date and available to you when you
need it. Your organization’s responsibility is to onboard locations and users, push policies, update
them, query logs, and generate reports.
Palo Alto Networks manages the following parts of the security infrastructure. In addition to the
security infrastructure, Prisma Access manages the cloud infrastructure components:
• Prisma Access
• Cortex Data Lake—We manage the delivery mechanism for logs.
• Content Updates—We manage the updating of the Prisma Access infrastructure, including
PAN-OS updates. For your mobile users, Prisma Access hosts several versions of the
GlobalProtect app and you can select the active GlobalProtect app version from that list.
• Fault Tolerance—We manage the availability of the service.
• Auto Scaling—We automatically scale the service when you add service connections or remote
networks, or when additional mobile users log in to one or more gateways in a single region.
• Provisioning—We provision the infrastructure with everything that is required.
• Service Monitoring—We monitor the service status and keep it functioning.
• Compute Location Mapping—Each Prisma Access location is mapped to security compute
location based on optimized performance and latency, which means that, unless otherwise
modified by a system administrator, the traffic in certain countries will be directed to a defined
compute location. See the Prisma Access Privacy Data Sheet for the location-to-compute
location mapping.
Your organization manages the following components of the security infrastructure.
• Users—You manage the onboarding of mobile users.
• Authentication—You manage the authentication of those users.
• Mobile device management (MDM)—You can control your organization's mobile devices that
are protected with Prisma Access using your own MDM software.
• Panorama and Cloud Services plugin—You make sure that the Panorama on which the Cloud
Services plugin is installed is running a Panorama version that supports the Cloud Services
plugin. In addition, you upgrade the Cloud Services plugin in Panorama after we inform you
that a new plugin is available.
• Policy creation and management—You plan for and create the policies in Panorama to use with
Prisma Access.
• Log analysis and forensics—Prisma Access provides the logs, you provide the analysis and
reporting, using integrated tools provided by us or by another vendor.
• On-premises security—You provide the on-premises security between micro-segmentations of
your on-premises network. In some deployments, you can also direct all traffic to be secured
with Prisma Access.
• Networking—You provide the network connectivity to Prisma Access.
• Monitoring—You monitor the on-premises network’s status.

Prisma Access Administrator’s Guide (Panorama Managed) 14 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

• Service Connectivity—You provide the connectivity to the Prisma Access gateway for mobile
users (for example, provide an ISP), and you also provide the on-premises devices used as the
termination points for the IPSec tunnels used by service connections and remote network
connections.
• Onboarding—You onboard the mobile users, HQ/Data center sites, and branch sites.

Prisma Access Administrator’s Guide (Panorama Managed) 15 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Releases and Upgrades

Prisma Access releases and updates allow you to stay up-to-date and secure your users. Some of
the updates are managed by Palo Alto Networks, such as Prisma Access infrastructure updates
and you will receive advance notification so you can plan around them. Other updates are your
responsibility and you must schedule the specified version of the content update, software
update, and plugin version (as required), at your earliest convenience.

You can retrieve the status of all cloud services, including Prisma Access and Cortex
Data Lake, along with a historical record of the uptime of each service, by accessing
the https://sase.status.paloaltonetworks.com/ website. You can also sign up for
email or text message updates at this site to be notified in advance when infrastructure
updates are planned and real-time notifications when updates occur, and when Palo Alto
Networks creates, updates, or resolves an incident.

• Prisma Access Release Types

• Prisma Access Upgrade Types
• Cadence for Software and Content Updates for Prisma Access
• Prisma Access Dataplane Upgrades
• Use the Prisma Access App to Get Upgrade Alerts and Updates

Prisma Access Release Types

Prisma Access has upgrades, including major releases and infrastructure maintenance, that include
new features and optimizations to deliver best-of-breed security for your remote networks and
mobile users.
The following list defines the release types, along with the advance notification we provide you
for each release. To make sure that you receive notifications for all releases, register for email or
text notifications for Prisma Access at the https://sase.status.paloaltonetworks.com/ website and
sign up for alerts in the Prisma Access app.
• Major Release—A major release typically includes significant new features and optimizations,
and such updates are pushed with a planned maintenance window set up by Palo Alto
Networks. Palo Alto Networks notify the customers of such planned maintenance activities via
email notifications via sase.status.paloaltonetworks.com and Prisma Access Insights. You must
subscribe to email alerts on both applications to stay up to date.
Notification—Palo Alto Networks provides you with the following notifications for major
releases:

Deployment Type Notification Period

Production Deployments Palo Alto Networks provides you with a

notification 21 days before a major release.

Prisma Access Administrator’s Guide (Panorama Managed) 16 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Deployment Type Notification Period

Lab Deployments Palo Alto Networks provides you with a

notification 7 days before a major release.

Lab tenants are not covered under the Prisma Access Service Level Agreement (SLA),
and customers are strongly advised to use the tenants only for pre-production testing
and qualification purposes.
• Infrastructure Maintenance—Includes incremental features and optimizations. In some cases,
Palo Alto Networks may combine a hotfix with infrastructure maintenance.
Notification—Palo Alto Networks provides you with the following notifications:

Deployment Type Notification Period

Production Deployments Palo Alto Networks provides you with a

notification 10 days before infrastructure
maintenance.

Lab Deployments Palo Alto Networks provides you with a

notification 7 days before infrastructure
maintenance.

• Cloud Services Plugin Release (Panorama Managed Deployments Only)—If Prisma Access
requires a new plugin, it is made available to download via the Palo Alto Networks Customer
Support Portal (CSP) and on Panorama by the following Tuesday (by 5 p.m. PST) after all
required upgrades have been successfully completed.
Notification—The service will send an email notification via Prisma Access Insights after the
plugin has been made available for the download.
Prisma Access may force all tenants to upgrade to a specific Cloud Services plugin
version to maintain backward compatibility and supported software versions. Such
enforcement activity will provide a 14-day advance notice (via Prisma Access Insights and
the sase.status.paloaltonetworks.com page) to plan for the upgrade of the plugin. The service
strongly recommends that you upgrade to the latest plugin as soon as it is available to
download.

Prisma Access Upgrade Types

Palo Alto Networks upgrades its cloud-based infrastructure without any intervention required
from you. Some upgrades require that you perform an action, such as install a new plugin.
The following list includes the different types of Prisma Access upgrades:
• Infrastructure Upgrade—Palo Alto Networks upgrades the Prisma Access infrastructure, which
includes the underlying service backend, orchestration, and monitoring infrastructure.

Prisma Access Administrator’s Guide (Panorama Managed) 17 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

• Dataplane Upgrade—Palo Alto Networks upgrades the Prisma Access dataplane that enables
traffic inspection and security policy enforcement on your network and user traffic.
You use the Prisma Access app to sign up for dataplane upgrade email alert notifications and
indicate your upgrade preferences.
• Cloud Services Plugin Upgrade (Panorama Managed Deployments Only)—When a new plugin
release becomes available, your network administrator will need to upgrade the Cloud Services
plugin on the Panorama appliance that manages Prisma Access.
• Panorama Software Version Upgrade (Panorama Managed Deployments Only) —An upgrade
of your Panorama software might be required to ensure continued compatibility with Prisma
Access.
The following table shows you what is included with each release, including the maintenance
window we provide and any impact to your Prisma Access service.

Upgrade Type Maintenance Window Impact

Infrastructure Upgrade 2-8 hours No impact to network

traffic; however you cannot
perform commits during the
maintenance window.
Palo Alto Networks schedules
the upgrades at a local time
that is minimally disruptive to
business functions.

Dataplane Upgrade 72 hours Palo Alto Networks uses

this window to upgrade the
dataplane for all customers.
You can make configuration
changes and commits during
this window. Our goal
is to minimize impact to
network traffic, but in some
cases there may be a brief
interruption. See Prisma
Access Dataplane Upgrades
for more information.
You use the Prisma
Access app to sign up for
dataplane upgrade email alert
notifications and indicate
your upgrade preferences,
including the preferred time
window for your upgrade.

Prisma Access Administrator’s Guide (Panorama Managed) 18 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Upgrade Type Maintenance Window Impact

Cloud Services Plugin You install the plugin when it Prisma Access might require
Upgrade (Panorama becomes available. you to upgrade all tenants
Managed Deployments Only) to a specific plugin version
to maintain backward
compatibility and supported
software versions.
During the plugin
upgrade, you cannot make
configuration changes and
commits in Panorama.

Panorama Software Version You schedule and perform When Prisma Access
Upgrade (Panorama the upgrade on the Panorama upgrades its infrastructure
Managed Deployments Only) that manages Prisma Access. and dataplane after a major
release, the upgrades can
be incompatible with earlier
Panorama versions. Because
of the fast-paced release
of Prisma Access and the
Cloud Services plugin, the
software compatibility
(end-of-support) dates for
Panorama are shorter than
the software end-of-life
dates for Panorama releases
and apply to Panorama
version compatibility with
Prisma Access only. For
more information, including
end-of-support dates for
Panorama when used with
Prisma Access, see Prisma
Access and Panorama Version
Compatibility in the Palo
Alto Networks Compatibility
Matrix.

Prisma Access Administrator’s Guide (Panorama Managed) 19 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Cadence for Software and Content Updates for Prisma

Access
The following table informs you of the software and content updates to get the latest applications
and threat signatures and leverage the threat prevention capabilities provided by Palo Alto
Networks. If the Cloud Controlled? column has an attribute of No, you perform the required
actions to update the component.

Component Update Schedule Cloud Controlled? Comments

(Yes/No)

Upgrades to For major Prisma No See End-of-Support

Panorama software Access releases, (EoS) Dates for
for compatibility with you might need Panorama Software
Prisma Access to upgrade your Version Compatibility
Panorama version with Prisma
for the following use Access to learn
cases: when a Panorama
version becomes
• Required
incompatible with
Upgrade—On
Prisma Access. See
occasion, you
Prisma Access and
will be required
Panorama Version
to upgrade the
Compatibility for the
software version
currently supported
on Panorama
Panorama versions
to maintain
to use with Prisma
compatibility with
Access. To upgrade
Prisma Access.
your Panorama to
• Maintenance a new version, see
Window—Your Install Content and
organization Software Updates for
will need to Panorama.
schedule a
maintenance
window to
upgrade the
Panorama
software
version.
• Impact—You
cannot use the
new plugin
version until
you upgrade

Prisma Access Administrator’s Guide (Panorama Managed) 20 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Component Update Schedule Cloud Controlled? Comments

(Yes/No)
your Panorama
version.
• Notification—
Palo Alto
Networks
will provide
you with a
notification 100
days before
the scheduled
major release
upgrade.
• Optional
Upgrade—In other
cases, you might
need to upgrade
the Panorama
software version
to use the new
features that
Prisma Access
supports in the
major release.
• Maintenance
Window—Your
organization
will need to
schedule a
maintenance
window to
upgrade the
Panorama
software
version.
• Impact—
You cannot
use the new
features that
Prisma Access
supports until
you upgrade
your Panorama.
• Notification—
Palo Alto
Networks will

Prisma Access Administrator’s Guide (Panorama Managed) 21 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Component Update Schedule Cloud Controlled? Comments

(Yes/No)
notify you of
any Panorama
requirements
21 days before
a scheduled
major release
upgrade as
defined in
Prisma Access
Release Types.

Cloud Services plugin Available after the No You perform the

version plugin release. tasks to upgrade the
plugin. See Prisma
Access Release Types
for details about
when Prisma Access
updates its plugin
version. See Upgrade
the Cloud Services
Plugin to upgrade
the plugin in the
Panorama appliance.

GlobalProtect app • Major Yes The cloud controls

GlobalProtect the versions of the
App Releases app that are available
(for example, x.0 for upgrade; however
or 5.x)—Prisma you can choose
Access updates between several
the agent on different hosted
the portal with versions of the app
the latest major and can control how
release 7-10 days and when to roll out
after the general GlobalProtect app
availability of the updates to the end
x.0.1 version of users. See Manage
that release. GlobalProtect App
Upgrades in Prisma
For example, given
Access for details.
an agent release of
5.1, Prisma Access If your Prisma
updates the agent Access deployment
on the portal 7-10 requires a hotfix of
days after the the GlobalProtect
release of 5.1.1. app, open a Support
Case with Palo
Alto Networks

Prisma Access Administrator’s Guide (Panorama Managed) 22 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Component Update Schedule Cloud Controlled? Comments

(Yes/No)
• Minor Technical Support for
GlobalProtect assistance.
App Releases (for
example, 5.1.x)
—Prisma Access
updates the agent
on the portal
with the latest
infrastructure
maintenance 7-10
days after the
general availability
of that release.

Applications and Daily with a threshold Yes

threat updates of 24 hours.
Palo Alto Networks
releases New
App-IDs on the
third Tuesday
of every month.
Plan to review
and incorporate
these new App-IDs
within the 24 hour
threshold.

Antivirus protection Every hour, 10 Yes Prisma Access is

minutes after the always up-to-date
hour with the latest
Antivirus release.

WildFire Real-Time Yes Prisma Access

retrieves WildFire
signatures for newly-
discovered malware
as soon as the
WildFire public cloud
can generate them.

GlobalProtect Data Every hour Yes Prisma Access is

File always up-to-date
with the latest
GlobalProtect data
file release.

Prisma Access Administrator’s Guide (Panorama Managed) 23 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Component Update Schedule Cloud Controlled? Comments

(Yes/No)

Clientless VPN Every hour Yes Prisma Access is

application signatures always up-to-date
with the latest
Clientless VPN
application signature
release.

Prisma Access Administrator’s Guide (Panorama Managed) 24 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Prisma Access Dataplane Upgrades

Prisma Access performs dataplane upgrades on the service to provide new security features
and capabilities to help protect your organization’s end-users, business assets, and digital
transformation. When a new version of Prisma Access requires a dataplane upgrade, you need to
understand how the upgrade process works and have the required prerequisites in place before
upgrading. The following sections provide an overview of the process, along with what you need
in order to have a successful upgrade.
• Dataplane Upgrade Overview
• Dataplane Upgrade Example

Dataplane Upgrade Overview

Prisma Access upgrades your dataplane in two phases on two weekend dates, and keeps you
informed about the upgrade using the Prisma Access app. On a high level, the following steps are
taken during the upgrade process.
• An email notification from the Prisma Access app arrives 21 days before the scheduled
dataplane upgrade start date. This email notification provides the dataplane upgrade start date
for phase #1.
• In the email, you are asked to select and submit the location or locations to upgrade first and
the preferred time window for the upgrade via the Prisma Access App.
You can change and submit the first locations to upgrade and time window multiple times for
a given tenant. The last submission that occurred seven days before the scheduled start date
will be chosen by the service for the upgrade. You will not be able to make any changes within
seven days of the upgrade start date.
If you make changes, it might take up to 30 minutes for the changes you made to be displayed
in the Upgrade Dashboard on Insights. You will be notified via email alert when the Prisma
Access has processed and completed the changes.

Palo Alto Networks strongly suggests that you select locations that reflect your entire
deployment. For example, if you have a mobile user, service connection, and remote
network deployment, select a location or locations that have all deployment types.
• Prisma Access will perform phase #1 of the upgrade on the selected location or locations
within the local time window selected for those locations.
• If the selected upgrade locations have any combination of Mobile Users—GlobalProtect,
Mobile Users—Explicit Proxy, Service Connections, or Remote Networks, the dataplane for
each deployment will be upgraded to the required dataplane version, as described later in this
section.
• Once the upgrade is complete in the first location, you’ll receive an email notification via the
Prisma Access app. Palo Alto Networks recommends that you monitor the service for any new
issues that occur immediately after the dataplane upgrade.

Prisma Access Administrator’s Guide (Panorama Managed) 25 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

• In an unlikely occurrence where you see a new issue, report the issue to Palo Alto Networks
technical support.
The technical support team will investigate the issue and take corrective actions that may also
include rolling back to the previous dataplane version. This decision will be communicated to
you via the technical support case.
• If there are no new issues or a new issue is not upgrade-related, Prisma Access will proceed
with the dataplane upgrade on the following weekend.
• The upgrade of the remaining locations will take place during the same time window you
selected for the first upgrade (in local time).
• After the dataplane upgrade completes, you will be notified via email alert.
The following figure shows the timeline used for the upgrade and includes the tasks that you
will need to perform for the dataplane upgrade (shown in green), as well as the steps that Prisma
Access performs.

The following section provides more details about the dataplane upgrade process.
After you sign up for notifications, Prisma Access informs you of the two weekend dates that
will be used for the upgrade process and sends these notifications 21 days, 3 days, and 24 hours
before the first phase of the upgrade will occur. The upgrade process occurs in two phases:
• Phase #1 upgrades the location or locations you chose on the first weekend using the time
window you provided and notifies you via email when the upgrade is complete. If you did not

Prisma Access Administrator’s Guide (Panorama Managed) 26 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

choose the locations to upgrade first, or did not select a time window, Prisma Access makes
the choices for you.

Palo Alto Networks attempts to upgrade the locations during the four-hour window
that you select via the Prisma Access app. However, completing the required upgrades
during this window is best-effort and Palo Alto Networks cannot guarantee that the
locations will be upgraded during that time. If the locations cannot be upgraded within
the specified time window, you will receive an email notification. Palo Alto Networks
recommends that you schedule a change request window starting at 8 p.m. local time
on Friday and ending at 8 p.m. local time on Sunday for each of the two weekends
when the dataplane upgrade occurs.

Prisma Access makes the following changes to your deployment during Phase #1 of the
upgrade.

Deployment Type What is Upgraded

Mobile User Deployments Prisma Access upgrades a single mobile user

gateway, also known as the Mobile User
Security Processing Node (MU-SPN), for the
location or locations you specify.

Remote Network Deployments Prisma Access upgrades the backup (HA)

remote network, also known as the Remote
Network Security Processing Node (RN-SPN),
then makes the backup remote network
the active node for the location or locations
you specify. The backup remote network
connection is not upgraded until the following
weekend, when the active and backup nodes
are upgraded for all locations.
If there are multiple RN-SPNs in the selected
location, all primary nodes are upgraded to the
new dataplane version.

Service Connections Prisma Access upgrades the backup (HA)

service connection, also known as the Service
Connection Corporate Access Node (SC-CAN),
then makes the backup service connection the
active node for the location or locations you
specify. The backup service connection is not
upgraded until the following weekend, when
the active and backup nodes are upgraded for
all locations.

Prisma Access Administrator’s Guide (Panorama Managed) 27 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Deployment Type What is Upgraded

If there are multiple SC-CANs in the selected
location, all backup nodes are upgraded to the
new dataplane version.

Between the first and second upgrades, monitor the first upgraded locations and perform
connectivity, performance, routing, and logging testing to make sure that the locations
upgraded successfully. If you encounter a service-impacting failure after the upgrade, open a
Support Case with Palo Alto Networks Technical Support for assistance. Palo Alto Networks
will attempt to resolve the issue by rolling back the dataplane to a previous dataplane version
within 24 hours.
• Seven days after Prisma Access upgrades the first location, Prisma Access upgrades the
remainder of your locations (Phase #2 upgrade), using the same time window you selected for
the first phase, and notifies you via email when the upgrade is complete.

The upgrade window can be longer. For example, if Phase #2 occurs during a national
holiday in the United States of America, the second phase of the upgrade happens 14
days after the first phase instead of seven. The notifications you receive in the Prisma
Access app show you the specific timeline for the upcoming dataplane upgrade.
The Prisma Access dataplane version is updated in the UI only after all phases of the upgrade
(both Phase #1 and Phase #2) have been completed.

Dataplane Upgrade Example

The following example shows a sample dataplane upgrade procedure for a Mobile Users
deployment with five locations (MU-SPNs) and three SC-CANs. The US West location has two
MU-SPNs as the result of an autoscale event (an extra MU-SPN was added after a large number
of mobile users logged in to that location).

Prisma Access Administrator’s Guide (Panorama Managed) 28 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

In this example, you selected a single location (US West) to upgrade first, and requested a four-
hour upgrade window of 8:00 a.m. to 12:00 noon Saturday for the upgrade.
On the first upgrade weekend (Phase #1), the dataplane upgrade for one of the MU-SPNs and the
primary node of the SC-CAN in the US West location takes place between 8:00 a.m. and 12:00
p.m. Pacific Time on Saturday.

To determine the MU-SPN that was upgraded, contact your authorized Palo Alto
Networks representative or partner.

Prisma Access Administrator’s Guide (Panorama Managed) 29 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Seven days after the first location is upgraded, Palo Alto Networks upgrades the remaining
components (Phase #2), including all the MU-SPNs and SC-CANs in the deployment, using the
same four-hour time window as was used for the first phase of the upgrade (8:00 a.m. to 12:00
p.m. on Saturday).
In this example, Prisma Access uses the following time zone information when upgrading the
dataplane:
• The remaining MU-SPN (MU-SPN 2) in the US West location is upgraded.
• The Japan Central MU-SPN and SC-CAN are upgraded using the local time in Japan.
• The UK MU-SPN and SC-CAN are upgraded using the local time in the UK.
• The US Southwest MU-SPN is upgraded using Pacific Time.

Prisma Access Administrator’s Guide (Panorama Managed) 30 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Prisma Access Administrator’s Guide (Panorama Managed) 31 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Use the Prisma Access App to Get Upgrade Alerts and

Updates
To stay informed about the upgrade schedule for your dataplane upgrade and to select your
upgrade preferences, you must use the Prisma Access app to subscribe to Prisma Access
notifications. Prisma Access uses email alerts to inform you of the two weekend dates when your
upgrade occurs; you select the location or locations you want to upgrade first and the four-hour
time window to use for the upgrade.
After the upgrade starts, you can also monitor the status of the upgrade using the Prisma Access
app as shown in the following steps.
STEP 1 | Sign up for alert notifications from the Prisma Access app.

STEP 2 | Check your notifications to be made aware of upcoming dataplane upgrades; then, select
your upgrade preferences using one of the following methods.
• Select Insights > Prisma Access Upgrade > Upgrade Preferences.
• Log in to the Prisma Access app, view the banner at the top of the page for your scheduled
upgrade, and select Click here.

• Check your email for notifications for your scheduled upgrade and click the hyperlink in the
email.
• Select Insights > Prisma Access Upgrade > Upgrade Preferences.
The Prisma Access Upgrade Dashboard displays.

STEP 3 | (Optional) Read the Upgrade Process to learn more about how the upgrade process works.

Prisma Access Administrator’s Guide (Panorama Managed) 32 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

STEP 4 | Select your Upgrade Preferences.

If you have a multitenant deployment, all tenants display in this area. If you have already
selected your upgrade preferences for your deployment, these selections display here.
1. Select the tenants for which to set upgrade preferences, then select Edit Preferences.

2. Select the Preferred Prisma Access Locations that you want to upgrade first.

Palo Alto Networks strongly suggests that you select locations that reflect your
entire deployment. For example, if you have a mobile user, service connection,
and remote network deployment, select a location or locations that have all
deployment types.

Select from the choices in the drop-down list.

• Prisma Access only displays the locations where you have deployed mobile users,
remote networks, service connections, or any combination thereof.
• The groups in the drop-down list belong to the same compute location.
Prisma Access will inform you via email alerts when the locations were upgraded.

Prisma Access Administrator’s Guide (Panorama Managed) 33 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

After the first set of Prisma Access locations is upgraded successfully, the Prisma Access
team monitors these locations for seven days, and then upgrades all remaining Prisma
Access locations. Selecting a single location or a small number of locations gives you a
chance to monitor these locations before the remainder of your locations are upgraded
one week later.
If no locations display in the drop-down list, you either selected multiple tenants that
have no common locations deployed or you have not yet onboarded any locations for
the tenants you selected.
3. Select the Preferred time for the upgrade window from the list of available options.
Choose from the following upgrade time windows. The time windows are local to the
location or locations being upgraded and are all four hour windows:
• Friday 8:00 p.m. to 12:00 a.m. (midnight)
• Saturday 12:00 a.m. (midnight) to 4:00 a.m.
• Saturday 4:00 a.m. to 8:00 a.m.
• Saturday 8:00 a.m. to 12:00 p.m. (noon)
• Saturday 12:00 p.m. (noon) to 4:00 p.m.
• Saturday 4:00 p.m. to 8:00 p.m.
Palo Alto Networks uses your preference to begin the rollout at the Prisma Access
location or locations you selected.The last submission that occurred seven days before
the scheduled start date will be chosen by the service for the upgrade. If you make
changes, it might take up to 30 minutes for the changes you made to be displayed in

Prisma Access Administrator’s Guide (Panorama Managed) 34 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

the Upgrade Dashboard on Insights. You will be notified via email alert when the Prisma
Access has processed and completed the changes.

If you do not provide your upgrade preferences seven days before the scheduled
upgrade window, Palo Alto Networks will automatically select the first set of
your deployed Prisma Access locations, notify you of the selection, and upgrade
the selected locations on the scheduled date. The remaining Prisma Access
locations, if any, in your deployment will be upgraded seven days after the
selected time window.

4. Select the Software Version that you want to upgrade to, if more than one version is
available.
5. Submit your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 35 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

STEP 5 | After your rollout begins, select Insights > Prisma Access Upgrade > Upgrade Status
by Tenants and view the Upgrade Status by Location. This page displays the following
information for each location that is being upgraded:
• The name of the tenant that is being upgraded.
• The start and finish date of the upgrade process.
• The dataplane version that the tenant is being upgraded to.
• The preferred time window for the upgrade.
• The initial locations that are being upgraded.
• The date that the remaining locations will be upgraded.
In addition, a table displays the locations being upgraded, the start date and time window of
the upgrade, and the time zone used for the upgrade. The Upgrade Status column provides
you with the following information:

Upgrade Status Description

Scheduled The dataplane upgrade has been scheduled.

Started The upgrade has started.

In Progress The dataplane upgrade is in progress.

Re-trying The dataplane upgrade did not complete

successfully, but Prisma Access continues to be
operational using the older dataplane version.
Prisma Access will retry the upgrade before the
maintenance window for the weekend expires.

Success The upgrade completed successfully.

STEP 6 | After the first set of locations has completed the dataplane upgrade, monitor the upgraded
locations and perform connectivity, performance, routing, and logging testing to make sure
that they upgraded successfully.

STEP 7 | When the second set of locations is scheduled to be upgraded, monitor those locations
and check their status by selecting Insights > Prisma Access Upgrade > Upgrade Status by
Tenants.
Prisma Access sends you an email notification after the dataplane upgrade is complete.

Prisma Access Administrator’s Guide (Panorama Managed) 36 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

View Prisma Access Software Versions

Prisma Access consists of components you manage such as Panorama and the Cloud Services
plugin, components that Prisma Access manages such as the dataplane version, and components
that Prisma Access manages but whose version you can control (the GlobalProtect version
hosted on the Prisma Access portal). The Service Setup page (Panorama > Cloud Services >
Configuration > Service Setup shows you the status of these components in a single page. This
page also contains notifications that show you when your current running Panorama version
and plugin versions will be end of support (EoS) for use with Prisma Access. Palo Alto networks
provides you with advance notice of EoS dates to give your organization sufficient time to plan
the upgrade.

All dates are in Coordinated Universal Time (UTC).

The Service Setup page provides you with the following information:

Prisma Access Administrator’s Guide (Panorama Managed) 37 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Area Description

Panorama Alert Displays the current Panorama version that

you are running. The Upgrade requirements
area provides you with information about
Panorama versions, including dates when
currently compatible Panorama versions reach
their end of support (EoS) dates for managing
Prisma Access. Use this information to plan your
Panorama upgrade in advance of its EoS date.

Plugin Alert Displays the current Cloud Services plugin

that is installed on the Panorama that manages
Prisma Access. The Upgrade requirements
area provides you with dates when the next
plugin version will be released, the deadline
for upgrading to the next plugin, and the date
when you will not be able to make changes
and commits using the earlier plugin version.
Use this information to plan for the next Cloud
Services plugin upgrade.

Prisma SD-WAN Integration Status Select Integrate with Prisma SD-WAN to

activate the CloudBlade thin client that allows
functionality between Prisma SD-WAN and
Prisma Access.

Generate Certificate for GlobalProtect App If you have enabled GlobalProtect App Log
Log Collection and Autonomous DEM Collection for Troubleshooting, or to enable
Autonomous Digital Experience Management
(ADEM) for your mobile users, click here
to generate a certificate. This certificate
allows GlobalProtect app to authenticate

Prisma Access Administrator’s Guide (Panorama Managed) 38 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Area Description
with Cortex Data Lake (to collect logs) and
Autonomous DEM. When you generate the
certificate, Prisma Access also downloads
the certificate to the Device Certificates in
Panorama Device > Certificate Management
> Certificates > Device Certificates under
the Mobile_User_Template template in the
Shared to be pushed to the mobile device.

GlobalProtect App Activation Displays the currently-running (active) version

of the GlobalProtect app that mobile users can
download from the Prisma Access portal, and
shows you the available GlobalProtect app
versions to which you can upgrade.

Dataplane PAN-OS version Displays the current PAN-OS version that

your dataplane is running. The dataplane is the
component of the Prisma Access infrastructure
that enables traffic inspection and policy
enforcement on your network and user traffic.

Share/Delete Contact Information Allows you to share contact information

(Company name, contact name, email, and
phone number) so that you can be contacted
about Palo Alto Networks service upgrades.
If you have previously entered contact
information, you can delete the information you
entered in this area.
Do not use any of the following special
characters in the contact information area:
• " (Double quotes)
• ' (Apostrophe)
• < (less than sign)
• > (greater than sign)
• & (ampersand)

Area Description

Panorama Alert Displays the current Panorama version that

you are running. The Upgrade requirements
area provides you with information about
Panorama versions, including dates when
currently compatible Panorama versions reach
their end of support (EoS) dates for managing

Prisma Access Administrator’s Guide (Panorama Managed) 39 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Area Description
Prisma Access. Use this information to plan your
Panorama upgrade in advance of its EoS date.

Plugin Alert Displays the current Cloud Services plugin

that is installed on the Panorama that manages
Prisma Access. The Upgrade requirements
area provides you with dates when the next
plugin version will be released, the deadline
for upgrading to the next plugin, and the date
when you will not be able to make changes
and commits using the earlier plugin version.
Use this information to plan for the next Cloud
Services plugin upgrade.

Prisma SD-WAN Integration Status Select Integrate with Prisma SD-WAN to

activate the CloudBlade thin client that allows
functionality between Prisma SD-WAN and
Prisma Access.

Generate Certificate for GlobalProtect App If you have enabled GlobalProtect App Log
Log Collection and Autonomous DEM Collection for Troubleshooting, or to enable
Autonomous Digital Experience Management
(ADEM) for your mobile users, click here
to generate a certificate. This certificate
allows GlobalProtect app to authenticate
with Cortex Data Lake (to collect logs) and
Autonomous DEM. When you generate the
certificate, Prisma Access also downloads
the certificate to the Device Certificates in
Panorama Device > Certificate Management
> Certificates > Device Certificates under
the Mobile_User_Template template in the
Shared to be pushed to the mobile device.

GlobalProtect App Activation Displays the currently-running (active) version

of the GlobalProtect app that mobile users can
download from the Prisma Access portal, and
shows you the available GlobalProtect app
versions to which you can upgrade.

Prisma Access Version Displays the current Prisma Access version

and the PAN-OS version that your dataplane
is running. The dataplane is the component of
the Prisma Access infrastructure that enables
traffic inspection and policy enforcement on
your network and user traffic.

Prisma Access Administrator’s Guide (Panorama Managed) 40 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Area Description

Share/Delete Contact Information Allows you to share contact information

(Company name, contact name, email, and
phone number) so that you can be contacted
about Palo Alto Networks service upgrades.
If you have previously entered contact
information, you can delete the information you
entered in this area.
Do not use any of the following special
characters in the contact information area:
• " (Double quotes)
• ' (Apostrophe)
• < (less than sign)
• > (greater than sign)
• & (ampersand)

Prisma Access Administrator’s Guide (Panorama Managed) 41 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Prisma Access Licensing

Prisma Access offers a licensing model that allows you to implement and use the capabilities
of Prisma Access aligned to your business needs in a way that delivers the fastest return on
investment. Whether your applications are migrating to the cloud, your users are working from
anywhere, or if you are looking to gain operational efficiencies, Prisma Access offers the relevant
type of license for your deployment.
You can choose from the following license editions (more details are in the Prisma Access
Licensing Guide):
• Business
• Business Premium
• Zero Trust Network Access (ZTNA) Secure Internet Gateway (SIG)
• Enterprise

Your Prisma Access license edition determines the security capabilities that are available
to you. If you use any capability in security rules or profiles that is unsupported based on
your license type, Prisma Access removes those configurations and those capabilities are
not enforced in your Prisma Access tenants until you update Prisma Access with a license
edition that supports those capabilities. To find the capabilities included with your license,
see the Prisma Access Licensing Guide.

All license editions are available for Local and Worldwide Prisma Access locations. When you
purchase a license with Worldwide locations, you can deploy Prisma Access in all Prisma Access
locations. When you purchase a license with Local locations, you can select up to five Prisma
Access locations.
Prisma Access uses units in licenses, and uses the following definitions for a unit:
• For mobile user deployments, a unit is defined as one mobile user. When you assign units in
Prisma Access from your Mobile users license, each unit allows a mobile user to utilize Prisma
Access—GlobalProtect, Prisma Access—Explicit Proxy, or both GlobalProtect and Explicit
Proxy.
• For remote network and Clean Pipe deployments, a unit is defined as 1 Mbps of bandwidth.

When a Prisma Access license expires, you can still use the service and collect logs for 15
days after license expiration. You cannot make changes to configuration. Prisma Access
shuts down its instances 15 days after license expiration and completely deletes the
instances and tenants 30 days after license expiration.

License Enforcement for Prisma Access Mobile User Deployments

Prisma Access uses these enforcement policies for mobile user licenses:
• Though there is no strict policing of the mobile user count, the service does track the number
of unique users over the last 90 days to ensure that you have purchased the proper license tier
for your user base, and stricter policing of user count may be enforced if continued overages
occur.

Prisma Access Administrator’s Guide (Panorama Managed) 42 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

• In addition, if you use Prisma Access for users—GlobalProtect, the GlobalProtect app is
required on each supported endpoint. The GlobalProtect app is not required for Mobile Users—
Explicit Proxy deployments.

Other Required Prisma Access Licenses

In addition to the Prisma Access licenses, in order to run the service you must also have the
following licensed components:
• Panorama—You deploy and manage Prisma Access using the Cloud Services plugin for
Panorama. In order to use this plugin, you must have Panorama with a valid support license.
See the Palo Alto Networks Compatibility Matrix for the Panorama versions that are supported
with the Cloud Services plugin. When you license the Prisma Access components, you must tie
the auth code to a licensed Panorama serial number.
• Cortex Data Lake—The Prisma Access infrastructure forwards all logs to Cortex Data Lake. You
can view the Prisma Access logs, ACC, and reports directly from Panorama for an aggregated
view into your remote network and mobile user traffic. To enable logging for Prisma Access,
you must purchase a Cortex Data Lake license.

Prisma Access Add-On Licenses

You can add the following capabilities to use with Prisma Access as an add-on license:
• Get Started
• Cheat Sheet: Enterprise DLP on Panorama Managed Prisma Access
• Cheat Sheet: Integrate IoT Security with Panorama Managed Prisma Access
• SaaS Security Inline

Determine Your Prisma Access License Type from Panorama

Some license requirements, such as the requirements you need to enable tenants in a multitenant
configuration, are dependent on the type of Prisma Access license you have. To determine your
license type, select Panorama > Licenses and find the information in the Prisma Access area.
Licenses available after November 17, 2020 include the license Edition and provide you with the
type of Prisma Access Locations you can deploy (either Local or Worldwide locations).

Prisma Access Administrator’s Guide (Panorama Managed) 43 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Licenses available before November 17, 2020, contain the words GlobalProtect Cloud Service in
the license areas and are divided by remote networks, mobile users, or Clean Pipe.

Cheat Sheet: Integrate ADEM with Panorama Managed Prisma

Access

This feature requires the Autonomous DEM add-on license to use with Panorama Managed
Prisma Access.

Prisma Access Administrator’s Guide (Panorama Managed) 44 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Check what’s available with your Panorama Managed Prisma Access subscription.

Autonomous Digital Experience Management (ADEM) provides native, end-to-end visibility

and performance metrics for real application traffic in your Secure Access Service Edge (SASE)
environment.

Get Started
Here’s how to get up and running with ADEM on Panorama Managed Prisma Access.

Check that your license covers ADEM.

• Here’s how to check what’s available with your license

Learn about how ADEM works for a Panorama Managed Prisma Access Mobile Users—
GlobalProtect and Remote Network deployment.

Enable ADEM for your Mobile Users—GlobalProtect and Remote Networks deployments.
• Enable ADEM in Panorama Managed Prisma Access for a Mobile Users—GlobalProtect
deployment
• Enable ADEM in Panorama Managed Prisma Access for a Remote Network deployment

Manage ADEM mobile users and remote sites.

Learn how to use Autonomous DEM in Prisma Access to troubleshoot common help desk
scenarios, such as complaints about application access, or end users reporting performance
issues.

Cheat Sheet: Integrate IoT Security with Panorama Managed

Prisma Access

This feature requires the IoT Security add-on license to use with Panorama Managed Prisma
Access.

Check what’s available with your Panorama Managed Prisma Access subscription.

IoT Security is an on-demand cloud subscription service designed to discover and protect
the growing number of connected “things” on your network. Unlike IT devices such as laptop
computers that perform a wide variety of tasks, IoT devices tend to be purpose-built with a
narrowly defined set of functions. As a result, IoT devices generate unique, identifiable patterns
of network behavior. Using machine learning and AI, IoT Security recognizes these behaviors and
identifies every device on the network, creating a rich, context-aware inventory that’s dynamically
maintained and always up to date.

Prisma Access Administrator’s Guide (Panorama Managed) 45 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

After it identifies a device and establishes a baseline of its normal network activities, it continues
monitoring its network activity so it can detect any unusual behavior indicative of an attack or
breach. If it detects such behavior, IoT Security notifies administrators through security alerts in
the IoT Security portal and, depending on each administrator’s notification settings, through email
and SMS notifications.
You get the same benefits from integrating IoT Security with Prisma Access as you do from
integrating it with next-generation firewalls. IoT is available as an add-on; after you purchase the
add-on, you activate your product during Prisma Access installation.

Get Started
Here’s how to get up and running with IoT Security on Panorama Managed Prisma Access.

Check that your license covers IoT Security.

• Here’s how to check what’s available with your license

Learn how Prisma Access works with IoT Security instead of next-generation firewalls.

Integrate IoT Security with Prisma Access.

Check the status of your IoT Security Integration with Prisma Access.

Cheat Sheet: Enterprise DLP on Panorama Managed Prisma

Access

This feature requires the Enterprise DLP add-on license to use with Panorama Managed Prisma
Access.

Check what’s available with your Panorama Managed Prisma Access subscription.

Data loss prevention (DLP) is a set of tools and processes that allow you to protect sensitive
information against unauthorized access, misuse, extraction, or sharing. Using the Enterprise
DLP plugin with Prisma Access enables you to use Prisma Access to enforce your organization’s
data security standards and prevent the loss of sensitive data across mobile users and remote
networks.
Prisma Access integrates its DLP capability to allow you to use the same DLP capabilities as
that used in Panorama and on next-generation firewalls. This integration provides you with an
improved experience that allows you to use the same DLP patterns, profiles, and rules as those
used in next-generation firewalls.
Use DLP with Panorama Managed Prisma Access by installing the Enterprise DLP plugin on the
same Panorama appliance that manages Prisma Access.

Prisma Access Administrator’s Guide (Panorama Managed) 46 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

If you are migrating from an existing DLP on Prisma Access license to the DLP plugin,
the locations of data patterns and data filtering profiles move in Panorama after the
migration:
• Data patterns move from Objects > Custom Objects > Data Patterns to Objects >
DLP > DLP Data Patterns.
• Data filtering profiles move from Objects > Security Profiles > Data Filtering to
Objects > DLP > DLP Data Filters.

Visibility and Monitoring Features in the Prisma Access App

Even though you’re using Panorama to manage Prisma Access, there are visibility and monitoring
features that are available to you in the Prisma Access app.
Log in to the hub and launch the Prisma Access app to find:
• Insights—Prisma Access Insights gives you a way to continuously monitor your Prisma Access
environment. When an event or status requires your attention, Insights sends you alert
notifications so you can quickly pinpoint issues that you can fix. It also gives you the visibility
into the fixes that the Prisma Access team is working on.
• Autonomous Digital Experience Management (ADEM)—Provides native, end-to-end visibility
and insights for all user traffic in your Secure Access Service Edge (SASE) environment. ADEM
functionality is natively integrated into the GlobalProtect app and Prisma Access and therefore
does not require you to deploy any additional appliances or agents. You can quickly isolate the
source of digital experience problems, and simplify remediation.
This feature requires the Autonomous DEM add-on license to use with Panorama Managed
Prisma Access.
• Activity—Activity identifies key findings that you can use to inform your policy updates and
close enterprise security and user productivity gaps. Activity gives you:
• Interactive dashboards where you can explore data for the applications, threats, users,
security subscriptions at work in your network
• Reports that you can share offline and schedule for regular updates
• A Log Viewer, which provides an audit trail for system, configuration, and network events.

Monitor Your Prisma Access Data Transfer Usage

You can view data transfer statistics for your mobile users, remote networks, and Clean Pipe
deployments using the Data Transfer tab (Panorama > Cloud Services > Status > Data Transfer).
This tab appears if you have the Prisma Access Edition licenses that became available after
November 2020. If you have a legacy license that was available before November 2020, this tab
does not display.
Prisma Access tracks this usage in a one-year period, starting with the date that you activate your
license.

Prisma Access Administrator’s Guide (Panorama Managed) 47 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Prisma Access tracks your data transfer for mobile users, remote networks, and Clean Pipe per
unit, and tracks the data starting on the date of your license activation. Units are based on the
type of Prisma Access license you have; for mobile users, a unit is one mobile user and for remote
networks, a unit is 1 Mbps.
Prisma Access allocates 250 GB of data for each unit per year, starting on the date of your license
activation. If you have a license with multiple types of Prisma Access deployments, Prisma Access
combines the units for all licenses you have to determine the maximum amount of data you can
transfer during a 1 year period. The following table provides examples of the data transfer limit by
license type and units purchased.
If you have a multitenant deployment, data transfer across all tenants must add up to the total
data transfer limit based on the allocated units in your license.

Quantity Purchased in Units Data Transfer Limit

1,000 Mobile Users and Remote Networks 250 Terabytes/Year (250 GB * 1,000 units)

1,000 Mobile Users only 250 Terabytes/Year (250 GB * 1,000 units)

1,000 Remote Networks only 250 Terabytes/Year (250 GB * 1,000 units)

1,000 Mobile Users and Remote Networks 500 Terabytes/Year (250 GB * 2,000 units)
1,000 Mobile Users only

1,000 Mobile Users and Remote Networks 500 Terabytes/Year (250 GB * 2,000 units)
1,000 Remote Networks only

The Data Transfer page includes the following fields.

Field Description

MU Usage The amount of mobile user data usage.

This data includes mobile user traffic for each type of
mobile user deployment (Mobile Users—GlobalProtect

Prisma Access Administrator’s Guide (Panorama Managed) 48 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Field Description
and Mobile Users—Explicit Proxy), and includes both
internal and internet traffic.

Net Usage The amount of remote network data usage. If you

have a Clean Pipe deployment, data usage is displayed
here.
This data includes both internal and internet traffic.

Internet Traffic Traffic sent and received from Prisma Access to

the internet, including all internet and public SaaS
applications.
Any traffic sent from Mobile Users—GlobalProtect,
Mobile Users—Explicit Proxy, and Remote Networks
to the internet, and all Explicit Proxy traffic, displays
in the Internet Traffic area.

Internal Traffic Traffic that matches the following conditions:

• Traffic from a remote network site to another
remote network site using remote network
connections.
• Traffic from a remote network site to a data
center or headquarters location using a remote
network connection (for the remote network site)
and a service connection (for the data center or
headquarters location).
• Traffic from a mobile user to a remote network site
using a GlobalProtect VPN tunnel and a remote
network connection.
• Traffic from a mobile user to a data center or
headquarters location using a GlobalProtect VPN
tunnel and a service connection.

Prisma Access Administrator’s Guide (Panorama Managed) 49 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Plan for Prisma Access IP Address Changes

After you set up your Prisma Access deployment, it is useful to know when IP addresses change
so that you can pro-actively plan your infrastructure, retrieve the IP addresses, and add the
required IP addresses to allow lists accordingly. The IP address changes can be the result of
changes you made (for example, adding another mobile users location) or changes that Prisma
Access performs automatically (for example, a large number of mobile users accesses a single
Prisma Access gateway).
The following sections describe how IP addresses can change:
• IP Address Allocation For Mobile Users on Prisma Access
• Remote Network IPSec Termination Nodes and Service IP Addresses on Prisma Access
• Add a New Compute Location for a Deployed Prisma Access Location
• IP Address Changes For Remote Network Connections That Allocate Bandwidth by Location
• Loopback IP Address Allocation for Mobile Users

IP Address Allocation For Mobile Users on Prisma Access

After you deploy Prisma Access for users for the first time, Prisma Access assigns two public and,
if applicable, egress IP addresses for each portal and gateway. These IP addresses are unique, not
shared, are dedicated to your Prisma Access deployment, and remain allocated to your tenant
until the Prisma Access subscription expires and the grace period is over.
If you have a multitenant setup, Prisma Access adds dedicated IP addresses for each tenant.
Since the public IP address is the source IP address used by Prisma Access for requests made
to an internet-based destination, you may need to know what the public IP address are and add
them to an allow list in your network to provide your users access to resources such as SaaS
applications or publicly-accessible partner applications.
New public IP addresses can be added to the tenant if the following events occur:
• A large number of mobile users access a location in the same location.
To address the capacity requirement to service large number of users, Prisma Access may
add one or more gateways, Prisma Access adds one or more gateways to accommodate the
increased number of users, assigns one or more of the existing public IP addresses to the new
gateway, and adds a new set of IP addresses to the mobile user locations to replace the ones
that were used.
• You add one or more locations to your deployment.
When you add more locations, Prisma Access adds another gateway and a new set of IP
addresses for each new location you add.
Because Prisma Access enables more public IP addresses after a scaling event and after you add
a location, you should add an IP change event notification URL, or use the API to retrieve mobile
user addresses, to be notified of IP address changes in your Prisma Access infrastructure. You can
then add any added or changed addresses to an allow list.

Prisma Access Administrator’s Guide (Panorama Managed) 50 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Public IP Address Scaling Examples for Mobile Users

The following examples illustrate the mobile user public IP address allocation process that Prisma
Access uses during a scaling event or when you add a new location.
In the following example, you specified two locations in the Asia Pacific region for a new mobile
user deployment: Sydney and Seoul. Each location is given two gateway IP addresses.

Then a large number of users log in to the Seoul location. To accommodate these extra users,
Prisma Access adds a second gateway for the Seoul location, takes one of the gateway addresses
from the first Seoul gateway (51.1.1.4) and assigns it to the second Seoul gateway. It then adds
two additional IP addresses (51.1.1.5 and 51.1.1.6 in this example) and adds them to the two
Seoul gateways.

Prisma Access Administrator’s Guide (Panorama Managed) 51 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Then you add another location, Tokyo, in the Asia Pacific region. Prisma Access creates two new
IP addresses for the new gateway (51.1.1.7 and 51.1.1.8).

Each time you add a location or have a scaling event, you should retrieve the new egress and
gateway IP addresses that Prisma Access assigned and add them to an allow list in your network.
Prisma Access keeps two sets of IP addresses at all times for all active gateways in each location.

Loopback IP Address Allocation for Mobile Users

Loopback addresses are IP addresses used by Prisma Access for requests made to an internal
source and are assigned from the infrastructure subnet. Loopback IP addresses can change for
mobile users during an infrastructure or dataplane upgrade.

Prisma Access Administrator’s Guide (Panorama Managed) 52 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Loopback IP addresses do not change for service connections or remote network

connections during an infrastructure or dataplane upgrade; only mobile user loopback IP
addresses can change.

Prisma Access allocates the loopback IP addresses from the infrastructure subnet that you specify
when you enable the Prisma Access infrastructure. You can add the entire infrastructure subnet
to an allow list and avoid planning for mobile user loopback IP changes during an infrastructure or
dataplane upgrade. To find the infrastructure subnet, select Panorama > Cloud Services > Status
> Network Details > Service Infrastructure and view the Infrastructure Subnet.
Retrieve these addresses using the API used to retrieve public IP and loopback IP addresses.
The following example shows a Prisma Access deployment that has an infrastructure subnet of
172.16.0.0/16. Prisma Access has assigned loopback IP addresses 172.16.0.1 and 172.16.0.3 for
mobile users from the infrastructure subnet.

After in infrastructure or dataplane upgrade (for example, to prepare for a new release of the
Cloud Services plugin), Prisma Access assigns two different IP addresses for mobile users from
the infrastructure subnet (172.16.0.1 is changed to 172.16.0.2 and 172.16.0.3 is changed to
172.16.0.4).

Prisma Access Administrator’s Guide (Panorama Managed) 53 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Remote Network IPSec Termination Nodes and Service IP

Addresses on Prisma Access
All new Prisma Access deployments allocate remote network bandwidth by compute location
instead of by Prisma Access location. You can also upgrade your current deployment to allocate
bandwidth by compute location.
When you onboard a remote network, you associate it with an IPSec Termination Node, and
each IPSec termination node has a Service IP Address associated with it. You use the Service
IP Address as the peer IP address when you set up the IPSec tunnel for the remote network
connection. Each termination node can provide you up to 1,000 Mbps of bandwidth. Associating
more than 1,000 Mbps of bandwidth to a compute location provides you with more than one
Service IP Address.

Prisma Access Administrator’s Guide (Panorama Managed) 54 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

When you onboard a remote network in an Ireland compute location, you are given a choice of
two IPSec termination nodes, because the total bandwidth is more than 1,000 Mbps.

Each IPSec termination node has its own Service IP address, as can be seen in Panorama > Cloud
Services > Status > Network Details > Remote Networks.

IP Address Changes For Remote Network Connections That

Allocate Bandwidth by Location
This section applies if you have a legacy Prisma Access deployment that allocates bandwidth
by location. Any new deployments allocate bandwidth by compute location; to learn about how
Prisma Access allocates those IP addresses, see Remote Network IPSec Termination Nodes and
Service IP Addresses on Prisma Access.
IP addresses for remote network connections are unique, not shared, and dedicated to your
Prisma Access deployment. These IP addresses do not change after Prisma Access creates them
as part of remote network onboarding, and the IP addresses persist after an upgrade. However,
take care when increasing the bandwidth of an existing connection, because the IP address of
a remote network can change if that increase causes the bandwidth in a location to exceed 500
Mbps.

In addition, egress IP addresses can change if Prisma Access creates a new Prisma Access
Locations by Compute Location and you decide to use this new compute location
with locations you have already onboarded. See Add a New Compute Location for a
Deployed Prisma Access Location for details.

Prisma Access Administrator’s Guide (Panorama Managed) 55 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

These bandwidth guidelines apply only when you upgrade an existing connection. A single remote
network connection, even a 1000 Mbps (Preview) connection, always receives a single Service IP
Address, regardless of its size.

The 1000 Mbps bandwidth option is in preview mode. The throughput during preview is
delivered on a best-effort basis and the actual performance will vary depending upon the
traffic mix.

The following example shows three remote network connections in the same location, each with a
bandwidth of 150 Mbps. Since the total bandwidth is 500 Mbps, Prisma Access assigns a single IP
address for all connections in the location.

The following example shows the bandwidth of remote network connection A being increased
from 150 Mbps to 300 Mbps. Since the total bandwidth of all connections is now more than 500
Mbps, Prisma Access assigns a new service IP address for the connection with the additional
bandwidth. The other service IP addresses remain unchanged.

Conversely, given four remote networks with a bandwidth of 100 Mbps, if you increase the
bandwidth of one of the remote networks to 100 Mbps, the Service IP address of that remote
network does not change because the total bandwidth is now 500 Mbps.

Prisma Access Administrator’s Guide (Panorama Managed) 56 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

If you reduce the bandwidth of a remote network connection, the Service IP address does
not change.

To find the service IP addresses in Panorama, select Panorama > Cloud Services > Status >
Network Details tab and click the Remote Networks radio button to display the Service IP
Address for the remote networks, or use the API script.

Service IP and Egress IP Address Allocation for Remote Networks

Prisma Access has more than 100 locations available to accommodate worldwide deployments
and provide a localized experience. Two locations might map to the same Service IP address,
which you use as the peer IP address when you set up the IPSec tunnel for the remote network
connection. However, the locations might use different egress IP addresses to make sure that the
user gets the correct default language for the region.

Service connections do not support language localization because egress to the internet
is not supported over service connections. Prisma Access allocates only one service IP
address per service connection, and that IP address is geographically registered to the
compute location that corresponds to the location you specify during onboarding.

The following example shows a customer deployment with two remote network locations
deployed in Canada: Central Canada and Canada East. Prisma Access assigned the same Service
IP Address to both locations. When you configure the remote network tunnel, use this IP address
as the peer IP address when you create the IPSec tunnel for the remote network connection.

However, Canada East uses a different default language (French) than Central Canada (English).
For this reason, Prisma Access assigns them different egress IP addresses. If you run the API script
for egress IP addresses, you will receive two different IP addresses for these two locations.

Prisma Access Administrator’s Guide (Panorama Managed) 57 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Retrieve the IP Addresses for Prisma Access

If you are manually adding IP addresses of your Prisma Access infrastructure to an allow list in
your network, or if you are using an automation script to enforce IP-based restrictions to limit
inbound access to enterprise applications, you should understand what these addresses do and
why you need to allow them, as well as the tasks you perform to retrieve them.
Prisma Access does not provision these IP addresses until after you complete your Prisma Access
configuration. After your deployment is complete, you retrieve these IP addresses using an API
script. The API script uses an API key that you obtain from the Prisma Access UI and a .txt file you
create which specifies the addresses you want to retrieve.

If you have a Mobile Users—GlobalProtect deployment, you can use the Prisma Access
UI instead of this API to manage public IP address allocation and confirm that the IP
addresses have been added to your allow lists before Prisma Access releases the IP
addresses. In this way, Prisma Access only provisions the IP addresses that you have allow
listed.

The following table provides you with a list of the IP address that Prisma Access uses for each
deployment type, along with the keyword you use when you run the API script to retrieve the IP
addresses, and describes whether or not you should add them to your organization’s allow lists.

Deployment Type IP Address Type Description

Mobile Users—GlobalProtect Prisma Access gateway Gateway IP addresses. You

(gp_gateway) must add both gateway and
portal IP addresses to allow
lists for your mobile user
deployments.
Mobile users connect to a
Prisma Access gateway to
access internal or internet
resources, such as SaaS or
public applications, for which
you have provided access.
For mobile users, during initial
deployment, Prisma Access
assigns two IP addresses for
each location you deploy.

Prisma Access portal Portal IP addresses. You

(gp_portal) must add both gateway and
portal IP addresses to allow
lists for your mobile user
deployments.
Mobile users log in to
the Prisma Access portal

Prisma Access Administrator’s Guide (Panorama Managed) 58 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Deployment Type IP Address Type Description

to receive their initial
configuration and gateway
location.

Loopback IP addresses The source IP address used

by Prisma Access for requests
made to an internal source,
and is assigned from the
infrastructure subnet. Add
the loopback IP address to
an allow list in your network
to give Prisma Access access
to internal resources such as
RADIUS or Active Directory
authentication servers.
Palo Alto Networks
recommends that you allow all
the IP addresses of the entire
infrastructure subnet in your
network, because loopback
IP addresses can change.
To find the infrastructure
subnet, select Panorama >
Cloud Services > Status >
Network Details > Service
Infrastructure. The subnet
displays in the Infrastructure
Subnet area.
To retrieve loopback IP
addresses, use the legacy API
script.

Mobile Users—Explicit Proxy Authentication Cache Service The address for the Prisma
(ACS) Access service that stores the
authentication state of the
explicit proxy users.
This address is only used for
explicit proxy for mobile users.

Network Load Balancer The address that Prisma

Access uses for the explicit
proxy network load balancer.
This address is only used for
explicit proxy for mobile users.

Prisma Access Administrator’s Guide (Panorama Managed) 59 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Deployment Type IP Address Type Description

Remote Network Remote Network IP The Service IP Addresses

addresses (remote_network) that Prisma Access assigns
for the Prisma Access remote
network connection, and
egress IP addresses that
Prisma Access uses to make
sure that remote network
users get the correct default
language for their region. Add
these addresses to allow lists
in your network to give Prisma
Access access to internet
resources.

Loopback IP addresses The source IP address used

by Prisma Access for requests
made to an internal source,
and is assigned from the
infrastructure subnet. Add
the loopback IP address
to an allow list to give
Prisma Access access to
internal resources such as
RADIUS or Active Directory
authentication servers.
To retrieve loopback IP
addresses, use the legacy API
script.

Clean Pipe Clean Pipe IP Addresses Add these IP addresses to an

(clean_pipe) allow list to give the Clean
Pipe service access to internet
resources.

Loopback IP addresses The source IP address used

by Prisma Access for requests
made to an internal source,
and is assigned from the
infrastructure subnet. Add
the loopback IP address
to an allow list to give
Prisma Access access to
internal resources such as
RADIUS or Active Directory
authentication servers.
To retrieve loopback IP

Prisma Access Administrator’s Guide (Panorama Managed) 60 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Deployment Type IP Address Type Description

addresses, use the legacy API
script.

Run the API Script Used to Retrieve Prisma Access IP Addresses

Prisma Access provides an API script that you can use to retrieve the public and private IP
addresses it uses in its infrastructure. If you need to add public IP addresses to allow lists in your
organization’s network, use the following steps to retrieve these IP addresses with the API script.

This command does not retrieve loopback addresses; to retrieve loopback IP addresses,
use the legacy API.

STEP 1 | Get the API key.

You need this key to authenticate to Prisma Access and retrieve the list of IP addresses using
the API command. Only a Panorama administrator or Superuser can generate or access this
API key.
1. Select Panorama > Cloud Services > Configuration > Service Setup.
2. Select Generate API Key.

If you have already generated an API key, the Current Key displays. If you haven’t yet
generated a key or want to replace the existing key to meet audit or compliance check
for key rotation, click Generate New API Key for a new key.

STEP 2 | Create a .txt file and put the API command options in the file.
Using the API the command to use is a two-step process. First, you create a .txt file, specifying
the parameters for the IP addresses to retrieve, and save the file in a folder that is reachable

Prisma Access Administrator’s Guide (Panorama Managed) 61 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

from the location where you run the command. Then, you run the API and specify the name
and location of the .txt file you created in the command.
Specify the following keywords and arguments in the .txt file. See Prisma Access IP Address
Retrieval Using the API Examples for examples. The examples in this document use a file name
of options.txt but you can specify any file name, as long as you reference it in the command.

Argument Possible choices (keywords) Comments

serviceType all all—Retrieves IP addresses

you need to add to an
remote_network
allow list for all service
gp_gateway types (Remote Networks,
Mobile Users (both gateways
gp_portal
and portals), and Clean
clean_pipe Pipe, as applicable to your
deployment).
swg_proxy
remote_network—Retrieves
IP addresses you need to add
to an allow list for remote
network deployments.
gp_gateway—Retrieves the
Mobile Users—GlobalProtect
gateway IP addresses you
need to add to an allow list for
mobile user deployments.
gp_portal —Retrieves the
Mobile Users—GlobalProtect
portal IP addresses you need
to add to an allow list for
mobile user deployments.
clean_pipe—Retrieves the IP
addresses you need to add
to an allow list for clean pipe
deployments.
swg_proxy—Retrieves the
egress IP addresses for each
deployed Explicit Proxy
location, the authentication
cache service (ACS), and the
network load balancers.

addrType all all or active—Retrieves all the

IP addresses you need to add
active
to an allow list.
service_ip
This API does not retrieve
auth_cache_service loopback IP addresses.

Prisma Access Administrator’s Guide (Panorama Managed) 62 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Argument Possible choices (keywords) Comments

network_load_balancer To retrieve loopback IP
addresses, use the legacy API.
service_ip—Retrieves the
Service IP Address, which you
use as the peer IP address
when you set up the IPSec
tunnel for the remote network
connection.
auth_cache_service—
Retrieves the IP address
for the explicit proxy ACS
(applicable to Explicit Proxy
deployments only).
network_load_balancer—
Retrieves the IP address for
the explicit proxy network
load balancer (applicable to
Explicit Proxy deployments
only).

actionType pre_allocate Mobile User deployments

only—An actionType of
pre_allocate allows you to
retrieve IP addresses or
subnets for Prisma Access
gateways and portals for
mobile user deployments.
Use this with a serviceType
of gp_gateway to retrieve
pre-allocated gateway IP
addresses and a serviceType
of gp_portal to retrieve pre-
allocated portal IP addresses.
Retrieving the pre-allocated
IP addresses lets you
add the gateway and
portal IP addresses to your
organization’s allow lists
before you onboard mobile
user locations, which in
turn gives mobile users
access to external SaaS
apps immediately after you
onboard the locations. See
Pre-Allocate IP Addresses for

Prisma Access Administrator’s Guide (Panorama Managed) 63 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Argument Possible choices (keywords) Comments

Prisma Access Mobile User
Locations for details.

location all all—Retrieves the IP addresses

from all locations. For mobile
deployed
user deployments, this
keyword retrieves the IP
addresses for both locations
you added during onboarding,
and locations you did not add.
deployed—Retrieves IP
addresses in all locations that
you added during mobile user
onboarding.
This keyword is applicable
to mobile user deployments
only. Prisma Access associates
IP addresses for every
mobile user location during
provisioning, even if you didn’t
select that location during
mobile user onboarding. If you
specify all, the API command
retrieves the IP addresses
for all mobile user locations,
including ones you didn’t
select for the deployment.
If you specify deployed,
the API command retrieves
only the IP addresses for the
locations you selected during
onboarding.

Specify the options in the .txt file in the following format:

{
"serviceType": "service-type",
"addrType": "address-type",
"location": "location"
}

Prisma Access Administrator’s Guide (Panorama Managed) 64 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

STEP 3 | Enter one of the following commands to retrieve the IP addresses.

• To use the API that was introduced in Prisma Access 2.1, enter the following command:

curl -X POST --data @option.txt -H header-api-key:Current-

API-Key "https://api.prod.datapath.prismaaccess.com/
getPrismaAccessIP/v2"

• To use the legacy API, enter the following command. This command uses a legacy API
endpoint that will be deprecated in May 2022:

curl -X POST --data @option.txt -k -H header-api-key:Current-

API-Key "https://api.gpcloudservice.com/getPrismaAccessIP/v2"

Where option.txt is the .txt file you created in Step 2 and Current-API-Key is the Prisma Access
API key.
For example, given a .txt file name of option.txt and an API key of 12345abcde, use the
following API command to retrieve the public IP address for all locations:

curl -X POST --data @option.txt -H header-api-key:12345abcde

"https://api.prod.datapath.prismaaccess.com/getPrismaAccessIP/v2"

The API command can return a large amount of information. To make the output more
readable, if you have Python installed, you can add | python -m json.tool at
the end of the CURL command.

The API command returns the addresses in the following format:

{
"result": [
{
"address_details": [
{
"address": "1.2.3.4"
"allow_listed": false
"addressType": "address-type"
"serviceType": "service-type"
}
],
"addresses": [
"1.2.3.4"
]
"zone": "zone-name",
"zone_subnet": [zone-subnet
]
},

Prisma Access Administrator’s Guide (Panorama Managed) 65 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

"status": "success"

Where:
• address_details shows the details of the address for each location.
• serviceType shows the type of IP address (either remote network (remote_network),
Prisma Access gateway (gp_gateway), Prisma Access portal (gp_portal), or Clean Pipe
(clean_pipe).
• addressType specifies the type of address specified with the addrType keyword (either
all, active, or pre-allocated if you Pre-Allocate IP Addresses for Prisma Access Mobile
User Locations).
• address shows the IP address you need to add to your allow lists.
If the API returns multiple IP addresses, Prisma Access summarizes the IP addresses in
the addresses field.
• addresses lists all the IP addresses for the location that you need to add to your allow lists.
• zone is the Prisma Access location associated with the IP addresses.
• zone_subnet is the subnet for mobile user gateways and portals. Prisma Access also
provides this subnet if you Pre-Allocate IP Addresses for Prisma Access Mobile User
Locations.
If there are any problems with the options in the .txt file, the API returns an error similar to the
following:

{"status": "error","result": "Invalid json format in the request.

trace_id: xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx "}

STEP 4 | Update the allow lists on your on-premises servers or SaaS application policy rules with the
IP addresses you retrieved.

Prisma Access IP Address Retrieval Using the API Examples

Use the following examples when entering keywords and arguments in the .txt file for the API
command to retrieve Prisma Access infrastructure IP addresses. To change the output of the
command, change the options in the .txt file; the command itself does not change.

Retrieve These IP Addresses Specify These Parameters in Comments

the .txt File

Mobile User IP Addresses

All mobile user IP Addresses An addrType of all means that

{ Prisma Access retrieves all IP
"serviceType": "gp_g addresses for the locations
ateway", you selected during mobile
"addrType": "all",
"location": "all" user onboarding.
} A location of all means that
Prisma Access retrieves IP

Prisma Access Administrator’s Guide (Panorama Managed) 66 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Retrieve These IP Addresses Specify These Parameters in Comments

the .txt File
addresses for all available
locations, including ones that
you have not onboarded.
Prisma Access reserves
non-onboarded location IP
addresses so that you can add
these IP addresses to your
allow lists before you onboard
them.

IP addresses for onboarded A location type of deployed

mobile user locations { means that Prisma Access
"serviceType": "gp_g retrieves only the IP
ateway", addresses for the locations
"addrType": "all",
"location": "deploye that you selected during
d" mobile user onboarding.
} Use either an addrType of all
or active to retrieve these
Or gateway IP addresses.

{
"serviceType": "gp_g
ateway",
"addrType": "active"
,
"location": "deploye
d"
}

Remote Network IP Addresses

Retrieve all remote network This command retrieves the

IP addresses { public and egress IP addresses
"serviceType": "remo of remote networks you have
te_network", onboarded. Do not use a
"addrType": "all",
"location": "all" location of deployed. You can
} use an addrType of active
but it retrieves the same
addresses as if you specified
an addrType of all.

Clean Pipe IP Addresses

Retrieve all clean pipe IP This command retrieves

addresses { the public and egress IP
"serviceType": "clea addresses of clean pipes you
n_pipe", have onboarded. Do not use

Prisma Access Administrator’s Guide (Panorama Managed) 67 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Retrieve These IP Addresses Specify These Parameters in Comments

the .txt File
"addrType": "all", a location of deployed. You
"location": "all" can use an addrType of active
} but it retrieves the same
addresses as if you specified
an addrType of all.

Explicit Proxy IP Addresses

Retrieve the ACS IP This command retrieves

addresses for deployed { the egress IP addresses for
locations "serviceType": "swg_ each deployed Explicit Proxy
proxy", location, the authentication
"location": "all",
"addrType": "all" cache service (ACS), and
} the network load balancers
(relevant for explicit proxy
deployments only).

Pre-Allocate IP Addresses for Prisma Access Mobile User

Locations
Prisma Access uses gateway and portal IP addresses for Mobile Users—GlobalProtect
deployments, and authentication cache service (ACS) and network load balancer IP addresses
for Mobile Users—Explicit Proxy deployments. Mobile Users—GlobalProtect IP addresses are
known as egress IP addresses. If you need to pre-allocate mobile user IP addresses before you
onboard the location (for example, if your organization needs to add the IP addresses for Mobile
Users—GlobalProtect deployments to allow lists to give mobile users access to external SaaS
applications), you can run an API script to have Prisma Access pre-allocate these IP addresses
for a location ahead of time, before you onboard it. You can then add the location’s egress IP
addresses to your organization’s allow lists before onboarding the location.
The API response also includes the public IP subnets for the egress IP addresses for the requested
location. The egress IP addresses of any locations you add are a part of this subnet. Adding
the subnets to your allow lists provides for future location additions without further allow list
modification.
Prisma Access does not pre-allocate your IP addresses and subnets unless you request them using
the API script. After you run the pre-allocation script, they have a validity period of 90 days. The
IP addresses that Palo Alto Networks provides you are unique, not shared, and dedicated to your
Prisma Access deployment during the validity period. You must onboard your locations before the
validity period ends or you lose the addresses; to find the validity period at any time, run the API
script.

Palo Alto Networks recommends that you only pre-allocate IP addresses for locations that
you want to onboard later.

To pre-allocate IP addresses, complete the following task.

Prisma Access Administrator’s Guide (Panorama Managed) 68 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

STEP 1 | Retrieve the Prisma Access API key.

STEP 2 | Pre-allocate the mobile user egress IP addresses by creating a .txt file and specifying the
following options in the .txt file you create.
Enter the following text in the .txt file:
• Mobile Users—GlobalProtect Deployments:

{
"actionType": "pre_allocate",
"serviceType": "gp_gateway",
"location": ["location"]
}

• Mobile Users—Explicit Proxy Deployments:

{
"actionType": "pre_allocate",
"serviceType": "swg_proxy",
"location": ["location"]}

Where location is the Prisma Access location or locations where you want to pre-allocate the
IP addresses. If you enter multiple locations, use brackets around the set of locations and
separate each location entry with quotes, a comma, and a space (for example, ["location1",
"location2", "location3"], and so on).
Enter a maximum of 12 locations. Entering more than 12 locations might cause timeout errors
when Prisma Access retrieves the pre-allocated IP addresses.

STEP 3 | Enter the CURL command as shown in Step 3 in Run the API Script Used to Retrieve Prisma
Access IP Addresses.

STEP 4 | Retrieve the IP addresses and subnets you requested, including their validity period, by re-
opening the .txt file, removing the existing information, and editing it.
• Mobile Users—GlobalProtect Deployments:
• To retrieve all pre-allocated IP addresses, enter the following text in the .txt file.

{
"serviceType": "all",
"addrType": "pre_allocated",
"location": "all"

Prisma Access Administrator’s Guide (Panorama Managed) 69 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

• To retrieve all pre-allocated IP addresses for Prisma Access portals for a given location,
enter the same information in the .txt file but substitute “all” with “gp_portal” in
the .txt file.
• Mobile Users—Explicit Proxy Deployments:
To pre-allocate all IP addresses you need to add to allow lists for an explicit proxy
deployment, enter the following text in the .txt file.

{
"actionType": "pre_allocate",
"serviceType": "swg_proxy",
"location": ["all"]
}

Palo Alto Networks recommends that you enter all so you can retrieve all required pre-
allocated egress IP addresses to add to your allow lists.

For Mobile Users—GlobalProtect deployments, while Prisma Access returns up to four

addresses for each location (two gateway IP addresses and, if required, two portal
IP addresses), the API command can return a large amount of information. To make
the output more readable, if you have Python installed, you can add | python -m
json.tool at the end of the CURL command.

STEP 5 | Re-enter the CURL command as shown in Step 3 in Run the API Script Used to Retrieve
Prisma Access IP Addresses to retrieve the pre-allocated addresses.
Prisma Access returns the information in the following format:

"result": [
{
"zone": "prisma-access-zone1",
"addresses": [
["ip-address1","ip-address2"]
"zone_subnet" :
[subnet-and-mask1","subnet-and-mask2"]
"address_details":[
{"address":"ip-address1",
"service_type":"service-type",

"addressType":"pre-allocated",
"expiring_in" : "validity-period" },
{"address":"ip-address2",
"service_type":"gp_gateway",
"addressType":"pre-allocated",
"validity_period_remaining" : "90
days" } ,

Prisma Access Administrator’s Guide (Panorama Managed) 70 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

},

Where the variables represent the following API command output:

Variable Explanation

prisma-access-zone1 The Prisma Access location for which pre-

allocated IP addresses were retrieved.

ip-address1 and ip-address2 The egress IP addresses that Prisma Access has
pre-allocated for the specified location.
Prisma Access retrieves two IP addresses for
each location; you must add both of these IP
addresses to your allow lists.

subnet-and-mask1 and subnet-and-mask2 The subnets that Prisma Access has pre-
allocated and reserved for the egress IP
addresses in your deployment.

service-type The type of the pre-allocated egress IP address

(either gp_portal for a Prisma Access portal
or gp_gateway for a Prisma Access gateway).

validity-period The remaining time, in days, for which the pre-

allocated IP address is valid.
You must onboard your mobile user location
before the IP addresses’ validity period ends. If
the pre-allocated IP addresses expire, you can
rerun the API script to retrieve another set of
pre-allocated IP addresses.

You could receive an error if you attempt to pre-allocate IP addresses for locations that meet
one of the following criteria:
• You have already onboarded the location.
• You onboarded, then deleted the location.
In this case, enter the following text in the .txt file to retrieve the Mobile Users—
GlobalProtect IP addresses for the location:

{
"serviceType": "gp_gateway",
"addrType": "all",
"location": "all"

Prisma Access Administrator’s Guide (Panorama Managed) 71 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

• You have reached the maximum number of mobile user locations allowed by your license
and cannot add any more locations.
• You entered the location name incorrectly.
• You entered a serviceType other than gp_gateway.
• you entered an actionType other than pre_allocate.

Set Up Prisma Access IP Address Change Notifications

To be notified of public IP address changes for remote networks and loopback IP address changes
for service connections, remote network connections, and mobile users, you can specify a URL
at which you can be alerted of a change. Prisma Access uses an HTTP POST request to send the
notification. This POST request includes the following notification data in JSON format:

{"addrType": "public_ip", "addrChangeType": "add", "utc_timestamp":

"2019-01-31 23:08:19.383894", "text": "Address List Change
Notification"}

{"addrType": "public_ip", "addrChangeType": "delete",

"utc_timestamp": "2019-01-31 23:13:35.882151", "text": "Address List
Change Notification"}

{"addrType": "loopback_ip", "addrChangeType": "update",

"utc_timestamp": "2019-01-31 23:29:27.100329", "text": "2018-05-11
23:29:27.100329"}

When you receive a notification, you must follow a two-step process. First, you must manually or
programatically retrieve the IP or loopback addresses. Then, you must update the IP addresses in
your organization’s appropriate allow list to ensure that users do not experience any disruption in
service.

Prisma Access sends this notification a few seconds before the new IP address becomes
active. We recommend that you use automation scripts to both retrieve and add the new
IP addresses to an allow list in your network.

To add an IP notification URL, complete the following task.

STEP 1 | Select Panorama > Cloud Services > Configuration > Service Setup.

Prisma Access Administrator’s Guide (Panorama Managed) 72 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

STEP 2 | Add an IP Change Event Notification URL where you can be notified of IP address changes
in your Prisma Access infrastructure.

You can specify an IP address or an FQDN to an HTTP or HTTPS web service that is listening
for change notifications. Prisma Access sends these notifications from the internet using a
public IP address.
You do not need to commit your changes for the notification URL to take effect.

Use Legacy Scripts to Retrieve Loopback Addresses

The commands described in this section are superseded by a newer API script as
of Prisma Access 1.5; however, they are still supported when you need to obtain the
loopback address, or for deployments that use them in scripts or other automated tools.

The following table shows the keywords and parameters that are available in the legacy API
scripts used with Prisma Access, and provides information and recommendations about which API
to use for the type of deployment you have.
These legacy commands also retrieve public IP and egress IP addresses; however, Palo Alto
Networks recommends that you use the newer API script to retrieve these commands and only
use the legacy API to retrieve the loopback IP addresses.
• A public IP address is the source IP address that Prisma Access uses for requests made to an
internet-based source. Add the public IP address to an allow list in your network to give Prisma
Access access to internet resources such as SaaS applications or publicly accessible partner
applications.
Mobile user, remote network, and clean pipe deployments use public IP addresses.
• An egress IP address is an IP address that Prisma Access uses for egress traffic to the internet,
and you must also add these addresses to an allow list to give Prisma Access access to internet
resources.
Among other purposes, Prisma Access uses egress IP addresses so that users receive web
pages in the language they expect from a Prisma Access location. All locations have public IP

Prisma Access Administrator’s Guide (Panorama Managed) 73 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

addresses; however, not all locations have egress IP addresses. The following locations do not
use egress IP addresses:
• Any locations that you added before the release of Prisma Access 1.4.
• Bahrain
• Belgium
• France North
• France South
• Hong Kong
• Ireland
• South Korea
• Taiwan
• United Kingdom
Mobile user, remote network, and clean pipe deployments use egress IP addresses.

Commands Used in Mobile User Deployments

Command Name Comments

get_egress_ip_all=yes command This command retrieves all the IP addresses

that you add to an allow list to give Prisma
curl -H header-api-
Access access to internet resources such as
key:Current-API-Key"https://
SaaS applications or publicly accessible partner
api.prod.datapath.prismaaccess.com/
applications. This command has the following
getAddrList/latest? constraints:
get_egress_ip_all=yes
• This command can retrieve a large number of
addresses (more than 200). If your enterprise
cannot add this number of IP addresses to
an allow list, you can use the gpcs_gp_gw
and gpcs_gp_portal keywords to retrieve
only the IP addresses you are currently
using; however you will have to rerun these
commands every time you add a location. In
addition, if a scaling event occurs, you will
need to the new IP addresses to an allow list.
• Prisma Access does not list the locations
that are associated with these IP addresses;
therefore, we recommend that you all the
IP addresses that are returned with this
command to an allow list.
• This command does not give you loopback
addresses.

gpcs_gp_gw and gpcs_gp_portal keywords Use this command if your deployment limits the
amount of IP addresses you can add to an allow

Prisma Access Administrator’s Guide (Panorama Managed) 74 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Commands Used in Mobile User Deployments

Command Name Comments
curl -H header-api- list. You must add all IP addresses returned with
key:Current-API-Key"https:// this command to an allow list in your network.
api.prod.datapath.prismaaccess.com/You can also retrieve the loopback IP addresses
getAddrList/latest? with this command.
fwType=gpcs_gp_gw |
gpcs_gp_portal&addrType=public_ip |
egress_ip_list | loopback_ip"

Commands Used In Remote Network Deployments

Command Name Comments

gpcs_remote_network keyword Use this command to find the IP addresses that

you need to add to an allow list for remote
curl -H header-api-
network deployments.
key:Current-API-Key"https://
api.prod.datapath.prismaaccess.com/You can also use this command to find the
getAddrList/latest? egress IP addresses for remote network
fwType=gpcs_remote_network deployments; the egress and IP addresses can
&addrType=public_ip | egress_ip_list | be different in some situations.
loopback_ip"

Commands Used in Clean Pipe Deployments

Command Name Comments

gpcs_clean_pipe keyword Use this command to find the IP addresses that

you need to add to an allow list for clean pipe
curl -H header-api-
deployments.
key:Current-API-Key"https://
api.prod.datapath.prismaaccess.com/
getAddrList/latest?
fwType=gpcs_clean_pipe&addrType=public_ip
| egress_ip_list | loopback_ip"

Use the Legacy Script to Retrieve Mobile User IP Addresses

This legacy script has been superseded by a by a newer API script as of Prisma Access
1.5. Palo Alto Networks recommends that you use the newer script to retrieve all IP
addresses with the exception of loopback addresses.

If you are adding public IP addresses to allow lists to give mobile users access to SaaS or public
applications, Prisma Access provides two IP addresses for each gateway and portal IP address
so that one IP address can be used during a scaling or other event. You can add this set of IP
addresses to an allow list before they are used, preventing any issues with mobile users being able
to access SaaS or public applications during a scaling event.

Prisma Access Administrator’s Guide (Panorama Managed) 75 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Retrieve these new addresses by completing the following task:

STEP 1 | Get the API key by selecting Panorama > Cloud Services > Configuration > Service Setup;
then, selecting Generate API Key.
You need this key to authenticate to Prisma Access and retrieve the list of IP addresses using
the curl command listed below. Only a Panorama administrator or Superuser can generate or
access this API key.

STEP 2 | Enter the following command to retrieve the mobile user public IP addresses:

curl -H header-api-key:Current-API-Key "https://

api.prod.datapath.prismaaccess.com/getAddrList/latest?
get_egress_ip_all=yes"

Where Current-API-Key is the Prisma Access API key.

For example, given an API key of 12345abcde, use the following API command to retrieve the
public IP address for all locations:

curl -H header-api-key:12345abcde "https://

api.prod.datapath.prismaaccess.com/getAddrList/latest?
get_egress_ip_all=yes"

Every time Prisma Access uses the one set of public IP addresses, it allocates another set of IP
addresses. If you think that Prisma Access has used the added set of public IP addresses (for
example, if a large number of mobile users have accessed a single location), you can run this
API command again to find the new set of public IP addresses. All IP addresses persist after an
upgrade.

Use the Legacy Script to Retrieve Public, Loopback, and Egress IP Addresses

This legacy script has been superseded by a by a newer API script as of Prisma Access
1.5. Palo Alto Networks recommends that you use the newer script to retrieve all IP
addresses with the exception of loopback addresses.

To retrieve public, loopback, and egress IP addresses, complete the following steps.
STEP 1 | Get the API key and add an IP Change Event Notification URL where you can be notified of
IP address changes in your Prisma Access infrastructure.
See Set Up Prisma Access IP Address Change Notifications for details.

STEP 2 | Retrieve the public IP addresses, loopback IP addresses, or both for Prisma Access.
Use the API key and the API endpoint URL either manually or in an automation script:

header-api-key:Current

Prisma Access Administrator’s Guide (Panorama Managed) 76 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

API Key "https://api.prod.datapath.prismaaccess.com/getAddrList/

latest?fwType=$fwType&addrType=$addrType"

where you need to replace Current API Key with your API key and use one or both of the
following keywords and arguments:

Keyword Description

fwType keyword

gpcs_gp_gw Retrieves Prisma Access gateway IP addresses

(for mobile user deployments).

gpcs_gp_portal Retrieves Prisma Access portal IP addresses (for

mobile user deployments).

gpcs_remote_network Retrieves Prisma Access remote network IP

addresses (for remote network deployments).

gpcs_clean_pipe Retrieves Prisma Access Clean Pipe IP addresses.

addrType keyword

public_ip Retrieves the source IP addresses that Prisma

Access uses for requests made to an internet-
based source.
For mobile user locations, Prisma Access lists the
IP addresses by location. For remote networks,
Prisma Access lists the IP addresses by remote
network name.

egress_ip_list Retrieves the IP addresses that Prisma Access

uses with public IP addresses for additional egress
traffic to the internet.
For mobile user locations, Prisma Access lists the
IP addresses by location. For remote networks,
Prisma Access lists the IP addresses by remote
network name.

loopback_ip Retrieves the source IP addresses used by Prisma

Access for requests made to an internal source
(for example, a RADIUS or Active Directory

Prisma Access Administrator’s Guide (Panorama Managed) 77 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Keyword Description
server), and is assigned from the infrastructure
subnet.

If you don’t specify a keyword, Prisma Access retrieves all IP addresses.

For example, you can try the following Curl command to manually retrieve the list of public IP
addresses for all remote networks:

curl -H header-api-
key:1234y9ydxb__0UmxetVTbC8XTyFMaoT4RBZBKBjfX419YVufeFG7
"https://api.prod.datapath.prismaaccess.com/getAddrList/latest?
fwType=gpcs_remote_network&addrType=public_ip"

or use a simple python script to retrieve the list of all IP addresses, for example:

#!/usr/bin/python
import subprocess
import json
api_key = '1234y9ydxb__0UmxetVTbC8XTyFMaoT4RBZBKBjfX419YVufeFG7' #
Replace with your key
api_end_point = 'https://api.prod.datapath.prismaaccess.com/
getAddrList/latest' # This call retrieves IP addresses for all your
Prisma Access firewalls
args = ['curl', '-k', '-H', 'header-api-key:' + api_key,
api_end_point]
p = subprocess.Popen(args, stdout=subprocess.PIPE)
output = p.communicate()
dout = json.loads(output[0])
addrStrList = dout['result']['addrList']
addrList = []
for addr_str in addrStrList:
addrList.append(addr_str.split(":")[1])
print(addrList)

STEP 3 | Update the allow lists on your on-premises servers or SaaS application policy rules with the
IP addresses you retrieved.

Prisma Access Administrator’s Guide (Panorama Managed) 78 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Zone Mapping
On a firewall, zones are associated with interfaces. But within Prisma Access, the networking
infrastructure is automatically set up for you. This means that you no longer need to worry
about configuring interfaces and associating them with the zones your create (and, in Panorama
Managed Prisma Access, the UI to configure interfaces is removed from Panorama—any
unnecessary Panorama UI elements are removed in Panorama Managed Prisma Access). However,
to enable consistent security policy enforcement, you must create zone mappings so that Prisma
Access will know whether to associate a zone with an internal (trust) interface or an external
(untrust) interface. This will ensure that your security policy rules are enforced properly. By
default, all of the zones you push to Prisma Access are set to untrust. You should leave any zones
associated with internet-bound traffic, including your sanctioned SaaS applications, set to untrust.
However, for all zones that enable access to applications on your internal network or in your data
center, you must map them to trust. Notice in the example below, all sanctioned SaaS applications
—Office 365 and Salesforce in this case—are segmented into the sanctioned-saas zone to enable
visibility and policy enforcement over the use of these applications. To enable Prisma Access to
associate the sanctioned-saas zone with an external-facing interface, you must map this zone to
untrust. Similarly, the eng-tools and dc-apps zones provide access to applications in the corporate
office and you must therefore designate them as trusted zones.

When creating zones, do not use any of the following names for the zones, because these are
names used for internal zones:
• trust
• untrust
• inter-fw
• Any name you use for the remote networks (remote network names are used as the source
zone in Cortex Data Lake logs)

Prisma Access logs that display a zone of inter-fw are logs used for communication within
the Prisma Access infrastructure.

Prisma Access Administrator’s Guide (Panorama Managed) 79 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Prisma Access APIs

In addition to the XML APIs that are available for configuration and management in Panorama,
there are XML APIs for the Cloud Services plugin that you can use to perform tasks specific to
Prisma Access. Use these APIs through a third-party service, application, or script to automate
configuration and reporting tasks for Prisma Access.

Access the API Using the Browser and Web Interface

To access the API using the browser, log in to the Panorama that manages Prisma Access with
administrator privileges, then enter /api at the end of the URL. The URL changes to the XML API
browser interface.

The Prisma Access APIs are located in the following XML Path Language (XPath) nodes in the
XML tree:
• Configuration Commands: XML API > Configuration Commands > devices >
entry[@name='localhost.localdomain'] > plugins > cloud_services
• Operational Commands: XML API > Operational Commands > request > plugins >
cloud_services > prisma-access
As you navigate in the XML tree, Prisma Access populates the tree in the XML area. You can enter
required values in the XML area and click Submit to process an XML request. For example, to
request the onboarding status of a job, navigate to XML API > Operational Commands > request
> plugins > cloud_services > prisma-access > job-status > jobid, enter the Job id in the jobid field,
enter the Service Type servicetype area, and click Submit to submit your request.

This XML only retrieves the onboarding status of a job. To retrieve the status of all commit
operations, use the Prisma Access UI.

Prisma Access Administrator’s Guide (Panorama Managed) 80 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Prisma Access returns the output in XML format.

Prisma Access Administrator’s Guide (Panorama Managed) 81 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

You can also use the web interface to find APIs in Panorama.

Use curl Commands to Retrieve API Commands

If you prefer to use CLI to retrieve API command results, you can use APIs in conjunction with the
the API you use to retrieve public and infrastructure IP addresses for Prisma Access. To do so, use
the following command:

Prisma Access Administrator’s Guide (Panorama Managed) 82 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Configuration Commands:
curl -k -X GET "https://<panorama-ip-address>/api/?key=<api-
key>&type=config&cmd=<api-parameters></api-parameters>
Operational Commands:
curl -k -X GET "https://<panorama-ip-address>/api/?key=<api-
key>&type=op&cmd=<api-parameters></api-parameters>
Where:
• <panorama-ip-address> is the IP address of the Panorama that manages Prisma Access.
• <api-key> is the API key for Prisma Access (Panorama > Cloud Services > Configuration >
Service Setup > Generate API Key).
• <api-parameters> and </api-parameters> are the API parameters you use to retrieve the
requested information from the API.
If you have a multi-tenant deployment, you add the name of the tenant for which you want to
retrieve API information into the API.
For example, given a Prisma Access deployment that has the following parameters:
• Panorama IP Address: 1.2.3.4
• API key: 12345abcde
• Tenant name: tenant-1
If you wanted to retrieve the number of active mobile users for that tenant, you would enter the
following curl command:
curl -k -X GET "https://1.2.3.4/api/?
key=12345abcde&type=op&cmd=<request><plugins><cloud_services><prisma-
access><multi-tenant><tenant-name><entry%20name='tenant-1'></entry></
tenant-name><remote-active-users-count/></multi-tenant></prisma-
access></cloud_services></plugins></request>"

Use CLI Commands with Panorama Managed Prisma Access

Prisma Access allows you to use CLI commands to retrieve Prisma Access data. To access the CLI,
establish a SSH connection using the IP address of the Panorama that manages Prisma Access.
The CLI uses the same modes and has the same behavior as PAN-OS commands, with the
exception of entering the tenant name for multi-tenant deployments; you enter the tenant name
using the tenant-name tenant-name command. For example, given a tenant name of tenant-1,
enter the following command to retrieve to retrieve the active user count in a multi-tenant
deployment:

admin-Panorama> request plugins cloud_services prisma-access multi-

tenant remote-active-users-count tenant-name tenant-1

pass
Current User Count: 253

Prisma Access Administrator’s Guide (Panorama Managed) 83 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Prisma Access Deployment Progress and Status

When you configure and commit and push your changes for a service connection, remote
network connection, mobile user deployment, or clean pipe instance, Prisma Access begins a
series of events to complete the deployment process. To allow you to view the progress of
onboarding and deployment jobs before they complete, and to view the status of completed jobs,
Prisma Access provides you with deployment status information that is available on the Prisma
Access status page.
Checking the progress of a job is useful if, for example, you need the Service IP Address of a
service connection or remote network connection to complete the IPSec tunnel connection to
your customer premises equipment (CPE). Since Prisma Access does not create the Service IP
Address until onboarding is complete, you can view the status of the onboarding job from the
deployment status page, instead of refreshing the Network Details page and waiting for the
Service IP Address to display.
To view the status of deployment jobs, select Panorama > Cloud Services > Status > Status.

The Deployment Status area displays a graphic element (a bubble) showing the status of the
deployment, along with the following text:

Deployment Status Text Description

Started The deployment job has started.

In-Progress The deployment job is in progress.

Success The deployment job succeeded.

Failed The deployment job failed.

Timeout The deployment job timed out.

Warning The deployment job was partially successful; some

commit operations succeeded and some commit
operations failed.

Prisma Access Administrator’s Guide (Panorama Managed) 84 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Click details to view the Job ID of the job, its status, and the percentage of its completion. The
Job ID field is the Job ID that is associated with the commit operation in Panorama.

To view more details of a specific deployment job, click the left arrow next to Job ID. The
following screenshot shows the deployment status of a commit that has the Panorama Job ID of
1555. The overall status is Warning because two of the nodes failed during the commit stage.

The first line of the job status shows the following information:
• The type of deployment job (either Service Connections, Remote Networks, Clean Pipe), or
the type of mobile user onboarding operation (GlobalProtect Gateways, GlobalProtect Portals,
or both gateways and portals).
• The Number of Nodes that are in the job.
Nodes represent the number of cloud firewalls, gateways, or portals that Prisma Access is
configuring for a specific job. The number of nodes do not always correspond to the number
of Service Connections, Remote Networks, mobile user locations, or Clean Pipe instances that
you deployed; for example, onboarding a location might cause configuration changes to both
Prisma Access firewalls and portals.
• The number of nodes that are still being provisioned (Provisioning in Progress).
• The number of nodes that failed (Provisioning Failed).
• The number of nodes that completed provisioning (Provisioning Complete).
The next line in the table provides more granular information about the deployment job. The
following screenshot shows three mobile user locations (Australia Southeast, South Africa West,
and Brazil East) being successfully onboarded.

Prisma Access Administrator’s Guide (Panorama Managed) 85 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Field Description

Name (Service Connection, The name of the service connection, remote network
Remote Network, and Clean Pipe connection, or clean pipe instance.
deployments only)

Location The location where the service connection, remote

network connection, mobile user, or clean pipe node was
onboarded.

Node Status The status of the deployment operation.

• Validation Checks In Progress—The deployment job
has started, and preliminary checks are in progress.
• Validation Checks Succeeded—The deployment job
has started, and preliminary checks have succeeded.
• Validation Checks Failed—The job failed during
validation. More information about the failure is
available in he Error Details area.
• Commit In Progress—Validation checks have
completed, and the commit job is complete.
• Commit Succeeded—Validation checks have
completed, and the commit job succeeded.
• Commit Failed—The job failed during the commit
stage. More information about the failure is available
in he Error Details area.
• Deployment In Progress—Preliminary checks and
commit operations have completed for the job, and
deployment is in progress.
• Deployment Succeeded—The job completed all stages
and was successful.
• Deployment Failed—Preliminary checks and commit
operations completed, but the job failed during the

Prisma Access Administrator’s Guide (Panorama Managed) 86 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Field Description
deployment stage. More information about the failure
is available in he Error Details area.

Action Needed If a job failed, provides additional information about the

steps you can perform to fix the issue (either Commit
and push your changes from Panorama again or Open a
support case).

Prisma Access does not retain the details of jobs that you onboard and later delete. For example,
job 42233 added the Australia Southeast, South Africa West, and Brazil East mobile user
locations. If you delete those locations later, clicking the left arrow next to Job ID for job 42233
does not provide any additional details about the job.

Prisma Access Administrator’s Guide (Panorama Managed) 87 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Troubleshoot the Prisma Access Deployment

The Troubleshooting Commands area in Panorama (Panorama > Cloud Services > Configuration
> Service Setup > Service Operations > Troubleshooting Commands) enables you to easily
retrieve the logging status of Prisma Access infrastructure components, as well as retrieve
the latest information about External Data Lists (EDLs) that are used with Prisma Access.
This information can be useful to monitor and troubleshoot issues with your Prisma Access
deployment.
• If you are having issues with receiving logs from one or more locations, you can check the
Logging Status for a mobile user or remote network security processing node (SPN) to check
the connectivity status of Cortex Data Lake with that SPN.
• If you are experiencing routing issues with service connections, also known as Corporate Access
Nodes (CANs), or Remote Network SPNs, you can view the Prisma Access routing tables.
• If you are having issues with EDLs not being updated in a timely fashion, you can query Prisma
Access to see what information (IP addresses or URLs) are included in the EDLs. You can also
refresh the EDL information.
To export the results of the troubleshooting commands to a .csv file, select Export to CSV after
running the command.

Prisma Access Administrator’s Guide (Panorama Managed) 88 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

The Troubleshooting Commands window displays the following information:

Tab Description

Logging Status Provides you with the connection status between

Cortex Data Lake and the Prisma Access mobile user
security processing nodes (MU-SPNs) or remote
network security processing nodes (RN-SPNs).
To view Mobile Users MU-SPN logging information,
select the Prisma Access Location from the drop-
down, or select All to view the logging status for
all locations. To view Remote Networks RN-SPN
information, select the Site Name from the drop-
down, or select All to view all remote networks.
The Retrieved Data table shows the following
information:
• Connection Name—The mobile user location (for
mobile users) or the name of the remote network
connection.
The name of the connection between the MU-
SPN or RN-SPN and Prisma Access displays as
Connection-xxxxx, where xxxxxx is a six-digit
number that identifies the MU-SPN or RN-SPN in
the Prisma Access infrastructure.
You cannot map this six-digit number to a location,
but you can see the location of the MU-SPN or
RN-SPN in the Connection Timestamp area.
• Status—Provides you with details of the
connection between Prisma Access and Cortex
Data Lake status (Up or Down).
• Connection Timestamp—The time that Panorama
checked the connection status. The timestamp
uses the local time of the MU-SPN or RN-SPN.

Routing Information Provides you with routing information for service

connection corporate access nodes (SC-CANs) and
for RN-SPNs. To view SC-CAN information, select
the Service Connection name from the drop-down;
to view RN-SPN information, select the Site Name
from the drop-down. Click Show Route Table to show
the routing table for the service connection or remote
network connection. The Retrieved Data table shows
the following information:
• Destination—The IP address and subnet of
networks that the virtual router can reach.

Prisma Access Administrator’s Guide (Panorama Managed) 89 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Tab Description
• Nexthop—The IP address of the device at the next
hop toward the Destination network. A next hop
of 0.0.0.0 indicates the default route.
• Metric—The Metric for the route. When a routing
protocol has more than one route to the same
destination network, it prefers the route with the
lowest metric value. Each routing protocol uses a
different type of metric; for example, BGP uses the
Multi Exit Discriminator (MED) Attribute. Prisma
Access considers the metric when making routing
decisions; for example, given the same route,
Prisma Access prefers a static route with a lower
metric over a BGP route with a higher metric.
• Flags—The set of flags that are displayed for the
route.
• A?B—Active and learned from BGP
• A C—Active and a result of an internal interface
(connected) - Destination = network
• A H—Active and a result of an internal interface
(connected) - Destination = Host only
• A R—Active and learned from RIP
• A S—Active and static
• O1—OSPF external type-1
• O2—OSPF external type-2
• Oi—OSPF intra-area
• Oo—OSPF inter-area
• S—Inactive (because this route has a higher
metric) and static

EDL Info Displays information about External Dynamic Lists

(EDLs) for Mobile Users MU-SPNs and Remote
Networks RN-SPNs.
For MU-SPNs, select the EDL Type and the EDL
Name for the type you specified from the drop-down
choices; then, enter the IP address of the mobile user
location (gateway) (Mobile Users GW IP address).

Prisma Access Administrator’s Guide (Panorama Managed) 90 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Tab Description
To find the IP address of a mobile user
gateway from the GlobalProtect app,
open the Settings and find the Gateway
IP address in the Connection tab. To find
the IP address of a mobile user gateway
from Prisma Access, use the API to
retrieve Prisma Access infrastructure IP
addresses using the "serviceType":
"gp_gateway" keywords in the .txt file.

For RN-SPNs, select the EDL Type, the EDL Name

for the type you specified, and the Remote Networks
Site Name.
After you Show EDL Info, the Retrieved Data table
shows the following information:
• Total Valid Entries—The total number of valid
entries in the specified EDL.
• Total Ignored Entries—The total number of entries,
if any, that Prisma Access ignored in the specified
EDL.
• Total Invalid Entries—The total number of invalid
entries, if any, in the specified EDL.
• Valid Entries—Shows the valid entries in the EDL.
These entries reflect the EDL type; for example,
an EDL Type of ip displays the IP addresses in the
EDL and an EDL Type of URL displays valid URLs
in the EDL.
The Valid Entries column shows detailed EDL
information for a maximum number of 100 EDL
entries.

EDL Status Displays the status of the EDLs used by Prisma

Access for Mobile Users and Remote Networks MU-
SPNs and RN-SPNs.
For MU-SPNs, select the EDL Type and the EDL
Name for the type you specified from the drop-down
choices; then, enter the IP address of the mobile user
location (gateway) (Mobile Users GW IP address).

Prisma Access Administrator’s Guide (Panorama Managed) 91 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Tab Description
To find the IP address of a mobile user
gateway from the GlobalProtect app,
open the Settings and find the Gateway
IP address in the Connection tab. To find
the IP address of a mobile user gateway
from Prisma Access, use the API to
retrieve Prisma Access infrastructure IP
addresses using the "serviceType":
"gp_gateway" keywords in the .txt file.

For RN-SPNs, select the EDL Type, the EDL Name

for the type you specified, and the Remote Networks
Site Name. Predefined URLs are not supported.
The Retrieved Data table shows the following
information:
• Next Update At—The time when the EDL of the
specified type will be refreshed.
• Source—More details about what is included in this
EDL.
• Referenced—Whether the EDL is referenced in a
security policy rule.
• Valid—Whether or not the EDL is valid.
• Auth-Valid—If the EDL uses authentication,
whether or not the authentication is valid.

EDL Refresh Refreshes the EDLs for Mobile Users and Remote
Networks MU-SPNs and RN-SPNs. You cannot
refresh predefined EDLs.

Refreshing an EDL is resource-intensive.

Palo Alto Networks recommends that
you refresh the EDLs a maximum of
once every two minutes. If you do not
manually refresh the EDLs, Prisma Access
automatically refreshes External Dynamic
Lists (EDLs) using the Check for Updates
value you defined in each EDL.

For MU-SPNs, select the EDL Type and the EDL

Name for the type you specified from the drop-down
choices; then, enter the IP address of the mobile user
location (gateway) (Mobile Users GW IP address).

Prisma Access Administrator’s Guide (Panorama Managed) 92 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Tab Description
To find the IP address of a mobile user
gateway from the GlobalProtect app,
open the Settings and find the Gateway
IP address in the Connection tab. To find
the IP address of a mobile user gateway
from Prisma Access, use the API to
retrieve Prisma Access infrastructure IP
addresses using the "serviceType":
"gp_gateway" keywords in the .txt file.

For RN-SPNs, select the EDL Type, the EDL Name

for the type you specified, and the Remote Networks
Site Name.
The Retrieved Data table shows the Message related
to the EDL refresh operation (either that the EDL
refresh operation is queued or that it is complete)
and the Timestamp when the refresh operation was
performed. The timestamp uses the local time of the
MU-SPN or RN-SPN.
To view the last time that the status was refreshed,
select the EDL Status tab. To see the EDL information
after it was refreshed, select the EDL Info tab.

Search EDL Enter search terms to find data inside the EDLs
you use with mobile users and remote networks in
Prisma Access. This functionality does not work with
Predefined URL lists or URL lists that you create;
EDLs that use IP addresses are supported.
You can enter search terms for either Mobile Users or
Remote Networks. To search for Mobile Users, enter
the IP address of the mobile user location (gateway)
for which you want to search (Mobile Users GW
IP address) with the Search String; to search in the
Remote Networks area, enter the Site Name with
the Search String. Click Search EDL to perform the
search.
If the string is matched in an EDL, the Retrieved Data
table shows the EDL Name where the search string
was matched, along with the Timestamp when the
match was made. The timestamp uses the date and
time of the Panorama that manages Prisma Access.

Prisma Access Administrator’s Guide (Panorama Managed) 93 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Overview

Prisma Access Administrator’s Guide (Panorama Managed) 94 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma
Access Components
After you determine what licenses you need and the bandwidth and mobile user quantity that is
required for your deployment, you activate and install the components as shown in the following
sections.
• Activate and Install Panorama Managed Prisma Access
• Transfer or Update Panorama Managed Prisma Access Licenses
• Configure Panorama Appliances in High Availability for Panorama Managed Prisma Access

95
Activate and Install the Prisma Access Components

Activate and Install Panorama Managed Prisma Access

If you have a new Panorama Managed Prisma Access deployment as of August 2022, use
Panorama Managed Prisma Access License Activation and Subscription Management to activate
licenses and manage subscriptions. Be sure to follow the planning checklist before you begin
activation.
If you have already activated your deployment and you need to upgrade your Cloud Services
plugin to a new version, use the workflow in the Prisma Access Release Notes (Panorama
Managed).
If you have an existing Panorama Managed Prisma Access deployment, Palo Alto Networks sends
you a notification about the transition of your Prisma Access license activation to the Prisma SASE
Platform. After the transition, you can only use the Prisma SASE Platform for License Activation.
You cannot use the other Common Services such as Tenant Management or Identity & Access.
Continue to manage your tenants and user role permissions on Panorama as you have been doing.

Prisma Access does not support FIPS-CC mode.

Planning Checklist Before You Activate Panorama Managed

Prisma Access
If you are deploying Prisma Access for the first time, make sure that you have the following
information and resources:
Be sure that you have the order fulfillment email that contains the activation links that are
required to activate Prisma Access.
If you will use an existing Panorama to manage Prisma Access, be sure you that the Panorama
on which you will install the Cloud Services plugin (which activates Prisma Access) is running
the minimum Panorama version.
During product activation, you can select an existing Panorama to manage Prisma Access, if
you have registered Panorama, installed the licenses, and activated the support license on the
Customer Support Portal (CSP). If you have added the Panorama serial number to the same
CSP account on which you want to deploy Prisma Access, you can select the serial number of
this Panorama appliance during installation.
Alternatively, if you have a licensed Panorama that you have not yet installed, you can select
that Panorama during product activation; the installation process provides you with links
to register and install Panorama. In either case, the activation process allows the Panorama
appliance you select to manage Prisma Access, and you must make sure that the Panorama
appliance is running the minimum software version.
For a list of the Panorama software versions that are supported with Prisma Access, see
Minimum Required Panorama Software Versions in the Palo Alto Networks Compatibility
Matrix.

Make a note of the serial number of the Panorama appliance; you use that serial
number in a later step.

Prisma Access Administrator’s Guide (Panorama Managed) 96 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

Be sure that you have configured a DNS server and NTP server on the Panorama that manages
Prisma Access (Panorama > Setup > Services). If you do not configure a DNS and NTP server,
you cannot verify your account and will have to reinstall the plugin.
During Prisma Access installation, Palo Alto Networks provides you the required roles on the
Hub to activate Prisma Access, if those Hub roles are not already present. After you complete
installation, you are assigned a role of Instance Admin. If you need additional roles on the Hub
to perform system tasks, log in to the Hub, select Settings > Access Management, find the
Account Administrator for your organization, and contact them to be assigned additional roles.
(Deployments Using Panorama Appliances in HA Mode Only) If you plan to use two Panorama
appliances in High Availability (HA) mode, to simplify the HA set up, you should configure
the Panorama appliances in HA after you purchase Prisma Access and Cortex Data Lake auth
codes and components and associate the serial number of the primary Panorama appliance
on which you plan to install the Cloud Services plugin with the auth codes, but before you
Activate and Install Panorama Managed Prisma Access. However, you can use the same
configuration process for Panorama appliances that already have the plugin installed.

License Activation
Complete the following steps to activate your Prisma Access licenses and download and install the
Cloud Services plugin.
STEP 1 | When you receive the activation email from Palo Alto Networks, select Get Started with
Prisma SASE and begin the activation process.

STEP 2 | When setup is complete, copy the one-time password (OTP). You use this when you verify
your account on Panorama.

Prisma Access Administrator’s Guide (Panorama Managed) 97 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

STEP 3 | Download and install the Cloud Services plugin.

See the Palo Alto Networks Compatibility Matrix for the Panorama versions that are supported
with the Cloud Services plugin.
You can either download the plugin from the Customer Support Portal, or you can check for
plugin updates directly from Panorama.
• To download and install the Cloud Services plugin by downloading it from the Customer
Support Portal, complete the following steps.
1. Log in to the Customer Support Portal and select Software Updates > Panorama
Integration Plug In.
2. Find the Cloud Services plugin in the Panorama Integration Plug In section and download
it.

Do not rename the plugin file or you will not be able to install it on Panorama.

3. Log in to the Panorama Web Interface of the Panorama you licensed for use with the
Prisma Access, select Panorama > Plugins > Upload and Browse for the plugin File that
you downloaded from the CSP.
4. Install the plugin.
• To download and install the Cloud Services plugin directly from Panorama, complete the
following steps:
1. Select Panorama > Plugins and click Check Now to display the latest Cloud Services
plugin updates.

2. Download the plugin version you want to install.

3. After downloading the plugin, Install it.
Installing a newer version of the Cloud Services plugin overwrites the previously installed
version. If you are installing the plugin for the first time, after you successfully install,
Panorama refreshes and the Cloud Services menu displays on the Panorama tab.

Prisma Access Administrator’s Guide (Panorama Managed) 98 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

STEP 4 | Retrieve the Prisma Access license(s).

1. Select Panorama > Licenses and click Retrieve license keys from license server.
2. Verify that you have the licenses for the Prisma Access components you plan to use.

STEP 5 | Verify your account.

When you try to use the Cloud Services plugin for the first time after installing it, you will
be prompted to verify your account. This step ensures that the Panorama serial number is
registered to use Prisma Access and enables a secure communication path between the Prisma
Access components and Panorama.
1. In Panorama, select Panorama > Cloud Services > Configuration and click Verify.
If Verify is disabled, check that you have configured a DNS server and NTP server on
Panorama > Setup > Services.
2. Paste the One-time Password you copied and click OK.

You have ten minutes to enter the OTP before it expires.

Prisma Access Administrator’s Guide (Panorama Managed) 99 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

STEP 6 | Apply device group changes in the Prisma Access infrastructure.

Prisma Access moves all device groups under the Shared hierarchy. This step applies the
device group changes to your configuration.
1. Select Panorama > Cloud Services > Configuration > Service Setup.
2. Click the gear icon to edit the Settings.
3. Make sure that Service_Conn_Device_Group is selected as the Device Group Name and
Shared is selected as the Parent Device Group.

Prisma Access Administrator’s Guide (Panorama Managed) 100 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

4. Click OK.
Do not click Cancel, even if you did not make any changes to this page.

STEP 7 | Continue to configure your Prisma Access deployment by Enabling the Service
Infrastructure.

Prisma Access Administrator’s Guide (Panorama Managed) 101 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

Verify Your Account Using the One-Time Password

To reverify your account using the one-time password (OTP), complete one of the following tasks:
STEP 1 | Generate an OTP by going to the CSP, selecting Assets > Cloud Services, selecting Generate
OTP, selecting the serial number of your Panorama appliance and Generate OTP.

STEP 2 | Verify your account.

When you try to use the Cloud Services plugin for the first time after installing it, you will
be prompted to verify your account. This step ensures that the Panorama serial number is
registered to use Prisma Access and enables a secure communication path between the Prisma
Access components and Panorama.
1. In Panorama, select Panorama > Cloud Services > Configuration and click Verify.
If Verify is disabled, check that you have configured a DNS server and NTP server on
Panorama > Setup > Services.
2. Paste the One-time Password you copied and click OK.

You have ten minutes to enter the OTP before it expires.

Prisma Access Administrator’s Guide (Panorama Managed) 102 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

Transfer or Update Panorama Managed Prisma Access

Licenses
If you need to transfer your Panorama Managed Prisma Access license from one Panorama
appliance to another, or if you have an evaluation Prisma Access license and you purchase a
production license, use one of the following supported upgrade paths to transfer or upgrade your
license.
The license update procedure you use for Panorama Managed Prisma Access depends on the
type of Prisma Access license you have. If you are upgrading from an evaluation to a paid Prisma
Access license, the update path differs depending on the type of license your Panorama appliance
has.
• If you are transferring a production (paid) Prisma Access license from one Panorama appliance
to another, use the workflow in Transfer or Update Prisma Access Licenses Between Panorama
Appliances to transfer the Prisma Access license.
• If you are upgrading from an evaluation Prisma Access license to a production Prisma Access
license, use one of the following workflows to transfer the license:
• If your Panorama is a production appliance with active, paid licenses, use the workflow
in Reset Your Panorama Managed Prisma Access License to update your licenses to the
production service. We recommend using this update path because you do not have to
migrate your existing configuration.
• If your Panorama is an evaluation appliance, you need to transfer your Prisma Access license
to a production appliance. Use the workflow in Transfer or Update Prisma Access Licenses
Between Panorama Appliances to update your license to the production service.
Before you upgrade from an evaluation to a paid (production) license, be aware of the
following guidelines and requirements:
• If the production license components do not contain all the evaluation components,
remove the unlicensed components before you configure your production Prisma Access
environment. For example, if you have an evaluation license for Remote Networks and
Mobile Users - GlobalProtect, and migrate to a production license for Mobile Users -
GlobalProtect only, be sure to remove all configuration for Remote Networks before
you migrate to production; otherwise, you will receive a message that the component is
unlicensed when you commit.
• Do not proceed with the workflow until the order process is complete, the order has been
fulfilled, and the support portal is showing the newly purchased cloud service licenses.
• An evaluation license has the same capabilities as the Prisma Access Local Enterprise
edition, including supporting a maximum of 5 locations and 2 service connections, and
includes all the supported add-ons. After you purchase your Prisma Access production
license, you must determine what is supported with your Prisma Access production license
and deactivate the unsupported capabilities before you update your license from evaluation
to production.
• The number of locations and service connections for your production license depends on
the license type; check your license details to see the maximum number of locations and
service connections that are supported.

Prisma Access Administrator’s Guide (Panorama Managed) 103 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

The following table shows the supported license update methods based on the type of Panorama
appliance used with the evaluation.

Reset Your Panorama Managed Prisma Access License

Use this workflow if you need to modify one or more of your licenses; for example, if you update
your Prisma Access license from an evaluation to a production version.

If you are upgrading your Prisma Access license from evaluation to production, make sure
that your Panorama appliance has active, paid licenses before starting this procedure.
If your Panorama has an evaluation license, you need to transfer the Prisma Access
license to a Panorama with a production license.

STEP 1 | In the Panorama appliance, select Panorama > Licenses.

STEP 2 | Make a note or take a screenshot of the licenses you have, the quantity of licenses, and the
expiration date of each license.

STEP 3 | Remove the license that you need to modify.

For example, if you are upgrading from an evaluation to a production license, remove the
evaluation cloud service licenses you have installed.
1. Open a SSH console session to the Panorama appliance.
2. Enter the delete license key command, then press the Tab key to view all installed
license keys.
3. Delete all Prisma Access license keys, including the license keys for Cortex Data Lake,
Prisma Access for Users, Prisma Access for Networks, and Prisma Access for Clean Pipe,
as applicable to your deployment.
The following is an example of the process:

admin-Panorama> delete license key [then click tab]

GlobalProtect_Cloud_Service_f_2017_11_07.key
2017/11/0712:32:51 0.3K
GlobalProtect_Cloud_Service_for_Mobile_Users_2017_11_07.key
2018/01/10 13:52:18 0.3K
GlobalProtect_Cloud_Service_for_Remote_Networks_2017_11_07.key
2018/01/10 13:52:18 0.3K
Logging_Service_2017_11_07.key 2018/01/10 13:52:18 0.3K

Prisma Access Administrator’s Guide (Panorama Managed) 104 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

admin-Panorama> delete license key

Logging_Service_2017_11_07.key
successfully removed Logging_Service_2017_11_07.key

admin-Panorama> delete license key

GlobalProtect_Cloud_Service_f_2017_11_07.key
successfully removed
GlobalProtect_Cloud_Service_f_2017_11_07.key

admin-Panorama> delete license key

GlobalProtect_Cloud_Service_for_Remote_Networks_2017_11_07.key
successfully removed
GlobalProtect_Cloud_Service_for_Remote_Networks_2017_11_07.key

admin-Panorama> delete license key

GlobalProtect_Cloud_Service_for_Mobile_Users_2017_11_07.key
successfully removed
GlobalProtect_Cloud_Service_for_Mobile_Users_2017_11_07.key

STEP 4 | From the Panorama administration console, select Panorama > Licenses and click Retrieve
license keys from license server.
This step should refresh the licenses you already have, and the new licenses should reflect the
new quantity you purchased and the new expiration date.

STEP 5 | Delete any existing certificates using CLI from Panorama by entering the following
command:

admin-Panorama> request plugins cloud_services panorama-certificate

delete

STEP 6 | Enter the debug plugins cloud_services reset-endpoint command to reset the
Panorama appliance.

STEP 7 | Create the new certificate with the new OTP by entering the following command, where
value is the new OTP:

admin-Panorama> request plugins cloud_services panorama-certificate

fetch debug yes otp value

STEP 8 | Complete the one-time password (OTP) verification procedure and verify the Panorama
appliance.

STEP 9 | In Panorama, verify that you can make configuration changes and can successfully push the
configuration to Prisma Access.
If the licenses do not update correctly, or if you are not able to make configuration changes
after the refresh, contact Palo Alto Networks support.

Prisma Access Administrator’s Guide (Panorama Managed) 105 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

Transfer or Update Prisma Access Licenses Between Panorama

Appliances
Use the following workflow if you need to transfer Prisma Access licenses from one Panorama
appliance to another, for example:
• If you need to transfer production (paid) licenses from one Panorama appliance to another.
• If you are running an evaluation license on an evaluation Panorama appliance. After you
upgrade the Prisma Access license to a paid license, you cannot transfer this license to a
Panorama that has an evaluation license; in this case, you must transfer the production Prisma
Access license from an evaluation to a production Panorama appliance.
If you are migrating from an evaluation to a paid license, do not proceed with the workflow
until the order process is complete, the order has been fulfilled, and the support portal is
showing the newly purchased cloud service licenses.
Prisma Access automatically preserves all instances and public and loopback IP addresses during
the license transfer.
STEP 1 | (Optional) Export a snapshot of your Panorama configuration to a host external to Panorama
or to an on-premises firewall.
While Prisma Access saves all its infrastructure settings, including public and loopback IP
addresses, you need to transfer any Panorama-specific configuration to the new Panorama
appliance. You can export your configuration after the license transfer process is complete, but
we recommend exporting it before you transfer the licenses as a best practice.

STEP 2 | Log in to the Palo Alto Networks Customer Support Portal.

STEP 3 | Select Assets > Devices.

STEP 4 | Find the production Panorama appliance to which you will be transferring the production
Prisma Access plugin and complete these steps:
1. Verify that it has an active support license.
2. Make a note of this serial number; you use it in a later step.

STEP 5 | Search for the current Panorama appliance you are using to run Prisma Access by using the
serial number.
The model name should be in the format PAN-PRA-25-Exx.

STEP 6 | Click the Actions icon for the current Panorama appliance.

Prisma Access Administrator’s Guide (Panorama Managed) 106 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

STEP 7 | Select Transfer Licenses and choose the Panorama appliance to which you will be migrating.

STEP 8 | Review the EULA and click Agree, then click Submit.

STEP 9 | Wait for a confirmation message in the Support Portal for a successful transfer.

STEP 10 | After the successful transfer of licenses, login to the administration console of your
production Panorama appliance.

STEP 11 | Select Panorama > Support and verify that the Panorama appliance has a valid support
license.

STEP 12 | Click Dashboard and verify that the Panorama appliance is running the minimum supported
software version. See Minimum Required Panorama Software Versions for details.

STEP 13 | Verify that the Panorama appliance is configured to use NTP by selecting Panorama > Setup
> Services > NTP and setting a value, such as pool.ntp.org, for the NTP Server.

STEP 14 | Install the Cloud Services plugin.

Prisma Access Administrator’s Guide (Panorama Managed) 107 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

STEP 15 | Select Panorama > Licenses and click Retrieve license keys from license server.
This should refresh the screen with recently transferred Prisma Access and Cortex Data Lake
licenses you purchased. If the cloud service licenses do not appear, contact Palo Alto Networks
Support for assistance.

STEP 16 | Complete the one-time password (OTP) verification procedure and verify the Panorama
appliance.

STEP 17 | Migrate the configuration from the previous Panorama appliance to the current Panorama
appliance.
• If the production Panorama appliance is completely new, export the configuration from the
Panorama appliance you used during the evaluation (if you have not done so already) and
import it to this Panorama appliance.
• If this is the Panorama appliance that you have been using to manage your existing VMs and
devices, load a partial configuration to this Panorama appliance.
You can now use this Panorama appliance to configure and manage Prisma Access.

Prisma Access Administrator’s Guide (Panorama Managed) 108 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

Configure Panorama Appliances in High Availability for

Panorama Managed Prisma Access
Deploying Panorama appliances in a high availability (HA) configuration provides redundancy in
case of a system or network failure and ensures that you have continuous connectivity to Prisma
Access. In an HA configuration, one Panorama appliance peer is the active-primary and the other
is the passive-secondary. In the event of a failover, the secondary peer becomes active and takes
over the role of managing Prisma Access.
To simplify the HA set up, configure the Panorama appliances in HA after you purchase Prisma
Access and Cortex Data Lake auth codes and components and associate the serial number of
the primary Panorama appliance on which you plan to install the Cloud Services plugin with the
auth codes, but before you Activate and Install Panorama Managed Prisma Access. However, you
can also use this process to configure existing Panorama appliances that already have the plugin
installed.
Whether you are just getting started with a new pair of Panorama appliances, or you have
already set up your standalone Panorama appliance and completed the licensing and installation
procedures, make sure to check the prerequisites before you enable HA:
You must register the Panorama appliance HA peers to the same customer account on the
Customer Support Portal (CSP).
The Panorama appliance peers must be of the same form factor (hardware appliances of the
same model or identical virtual appliances) and same OS version and must have the same set of
licenses. The premium support license is required for Prisma Access and Cortex Data Lake.
The serial number of the primary Panorama appliance is tied to your Prisma Access and Cortex
Data Lake auth codes. If you have installed and set up the plugin on a standalone Panorama
appliance, ensure that you use that Panorama appliance as the primary peer. If you need to
assign this standalone peer as the secondary Panorama appliance, contact Palo Alto Networks
support for assistance with transferring the license to the primary Panorama appliance peer
before you continue.

If you disable HA for a Panorama pair and revert to a configuration where a single
Panorama manages Prisma Access, you must re-verify your account to prevent errors
when retrieving the status of Prisma Access components.

To set up your Panorama appliances in an HA configuration, complete the following steps.

STEP 1 | Set Up HA on Panorama.
Set the primary Panorama appliance as Primary and the secondary Panorama appliance as
Secondary and be sure that the serial number of your primary Panorama appliance is tied to
your Prisma Access and Cortex Data Lake auth codes.

Prisma Access Administrator’s Guide (Panorama Managed) 109 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

STEP 2 | Make sure that the primary (active) and secondary (passive) Panorama appliances are
synchronized and that the HA link state between them is up.
1. Access the Dashboard on the primary Panorama appliance and select Widgets > System
> High Availability to display the HA widget.
2. Sync to peer, click Yes, and wait for the Running Config to display Synchronized.
3. Make sure that the Local peer is active.
4. Access the Dashboard on the passive Panorama appliance and select Widgets > System
> High Availability to display the HA widget.
5. Verify that the Running Config displays Synchronized.
6. Make sure that the Local peer is passive.

STEP 3 | Install the Prisma Access components on the primary Panorama appliance.
1. Log in to the primary Panorama appliance and select Panorama > Licenses.
2. Click Retrieve the license keys from license server.
3. Activate and Install Panorama Managed Prisma Access, including generating a one-time
password (OTP) and verifying your account.

STEP 4 | Check that HA is enabled.

1. On the primary Panorama appliance, Access the CLI and enter the following operational
command:
tail follow yes mp-log plugin_cloud_services.log
2. Find the following text in the log output, where X is the serial number of the primary
Panorama appliance and Y is the serial number of the secondary Panorama appliance:

2017-11-06 15:14:07.790 -0800 INFO: [hainfo] Sending

update to CSP for HA peer serial information to https://
updates.paloaltonetworks.com/licensesvc/licenseservice.asmx/
PanoramaHAInfo (https://updates.paloaltonetworks.com/
licensesvc/licenseservice.asmx/PanoramaHAInfo)

2017-11-06 15:14:07.791 -0800 INFO: [hainfo] Data

string is primarypanoramasn=<varname>X</varname>
&secondarypanoramasn=<varname>Y</varname>

2017-11-06 15:14:17.595 -0800 INFO: [hainfo] HTTP_CODE 200,

RESPONSE: <?xml version="1.0" encoding="utf-8"?> <PanoramaHA
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance (http://
www.w3.org/2001/XMLSchema-instance)" xmlns:xsd="http://
www.w3.org/2001/XMLSchema (http://www.w3.org/2001/
XMLSchema)" xmlns="http://www.paloaltonetworks.com/ (http://
www.paloaltonetworks.com/)"> <success>true</success>
</PanoramaHA>

Prisma Access Administrator’s Guide (Panorama Managed) 110 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

2017-11-06 15:14:17.596 -0800 INFO: [hainfo] Cached HA Peer's

serial number <varname>Y</varname>

3. Log in to the Customer Support Portal (CSP) and select Assets > Cloud Services to verify
that both Panorama peers are tied to your Prisma Access and Cortex Data Lake licenses.
4. Check the fields for the primary and secondary Panorama appliance.
The Auth Code, Model Name, License Description, and Expiration Date fields should
be the same for the primary and secondary Panorama appliance, because Palo Alto
Networks has associated the Prisma Access license automatically to the secondary
Panorama appliance.

STEP 5 | Log in to the secondary Panorama appliance and Activate and Install Panorama Managed
Prisma Access.
When you log in to the Customer Support Portal (CSP) to generate the OTP, make sure that
you specify the serial number for the secondary Panorama appliance.

STEP 6 | Commit your changes on the primary and secondary Panorama appliance.
1. Commit > Commit and Push your changes.
2. Click OK and Push.

STEP 7 | Verify that the primary and secondary Panorama appliances are still in a synchronized state.

Prisma Access Administrator’s Guide (Panorama Managed) 111 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Activate and Install the Prisma Access Components

Prisma Access Administrator’s Guide (Panorama Managed) 112 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access
Infrastructure and Service
Connections
Prisma Access requires a service infrastructure that uses an infrastructure subnet you specify.
Prisma Access uses the IP addresses within this subnet to establish the network backbone that
connects your remote sites, mobile users, headquarters and data center (if applicable). Prisma
Access also uses service connections to access internal resources from your headquarters or data
center location. Learn more about these, as well as a high-level configuration overview, in the
following sections.
• Set Up Panorama Managed Prisma Access
• Prisma Access Service Infrastructure
• Prisma Access Service Connections
• Prisma Access Locations

113
Prepare the Prisma Access Infrastructure and Service Connections

Set Up Panorama Managed Prisma Access

The following workflow provides you with the summary steps that you take to install and
configure Panorama Managed Prisma Access.

If you are setting up a deployment that includes multiple instances of Prisma Access on a
single Panorama (multitenancy), see Manage Multiple Tenants in Prisma Access. Most
organizations do not have a need to create and manage multiple tenants.

STEP 1 | Add the following URLs and ports to an allow list on any security appliance that you use with
the Panorama appliance that manages Prisma Access.
In addition, if your Panorama appliance uses a proxy server (Panorama > Setup > Service
> Proxy Server), or if you use SSL forward proxy with Prisma Access, be sure to add the
following URLs and ports to an allow list on the proxy or proxy server.
• api.gpcloudservice.com (for Prisma Access)
• api.paloaltonetworks.com (for Prisma Access)
• apitrusted.paloaltonetworks.com (for Prisma Access)
• The FQDNs and ports required for Cortex Data Lake

If there is a Palo Alto Networks next-generation firewall between the Panorama

appliance and the internet, you must add a security policy rule on the firewall to
allow the paloalto-logging-service and paloalto-shared-services App-IDs from
the Panorama appliance to the internet. These applications allow SSL-secured
communication to Prisma Access and to Cortex Data Lake that the Panorama
appliance uses to query logs. If the Panorama appliance is behind a legacy Layer
4 firewall, permit ports 443 and 444 outbound from the Panorama to allow this
traffic from the Panorama. Note that opening layer 4 ports instead of using Palo Alto
Networks App-IDs is less secure and not recommended.

STEP 2 | Add the ports used by Panorama to allow lists in your network.

STEP 3 | Identify your license requirements; then Activate and Install the Prisma Access Components.

STEP 4 | Import your existing Panorama configuration to Prisma Access, or create new templates and
device groups to begin configuration of Prisma Access.
In order to push configuration—such as security policy, authentication policy, server profiles,
security profiles, address objects, and application groups—to Prisma Access, you must either
create new templates and device groups with the configuration settings you want to push to
Prisma Access, or leverage your existing device groups and templates by adding them to the

Prisma Access Administrator’s Guide (Panorama Managed) 114 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

template stacks and device group hierarchies that Prisma Access creates when you onboard
the service.
Prisma Access creates the following templates and device groups, depending on what you
have purchased (for example, if you do not purchase an Explicit Proxy license, you will not see
the Explicit Proxy templates and device groups):
• Templates:
• Explicit_Proxy_Template
• Explicit_Proxy_Template_Stack
• Mobile_User_Template
• Mobile_User_Template_Stack
• Remote_Network_Template
• Remote_Network_Template_Stack
• Service_Conn_Template
• Service_Conn_Template_Stack
• Device Groups:
• Explicit_Proxy_Device_Group
• Mobile_User_Device_Group
• Remote_Network_Device_Group
• Service_Conn_Device_Group
Configuration is simplified in Prisma Access because you do not have to configure any of
the infrastructure settings, such as interfaces and routing protocols. This configuration is
automated and pushed from Panorama in the templates and device groups that the service
creates automatically. You can configure any infrastructure settings that are required by the
service, such as settings required to create IPSec VPN tunnels to the IPSec-capable devices at
your remote network locations, directly from the plugin. Optionally, you can add templates and
device group hierarchies to the configuration to simplify the service setup.
To simplify the service setup, create or import the templates and device groups you need
before you begin the setup tasks for using Prisma Access.
When creating templates and device groups for Prisma Access, you do not need to assign
managed devices to it. Instead, you will add them to the template stacks and device group
hierarchies that Prisma Access creates. Do not add any of the templates or device groups
created by Prisma Access to any other template stacks or device groups.

STEP 5 | Sign up for email notifications using the Prisma Access app.
Prisma Access provides you with notifications about the service, including any dataplane
upgrades, using notifications from this app.

Prisma Access Administrator’s Guide (Panorama Managed) 115 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

STEP 6 | Change the default master key for Panorama and in the Cloud Services plugin.
Palo Alto Networks recommends changing the master key in Panorama and in the Cloud
Services plugin as a security best practice and that you change the master key monthly.
Because the Panorama and Prisma Access master keys do not synchronize, Palo Alto Networks
recommends that you do not automatically rotate the master key in Panorama without
also synchronizing the master key in Prisma Access. You can use the Panorama UI or API
commands to change the master keys.

Be sure to keep track of the master key you deploy because master keys cannot be
recovered. When a master key expires, you must enter the current master key in order
to configure a new master key. You must reset your Panorama appliance to factory
default if you cannot provide the current master key when it expires.

1. Change the master key in Panorama.

1. Select Panorama > Master Key and Diagnostics.
Do not specify a Current Master Key.
2. Configure the New Master Key and Confirm Master Key.
Make a note of the master key you configured.
3. Configure the master key Lifetime and Time for Reminder.
4. Click OK.
2. Change the master key for Prisma Access by selecting Panorama > Cloud Services >
Configuration > Service Operations > Edit master key, then entering the same master
key you entered for Panorama.
You can also change the master key by using API commands. This requires two steps–one to
change the Panorama master key and one to change the Prisma Access master key. Use the
following API commands to change the master key:
• Panorama: XML API > Operational Commands > request > master-key
• Prisma Access: XML API > Operational Commands > request > plugins > cloud_services >
prisma-access > sync

STEP 7 | Enable the service infrastructure and service connections that allows communication
between Prisma Access elements.
1. Plan to enable the service infrastructure and service connections.
2. Enable the service infrastructure.
3. Create a service connection to allow access to your corporate resources.
If you don’t require access to your corporate resources, you should still create a service
connection to enable access between mobile users and remote networks.

Prisma Access Administrator’s Guide (Panorama Managed) 116 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

STEP 8 | Prisma Access Mobile User Deployments and secure mobile users with GlobalProtect or
Explicit Proxy, as required for your deployment.
To Set Up GlobalProtect on Panorama Managed Prisma Access:
1. Configure zones for mobile users by creating two zones in the Mobile_User_Template (for
example, Mobile-Users and Internet) and mapping the zones. You should map any zone that
is not Prisma Access connected users or HQ or branch offices to Untrust.
Under Panorama > Cloud Services > Configuration > Mobile Users, map Internet to
Untrust; Mobile-Users to Trust.
2. Configure authentication.
We recommend using local authentication as a first step to verify that the service is set
up and your users have internet access. You can later switch to using your corporate
authentication methods.
3. Configure Security policies for the device group.
To create a Security policy to allow traffic to the Internet, select the
Mobile_User_Device_Group Policies > Security > Prerules > Add a rule. For example:
Mobile-Users to Internet.
4. Commit and push your changes to get started with the service.
5. Select Panorama > Cloud Services > Status > Monitor > Mobile Users to view the Status
and verify that you can ping the Portal FQDN.
6. Validate that Prisma Access is securing Internet traffic for mobile users by downloading
and installing the GlobalProtect app, using the app to connect to the portal as a mobile user
(local user), browsing to a few websites on the internet, and checking the traffic logs on
Panorama.
To Secure Mobile Users with an Explicit Proxy:
1. Read the guidelines and requirements.
2. Configure SAML Authentication (for example, use the Cloud Identity Engine to authenticate
Explicit Proxy mobile users. SAML authentication is required for Explicit Proxy.
3. Set up Group Mapping using the Cloud Identity Engine.
4. Complete the Explicit Proxy configuration.
5. Commit and Push your changes.

STEP 9 | Plan, create, and configure remote network connections.

1. Add one or more remote networks to Prisma Access.
You can onboard one location and then add additional locations using the bulk import
capability.
2. Create a Security policy rule to allow traffic from the remote networks to HQ (For
example: Trust to Trust).
3. Validate the connectivity between the service connection, remote network connection,
and mobile users.

Prisma Access Administrator’s Guide (Panorama Managed) 117 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

STEP 10 | Run the API Script Used to Retrieve Prisma Access IP Addresses and Use the Legacy Script
to Retrieve Mobile User IP Addresses.
You add these addresses to an allow list on your organization’s network to limit inbound access
to your enterprise network and applications.

STEP 11 | (Optional) Change the authentication method from local authentication to your
organization’s authentication method.
1. Create an authentication profile that meets your organization’s requirements (Cloud
Identity Engine, SAML, LDAP, RADIUS, etc).
2. If your organization uses an on-premises authentication server such as RADIUS or Active
Directory, add the IP addresses that Prisma Access uses as its source IP address for
internal requests (Retrieve the IP Addresses for Prisma Access) to allow lists in your
network, or allow the IP addresses of the entire Infrastructure Subnet (Prisma Access
takes the loopback IP address from this subnet).
3. Update the Authentication Profile for the Prisma Access portal and gateway to use this
new authentication profile.

STEP 12 | (Optional) Forward logs from Cortex Data Lake to a syslog server, HTTPS server, or email
server.

Prisma Access Administrator’s Guide (Panorama Managed) 118 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Prisma Access Service Infrastructure

Prisma Access requires a service infrastructure that uses an infrastructure subnet you specify.
Prisma Access uses the IP addresses within this subnet to establish the network backbone that
connects your remote sites, mobile users, headquarters and data center (if applicable).
To Enable the Service Infrastructure in the cloud for your remote network locations and mobile
users, you must provide a subnet that Prisma Access uses to establish a network infrastructure
between your remote network locations, mobile users, and service connections to your
headquarters/data center (if applicable). The IP addresses in this subnet also enable Prisma Access
to determine the service routes for services such as LDAP, DNS, or SCEP, as well as enable other
inter-service communication. Because a large number of IP addresses will be required to set up
the infrastructure, you must use a /24 subnet (for example, 172.16.55.0/24) at a minimum. This
subnetwork will be an extension to your existing network or with the IP address pools you assign
for Prisma Access for users. If you have a large number of mobile users, branch offices, or both,
provide a larger infrastructure subnet.

Service Infrastructure Requirements

Use the following recommendations and requirements when adding an infrastructure subnet:
• You can assign Prisma Access an infrastructure subnet from a existing supernet in
your organization’s IP address pool, but do not assign any of the IP addresses from the
infrastructure subnet for any other use in your existing network.
The following example shows a Prisma Access infrastructure subnet, 10.10.1.0/24, that
you assigned from an existing supernet, 10.0.0.0/8. After you assign 10.10.1.0/24 as the
infrastructure subnet, your organization cannot use any IP addresses from that subnet. For
example, you can assign 10.10.2.1 to an endpoint, but 10.10.1.1 is not allowed because that IP
address is part of the infrastructure subnet.

• If you create a new subnet for the infrastructure subnet, use a subnet that does not overlap
with other IP addresses you use internally.

Prisma Access Administrator’s Guide (Panorama Managed) 119 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

• (Recommended) Use an RFC 1918-compliant subnet. 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.169.253, 169.254.169.254, 169.254.201.0/24, 169.254.202.0/24, and
100.64.0.0/10.
• The subnet cannot overlap with the IP address pools you plan to use for the address pools you
assign for your mobile users deployment.
• Because the service infrastructure can be very large, you must designate a /24 subnet at a
minimum.

Configure the Service Infrastructure

Before you can begin setting up Prisma Access to secure your remote networks and/or mobile
users, you must configure an infrastructure subnet, which Prisma Access will use to create the
network backbone for communication between your service connections, remote networks,
and mobile users, as well as with the corporate networks you plan to connect to Prisma Access
over service connections. Because a large number of IP addresses will be required to set up the
infrastructure, you must use a /24 subnet (for example, 172.16.55.0/24) at a minimum. Be sure
you follow all guidelines and requirements.
STEP 1 | Select Panorama > Cloud Services > Configuration > Service Setup and click the gear icon to
edit the Settings.

Prisma Access Administrator’s Guide (Panorama Managed) 120 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

STEP 2 | On the General tab, specify an Infrastructure Subnet that meets the requirements, for
example, 172.16.55.0/24.

STEP 3 | (Optional) If you want to enable Prisma Access to use BGP to dynamically discover routes to
resources on your remote networks and HQ/data center locations, enter the Infrastructure
BGP AS you want to use within the Prisma Access infrastructure.
If you do not supply an AS number, the default AS number 65534 will be used.

STEP 4 | (Optional) Add one or more templates to the predefined template stack,
Service_Conn_Template_Stack.
The templates you add here can help simplify the process of adding new service connections.
For example, if you add a template containing existing IPSec configuration settings, such as
IPSec tunnel, Tunnel Monitoring, and IPSec Crypto Profile configurations, you can select these
configurations when defining the tunnel settings for each service connection rather than
having to create the tunnel configuration from scratch. You can optionally edit the predefined
Service_Conn_Template with tunnel settings that you can leverage when creating the tunnels
from Prisma Access to your corporate network sites.

STEP 5 | (Optional) Enable Prisma Access to resolve your internal domains using your corporate DNS
servers.
Use this step if you need Prisma Access to be able to resolve your internal domains to
access services, such as LDAP servers, on your corporate network via service connections.
For example, if you want a DNS lookup for your corporate domain to go exclusively to the
corporate DNS server, specify the corporate domain and the corporate DNS servers here.
1. Select the Internal Domain List tab.
2. Add the Domain Names, Primary DNS, and Secondary DNS servers that you want
Prisma Access to use to resolve your internal domain names.
You can use a wildcard (*) in front of the domains in the domain list, for example
*.acme.local or *.acme.com.

Prisma Access Administrator’s Guide (Panorama Managed) 121 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

STEP 6 | Enable Cortex Data Lake.

1. Select the Cortex Data Lake tab.
2. Select a Cortex Data Lake Theater and click OK.

3. Configure the device groups you are using to push settings to Prisma Access with a Log
Forwarding profile that forwards the desired log types to Panorama/Cortex Data Lake.
The Cloud Services plugin automatically adds the following Log Settings (Device > Log
Settings) after a new installation or when removing non-Prisma Access templates from a
Prisma Access template stack:
• Log Settings for System logs (system-gpcs-default), User-ID logs (userid-gpcs-
default), HIP Match logs (hipmatch-gpcs-default), and GlobalProtect logs (gp-
prismaaccess-default) are added to the Mobile_User_Template.
• Log Settings for System logs (system-gpcs-default), User-ID logs (userid-gpcs-
default), and GlobalProtect logs (gp-prismaaccess-default) are added to the
Remote_Network_Template.
• Log Settings for System logs (system-gpcs-default) and GlobalProtect logs (gp-
prismaaccess-default) are added to the Service_Conn_Template.
These Log Setting configurations automatically forward System, User-ID, HIP Match, and
GlobalProtect logs to Cortex Data Lake.
To apply log setting changes, perform the following steps, then commit and push your
changes:
• To apply the log setting to the mobile user template, select Panorama > Cloud
Services > Configuration > Mobile Users, click the gear icon to edit the settings, and
click OK.
• To apply the log setting to the remote network template, select Panorama > Cloud
Services > Configuration > Remote Networks, click the gear icon to edit the settings,
and click OK.
• To apply the log setting to the service connection template, select Panorama > Cloud
Services > Configuration > Service Setup, click the gear icon to edit the settings, and
click OK.
The way you enable log forwarding for other log types depends on the type. For logs
that are generated based on a policy match, use a log forwarding profile. See the Cortex
Data Lake Getting Started Guide for more information.

Prisma Access Administrator’s Guide (Panorama Managed) 122 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

STEP 7 | (Optional) Configure Miscellaneous settings.

1. (Optional) Append the ending token for URLs in external dynamic lists (EDLs) or custom
URL categories by selecting Append the ending token to the URLs in the URL filtering
configuration.
If you use URLs in EDLs or custom URL categories and do not append a forward slash
(/) to the URL, it is possible to allow more URLs than you intended. For example,
entering example.com as a matching URL instead of example.com/ would also match
example.com.website.info or example.com.br.
By selecting Append the ending token to the URLs in the URL filtering configuration,
Prisma Access sets an ending token to URLs in EDLs or custom URL categories so that,
if you enter example.com, Prisma Access treats it as it would treat example.com/ and
only matches that URL.
2. (Optional) Disable Traffic Logging on Service Connections to disable logging on the
service connections for your Prisma Access deployment.
If the majority of the traffic flows logged by the service connections are asymmetric,
disabling service connection logging might be required to reduce the consumption of
Cortex Data Lake logging storage. If your deployment does not have asymmetric flows
via the service connections, you do not need to disable logging.

STEP 8 | (Optional) Configure Advanced settings (routing preferences, symmetric network path
options for service connections, and HIP redistribution).
1. Specify the Routing Preference to use with service connections.
You can specify network preferences to use either your organization’s network, or the
Prisma Access network, to process the service connection traffic.
• Default—Prisma Access uses default routing in its internal network.
• Hot potato routing—Prisma Access hands off service connection traffic to your
organization’s WAN as quickly as possible.

Changing the Prisma Access service connection routing method requires a

thorough understanding of your organization’s topology and routing devices,
along with an understanding of how Prisma Access routing works. We
recommend that you read Routing for Service Connection Traffic carefully
before changing the routing method from default.
2. Configure the Backbone Routing to use for the service connections.
By default, the Prisma Access backbone requires that you have a symmetric network
path for the traffic returning from the data center or headquarters location by way of

Prisma Access Administrator’s Guide (Panorama Managed) 123 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

a service connection. If you want to use ECMP or another load balancing mechanism
for service connections from your CPE, you can enable asymmetric flows through the
Prisma Access backbone.
• Select no-asymmetric-routing to require symmetric flows across the service
connection backbone (the default setting).
• Select asymmetric-routing-only to allow Prisma Access to use asymmetric flows
across the service connection backbone.
• If you have multiple service connections to a location, you can take advantage of load
balancing in your Prisma Access deployment by selecting asymmetric-routing-with-
load-share. However, load balancing is done on a best-effort basis, and load balancing
will fail if one of the service connections goes down.
3. Enable HIP Redistribution to use service connections to redistribute HIP information
from mobile users and users at remote networks.
4. Enable Quarantine List Redistribution to have Prisma Access identify and quarantine
compromised devices that are connected with the GlobalProtect app.
5. Withdraw Static Routes if Service Connection or Remote Network IPSec tunnel is down
if you want Prisma Access to remove static routes when a tunnel goes down without a
backup tunnel.
Prisma Access removes the route in the following situations:
• The primary tunnel goes down and there is no secondary tunnel.
• If a primary and secondary tunnel is configured, but both go down.
You cannot apply this change if tunnel monitoring is not enabled.
6. (Optional) If you want to route remote network and service connection IPSec tunnel
packets to the static IKE gateways over the internet, Enable automatic IKE peer host
routes for Remote Networks and Service Connections.
7. (Optional) Specify Outbound Routes for the Service (Max 10) by adding up to 10
prefixes for which Prisma Access adds static routes on all service connections and

Prisma Access Administrator’s Guide (Panorama Managed) 124 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

remote network connections. Prisma Access then routes traffic to these prefixes over
the internet.

STEP 9 | Click OK to save the Service Setup settings.

Prisma Access Administrator’s Guide (Panorama Managed) 125 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

STEP 10 | Commit all your changes to Panorama and push the configuration changes to Prisma Access.
1. Click Commit > Commit to Panorama.
2. Click Commit > Push to Devices and click Edit Selections.
3. On the Prisma Access tab, make sure Service setup is selected and then click OK.
Prisma Access should automatically select the components that need to be committed.

4. Click Push.

STEP 11 | Verify that Prisma Access is successfully connected to Cortex Data Lake.
1. Select Panorama > Cloud Services > Status > Status > Cortex Data Lake and verify that
the Status is OK.

If the status is Error, click the details link to view any errors.

STEP 12 | Continue setting up Prisma Access:

• Create a Service Connection to Allow Access to Private Apps
• Configure Prisma Access for Networks
• Configure Prisma Access for Users

Prisma Access Administrator’s Guide (Panorama Managed) 126 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Prisma Access Service Connections

A service connection, also known as a Corporate Access Node (CAN), allows mobile users and
users at remote networks access to internal resources and lets your mobile users and remote
networks communicate with each other. Palo Alto Networks recommends always creating
a service connection in your Prisma Access deployment. All service connection have these
characteristics:
• A service connection allows access to the resources in your HQ or data center.
For example, if your security policy requires user authentication using an on-premises
authentication service, such as your Active Directory, you will need to enable Prisma Access
to access the corporate location where the service resides (and set up a service account that
the service can use to access it). Similarly, if you have corporate resources that your remote
networks and mobile users will need to access, you must enable Prisma Access to access the
corresponding corporate network.
If you create service connections for this reason, you should plan for the service connections
before implementing them.
• A service connection allows remote networks and mobile users to communicate with each
other.
Even if you don’t need access to your HQ or data center, you might have a need to allow
your mobile users to access your remote network locations. In this case, you can create a
service connection with placeholder values. This is required because, while all remote network
connections are fully meshed, mobile users connect to remote networks using the service
connection in a hub-and-spoke network. For this reason, you might also create a service
connection with placeholder values if your existing service connection is not in an ideal
geographical location.
• Service connections do not support language localization because egress to the internet is not
supported over service connections. Prisma Access allocates only one service IP address per
service connection, and that IP address is geographically registered to the compute location
that corresponds to the location you specify during onboarding.
The number of service connections you receive depends on your Prisma Access license.
• If you have a ZTNA or Enterprise license, the number of service connections depends on
your License edition. If you have a Local edition, you can configure a maximum of two service
connections; f you have a Worldwide edition, you can configure a maximum of five service
connections.

Prisma Access Administrator’s Guide (Panorama Managed) 127 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

• If you manage multiple tenants and have a ZTNA or Enterprise license, the number of service
connections per tenant depends on the number of units you allocate per tenant and the type of
license you have.
• If you have a Global license and allocate at least 1,000 units for a tenant, you can allocate a
maximum of five service connections for that tenant.
• If you have a Global license and allocate between 200 and 999 units for a tenant, you can
allocate a maximum of two service connections for that tenant (the same as the number of
connections for a Local deployment).
• If you have a Local license, you can allocate a maximum of two service connections per
tenant, regardless of the number of units you allocate past the minimum of 200.
For both Global and Local licenses, you can purchase additional licenses for service
connections if more are required.

While each service connection provides approximately 1 Gbps of throughput, the actual
throughput is dependent on several factors, including:
• Traffic mix (for example, frame size)
• Latency and packet loss between the service connection and the headquarters location
or data center
• Service provider performance limits
• Customer termination device performance limits
• Other customer data center traffic

Plan the Service Connections

If you use the service connection to access information from your headquarters or data center,
gather the following information for each of your HQ/data center sites that you want to connect
to Prisma Access:

If you are creating a service connection only to provide communication between remote
networks and mobile users, you do not need this information.

IPSec-capable firewall, router, or SD-WAN device connection.

IPSec settings for terminating the primary VPN tunnel from Prisma Access to the IPSec-capable
device on your corporate network.
IPSec settings for terminating the secondary VPN tunnel from Prisma Access to the IPSec-
capable device on your corporate network.

If you have an existing template that contains IPSec tunnel, Tunnel Monitoring,
and IPSec Crypto Profile configurations, you can add that template to the template
stack to simplify the process of creating the IPSec tunnels. Or, you can edit the
Service_Conn_Template that gets created automatically and create the IPSec
configurations required to create the IPSec tunnel back to the corporate site.
Prisma Access also provides you with a set of predefined IPSec templates for some
commonly-used network devices, and a generic template for any device that is not
included in the predefined templates.

Prisma Access Administrator’s Guide (Panorama Managed) 128 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

List of IP subnetworks at the site.

List of internal domains that the cloud service will need to be able to resolve.
IP address of a node at your network’s site to which Prisma Access can send ICMP ping
requests for IPSec tunnel monitoring.
Make sure that this address is reachable by ICMP from the entire Prisma Access infrastructure
subnet.
Service account for your authentication service, if required for access.
Network reachability settings for the service infrastructure subnet.
We recommend that you make the entire service infrastructure subnet reachable from the
HQ or Data Center site. Prisma Access uses IP addresses for all control plane traffic, including
tunnel monitoring, LDAP, User-ID, and so on from this subnet.
The routing type (either static or dynamic (BGP)) to use with service connections.
In order for Prisma Access to route users to the resources they need, you must provide the
routes to the resources. You can do this in one or more of the following ways:
• Define a static route to each subnetwork or specific resource that you want your users to
be able to access.
• Configure BGP between your service connection locations and Prisma Access.
• Use a combination of both methods.
If you configure both static routes and enable BGP, the static routes will take precedence.
While it might be convenient to use static routes if you have just a few subnetworks or
resources you want to allow access to, in a large data center/HQ environment where you have
routes that change dynamically, BGP will enable you to scale easier. Dynamic routing also
provides redundancy for your service connections. If one service connection tunnel is down,
BGP can dynamically route mobile user and remote network traffic over the operational service
connection tunnel.

Create a Service Connection to Allow Access to Private Apps

To create a service connection to allow access to private apps or internal corporate resources,
complete the following steps.

If you are creating a service connection to allow communication between mobile users
and remote networks, instead of enabling access to your corporate resources, follow the
instructions in Create a Service Connection to Enable Access between Mobile Users
and Remote Networks.

STEP 1 | Select Panorama > Cloud Services > Configuration > Service Connection.

STEP 2 | Add a new service connection to one of your corporate network sites.

STEP 3 | Specify a Name for the corporate site.

STEP 4 | Select the Location closest to where the site is located.

See this section for a list of Prisma Access locations.

Prisma Access Administrator’s Guide (Panorama Managed) 129 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

STEP 5 | Select or add a new IPSec Tunnel configuration to access the firewall, router, or SD-WAN
device at the corporate location:
• If you have added a template to the Service_Conn_Template_Stack (or modified the
predefined Service_Conn_Template) that includes an IPSec Tunnel configuration, select that
IPSec Tunnel from the drop-down. Note that the tunnel you are creating for each service
connection connects Prisma Access to the IPSec-capable device at each corporate location.
The peer addresses in the IKE Gateway configuration must be unique for each tunnel. You
can, however, re-use some of the other common configuration elements, such as Crypto
profiles.

The IPSec Tunnel you select from a template must use Auto Key exchange and IPv4
only. In addition, make sure that the IPSec tunnel, IKE gateway, and crypto profile
names are 31 characters or less.
• To create a new IPSec Tunnel configuration, click New IPSec Tunnel, give it a Name and
configure the IKE Gateway, IPSec Crypto Profile, and Tunnel Monitoring settings.
• If the IPSec-capable device at your HQ or data center location uses policy-based VPN,
on the Proxy IDs tab, Add a proxy ID that matches the settings configured on your local

Prisma Access Administrator’s Guide (Panorama Managed) 130 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

IPSec device to ensure that Prisma Access can successfully establish an IPSec tunnel
with your local device.
• Leave Enable Replay Protection selected to detect and neutralize against replay attacks.
• Select Copy TOS Header to copy the Type of Service (TOS) header from the inner IP header
to the outer IP header of the encapsulated packets in order to preserve the original TOS
information.
• To enable tunnel monitoring for the service connection, select Tunnel Monitor.
• Enter a Destination IP address.
Specify an IP address at your HQ or data center site to which Prisma Access can send
ICMP ping requests for IPSec tunnel monitoring. Make sure that this address is reachable
by ICMP from the entire Prisma Access infrastructure subnet.
• If you use tunnel monitoring with a peer device that uses multiple proxy IDs, specify a
Proxy ID or add a New Proxy ID that allows access from the infrastructure subnet to
your HQ or data center site.
The following figure shows a proxy ID with the service infrastructure subnet
(172.16.55.0/24 in this example) as the Local IP subnet and the HQ or data center’s
subnet (10.1.1.0/24 in this example) as the Remote subnet.

The following figure shows the Proxy ID you created being applied to the tunnel monitor
configuration by specifying it in the Proxy ID field.

Prisma Access Administrator’s Guide (Panorama Managed) 131 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

You must configure a static route on your CPE to the Tunnel Monitor IP Address
for tunnel monitoring to function. To find the destination IP address to use
for tunnel monitoring from your data center or HQ network to Prisma Access,
select Panorama > Cloud Services > Status > Network Details, click the Service
Infrastructure radio button, and find the Tunnel Monitor IP Address.

STEP 6 | BGP and hot potato routing deployments only—Select a service connection to use as the
preferred backup (Backup SC).
You can select any service connection that you have already added. Prisma Access uses
the Backup SC you select as the preferred service connection in the event of a link failure.
Selecting a backup service connection can prevent asymmetric routing issues if you have
onboarded more than two service connections. This choice is available in Hot potato routing
mode only.

STEP 7 | If you have a secondary WAN link at this location, select Enable Secondary WAN and then
select or configure an IPSec Tunnel the same way you did to set up the primary IPSec tunnel.
If the primary WAN link goes down, Prisma Access detects the outage and establishes a tunnel
to the headquarters or data center location over the secondary WAN link. If the primary WAN
link becomes active, the link switches back to the primary link.
Configuring a Secondary WAN is not supported in the following deployments:
• If your secondary WAN is set up in active-active mode with the Primary IPSec tunnel.
• If your customer premises equipment (CPE) is set up in an Equal Cost Multipath (ECMP)
configuration with the Primary and Secondary IPSec tunnel.

If you use static routes, tunnel failover time is less than 15 seconds from the time of detection,
depending on your WAN provider.
If you configure BGP routing and have enabled tunnel monitoring, the shortest default hold
time to determine that a security parameter index (SPI) is failing is the tunnel monitor, which
removes all routes to a peer when it detects a tunnel failure for 15 consecutive seconds. In this
way, the tunnel monitor determines the behavior of the BGP routes. If you do not configure
tunnel monitoring, the hold timer determines the amount of time that the tunnel is down
before removing the route. Prisma Access uses the default BGP HoldTime value of 90 seconds
as defined by RFC 4271, which is the maximum wait time before Prisma Access removes a

Prisma Access Administrator’s Guide (Panorama Managed) 132 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

route for an inactive SPI. If the peer BGP device has a shorter configured hold time, the BGP
hold timer uses the lower value.
When the secondary tunnel is successfully installed, the secondary route takes precedence
until the primary tunnel comes back up. If the primary and secondary are both up, the primary
route takes priority.

If you use a different BGP peer for the secondary (backup) connection, Prisma Access
does not honor the Multi-Exit Discriminator (MED) attributes advertised by the
CPE. This caveat applies if you use multiple BGP peers on either remote network
connections or service connections.

STEP 8 | (Optional, 3.2 Innovation Deployments Only) Enable Source NAT for Mobile Users—
GlobalProtect IP pool addresses, IP addresses in the Infrastructure Subnet, or both.
You can specify a subnet at one or more service connections that are used to NAT traffic
between Prisma Access GlobalProtect mobile users and private applications and resources at a
data center.
• Enable Data Traffic Source NAT—Performs NAT on Mobile User IP Address pool addresses
so that they are not advertised to the data center, and only the subnets you specify at the
service connections are advertised and routed in the data center.
• Enable Infrastructure Traffic Source NAT—Performs NAT on addresses from the
Infrastructure Subnet so that they are not advertised to the data center, and only those
subnets you specify at the service connections are advertised and routed in the data center.
• IP Pool—Specify the IP address pool used to perform NAT on the mobile user IP address
pool, Infrastructure Subnet, or both.
Use a private IP (RFC 1918) subnet or a suitable subnet that is routable in your routing
domain, and does not overlap with the Mobile Users—GlobalProtect IP address pool or the
Infrastructure Subnet. Enter a subnet between /25 and /32.

STEP 9 | Enable routing to the subnetworks or individual IP addresses at the corporate site that your
users will need access to.
Prisma Access uses this information to route requests to the appropriate site. The networks
at each site cannot overlap with each other or with IP address pools that you designated for

Prisma Access Administrator’s Guide (Panorama Managed) 133 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

the service infrastructure or for the Prisma Access for users IP pools. You can configure Static
Routes, BGP, or a combination of both.
To configure Static Routes:
1. On the Static Routes tab, click Add and enter the subnetwork address (for example,
172.168.10.0/24) or individual IP address of a resource, such as a DNS server (for example,
10.32.5.1/32) that your remote users will need access to.
2. Repeat for all subnets or IP addresses that Prisma Access will need access to at this
location.

To configure BGP:
1. On the BGP tab, select Enable.
When you enable BGP, Prisma Access sets the time to live (TTL) value for external BGP
(eBGP) to 8 to accommodate any extra hops that might occur between the Prisma Access

Prisma Access Administrator’s Guide (Panorama Managed) 134 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

infrastructure and your customer premises equipment (CPE) that terminates the eBGP
connection.

Prisma Access does not accept BGP default route advertisements for either service
connections or remote network connections.
2. (Optional) Select from the following choices:
• To add a no-export community for Corporate Access Nodes (Service Connections) to the
outbound prefixes from the eBGP peers at the customer premises equipment (CPE), set
Add no-export community to Enabled Out. This capability is Disabled by default.
Do not use this capability in hot potato routing mode.
• To prevent the Prisma Access BGP peer from forwarding routes into your organization’s
network. Don’t Advertise Prisma Access Routes.
By default, Prisma Access advertises all BGP routing information, including local routes
and all prefixes it receives from other service connections, remote networks, and mobile
user subnets. Select this check box to prevent Prisma Access from sending any BGP
advertisements, but still use the BGP information it receives to learn routes from other
BGP neighbors.

Since Prisma Access does not send BGP advertisements if you select this option,
you must configure static routes on the on-premises equipment to establish
routes back to Prisma Access.
• To reduce the number of mobile user IP subnet advertisements over BGP to your
customer premises equipment (CPE), specify Prisma Access to summarize the subnets
before it advertises them by selecting Summarize Mobile User Routes before
advertising.
By default, Prisma Access advertises the mobile users IP address pools in blocks of /24
subnets; if you summarize them, Prisma Access advertises the pool based on the
subnet you specified. For example, Prisma Access advertises a public user mobile IP
pool of 10.8.0.0/20 using the /20 subnet, rather than dividing the pool into subnets of
10.8.1.0/24, 10.8.2.0/24, 10.8.3.0/24, and so on before advertising them. Summarizing
these advertisements can reduce the number of routes stored in CPE routing tables. For
example, you can use IP pool summarization with cloud VPN gateways (Virtual Private

Prisma Access Administrator’s Guide (Panorama Managed) 135 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Gateways (VGWs) or Transit Gateways (TGWs)) that can accept a limited number of
routes.

If you have hot potato routing enabled and you enable route summarization,
Prisma Access no longer prepends AS-PATHs, which might cause asymmetric
routing. Be sure that your return traffic from the data center or headquarters
location has guaranteed symmetric return before you enable route
summarization with hot potato routing.
3. Enter the IP address assigned as the Router ID of the eBGP router on the data center/HQ
network for which you are configuring this service connection as the Peer Address.
4. Enter the Peer AS, which is the autonomous system (AS) to which the firewall virtual router
or BGP router at your data center/HQ network belongs.
5. (Optional) Enter an address that Prisma Access uses as its Local IP address for BGP.
Specifying a Local Address is useful where the device on the other side of the connection
(such as an Amazon Web Service (AWS) Virtual Private Gateway) requires a specific local IP
address for BGP peering to be successful. Make sure that the address you specify does not
conflict or overlap with IP addresses in the Infrastructure Subnet or subnets in the service
connection.

You must configure a static route on your CPE to the BGP Local Address.

If you use IPv6 networking for your service connection, you can configure IPv6 addresses
as well as IPv4 addresses. You also need to enable IPv6 networking globally in your Prisma
Access infrastructure before you can use IPv6 addressing.
If you do not specify a local address, Prisma Access uses an IP address from the
Infrastructure Subnet. After you Commit and Push your changes, you can find the Local

Prisma Access Administrator’s Guide (Panorama Managed) 136 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Address used under the EBGP Router Address (Panorama > Cloud Services > Status >
Network Details > Service Connection > EBGP Router).
6. (Optional) Enter and confirm a Secret passphrase to authenticate BGP peer
communications.

STEP 10 | (Optional) If you configured a Secondary WAN and you need to change the Peer Address
or Local Address for the secondary (backup) BGP peer, deselect Same as Primary WAN and
enter a unique Peer and, optionally, Local IP address for the secondary WAN.
In some deployments (for example, when using BGP to peer with an AWS VPN gateway), the
BGP peer for the primary and secondary WAN might be different. In those scenarios, you can
choose to set a different BGP peer for the secondary WAN.

For BGP deployments with secondary WANs, Prisma Access sets both the primary
and secondary tunnels in an UP state, but follows normal BGP active-backup behavior
for network traffic. Prisma Access sets the primary tunnel as active and sends and
receives traffic through that tunnel only; if the primary tunnel fails, Prisma Access
detects the failure using BGP rules, sets the secondary tunnel as active, and uses only
the secondary tunnel to send and receive traffic.

Prisma Access Administrator’s Guide (Panorama Managed) 137 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

STEP 11 | If required, enable Quality of Service for the service connection and specify a QoS profile or
add a New QoS Profile.
You can create QoS profiles to shape QoS traffic for remote network and service connections
and apply those profiles to traffic that you marked with PAN-OS security policies, traffic that
you marked with an on-premises device, or both PAN-OS-marked and on-premise-marked
traffic. See Quality of Service in Prisma Access for details.

STEP 12 | (Optional) Configure Miscellaneous settings.

1. (Optional) Disable Traffic Logging on Service Connections to disable logging on the
service connections for your Prisma Access deployment.
If the majority of the traffic flows logged by the service connections are asymmetric,
disabling service connection logging might be required to reduce the consumption of
Cortex Data Lake logging storage. If your deployment does not have asymmetric flows
via the service connections, you do not need to disable logging.

Prisma Access Administrator’s Guide (Panorama Managed) 138 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

STEP 13 | Commit your changes to Panorama and push the configuration changes to Prisma Access.
1. Click Commit > Commit and Push.
2. Edit Selections and, in the Prisma Access tab, make sure that Service Setup is selected in
the Push Scope, then click OK.

3. Click Commit and Push.

STEP 14 | Add more service connections by repeating Step 2 through Step 13.

STEP 15 | Configure the IPSec tunnel or tunnels from your IPSec-capable device on your corporate
network back to Prisma Access.
1. To determine the IP address of the tunnel within Prisma Access, select Panorama >
Cloud Services > Status > Network Details, click the Service Connection radio button,
and note the Service IP Address for the site.
The Service IP Address is the public-facing address that you will need to connect
to when you create the tunnel from your IPSec-capable device back to the service
connection.

2. On your IPSec-capable device at the corporate location, configure an IPSec tunnel that
connects to the Service IP Address within Prisma Access and commit the change on that
device so that the tunnel can be established.

Prisma Access Administrator’s Guide (Panorama Managed) 139 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Verify Service Connection Status

To verify that the service connection has been successfully set up, select Panorama > Cloud
Services > Status > Status and check that the Status is OK.

If you created a service connection with placeholder values to enable communication

between mobile users and users at remote networks, you do not need to verify the
service connection status.

The Deployment Status area allows you to view the progress of onboarding and deployment jobs
before they complete, as well as see more information about the status of completed jobs. See
Prisma Access Deployment Progress and Status for details.

If the status is not OK, hover over the Status icon to view any errors.
To see a graphical representation of the service connection along with status details, select
Service Connection on the Monitor tab.

Prisma Access Administrator’s Guide (Panorama Managed) 140 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Select a region to get more detail about that region.

Prisma Access Administrator’s Guide (Panorama Managed) 141 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Click the tabs below the map to see additional information about the service connections.
Status tab:
• Location—The location where your service connection is deployed.
• Remote Peer—The corporate location to which this s service infrastructure is setting up an
IPSec tunnel.

Prisma Access Administrator’s Guide (Panorama Managed) 142 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

• Allocated Bandwidth—The number of service connections you have allocated multiplied by

300 Mbps.
This number does not reflect the available service connection bandwidth.

While each service connection provides approximately 1 Gbps of throughput, the

actual throughput is dependent on several factors, including:
• Traffic mix (for example, frame size)
• Latency and packet loss between the service connection and the headquarters
location or data center
• Service provider performance limits
• Customer termination device performance limits
• Other customer data center traffic
• ECMP—If you have equal cost multipath (ECMP) configured for this service connection. Since
ECMP is not used for service connections, this status is Disabled.
• Config Status—The status of your last configuration push to the service. If the local
configuration and the configuration in the cloud match, the Config Status is In sync. If you have
made a change locally, and not yet pushed the configuration to the cloud, this may display
the status Out of sync. Hover over the status indicator for more detailed information. After
committing and pushing the configuration to Prisma Access, the Config Status changes to In
sync.
• BGP Status—Displays information about the BGP state between the firewall or router at
your corporate/headquarters location and Prisma Access where the service connection is
established. Although you might temporarily see the status pass through the various BGP
states (Idle, Active, Open send, Open pend, Open confirm, most commonly, the BGP status
shows:
• Connect—The router at your data center/headquarters is trying to establish the BGP peer
relationship with Prisma Access.
• Established—The BGP peer relationship has been established.
This field will also show if the BGP connection is in an error state:
• Warning—There has not been a BGP status update in more than eight minutes. This may
indicate an outage on the firewall.
• Error—The BGP status is unknown.
• Tunnel Status—The operational status of the connection between Prisma Access and your
service connection.
Statistics tab:
• Location—The location where your service connection is deployed.
• Remote Peer—The corporate location to which the service connection is setting up an IPSec
tunnel.
• Ingress Bandwidth (Mbps)—The bandwidth from the HQ/data center location to Prisma
Access.

Prisma Access Administrator’s Guide (Panorama Managed) 143 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

• Ingress Peak Bandwidth (Mbps)—The peak load from the HQ/data center location into the
cloud service.
• Egress Bandwidth (Mbps)—The bandwidth from Prisma Access into the HQ/data center
location.
• Egress Peak Bandwidth (Mbps)—The peak load from Prisma Access into the HQ/data center
location.
• QoS—Select this button to display a graphic chart that shows a real-time and historical QoS
statistics, including the number of dropped packets per class. This chart displays only for
service connections or remote network connections that have QoS enabled.
If you configured BGP, you can check its status by selecting Panorama > Cloud Services > Status
> Network Details > Service Connection > Show BGP Status.

The BGP Status dialog displays. This table provides you with the following information:
• Peer—Routing information for the BGP peer, including status, total number of routes,
configuration, and runtime statistics and counters. The total number of routes display in the
bgpAfiIpv4-unicast Counters area, in the Incoming Total and Outgoing Total fields.

• Local RIB—BGP routes that Prisma Access uses locally. Prisma Access selects this information
from the BGP RIB-In table, which stores the information sent by neighboring networking

Prisma Access Administrator’s Guide (Panorama Managed) 144 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

devices, applies local BGP import policies and routing decisions, and stores the Local RIB
information in the Routing Information Base (RIB).
Note that only the first 256 entries are shown. To view additional entries, enter a subnet or IP
address in the Filter field and click Apply Filter to view a subset of the routing entries up to a
maximum of 256.

• RIB Out—Routing information that Prisma Access advertises to its peers through BGP update
messages. See How BGP Advertises Mobile User IP Address Pools for an example of this table.

Create a Service Connection to Enable Access between Mobile

Users and Remote Networks
Even if you don’t need to access resources at your organization’s HQ or data center, you still need
to configure a service connection to allow network communication between mobile users and
remote network locations and between mobile users in different geographical locations.
Create this type of service connection for the following environments:
• Your deployment includes both remote networks and mobile users and you do not already
have a service connection configured.
• You have mobile users in different geographical areas who need direct access to each other’s
endpoints.
• You have already configured a service connection, but the existing service connection is not in
an ideal location between the remote networks and mobile users.
All remote network locations communicate to each other in a mesh network. Mobile users
connect to remote networks using the service connection in a hub-and-spoke network. In
some cases, it might improve network efficiency to place another service connection closer to
the remote network or networks that the mobile users most frequently access.
To configure a service connection to connect mobile users and remote networks, Add a service
connection using the following values:
• Specify a Region that is close to your mobile users.
• Add an IPSec Tunnel and IKE Gateway, using placeholder values.
• Add placeholder Corporate Subnets.
Since Prisma Access doesn’t route any traffic through this tunnel, any value that does not
conflict or overlap with other configured subnets is valid.
The following example shows a Prisma Access deployment with mobile users in different
geographical areas and remote networks. The remote network connections are connected in a
mesh network in the Prisma Access infrastructure, but the mobile users cannot connect to the
remote networks. In addition, the mobile users in different geographic areas cannot connect to
each other without a service connection.

Prisma Access Administrator’s Guide (Panorama Managed) 145 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

After you add a service connection, the service connection connects the mobile users and the
remote networks in a hub-and-spoke network.

Another case where a service connection of this type is useful is when the service connection is
far from the mobile users. The following figure shows an example of this network deployment.

Prisma Access Administrator’s Guide (Panorama Managed) 146 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Adding a second service connection that is closer to the mobile users creates a more efficient
network between the mobile users and remote networks.

Prisma Access Administrator’s Guide (Panorama Managed) 147 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Prisma Access Locations

The following topics show the Prisma Access locations by compute location and by region.
When you onboard service connections or remote network connections, the locations appear
alphabetically in the drop-down. When you onboard mobile users, the locations are sorted by
region. If you are in North America, we provide a Map of North America Prisma Access Locations
you can use as a reference.
Explicit Proxy supports a subset of these Prisma Access locations.
• Prisma Access Locations by Compute Location
• Prisma Access Locations by Region
• Map of North America Prisma Access Locations
• Explicit Proxy Locations

Prisma Access Locations by Compute Location

Locations denoted with two asterisks (**) are Local Zones, which do not support all Prisma Access
functionality.

Compute Location Prisma Access Location

Asia Northeast Japan Central

Asia South Bangladesh

India South
India West
Pakistan South
Pakistan West

Asia Southeast (Indonesia) Indonesia

Asia Southeast (Singapore) Cambodia

Malaysia
Myanmar
Pakistan West (II)
Philippines
Singapore
Sri Lanka
Thailand
Vietnam

Prisma Access Administrator’s Guide (Panorama Managed) 148 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Compute Location Prisma Access Location

Australia South Australia South

Australia Southeast Australia East

Australia Southeast
New Zealand
Papua New Guinea

Australia West (Perth)** Australia West (Perth)**

Bahrain Bahrain

Belgium Belgium
Latvia
Senegal

Canada Central (Montreal) Canada East

Canada Central (Toronto) Canada Central

Europe Central Austria

Bulgaria
Croatia
Czech Republic
Egypt
Germany Central
Germany North
Germany South
Greece
Hungary
Kuwait
Liechtenstein
Luxembourg
Moldova
Nigeria
Romania
Saudi Arabia
Slovakia

Prisma Access Administrator’s Guide (Panorama Managed) 149 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Compute Location Prisma Access Location

Slovenia
South Africa Central
Turkey
Ukraine
Uzbekistan

Europe Central (Warsaw) Poland

Europe North Belarus

Finland
Kazakhstan
Lithuania
Norway
Russia Central
Russia Northwest

Europe North (Stockholm) Sweden

Europe Northwest United Kingdom

Ghana

Europe Northwest (Paris) France South

Europe South Italy

Jordan
Kenya
Monaco

Europe Southwest Andorra

Portugal
Spain Central
Spain East

Europe West Denmark

Netherlands Central
Netherlands South

France North France North

Prisma Access Administrator’s Guide (Panorama Managed) 150 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Compute Location Prisma Access Location

Hong Kong Hong Kong

India North India North

Ireland Ireland

Japan South Japan South

Middle-East Central (Qatar) Qatar

Middle-East Central (UAE) United Arab Emirates

Middle-East West Israel

Nigeria (Lagos)** Nigeria (Lagos)**

New Zealand (Auckland)** New Zealand (Auckland)**

South Africa West South Africa West

South America East Brazil Central

Brazil East
Brazil South
Paraguay
Venezuela

South America West Argentina

Bolivia
Chile
Peru
Uruguay

South America West (Lima)** South America West (Lima)**

South Korea South Korea

Switzerland Switzerland
Uganda

Taiwan Taiwan

US Central US Central

Prisma Access Administrator’s Guide (Panorama Managed) 151 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Compute Location Prisma Access Location

US-Central (Chicago)** US-Central (Chicago)**

US Central West US Central West

US East US East
US Northeast
Guatemala

US Northwest Canada West

US Northwest

US South Mexico Central

Mexico West
US South

US Southeast Colombia
Costa Rica
Ecuador
Panama
US Southeast

US Southeast (Miami)** US Southeast (Miami)**

US Southwest US Southwest
US West

Prisma Access Locations by Region

Locations

Africa Region

Kenya

Nigeria

South Africa Central

South Africa West

Asia Region

Prisma Access Administrator’s Guide (Panorama Managed) 152 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Locations

Bangladesh

Cambodia

Hong Kong

India North

India South

India West

Indonesia

Malaysia

Myanmar

Pakistan South

Pakistan West

Pakistan West (II)

Papua New Guinea

Philippines

Singapore

South Korea

Sri Lanka

Taiwan

Thailand

Vietnam

ANZ Region

Australia East

Australia South

Australia Southeast

New Zealand

Prisma Access Administrator’s Guide (Panorama Managed) 153 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Locations

Europe Region

Andorra

Austria

Belarus

Belgium

Bulgaria

Croatia

Czech Republic

Denmark

Finland

France North

France South

Germany Central

Germany North

Germany South

Greece

Hungary

Ireland

Italy

Liechtenstein

Lithuania

Luxembourg

Moldova

Monaco

Netherlands Central

Prisma Access Administrator’s Guide (Panorama Managed) 154 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Locations

Netherlands South

Norway

Poland

Portugal

Romania

Russia Central

Russia Northwest

Slovakia

Slovenia

Spain Central

Spain East

Sweden

Switzerland

UK

Ukraine

Uzbekistan

Japan Region

Japan Central

Japan South

Middle East Region

Bahrain

Egypt

Israel

Jordan

Kuwait

Prisma Access Administrator’s Guide (Panorama Managed) 155 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Locations

Saudi Arabia

Turkey

United Arab Emirates

North America Region

Canada Central

Canada East

Canada West

Costa Rica

Mexico Central

Mexico West

Panama

US Central

US East

US Northeast

US Northwest

US South

US Southeast

US Southwest

US West

South America Region

Argentina

Bolivia

Brazil Central

Brazil East

Brazil South

Prisma Access Administrator’s Guide (Panorama Managed) 156 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Locations

Chile

Colombia

Ecuador

Paraguay

Peru

Venezuela

Map of North America Prisma Access Locations

Use the following map as a reference to assist you when choosing Prisma Access locations in
North America.

Prisma Access Administrator’s Guide (Panorama Managed) 157 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Explicit Proxy Locations

Prisma Access supports the following locations for explicit proxy. Explicit Proxy uses GeoDNS to
resolve and connect the mobile user to the closest Prisma Access deployed location.
• Africa, Europe & Middle East:
• Belgium
• Finland
• France South
• Germany Central
• Israel
• Italy
• Netherlands Central
• Poland
• Qatar
• Spain Central
• Switzerland
• UK
• Asia, Australia & Japan:
• Australia South
• Australia Southeast
• Hong Kong
• Japan Central
• Japan South
• India North
• India West
• Indonesia
• Singapore
• South Korea
• Taiwan

Prisma Access Administrator’s Guide (Panorama Managed) 158 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

• North America & South America:

• Brazil South
• Chile
• Canada Central
• Canada East
• US Central
• US East
• US Northwest
• US South
• US Southeast
• US Southwest
• US Central West

Prisma Access Administrator’s Guide (Panorama Managed) 159 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prepare the Prisma Access Infrastructure and Service Connections

Prisma Access Administrator’s Guide (Panorama Managed) 160 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users
Securing mobile users from threats and risky applications is often a complex mix of procuring
and setting up the security and IT infrastructure and then ensuring bandwidth and uptime
requirements in multiple locations around the globe while staying within your budget. Prisma
Access allow you to secure mobile users using GlobalProtect or an Explicit Proxy.
• Prisma Access Mobile User Deployments
• GlobalProtect on Prisma Access
• Explicit Proxy on Prisma Access
• IP Address Pools in a Mobile Users—GlobalProtect Deployment
• How the GlobalProtect App Selects a Prisma Access Location for Mobile Users
• Monitor and Log Out GlobalProtect Users in Prisma Access
• Manage GlobalProtect App Upgrades in Prisma Access
• Deploy Explicit Proxy and GlobalProtect or a Third-Party VPN in Prisma Access
• Integrate Prisma Access with On-Premises Gateways
• Manage Priorities for Prisma Access and On-Premises Gateways
• Allow Listing for Mobile Users—GlobalProtect Deployments
• Report Prisma Access Website Access Issues

161
Secure Mobile Users

Prisma Access Mobile User Deployments

Prisma Access offers two connection methods to secure mobile users; you can secure them using
GlobalProtect or secure them using an explicit proxy.
If you determine that your deployment would benefit by having some users connect using
GlobalProtect and some users connect using an Explicit Proxy, Prisma Access allows you to
distribute the users in your GlobalProtect for Users license between Mobile Users—GlobalProtect
and Mobile Users—Explicit Proxy.
• Secure Mobile Users with GlobalProtect—If your goal is to secure mobile users’ access to all
applications, ports, and protocols, and to get consistent security whether the user is inside or
outside your network, use Mobile Users—GlobalProtect. The GlobalProtect infrastructure is
deployed for you and scales based on the number of active users and their locations. After
you complete the configuration, users then connect to the closest Prisma Access gateway
(location) you have onboarded for policy enforcement. This enables you to enforce consistent
security for your users even in locations where you do not have a network infrastructure and
IT presence.
The GlobalProtect app installed on the users' endpoint secures users traffic to internet, SaaS
applications, your internal and public cloud resources.
• Secure Mobile Users with an Explicit Proxy—If your organization has designed its network
around an explicit proxy design, the explicit proxy connect method will help you quickly
replace the existing method and move to the Prisma Access Secure Access Service Edge (SASE)
solution. You can then send internet and external SaaS application traffic to the Prisma Access
infrastructure and enforce security in the cloud.
With an explicit proxy, you configure a proxy URL and a Proxy Auto-Configuration (PAC) file.
The GlobalProtect app is not required to be installed on the users’ endpoints.

Prisma Access Administrator’s Guide (Panorama Managed) 162 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

GlobalProtect on Prisma Access

GlobalProtect allows you to protect mobile users by installing the GlobalProtect app on their
endpoints and configuring GlobalProtect settings in Prisma Access. GlobalProtect allows you to
secure mobile users’ access to all applications, ports, and protocols, and to get consistent security
whether the user is inside or outside your network.
When you secure mobile users using GlobalProtect, you will need to define the settings to
configure the portal and gateways in the cloud. For example, you will define a portal hostname,
set up the IP address pool for your mobile users, and configure DNS settings for your internal
domains. You may be able to leverage using existing configurations for some of the required
settings, such as what authentication profile to use to authenticate mobile users. If you already
have a template with your authentication profiles, certificates, certificate profiles, and server
profiles, you can add that template to the predefined template stack during onboarding to simplify
the setup process.
While it is not necessary to push your Security policy settings and objects to Prisma Access
during the onboarding process, if you already have device groups and templates with the
configuration objects you need (for example, Security policy, zones, User-ID configuration, and
other policy objects) go ahead and add them when you onboard. This way you can to complete
the zone mapping that is required to enable Prisma Access to map the zones in your policy to the
appropriate interfaces and zones within the cloud. However, if you don’t have your policy set yet,
you can go back later and push it to Prisma Access for users.
In addition, 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, you must configure at least one service connection with placeholder values, even if
you don’t plan to use the connection to provide access to your data center or HQ locations. The
reason this is required is because, while all remote network locations are fully meshed, Prisma
Access gateways (also known as locations) connect to the service connection in a hub-and-spoke
architecture to provide access to the internal networks in your Prisma Access infrastructure.

Planning Checklist—GlobalProtect on Prisma Access

If you use GlobalProtect to secure mobile users, use the following checklist to ensure that you
will be able to successfully enable the service and enforce consistent policy for your mobile users
(protecting users with the GlobalProtect app installed on their endpoints and allowing users to
securely access applications using Clientless VPN).

Prisma Access Administrator’s Guide (Panorama Managed) 163 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

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.169.253, 169.254.169.254, 169.254.201.0/24, 169.254.202.0/24, 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 Panorama Managed Prisma Access. 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 Panorama Managed Prisma Access. Before you onboard your

Prisma Access Administrator’s Guide (Panorama Managed) 164 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

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 an 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

Prisma Access Administrator’s Guide (Panorama Managed) 165 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

issues, and generate troubleshooting and diagnostic logs to be sent to Cortex Data
Lake for further analysis. You need to generate a certificate so that the GlobalProtect
app can authenticate with Cortex Data Lake to collect the troubleshooting logs. This
functionality is under Panorama > Cloud Services > Configuration > Service Setup >
Generate 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.

IP Address Pools in a Mobile Users—GlobalProtect Deployment

Make sure that you have specified an IP address pool that allows enough coverage for the
mobile users in your organization. It is important to remember that each unique user can use
multiple devices to connect to Prisma Access at the same time, and each connected device
requires a unique IP address from the pool. The addresses in this pool must not overlap with other
address pools you use internally or with the IP subnet you assign when you Enable the Service
Infrastructure.
You can specify IP pools for all users in the world (Worldwide), per Prisma Access theater, or per
location group.
We recommend 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 your pool space is
limited, you can specify a smaller address pool; however, if your IP address pool reaches its limit,
additional mobile user devices will not be able to connect.
In Panorama, the UI validates that you enter valid IP subnets (for example, if you enter a pool with
a subnet of less than /23, it will prompt you to change it). However, it does not check to ensure
that you have allocated sufficient IP addresses for your deployment.

This validation is not available if you configure locations using CLI. If you deploy all
locations using CLI, we recommend that you add a /18 address in the Worldwide pool for
mobile users.

Prisma Access checks your configuration to make sure that you have specified the following
minimum IP address pool:
• A minimum of /23 (512 IP addresses) is required for either a Worldwide or regional address
pool.
• If you do not onboard any Prisma Access gateways in a region, an IP address pool for that
region is not required. For example, if you specify gateways in the US Northwest, US West,
and US Southwest locations, you need to only specify an IP address pool for the North America
& South America region. Conversely, if you enable mobile user locations in Europe without
specifying either a Worldwide address pool or the Africa, Europe, & Middle East theater, your
deployment will fail.

Prisma Access Administrator’s Guide (Panorama Managed) 166 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

• GlobalProtect mobile users consume the IP addresses in the location group first, then theater-
specific IP addresses, then Worldwide IP addresses. For example, if you specify a pool for a
location group and Worldwide, and you then exhaust the available IP addresses in the location
group pool, Prisma Access then takes IP addresses from the Worldwide pool to use in that
location group.
If you specify more than one block of IP address pools, Prisma Access uses the pools in the
order that you entered them during mobile user setup.

Set Up GlobalProtect on Panorama Managed Prisma Access

To configure a Mobile Users—GlobalProtect deployment, complete the following steps. Before
you begin, be sure that you understand how Prisma Access works and use the checklist to plan for
your GlobalProtect deployment.
STEP 1 | Select Panorama > Cloud Services > Configuration > Mobile Users—GlobalProtect.

STEP 2 | Configure the template stack and device group hierarchy that the cloud service will push to
the portal and gateway.
1. Edit the Settings.

2. In the Templates section of the Settings tab, Add the template that contains the
configuration you want to push to Prisma Access for users.

Although you can add existing templates to the stack from the plugin, you
cannot create a new template from the plugin. Instead, use the workflow to add
a new template.

You can Add more than one existing template to the stack and then order them
appropriately using Move Up and Move Down. This is important because Panorama
evaluates the templates in the stack from top to bottom and settings in templates that
are higher in the stack take priority over the same settings specified in templates that are
lower in the stack. You cannot move the default Mobile_User_Template from the top of

Prisma Access Administrator’s Guide (Panorama Managed) 167 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

the stack; this prevents you from overriding any settings that Prisma Access requires to
create the network infrastructure in the cloud.

If you want to customize the agent configuration that the Prisma Access for
users pushes to clients from the portal, you must edit the GlobalProtect Portal
configuration in the Mobile_User_Template to add a new agent configuration.
After configuring the Agent configuration, move it above the DEFAULT agent
configuration that is predefined in the template to ensure that your settings take
precedence over the default settings. When editing this template, do not remove
or change the External Gateway entry.

3. In the Device Group section, select the Parent Device Group that contains the
configuration settings you want to push to Prisma Access for users, or leave the parent
device group as Shared to use the Prisma Access device group shared hierarchy.
You will push all of the configuration—including the address groups, Security policy,
Security profiles, and other policy objects (such as application groups and objects), HIP
objects and profiles and authentication policy—that Prisma Access for users needs to
enforce consistent policy to your mobile users using the device group hierarchy you
specify here. In addition, you must make sure that you have configured a Log Forwarding
profile that forwards the desired log types to Panorama/Cortex Data Lake in a device

Prisma Access Administrator’s Guide (Panorama Managed) 168 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

group that gets pushed to Prisma Access for users; this is the only way that the cloud
service knows which logs to forward to Cortex Data Lake.
4. (Optional) If you have configured a next-generation firewall as a master device or added
a Cloud Identity Engine profile to make user and group information selectable in security
policies, select User-ID Master Device or Cloud Identity Engine; then, select either the
Master Device or the Cloud Identity Engine profile that you created.

STEP 3 | (Optional) Configure Prisma Access to use the Directory Sync component of the Cloud
Identity Engine to retrieve user and group information.
You must configure the Directory Sync component of the Cloud Identity Engine to retrieve
user and group information from cloud directory or Active Directory (AD) before you enable
and configure Directory Sync integration in Prisma Access Group Mapping Settings.

STEP 4 | Click OK to save the mobile user settings.

STEP 5 | Map the zones configured within the selected template stack as trusted or untrusted.
On a Palo Alto Networks next-generation firewall, Security policy is enforced between
zones, which map to physical or virtual interfaces on the firewall. However, with Prisma
Access for users, the networking infrastructure is automatically set up for you, which means

Prisma Access Administrator’s Guide (Panorama Managed) 169 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

you no longer need to configure interfaces and associate them with zones. However, to
enable consistent security policy enforcement, you must map the zones you use within your
organization as trust or untrust so that Prisma Access for users can translate the policy rules
you push to the cloud service to the internal zones within the networking infrastructure.
1. Edit the Zone Mapping settings.
By default, all of the zones in the Mobile_User_Template_Stack are classified as
Untrusted Zones.
2. For each zone you want to designate as trusted, select it and click Add to move it to the
list of Trusted Zones.

3. Click OK to save your changes.

STEP 6 | Configure the GlobalProtect portal and external gateway settings.

You can configure Prisma Access gateways as external gateways only—not as internal
gateways.
1. In the Onboarding section, click Configure.
2. On the General tab, specify the Portal Name Type:
• Use Default Domain—If you select this option, your portal hostname uses the default
domain name: .gpcloudservice.com. In this case, simply enter a Portal Hostname

Prisma Access Administrator’s Guide (Panorama Managed) 170 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

to append to the default domain name. Prisma Access for users will automatically
create the necessary certificates and publish the hostname to public DNS servers.

If you already have a GlobalProtect deployment with an existing portal name and
you want to continue to use that portal name, add a CNAME entry that maps Prisma
Access portal name to your existing portal name. For example, if you have an existing
portal named portal.acme.com and you want to map the new Prisma Access portal to
this same name, you would add a CNAME of gpcs2.gpcloudservice.com to the DNS
entry for your existing portal.

The *.gpcloudservice.com domain is associated with the Palo Alto Networks

application.
• Use Company Domain—Select this option if you want the domain in the
portal hostname to match your company domain name (for example,
myportal.mydomain.com). If you want to use this option, you must first obtain your
own certificate and configure an SSL/TLS service profile that points to it. Then you

Prisma Access Administrator’s Guide (Panorama Managed) 171 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

can configure the portal name by selecting the SSL/TLS Service Profile and entering
the Portal Hostname. If you use this option, you must point your internal DNS
servers to the Portal DNS CNAME, which is the hostname of the portal with the
.gpcloudservice.com domain. For example, if you specified a DNS hostname of

Prisma Access Administrator’s Guide (Panorama Managed) 172 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

acme-portal.acme.com, you would need to create a DNS CNAME entry that maps
that hostname to acme-portal.gpcloudservice.com on your internal DNS servers.

If you need to upload a new certificate, import the certificate and private key;
then, view the SSL/TLS service being used by Prisma Access under Network >
GlobalProtect > Portals > GlobalProtect_Portal > Authentication and check the
SSL/TLS Service Profile name. This field only displays if you are using a company
domain instead of the default domain. You can then select Device > Certificate
Management > SSL/TLS Certificate Profile and replace the certificate in the
SSL/TLS profile used by the portal with the certificate you imported.
3. Select an Authentication Profile that specifies how Prisma Access should authenticate
mobile users or create a new one.
If you added a parent device group that contains an authentication profile configuration,
you should see it on the list of available profiles. If you did not push the profile in the
device group, you can create an authentication profile now.

After you commit and push your changes, you cannot make any changes to the
authentication profile and authentication override certificate in this area and
the choices become read-only. To make changes after initial onboarding, modify
or add one or more GlobalProtect client authentication configurations under
the Mobile_User_Template.
4. Select an Authentication Override Certificate to encrypt the secure cookies that mobile
users authenticate to the portal and gateway.
If you added a parent device group that contains the certificate you want to use to
encrypt authentication cookies, you should see it on the list of available certificates. If
you did not push a certificate in the device group, you can import or generate one now.
5. (Optional) If you do not require GlobalProtect endpoints to have tunnel connections
when on the internal network, enable Internal Host Detection.
1. Select the Internal Host Detection check box.
2. Enter the IP Address of a host that users can reach only from the internal network.
3. Enter the DNS Hostname for the IP address you entered. Clients that try to connect
perform a reverse DNS lookup on the specified address. If the lookup fails, the client
determines that it needs a tunnel connection to Prisma Access for users.

Prisma Access copies the internal host detection settings you specify here to the
default agent settings in your GlobalProtect portal configuration (Network
> GlobalProtect > Portals > <portal-config> > Agent > DEFAULT > Internal).
If you have entered internal host detection settings for the default agent in
the GlobalProtect portal, you will not be able to change the options here and
must change it in the portal. If you require multiple agent configs, enter settings
for the default agent config in the GlobalProtect portal and use those settings
for Prisma Access, then select Network > GlobalProtect > Portals > <portal-
config> > Agent and Add a non-default config, and specify that config in other
parts of your deployment.
6. (Optional) To ensure that your mobile users have redundancy connectivity to the
services and applications that are accessible from service connections, Enable Network
Redundancy between the portals or gateways and service connections.

Prisma Access Administrator’s Guide (Panorama Managed) 173 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

If you have a Mobile Users–GlobalProtect deployment that includes service connections,

and are running a Cloud Services plugin version of 3.0 or later, Palo Alto Networks
recommends that, as a best practice, you create two service connections in two different
Prisma Access compute locations and enable Mobile User Regional Redundancy. This
change will improve your resiliency posture and will mitigate any outages that could
occur in the event of a tunnel failure between the GlobalProtect mobile user and service
connection dataplane.
7. (Optional) If your organization uses allow lists to control access to public or SaaS
applications, specify whether or not you are Using IP Allow Lists in SaaS Apps.
To enable you to add the public (egress) IP addresses for your GlobalProtect—
Mobile User deployment to any SaaS application allow lists you use within your
organization, Prisma Access provides you with the IP addresses and lets you verify that
you have added them to your allow list before using them in your environment. You
can implement allow listing for Prisma Access egress IP addresses for both existing
deployments and new deployments.
8. (Optional) Customize the GlobalProtect app settings (for example, specify the connect
method GlobalProtect uses) by selecting Network > GlobalProtect > Portals >
GlobalProtect_Portal > Agent, selecting the config you want to customize or selecting
DEFAULT, selecting App, then customizing the GlobalProtect app.

STEP 7 | Select the Locations and the regions associated with those locations where you want to
deploy your mobile users.
The Locations tab displays a map. Highlighting the map shows the global regions (Americas,
Europe, and Asia Pacific) and the locations available inside each region. Select a region, then
select the locations you want to deploy in each region. Limiting your deployment to a single
region provides more granular control over deployed regions and allows you to exclude regions
as required by your policy or industry regulations. See Prisma Access Locations for the list of

Prisma Access Administrator’s Guide (Panorama Managed) 174 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

regions and locations. You can select a location in a region that is closest to your mobile users,
or select a location as required by your policy or industry regulations.

Prisma Access uses the Hong Kong, Netherlands Central, and US Northwest locations
as fallback mobile user locations if other locations are not available. For this reason,
Palo Alto Networks strongly recommends that you enable at least one of these
locations during mobile user onboarding.

1. Click the Locations tab and select a region.

2. Select one or more Prisma Access gateways within your selected region using the map.
Hovering your cursor over a location highlights it. White circles indicate an available
location; green circles indicate that you have selected that location.

Prisma Access Administrator’s Guide (Panorama Managed) 175 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

In addition to the map view, you can view a list of regions and locations. Choose
between the map and list view from the lower left corner. In the list view, the list

Prisma Access Administrator’s Guide (Panorama Managed) 176 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

displays regions sorted by columns, with all locations sorted by region. You can select All
sites within a region (top of the dialog).

STEP 8 | Set up the IP address pools used to assign IP addresses to GlobalProtect endpoints by
selecting the IP Pools tab and Add an IP address pool.
1. Specify a Region for the IP address pool.
You can use a single IP address pool for all GlobalProtect endpoints in the world
(Worldwide), you can use separate pools for each theater where you have mobile users,
or you can specify pools per location group (a group of locations that is smaller than the
theater). You can also specify a combination of worldwide, per-theater, or per-location
group IP pools. For example, you could add a pool for a specific location group and then
add a Worldwide pool to use for all other locations.
Use location group-specific IP address pools if you have services that depend on the
source IP address of the user to identify the user’s details (such as location-based
services or services based on a user group or function) so you can apply access control
policies, or to perform routing or policy operations on different countries if the countries

Prisma Access Administrator’s Guide (Panorama Managed) 177 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

are in different compute regions. For example, you could use a separate IP address
pool for Canada and one for Brazil, which are in different compute locations, to provide
distinct access and security controls.

To use location group-specific IP address pools, you must also specify a

Worldwide or theater-specific pool.

GlobalProtect mobile users consume the IP addresses in the location group first, then
theater-specific IP addresses, then Worldwide IP addresses. For example, if you specify
a pool for a location group and Worldwide, and you then exhaust the available IP
addresses in the location group pool, Prisma Access then takes IP addresses from the
Worldwide pool to use in that location group.
• To specify IP pools that can be used by all GlobalProtect mobile users, select
Worldwide.
• To specify IP pools that can be used by GlobalProtect users in a specific theater,
select the theater.
• To specify IP pools that are specific to the location group, select it from the list.

2. Enter an IP Pool to assign to the endpoints in the region you selected.

• Enter a minimum required subnet of /23 (512 IP addresses) per location. Additional
locations require a minimum /23 subnet. If you specify a Worldwide subnet, the
minimum required subnet is /23 but we recommend providing enough subnets to

Prisma Access Administrator’s Guide (Panorama Managed) 178 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

allocate a of IP addresses that is equal to or greater than the number of licensed

mobile users so that they can log in at the same time.
Do not specify addresses that overlap with other networks you use internally or with
the pools you assigned when you Enable the Service Infrastructure. In addition, do
not use the following IP addresses and subnets, because Prisma Access reserves
those IP addresses and subnets for its internal use:
169.254.169.253, 169.254.169.254, 169.254.201.0/24, 169.254.202.0/24, and
100.64.0.0/10.

We recommend using an RFC 1918-compliant IP address pool. While we

support the use of non-RFC 1918-compliant (public) IP addresses for mobile
users, we do not recommend using them due to possible conflicts with
internet public IP address space.

STEP 9 | To specify the DNS resolution settings for your internal and external (public) domains, select
Network Services tab and Add the settings.
GlobalProtect endpoints with an active tunnel connection use their virtual network adapters
rather than their physical network adapters and therefore require separate DNS resolution
settings.
Configure network settings in the Network Services window.
• Select a Region from the drop-down.
Select Worldwide, select a theater, or select a location group to apply the DNS settings
globally. If you specify multiple proxy settings with a mix of Worldwide, theater, and

Prisma Access Administrator’s Guide (Panorama Managed) 179 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

location group-specific settings, Prisma Access uses the settings for the location group, then
theater, then Worldwide. Prisma Access evaluates the rules from top to bottom in the list.
• Add one or more rules to configure the DNS settings for Internal Domains.
• Enter a unique Rule Name for the rule.
• you want your internal DNS server to only resolve the domains you specify, enter the
domains to resolve in the Domain List. Specify an asterisk in front of the domain; for
example, *.acme.com. You can specify a maximum of 1,024 domain entries.

Prisma Access has a predefined rule to resolve *.amazonaws.com domains using

the Cloud Default server. If you want your internal DNS servers to resolve a
more-specific *.amazonaws.com domain (for example, *.s3.amazonaws.com),
enter the URL in the Domain List. Prisma Access evaluates the domain names
from longest to shortest, then from top to bottom in the list.
• If you have a Custom DNS server that can access your internal domains, specify the
Primary DNS and Secondary DNS server IP addresses, or select Use Cloud Default to
use the default Prisma Access DNS server.
• Specify the DNS settings for Public Domains.
• Use Cloud Default—Use the default Prisma Access DNS server.
• Same as Internal Domains—Use the same server that you use to resolve internal
domains. When you select this option, the DNS Server used to resolve public domains is
same as the server configured for the first rule in the Internal Domains section.
• Custom DNS server—If you have a DNS server that can access your public (external)
domains, enter the Primary DNS server address in that field.
(Optional) You can Add a DNS Suffix to specify the suffix that the client should use locally
when an unqualified hostname is entered that it cannot resolve, for example, acme.local. Do

Prisma Access Administrator’s Guide (Panorama Managed) 180 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

not enter a wildcard (*) character in front of the domain suffix (for example, acme.com). You
can add multiple suffixes.
• If you want Prisma Access to proxy DNS requests, configure values for UDP queries (the
Interval to retry the query in seconds and the number of retry Attempts to perform.
For more information about how Prisma Access proxies DNS requests, see DNS Resolution
for Mobile Users—GlobalProtect Deployments.

STEP 10 | (Optional) If your deployment uses Windows Internet Name Service (WINS) based, you can
specify WINS servers to resolve NetBIOS name-to-IP address mapping by selecting WINS
Configuration; selecting a region for the WINS server or selecting Worldwide to apply the
WINS configuration worldwide, then specifying a Primary WINS and, optionally, Secondary
WINS server address.
After you enable WINS, Prisma Access can push WINS configuration to mobile users’
endpoints over GlobalProtect.

STEP 11 | (Optional) Select Advanced RCODE Support to allow the primary DNS server to fail over to
the secondary DNS server if an RCODE 2 (SERVFAIL) and RCODE 5 (REFUSED) DNS return
code is received.
A DNS response code of SERVFAIL refers to a communication error with the primary DNS
server, and a DNS response code of REFUSED means that the primary DNS server refused to

Prisma Access Administrator’s Guide (Panorama Managed) 181 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

provide the requested information. In both cases, the service fails over to the secondary DNS
server.

Prisma Access Administrator’s Guide (Panorama Managed) 182 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 12 | (Optional) If you allow your mobile users to manually select gateways from the GlobalProtect
app, select the Manual Gateway Locations that the users can view from their GlobalProtect
app.
Choosing a subset of onboarded locations reduces the number of available gateways that
mobile users can view in their GlobalProtect app for manual gateway selection.
If you do not select manual gateways in this tab, Prisma Access selects the following list of
gateways by default.
• Australia Southeast
• Belgium
• Brazil South
• Canada East
• Finland
• France North
• Germany Central
• Hong Kong
• India West
• Ireland
• Israel
• Japan Central
• Netherlands Central
• Saudi Arabia
• Singapore
• South Africa Central
• South Korea
• Taiwan
• UK
• US East
• US West
Prisma Access lets you select only gateways that you have onboarded. For example, if you
don’t choose UK when you select locations, you cannot select UK as a manual gateway (the
location is grayed out).

Prisma Access Administrator’s Guide (Panorama Managed) 183 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

If you need to delete a location after you onboard it, and it is selected as one of the
Manual Gateway Locations, be sure to deselect it here as well as in the Locations tab.

STEP 13 | Click OK to save the Onboarding settings.

STEP 14 | Configure IPv6 Availability options.

If you use IPv6 networking in your Mobile Users—GlobalProtect deployment, you can
configure Prisma Access to use IPv6 addresses in your mobile user networking. You also need
to enable IPv6 networking globally in your Prisma Access infrastructure before you can use
IPv6 addressing.

Prisma Access Administrator’s Guide (Panorama Managed) 184 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 15 | (Optional, Windows and macOS only) Exclude video traffic from the GlobalProtect tunnel.
Exclude video traffic from the tunnel; then, Add or Delete video streaming applications that
you want to exclude from the GlobalProtect tunnel.

STEP 16 | Create security policy rules to secure traffic for your mobile users.
1. Select the Device Group in which to add policy rules. You can select the
Mobile_User_Device_Group or the parent device group that you selected when setting
up Prisma Access for mobile users.
2. Create security policy rules. Make sure that you do not define security policy rules to
allow traffic from any zone to any zone. In the security policy rules, use the zones that
you defined in the template stack you are pushing to the cloud service.

Prisma Access Administrator’s Guide (Panorama Managed) 185 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 17 | Configure logs to forward to Cortex Data Lake.

The Cloud Services plugin automatically adds the following Log Settings (Device > Log
Settings) after a new installation or when removing non-Prisma Access templates from a
Prisma Access template stack:
• Log Settings for System logs (system-gpcs-default), User-ID logs (userid-gpcs-default), HIP
Match logs (hipmatch-gpcs-default), and GlobalProtect logs (gp-prismaaccess-default) are
added to the Mobile_User_Template.
• Log Settings for System logs (system-gpcs-default), User-ID logs (userid-gpcs-default), and
GlobalProtect logs (gp-prismaaccess-default) are added to the Remote_Network_Template.
• Log Settings for System logs (system-gpcs-default) and GlobalProtect logs (gp-
prismaaccess-default) are added to the Service_Conn_Template.
These Log Setting configurations automatically forward System, User-ID, and HIP Match logs
to Cortex Data Lake.

STEP 18 | (Optional) Forward logs for other log types to Cortex Data Lake.
To do this, you must create and attach a log forwarding profile to each policy rule for which
you want to forward logs.
1. Select the Device Group in which you added the policy rules.
2. Select Objects > Log Forwarding and Add a profile. In the Log Forwarding Profile Match
List, Add each log type that you want to forward.
The following example enables forwarding of Traffic, Threat Prevention, WildFire
Submission, URL Filtering, Data Filtering, and Authentication logs.
3. Select Panorama/Cortex Data Lake as the Forward Method. When you select Panorama,
the logs are forwarded to Cortex Data Lake. You will be able to monitor the logs and
generate reports from Panorama. Cortex Data Lake provides a seamless integration to
store logs without backhauling them to your Panorama at the corporate headquarters,
and Panorama can query Cortex Data Lake as needed.

4. Select Policies > Security and edit the policy rule. In Actions, select the Log Forwarding
profile you created.

Prisma Access Administrator’s Guide (Panorama Managed) 186 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 19 | Commit all your changes to Panorama and push the configuration changes to Prisma Access.
1. Click Commit > Commit and Push.
2. Edit Selections and, in the Prisma Access tab, make sure that Mobile Users is selected in
the Push Scope, then click OK.

3. Click Commit and Push.

Prisma Access Administrator’s Guide (Panorama Managed) 187 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 20 | To verify that Prisma Access for users is deployed and active, select Panorama > Cloud
Services > Status > Status.
After the provisioning completes, the mobile users Status and Config Status should show OK.
The Deployment Status area allows you to view the progress of onboarding and deployment
jobs before they complete, as well as see more information about the status of completed jobs.
See Prisma Access Deployment Progress and Status for details.

To view the number of unique users who are currently logged in, or to log out a logged in user,
click the hyperlinked number next to Current Users.

Prisma Access Administrator’s Guide (Panorama Managed) 188 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

To view historical information of previously-logged in users for a 90-day time period, click the
number next to Users (Last 90 days).
When the number of users in the Users (Last 90 days) field reaches 80% of the total licensed
number, the number displays in a red color.
To export the list of users to a csv file, select Export to CSV. Note that a maximum of 45,000
users can be exported to a CSV file.

Prisma Access Administrator’s Guide (Panorama Managed) 189 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

To display a map that shows the locations of Prisma Access portals and gateways running in
the regions you have selected, select Monitor; then, select Mobile Users.

Prisma Access Administrator’s Guide (Panorama Managed) 190 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Select a region to get more detail about that region.

• Location—The location where your cloud service infrastructure is deployed to secure
mobile users on your network.

Prisma Access Administrator’s Guide (Panorama Managed) 191 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

• Current Users—The number of users who are connected and being secured by the service.
When the current mobile user count reaches 80% of its total licensed number, this number
displays in red.
• Peak Users—The count for the maximum number of concurrent users.
• Peak Users Timestamp—The timestamp when the Peak Users data was last retrieved.
• Status—The operational status of the connection between Prisma Access and your mobile
users.
• Config Status—The status of your last configuration push to the service. If you have made
a change locally, and not yet pushed the configuration to the cloud, this may display the
status Out of sync. Hover over the status indicator for more detailed information. After

Prisma Access Administrator’s Guide (Panorama Managed) 192 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

committing and pushing the configuration to Prisma Access, the Config Status changes to In
sync.

STEP 21 | If you chose to Use Company Domain for your portal hostname, you must add a DNS entry
on your internal DNS servers to map the portal hostname you defined to the Portal DNS
CNAME displayed on the Cloud Services > Configuration > Mobile Users > Onboarding >
General tab (for example, <portal_hostname>.gpcloudservice.com).

Prisma Access Administrator’s Guide (Panorama Managed) 193 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 22 | Deploy the GlobalProtect app software to your end users.

For Mac OS or Windows users, you can direct users to the Prisma Access portal address,
where they can download the GlobalProtect app from the portal.

Prisma Access manages the version of the GlobalProtect app on the portal and you
can select the active version from the versions that Prisma Access hosts, as well as
control the ability of users to download it.

Alternatively, you can host GlobalProtect app software on a web server for your Mac OS and
Windows users. Prisma Access is compatible with any GlobalProtect app versions that are not
listed as end of life.
Mobile app users can download and install the GlobalProtect mobile app from the appropriate
app store for their operating systems.

Enable Mobile User Regional Redundancy

To ensure that your mobile users always have access to the services and applications that
are accessible from service connections, enable network redundancy between the portals or
gateways and service connections. This feature provides redundant network paths between
the mobile user dataplane and service connections in different compute locations. Enabling
redundancy provides users with more resilient access to resources behind service connections in
a data center or headquarters locations. Because a service connection is required for mobile users
to access resources from remote networks, users also have more resiliency in accessing resources
in remote network locations.
STEP 1 | Create at least two service connections in different Prisma Access locations that map to
unique compute locations.
We recommend you to have multiple service connections to ensure there are alternate paths
to the data center if the connectivity through one of the Prisma Access locations fails.

STEP 2 | Enable asymmetric routing with load sharing across service connections in your backbone
routing options to choose the best alternate route in case of connectivity failure.

Prisma Access Administrator’s Guide (Panorama Managed) 194 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 3 | Select the Enable Network Redundancy check box when you onboard mobile users.
If you have already onboarded mobile users, edit the configuration settings in the Onboarding
section.
1. Select Panorama > Cloud Services > Configuration > Mobile Users - GlobalProtect.
2. Select the hostname in the Onboarding section.
3. Select the Enable Network Redundancy check box.
4. Click OK.

STEP 4 | Commit all your changes to Panorama and push the configuration changes to Prisma Access.
1. Click Commit > Commit and Push.
2. Edit Selections and, in the Prisma Access tab, make sure that Mobile Users is selected in
the Push Scope, then click OK.
3. Click Commit and Push.

Prisma Access Administrator’s Guide (Panorama Managed) 195 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

How the GlobalProtect App Selects a Prisma Access

Location for Mobile Users
When a mobile user connects to a Prisma Access location, the GlobalProtect app uses the
following selection process to determine the location to which it connects.

You enable the mobile user locations where you want Prisma Access to be present during
mobile user onboarding. If you do not select the location during onboarding, Prisma
Access does not use it in your deployment.

• If the mobile user connects in a country that has a Prisma Access location, the user connects to
the location in that country.
• If the mobile user cannot connect to an in-country location for any reason, Prisma Access
selects from one of the following mobile user locations to connect the user based on region.
• Asia, Australia & Japan: Hong Kong, Japan Central, or Japan South
• Africa, Europe & Middle East: Netherlands Central
• North America & South America: US Northwest
Palo Alto Networks recommends that you enable at least one of these locations in their
respective regions during mobile user onboarding to provide redundancy. If you have mobile
users who connect to Prisma Access from a country that does not have a Prisma Access
location, you must enable at least one of the fallback locations in the preceding list.
The Hong Kong, Japan Central, Japan South, Netherlands Central, and US Northwest locations
can accept client connections from anywhere and are known as global fallback locations. In
addition to these locations, you can enable one or more of the following locations which also
act as global fallback locations:
• Bahrain
• France North
• Ireland
• South Africa West
• South Korea
• Palo Alto Networks recommends that you enable locations in more than one compute location
for redundancy purposes.
• If you use on-premises gateways with Prisma Access locations, you can specify priorities in
Prisma Access to let mobile users connect to either a specific on-premises GlobalProtect
gateway or a Prisma Access location.
• When mobile users connect, the GlobalProtect app does not use the following Prisma Access
locations in the automatic gateway selection process, even if you selected the Prisma Access
locations in the plugin during onboarding. However, mobile users can still manually select one

Prisma Access Administrator’s Guide (Panorama Managed) 196 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

of these locations and set it as a preferred location (gateway) as long as you allow them to
manually select those locations during mobile user onboarding:
• Australia: Australia East
• Brazil: Brazil East and Brazil Central
• France: France South
• Germany: Germany North and Germany South
• India: India South
• Mexico: Mexico West
• Netherlands: Netherlands South
• Pakistan: Pakistan West
• Russia: Russia Northwest
• Spain: Spain East

You might have to change your Connect Method to On-Demand for the mobile user to
manually connect to a gateway.

Prisma Access Administrator’s Guide (Panorama Managed) 197 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Explicit Proxy on Prisma Access

In addition to securing mobile users with GlobalProtect, you can configure an Explicit Proxy using
Prisma Access. Explicit Proxy uses a PAC file that instructs a web browser to forward traffic to the
web proxy server instead of the destination server, and protects your web-based internet (HTTP
and HTTPS) traffic.
Prisma Access provides a complete cloud Secure Web Gateway (SWG) capability, including an
Explicit Proxy connection method based in the cloud. If you have existing PAC files, you can use
them with Prisma to leverage your existing PAC files, simplifying the onboarding experience for
customers migrating from legacy proxy-based SWG solutions. You can also use an Explicit Proxy if
you need to use a proxy for auditing or compliance purposes.
Over time, you can transition to a more secure connection method in Prisma Access that secures
all ports and protocols, not just web-based internet traffic.

How Explicit Proxy Works in Prisma Access

The following section shows the workflow when mobile users are secured by Prisma Access using
an Explicit Proxy as the connection method. Before you start, you need to have configured Prisma
Access Explicit Proxy.
The traffic takes the following path. Callouts in the figure show the process.

STEP 1 | The mobile user browses the Internet or accesses the SaaS application by entering the URL
or IP address using a web browser.

STEP 2 | The browser on the mobile users’ endpoint checks for the PAC file.
This PAC file specifies that the URL or SaaS request should be forwarded to Prisma Access
Explicit Proxy.

STEP 3 | The HTTPS client (the browser on the mobile user’s endpoint) forwards the URL request to
the proxy URL.

STEP 4 | The traffic is redirected to Explicit Proxy, and the proxy decrypts the traffic.

Prisma Access Administrator’s Guide (Panorama Managed) 198 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 5 | The proxy inspects the traffic and checks for the authentication cookie set up by the Prisma
Access Explicit Proxy.
The cookie contains information that identifies the mobile user, and uses the cookie to
authenticate the user.

STEP 6 | If, upon inspection of the cookie, Prisma Access determines that the user has not been
authenticated, it redirects the user for authentication.

STEP 7 | After the IdP authenticates the user, Prisma Access stores the authentication state of the
user in the Authentication Cache Service (ACS). The validity period of the authentication is
based on the Cookie Lifetime value you specify during Explicit Proxy configuration.

STEP 8 | The Explicit Proxy checks for the presence and validity of our cookie. If the cookie is not
present or is invalid, the user is redirected to ACS. After ACS confirms the authentication of
the user, the user is redirected back to Explicit Proxy with a token. The proxy then validates
that token and sets the cookie for that domain for that user.

STEP 9 | Prisma Access applies security enforcement based on the security policy rules that the
administrator has configured.

STEP 10 | If the URL is not blocked by security policy rules, Prisma Access sends the URL request to
the internet.

How Explicit Proxy Identifies Users

Explicit Proxy identifies users in the traffic logs dependent on how the users authenticate with the
proxy, as shown in the following table.

Authentication Type User Identification in Traffic Logs

Users that are logged in using SAML The username.

authentication and decryption

Users that are logged in from another proxy XAU header information.
that uses X-Authenticated-User (XAU)
Explicit Proxy only allows traffic from specific
headers
IP addresses to use XAU for authentication.
You create an address object and specify
the IP addresses where you allow XAU for
authentication; then, add the address object
in the Trusted Source Address field during
Explicit Proxy setup.

Authenticated cross-origin resource sharing The swg-authenticated-ip-user user.

(CORS) requests
To help identify traffic that is coming from
authenticated users in cases where browsers
cannot send cookies or perform authentication
redirection, such as CORS requests, Explicit

Prisma Access Administrator’s Guide (Panorama Managed) 199 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Authentication Type User Identification in Traffic Logs

Proxy adds the swg-authenticated-ip-
user to the traffic logs.

Undecrypted traffic (if you have allowed The swg-authenticated-ip-user user.

Explicit Proxy to allow undecrypted traffic
You can specify Explicit Proxy to allow
from IP addresses where users have
undecrypted traffic from IP addresses
previously authenticated)
where users have authenticated; to do so,
specify Decrypt traffic that matches existing
decryption rules; for undecrypted traffic,
allow traffic only from known IPs registered
by authenticated users when you configure
Explicit Proxy. In these configurations, Explicit
Proxy adds the swg-authenticated-ip-
user to the traffic logs.

Planning Checklist—Explicit Proxy

Before you secure mobile users with an Explicit Proxy, make sure that you are aware of the
software and network requirements described in this section.
Onboarding Guidelines—Use the following guidelines when you license and onboard your Explicit
Proxy deployment:
• Explicit Proxy supports a subset of Prisma Access locations.
If you have a Local or Evaluation license for Prisma Access for Users and you have a Mobile
Users—GlobalProtect deployment as well as a Mobile Users—Explicit Proxy deployment, you
can deploy a maximum of five locations for each (five locations maximum for Mobile Users
—GlobalProtect and five locations maximum for Mobile Users—Explicit Proxy). If you have a
Worldwide license, there are no restrictions for the maximum number of locations.
• You cannot add locations that are denoted with two asterisks; these are Local Zones and are
not supported with Prisma Access.
• Explicit Proxy supports multitenancy under the following conditions: if you have an existing
Prisma Access non-multitenant deployment and convert it to a multitenant deployment, only
the first tenant (the tenant you migrated) supports Explicit Proxy. Any subsequent tenants you
create for the multitenant deployment after the first do not support Explicit Proxy.
• When onboarding an Explicit Proxy deployment, Palo Alto Networks recommends that all the
configuration be performed in a single browser. You can, however, add security policies from
multiple browsers or browser sessions.
Network Guidelines and Requirements—When configuring Explicit Proxy, make sure that you are
aware of the following network guidelines and have made the following configuration changes in
your network and security environment:

Prisma Access Administrator’s Guide (Panorama Managed) 200 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

• You must configure an SSL decryption policy for all Explicit Proxy traffic.

Decryption is required for Prisma Access to read the authentication state cookie
set up by Prisma Access on the mobile user’s browser. Failing to enforce decryption
enables the abuse of Explicit Proxy as an open proxy that can be widely misused as a
forwarding service for conducting denial of service attacks.

To prevent users from accessing undecrypted sites, be sure to leave the Decrypt traffic that
matches existing decryption rules; for undecrypted traffic, allow traffic only from known IPs
registered by authenticated users check box selected when you configure Explicit Proxy.
• Explicit Proxy does not support HTTP/2 natively. HTTP/2 protocol requests will be
downgraded to HTTP/1.1. Explicit Proxy strips out application-layer protocol negotiation
(ALPN) headers from uploaded files, regardless of your configuration.
• The maximum supported TLS version is 1.3. When creating a decryption profile, specify a Max
Version of TLS v1.3.

• If mobile users are connecting from remote sites or headquarters/data center locations using
an Explicit Proxy, the mobile user endpoint must be able reach and route to the IdP, ACS
FQDN, Explicit Proxy URL, and URL of the PAC file hosted by Prisma Access. To find the ACS
FQDN and the Explicit Proxy URL, select Panorama > Cloud Services > Status > Network
Details > Mobile Users—Explicit Proxy.
Panorama and Content Version Requirements—Make sure that your deployment has the
following minimum Panorama and Antivirus Content version requirements:
• Explicit Proxy requires a minimum Panorama version of 10.0.5.

Prisma Access Administrator’s Guide (Panorama Managed) 201 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

• Explicit Proxy requires a minimum antivirus Content Version of 3590 to be installed on the
Panorama to support the predefined security policies. Install the required Content Version
before committing the Mobile Users—Explicit Proxy configuration.
Palo Alto Networks Subscription Support—Explicit Proxy includes Threat Prevention, URL
Filtering, WildFire, DNS Security, and DLP subscriptions. The DNS Security subscription is also
included and includes support for the Command and Control Domains and Malware Domains
DNS Security threat categories.
Mobile User App Support and Browser Guidelines—Explicit Proxy supports the following apps
and has the following browser guidelines and requirements:
• Explicit Proxy secures internet and SaaS applications accessed over the mobile users’ browser
using HTTP and HTTPS traffic only. Non-web ports and protocols are not supported.
• Explicit Proxy does not support the full client-based version of Microsoft 365 (Office 365),
which uses non-web ports. However, it is designed to support web-based M365, including
Office Online (office.com).
• Explicit Proxy does not provide access to private applications.
• Mobile users will be unidentified in the traffic logs for sites that are not decrypted, with some
exceptions.
• Make a note of the following browser requirements and usage guidelines:
• If you use Explicit Proxy, do not disable cookies in your browser; if you do, you cannot
browse any web pages.
• If you are using Explicit Proxy with Microsoft Edge, be sure that Settings > Privacy, Search,
and Services > Tracking prevention is set to Basic.
• If you use Safari with Explicit Proxy, you might experience issues when accessing websites.
Instead of Safari, use Microsoft Edge, Firefox, Chrome, or Internet Explorer as your browser.
• When using Firefox with an Explicit Proxy, go to about:config and set
security.csp.enable to false. In addition, some add-ons, such as ones that perform
ad blocking or tracking protection, might interfere with tracking protection.
• To support desktop applications, or applications that do not send HTTP traffic, you can
configure GlobalProtect in split tunnel mode and use GlobalProtect in conjunction with
Explicit Proxy.
• If you visit a website for the first time, are prompted to enter Explicit Proxy credentials, then
refresh the browser, you might receive an error. If this condition occurs, re-visit the website
without refreshing and retry the authentication operation.
PAC File Requirements and Guidelines—Follow the PAC file requirements and guidelines when
you set up the PAC file to use with Explicit Proxy.
Proxy Chaining Guidelines—If you use proxy chaining from a third-party proxy to Explicit Proxy,
specify the Explicit Proxy URL (Panorama > Cloud Services > Status > Network Details > Mobile
Users—Explicit Proxy) in the third-party proxy to forward traffic to Explicit Proxy.
Authentication Requirements—SAML is the only supported authentication protocol. Prisma
Access supports PingOne, Azure AD, and Okta as SAML authentication providers, but you should
be able to use any vendor that supports SAML 2.0 as a SAML identity provider (IdP). For more
details about configuring SAML authentication with Prisma Access, including examples for Azure

Prisma Access Administrator’s Guide (Panorama Managed) 202 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

AD, Okta, and Active Directory Federation Services (ADFS) 4.0, see Authenticate Mobile Users in
the Prisma Access Integration Guide (Panorama Managed).
Group Mapping Requirements—You use the Cloud Identity Engine to retrieve user and group
mapping information.
Private or Data Center Access Support—Explicit Proxy does not support flows to Private or Data
Center access for internal applications. It is internet-outbound only.
Port Listening Guidelines—Explicit Proxy only listens on port 8080.
On-Premises Support—Explicit Proxy is a cloud-based proxy solution, and is not offered as an on-
premises product.

Set Up Your Explicit Proxy PAC File

Use the following guidelines and requirements when configuring the PAC file to use with Explicit
Proxy:
• PAC files are required to steer user traffic to Explicit Proxy.
• You can only host one PAC file for use with Prisma Access, and the Explicit Proxy PAC file is
hosted in the United States. If you require alternative PAC file access outside of the United
States, you can host the PAC file in your enterprise.
• Only ASCII text format is supported for PAC files. Palo Alto Networks recommends that you
create and save the PAC file in a text editor such as VI or Vim.
• Upload the PAC file after you create your Explicit Proxy configuration and commit and push
your changes. After you upload your PAC file, a commit and push operation is not required.
• You must have at least one Explicit Proxy URL in the return "PROXY
foo.proxy.prismaaccess.com:8080"; statement beginning for traffic
ingressing to Prisma Access. Either use a configured domain used when you push
your changes or use a valid IPv4 address or DIRECT keyword such as PROXY
paloaltonetworks-245139.proxy.prismaaccess.com:8080 or PROXY
1.2.3.4:8080, and so on.
• If the proxy is not being bypassed, then the you must provide a PROXY keyword. A valid proxy
statement is required if no DIRECT keyword is configured for the proxy bypass.
• If a valid PROXY statement is found before an invalid PROXY statement, Explicit Proxy skips
the validity check all on all PROXY statements after the first. For example, a PAC file with the
valid statement PROXY paloaltonetworks-245139.proxy.prismaaccess.com:8080
followed by the invalid statement PROXY foo.proxy.prismaacess.com:8080
would be considered valid since Explicit Proxy skips the validity check for
foo.proxy.prismaacess.com:8080.
• If you are using a PROXY statement to have ACS traffic bypass the Prisma Access proxy, the
PROXY statement should not use the Explicit Proxy URL. In this configuration, Explicit Proxy
provides an error message, but allows you to upload the PAC file. You can direct the ACS
traffic to other proxies using a valid FQDN or IPv4 address, or directly to the internet, using
the DIRECT keyword.
• Only IPv4 addresses are supported in PROXY statements. Do not use IPv6 addresses in
PROXY statements.
• The maximum file size for a PAC file is 256 KB.

Prisma Access Administrator’s Guide (Panorama Managed) 203 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

• You must specify IdP and ACS URLs to be bypassed.

• You cannot delete a PAC file after you've uploaded it. You can, however, upload a new PAC file
to overwrite the existing one.
• If you change the Explicit Proxy URL in Prisma Access but do not change the PAC file to reflect
the change, the change won't be applied. You must upload a new PAC file specifying the new
Explicit Proxy URL.
Explicit Proxy provides you with a sample PAC file that you can modify and use as the PAC file
for your Explicit Proxy deployment. The sample PAC file that Prisma Access provides contains the
following data:

function FindProxyForURL(url, host) {

/* Bypass localhost and Private IPs */
var resolved_ip = dnsResolve(host);
if (isPlainHostName(host) ||
shExpMatch(host, "*.local") ||
isInNet(resolved_ip, "10.0.0.0", "255.0.0.0") ||
isInNet(resolved_ip, "172.16.0.0", "255.240.0.0") ||
isInNet(resolved_ip, "192.168.0.0", "255.255.0.0") ||
isInNet(resolved_ip, "127.0.0.0", "255.255.255.0"))
return "DIRECT";
/* Bypass FTP */
if (url.substring(0,4) == "ftp:")
return "DIRECT";
/* Bypass SAML, e.g. Okta */
if (shExpMatch(host, "*.okta.com") || shExpMatch(host,
"*.oktacdn.com"))
return "DIRECT";
/* Bypass ACS */
if (shExpMatch(host, "*.acs.prismaaccess.com"))
return "DIRECT";
/* Forward to Prisma Access */
return "PROXY foo.proxy.prismaaccess.com:8080";

If you want to use the default PAC file that Prisma Access provides, you can optionally modify the
fields in the PAC file as described in the following table.

Text Description

Enter any hostnames or IP addresses that

var resolved_ip = dnsResolve(ho should not be sent to Explicit Proxy between
st); the JavaScript functions var resolved_ip
= and return “DIRECT”;.
...
If you do not modify the data in this file, the
return "DIRECT"; following hostnames and IP addresses bypass
Explicit Proxy:
• if (isPlainHostName(host)—
Bypasses Explicit Proxy for hostnames
that contain no dots (for example, http://
intranet).

Prisma Access Administrator’s Guide (Panorama Managed) 204 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Text Description
• shExpMatch(host, "*.local") ||—
Bypasses the proxy for any hostnames
that are hosted in the internal network
(localhost).
• isInNet(resolved_ip,
"10.0.0.0", "255.0.0.0")
|| isInNet(resolved_ip,
"172.16.0.0", "255.240.0.0")
|| isInNet(resolved_ip,
"192.168.0.0", "255.255.0.0")
|| isInNet(resolved_ip,
"127.0.0.0", "255.255.255.0"))—
Bypasses Explicit Proxy for any IP addresses
that are in the private or loopback IP
address range.

Bypasses Explicit Proxy for FTP sessions.

if (url.substring(0,4) == "ftp:
")
return "DIRECT";

Bypasses Explicit Proxy for the SAML IdP. Be

if (shExpMatch(host, "*.okta.co sure to add all FQDNs used by the IdP.
m") || shExpMatch(host, "*.okta
cdn.com")) If you use Okta as the IdP used for SAML
return "DIRECT"; authentication, enter *.okta.com and
*.oktacdn.com.

Bypasses Explicit Proxy for the Prisma Access

if (shExpMatch(host, "*.acs.pri Authentication Cache Service (ACS).
smaaccess.com"))
return "DIRECT"; Instead of using a wildcard, you can add the
specific ACS FQDN for your deployment. Find
this FQDN under Panorama > Cloud Services
> Status > Network Details > Mobile Users—
Explicit Proxy > ACS FQDN.

Bypasses Explicit Proxy for the Explicit Proxy

return "PROXY foo.proxy.prismaa URL.
ccess.com:8080"
You must have at least one Explicit
Proxy URL in the return "PROXY
foo.proxy.prismaaccess.com:8080";
statement for traffic ingressing to
Prisma Access. Either use a configured
domain used when you push your
changes, or use a valid IPv4 address
or DIRECT keyword such as PROXY

Prisma Access Administrator’s Guide (Panorama Managed) 205 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Text Description
paloaltonetworks-245139.proxy.prismaaccess.co
or PROXY 1.2.3.4:8080.

Secure Mobile Users with an Explicit Proxy

To secure mobile users with an Explicit Proxy, complete the following steps.
Before you configure Explicit Proxy guidelines, be aware of how explicit proxy works and how
explicit proxy identifies users, go through the planning checklist, and learn how to set up the
Explicit Proxy PAC file.
STEP 1 | Configure SAML authentication, including configuring a SAML Identity Provider and an
Authentication Profile, for Prisma Access. You specify the authentication profile you create
in a later step.
Use the following guidelines when configuring authentication for the IdP and in Panorama:
• Panorama Guidelines:
• Be sure that you configure the authentication profile under the
Explicit_Proxy_Template.
• Use mail as the user attribute in the IdP server profile and in the Authentication Profile
on Panorama.
• Explicit Proxy does not support Sign SAML Message to IdP in the SAML Identity
Provider Server Profile.
• When you configure the Cloud Identity Engine to retrieve user and group mapping
information, use mail or userPrincipalName as the SamAccountName in Group Mapping.
• When configuring Group Mapping Settings during Explicit Proxy setup, use the same
Directory Attribute for Primary Username and email, or Prisma Access does not
accurately reflect user counts. For example, given the following user profile:

sAMAccountName: muser
Netbios: example
userPrincipalName: [email protected]
mail: [email protected]

If, in the Cloud Identity Engine configuration, you use a Primary Username of
userPrincipalName and an E-Mail of mail, the user information that Cortex
Data Lake returns in traffic logs and the user information that the ACS returns in
authentication logs will be different. In this example, ACS sends the mail attribute
([email protected]) to the authentication logs and Cortex Data Lake sends
the userPrincipalName attribute ([email protected]) to the traffic logs. As a result
of this mismatch, your user count will not be accurate in the Current Users and Users
(Last 90 days) fields when checking the Explicit Proxy status in the Status (Panorama >
Cloud Services > Status > Status page. For this reason, use the same directory attribute

Prisma Access Administrator’s Guide (Panorama Managed) 206 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

for Primary Username and E-Mail (for example, mail) when specifying Group Mapping
Settings.
• When using Panorama to manage Prisma Access, the Cloud Identity Engine does not
auto-populate user and group information in security policy rules.
• IdP Guidelines:
• Use the following URLs when configuring SAML:
SAML Assertion Consumer Service URL: https://
global.acs.prismaaccess.com/saml/acs
Entity ID URL: https://global.acs.prismaaccess.com/saml/metadata
• If you use Okta as the IdP, use EmailAddress for the Name ID Format setting.
• Enter a single sign on URL of https://global.acs.prismaaccess.com/saml/
acs.
• Single Logout (SLO) is not supported.
• To troubleshoot IdP authentication issues, use the IdP’s monitoring and troubleshooting
capabilities. The ACS does not log IdP authentication failures.
• When creating an Authentication Profile for the SAML IdP, in the Advanced tab, select
all in the Allow List or Explicit Proxy will not be able to retrieve group mapping.

STEP 2 | Configure Explicit Proxy settings.

1. Select Panorama > Cloud Services > Configuration > Mobile Users—Explicit Proxy and
click the gear icon to edit Explicit Proxy Settings.
2. In the Settings tab, edit the following settings:
• (Optional) In the Templates section, Add the template or templates that contains the
configuration you want to push for Explicit Proxy.
By default, Prisma Access creates a new template stack
Explicit_Proxy_Template_Stack and a new template Explicit_Proxy_Template. If you
have existing settings you want to import, import them now. If you are starting with
a new Explicit Proxy configuration, make sure that you are using this template when
you create and edit your Device settings in Panorama.
You can Add more than one existing template to the stack and then order them
appropriately using Move Up and Move Down. Panorama evaluates the templates in
the stack from top to bottom, and settings in templates that are higher in the stack
take priority over the same settings specified in templates that are lower in the stack.
You cannot move the default Explicit_Proxy_Template from the top of the stack; this
prevents you from overriding any required Explicit Proxy settings.
• In the Device Group section, select the Parent Device Group that contains the
configuration settings you want to push for the Explicit Proxy, or leave the parent
device group as Shared to use the Prisma Access device group shared hierarchy. The
Device Group Name cannot be changed.
• (Optional) If you have configured a next-generation firewall as a master device or
added a Cloud Identity Engine profile to make user and group information selectable

Prisma Access Administrator’s Guide (Panorama Managed) 207 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

in security policies, select User-ID Master Device or Cloud Identity Engine; then,
select either the Master Device or the Cloud Identity Engine profile that you created.
• In the License Allocation section, specify the number of mobile users to allocate for
Explicit Proxy.

3. In the Group Mapping Settings tab, Enable Directory Sync Integration (now known as
the Cloud Identity Engine) to configure Prisma Access to use the Cloud Identity Engine
to retrieve user and group information.
You use the Cloud Identity Engine to populate user and group mapping information for
an Explicit Proxy deployment. To configure the Cloud Identity Engine, you set up the
Cloud Identity Engine on your AD and associate the Panorama that manages Prisma

Prisma Access Administrator’s Guide (Panorama Managed) 208 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Access with the Cloud Identity Engine in the hub; then, set up the Cloud Identity Engine
in Prisma Access.
Enter mail for the Directory Attribute in the Primary Username field and mail for the E-
Mail field.

4. Click OK when finished.

STEP 3 | (Optional, Innovation Deployments Starting with 3.0 Innovation Only) Configure Block
Settings.
Use Block Settings to block access to an internet destination at the DNS resolution stage.

To restrict access to Explicit Proxy to specific source IP addresses, you can also use
special objects. These Address Objects, Address Groups, and External Dynamic Lists
(EDLs) that use specific names allow the IP addresses you specify for internet traffic
and block any other IP addresses.

STEP 4 | In the Authentication Settings tab, configure decryption, X-Authenticated-User (XAU), and
authentication settings.
1. Configure your settings for decrypted traffic.
• Select Decrypt Traffic That Matches Existing Decryption rules; For Undecrypted
Traffic, Allow Traffic Only From Known IPs Registered By Authenticated Users to
configure the following decryption rules:
• Traffic that matches decryption policy rules you have configured with an Action to
Decrypt or Decrypt and Forward will be decrypted.
If a user accesses an undecrypted HTTPS site, and a user has not yet authenticated
to Explicit Proxy from that IP address, the user is blocked. However, the user can

Prisma Access Administrator’s Guide (Panorama Managed) 209 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

access a decrypted site, complete authentication, and then access undecrypted

sites.
• Undecrypted traffic is allowed from IP addresses from which mobile user have
already authenticated.
Explicit Proxy requires decryption to authenticate users. Enter the domains that
can be decrypted in a custom URL category; then, specify those categories in If

Prisma Access Administrator’s Guide (Panorama Managed) 210 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Authentication traffic is forwarded through Explicit Proxy, specify the domains used
in the authentication flow.

Only add the domains that are required for authentication to the Custom
URL category you specify, including all ACS and IdP FQDNs. You must add
authentication URLs to the Custom URL category, even if you have added
them to a decryption policy.
• To allow all traffic to be decrypted, select Decrypt All traffic (Overrides Existing
Decryption Rules).
If you choose this radio button, ensure that:
• You do not have exceptions in your decryption policy.
• You are applying source IP address-based restrictions in your security policy.

Failing to follow these recommendations enables the abuse of Explicit Proxy

as an open proxy that can be widely misused as a forwarding service for
conducting denial of service attacks.

• You have at least one SSL Forward Proxy certificate specified as a Forward Trust
Certificate.
If you do not have a forward trust certificate, create one on Panorama; then,
Commit and Push your changes to Prisma Access. Failure to have a forward trust
certificate will cause a commit error when you commit your Explicit Proxy changes.
2. (Optional) Enter any IP addresses from which undecrypted HTTP or HTTP Cross-Origin
Resource Sharing (CORS) traffic should be allowed to the Trusted Source Address.
Add the IP addresses to IP address-based Address Objects and Add the address objects
in the field.
Enter a maximum of 100,000 addresses. Make sure that the address object uses IP
addresses only.
3. (Optional) If you want to allow the Trusted Source Address IP addresses to use XAU
for identity, select Use X-Authenticated-User (XAU) header on incoming HTTP/HTTPS
requests for Identity.
Select this option if you if you are using proxy chaining from a third-party proxy to
Explicit Proxy, users have authenticated in that proxy, and the proxy uses XAU headers.
XAU headers are the only HTTP headers supported for Explicit Proxy header ingestion.
X-Forwarded-For (XFF) headers are not supported.
4. (Optional) Specify settings for privacy-sensitive websites by creating security policy
rules for those sites, then specifying the Security Policy or policies for those sites in the
Enforce Authentication Only area.
For any websites you specify in the in the Security Policy or policies you add, Explicit
Proxy decrypts the websites based on the decryption policies, but does not inspect or
log the decrypted traffic.

Prisma Access Administrator’s Guide (Panorama Managed) 211 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 5 | (Optional) If you want to forward traffic to Explicit Proxy from your branches through a
secure IPSec tunnel, configure Advanced settings and retrieve anycast IP addresses if you
want to use Explicit Proxy in conjunction with a Prisma Access remote network.
This solution uses anycast addresses with a remote network IPSec tunnel to allow Explicit
Proxy to be used for users and devices at a remote network site or branch location.

STEP 6 | Click Configure to configure Explicit Proxy setup.

1. Specify an Explicit Proxy FQDN.
By default, the name is proxyname.proxy.prismaaccess.com, where proxyname is the
subdomain you specify, and uses port 8080. If you want to use your organization’s

Prisma Access Administrator’s Guide (Panorama Managed) 212 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

domain name in the Explicit Proxy URL (for example, thisproxy.proxy.mycompany.com),

enter a CNAME record your organization’s domain.
For example, to map a proxy URL named thisproxy.prismaaccess.com to a
proxy named thisproxy.proxy.mycompany.com, you would add a CNAME of
thisproxy.proxy.prismaaccess.com to the CNAME record in your organization’s domain.
2. Specify an Authentication Profile and Cookie Lifetime.
• Specify the SAML Authentication Profile you used in Step 1, or add a New
authentication profile to use with Prisma Access.
You must configure SAML authentication, including configuring a SAML Identity
Provider (IdP) and an Authentication Profile, to use an Explicit Proxy.
• (Optional) Specify a Cookie Lifetime for the cookie that stores the users’
authentication credentials.
Prisma Access caches the user’s credentials and stores them in the form of a cookie.
To change the value, specify the length of time to use in Seconds, Minutes, Hours, or
Days.

To prevent issues with users not being able to download large files before
the cookie lifetime expires, or the cookie expiring when users are accessing a
single website for a long period of time, Palo Alto Networks recommends that
you configure a Cookie Lifetime of at least one day. If Explicit Proxy users
have a cookie lifetime expiration issue, they can browse to a different website
to re-authenticate to ACS and refresh the ACS cookie.

If you are downloading a file, and the file download takes longer than the Cookie
Lifetime, the file download will terminate when the lifetime value expires. For this
reason, consider using a longer Cookie Lifetime if you download large files that take a
long time to download.

STEP 7 | Select the Locations and the regions associated with those locations where you want to
deploy your Explicit Proxy for mobile users. Prisma Access adds a proxy node into each
location you select.
Explicit Proxy supports a subset of all Prisma Access locations. See Explicit Proxy Locations for
the list of locations.
The Locations tab displays a map. Highlighting the map shows the global regions (Americas,
Europe, and Asia Pacific) and the locations available inside each region. Select a region, then
select the locations you want to deploy in each region. Limiting your deployment to a single
region provides more granular control over deployed regions and allows you to exclude regions
as required by your policy or industry regulations. See Prisma Access Locations for the list of

Prisma Access Administrator’s Guide (Panorama Managed) 213 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

regions and locations. You can select a location in a region that is closest to your mobile users,
or select a location as required by your policy or industry regulations.
1. Click the Locations tab and select a region.

2. Select one or more Explicit Proxy locations within your selected region using the map.
Hovering your cursor over a location highlights it. White circles indicate an available
location; green circles indicate that you have selected that location.

In addition to the map view, you can view a list of regions and locations. Choose
between the map and list view from the lower left corner. In the list view, the list

Prisma Access Administrator’s Guide (Panorama Managed) 214 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

displays regions sorted by columns, with all locations sorted by region. You can select All
sites within a region (top of the dialog).

3. Click OK to add the locations.

STEP 8 | Configure security policy rules to enforce your organization’s security policies.
To make required configuration changes and to control the URLs that mobile users can access
from Explicit Proxy, use security policies. Use the following guidelines and requirements when
configuring your security policies:
• Based on your business goals, create security policies for sanctioned internet and SaaS apps
using App-ID and user groups that need access to those applications.
• Attach security profiles to all security policy rules so that you can prevent both known and
unknown threats following the security profile best practices.

Prisma Access Administrator’s Guide (Panorama Managed) 215 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 9 | Commit your changes to Panorama and push the configuration changes to Prisma Access.
1. Click Commit > Commit and Push.
2. Edit Selections and, in the Prisma Access tab, make sure that Explicit Proxy is selected in
the Push Scope, then click OK.

3. Click Commit and Push.

STEP 10 | Select the PAC file to use with Explicit Proxy.

1. Select Panorama > Cloud Services > Configuration > Mobile Users > Explicit Proxy.
Be sure that you enter a port of 8080 in the PAC file.
2. Select the Connection Name for the Explicit Proxy setup you just configured.
3. Enter the PAC (Proxy Auto-Configuration) File to use for Explicit Proxy.

Be sure that you understand how PAC files work and how to modify them before
you upload them to Prisma Access.

Browse and upload the file.

Prisma Access provides you with a sample PAC file; you can Download sample PAC file,
change the values, and upload that file. See Set Up Your Explicit Proxy PAC File for PAC
file requirements and guidelines as we as a description of the contents of the sample
PAC file.

Create Block Settings in an Explicit Proxy Deployment

To enable this functionality, reach out to your Palo Alto Networks account representative or
partner, who will contact the Site Reliability Engineering (SRE) team and submit a request.

Prisma Access Administrator’s Guide (Panorama Managed) 216 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

When users access an internet destination using Explicit Proxy, the DNS resolution for the
internet destination is performed by Explicit Proxy. To block access to an internet destination
at the DNS resolution stage, you can use block settings. You can block based on DNS Security
categories, URL Filtering categories or external dynamic lists (EDLs).
For domains that you block, Prisma Access blocks the domains and users receive a block
page during the HTTP GET request (for unencrypted websites) or HTTP Connect request (for
encrypted websites), which means that domains are blocked during the initial connection request.
When you block access to the site, user are shown a block page after taking them through the
authentication flow, and the username is captured for further forensics and Security Operations
Center (SOC) workflows.
To configure block settings, complete the following steps.
STEP 1 | Configure Block Settings to block domains or domain categories.
Specify the domains or domain categories for malicious websites, or for any websites that you
do not want users to access. Prisma Access prevents users from accessing the URLs and IP
addresses you specify in this area when users initiate an HTTP GET (for unencrypted requests)

Prisma Access Administrator’s Guide (Panorama Managed) 217 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

or HTTP CONNECT (for encrypted requests). Users receive a block page when they attempt to
access blocked websites.

1. In Blocked Domain Category List, enter the pre-defined categories to block.

Prisma Access Administrator’s Guide (Panorama Managed) 218 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Custom URL categories are not supported.

2. In EDL Domain, enter domain-based external dynamic lists (EDLs) to block.
You can only select EDLs that have an EDL type of Dynamic Domain Lists; dynamic IP
lists and dynamic URL lists are not allowed.
3. If you want to exempt any domains that are included in a Blocked Domain Category List,
specify them as an Exempted Domain.
Any domains that are entered are exempted from being blocked, even if they appear in a
domain category that you have blocked.
• You can enter a maximum of 100 domains.
• The maximum domain record length is 256 characters.

STEP 2 | Select the IP addresses to block in the Blocked Source Address area.
You can Add addresses, address groups, IP address-based EDLs, or region- and country-based
IP addresses.
Use the following IP address guidelines:
• Use EDLs with a Type of IP List or Predefined IP List only.
• Use Address Objects with a type of IP Range or IP Netmask only.
• Address groups with dynamic objects membership are not supported.
• Do not use custom regions in IP address objects; instead, use predefined regions.

STEP 3 | Select Log requests to blocked domains to have Prisma Access log blocked domain requests.
Since blocked domain logs can generate a lot of traffic from botnets, use caution when you
enable logging, or use it only for troubleshooting purposes. If you restrict your proxy usage
(for example, if you restrict usage to specific IP addresses), you might be able to enable logging
without restriction.

Use Special Objects to Restrict Explicit Proxy Internet Traffic to Source IP Addresses
Explicit Proxy provides you with special Address Objects, Address Groups, and External Dynamic
Lists (EDLs) to restrict access to Explicit Proxy to specific source IP addresses. When you create
one or more of these special objects using the following exact names, Explicit Proxy allows the
source IP addresses you specify and blocks any other IP addresses:
• Address Object—Select Objects > Addresses in the Explicit_Proxy_Device_Group and create
an object named Palo Alto Networks Explicit Proxy Allowed Source Address.
• Address Group—Select Objects > Address Groups in the Explicit_Proxy_Device_Group and
create an object named Palo Alto Networks Explicit Proxy Allowed Source Address Group.
• External Dynamic List (EDL)—Select Objects > External Dynamic Lists in the
Explicit_Proxy_Device_Group and create an EDL named Palo Alto Networks Explicit Proxy
Allowed Source List, and create an EDL with a type of IP List.
You can specify IP addresses such as egress IP addresses of branch offices.

Prisma Access Administrator’s Guide (Panorama Managed) 219 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Using wildcards (such as *.*) to skip Explicit Proxy authentication for a large number of domains is
not permitted unless you restrict your source traffic to specific source IP addresses using one of
these special objects.
Use Address Objects, Address Groups, or EDLs separately or jointly; for example, you could create
only an Address Group without creating an Address Object or EDL.

Monitor and Troubleshoot Explicit Proxy

After you have configured Explicit Proxy for mobile users, monitor the status and troubleshoot
any issues by checking the status of your Prisma Access Explicit Proxy deployment.

Prisma Access Administrator’s Guide (Panorama Managed) 220 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

• Select Panorama > Cloud Services > Status > Status to see Explicit Proxy status.

The mobile users Status and Config Status fields indicate whether the connection between
Prisma Access and your mobile users is OK, unable to fetch the status on the tunnel (Warning),
or that the mobile users cannot connect to Explicit Proxy (Error).
Click the hyperlink next to Current Users and Users (Last 90 days) to get more information
about mobile users.
• Current Users—The current number of authenticated users who have browsed traffic in the
last five minutes.
• Users (Last 90 days)—The number of unique authenticated Explicit Proxy users for the last
90 days.

Prisma Access Administrator’s Guide (Panorama Managed) 221 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

• Select Panorama > Cloud Services > Status > Monitor > Mobile Users—Explicit Proxy to
display a map showing the deployed Explicit Proxy locations.

• Select Panorama > Cloud Services > Status > Network Details > Mobile Users—Explicit Proxy
to view the following details:

• Explicit Proxy URL—The URL used for Explicit Proxy.

• ACS FQDN—The FQDN of the ACS.
• SAML Meta Data—The authentication profile metadata used by SAML. You can Export
SAML Metadata to save the metadata file.
• To troubleshoot authentication-related issues, check the traffic logs (Monitor > Logs >
Traffic) and authentication logs (Monitor > Logs > Authentication). Explicit Proxy displays the
following IP addresses and locations in the logs:
• IP Addresses—If mobile users bypass the ACS FQDN in the PAC file, the IP address
displayed in the Source column in the Traffic logs and the Traffic logs and the IP Address
column in the Authentication logs, when viewed under the Explicit_Proxy_Device_Group,
will be same as the mobile user’s IP address. If users do not bypass the ACS FQDN in the
PAC file, the source IP address is the public IP address of the Explicit Proxy cloud firewall
where redirects are going to ACS.
• Locations—If mobile users bypass the ACS FQDN in the PAC file, the Region Name
displayed in the Region Column in Authentication Logs, Current Users, and Users (Last 90
days) is one of the five 5 regions (us-west-2, us-east-1, eu-west-2, eu-west-3, ap-south-1)
where the ACS is deployed, and shows the region where Explicit Proxy is performing the
redirects from the client’s browser. If users do not bypass the ACS FQDN in the PAC file,
the Region Name displayed in the Region Column in Authentication Logs, Current Users,
and Users (Last 90 days) is one of the five 5 regions (us-west-2, us-east-1, eu-west-2, eu-
west-3, ap-south-1) where the ACS is deployed, and shows the region where Explicit Proxy
is performing the redirects from the Explicit Proxy firewall.

Prisma Access Administrator’s Guide (Panorama Managed) 222 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Monitor and Log Out GlobalProtect Users in Prisma

Access
There are several locations in Panorama where you can view the list of logged-in users. You can
view unique users, the location in which the users are logged in, and tables that provide additional
information. It is also important to understand how Prisma Access counts the number of users in
each location in a Mobile Users—GlobalProtect deployment.
You can get a detailed view of users from several locations:
• To see an overall view of users and to open a table that allows you to view and log out logged-
in users, select Panorama > Cloud Services > Status > Status.
• To see a graphic view of users in a map view, and to view users by region and location, select
Panorama > Cloud Services > Status > Service Stats > Mobile Users—GlobalProtect.
• You can also learn more about how Prisma Access counts mobile users.

View GlobalProtect Mobile Users from the Status Tab

To view the total number of unique users who are currently logged in across all locations, select
Panorama > Cloud Services > Status > Status > Mobile Users—GlobalProtect.

To view more details about the users who are currently logged in, click the hyperlinked number
next to Current Users to display the Current Users table.

The total number of users that display in the Status page, and the number that displays
in the pop-up table, might be different; the number that displays in the table might be
larger.

You can log out active users from the Current Users table; to do so, select the user and click
Logout. Note that you might have to close and then re-open the screen to have Prisma Access
remove the logged-out user from the Current Users page.

Prisma Access Administrator’s Guide (Panorama Managed) 223 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

The following screen shows users who logged in with the GlobalProtect app and with Clientless
VPN. The screen shows the users’ username, public IP, and last login time. If the user is logged in
with the GlobalProtect app, it also shows their client OS, private IP address, and computer name.

View GlobalProtect Mobile Users from the Monitor Tab

To view the number of unique users that are logged in per region, select Panorama > Cloud
Services > Status > Service Stats > Mobile Users—GlobalProtect.

Prisma Access Administrator’s Guide (Panorama Managed) 224 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

To view details about locations in a region, click the region.

The number of users that displays in the global map view page and the number that
displays in the table per region might be different; the number that displays in the table
might be larger.

How Prisma Access Counts GlobalProtect Mobile Users

The number of total users that display in the status areas might be different than the number that
displays in the associated tables. The following section describes the differences.
• Status tab (Panorama > Cloud Services > Status > Status)—The number of users that displays
in the main page, in the Mobile Users—GlobalProtect area, might be different than the number
that displays in the table when you click the Current Users hyperlink. The number that displays
in the Mobile Users—GlobalProtect area counts the number of unique users; the list of users in

Prisma Access Administrator’s Guide (Panorama Managed) 225 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

the Current Users table counts all users per login or connection. If a single user is logged in to
more than one gateway or is connected with multiple devices, the number in the table might be
larger.
For example, a user user1 is logged into two gateways in the United Kingdom location; this
condition might have occurred because Prisma Access automatically added gateways when a
large number of users logged in to the same location. In this case, Prisma Access counts user1
once in the Mobile Users—GlobalProtect area, but twice in the Current Users table.

To prevent the same mobile usernames (appearing in different formats) from being
counted multiple times, Panorama Managed Prisma Access will normalize usernames
to a single format.
For example, when users connect to a gateway, Panorama Managed Prisma Access can
receive instances of the same username from the gateway in various formats, such as:
• [email protected]
• domain\jane.doe
• (null)\[email protected]
• jane.doe
Before normalization, these instances of the same username are counted as individual
users, causing the mobile user counts to be inflated incorrectly.
After normalization, all usernames will be in the [email protected] format, and
the mobile user counts will accurately reflect the number of users who have connected
to Panorama Managed Prisma Access within the last 90 days. If the username is
already in the [email protected] format, the username is not normalized.
• Monitor tab (Panorama > Cloud Services > Status > Service Stats > Mobile Users—
GlobalProtect)—The number of Users you see in the global map might be different than the
number that displays in the table when you select a region. A user that is logged in to more

Prisma Access Administrator’s Guide (Panorama Managed) 226 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

than one gateway or is connected with multiple devices might show up multiple times in the
table.
The following screenshots provide an example. There are 23 unique users logged into the Asia
region, as shown in the global map.

If you select the Asia region, Prisma Access gives the number of unique users (23) on the top
left of the region page. However, two users are connected via multiple devices in the South
Korea location (for example, a smart phone and a computer). Because the users have two

Prisma Access Administrator’s Guide (Panorama Managed) 227 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

separate connections, Prisma Access counts them twice in the table, giving a total number
count in the table of 25.

Prisma Access Administrator’s Guide (Panorama Managed) 228 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Manage GlobalProtect App Upgrades in Prisma Access

Prisma Access hosts the GlobalProtect app version that macOS and Windows users in your
organization can download from the Prisma Access portal. Prisma Access offers several versions
of the GlobalProtect app, and you can choose to make one of those versions the active version.
You can also manage mobile users' access to the GlobalProtect app, or perform staged upgrades.
• Select the Active GlobalProtect App Version for Prisma Access
• Manage User Access to GlobalProtect App Updates from Prisma Access
• Perform Staged Updates of the GlobalProtect App on Prisma Access

Select the Active GlobalProtect App Version for Prisma Access

Prisma Access manages the GlobalProtect app version for Windows and macOS users in your
organization. While Prisma Access hosts several GlobalProtect app versions, only one of the
hosted versions is active. When mobile users log in to the Prisma Access portal, the active version
is the one that is available for mobile users to download and install on their Windows and macOS
devices.
If your currently-active version is end-of-life, Prisma Access notifies you and requests that you
activate a supported version.
You can select multiple GlobalProtect versions in a multitenant deployment. The GlobalProtect
app version settings you apply are per tenant and not global; you control the app version on a per-
tenant basis.
You can replace the current active version with another hosted version from the Service Setup
page by completing the following steps.

If you are using Prisma Access in a FedRAMP environment, you must use the FIPS-
certified version of GlobalProtect, which is version of 5.1.4. If you change the default
GlobalProtect version from 5.1.4, you cannot select version 5.1.4 from the Panorama UI
and must open a Support case with Palo Alto Networks Technical Support to add it back.

STEP 1 | Select Panorama > Cloud Services > Configuration > Service Setup.

Prisma Access Administrator’s Guide (Panorama Managed) 229 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 2 | Select Activate new GlobalProtect App version.

The active version is indicated in the drop-down list.

If your current GlobalProtect version is end-of-life (EoL), a message displays in this area
on the Service Setup page; if you receive this message, upgrade your GlobalProtect app
version by continuing to the next step.

STEP 3 | Select the version to which you want to upgrade and click OK.
A window displays to verify your choice.

After the app has been activated, you receive a success message.

STEP 4 | View the System Status page to verify the Active GlobalProtect App version.

Prisma Access Administrator’s Guide (Panorama Managed) 230 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Manage User Access to GlobalProtect App Updates from Prisma

Access
To manage mobile user access to the active GlobalProtect app version that is hosted by Prisma
Access, complete the following steps.
STEP 1 | In Panorama, select Network > GlobalProtect > Portals.

STEP 2 | Select the Mobile_User_Template from the Template drop-down.

STEP 3 | Select GlobalProtect_Portal to edit the Prisma Access portal configuration.

STEP 4 | Select the Agent tab and select the app configuration.

STEP 5 | Select the App tab.

STEP 6 | In the App Configurations area, select a choice in Allow User to Upgrade GlobalProtect App
to specify whether mobile users can upgrade their GlobalProtect app version to the active
version that is hosted on Prisma Access and, if they can, whether they can choose when to
upgrade:
• Allow with Prompt (default)—Prompt users when a new version is activated and allow users
to upgrade their software when it is convenient.
• Disallow—Prevent users from upgrading the app software.
• Allow Manually—Allow users to manually check for and initiate upgrades by selecting
Check Version in the GlobalProtect app.
• Allow Transparently—Automatically upgrade the app software whenever a new version
becomes available on the portal.
• Internal—Automatically upgrade the app software whenever a new version becomes
available on the portal, but wait until the endpoint is connected internally to the corporate
network. This prevents delays caused by upgrades over low-bandwidth connections.

Perform Staged Updates of the GlobalProtect App on Prisma

Access
If you manage a large organization, you might want to update mobile users to the latest version
of the GlobalProtect app in stages. For example, you could assign a smaller group to update their
GlobalProtect app before rolling out the update to everybody in your organization. To do so,
complete the following task.
STEP 1 | If you have not yet created it, create a user group for the first group of users to which you
want to roll out the GlobalProtect app update.
You can use User-ID to map users to groups, or select Device > Local User Database > User
Groups to manually create a group.

Prisma Access Administrator’s Guide (Panorama Managed) 231 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 2 | Create a new GlobalProtect agent configuration to use for the first group of users.
1. In Panorama, select Network > GlobalProtect > Portals.
2. Select the Mobile_User_Template from the Template drop-down.
3. Select GlobalProtect_Portal to edit the Prisma Access portal configuration.
4. Select the Agent tab.
5. Select the DEFAULT configuration and Clone it.
You can also Add a new configuration; but cloning the existing configuration copies over
required information for the new configuration.
6. Specify a Name for the configuration.

7. Select the Config Selection Criteria tab.

8. In the User/User Group area, select the user you created in Step 1.

9. Select the App tab.

Prisma Access Administrator’s Guide (Panorama Managed) 232 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

10. Change Allow User to Upgrade GlobalProtect App to either Allow with Prompt or Allow
Transparently.
Allow with Prompt prompts users when a new version is activated and allows them
to upgrade their software when it is convenient; Allow Transparently automatically
upgrades the app software whenever a new version becomes available on the portal.

11. Click OK to save your changes.

STEP 3 | Select Move Up to move your configuration above the default configuration.
When an app connects, the portal compares the source information in the packet against the
agent configurations you have defined. As with security rule evaluation, the portal looks for
a match starting from the top of the list. When it finds a match, it delivers the corresponding
configuration to the app.

STEP 4 | Repeat these steps for the DEFAULT configuration, but change Allow User to Upgrade
GlobalProtect App to Disallow to prevent users from updating to the latest GlobalProtect
app software.

Prisma Access Administrator’s Guide (Panorama Managed) 233 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 5 | When you want to let the rest of the users update their apps, change Allow User to Upgrade
GlobalProtect App in the DEFAULT configuration to a selection that allows it (either Allow
with Prompt or Allow Transparently).

Prisma Access Administrator’s Guide (Panorama Managed) 234 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Deploy Explicit Proxy and GlobalProtect or a Third-Party

VPN in Prisma Access
If you are using GlobalProtect in split tunnel mode to provide secure access to private apps only,
you can add Prisma Access Explicit Proxy (Explicit Proxy) to your deployment to secure public
apps, including internet and external SaaS applications.
In addition, if you are using a VPN client for access to data center and private applications, you
can continue to use that client to secure access to private apps while you use Explicit Proxy and a
PAC file to secure access to public apps. You can deploy Explicit Proxy in a location close to your
mobile users, which eliminates the need to backhaul traffic to your data center for web security.

Use Explicit Proxy with GlobalProtect and Third-Party VPNs

Examples
This section provides examples of adding Explicit Proxy to existing on-premise GlobalProtect,
Prisma Access Mobile Users—GlobalProtect, and third-party VPN deployments.
The following figure shows a deployment using an on-premise or virtual GlobalProtect gateway
along with Explicit Proxy. GlobalProtect routes the traffic using the GlobalProtect client to the
Palo Alto Networks next-generation firewall. To configure this deployment, you create a split
tunnel configuration in GlobalProtect, allowing private apps to be secured with GlobalProtect
and public apps to be secured with Explicit Proxy. When configuration is complete, mobile users
connect to the private apps in your organization’s data center using GlobalProtect and connect to
private internet-based apps using Explicit Proxy.

If you have a third-party VPN, you can use it to connect to private apps in the data center, while
securing public apps using Explicit Proxy, as shown in the following figure.

Prisma Access Administrator’s Guide (Panorama Managed) 235 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

How Explicit Proxy Works With GlobalProtect

Before you decide what applications or traffic you should protect with Explicit Proxy and which
applications you should protect with either GlobalProtect or a third-party VPN, you should
understand how GlobalProtect and Prisma Access make their forwarding decisions based on the
Explicit Proxy and VPN configuration. The examples in this section assume that you have already
deployed Explicit Proxy and GlobalProtect into your organization’s network and have configured
GlobalProtect split tunnel options. The following figure shows the process.

Prisma Access Administrator’s Guide (Panorama Managed) 236 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

When a mobile user requests an private or internet-based resource or app, the request is
evaluated by the Explicit Proxy PAC file on the endpoint.
• A return "DIRECT"; function in the PAC file causes the traffic specified in the expression
to bypass Explicit Proxy processing.
Explicit Proxy provides you with a sample PAC file that uses the return "DIRECT"; function
with IP addresses and URLs. See Set Up Your Explicit Proxy PAC File to see the contents of the
PAC file and a description of how to use it.
• A dnsresolve(host) function in the PAC file forces the endpoint to make a DNS query to
resolve a hostname to an IP address. This query then follows the VPN policy (for example, split
tunnel or split DNS) for forwarding the DNS request to the destination DNS server.
The PAC file provided with Explicit Proxy uses dnsresolve(host), return "DIRECT";,
and private IP addresses together in an expression. If, after a DNS lookup, the returned IP
address is included with the private IP addresses in the expression, the traffic associated with
the private IP address bypasses Explicit Proxy processing.
• Traffic that is specified in the PAC file as return "PROXY sitename:8080"; is
forwarded to Explicit Proxy.
After the web request is evaluated based on the conditions in the PAC file, it is then sent to the
GlobalProtect or third-party VPN configuration on the endpoint for processing and the traffic
is evaluated in the GlobalProtect app for split tunnel configuration options. You can split traffic
based on domain (URL) or application or subnet. If you have configured split DNS options in
GlobalProtect, traffic is also evaluated based on those DNS options.
After the traffic is processed, it is then sent to GlobalProtect, direct to the internet, or to Explicit
Proxy, based on the PAC file and VPN processing.
The following figure shows a mobile user attempting to access a private resource using the URL
internal-app.corp.com.

• The PAC file has the following configuration to allow internal-app.corp.com to bypass
Explicit Proxy.

/* Bypass internal URL */

Prisma Access Administrator’s Guide (Panorama Managed) 237 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

if (shExpMatch(host, "*internal-app.corp.com"))
return "DIRECT";

• When the mobile user requests internal-app.corp.com from their browser, the browser
evaluates the conditions in the PAC file. Based on that evaluation, the browser does not
forward the request to the proxy and sends it directly to the GlobalProtect app.
• GlobalProtect notes that internal-app.corp.com is listed in the Include Domain and
sends it through the VPN tunnel.
• GlobalProtect sends the request to the resource in internal-app.corp.com based on the
configuration options in GlobalProtect.
You might want to configure some resources, such as login resources, so that they do not use
either Explicit Proxy or the GlobalProtect or third-party VPN for processing. The following figure
shows a user logging in to Microsoft Online by entering login.microsoftonline.com from
their browser.

• The PAC file has the following configuration to allow internal-app.corp.com to bypass
Explicit Proxy traffic.

/* Bypass internal URL */

if (shExpMatch(host, "login.microsoftonline.com"))
return "DIRECT";

• When the mobile user requests login.microsoftonline.com from their browser, the PAC
file evaluates the request from the PAC file in the mobile user’s endpoint and then sends it to
the GlobalProtect VPN configuration (GlobalProtect in this case) for processing.
• The GlobalProtect app notes that login.microsoftonline.com is listed in the Exclude
Domain.
• GlobalProtect bypasses the VPN and sends the request direct to the internet, based on the
configuration options in GlobalProtect.

Prisma Access Administrator’s Guide (Panorama Managed) 238 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Requirements and Recommendations for Using Explicit Proxy with

GlobalProtect and Third-Party VPNs
Before you start your configuration, make sure that you follow the requirements and
recommendations that are required to deploy Explicit Proxy with GlobalProtect or with a third-
party VPN:
• To use Explicit Proxy with GlobalProtect, you must deploy GlobalProtect (either a Mobile Users
—GlobalProtect deployment or a standalone GlobalProtect deployment that uses GlobalProtect
gateways and portals.
You configure a split tunnel configuration in GlobalProtect. The examples in this section show
traffic being split based on a domain (URL) or application; however, you can also split traffic
based on the access route.
You can also configure split DNS options in GlobalProtect to configure which domains are
resolved by the VPN assigned DNS servers and which domains are resolved by the local DNS
servers.
• To use Explicit Proxy with a third-party VPN, you must deploy the VPN solution.
• Make a list of the applications that you want to secure with the Mobile Users—GlobalProtect
or third-party VPN deployment.
For example, if you are configuring Explicit Proxy with GlobalProtect, you should configure
GlobalProtect to secure all access to private apps or resources, while configuring the Explicit
Proxy PAC file to secure public apps or SaaS applications. The configuration examples in this
section have GlobalProtect resolving the internal domains and Explicit Proxy resolving external
domains.
• Configure authentication for Explicit Proxy and GlobalProtect or the third-party VPN.
• For Explicit Proxy, you must use SAML authentication. Follow the guidelines for configuring
SAML in an Explicit Proxy deployment, including the URLs to use for SAML sign-on.
• For Mobile Users—GlobalProtect deployments, if you use SAML authentication with Okta
as the Identity Provider (IdP), see the procedure you use to configure SAML authentication
using Okta in the Prisma Access Integration Guide (Panorama Managed).
• For standalone GlobalProtect deployments, you can configure SAML authentication in PAN-
OS.
• For a third-party VPN, refer to the product documentation for that VPN.
Palo Alto Networks recommends that you use the default browser on each mobile user’s
endpoint for SAML authentication so you can take advantage of single sign-on (SSO) by editing
the portal configuration as shown in Secure Mobile Users with an Explicit Proxy.
• You must make sure that the browsers used by the mobile users honor the configuration in the
PAC file. See Planning Checklist—Explicit Proxy for Explicit Proxy browser restrictions.

Use Explicit Proxy with GlobalProtect

To implement GlobalProtect—Mobile Users with Explicit Proxy, complete the following steps.
These configuration steps make the following assumptions about your network environment; if
your network environment is different, the configuration might be different:

Prisma Access Administrator’s Guide (Panorama Managed) 239 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

• Mobile users are able to reach and resolve the GlobalProtect portal hostname, gateway
FQDNs, Explicit Proxy URL, and PAC File URL.
• To find the gateway FQDNs, select Panorama > Cloud Services > Status > Network Details
> Mobile Users—GlobalProtect > Gateways.
• To find the PAC File URL, select Panorama > Cloud Services > Configuration > Mobile
Users—Explicit Proxy > PAC File URL.

• Mobile Users are able to resolve internal domains from GlobalProtect.

STEP 1 | Plan your Mobile Users—Explicit Proxy deployment and your GlobalProtect deployment
(either your Mobile Users—GlobalProtect or standalone GlobalProtect deployment).

STEP 2 | Decide which applications you want to send to GlobalProtect and which applications you
want to send to Explicit Proxy.
The following steps direct private applications hosted at your data center to GlobalProtect and
requests to internet and public SaaS applications to Explicit Proxy.

STEP 3 | In the Panorama that manages Prisma Access, configure GlobalProtect portal settings.
1. Select Network > GlobalProtect > Portals.
Be sure that you are in the Mobile_User_Template from the Template drop-down.
2. Select GlobalProtect_Portal to edit the Prisma Access portal configuration.
3. Select the Agent tab and select the DEFAULT configuration or Add a new one.
4. Select the App tab.
5. Make the following app configuration changes:
• In Detect Proxy for Each Connection, select Yes.
• In Set Up Tunnel Over Proxy (Windows & Mac Only), select No.
• In Use Default Browser for SAML Authentication, select Yes.

Prisma Access Administrator’s Guide (Panorama Managed) 240 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 4 | Create a split tunnel in GlobalProtect that allows you to direct the internal traffic to
GlobalProtect.
The following example uses a split tunnel to direct traffic based on domain (FQDN); you could
also configure a split tunnel based on the access route of traffic.
1. While you are still in the GlobalProtect Agent configuration (Network > GlobalProtect >
Gateways > GlobalProtect External Gateway), select Agent > Client Settings.
2. Select the DEFAULT configuration or Add a new one.
3. Select Split Tunnel > Domain and Application.
4. Add the Include Domain and, optionally, the Ports to use with the domain.
This example uses internal-app.corp.com as the URL you use to host apps in your data
center. You add this URL and the SAML authentication URL in the Exclude Domain.

5. Click OK to save your changes.

6. Commit and Push your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 241 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 5 | Configure the PAC file to exclude the domains you entered for split tunnel.
The following example shows a PAC file with the URL that hosts private apps (internal-
app.corp.com) bypassing the internal proxy. The parameters in the following PAC file are all
example values:
• The portal hostname is splittunnel.gpcloudservice.com.
• The mobile user gateways (Panorama > Cloud Services > Status > Network Details
> Mobile Users—GlobalProtect > Gateways) are contained in the wildcard FQDN
*examplegateways.gw.gpcloudservice.com.
• The PAC File URL (Panorama > Cloud Services > Configuration > Mobile Users—Explicit
Proxy > PAC File URL) is https://pacfileurl.pac.
• internal-app.corp.com is hosting the private apps that are being protected by Mobile
Users—GlobalProtect.
• Okta is being used for SAML authentication.
• The Explicit Proxy URL is example.proxy.prismaacess.com.
For more information about what PAC files do and how to create and modify them, see Set Up
Your Explicit Proxy PAC File.

function FindProxyForURL(url, host) {

/* Bypass FTP */
if (url.substring(0,4) == "ftp:")
return "DIRECT";
/* Bypass the Prisma Access Portal Hostname */
if (shExpMatch(host, "*.splittunnel.gpcloudservice.com"))
return "DIRECT";
/* Bypass the Prisma Access Gateway */
if (shExpMatch(host,
"*examplegateways.gw.gpcloudservice.com"))
return "DIRECT";
/* Bypass the Prisma Access PAC File URL */
if (shExpMatch(host, "https://pacfileurl.pac"))
return "DIRECT";
/* Bypass the URLs Being Sent to the GlobalProtect Portal */
if (shExpMatch(host, "*.internal-app.corp.com"))
return "DIRECT";
/* Bypass ACS */
if (shExpMatch(host, "*.acs.prismaaccess.com"))
return "DIRECT";
/* Forward to Prisma Access */
return "PROXY example.proxy.prismaaccess.com:8080";
}

Use Explicit Proxy with Third-Party VPNs

To use third-party VPNs with Explicit Proxy, you have be able to make the following changes in
your network:

Prisma Access Administrator’s Guide (Panorama Managed) 242 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

• You must configure your third-party VPN to perform split tunneling to direct internet traffic to
Explicit Proxy.
For any assistance with configuring your third-party VPN, contact your third-party VPN
vendor.
• modify the PAC file to have Explicit Proxy bypass any of the following VPN components:
• Any IP addresses associated with the third-party VPN
• Any login URLs required for the third-party VPN
In the following example, you configured the PAC file so that Explicit Proxy bypasses internal
resources using private IP addresses, as well as authentication traffic flows.

++++++++++++++++
function FindProxyForURL(url, host) {
if (isPlainHostName(host) ||
shExpMatch(host, "*.local") ||
isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0"))
return "DIRECT";
/* Bypass SAML for AnyConnect Azure */
if (shExpMatch(host, "login.microsoftonline.com"))
return "DIRECT";
if (shExpMatch(host, "login.windows.net"))
return "DIRECT";
if (shExpMatch(host, "login.microsoft.com"))
return "DIRECT";
/* Forward to Prisma Access */
return "PROXY example.proxy.prismaaccess.com:8080";
}

Prisma Access Administrator’s Guide (Panorama Managed) 243 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Integrate Prisma Access with On-Premises Gateways

Prisma Access enables you to extend the Palo Alto Networks security platform out to your remote
network locations and your mobile users without having to build out your own global security
infrastructure and expand your operational capacity. In cases where you have already deployed
GlobalProtect gateways in regions where you already have the infrastructure to manage it, you
can leverage this investment by configuring Prisma Access to direct mobile users to your existing
external gateways when appropriate.
You can Manage Priorities for Prisma Access and On-Premises Gateways, which allow you to
specify priorities for on-premises and Prisma Access gateways. Administrators cannot specify
mobile users to connect to a specific Prisma Access gateway; however administrators can Allow
Mobile Users to Manually Select Specific Prisma Access Gateways using the GlobalProtect app.

You cannot use your own portal with Prisma Access. You can only use the portal that is
deployed when your Prisma Access for mobile users is provisioned.

To configure one of these hybrid Prisma Access deployments, you must edit the
GlobalProtect_Portal configuration within the Mobile_User_Template to add your on-premises
gateways to the appropriate regions:
STEP 1 | Edit the Prisma Access portal configuration.
1. To add an existing gateway to the list of available gateways, select Network >
GlobalProtect > Portals.
2. Select Mobile_User_Template from the Template drop-down.
3. Select GlobalProtect_Portal to edit the Prisma Access portal configuration.

Prisma Access Administrator’s Guide (Panorama Managed) 244 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 2 | Add your on-premises gateway to the list of gateways in the agent configuration.
1. Select the Agent tab and select the DEFAULT agent configuration or Add a new one.
2. Select the External tab and Add your on-premises gateway.

If you add a new agent configuration and you want to add the Prisma Access
gateways to the list of external gateways in that configuration, you must set
the Name to Prisma Access (existing deployments might use the name GP cloud
service) and the Address to gpcloudservice.com. You must enter these values
exactly as shown, and you cannot use either of these values for non-Prisma
Access gateways.
3. Enter the Name of the gateway and specify either the FQDN or IP address of the
gateway in the Address field; this value must exactly match the common name (CN) in
the gateway certificate.
4. (Optional) If you want mobile users to only connect to the gateway when they are in the
corresponding region, Add the Source Region to restrict the gateway to. For example,
if you have a gateway in France, you would select FR (France). If you have a gateway in
Sweden, you would select (SE) Sweden.
One benefit of this is that users will then be able to access a gateway that enables access
to internet resources in their own language.
5. Configure other agent settings as necessary to complete the agent configuration.
6. Click OK to save the portal configuration.

Prisma Access Administrator’s Guide (Panorama Managed) 245 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 3 | Commit all your changes to Panorama and push the configuration changes to Prisma Access.
1. Click Commit > Commit to Panorama.
2. Click Commit > Push to Devices and click Edit Selections.
3. On the Prisma Access tab, make sure Prisma Access for users is selected and then click
OK.

4. Click Push.

Prisma Access Administrator’s Guide (Panorama Managed) 246 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Manage Priorities for Prisma Access and On-Premises

Gateways
Prisma Access enables you to extend the Palo Alto Networks security platform out to your mobile
users. In a hybrid deployment where your enterprise uses Integrate Prisma Access with On-
Premises Gateways, you can set priorities in Prisma Access to let mobile users connect to either a
specific on-premises GlobalProtect gateway or a Prisma Access gateway.
You can select an on-premises gateway that is physically closest to your mobile users and allow
users to connect to a different gateway (either on-premises or cloud) to ensure secure access for
mobile users if they change locations. You can also specify priority for gateways that are in the
same country or same linguistic area as your mobile users.

If you add on-premises gateways to your Prisma Access deployment, check to see if the
priority for the Prisma Access gateways is set to None and, if it is, change the priority. If
the priority is set to None, the service will not select a gateway. See Configure Priorities
for Prisma Access and On-Premises Gateways to change the priority of your Prisma
Access gateways.

If you require users to connect to a specific Prisma Access gateway, you can Allow Mobile Users
to Manually Select Specific Prisma Access Gateways. Mobile users choose one of the Prisma
Access gateways using the GlobalProtect app that is installed on their endpoint.
Complete the following workflow to configure gateway priorities in Prisma Access.
• Set Equal Gateway Priorities for On-Premises and Prisma Access Gateways
• Set a Higher Gateway Priority for an On-Premises Gateway
• Set Higher Priorities for Multiple On-Premises Gateways
• Configure Priorities for Prisma Access and On-Premises Gateways
• Allow Mobile Users to Manually Select Specific Prisma Access Gateways

Set Equal Gateway Priorities for On-Premises and Prisma Access

Gateways
To enable secure access for your mobile workforce no matter where they are located, you can set
equal priorities for the on-premises GlobalProtect gateways and the Prisma Access gateways. The
GlobalProtect app uses Gateway Priority in a Multiple Gateway Configuration to determine the
preferred gateway.
You can use this configuration if your mobile users are most often closer to an on-premises
gateway. When users change locations, the GlobalProtect app chooses another gateway (either
on-premises or Prisma Access gateway) based on the highest priority and lowest response time.
The following figure shows a sample configuration with two mobile users in North America. You
set the gateway priority to Highest for both the Prisma Access gateways and the on-premises
gateways.
In this example, User 1’s GlobalProtect app determines that the Prisma Access gateway has a
lower response time than the on-premises gateway, and user 2’s GlobalProtect app determines

Prisma Access Administrator’s Guide (Panorama Managed) 247 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

that the on-premises gateway has a lower response time. Since all gateways have the same
priority, User 1 connects to the Prisma Access gateway and User 2 connects to the on-premises
gateway, based on the lower response time.

Set a Higher Gateway Priority for an On-Premises Gateway

In situations where you want to direct mobile users to use an on-premises gateway instead of
the Prisma Access gateways, specify the on-premises gateways with a source region and a higher
priority than the Prisma Access gateway.
The following figure shows a sample configuration for mobile users in Indonesia. To avoid the
possibility of mobile users being connected to the nearest Prisma Access gateway in Singapore,
you set the gateway priority to Highest for the on-premises gateway in Indonesia and set the
priority to Medium for the Prisma Access gateways.
This example also specifies a source region of Indonesia for the on-premises gateway. We
recommend specifying a source region for the following reasons:
• Specifying a source region for an on-premises gateway allows users in a region to access that
gateway and prevents users outside of that region from connecting to that gateway. In this
example, only mobile users in Indonesia can connect to the on-premises gateway with the
source region of Indonesia, and the higher priority means that the on-premise gateway has
priority over the Prisma Access gateways.
• If you set a source region of Any for the on-premises gateway in Indonesia, every mobile user
in your organization would prefer the on-premises gateway in Indonesia, because of its higher
priority and worldwide accessibility. This configuration means that mobile users might never
connect to the Prisma Access gateways.

Prisma Access Administrator’s Guide (Panorama Managed) 248 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Set Higher Priorities for Multiple On-Premises Gateways

To ensure that traffic to the internet stays in language-specific regions, you can configure multiple
gateways in multiple source regions, setting the priority of the on-premise gateways to Highest
and the priority of the Prisma Access gateways to Medium.
The following figure shows a sample configuration for mobile users in Scandinavia. Using this
configuration, when the mobile users access internet websites, the websites use the character
encoding set that is specific to their languages.
In this example, you configure on-premises gateways with source regions in Denmark, Norway,
and Sweden. You set the priority of those gateways to Highest and set the priority of the Prisma
Access gateways to Medium. Specifying a source region for the on-premises gateways allows
users in those regions to access those gateways, and prevents users outside of those regions from
connecting to those gateways.
In this example, the GlobalProtect app for mobile users in Sweden selects the on-premises
gateway in Sweden because of the source region and higher gateway priority.

Prisma Access Administrator’s Guide (Panorama Managed) 249 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Configure Priorities for Prisma Access and On-Premises Gateways

Use this workflow to configure priorities for a deployment that uses on-premises gateways with
Prisma Access.
STEP 1 | Log in to Prisma Access.

STEP 2 | Select Network > GlobalProtect > Portals in the Mobile_User_Template template.

STEP 3 | Click the portal name in the Name field.

Prisma Access Administrator’s Guide (Panorama Managed) 250 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 4 | Click the Agent tab.

STEP 5 | Click the name of the agent to configure.

The default agent is named DEFAULT.

STEP 6 | Click the External tab.

Prisma Access Administrator’s Guide (Panorama Managed) 251 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 7 | Set the priority of the Prisma Access gateways.

1. Click Prisma Access.
Some existing deployments might use GP Cloud Service in this field; if so, select this.
2. Set the priority for your preferred configuration.
• To Set Equal Gateway Priorities for On-Premises and Prisma Access Gateways,
change the priority from None to Highest.
• To Set a Higher Gateway Priority for an On-Premises Gateway or Set Higher
Priorities for Multiple On-Premises Gateways, change the priority from None to
Medium.

3. Be sure that the Manual check box is selected.

Checking the Manual check box ensures that mobile users can select a specific Prisma
Access gateway if it is required.

Prisma Access Administrator’s Guide (Panorama Managed) 252 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Do not add a source region for the Prisma Access gateways; any region you
specify is not applied to the configuration.
4. Click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 253 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 8 | Add one or more on-premises external gateways to your configuration.

1. Enter a descriptive Name for the gateway.
The name you enter should match the name you defined when you configured the
gateway, and it should be descriptive enough for users to know the location of the
gateway to which they connect.
2. Enter the FQDN or IP address of the interface where the gateway is configured in the
Address field.
You can configure an IPv4 address. The address you specify must exactly match the
Common Name (CN) in the gateway server certificate.
3. Add one or more Source Regionsfor the on-premises gateway, or select Any to make the
gateway available to all regions.

If you set the priority of on-premises external gateways higher than Prisma
Access gateways, we recommend that you specify source regions for the
external gateways. If you specify Any for the region, the GlobalProtect app
might never select Prisma Access gateways over on-premises gateways because
of the higher priority for the on-premises gateways.
4. Select the Manual check box to allow users to manually switch to the gateway.
5. Set the Priority of the on-premises gateway to Highest (the default).

Prisma Access Administrator’s Guide (Panorama Managed) 254 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

6. Click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 255 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Prisma Access Administrator’s Guide (Panorama Managed) 256 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 9 | (Optional) Set the priority for additional gateways by repeating Step 8.

Be sure to specify the correct source regions.

The following figure shows a sample configuration with multiple gateways that have source
regions in Norway, Sweden, and Denmark. Note that the Manual check box is selected, which
indicates that a mobile user can manually select any of these gateways.

Prisma Access Administrator’s Guide (Panorama Managed) 257 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Prisma Access Administrator’s Guide (Panorama Managed) 258 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Allow Mobile Users to Manually Select Specific Prisma Access

Gateways
When system administrators specify priorities for gateways in Panorama, they can only specify
priorities for all Prisma Access gateways as a whole.

When configuring the Prisma Access gateways, do not specify a source region. Any region
you specify is not applied to the configuration.

To choose a specific Prisma Access gateway, mobile users can select the gateway on their
endpoint from the drop-down list in their GlobalProtect app.

This configuration requires that you configure Manual selection of the gateway when you
Configure Priorities for Prisma Access and On-Premises Gateways.

The following figure shows a user choosing a list of Prisma Access gateways from the endpoint’s
GlobalProtect app.

The tasks you perform to connect to a specific gateway are based on the operating system of
your endpoint. For details, see the GlobalProtect App User Guide.

Prisma Access Administrator’s Guide (Panorama Managed) 259 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Allow Listing for Mobile Users—GlobalProtect

Deployments
To enable you to add the public (egress) IP addresses for your GlobalProtect—Mobile User
deployment to any SaaS application allow lists you use within your organization, Prisma Access
provides the IP addresses and lets you verify that you have added them to your allow list
before using them in your environment. After you have added the egress IP addresses to your
organization’s allow lists, you return to the Prisma Access UI, confirm the GlobalProtect egress IP
addresses as being allow listed, and Commit and Push your changes. Prisma Access then releases
these egress IP addresses and adds them to your deployment. If Prisma Access adds more IP
addresses after initial configuration as a result of an autoscale event, you confirm the new egress
IP addresses as being added before Prisma Access adds them to your deployment.
This method of egress IP address allocation has the following benefits:
• It ensures that Prisma Access only provisions IP addresses that you have allow listed.
• It prevents mobile users from attempting to connect to Prisma Access from an IP address that
is blocked by your organization’s network. Prisma Access does not release IP addresses to your
deployment until they have been confirmed by you as allow listed.
• It provides a way to retrieve your current egress IP addresses without using the Prisma Access
API.
Prisma Access allocates egress IP addresses in the following situations:
• When you onboard your locations during mobile user onboarding.
Prisma Access allocates two gateway IP addresses for each location you onboard.

If you onboard a location, and other locations in the same compute location are
experiencing an autoscale event, Prisma Access might allocate more than two IP
addresses for the new location. In this situation, be sure that you add all these IP
addresses to your allow lists and confirm all addresses as being Added to My Allow
List.
• During a large scaling event.
If the number of mobile users exceeds the capacity of the two pre-allocated IP addresses,
Prisma Access allocates one more set of two IP addresses.
Autoscale events affect all the onboarded locations in a compute location. When an autoscale
event occurs for a location and you have not yet confirmed the addresses as being added to
your allow lists, all locations in that compute location will show an Autoscale Status of Not
Allowed.

To keep informed of any IP addresses that Prisma Access adds as a result of an

autoscale event, you can set up a URL where Prisma Access will notify you of IP
address changes.
You are not required to enable this functionality; you choose whether or not to let Prisma Access
release the IP addresses until you have confirmed them as being allow listed in the UI.

Prisma Access Administrator’s Guide (Panorama Managed) 260 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Manage Allow Listing for Existing Mobile User Deployments

If you have an existing Prisma Access deployment with a version earlier than 3.0 and are
upgrading to a version of Prisma Access that supports the allow listing functionality, Prisma
Access allows you to use the egress IP addresses you have already been provisioned with no
further configuration.
If you do not need to use the allow listing functionality in your Prisma Access deployment, take
no action. The mobile user onboarding and procedure is unchanged and Prisma Access allocates
egress IP addresses as before. The only difference is the addition of an Egress IP Allow List table
in the Panorama > Cloud Services > Configuration > Mobile Users—GlobalProtect area; however,
this table will be empty because you are not using the allow listing functionality.
If you want to enable the allow listing functionality for an existing Prisma Access deployment,
complete the following steps.
STEP 1 | Select Panorama > Cloud Services > Configuration > Mobile Users—GlobalProtect.

STEP 2 | Select your Hostname and Configure it (for an existing deployment), or Configure your
deployment for the first time (for a new deployment).

STEP 3 | Specify Using IP Allow List in SaaS Apps as Yes.

STEP 4 | Commit and Push your changes to enable the allow listing functionality.
Make a note of the following changes to that occur after you enable allow listing and commit
and push your changes:
• Prisma Access confirms any egress IP addresses you are already using as being allow listed.
• Prisma Access will not provision any new egress IP addresses that are allocated during
onboarding or autoscale events until you confirm them as allow listed. See Manage Allow
Listing for New Prisma Access Deployments for the procedure you use to do so.

Prisma Access Administrator’s Guide (Panorama Managed) 261 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Manage Allow Listing for New Prisma Access Deployments

To prevent Prisma Access from provisioning public (egress) GlobalProtect IP addresses to your
deployment until you have added them to your allow lists, specify Yes in the Using IP Allow List in
SaaS Apps setting during Mobile Users—GlobalProtect onboarding. Confirm that you have added
them in the Prisma Access UI by completing the following task.
STEP 1 | Select Panorama > Cloud Services > Configuration > Mobile Users—GlobalProtect.

STEP 2 | Select your Hostname and Configure it (for an existing deployment), or Configure your
deployment for the first time (for a new deployment).

STEP 3 | Specify Using IP Allow List in SaaS Apps as Yes.

STEP 4 | Continue your Prisma Access onboarding, including selecting the locations to use in your
Mobile Users—GlobalProtect deployment, and Commit and Push your changes.
It might take up to a minute for the changes to be reflected in the UI. If you view the Egress
IP Allow List before committing and pushing your changes, it shows a status of 0/0 Egress IPs
Confirmed Allow Listed, because Prisma Access has not assigned any egress IP addresses to
your deployment.

STEP 5 | View the Egress IP Allow List table, and make a note of the egress IP addresses that need to
be added to your allow lists.
You can view the egress IP addresses in the Confirmed Allow Listed Egress IPs / Allocated
field of the Egress IP Allow List table. The first number indicates whether or not the IP address

Prisma Access Administrator’s Guide (Panorama Managed) 262 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

has been confirmed as being added to your allow lists. For a description of the other fields in
this table, see Fields in the Egress IP Allow List table.
The following example shows the IP addresses for the US Northeast location. The description
of 0/2 Egress IPs Confirmed Allow Listed indicates that 0 of the two egress IP
addresses have been marked as being added to your allow lists, and you need to add them.

If you have a new Prisma Access deployment, or if you have added locations or had an
autoscale event, the table shows that none of the egress IP addresses have been added to your
organization’s allow list.

If you have an existing Prisma Access deployment, the table shows a Provisioning Status of
Provisioned and an Autoscale Status of Allowed, which indicates that Prisma Access marked
the egress IP addresses as added.

Prisma Access will allocate two addresses for each newly-added location. If an existing location
has previously had an autoscale event when a large number of mobile users logged in to
a single location at the same time, Prisma Access allocates additional egress IP address in
multiples of two, and an existing location could have four or more addresses.

STEP 6 | Find the new egress IP addresses that need to be added to your organization’s allow lists by
selecting the Location name in the table.

STEP 7 | Add these egress IP addresses to your organization’s allow lists.

Prisma Access Administrator’s Guide (Panorama Managed) 263 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

STEP 8 | After you have allow listed the egress IP address, return to the egress IP area and indicate
that you have added them to your allow lists by selecting Added to My Allow List.

STEP 9 | Commit and push your changes to make them active in Prisma Access.
1. Select Commit > Commit and Push and Edit Selections in the Push Scope.
2. Select Prisma Access, then make sure that Mobile Users is selected.

3. Click OK to save your changes to the Push Scope.

4. Commit and Push your changes.
If you view the Egress IP Allow List table before committing and pushing your changes, the
Confirmed column shows a status of 0/0 Egress IPs Confirmed Allow Listed because Prisma
Access has not assigned any IP addresses to your deployment until you Commit and Push.

After you Commit and Push, the Confirmed column will show a status of 0/2 Egress IPs
Confirmed Allow Listed, because you have not yet confirmed the IP addresses as having been
allow listed in the Prisma Access UI.

Allow Listing Examples for Autoscale Events

When you onboard a mobile user location, Prisma Access provides you with two egress IP
addresses - one active IP address and one address to use in case of an autoscale event. The
following provides examples of how Prisma Access allocates and provisions egress IP addresses
after an autoscale event.
Autoscale Event—If a large number of mobile users log in to a mobile user location at the
same time, that event might cause Prisma Access to allocate an additional set of two egress IP
addresses to accommodate the large number of users. After you have allow listed the first two
egress IP addresses, the status before an autoscale event shows the two egress IP addresses
as being allow listed with a confirmed status of 2/2 Egress IPs Confirmed Allow Listed, a
provisioning status of Provisioned, and an autoscale status of Allowed, as shown in the Hong
Kong location in the following screenshot.

Prisma Access Administrator’s Guide (Panorama Managed) 264 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

If a large number of mobile users log in to the Hong Kong location at the same time, Prisma
Access makes the backup egress IP address active and allocates two more IP addresses and
makes one of them active. When an autoscale event occurs, the egress IP addresses have been
allocated but not provisioned, the confirmed status is 2/4 Egress IPs Confirmed Allow Listed, and
the provisioning status shows Provisioned without enough capacity. In addition, the autoscale
status shows Not Allowed, which means that Prisma Access will not provision the extra egress IP
address to your deployment if an autoscale event occurs.

After you have added the new egress IP addresses to your allow lists, select the location name;
then, select Added to My Allow List for the two IP addresses that were added and Commit and
Push your changes.

When complete, the Hong Kong location shows that all four egress IP addresses are confirmed
and provisioned, and autoscaling is active.

Fields in the Egress IP Allow List table

The Egress IP Allow List table is located in Panorama > Cloud Services > Configuration > Mobile
Users—GlobalProtect.

Prisma Access Administrator’s Guide (Panorama Managed) 265 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

The Egress IP Allow List table contains the following fields:

Field Description

Location The onboarded mobile user location.

Confirmed Allow Listed Egress IPs / The number of egress IP addresses that have
Allocated been confirmed as being allow listed, and the
number of egress IP addresses that have been
allocated.

Provisioning Status The allow listing status of the egress IP

addresses.
• Provisioned—You have added the egress IP
addresses to your organization’s allow lists,
have confirmed them as having been added
in the Prisma Access UI by checking Added
to My Allow List, and have committed and
pushed your changes to make them fully
provisioned.
• Not Provisioned—Prisma Access has
allocated IP addresses for the location, and
you have added the egress IP addresses to
your organization’s allow lists and confirmed
them as having been added in the Prisma
Access UI, but you have not yet onboarded
this location.

Prisma Access Administrator’s Guide (Panorama Managed) 266 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Field Description
• Cannot Be Provisioned—You have
onboarded this location, but have not
yet checked Add to My Allow List and
committed and pushed your changes.
Until you specify in Prisma Access that
you have added these egress IPs to your
organization’s allow lists and Commit and
Push your changes, Prisma Access will
not provision these IP addresses to your
deployment.
• Provisioned with partial capacity—You have
added the first set of egress IP addresses,
have confirmed them as having been added
in the Prisma Access UI, and have Committed
and Pushed your changes. However, Prisma
Access has added another set of IP addresses
as part of an autoscale event, and those IP
addresses have not been specified as added
to your allow lists in the Prisma Access UI.
The following screenshot shows an example
of a deployment that would be marked as
Provisioned with partial capacity. Two IP
addresses have been marked as Added to
My Allow List; however, Prisma Access
has added two more IP addresses to this
location, and those locations have not been
added in the UI.

Autoscale Status Shows the status of the autoscaling in Prisma

Access.
• Allowed—You have added all IP addresses
to the allow lists. If a large number of mobile

Prisma Access Administrator’s Guide (Panorama Managed) 267 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Field Description
users log in to a single location and trigger an
autoscale event, Prisma Access will use the
allow listed IP addresses for the autoscale
event.
• Not Allowed—You have not specified all IP
addresses as being added to your allow lists
in the Prisma Access UI, or you have not
committed and pushed your changes after
marking them as added. If Prisma Access
triggers an autoscale event, Prisma Access
will not provision more IP addresses to add
more capacity for the location.
Every time that you add a location, or every
time that Prisma Access adds IP addresses as
a result of an autoscale event, you need to
refresh the page that contains the Egress IP
Allow List table, specify Added to My Allow
List to mark the IP addresses as being added
to your organization’s allow lists, and Commit
and Push your changes.

To keep informed of any IP

addresses that Prisma Access adds
as a result of an autoscale event,
you should set up a URL where
Prisma Access will notify you of IP
address changes.

Timestamp The last known time when an IP was allocated

for this region in Coordinated Universal Time
(UTC).

Prisma Access Administrator’s Guide (Panorama Managed) 268 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

Report Prisma Access Website Access Issues

Some websites such as stubhub.com, ticketmaster.com, or dollartree.com, block traffic from the
AWS cloud IP address range. When users who are secured by Prisma Access attempt to access
these websites, they can be denied access with the following message on the web browser:

Access Denied.

You don't have permission to access "http://www.dollartree.com/" on

this server. Reference #18.7f955b8.1509600370.44eb7c8

To report this problem, enter https://reportasite.gpcloudservice.com/ from a web browser

and provide the URL of the website that is inaccessible. After 24-48 hours, return to https://
reportasite.gpcloudservice.com/ and enter the same URL to see its status.
Palo Alto Networks provides you with the IP address that is used by the URL; in some cases, you
must add this IP address to your organization’s allow lists so that this traffic is not blackholed. If
you have URLs that get redirected, add these IP addresses to your allow lists:
• 65.154.226.160
• 154.59.126.110
• 66.232.36.110
Prisma Access URL Redirect Process
Some websites block traffic from a cloud IP address range. When users who are secured by
Prisma Access attempt to access these websites, they can be denied access. In order to ensure
that access to these websites is restored, Palo Alto Networks reviews all such reported sites and,
if an access issue is found, categorizes the site and adds an egress policy that NATs the IP address
to one that can be accessed. Palo Alto Networks thoroughly reviews the sites to determine their
reputation and only websites with a pristine reputation are added to the egress rule, while the
others are rejected, using this process:
1. You notify us of the URL with access issues using https://reportasite.gpcloudservice.com/.
2. Site Reliability Engineering (SRE) automation reviews the URL.

Prisma Access Administrator’s Guide (Panorama Managed) 269 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Secure Mobile Users

3. If SRE determines the URL to be safe, a policy-based forwarding (PBF) rule is applied to the
URL and its parent domain.
4. The traffic is routed via Prisma Access from the GlobalProtect gateway or remote network to
a URL processing hub, where the PBF rule is applied to the domain, and from the hub to a Palo
Alto Networks data center.
5. As traffic egresses from the data center, the URL is source NATted to the IP address of the
data center.
As a result of these actions, traffic to and from the SaaS applications is not dropped because the
data center IP address has a clean reputation.

Prisma Access Administrator’s Guide (Panorama Managed) 270 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure
Branches
As you business scales and your office locations become geographically distributed, Prisma Access
for networks allows you to speedily onboard your remote network locations and deliver best-
in-breed security for your users. It offers a convenient option that removes the complexity in
configuring and managing devices at every remote location. The service provides an efficient
way to easily add new remote network locations and minimize the operational challenges with
ensuring that users at these locations are always connected and secure, and it allows you to
manage policy centrally from Panorama for consistent and streamlined security for your remote
network locations.
To connect your remote network locations to Prisma Access, you can use the Palo Alto Networks
next-generation firewall or a third-party, IPSec-compliant device including SD-WAN, that can
establish an IPSec tunnel to the service.
In addition to IPSec tunnel connectivity, Prisma SD-WAN lets you use a CloudBlade that you
onboard as a remote network to integrate the Prisma SD-WAN Controller and ION devices with
Prisma Access.
• Prisma Access Remote Network Deployments
• Onboard and Configure Remote Networks
• Plan to Migrate to an Aggregate Bandwidth Remote Network Deployment
• Remote Network Locations with Overlapping Subnets
• Configure Remote Network and Service Connection Connected with a WAN Link
• Use Predefined IPSec Templates to Onboard Service and Remote Network Connections
• Onboard Remote Networks with Configuration Import

271
Use Remote Networks to Secure Branches

Prisma Access Remote Network Deployments

Use remote networks to secure remote network locations, such as branches, and users in those
branches with cloud-based next-generation firewalls. You can enable access to the subnetworks
at each remote network location using either static routes, dynamic routing using BGP, or a
combination of static and dynamic routes. All remote network locations that you onboard are fully
meshed.Prisma Access for networks allows you to pick the geographic locations where you want
to deploy Prisma Access to secure your remote network locations.

Prisma Access Administrator’s Guide (Panorama Managed) 272 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Planning Checklist—Prisma Access Remote Networks

Before you begin to onboard remote networks, make sure you have the following configuration
items ready to ensure that you will be able to successfully enable the service and enforce policy
for users in your remote network locations:
Aggregate Bandwidth Model—Bandwidth for your remote networks locations are allocated
at an aggregate level per compute location. Each location you onboard has a corresponding
compute location for which bandwidth is allocated. You allocate bandwidth per compute
location, instead of per location. This method is known as the aggregate bandwidth model.
The aggregate bandwidth model is available for all new deployments. If you have an existing
deployment that allocated bandwidth by location, you can migrate from allocating bandwidth
per location to allocating bandwidth per compute location.

Before you migrate to the aggregate bandwidth model, you should review the
migration checklist.

All locations you onboard share the allocated bandwidth for that compute location. For
example, you need to onboard four branch offices using remote networks in the Singapore,
Thailand, and Vietnam locations. All these locations map to the Asia Southeast compute
location. If you allocate 200 Mbps bandwidth to the Asia Southeast compute location, Prisma
Access divides the 200 Mbps of bandwidth between the four branch offices you onboarded in
that location. If you also add a location in Hong Kong, you note that Hong Kong maps to the
Hong Kong compute location, and you would need to add bandwidth to that compute location.
Specify a minimum bandwidth of 50 Mbps per compute location.
Prisma Access dynamically allocates the bandwidth based on load or demand per location.
Using the previous example where the four sites collectively use up to 200 Mbps, if one
or more sites are not using as much bandwidth as the other sites, Prisma Access provides
more bandwidth for the locations that are more in demand, giving you a more efficient use of
allocated bandwidth. In addition, if one of the sites goes down, Prisma Access reallocates the
bandwidth between the other sites that are still up in that compute location.
IPSec Termination Nodes—You assign an IPSec termination node to the remote network during
onboarding. Each IPSec termination node can provide you with a maximum of 1,000 Mbps of
bandwidth. If you allocate more than 1,000 Mbps of bandwidth to a compute location, Prisma
Access provides you with an additional IPSec termination node.
• IPSec Termination Nodes and Upgrades from Releases Earlier than 3.2—Before 3.2, one
IPSec Termination Node was allocated for every 500 Mbps of allocated bandwidth in a
compute location. If you have a remote network deployment earlier than 3.2 and upgrade
to a release that is 3.2.1 or later, and if remote network locations have more than 500
Mbps allocated to their corresponding compute location, every remote network associated
with the IPSec Termination Node can support up to 1,000 Mbps of bandwidth. After you
upgrade to 3.2 or later, Prisma Access deploys one IPSec Termination Node for every 1,000
Mbps of allocated bandwidth. For existing remote networks, Prisma Access can increase the
bandwidth for a remote network using an autoscaling mechanism that is triggered when the

Prisma Access Administrator’s Guide (Panorama Managed) 273 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

bandwidth consumption on the remote network requires additional capacity. See Changes
to Default Behavior in the Prisma Access (Panorama Managed) Release Notes for details.
The current IPSec termination node-to-remote network mapping after the upgrade to
3.2 is unchanged, and the number of IPSec Termination Nodes remain the same. IPSec
termination nodes are added or deleted only when you increase or decrease the bandwidth
for an existing compute location or when you onboard new compute locations for remote
networks.
Service Connection—If your remote network locations require access to infrastructure in your
corporate headquarters to authenticate users or to enable access to critical network assets,
you must create a service connection so that headquarters and the remote network locations
are connected. If the remote network location is autonomous and does not need to access to
infrastructure at other locations, you do not need to set up the service connection (unless your
mobile users need access).
Template—Prisma Access automatically creates a template stack
(Remote_Network_Template_Stack) and a top-level template (Remote_Network_Template)
for Prisma Access for networks. To Onboard and Configure Remote Networks, you will either
need to configure the top-level template from scratch or leverage your existing configuration,
if you are already running a Palo Alto networks firewall on premise. The template requires
the settings to establish the IPSec tunnel and Internet Key Exchange (IKE) configuration for
protocol negotiation between your remote network location and Prisma Access for networks,
zones that you can reference in security policy, and a log forwarding profile so that you can
forward logs from the Prisma Access for remote networks to Cortex Data Lake.
IPSec Tunnel Configurations—If you have an existing template that contains IPSec tunnel,
Tunnel Monitoring, and IPSec Crypto Profile configurations, you can add that template to the
Remote_Network_Template_Stack to simplify the process of creating the IPSec tunnels. Or,
you can edit the Remote_Network_Template that gets created automatically and create the
IPSec configurations required to create the IPSec tunnel back to the corporate site. Prisma
Access also provides you with a set of predefined IPSec templates for some commonly-used
network devices, and a generic template for any device that is not included in the predefined
templates. Be sure to following the IPSec tunnel recommendations when you configure the
remote network tunnel
Configure IP Subnets for Static Routing or BGP for Dynamic Routing—In order for Prisma
Access to route traffic to your remote networks, you must provide routing information for
the subnetworks that you want to secure using Prisma Access. You can do this in several
ways. You can either define a static route to each subnetwork at the remote network location,
or configure BGP between your service connection locations and Prisma Access, or use a
combination of both methods. If you configure both static routes and enable BGP, the static
routes take precedence. While it might be convenient to use static routes if you have just a
few subnetworks at your remote network locations, in a large deployment with many remote
networks with overlapping subnets, BGP will enable you to scale more easily.
Parent Device Group—Prisma Access for networks requires you to specify a parent device
group that will include your security policy, security profiles, and other policy objects (such as
application groups and objects, and address groups), as well as authentication policy so that
Prisma Access for networks can consistently enforce policy for traffic that is routed through
the IPSec tunnel to Prisma Access for networks. You will need to either define policy rules and

Prisma Access Administrator’s Guide (Panorama Managed) 274 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

objects on Panorama or use an existing device group to secure users in the remote network
location.

If you use an existing device group that references zones, make sure
to add the corresponding template that defines the zones to the
Remote_Network_Template_Stack. Doing so will allow you to complete the zone
mapping when you Onboard and Configure Remote Networks.

Prisma Access Administrator’s Guide (Panorama Managed) 275 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Onboard and Configure Remote Networks

For each remote network that you want to secure using Prisma Access for networks, you push the
required policy configuration to Prisma Access and onboard each remote network so that you can
start sending traffic from the remote site through the IPSec tunnel to Prisma Access.
Use one of the following procedures to onboard your remote networks depending on your
bandwidth allocation type:
• Allocate Bandwidth by Compute Location—The default mode of allocating bandwidth is by
compute location. This model is also known as the aggregate bandwidth model.
• Allocate Bandwidth by Remote Network Location—If you have a deployment that you
onboarded before Prisma Access 1.8 and have not yet migrated to the aggregate bandwidth
model, you allocate bandwidth by location.
If you currently allocate bandwidth by location, you can migrate to the aggregate bandwidth
model and allocate bandwidth by compute location; however, not all existing deployments can
migrate.
Before you begin onboarding your remote networks, be sure to go through the remote network
planning checklist.

Configure Prisma Access for Networks—Allocating Bandwidth by

Compute Location
To configure a Prisma Access remote network deployment that allocates bandwidth by compute
location, complete the following steps.

If you need to onboard many remote networks (up to 1,000), you can onboard a remote
network using the following procedure, then export the remote network configuration
to a CSV file, add the other remote networks you want to onboard to the CSV file, then
import the CSV file to save the configuration into Prisma Access.

STEP 1 | Select Panorama > Cloud Services > Configuration > Remote Networks and edit the settings
by clicking the gear icon in the Settings area.
1. In the Templates section, Add any templates that contain configuration you want
to push to Prisma Access for networks. For example, if you have existing templates
that contain your zone configurations, or IPSec tunnel, IKE Gateway, or crypto profile
settings, you can add them to the predefined Remote_Network_Template_Stack to
simplify the onboarding process.
You can Add more than one template to the stack and then order them appropriately
using Move Up and Move Down. This is important because Panorama evaluates in the
stack from top to bottom, with settings in templates higher in the stack taking priority

Prisma Access Administrator’s Guide (Panorama Managed) 276 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

over the same settings specified in templates lower in the stack. Note that you cannot
move the default template from the top of the stack.

Although you can add existing templates to the stack from the plugin, you
cannot create a new template from the plugin. Instead, use the workflow to add
a new template.
2. Select the Parent Device Group for Prisma Access for remote networks. You can select
an existing device group or use Shared.
You will push all of the configuration—including the security policy, security profiles, and
other policy objects (such as application groups and objects, and address groups), HIP
objects and profiles and authentication policy—that Prisma Access for networks needs to
enforce consistent policy to your remote network users using the device group hierarchy
you specify here.

You don’t need to define all of the policy that you will push to the remote
network yet. Instead, configure the settings to onboard the remote site. You
can then go back and add the templates and device groups with the complete
configurations to push consistent policy out to your remote networks.
3. (Optional) If you have configured a next-generation firewall as a master device or added
a Cloud Identity Engine profile to make user and group information selectable in security

Prisma Access Administrator’s Guide (Panorama Managed) 277 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

policies, select User-ID Master Device or Cloud Identity Engine; then, select either the
Master Device or the Cloud Identity Engine profile that you created.
4. If you will be configuring remote networks that have overlapping subnets, select the
Overlapped Subnets check box to enable outbound internet access for those locations.
While configuring Remote Network Locations with Overlapping Subnets introduces
some limitations, it is acceptable in some cases (for example, if you want to add a guest
network at a retail store location).

Prisma Access Administrator’s Guide (Panorama Managed) 278 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 2 | (Optional) Configure DNS Proxy settings for your remote network.
Prisma Access allows you to specify DNS servers to resolve both domains that are internal to
your organization and external domains. If you do not specify any settings, Prisma Access does
not proxy DNS requests for remote networks.
1. In the Remote_Network_Device_Group device group, select Policies > Security and Add
a security policy rule with an Application of DNS and an Action of Allow to allow DNS
traffic.
Without a security policy rule to allow DNS traffic, DNS resolution does not occur.

2. If you configure Prisma Access to proxy the DNS requests from your remote networks,
update the DNS settings on all the endpoints in that network to use the Prisma Access
Remote Network DNS Proxy IP Address as the primary DNS server and use your DNS
server as secondary DNS server. You can get this DNS proxy IP from Panorama > Cloud
Services > Status > Network Details > Service Infrastructure.

3. Add one or more DNS Proxy settings, entering the following values:
• Select a Region from the drop-down at the top of the window.
Select Worldwide to apply the DNS settings globally, select a specific theater,
or select settings per location group (a group of locations that is smaller than the
theater). If you add multiple settings, the location group settings are used first, then
the theater settings, then the worldwide settings. Prisma Access evaluates the rules
from top to bottom in the list.
• Add one or more rules to configure the DNS settings for Internal Domains.
• Enter a unique Rule Name for the rule.
• you want your internal DNS server to only resolve the domains you specify, enter
the domains to resolve in the Domain List. Specify an asterisk in front of the
domain; for example, *.acme.com. You can specify a maximum of 1,024 domain
entries.
• If you have a Custom DNS server that can access your internal domains, specify
the Primary DNS and Secondary DNS server IP addresses, or select Use Cloud
Default to use the default Prisma Access DNS server.
• Specify the DNS settings for Public Domains.
• Use Cloud Default—Use the default Prisma Access DNS server.
• Same as Internal Domains—Use the same server that you use to resolve internal
domains. When you select this option, the DNS Server used to resolve public

Prisma Access Administrator’s Guide (Panorama Managed) 279 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

domains is same as the server configured for the first rule in the Internal Domains
section.
• Custom DNS server—If you have a DNS server that can access your public
(external) domains, enter the Primary DNS server address in that field.
(Optional) You can Add a DNS Suffix to specify the suffix that the client should use
locally when an unqualified hostname is entered that it cannot resolve, for example,
acme.local. Do not enter a wildcard (*) character in front of the domain suffix (for
example, acme.com). You can add multiple suffixes.
• If you want Prisma Access to proxy DNS requests, configure Configure values for the
use for UDP queries (the Interval to retry the query in seconds and the number of
retry Attempts to perform).
If you want Prisma Access to proxy DNS requests for your GlobalProtect users, you
must update your endpoints to use the Remote Network DNS Proxy IP Address as
the primary DNS server (Panorama > Cloud Services > Status > Network Details >
Service Infrastructure).
4. (Optional) Select Advanced RCODE Support to allow the primary DNS server to fail over
to the secondary DNS server if an RCODE 2 (SERVFAIL) and RCODE 5 (REFUSED) DNS
return code is received.
A DNS response code of SERVFAIL refers to a communication error with the primary
DNS server, and a DNS response code of REFUSED means that the primary DNS server
refused to provide the requested information. In both cases, the service fails over to the
secondary DNS server.

STEP 3 | (Optional) Enable QoS for your remote network deployment and specify a QoS Profile,
Guaranteed Bandwidth Ratio, the amount of Reserved for Guaranteed Bandwidth (Mbps)
bandwidth and, optionally, customize site options per location (Customize Per Site).
You enable QoS at a compute location level; however, you can specify to enable or disable
QoS on a per-site basis, and specify a QoS profile on a per-site basis, when you add your
remote network in a later step. Before you configure QoS, you should understand how QoS

Prisma Access Administrator’s Guide (Panorama Managed) 280 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

works for remote networks that allocate bandwidth by compute location, including specifying
the guaranteed bandwidth and customizing bandwidth per site.

STEP 4 | (Optional) Configure Group Mapping Settings to have Prisma Access use the Directory Sync
component of the Cloud Identity Engine to retrieve user and group information.
You must configure the Cloud Identity Engine to retrieve user and group information from
your Active Directory (AD) before you enable group mapping in Prisma Access using Group
Mapping Settings.

STEP 5 | Create new zones in the one of the templates in the stack (Network > Zones> Add) or map
the zones referenced in existing templates you added to the stack as trusted or untrusted.
On Panorama, policy rules are defined in device groups, and zones are defined in templates.
Therefore, you need to make sure that you add the templates that reference the zones
included in your policy rules to the template stack.
On a Palo Alto Networks® next-generation firewall, security policy is enforced between zones,
which map to physical or virtual interfaces on the firewall. But as Prisma Access for networks
has only two zones, trust and untrust, you need to map any zone with traffic bound to the
Internet (including your sanctioned SaaS applications) as untrust and all internal zones as trust.
1. (Optional) Edit the zone mapping settings.
By default, all of the zones in Prisma Access for networks template stack a are classified
as Untrusted Zones. If you have not yet defined zones or if the templates in the
Remote_Network_Template_Stack do not have zone configurations, you can come back
and add them when you push policy to Prisma Access for networks.
2. For each zone you want to designate as trusted, select it and click Add to move it to the
list of Trusted Zones.
3. Click OK to save the mappings.

Prisma Access Administrator’s Guide (Panorama Managed) 281 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 6 | Allocate bandwidth for the locations that you want to onboard by clicking the gear icon in
the Bandwidth Allocation area.
You allocate bandwidth at an aggregate level per compute location. See Prisma Access Remote
Network Deployments for details.

If you have removed Autonomous DEM as an add-on license, or if you remove

Autonomous DEM for remote networks from your license, select Disable Autonomous
DEM. If you remove Autonomous DEM for remote networks and do not disable
Autonomous DEM, you will receive an error upon commit.

If you have an existing remote networks deployment that currently onboards remote networks
by location, a pop-up window displays, asking if you want to migrate to the aggregate
bandwidth model. Click Migrate to continue, or Cancel to cancel the migration.

The migration to the aggregate bandwidth model is permanent and not reversible.
Before you migrate, review the pre-migration checklist. You must Commit and Push
your changes for them to take effect.

The Service IP Address (the public IP addresses used on the Prisma Access side of the IPSec
tunnel for the remote network connection) do not change when you migrate your deployment
to the aggregate bandwidth model, and no reconfiguration of your IPSec tunnel is required.

STEP 7 | Enter the Bandwidth Allocation you want for each Compute Location that is associated with
the Prisma Access Locations you want to onboard.
To verify the bandwidth amount you entered, select the check mark next to the bandwidth
amount; to cancel the amount, select x.
Specify a minimum bandwidth of 50 Mbps and a maximum bandwidth of the maximum
remaining licensed bandwidth.

STEP 8 | (Optional, Deployments with Autonomous DEM for Remote Networks Licenses Only) Enable
Autonomous DEM Allocation for the compute location for which you allocated bandwidth.
If you enable Autonomous DEM for the compute location, the amount of bandwidth used
by the Autonomous DEM license is the same as the bandwidth you specify for the compute
location. The Autonomous DEM Allocated Total shows you how much bandwidth is used by
Autonomous DEM and how much is remaining. See the Autonomous DEM guide for more
information.

Prisma Access Administrator’s Guide (Panorama Managed) 282 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 9 | Wait for the bandwidth to be reflected in the Allocated Total field at the top of the page;
then, click OK.

STEP 10 | (Optional) If you want to configure your remote network to provide secure inbound access
to remote network locations, click the Inbound Access Remote Networks tab and follow the
workflow to configure secure inbound access for a remote network.

STEP 11 | Add a remote network and specify a Name.

You cannot change the name of the remote network location after you enter it.
Make sure you know your naming scheme for your remote networks before you begin
onboarding.

STEP 12 | (Optional, BGP deployments only) Create a configuration so that your remote network
connection can use up to four IPSec tunnels for its traffic (ECMP Load Balancing).
Static routes are not supported (BGP is required), and, if you have QoS configured, you cannot
change the Allocation Ratio for ECMP links. If your deployment uses one IPSec tunnel for its

Prisma Access Administrator’s Guide (Panorama Managed) 283 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

remote network connection or uses static routes, select None for ECMP Load Balancing and
continue to Step 12.
1. Select one of the choices to enable or disable ECMP load balancing.
• None—Do not use ECMP load balancing (use a single remote network tunnel for this
remote network connection). This is the only choice you can make for static routes;
BGP is required for ECMP load balancing.
• Enabled with Symmetric Return—Specify up to four IPSec tunnels for this remote
network connection and force Prisma Access to use the same link for the return
traffic as it used to send the traffic.
Select this option if you use one or more tunnels as a backup tunnel to be used only if
one of the primary tunnels go down. If a link fails, Prisma Access uses one of the other
tunnels to send and receive traffic symmetrically.

2. Add an IPSec tunnel for the remote network connection and specify the following
values:
• Enable—Enables BGP for the IPSec tunnel.
This selection is not configurable; you must enable BGP to configure ECMP.
• Summarize Mobile User Routes before advertising—Reduces the number of mobile
user IP subnet advertisements over BGP to your customer premises equipment (CPE)
by summarizing them.
By default, Prisma Access advertises the mobile users IP address pools in blocks
of /24 subnets; if you summarize them, Prisma Access advertises the pool based
on the subnet you specified. For example, Prisma Access advertises a public user
mobile IP pool of 10.8.0.0/20 using the /20 subnet, rather than dividing the pool
into subnets of 10.8.1.0/24, 10.8.2.0/24, 10.8.3.0/24, and so on before advertising
them. Summarizing these advertisements can reduce the number of routes stored in
CPE routing tables. For example, you can use IP pool summarization with cloud VPN

Prisma Access Administrator’s Guide (Panorama Managed) 284 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

gateways (Virtual Private Gateways (VGWs) or Transit Gateways (TGWs)) that can
accept a limited number of routes.

If you enable route summarization for a location that uses ECMP, you must
enable route summarization on all links to that location, or you will receive an
error during commit.

Prisma Access sets the community string for aggregated mobile user routes to
0xFFFE:0xFFF0.
• Advertise Default Route—Prisma Access originates a default route advertisement for
the remote network using eBGP.

Be sure that your network does not have another default route being
advertised by BGP, or you could introduce routing issues in your network.
• Don’t Advertise Prisma Access Routes—Prevents the Prisma Access BGP peer from
forwarding routes into your organization’s network.
By default, Prisma Access advertises all BGP routing information, including local
routes and all prefixes it receives from other service connections, remote networks,
and mobile user subnets. Select this check box to prevent Prisma Access from sending
any BGP advertisements, but still use the BGP information it receives to learn routes
from other BGP neighbors.
Since Prisma Access does not send BGP advertisements if you select this option, you
must configure static routes on the on-premises equipment to establish routes back
to Prisma Access.

• Peer AS—Specify the autonomous system (AS) to which the firewall, virtual router, or
BGP router at your remote network belongs.
• Peer IP Address—Enter the IP address assigned as the Router ID of the eBGP router
on the remote network for which you are configuring this connection.
• Local IP Address (Optional)—Enter an address that Prisma Access uses as its Local
IP address for BGP.Specify the IP address to use on the Prisma Access side of the
tunnel.
Specifying a Local Address is useful where the device on the other side of the
connection (such as an Amazon Web Service (AWS) Virtual Private Gateway)
requires a specific local IP address for BGP peering to be successful. Make sure

Prisma Access Administrator’s Guide (Panorama Managed) 285 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

that the address you specify does not conflict or overlap with IP addresses in the
Infrastructure Subnet or subnets in the remote network.
• Secret and Confirm Secret (Optional)—Enter and confirm a passphrase to
authenticate BGP peer communications.
3. Repeat the previous step to add up to four tunnels to use with the remote network
connection.

STEP 13 | Select the Location in which Prisma Access will deploy the infrastructure required to secure
your remote network location. This region should be geographically located close to your
remote network location.
If you have not yet allocated bandwidth for the compute location to which the location maps,
Prisma Access prompts you to enter bandwidth for that compute location.

STEP 14 | Select the IPSec Termination Node that you want to use for this remote network.
Prisma Access uses this node to associate remote network locations with compute locations.

STEP 15 | (Static routing or single-tunnel deployments only) Select or add a new IPSec Tunnel
configuration to access the firewall, router, or SD-WAN device at the corporate location:
• Select one of the predefined IPSec templates in the Remote_Network_Template, or, if
you have added a template to the Remote_Network_Template_Stack (or modified the
predefined Remote_Network_Template) that includes an IPSec Tunnel configuration, select
that IPSec Tunnel from the drop-down. Note that the tunnel you are creating for each

Prisma Access Administrator’s Guide (Panorama Managed) 286 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

remote network connection connects Prisma Access to the IPSec-capable device at each
branch location.
Use the following guidelines when configuring an IPSec tunnel:
• The peer addresses in the IKE Gateway configuration must be unique for each tunnel.
You can, however, re-use some of the other common configuration elements, such as
crypto profiles.
• The IPSec Tunnel you select from a template must use Auto Key exchange and IPv4
only.
• The IPSec tunnel, IKE gateway, and crypto profile names cannot be longer than 31
characters.
• If you onboard multiple remote networks to the same location with dynamic IKE peers,
you must use the same IKE crypto profile for all remote network configurations.
• To create a new IPSec Tunnel configuration, click New IPSec Tunnel, give it a Name and
configure the IKE Gateway, IPSec Crypto Profile, and Tunnel Monitoring settings.
• If the IPSec-capable device at your branch location uses policy-based VPN, on the Proxy
IDs tab, Add a proxy ID that matches the settings configured on your local IPSec device

Prisma Access Administrator’s Guide (Panorama Managed) 287 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

to ensure that Prisma Access can successfully establish an IPSec tunnel with your local
device.
• Leave Enable Replay Protection selected to detect and neutralize against replay attacks.
• Select Copy TOS Header to copy the Type of Service (TOS) header from the inner IP header
to the outer IP header of the encapsulated packets in order to preserve the original TOS
information.
• To enable tunnel monitoring for the service connection, select Tunnel Monitor.
• Enter a Destination IP address.
Specify an IP address at your branch location to which Prisma Access can send ICMP
ping requests for IPSec tunnel monitoring. Make sure that this address is reachable by
ICMP from the entire Prisma Access infrastructure subnet.
• If you use tunnel monitoring with a peer device that uses multiple proxy IDs, specify a
Proxy ID or add a New Proxy ID that allows access from the infrastructure subnet to
your branch location.
The following figure shows a proxy ID with the service infrastructure subnet
(172.16.55.0/24 in this example) as the Local IP subnet and the branch location’s subnet
(10.1.1.0/24 in this example) as the Remote subnet.

The following figure shows the Proxy ID you created being applied to the tunnel monitor
configuration by specifying it in the Proxy ID field.

Prisma Access Administrator’s Guide (Panorama Managed) 288 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

You must configure a static route on your CPE to the Tunnel Monitor IP Address for
tunnel monitoring to function. To find the destination IP address to use for tunnel
monitoring from your branch location to Prisma Access, select Panorama > Cloud
Services > Status > Network Details, click the Service Infrastructure radio button,
and find the Tunnel Monitor IP Address.

STEP 16 | If you have a secondary WAN link at this location, select Enable Secondary WAN.

Be sure to create a unique IPSec tunnel for each remote network’s secondary WAN;
Prisma Access does not support reusing the same IPSec tunnel for secondary WANs in
multiple remote networks.

Configuring a Secondary WAN is not supported in the following deployments:

• If your secondary WAN is set up in active-active mode with the Primary IPSec tunnel.
• If your customer premises equipment (CPE) is set up in an Equal Cost Multipath (ECMP)
configuration with the Primary and Secondary IPSec tunnel.
If you use static routes, tunnel failover time is less than 15 seconds from the time of detection,
depending on your WAN provider.
If you configure BGP routing and have enabled tunnel monitoring, the shortest default hold
time to determine that a security parameter index (SPI) is failing is the tunnel monitor, which
removes all routes to a peer when it detects a tunnel failure for 15 consecutive seconds. In this
way, the tunnel monitor determines the behavior of the BGP routes. If you do not configure
tunnel monitoring, the hold timer determines the amount of time that the tunnel is down
before removing the route. Prisma Access uses the default BGP HoldTime value of 90 seconds
as defined by RFC 4271, which is the maximum wait time before Prisma Access removes a
route for an inactive SPI. If the peer BGP device has a shorter configured hold time, the BGP
hold timer uses the lower value.
When the secondary tunnel is successfully installed, the secondary route takes precedence
until the primary tunnel comes back up. If the primary and secondary are both up, the primary
route takes priority.

If you use a different BGP peer for the secondary (backup) connection, Prisma Access
does not honor the Multi-Exit Discriminator (MED) attributes advertised by the
CPE. This caveat applies if you use multiple BGP peers on either remote network
connections or service connections.

STEP 17 | Enable routing to the subnetworks or individual IP addresses at the remote network site that
your users will need access to.
Prisma Access uses this information to route requests to the appropriate site. The networks
at each site cannot overlap with each other or with IP address pools that you designated for

Prisma Access Administrator’s Guide (Panorama Managed) 289 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

the service infrastructure or for the Prisma Access for users IP pools. You can configure Static
Routes, BGP, or a combination of both.
• To configure Static Routes:
1. On the Static Routes tab, click Add and enter the subnetwork address (for example,
172.168.10.0/24) or individual IP address of a resource, such as a DNS server (for
example, 10.32.5.1/32) that your remote users will need access to.
2. Repeat for all subnets or IP addresses that Prisma Access will need access to at this
location.

• To configure BGP:
1. Select the BGP tab.
2. (Optional) Select the ECMP Load Balancing choices. See Step 9.
3. If you select None for ECMP Load Balancing, enter the BGP choices.

4. To enable BGP for the remote network connection, select Enable.

Prisma Access Administrator’s Guide (Panorama Managed) 290 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

When you enable BGP, Prisma Access sets the time to live (TTL) value for external
BGP (eBGP) to 8 to accommodate any extra hops that might occur between the Prisma
Access infrastructure and your customer premises equipment (CPE) that terminates the
eBGP connection.
5. To reduce the number of mobile user IP subnet advertisements over BGP to your
customer premises equipment (CPE) by summarizing them, select Summarize Mobile
User Routes before advertising.
By default, Prisma Access advertises the mobile users IP address pools in blocks of /24
subnets; if you summarize them, Prisma Access advertises the pool based on the
subnet you specified. For example, Prisma Access advertises a public user mobile IP
pool of 10.8.0.0/20 using the /20 subnet, rather than dividing the pool into subnets of
10.8.1.0/24, 10.8.2.0/24, 10.8.3.0/24, and so on before advertising them. Summarizing
these advertisements can reduce the number of routes stored in CPE routing tables. For
example, you can use IP pool summarization with cloud VPN gateways (Virtual Private
Gateways (VGWs) or Transit Gateways (TGWs)) that can accept a limited number of
routes.
Prisma Access sets the community string for aggregated mobile user routes to
0xFFFE:0xFFF0.
6. To allow Prisma Access to advertise a default route for the remote network using eBGP,
select Advertise Default Route.
If you select Advertise Default Route, be sure that your network does not have another
default route being advertised by BGP, or you could introduce routing issues in your
network.

You must publish your default routes before you make this selection to advertise
them. In addition, be sure that your network does not have another default route
being advertised by BGP, or you could introduce routing issues in your network.
7. To prevent the BGP peer on the Prisma Access firewall from forwarding routes into your
organization’s network, select Don’t Advertise Prisma Access Routes.
By default, Prisma Access advertises all BGP routing information, including local routes
and all prefixes it receives from other service connections, remote networks, and mobile
user subnets. Select this check box to prevent Prisma Access from sending any BGP
advertisements, but still use the BGP information it receives to learn routes from other
BGP neighbors.
Since Prisma Access does not send BGP advertisements if you select this option, you
must configure static routes on the on-premises equipment to establish routes back to
Prisma Access.
8. Enter the Peer AS, which is the autonomous system (AS) to which the firewall, virtual
router, or BGP router at your remote network belongs.
9. Enter the IP address assigned as the Router ID of the eBGP router on the remote
network for which you are configuring this connection as the Peer Address.
10.(Optional) Enter an address that Prisma Access uses as its Local IP address for BGP.
Specifying a Local Address is useful where the device on the other side of the
connection (such as an Amazon Web Service (AWS) Virtual Private Gateway) requires

Prisma Access Administrator’s Guide (Panorama Managed) 291 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

a specific local IP address for BGP peering to be successful. Make sure that the address
you specify does not conflict or overlap with IP addresses in the Infrastructure Subnet or
subnets in the remote network.

You must configure a static route on your CPE to the BGP Local Address.

11.(Optional) Enter and confirm a passphrase to authenticate BGP peer communications.

12.(Optional) If you configured a Secondary WAN and you need to change the Peer
Address or Local Address for the secondary (backup) BGP peer, deselect Same
as Primary WAN and enter a unique Peer and, optionally, Local IP address for the
secondary WAN.
If you use IPv6 networking in your remote network deployment, you can configure IPv6
addresses as well as IPv4 addresses. You also need to enable IPv6 networking globally in
your Prisma Access infrastructure before you can use IPv6 addressing.
In some deployments (for example, when using BGP to peer with an AWS VPN gateway),
the BGP peer for the primary and secondary WAN might be different. In those scenarios,
you can choose to set a different BGP peer for the secondary WAN.

For BGP deployments with secondary WANs, Prisma Access sets both the
primary and secondary tunnels in an UP state, but follows normal BGP active-
backup behavior for network traffic. Prisma Access sets the primary tunnel
as active and sends and receives traffic through that tunnel only; if the
primary tunnel fails, Prisma Access detects the failure using BGP rules, sets the
secondary tunnel as active, and uses only the secondary tunnel to send and
receive traffic.

STEP 18 | (Optional) Enable QoS for the location and specify a QoS Profile.
You specify QoS options and overall settings on a per-compute location basis in the Settings;
however, you can enable or disable QoS or change the QoS profile on a per-location basis
here.

STEP 19 | Commit the configuration changes to Panorama and push the configuration out to Prisma
Access for networks.
1. Click Commit > Commit to Panorama.
2. Click Commit > Commit and Push. Click Edit Selections > Prisma Access, and select
both Prisma Access for networks and Prisma Access for service setup to push the
configuration out to the service.

3. Click OK and Push.

Prisma Access Administrator’s Guide (Panorama Managed) 292 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 20 | Configure the IPSec-capable device at the remote network location to set up an IPSec
connection with Prisma Access for networks.
1. Find the Service IP Address for this remote network connection by selecting Panorama
> Cloud Services > Status > Network Details, clicking the Remote Networks radio
button, and viewing the Service IP Address field. Prisma Access for networks
infrastructure has assigned this IP address for the Prisma Access remote network
connection, and you must configure this as the peer IP address to set up the IPSec
tunnel between the remote network location and Prisma Access for networks.

2. Check the Local IP address for the device at the remote network location on the
Panorama > Cloud Services > Status > Network Details > Remote Networks page. If
you are performing NAT at the remote network location, the Local IP address displays
the IP address of the device after NAT.

STEP 21 | To secure traffic at the remote network location you must create security policy rules.
1. Select Policies.
2. Select the Device Group in which to add policy rules. You can select the
Remote_Network_Device_Group or the parent device group that you selected for
defining policies to secure the remote network location.
3. Create security policy rules. Make sure that you do not define security policy rules to
allow traffic from any zone to any zone. In the security policy rules, use the zones that
you defined in your template.
If a user on your network is denied access to a website, report website access issues
before you open a ticket with Palo Alto Networks.

STEP 22 | Enable logging to Cortex Data Lake. You must create and attach a log forwarding profile to
each policy rule for which you want to forward logs.
1. Select Objects > Log Forwarding.
2. Select the Device Group in which you added the policy rules, for example,
Remote_Network_Device_Group.
3. Add a Log Forwarding profile. In the log forwarding profile match list, Add each Log
Type that you want to forward.
4. Select Panorama/Cortex Data Lake as the Forward Method to enable Prisma Access to
forward the logs to Cortex Data Lake. You will be able to monitor the logs and generate
reports from Panorama. Cortex Data Lake provides a seamless integration to store

Prisma Access Administrator’s Guide (Panorama Managed) 293 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

logs without backhauling them to your Panorama at the corporate headquarters, and
Panorama can query Cortex Data Lake as needed.
The following example enables forwarding of Traffic, Threat Prevention, WildFire
Submission, URL Filtering, Data Filtering, and Authentication logs to Cortex Data Lake.

5. Select Policies > Security and edit the policy rule. In Actions, select the Log Forwarding
profile you created.

STEP 23 | Commit all your changes to Panorama and push the configuration changes to Prisma Access.
1. Click Commit > Commit and Push.
2. Edit Selections and, in the Prisma Access tab, make sure Prisma Access for networks is
selected in the Push Scope, then click OK.
3. Commit and Push your changes.

STEP 24 | Check the remote network status.

See Verify Remote Network Connection Status for details.

Configure Prisma Access for Networks—Allocating Bandwidth by

Location
If you have deployed remote networks using the Cloud Services plugin 1.7 or earlier, you can
continue to allocate bandwidth by location by completing the following steps.
Before you begin onboarding your remote networks, be sure you go through the steps to Prisma
Access Remote Network Deployments.
If you need to onboard many remote network locations, onboard a remote network using this
workflow and then import the remote network configuration.
STEP 1 | Select Panorama > Cloud Services > Configuration > Remote Networks and edit the settings
by clicking the gear icon in the Settings area.
1. In the Templates section, Add any templates that contain configuration you want
to push to Prisma Access for networks. For example, if you have existing templates
that contain your zone configurations, or IPSec tunnel, IKE Gateway, or crypto profile
settings, you can add them to the predefined Remote_Network_Template_Stack to
simplify the onboarding process.
You can Add more than one template to the stack and then order them appropriately
using Move Up and Move Down. This is important because Panorama evaluates in the
stack from top to bottom, with settings in templates higher in the stack taking priority

Prisma Access Administrator’s Guide (Panorama Managed) 294 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

over the same settings specified in templates lower in the stack. Note that you cannot
move the default template from the top of the stack.

Although you can add existing templates to the stack from the plugin, you
cannot create a new template from the plugin. Instead, use the workflow to add
a new template.
2. Select the Parent Device Group for Prisma Access for remote networks. You can select
an existing device group or use Shared.
You will push all of the configuration—including the security policy, security profiles, and
other policy objects (such as application groups and objects, and address groups), HIP
objects and profiles and authentication policy—that Prisma Access for networks needs to

Prisma Access Administrator’s Guide (Panorama Managed) 295 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

enforce consistent policy to your remote network users using the device group hierarchy
you specify here.

You don’t need to define all of the policy that you will push to the remote
network yet. Instead, configure the settings to onboard the remote site. You
can then go back and add the templates and device groups with the complete
configurations to push consistent policy out to your remote networks.
3. (Optional) If you have configured an on-premises next-generation firewall as a master
device, select the Master Device you configured.
When you select the Master Device, Prisma Access auto-populates user and group
information in the security policy rules in Panorama for mobile user and remote network
device groups.
4. If you will be configuring remote networks that have overlapping subnets, select the
Overlapped Subnets check box to enable outbound internet access for those locations.
While configuring Remote Network Locations with Overlapping Subnets introduces
some limitations, it is acceptable in some cases (for example, if you want to add a guest
network at a retail store location).

Prisma Access Administrator’s Guide (Panorama Managed) 296 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 2 | (Optional) Configure DNS Proxy settings for your remote network.
Prisma Access allows you to specify DNS servers to resolve both domains that are internal to
your organization and external domains. If you do not specify any settings, Prisma Access does
not proxy DNS requests for remote networks.
1. In the Remote_Network_Device_Group device group, select Policies > Security and Add
a security policy rule with an Application of DNS and an Action of Allow to allow DNS
traffic.
Without a security policy rule to allow DNS traffic, DNS resolution does not occur.

2. If you configure Prisma Access to proxy the DNS requests from your remote networks,
update the DNS settings on all the endpoints in that network to use the Prisma Access
Remote Network DNS Proxy IP Address as the primary DNS server and use your DNS
server as secondary DNS server. You can get this DNS proxy IP from Panorama > Cloud
Services > Status > Network Details > Service Infrastructure.

3. Add one or more DNS proxy settings, entering the following values:
• For Internal Domains:
• Select a Region (North America & South America, Africa, Europe & Middle East, or
Asia, Australia & Japan), or specify Worldwide to apply the DNS settings globally.
You can add multiple region-specific DNS proxy settings, or specify a DNS proxy
for one or more regions and specify another worldwide DNS proxy for the rest of
the world. If you specify only a regional setting and onboard remote networks in
that region only, Prisma Access does not proxy the DNS requests, and the source
IP address of the DNS request is the remote network’s EBGP Router IP address. If
you specify multiple proxy settings with a mix of regional and worldwide regions,

Prisma Access Administrator’s Guide (Panorama Managed) 297 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Prisma Access uses the regional settings for the Locations in the region you
specify; otherwise, Prisma Access uses the worldwide settings.
• Specify the IP addresses of the Primary DNS and Secondary DNS servers that your
remote network should use to resolve internal domains.
• (Optional) If you want your internal DNS server to only resolve the domains you
specify, enter the domains to resolve in the Domain List.
You can use a wildcard (*) in front of the domains in the domain list, for example
*.acme.local or .acme.com. You can specify a maximum of 1,024 domain entries.
• For External Domains:
• Enter a Primary DNS choice.
To use the default Prisma Access DNS server, select Use Cloud Default. To use
the same server that you use to resolve internal domains, select Same as Internal
Domains. To use third-party or public DNS server, select Custom DNS Server, then
specify the IP address of the DNS server.
• Enter a Secondary DNS choice, choosing from the same options you chose for the
Prisma DNS.

STEP 3 | (Optional) Configure Prisma Access to use the Directory Sync component of the Cloud
Identity Engine to retrieve user and group information using Group Mapping Settings.
You must configure the Cloud Identity Engine to retrieve user and group information from
your Active Directory (AD) before you enable group mapping in Prisma Access using Group
Mapping Settings.

STEP 4 | Create new zones in the one of the templates in the stack (Network > Zones> Add) or map
the zones referenced in existing templates you added to the stack as trusted or untrusted.
On Panorama, policy rules are defined in device groups, and zones are defined in templates.

Prisma Access Administrator’s Guide (Panorama Managed) 298 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Therefore, you need to make sure that you add the templates that reference the zones
included in your policy rules to the template stack.
On a Palo Alto Networks® next-generation firewall, security policy is enforced between zones,
which map to physical or virtual interfaces on the firewall. But as Prisma Access for networks
has only two zones, trust and untrust, you need to map any zone with traffic bound to the
Internet (including your sanctioned SaaS applications) as untrust and all internal zones as trust.
1. (Optional) Edit the zone mapping settings.
By default, all of the zones in Prisma Access for networks template stack a are classified
as Untrusted Zones. If you have not yet defined zones or if the templates in the
Remote_Network_Template_Stack do not have zone configurations, you can come back
and add them when you push policy to Prisma Access for networks.
2. For each zone you want to designate as trusted, select it and click Add to move it to the
list of Trusted Zones.
3. Click OK to save the mappings.

STEP 5 | Click Add in the Onboarding settings, and specify a Name to identify the infrastructure that
will secure the remote network location you are onboarding.

You cannot change the name of the remote network location after you enter it.
Make sure you know your naming scheme for your remote networks before you begin
onboarding.

Prisma Access Administrator’s Guide (Panorama Managed) 299 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 6 | (BGP deployments only) Create a configuration so that your remote network connection can
use up to four IPSec tunnels for its traffic (ECMP Load Balancing).
QoS is not supported with ECMP load balancing, and static routes are not supported (BGP is
required). If your deployment uses one IPSec tunnel for its remote network connection or uses
static routes, select None for ECMP Load Balancing and continue to Step 9.
Specify a minimum Bandwidth of 50 Mbps.
Prisma Access divides the bandwidth you select by the number of tunnels; for example, if you
specify 300 Mbps and add four tunnels, each tunnel carries 75 Mbps. If one of the tunnels
goes down, your network connection will now carry 225 Mbps instead of 300 Mbps.
1. Select one of the choices to enable or disable ECMP load balancing.
• None—Do not use ECMP load balancing (use a single remote network tunnel for this
remote network connection). This is the only choice you can make for static routes;
BGP is required for ECMP load balancing.
• Enabled with Symmetric Return—Specify up to four IPSec tunnels for this remote
network connection and force Prisma Access to use the same link for the return
traffic as it used to send the traffic.
Select this option if you use one or more tunnels as a backup tunnel to be used only if
one of the primary tunnels go down. If a link fails, Prisma Access uses one of the other
tunnels to send and receive traffic symmetrically.

2. Add an IPSec tunnel for the remote network connection and specify the following
values:
• Enable—Enables BGP for the IPSec tunnel.
This selection is not configurable; you must enable BGP to configure ECMP.

Prisma Access Administrator’s Guide (Panorama Managed) 300 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

• Summarize Mobile User Routes before advertising—Reduces the number of mobile

user IP subnet advertisements over BGP to your customer premises equipment (CPE)
by summarizing them.
By default, Prisma Access advertises the mobile users IP address pools in blocks
of /24 subnets; if you summarize them, Prisma Access advertises the pool based
on the subnet you specified. For example, Prisma Access advertises a public user
mobile IP pool of 10.8.0.0/20 using the /20 subnet, rather than dividing the pool
into subnets of 10.8.1.0/24, 10.8.2.0/24, 10.8.3.0/24, and so on before advertising
them. Summarizing these advertisements can reduce the number of routes stored in
CPE routing tables. For example, you can use IP pool summarization with cloud VPN
gateways (Virtual Private Gateways (VGWs) or Transit Gateways (TGWs)) that can
accept a limited number of routes.

If you enable route summarization for a location that uses ECMP, you must
enable route summarization on all links to that location, or you will receive an
error during commit.

Prisma Access sets the community string for aggregated mobile user routes to
0xFFFE:0xFFF0.
• Advertise Default Route—Allows Prisma Access to advertise a default route for the
remote network using eBGP.

You must publish your default routes before you make this selection to
advertise them. In addition, be sure that your network does not have another
default route being advertised by BGP, or you could introduce routing issues
in your network.
• Don’t Advertise Prisma Access Routes—Prevents the Prisma Access BGP peer from
forwarding routes into your organization’s network.
By default, Prisma Access advertises all BGP routing information, including local
routes and all prefixes it receives from other service connections, remote networks,
and mobile user subnets. Select this check box to prevent Prisma Access from sending

Prisma Access Administrator’s Guide (Panorama Managed) 301 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

any BGP advertisements, but still use the BGP information it receives to learn routes
from other BGP neighbors.
Since Prisma Access does not send BGP advertisements if you select this option, you
must configure static routes on the on-premises equipment to establish routes back
to Prisma Access.

• Peer AS—Specify the autonomous system (AS) to which the firewall, virtual router, or
BGP router at your remote network belongs.
• Peer IP Address—Enter the IP address assigned as the Router ID of the eBGP router
on the remote network for which you are configuring this connection.
• Local IP Address (Optional)—Enter an address that Prisma Access uses as its Local
IP address for BGP.Specify the IP address to use on the Prisma Access side of the
tunnel.
Specifying a Local Address is useful where the device on the other side of the
connection (such as an Amazon Web Service (AWS) Virtual Private Gateway)
requires a specific local IP address for BGP peering to be successful. Make sure

Prisma Access Administrator’s Guide (Panorama Managed) 302 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

that the address you specify does not conflict or overlap with IP addresses in the
Infrastructure Subnet or subnets in the remote network.
• Secret and Confirm Secret (Optional)—Enter and confirm a passphrase to
authenticate BGP peer communications.
3. Repeat the previous step to add up to four tunnels to use with the remote network
connection.

STEP 7 | Select the Location in which Prisma Access will deploy the infrastructure required to secure
your remote network location. This region should be geographically located close to your
remote network location.

STEP 8 | Select the Bandwidth you want to allocate to this remote network location. The bandwidth
you select cannot exceed the total amount of bandwidth you have licensed. Use this setting
to define the amount of the total licensed bandwidth you want to allocate to this location.
To help you determine how much bandwidth a specific site needs, consider the bandwidth
available from your ISP at each location. If you enable ECMP Load Balancing, you must specify
a minimum of 50 Mbps.

You can change the bandwidth of a remote network connection after you onboard it,
with the exception of the 500 Mbps (w/o SSL Decryption) or 1000 Mbps (Preview)
bandwidth choices. If you select either of these preview choices and then need to
change the bandwidth, you must first add an identical network with the only change
being the lower, non-Preview bandwidth choice, commit your changes, make a note
of the Service IP address and reconfigure your IPSec tunnel to use that address, then
delete the existing remote network with the preview bandwidth choice.

Prisma Access Administrator’s Guide (Panorama Managed) 303 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 9 | (Static routing or single-tunnel deployments only) Select or add a new IPSec Tunnel
configuration to access the firewall, router, or SD-WAN device at the corporate location:
• If you have added a template to the Remote_Network_Template_Stack (or modified the
predefined Remote_Network_Template) that includes an IPSec Tunnel configuration, select
that IPSec Tunnel from the drop-down. Note that the tunnel you are creating for each
remote network connection connects Prisma Access to the IPSec-capable device at each
branch location.
Use the following guidelines when configuring an IPSec tunnel:
• The peer addresses in the IKE Gateway configuration must be unique for each tunnel.
You can, however, re-use some of the other common configuration elements, such as
crypto profiles.
• The IPSec Tunnel you select from a template must use Auto Key exchange and IPv4
only.
• If you onboard multiple remote networks to the same location with dynamic IKE peers,
you must use the same IKE crypto profile for all remote network configurations.
• To create a new IPSec Tunnel configuration, click New IPSec Tunnel, give it a Name and
configure the IKE gateway, IPSec crypto profile, and tunnel monitoring settings.
• If the IPSec-capable device at your branch location uses policy-based VPN, on the Proxy
IDs tab, Add a proxy ID that matches the settings configured on your local IPSec device

Prisma Access Administrator’s Guide (Panorama Managed) 304 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

to ensure that Prisma Access can successfully establish an IPSec tunnel with your local
device.
• Leave Enable Replay Protection selected to detect and neutralize against replay attacks.
• Select Copy TOS Header to copy the Type of Service (TOS) header from the inner IP header
to the outer IP header of the encapsulated packets in order to preserve the original TOS
information.
• To enable tunnel monitoring for the service connection, select Tunnel Monitor.
• Enter a Destination IP address.
Specify an IP address at your branch location to which Prisma Access can send ICMP
ping requests for IPSec tunnel monitoring. Make sure that this address is reachable by
ICMP from the entire Prisma Access infrastructure subnet.
• If you use tunnel monitoring with a peer device that uses multiple proxy IDs, specify a
Proxy ID or add a New Proxy ID that allows access from the infrastructure subnet to
your branch location.
The following figure shows a proxy ID with the service infrastructure subnet
(172.16.55.0/24 in this example) as the Local IP subnet and the branch location’s subnet
(10.1.1.0/24 in this example) as the Remote subnet.

The following figure shows the Proxy ID you created being applied to the tunnel monitor
configuration by specifying it in the Proxy ID field.

Prisma Access Administrator’s Guide (Panorama Managed) 305 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

You must configure a static route on your CPE to the Tunnel Monitor IP Address for
tunnel monitoring to function. To find the destination IP address to use for tunnel
monitoring from your branch location to Prisma Access, select Panorama > Cloud
Services > Status > Network Details, click the Service Infrastructure radio button,
and find the Tunnel Monitor IP Address.

STEP 10 | If you have a secondary WAN link at this location, select Enable Secondary WAN.

Be sure to create a unique IPSec tunnel for each remote network’s secondary WAN;
Prisma Access does not support reusing the same IPSec tunnel for secondary WANs in
multiple remote networks.

If you use static routes, tunnel failover time is less than 15 seconds from the time of detection,
depending on your WAN provider.
If you configure BGP routing and have enabled tunnel monitoring, the shortest default hold
time to determine that a security parameter index (SPI) is failing is the tunnel monitor, which
removes all routes to a peer when it detects a tunnel failure for 15 consecutive seconds. In this
way, the tunnel monitor determines the behavior of the BGP routes. If you do not configure
tunnel monitoring, the hold timer determines the amount of time that the tunnel is down
before removing the route. Prisma Access uses the default BGP HoldTime value of 90 seconds
as defined by RFC 4271, which is the maximum wait time before Prisma Access removes a

Prisma Access Administrator’s Guide (Panorama Managed) 306 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

route for an inactive SPI. If the peer BGP device has a shorter configured hold time, the BGP
hold timer uses the lower value.
When the secondary tunnel is successfully installed, the secondary route takes precedence
until the primary tunnel comes back up. If the primary and secondary are both up, the primary
route takes priority.

If you use a different BGP peer for the secondary (backup) connection, Prisma Access
does not honor the Multi-Exit Discriminator (MED) attributes advertised by the
CPE. This caveat applies if you use multiple BGP peers on either remote network
connections or service connections.

STEP 11 | Enable routing to the subnetworks or individual IP addresses at the remote network site that
your users will need access to.
Prisma Access uses this information to route requests to the appropriate site. The networks
at each site cannot overlap with each other or with IP address pools that you designated for

Prisma Access Administrator’s Guide (Panorama Managed) 307 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

the service infrastructure or for the Prisma Access for users IP pools. You can configure Static
Routes, BGP, or a combination of both.
• To configure Static Routes:
1. On the Static Routes tab, click Add and enter the subnetwork address (for example,
172.168.10.0/24) or individual IP address of a resource, such as a DNS server (for
example, 10.32.5.1/32) that your remote users will need access to.
2. Repeat for all subnets or IP addresses that Prisma Access will need access to at this
location.

• To configure BGP:
1. Select the BGP tab.
2. Select the ECMP Load Balancing choices. See Step 6.
3. If you select None for ECMP Load Balancing, enter the BGP choices.

Prisma Access Administrator’s Guide (Panorama Managed) 308 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

4. To enable BGP for the remote network connection, select Enable.

When you enable BGP, Prisma Access sets the time to live (TTL) value for external
BGP (eBGP) to 8 to accommodate any extra hops that might occur between the Prisma
Access infrastructure and your customer premises equipment (CPE) that terminates the
eBGP connection.
5. To reduce the number of mobile user IP subnet advertisements over BGP to your
customer premises equipment (CPE) by summarizing them, select Summarize Mobile
User Routes before advertising.
By default, Prisma Access advertises the mobile users IP address pools in blocks of /24
subnets; if you summarize them, Prisma Access advertises the pool based on the
subnet you specified. For example, Prisma Access advertises a public user mobile IP
pool of 10.8.0.0/20 using the /20 subnet, rather than dividing the pool into subnets of
10.8.1.0/24, 10.8.2.0/24, 10.8.3.0/24, and so on before advertising them. Summarizing
these advertisements can reduce the number of routes stored in CPE routing tables. For
example, you can use IP pool summarization with cloud VPN gateways (Virtual Private

Prisma Access Administrator’s Guide (Panorama Managed) 309 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Gateways (VGWs) or Transit Gateways (TGWs)) that can accept a limited number of
routes.
Prisma Access sets the community string for aggregated mobile user routes to
0xFFFE:0xFFF0.
6. To allow Prisma Access to advertise a default route for the remote network using eBGP,
select Advertise Default Route.
If you select Advertise Default Route, be sure that your network does not have another
default route being advertised by BGP, or you could introduce routing issues in your
network.

You must publish your default routes before you make this selection to advertise
them. In addition, be sure that your network does not have another default route
being advertised by BGP, or you could introduce routing issues in your network.
7. To prevent the BGP peer on the Prisma Access firewall from forwarding routes into your
organization’s network, select Don’t Advertise Prisma Access Routes.
By default, Prisma Access advertises all BGP routing information, including local routes
and all prefixes it receives from other service connections, remote networks, and mobile
user subnets. Select this check box to prevent Prisma Access from sending any BGP
advertisements, but still use the BGP information it receives to learn routes from other
BGP neighbors.
Since Prisma Access does not send BGP advertisements if you select this option, you
must configure static routes on the on-premises equipment to establish routes back to
Prisma Access.
8. Enter the Peer AS, which is the autonomous system (AS) to which the firewall, virtual
router, or BGP router at your remote network belongs.
9. Enter the IP address assigned as the Router ID of the eBGP router on the remote
network for which you are configuring this connection as the Peer Address.
10.(Optional) Enter an address that Prisma Access uses as its Local IP address for BGP.
Specifying a Local Address is useful where the device on the other side of the
connection (such as an Amazon Web Service (AWS) Virtual Private Gateway) requires
a specific local IP address for BGP peering to be successful. Make sure that the address
you specify does not conflict or overlap with IP addresses in the Infrastructure Subnet or
subnets in the remote network.

You must configure a static route on your CPE to the BGP Local Address.

11.(Optional) Enter and confirm a passphrase to authenticate BGP peer communications.

12.(Optional) If you configured a Secondary WAN and you need to change the Peer
Address or Local Address for the secondary (backup) BGP peer, deselect Same

Prisma Access Administrator’s Guide (Panorama Managed) 310 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

as Primary WAN and enter a unique Peer and, optionally, Local IP address for the
secondary WAN.
In some deployments (for example, when using BGP to peer with an AWS VPN gateway),
the BGP peer for the primary and secondary WAN might be different. In those scenarios,
you can choose to set a different BGP peer for the secondary WAN.

For BGP deployments with secondary WANs, Prisma Access sets both the
primary and secondary tunnels in an UP state, but follows normal BGP active-
backup behavior for network traffic. Prisma Access sets the primary tunnel
as active and sends and receives traffic through that tunnel only; if the
primary tunnel fails, Prisma Access detects the failure using BGP rules, sets the
secondary tunnel as active, and uses only the secondary tunnel to send and
receive traffic.

STEP 12 | If required, enable Quality of Service for the remote network connection and specify a QoS
profile or add a New QoS Profile.
You can create QoS profiles to shape QoS traffic for remote network and service connections
and apply those profiles to traffic that you marked with PAN-OS security policies, traffic that

Prisma Access Administrator’s Guide (Panorama Managed) 311 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

you marked with an on-premises device, or both PAN-OS-marked and on-premise-marked

traffic.

STEP 13 | (Optional) Configure Inbound Access options.

This choice only applies if you want to configure your remote network for remote network
inbound access.

STEP 14 | Commit the configuration changes to Panorama and push the configuration out to Prisma
Access for networks.
1. Click Commit > Commit to Panorama.
2. Click Commit > Commit and Push. Click Edit Selections > Prisma Access, and select
both Prisma Access for networks and Prisma Access for service setup to push the
configuration out to the service.

3. Click OK and Push.

Prisma Access Administrator’s Guide (Panorama Managed) 312 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 15 | Configure the IPSec-capable device at the remote network location to set up an IPSec
connection with Prisma Access for networks.
1. Find the Service IP Address for this remote network connection by selecting Panorama
> Cloud Services > Status > Network Details, clicking the Remote Networks radio
button, and viewing the Service IP Address field. Prisma Access for networks
infrastructure has assigned this IP address for the Prisma Access remote network
connection, and you must configure this as the peer IP address to set up the IPSec
tunnel between the remote network location and Prisma Access for networks.

2. Check the Local IP address for the device at the remote network location on the
Panorama > Cloud Services > Status > Network Details > Remote Networks page. If
you are performing NAT at the remote network location, the Local IP address displays
the IP address of the device after NAT.

STEP 16 | To secure traffic at the remote network location you must create security policy rules.
1. Select Policies.
2. Select the Device Group in which to add policy rules. You can select the
Remote_Network_Device_Group or the parent device group that you selected for
defining policies to secure the remote network location.
3. Create security policy rules. Make sure that you do not define security policy rules to
allow traffic from any zone to any zone. In the security policy rules, use the zones that
you defined in your template.
If a user on your network is denied access to a website, report website access issues
before you open a ticket with Palo Alto Networks.

STEP 17 | Enable logging to Cortex Data Lake. You must create and attach a log forwarding profile to
each policy rule for which you want to forward logs.
1. Select Objects > Log Forwarding.
2. Select the Device Group in which you added the policy rules, for example,
Remote_Network_Device_Group.
3. Add a Log Forwarding profile. In the log forwarding profile match list, Add each Log
Type that you want to forward.
4. Select Panorama/Cortex Data Lake as the Forward Method to enable Prisma Access to
forward the logs to Cortex Data Lake. You will be able to monitor the logs and generate
reports from Panorama. Cortex Data Lake provides a seamless integration to store

Prisma Access Administrator’s Guide (Panorama Managed) 313 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

logs without backhauling them to your Panorama at the corporate headquarters, and
Panorama can query Cortex Data Lake as needed.
The following example enables forwarding of Traffic, Threat Prevention, WildFire
Submission, URL Filtering, Data Filtering, and Authentication logs to Cortex Data Lake.

5. Select Policies > Security and edit the policy rule. In Actions, select the Log Forwarding
profile you created.

STEP 18 | Commit all your changes to Panorama and push the configuration changes to Prisma Access.
1. Click Commit > Commit to Panorama.
2. Click Commit > Push to Devices and click Edit Selections.
3. On the Prisma Access tab, make sure Prisma Access for networks is selected and then
click OK.
4. Click Push.

STEP 19 | Check the remote network status.

Verify Remote Network Connection Status

STEP 1 | Select Panorama > Cloud Services > Status > Status to verify that the remote network
connections have been successfully deployed.
The Deployment Status area allows you to view the progress of onboarding and deployment
jobs before they complete, as well as see more information about the status of completed jobs.
See Prisma Access Deployment Progress and Status for details.

STEP 2 | To display a map that shows the locations of the remote networks in the regions you have
selected, select Panorama > Cloud Services > Status > Monitor and click the Remote
Networks tab.

STEP 3 | Select a region to get more detail about that region.

Prisma Access Administrator’s Guide (Panorama Managed) 314 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 4 | Click the tabs below the map to see additional remote network statistics.
Status tab:

• Location—The location where your remote network is deployed.

• Remote Peer—The peer to which the remote network has an IPSec tunnel connection.
• IPSec Termination Node—The IPSec termination node associated with the remote network.
This field only displays if you allocate bandwidth by compute location.
• ECMP—Whether you have enabled ECMP Load Balancing on this remote network
connection.
• Config Status—The status of your last configuration push to the service. If you have made a
change locally, and not yet pushed the configuration to the cloud, the status shows Out of
sync. Hover over the status indicator for more detailed information. After committing and
pushing the configuration to Prisma Access, the Config Status changes to In sync.
• BGP Status—Displays information about the BGP state between the firewall or router at the
remote network location and Prisma Access. Although you might temporarily see the status

Prisma Access Administrator’s Guide (Panorama Managed) 315 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

pass through the various BGP states (idle, active, open send, open pend, open confirm,
most commonly, the BGP status shows:
• Connect—The router at the remote network location is trying to establish the BGP peer
relationship with Prisma Access.
• Established—The BGP peer relationship has been established.
This field will also show if the BGP connection is in an error state:
• Warning—There has not been a BGP status update in more than eight minutes. This may
indicate an outage on the firewall.
• Error—The BGP status is unknown.
• Tunnel Status—The operational status of the connection between Prisma Access and the
remote network.
Statistics tab:

• Location—The location where your remote network is deployed.

• Remote Peer—The corporate location to which this remote network is setting up an IPSec
tunnel.
• Ingress Bandwidth (Mbps)—The bandwidth from the remote network location to Prisma
Access.

For the Ingress Bandwidth, Ingress Peak Bandwidth, Egress Bandwidth, and Egress
Peak Bandwidth fields, when the bandwidth consumption on a remote network
goes beyond 80% of the allocated bandwidth, the numbers display in a red color.
• Ingress Peak Bandwidth (Mbps)—The peak load from the remote network location into the
cloud service.

Prisma Access Administrator’s Guide (Panorama Managed) 316 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

• Egress Bandwidth (Mbps)—The bandwidth from Prisma Access into the remote network
location.
• Egress Peak Bandwidth (Mbps)—The peak load from Prisma Access into the remote
network location.
To find statistics about locations in the region, select Bandwidth Usage.

Select the check mark for a location to see detailed bandwidth usage. For deployments that
allocate bandwidth by compute location, select an IPSec termination node to view statistics
for that node. Prisma Access uses the 95th percentile standard to gather statistics, which

Prisma Access Administrator’s Guide (Panorama Managed) 317 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

tracks bandwidth at peak utilization and ignores the top 5 percent of utilization peaks and large
bursts.

Verify Remote Connection BGP Status

If you configured BGP, you can check its status by selecting Panorama > Cloud Services > Status
> Network Details > Remote Networks > BGP Status.

Prisma Access Administrator’s Guide (Panorama Managed) 318 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

The BGP Status dialog displays. This table provides you with the following information:
• Peer—Routing information for the BGP peer, including status, total number of routes,
configuration, and runtime statistics and counters. The total number of routes display in the
bgpAfiIpv4-unicast Counters area, in the Incoming Total and Outgoing Total fields.

• Local RIB—Routing information that has been received from different peers and is stored in the
Routing Information Base (RIB).

• RIB Out—Routing information that Prisma Access advertises to its peers through BGP update
messages. See How BGP Advertises Mobile User IP Address Pools for Service Connections and
Remote Network Connections for an example of this table and for information about how BGP
utilizes the IP address pool you create for mobile users.

Prisma Access Administrator’s Guide (Panorama Managed) 319 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Plan to Migrate to an Aggregate Bandwidth Remote

Network Deployment
Bandwidth for new Prisma Access remote network deployments are allocated at an aggregate
level per compute location, also known as the aggregate bandwidth model. Allocating bandwidth
at a compute location level offers you more flexibility in allocating your licensed remote network
bandwidth, because Prisma Access dynamically allocates the bandwidth for each location based
on load or demand.
If you have an existing deployment that allocates bandwidth by Prisma Access location, you can
migrate to the aggregate bandwidth model. You can also migrate your remote network QoS
deployment. When you migrate, all remote networks use the aggregate bandwidth model.
Use the following checklist to plan for the migration to the aggregate bandwidth model:
Note the following remote network components that remain unchanged after migration:
• There are no changes to the dataplane. Traffic continues to flow through the Prisma Access
dataplane without any change to the existing configuration.
• The migration does not impact existing tunnels.
No reconfiguration of your IPSec tunnel parameters are required. IKE gateways, IKE and
IPSec crypto profiles, and IPSec tunnel configurations remain unchanged.
• The remote network Service IP Address (the public IP addresses used on the Prisma Access
side of the IPSec tunnel for the remote network connection) does not change for each
remote network when you migrate your deployment to the aggregate bandwidth model.
Prisma Access assigns IPSec termination nodes and allocates bandwidth to remote networks
during a migration to the aggregate bandwidth model. You should understand how this model
works before you migrate.

If you want to reassign an existing remote network to another IPSec termination

node after migration, Prisma Access assigns another Service IP Address to the remote
network after you commit and push your changes. In this case, you will need to
reconfigure your CPE to point to the new IP address for the remote network tunnel.
If you have an unsupported configuration, you will not see the Bandwidth Allocation tab or
view the banner to migrate. The following configurations are not supported for migration to
the aggregate bandwidth model:
• A remote network with a bandwidth of 1000 Mbps.
• A Prisma SD-WAN CloudBlade integration with Prisma Access that has a version earlier
than 3.0.
• A remote network configuration that provides secure inbound access to applications at a
remote network site earlier than 2.1 Innovation.
If you use QoS with your remote networks, be sure to follow the QoS migration guidelines
before you migrate.

Prisma Access Administrator’s Guide (Panorama Managed) 320 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

If you’re not sure which model your deployment is using, Select Panorama > Cloud Services >
Configuration > Remote Networks.
• If you see a Bandwidth field in the Remote Networks area, you are allocating bandwidth by
Prisma Access location, and you can migrate to the aggregate bandwidth model.

• If you see an IPSec Termination Node, you have already migrated to the aggregate
bandwidth model.

After you migrate to the aggregate bandwidth model, the change is permanent and you cannot
revert to having a deployment that allocates bandwidth by Prisma Access location.
You must have a minimum of 50 Mbps of available bandwidth to migrate to the aggregate
bandwidth model.

Prisma Access Administrator’s Guide (Panorama Managed) 321 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

If you want to implement QoS after migration, learn the differences about configuring QoS for
an aggregate bandwidth deployment.
• Be sure to use a Class Bandwidth Type of Percentage instead of Mbps in your QoS profiles.
Prisma Access does not support bandwidth types of Mbps in QoS profiles for deployments
that allocate bandwidth by compute location.

• Understand how to specify a guaranteed bandwidth ratio and how to customize bandwidth
per site.
Using a guaranteed bandwidth ratio, you can allocate a percentage of the total allocated
bandwidth in the compute location. Prisma Access divides the guaranteed bandwidth
equally by the number of IPSec termination nodes in the compute location.
By customizing the bandwidth per site, you can apply an Allocation Ratio for the sites an
a single IPSec termination node and specify QoS profiles per site in the remote network
Settings. Alternatively, you can specify a QoS profile during remote network configuration
by selecting the remote network and specifying a QoS profile in the QoS tab.
If you have configured your remote networks to provide secure inbound access to your remote
network locations, all existing inbound access features are supported, such as enabling a
secondary WAN link (Enable Secondary WAN), BGP, QoS and source NAT options. There
is also no change to the bandwidth that is consumed by the public IP addresses that Prisma
Access allocates (5 IP addresses take 150 Mbps from your remote network license allocation,
and 10 IP addresses take 300 Mbps).
If you need to configure inbound access after you migrate, use the inbound access procedure
that is specific to the aggregate bandwidth model.
Palo Alto Networks recommends that you take a note of your existing bandwidth settings and
total licensed bandwidth before you migrate.

Although Prisma Access migrates your bandwidth during migration; you should note
your current settings as a best practice and make any adjustments to the compute
location bandwidth after you migrate.

• Check your existing bandwidth settings by selecting Panorama > Cloud Services >
Configuration > Remote Networks and make a note of the existing Bandwidth that is
available for each remote network connection.
• Navigate to Panorama > Licenses and check your total licensed bandwidth in Mbps for
remote networks. This information is included under Prisma Access Net Capacity or
GlobalProtect Cloud Service for Mobile Users, depending on your license type.
After you migrate, make a note of the following differences to your deployment:

Prisma Access Administrator’s Guide (Panorama Managed) 322 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

• You onboard all new remote networks using the aggregate bandwidth remote network
onboarding procedure.
• When you view Bandwidth Usage Statistics, you view them at a per-IPSec termination node
level.

Bandwidth Allocation for a Migrated Aggregate Bandwidth

Deployment
If you have a deployment that allocates bandwidth by Prisma Access location, Prisma Access
makes the following changes when you migrate to the aggregate bandwidth model:
• Prisma Access sums the bandwidth for all locations in a given compute location and allocates
the summed bandwidth to that compute location.
For example, you have three locations (Location 1, Location 2, and Location 3) in the Mexico
West, US Southwest, and US West locations, and each existing location has 50 Mbps of
bandwidth. Since each location is in the US Southwest compute location, Prisma Access
sums the bandwidth of the three locations and allocates 150 Mbps of bandwidth to the US
Southwest location.
• If all the location or locations in a compute location have a total bandwidth of less than 50
Mbps, Prisma Access will increase the bandwidth to 50 Mbps for that compute location.
Prisma Access provides you with the locations that require the bandwidth increase during the
migration process.

Prisma Access Administrator’s Guide (Panorama Managed) 323 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

• Prisma Access uses IPSec termination nodes in aggregate bandwidth deployments. During
migration, Prisma Access provides one IPSec termination node per compute location for every
1,000 Mbps of allocated bandwidth. For example, if you allocate 1500 Mbps of bandwidth in a
compute location, Prisma Access provides that location with two IPSec termination nodes.
You assign IPSec termination nodes to a remote network during remote network onboarding.
In an aggregate bandwidth migration, Prisma Access associates the IPSec termination nodes
to the remote networks during migration. The following list provides some examples of IPSec
termination node association for a migration:
• If you have four remote networks that are in the same compute location, and those
remote networks have 50 Mbps of bandwidth each, Prisma Access allocates 200 Mbps
of bandwidth to that compute location, provides a single IPSec termination node to that
compute location, and associates that IPSec termination node to all four remote networks.
• If you have three remote networks in the same compute location with 100 Mbps each,
Prisma Access allocates 300 Mbps of bandwidth to that compute location, provides a single
IPSec termination node to that compute location, and associates that IPSec termination
node to all three remote networks.
• If you have seven remote networks in the same compute location, with two remote
networks having 500 Mbps and five remote networks having 100 Mbps each, Prisma Access
allocates 1500 Mbps of bandwidth to that compute location. Because the total allocated
bandwidth in that compute location is greater than 1,000 Mbps, Prisma Access allocates
two IPSec termination nodes and makes the following associations:
• The two 500 Mbps remote networks are assigned one IPSec termination node (one node
for each 1,000 Mbps remote network).
• The five 100 Mbps remote networks are assigned one IPSec termination node.
After you migrate, you can change the IPSec termination node association to increase
bandwidth for a location. For example, given a compute location with two IPSec termination
nodes, you could reassign a single IPSec termination node to a single location and reassign
the other IPSec termination node to the remaining locations, which effectively provides the
location that does not share an IPSec termination node with more bandwidth.
• If you reduce bandwidth sufficiently, you might have to release an IPSec termination node. For
example, if you reduce the bandwidth in a compute location from 1500 Mbps to 800 Mbps,
you would need to remove one of the existing IPSec termination nodes. If any of those nodes
are being used by existing locations, you must reassign the IPSec termination node before you
delete the IPSec termination node.

Prisma Access Administrator’s Guide (Panorama Managed) 324 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

QoS Migration Guidelines

If you use QoS with your current Prisma Access remote network deployment and you allocate
bandwidth by location, you can migrate to an aggregate bandwidth deployment while still
retaining your existing QoS policies and profiles.
Using the aggregate bandwidth model, you allocate bandwidth at an aggregate level per compute
location, and Prisma Access dynamically allocates the bandwidth based on load or demand per
location.
After migration, the QoS tab displays the QoS configuration in the remote network settings
(Panorama > Cloud Services > Configuration > Remote Networks > Settings). Any compute
locations that map to locations that have QoS enabled have Enable QoS selected; any compute
locations that map to locations that do not have QoS enabled have Enable QoS deselected.
The following screenshot shows a sample QoS tab after migration. A remote network in the US
West location has QoS enabled, and no other locations have QoS enabled. Since the US West
location maps to the US Southwest compute location, the QoS tab shows QoS enabled for the US
Southwest compute location.

Palo Alto Networks makes the following recommendations and requirements for QoS in an
aggregate bandwidth deployment.
• Because bandwidth is shared for all locations in a single compute location, you should change
the Class Bandwidth Type of Mbps to Percentage. The only time that a bandwidth type of

Prisma Access Administrator’s Guide (Panorama Managed) 325 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Mbps is supported is when you have an existing deployment that allocates bandwidth by
location and you then migrate to an aggregate bandwidth deployment.

• You cannot adjust QoS bandwidth allocation based on Mbps in the profile; for profiles that use
a Percentage bandwidth type, you can change the QoS bandwidth per location by adjusting the
Guaranteed Bandwidth Ratio and customizing the QoS profile per site.

Prisma Access Administrator’s Guide (Panorama Managed) 326 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

• You cannot mix bandwidth types in a compute location; if you do, you receive an error
message during commit.

• If you add new locations and those locations belong to a new compute location, you will only
be able to create profiles that have a Class Bandwidth Type of Percentage in the new compute
location.
• If you retain QoS profiles that have a Class Bandwidth Type of Mbps, any changes you make
to the Guaranteed Bandwidth Ratio or customize the QoS profile per site are ignored.
• After migration, any locations who use QoS profiles with a Class Bandwidth Type of Mbps
show a QoS Class Type For Sites of Mbps for their corresponding compute location in the QoS
tab. QoS Profiles with a Class Bandwidth Type of Percentage show a QoS Class Type For Sites
of Percentage.
In addition, you cannot select any QoS profiles that have a Class Bandwidth Type of Mbps.
The following screenshot shows the US Southwest compute location using a QoS profile with

Prisma Access Administrator’s Guide (Panorama Managed) 327 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

a Class Bandwidth Type of Mbps. That choice is not selectable in the drop-down in the QoS
Profile area.

However, you can select a QoS Profile that uses a Class Bandwidth Type of Percentage
(QoS-2 in this example).

Prisma Access Administrator’s Guide (Panorama Managed) 328 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

• If you change the QoS profile for a compute location from a Class Bandwidth Type of Mbps
to Percentage, you should make the change during a maintenance window or during off peak
hours. Changing the QoS profile might change the traffic prioritization.

• You can only select QoS profiles with a Class Bandwidth Type of Percentage when you
customize the QoS profile per site.

Migrate to the Aggregate Bandwidth Model

If you have a Prisma Access remote network deployment that allocates bandwidth by location,
Prisma Access allows you to make your deployment more flexible and scalable by migrating to a
deployment that allocates bandwidth by compute location (the aggregate bandwidth model). After
you review the migration planning checklist, use the following steps to migrate to the aggregate
bandwidth model.
STEP 1 | Select Panorama > Cloud Services > Configuration > Remote Networks.

Prisma Access Administrator’s Guide (Panorama Managed) 329 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 2 | Edit the settings by clicking the gear icon in the Bandwidth Allocation area.

STEP 3 | Select Migrate in the pop-up window that displays.

The migration to the aggregate bandwidth model is permanent and not reversible.
Before you migrate, review the pre-migration checklist. You must Commit and Push
your changes for them to take effect.
If you have QoS Profiles with a Class Bandwidth Type of Mbps, Prisma Access notifies
you that you should plan to change these profiles to a Class Bandwidth Type of
Percentage.

Prisma Access Administrator’s Guide (Panorama Managed) 330 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 4 | Review the information in the Migration Confirmation window; then, click OK.

If all the location or locations in a compute location have a total bandwidth of less
than 50 Mbps, Prisma Access will increase the bandwidth to 50 Mbps for that
compute location. Prisma Access provides you with the locations that require the
bandwidth increase during the migration process.

Prisma Access migrates your allocated remote network bandwidth to the aggregate bandwidth
model and displays a confirmation window. Click Close to close the window.

STEP 5 | Commit and Push your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 331 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Remote Network Locations with Overlapping Subnets

As a general rule, you cannot have any overlapping subnets within a Prisma Access deployment.
That is, the subnets for all remote network locations, your service connections, and your Prisma
Access for mobile users IP address pool cannot overlap. However, in some circumstances you
cannot avoid having overlapping subnets; for example:
• Your organization has two WAN links that you want to combine for a higher bandwidth
throughput in a single remote network location (an active/active WAN deployment).
• You want to configure an overlapping subnet deployment by design (for example, your
organization uses the same network topology and IP assignments across multiple retail
locations).
• Your organization has one fast WAN link and a slower WAN link, and you want to add both
of them to a remote network and designate the WAN link for traffic based on the subnet or
application. For example, you might want to route all guest Wi-Fi traffic over one WAN and all
other traffic over the other WAN, or you might want to send all web traffic over one WAN and
all other traffic over the other WAN.
• You acquired a company that uses subnets that overlap with your existing subnets you have in
use.
Prisma Access allows you to onboard remote network locations with overlapping subnets, as long
as you select Overlapped Subnets check box in the remote network settings when you Onboard
and Configure Remote Networks.

Remote network connections with overlapped subnets support outbound internet only.
Refer to the table in the following figure for more details. You can bypass these limitations
by configuring source NAT on the on-premise Palo Alto Networks next-generation firewall
(if present) or networking device (router, switch, or SD-WAN device) that connects to the
IPSec tunnel used for the remote network connection with overlapped subnets.

Prisma Access Administrator’s Guide (Panorama Managed) 332 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

If you add a location with overlapping subnets, it has no effect on locations that don’t use
overlapping subnets; those sites retain their existing functionality.

Prisma Access Administrator’s Guide (Panorama Managed) 333 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Configure Remote Network and Service Connection

Connected with a WAN Link
If you have a deployment where a remote network location(s) and an HQ or data center with a
service connection are directly connected over a WAN link, to ensure optimal routing (with eBGP)
you must:
• Add a static route to the eBGP router address. In addition to the default route that sends all
traffic to Prisma Access, you must add a static route locally on the IPSec-capable device or
router at the remote network(s).
• Filter the routes that are advertised from the IPSec capable device or router at HQ to the
eBGP peers at other directly connected locations. As a best practice, configure the BGP router
at HQ to only advertise routes that you want to allow across the WAN link; you ensure that
the eBGP router at HQ does not advertise the routes it learns from Prisma Access to other
remote network location(s) secured by Prisma Access. In this example, the eBGP router at
HQ only advertises routes that employees from the branch office will need to connect to the
servers (subnets) at HQ.
The following illustration shows a retail business with two paths to the servers at the HQ location.
One path is a WAN link that provides direct connectivity for employees accessing servers at HQ,
and the other path secures traffic generated by other users at this location. For example, traffic
generated by customers accessing the retailer’s website over Wifi or using the kiosk at the branch
office to check inventory. This traffic is sent through the tunnel to the remote network and on to
HQ.

Prisma Access Administrator’s Guide (Panorama Managed) 334 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

To set up this configuration, create a remote network connection and create a service connection
to onboard the remote network and HQ locations. The details below show how to set up the
router configuration at each location to ensure optimal routing:
STEP 1 | Add the static routes on your router or on-premises IPSec capable device at the remote
network location.
If you have a Palo Alto Networks firewall at the edge of the WAN link, on Network > Virtual
Routers > Static Routes, Add the static routes:

STEP 2 | Configure the routes that you want to advertise to another directly connected location over
the WAN link.
In this example, you need to configure this on the at HQ location. If you have an on-premises
Palo Alto Networks firewall at the edge of the WAN link, you can set up route redistribution
and configure which BGP routes to export on Network > Virtual Routers > BGP.

Prisma Access Administrator’s Guide (Panorama Managed) 335 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Use Predefined IPSec Templates to Onboard Service and

Remote Network Connections
Prisma Access includes predefined IPSec templates for common third-party IPSec and SD-WAN
devices. These profiles expedite and simplify the onboarding of service connections and remote
network connections that use one of these devices to terminate the connection.
Sharing a common template also allows you to Onboard Multiple Remote Network Connections
of the Same Type with commonly-shared cryptos, pre-shared keys, and Peer identifiers.
• Onboard a Service Connection or Remote Network Connection Using Predefined Templates
• Onboard Multiple Remote Network Connections of the Same Type
• Supported IKE and IPSec Cryptographic Profiles for Common SD-WAN Devices
Prisma Access provides you with the following predefined templates that you can use to set up
IPSec tunnels between your on-premises device and Prisma Access:
• IPSec Tunnels (Network > IPSec Tunnels) under Remote_Network_Template and
Service_Conn_Template.
• IKE Gateways (Network > Network Profiles > IKE Gateways) under
Remote_Network_Template and Service_Conn_Template.
• IPSec Crypto Profiles (Network > Network Profiles > IPSec Crypto) under
Remote_Network_Template and Service_Conn_Template.
• IKE Crypto Profiles (Network > Network Profiles > IKE Crypto) under
Remote_Network_Template and Service_Conn_Template.
Currently, templates for the following vendors are available:

In addition to the following templates, we provide a Generic template that you can use
with any on-premises device that is not listed here.

• Cisco appliances:
• Cisco Integrated Services Routers (ISRs)
• Cisco Adaptive Security Appliances (ASAs)
• Citrix
• Prisma SD-WAN (formerly CloudGenix)
• Riverbed
• Silver Peak
Use the following workflows to onboard service connections or remote network connections
using the predefined IPSec templates.

Prisma Access Administrator’s Guide (Panorama Managed) 336 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Onboard a Service Connection or Remote Network Connection

Using Predefined Templates
To onboard a service connection or remote network connection using the templates provided by
Prisma Access, complete the following task.
STEP 1 | In Panorama, perform configuration so that the templates display in Panorama.
When you upgrade the Cloud Services plugin, the new templates do not automatically display.
Complete this step once after upgrading to have the templates permanently display. New
installations perform this initial configuration as part of their first-time setup and this extra
step is not required.

You can also complete this step if you delete these templates and need to retrieve
them.

• For service connections, select Panorama > Cloud Services > Configuration > Service
Setup, click the gear icon in the Settings area to open the Settings, then click OK.
• For remote network connections, select Panorama > Cloud Services > Configuration >
Remote Networks, click the gear icon in the Settings area to open the Settings, then click
OK.

STEP 2 | Select Network, then select the correct Template (either Remote_Network_Template if you
are creating a remote network connection or Service_Conn_Template if you are creating a
service connection).

STEP 3 | Determine the type of device that is used to terminate the service connection or remote
network connection, and find a template to use with that device.

If your SD-WAN or IPSec device is not on the list, use the generic profiles.

Prisma Access Administrator’s Guide (Panorama Managed) 337 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 4 | Select Network > Network Profiles > IKE Gateways and make the following changes to the
IKE gateway profile for your device:
You can use the IPSec crypto and IKE crypto profiles with no changes; however, you must
make specific changes to the IKE gateway profile to match the network settings.
• (Optional) If you know the public IP address of the on-premises device that will be used to
set up the IPSec tunnel with Prisma Access, set a static IP address by specifying a Peer IP
Address Type of IP and enter the Peer Address for the IPSec tunnel.
• If using a pre-shared key for the IPSec tunnel, specify a Pre-shared Key.
• Specify a Peer Identification of either IP Address or User FQDN.
Be sure that you match the settings you specify here when you configure the device used
to terminate the other side of the IPSec tunnel.

STEP 5 | Onboard the service connection or remote network connection, specifying the IPSec tunnel
configuration that matches the device on the other side of the IPSec tunnel.

Prisma Access Administrator’s Guide (Panorama Managed) 338 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 6 | (Optional) If you need to add a backup tunnel (Secondary WAN) for a service connection or
remote connection, perform the following additional configuration steps.
Configuring a Secondary WAN is not supported in the following deployments:
• If your secondary WAN is set up in active-active mode with the Primary IPSec tunnel.
• If your customer premises equipment (CPE) is set up in an Equal Cost Multipath (ECMP)
configuration with the Primary and Secondary IPSec tunnel.
1. Create a new IKE Gateway for the backup tunnel, copying the settings from the
predefined template you want to duplicate.
The following example creates a backup tunnel configuration for generic networking
devices.

2. Under Advanced Options, specify the IKE Crypto Profile for the predefined template
you want to use.
Palo Alto Networks recommends that you use GCM ciphers instead of CBC ciphers for
IPSec tunnels.
If you are onboarding a Prisma SD-WAN, select Enable Passive Mode.

Prisma Access Administrator’s Guide (Panorama Managed) 339 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

3. Create a new IPSec Tunnel, specifying the new IKE gateway you created, but copying all
the other settings from the default template.

4. When you onboard the service connection or remote network connection, Enable
Secondary WAN and specify the tunnel you created for the backup WAN.

Prisma Access Administrator’s Guide (Panorama Managed) 340 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 7 | Complete the configuration of the service connection or remote network connection by
matching the cryptos, pre-shared key, and Peer identifiers on the device that is used to
terminate the other side of the IPSec tunnel.

STEP 8 | (Optional) If you need to onboard multiple remote network connections that use the same
types of networking devices, Export the configuration of the remote network, edit the
settings, then Import that configuration.
See Onboard Multiple Remote Network Connections of the Same Type for details.

Onboard Multiple Remote Network Connections of the Same

Type
To streamline the process to Onboard and Configure Remote Networks, you can onboard a single
remote network connection that uses a networking device that is common to your network
deployment, then Export those settings to a Comma Separated Value (CSV) text file. The CSV
file includes the values of IPSec tunnel and IKE gateway settings for the network you selected
for export. After you export the common configuration settings, you can edit these settings and
make them unique for each new remote network you want to onboard, retain the settings that are
common to each device, then Import that configuration.
For more information, including a description of all editable fields in the CSV table, see Onboard
Remote Networks with Configuration Import.

Prisma Access Administrator’s Guide (Panorama Managed) 341 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Supported IKE and IPSec Cryptographic Profiles for Common SD-

WAN Devices
This section provides you with the supported cryptographic profiles for many common SD-WAN
devices. If you are configuring an SD-WAN device, use these profiles as a guideline as to what you
can configure for the remote network in Prisma Access.
• Aruba SD-WAN supported IKE and IPSec crypto profiles
• Aryaka SD-WAN supported IKE and IPSec crypto profiles
• Citrix SD-WAN supported IKE and IPSec crypto profiles
• Prisma SD-WAN device supported IKE and IPSec crypto profiles
• Nuage Networks SD-WAN supported IKE and IPSec crypto profiles
• Riverbed SteelConnect SD-WAN supported IKE and IPSec crypto profiles
• Silver Peak SD-WAN supported IKE and IPSec crypto profiles
• Viptela SD-WAN supported IKE and IPSec crypto profiles

Prisma Access Administrator’s Guide (Panorama Managed) 342 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Onboard Remote Networks with Configuration Import

To streamline the process to onboard and configure remote networks, you have the option to
onboard at least one remote network and then export those settings to a Comma Separated Value
(CSV) text file. The CSV file includes the values of IPSec tunnel and IKE gateway settings for the
network you selected for export, and you can then edit these settings and make them unique for
each new network you may want to onboard. You can modify the CSV file to include 100 new
remote networks and then import the CSV file back to speed up the process of onboarding new
remote network locations.
The CSV file does not include keys or passwords, such as the BGP shared secret, the IKE
preshared key, Proxy ID, IKE crypto profile, IPSec crypto profile. Therefore, any keys and
passwords required for the IPSec tunnel and IKE gateway settings are inherited from the network
you select when you initiate the CSV file import.
When using this bulk import process, you must wait for Prisma Access to deploy the
infrastructure for securing these locations.
STEP 1 | Select Panorama > Cloud Services > Configuration > Remote Networks (in the Onboarding
section).

STEP 2 | Select a location, then Export the configuration of a remote network that you have
previously onboarded.
If you have not yet added any locations, you need to Add a location, then download its
configuration. You must select a remote network and click Export. A CSV file that includes the
settings is downloaded to your computer.

STEP 3 | (Deployments that allocate bandwidth by compute location only) Make sure that you have
allocated bandwidth for the locations to onboard.
Each location you onboard has a corresponding compute location for which bandwidth is
allocated.
1. Select Panorama > Cloud Services > Configuration > Remote Networks and click the
gear in the Bandwidth Allocation area.
2. Check the Bandwidth Allocation field in the table that displays.
The table in this area shows the compute location-to-Prisma Access location mapping.
You must have bandwidth allocated for the compute locations that are associated with
the locations you want to onboard. For example, to onboard the Japan Central location,
make sure that you have allocated bandwidth in the Asia Northeast compute location.
3. If you have not yet allocated bandwidth for the compute locations that are associated
with the locations you want to onboard, add it now.

Prisma Access Administrator’s Guide (Panorama Managed) 343 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

STEP 4 | (Deployments that allocate bandwidth by compute location only) Find the IPSec Termination
Node associated with the location or locations you want to onboard.
You assign an IPSec Termination Node to the remote network during onboarding, and you enter
this value in the spn-name column of the CSV file.
To find the IPSec Termination Node, perform one of the following actions:
• Select Panorama > Cloud Services > Configuration > Remote Networks, Add a remote
network and select the location you want to onboard, and make a note of the IPSec
Termination Node choices in the onboarding area.

• Open a command-line interface (CLI) session with the Panorama that manages Prisma
Access and enter the show plugins cloud_services remote-networks agg-
bandwidth region compute-location-name, where compute-location-name is the compute
location that is associated with the location you want to onboard. The IPSec Termination
Node displays in the spn-name-list field.

STEP 5 | Modify the CSV file to add configuration for remote networks.
See Fields in Remote Networks Table for a description of the fields and the possible values in
this file.
You must rename the network(s) listed in the exported file. If the file has duplicate names the
import will fail.

STEP 6 | Import the CSV file.

The configuration from the file are displayed on screen. The remote network you selected to
import the file will serve as a model configuration, and the remote networks listed in the file
will inherit the keys and any missing values that do not have to be unique from there.

STEP 7 | Commit and push your changes.

1. Commit > Commit and Push your changes.
2. Click OK and Push.

Fields in Remote Networks Table

The following table provides a description of the fields in the remote networks table. Fields
marked as Y in the Required row are required fields and fields marked as N are optional.

Prisma Access Administrator’s Guide (Panorama Managed) 344 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Field Description Required?

(Y/N)

name The name of the remote network. Y

bandwidth (Deployments that allocate bandwidth by Y

location only) The allocated bandwidth of the
remote network. Acceptable values are:
• 2 Mbps
• 5 Mbps
• 10 Mbps
• 20 Mbps
• 25 Mbps
• 50 Mbps
• 100 Mbps
• 150 Mbps
• 300 Mbps
• 500 Mbps
• 1000 Mbps

The 1000 Mbps bandwidth option

is in preview mode. The throughput
during preview is delivered on a
best-effort basis and the actual
performance will vary depending
upon the traffic mix.

region The remote network’s location. See the list of Y

Prisma Access locations for the values to enter.
Enter the locations exactly as they are in this
document (for example, US West, or Japan
South).

subnets Statically routed subnets on the LAN side of the N

remote network. Separate multiple subnets with
commas.

bgp_peer_as The BGP Autonomous System Number (ASN) of N

the remote network peer device.

bgp_peer_address The BGP peer address of the remote network N

peer device.

Prisma Access Administrator’s Guide (Panorama Managed) 345 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Field Description Required?

(Y/N)

tunnel_name The name of the IPSec tunnel configuration. A Y

unique value is required.

gateway_name The name of the IKE Gateway configuration. A Y

unique value is required.

peer_ip_address The IP address of the Prisma Access peer device. N

local_id_type The type of IKE ID that Prisma Access presents N

to the peer device. If you use certificates in the
remote network to which you import this file,
all imported types specified will refer to the
Configured Certificate values.

local_id_value The value of the IKE ID that Prisma Access N

presents to the peer device. If you use
certificates in the remote network to which you
import this file, all imported types specified will
refer to the Configured Certificate values.

peer_id_type The value of the IKE ID that the peer presents N

to Prisma Access. If you use certificates in the
remote network to which you import this file, all
imported types specified will refer to the Peer
Certificate values.

peer_id_value The value of the IKE ID that Prisma Access N

presents to the peer device. If you use
certificates in the remote network to which you
import this file, all imported types specified will
refer to the Peer Certificate values.

monitor_ip The tunnel monitoring IP address the cloud will N

use to determine that the IPSec tunnel is up and
the peer network is reachable.

You cannot export a proxy-ID value

for the tunnel monitor.

proxy_ids The proxy IDs that are configured for the peer. N
For route-based VPNs, leave this field blank.
Specify the Proxy ID in the following CSV
configuration format:
[{"name":"proxyidname", "local":"1.2.3.4/32",
"remote":"4.3.2.1/32", "protocol":{"udp":
{"local-port":123, "remote-port":234}}},

Prisma Access Administrator’s Guide (Panorama Managed) 346 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Field Description Required?

(Y/N)
{"name":"proxyidname2", "local":"2.3.4.5/32",
"remote":"3.4.5.6/32", "protocol":{"tcp":
{"local-port":234,"remote-port":345}}}]

sec_wan_enabled Specifies whether or not you enable a secondary N

IPSec tunnel. Acceptable values are yes and no.

sec_tunnel_name The name of the secondary IPSec tunnel N

configuration. A unique value is required if you
specify a secondary tunnel.

sec_gateway_name The name of the secondary IKE Gateway N

configuration. A unique value is required if you
specify a secondary tunnel.

sec_peer_ip_address The IP address of the Prisma Access peer device N

for the secondary IPSec tunnel.

sec_local_id_type The type of IKE ID that Prisma Access presents N

to the peer device for the secondary IPSec
tunnel. If you use certificates in the remote
network to which you import this file, all
imported types specified will refer to the
Configured Certificate values.

sec_local_id_value The value of the IKE ID that Prisma Access N

presents to the peer device for the secondary
IPSec tunnel. If you use certificates in the
remote network to which you import this file,
all imported types specified will refer to the
Configured Certificate values.

sec_peer_id_type The value of the IKE ID that the peer presents to N

Prisma Access for the secondary IPSec tunnel.
If you use certificates in the remote network
to which you import this file, all imported types
specified will refer to the Peer Certificate values.

sec_peer_id_value The value of the IKE ID that Prisma Access N

presents to the peer device for the secondary
IPSec tunnel. If you use certificates in the
remote network to which you import this file, all
imported types specified will refer to the Peer
Certificate values.

sec_monitor_ip The tunnel monitoring IP address the cloud will N

use for the secondary IPSec tunnel to determine

Prisma Access Administrator’s Guide (Panorama Managed) 347 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Field Description Required?

(Y/N)
that the IPSec tunnel is up and the peer network
is reachable.

You cannot export a proxy-ID value

for the tunnel monitor.

sec_proxy_ids The proxy IDs that are configured for the peer N
for the secondary IPSec tunnel. For route-based
VPNs, leave this field blank. Specify the Proxy ID
in the following CSV configuration format:
[{"name":"proxyidname", "local":"1.2.3.4/32",
"remote":"4.3.2.1/32", "protocol":{"udp":
{"local-port":123, "remote-port":234}}},
{"name":"proxyidname2", "local":"2.3.4.5/32",
"remote":"3.4.5.6/32", "protocol":{"tcp":
{"local-port":234,"remote-port":345}}}]

ecmp_link_1_tunnel_name (ECMP deployments only) The name of the

IPSec tunnel configuration for ECMP tunnel 1. A
unique value is required.

ecmp_link_1_gateway_name (ECMP deployments only) The name of the IKE

Gateway configuration for ECMP tunnel 1. A
unique value is required.

ecmp_link_1_peer_ip_address (ECMP deployments only) The IP address of the

Prisma Access peer device for ECMP tunnel 1.

ecmp_link_1_local_id_type (ECMP deployments only) The type of IKE ID

that Prisma Access presents to the peer device
for ECMP tunnel 1. If you use certificates in
the remote network to which you import this
file, all imported types specified will refer to the
Configured Certificate values.

ecmp_link_1_local_id_value (ECMP deployments only) The value of the

IKE ID that Prisma Access presents to the peer
device for ECMP tunnel 1. If you use certificates
in the remote network to which you import this
file, all imported types specified will refer to the
Configured Certificate values.

ecmp_link_1_peer_id_type (ECMP deployments only) The value of the IKE

ID that the peer presents to Prisma Access for
ECMP tunnel 1. If you use certificates in the
remote network to which you import this file, all

Prisma Access Administrator’s Guide (Panorama Managed) 348 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Field Description Required?

(Y/N)
imported types specified will refer to the Peer
Certificate values.

ecmp_link_1_peer_id_value (ECMP deployments only) The value of the

IKE ID that Prisma Access presents to the peer
device for ECMP tunnel 1. If you use certificates
in the remote network to which you import this
file, all imported types specified will refer to the
Peer Certificate values.

ecmp_link_1_monitor_ip (ECMP deployments only) The tunnel monitoring

IP address the cloud will use to determine that
the IPSec tunnel is up and the peer network is
reachable for ECMP tunnel 1.

You cannot export a proxy-ID value

for the tunnel monitor.

ecmp_link_1_proxy_ids (ECMP deployments only) The proxy IDs that are

configured for the peer for ECMP tunnel 1. For
route-based VPNs, leave this field blank. Specify
the Proxy ID in the following CSV configuration
format:
[{"name":"proxyidname", "local":"1.2.3.4/32",
"remote":"4.3.2.1/32", "protocol":{"udp":
{"local-port":123, "remote-port":234}}},
{"name":"proxyidname2", "local":"2.3.4.5/32",
"remote":"3.4.5.6/32", "protocol":{"tcp":
{"local-port":234,"remote-port":345}}}]

ecmp_link_1_bgp_peer_as (ECMP deployments only) The BGP Autonomous

System Number (ASN) of the remote network
peer device for ECMP tunnel 1.

ecmp_link_1_bgp_peer_address (ECMP deployments only) The BGP peer address

of the remote network peer device for ECMP
tunnel 1.

ecmp_link_2_tunnel_name (ECMP deployments only) The name of the

IPSec tunnel configuration for ECMP tunnel 2. A
unique value is required.

ecmp_link_2_gateway_name (ECMP deployments only) The name of the IKE

Gateway configuration for ECMP tunnel 2. A
unique value is required.

Prisma Access Administrator’s Guide (Panorama Managed) 349 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Field Description Required?

(Y/N)

ecmp_link_2_peer_ip_address (ECMP deployments only) The IP address of the

Prisma Access peer device for ECMP tunnel 2.

ecmp_link_2_local_id_type (ECMP deployments only) The type of IKE ID

that Prisma Access presents to the peer device
for ECMP tunnel 2. If you use certificates in
the remote network to which you import this
file, all imported types specified will refer to the
Configured Certificate values.

ecmp_link_2_local_id_value (ECMP deployments only) The value of the

IKE ID that Prisma Access presents to the peer
device for ECMP tunnel 2. If you use certificates
in the remote network to which you import this
file, all imported types specified will refer to the
Configured Certificate values.

ecmp_link_2_peer_id_type (ECMP deployments only) The value of the IKE

ID that the peer presents to Prisma Access for
ECMP tunnel 2. If you use certificates in the
remote network to which you import this file, all
imported types specified will refer to the Peer
Certificate values.

ecmp_link_2_peer_id_value (ECMP deployments only) The value of the

IKE ID that Prisma Access presents to the peer
device for ECMP tunnel 2. If you use certificates
in the remote network to which you import this
file, all imported types specified will refer to the
Peer Certificate values.

ecmp_link_2_monitor_ip (ECMP deployments only) The tunnel monitoring

IP address the cloud will use to determine that
the IPSec tunnel is up and the peer network is
reachable for ECMP tunnel 2.

You cannot export a proxy-ID value

for the tunnel monitor.

ecmp_link_2_proxy_ids (ECMP deployments only) The proxy IDs that are

configured for the peer for ECMP tunnel 2. For
route-based VPNs, leave this field blank. Specify
the Proxy ID in the following CSV configuration
format:
[{"name":"proxyidname", "local":"1.2.3.4/32",
"remote":"4.3.2.1/32", "protocol":{"udp":

Prisma Access Administrator’s Guide (Panorama Managed) 350 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Field Description Required?

(Y/N)
{"local-port":123, "remote-port":234}}},
{"name":"proxyidname2", "local":"2.3.4.5/32",
"remote":"3.4.5.6/32", "protocol":{"tcp":
{"local-port":234,"remote-port":345}}}]

ecmp_link_2_bgp_peer_as (ECMP deployments only) The BGP Autonomous

System Number (ASN) of the remote network
peer device for ECMP tunnel 2.

ecmp_link_2_bgp_peer_address (ECMP deployments only) The BGP peer address

of the remote network peer device for ECMP
tunnel 2.

ecmp_link_3_tunnel_name (ECMP deployments only) The name of the

IPSec tunnel configuration for ECMP tunnel 3. A
unique value is required.

ecmp_link_3_gateway_name (ECMP deployments only) The name of the IKE

Gateway configuration for ECMP tunnel 3. A
unique value is required.

ecmp_link_3_peer_ip_address (ECMP deployments only) The IP address of the

Prisma Access peer device for ECMP tunnel 3.

ecmp_link_3_local_id_type (ECMP deployments only) The type of IKE ID

that Prisma Access presents to the peer device
for ECMP tunnel 3. If you use certificates in
the remote network to which you import this
file, all imported types specified will refer to the
Configured Certificate values.

ecmp_link_3_local_id_value (ECMP deployments only) The value of the

IKE ID that Prisma Access presents to the peer
device for ECMP tunnel 3. If you use certificates
in the remote network to which you import this
file, all imported types specified will refer to the
Configured Certificate values.

ecmp_link_3_peer_id_type (ECMP deployments only) The value of the IKE

ID that the peer presents to Prisma Access for
ECMP tunnel 3. If you use certificates in the
remote network to which you import this file, all
imported types specified will refer to the Peer
Certificate values.

ecmp_link_3_peer_id_value (ECMP deployments only) The value of the

IKE ID that Prisma Access presents to the peer
device for ECMP tunnel 3. If you use certificates

Prisma Access Administrator’s Guide (Panorama Managed) 351 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Field Description Required?

(Y/N)
in the remote network to which you import this
file, all imported types specified will refer to the
Peer Certificate values.

ecmp_link_3_monitor_ip (ECMP deployments only) The tunnel monitoring

IP address the cloud will use to determine that
the IPSec tunnel is up and the peer network is
reachable for ECMP tunnel 3.

You cannot export a proxy-ID value

for the tunnel monitor.

ecmp_link_3_proxy_ids (ECMP deployments only) The proxy IDs that are

configured for the peer for ECMP tunnel 3. For
route-based VPNs, leave this field blank. Specify
the Proxy ID in the following CSV configuration
format:
[{"name":"proxyidname", "local":"1.2.3.4/32",
"remote":"4.3.2.1/32", "protocol":{"udp":
{"local-port":123, "remote-port":234}}},
{"name":"proxyidname2", "local":"2.3.4.5/32",
"remote":"3.4.5.6/32", "protocol":{"tcp":
{"local-port":234,"remote-port":345}}}]

ecmp_link_3_bgp_peer_as (ECMP deployments only) The BGP Autonomous

System Number (ASN) of the remote network
peer device for ECMP tunnel 3.

ecmp_link_3_bgp_peer_address (ECMP deployments only) The BGP peer address

of the remote network peer device for ECMP
tunnel 3.

ecmp_link_4_tunnel_name (ECMP deployments only) The name of the

IPSec tunnel configuration for ECMP tunnel 4. A
unique value is required.

ecmp_link_4_gateway_name (ECMP deployments only) The name of the IKE

Gateway configuration for ECMP tunnel 4. A
unique value is required.

ecmp_link_4_peer_ip_address (ECMP deployments only) The IP address of the

Prisma Access peer device for ECMP tunnel 4.

ecmp_link_4_local_id_type (ECMP deployments only) The type of IKE ID

that Prisma Access presents to the peer device
for ECMP tunnel 4. If you use certificates in

Prisma Access Administrator’s Guide (Panorama Managed) 352 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Field Description Required?

(Y/N)
the remote network to which you import this
file, all imported types specified will refer to the
Configured Certificate values.

ecmp_link_4_local_id_value (ECMP deployments only) The value of the

IKE ID that Prisma Access presents to the peer
device for ECMP tunnel 4. If you use certificates
in the remote network to which you import this
file, all imported types specified will refer to the
Configured Certificate values.

ecmp_link_4_peer_id_type (ECMP deployments only) The value of the IKE

ID that the peer presents to Prisma Access for
ECMP tunnel 4. If you use certificates in the
remote network to which you import this file, all
imported types specified will refer to the Peer
Certificate values.

ecmp_link_4_peer_id_value (ECMP deployments only) The value of the

IKE ID that Prisma Access presents to the peer
device for ECMP tunnel 4. If you use certificates
in the remote network to which you import this
file, all imported types specified will refer to the
Peer Certificate values.

ecmp_link_4_monitor_ip (ECMP deployments only) The tunnel monitoring

IP address the cloud will use to determine that
the IPSec tunnel is up and the peer network is
reachable for ECMP tunnel 4.

You cannot export a proxy-ID value

for the tunnel monitor.

ecmp_link_4_proxy_ids (ECMP deployments only) The proxy IDs that are

configured for the peer for ECMP tunnel 4. For
route-based VPNs, leave this field blank. Specify
the Proxy ID in the following CSV configuration
format:
[{"name":"proxyidname", "local":"1.2.3.4/32",
"remote":"4.3.2.1/32", "protocol":{"udp":
{"local-port":123, "remote-port":234}}},
{"name":"proxyidname2", "local":"2.3.4.5/32",
"remote":"3.4.5.6/32", "protocol":{"tcp":
{"local-port":234,"remote-port":345}}}]

Prisma Access Administrator’s Guide (Panorama Managed) 353 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Use Remote Networks to Secure Branches

Field Description Required?

(Y/N)

ecmp_link_4_bgp_peer_as (ECMP deployments only) The BGP Autonomous

System Number (ASN) of the remote network
peer device for ECMP tunnel 4.

ecmp_link_4_bgp_peer_address (ECMP deployments only) The BGP peer address

of the remote network peer device for ECMP
tunnel 4.

spn-name (Deployments that allocate bandwidth by

compute location only) The name of the IPSec
Termination Node. This field is required for
deployments that allocate bandwidth by
compute location.

Prisma Access Administrator’s Guide (Panorama Managed) 354 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based
Policies with Prisma Access
Prisma Access requires that you configure IP address-to-username mapping to consistently
enforce user-based policy for mobile users and users at remote network locations. In addition, you
need to configure username to user-group mapping if you want to enforce policy based on group
membership.
To select users and groups from a drop-down list when you create and configure policies in
Panorama, you can also configure Panorama to obtain the list of user groups retrieved from the
username-to-user group mapping.
The following sections provide an overview and the steps you perform to configure and
implement User-ID and use the Cloud Identity Engine to get IP address-to-username and
username-to-user group mapping in Prisma Access.
• Configure User-ID in Panorama Managed Prisma Access
• Configure User-ID for Remote Network Deployments
• Get User and Group Information Using the Cloud Identity Engine
• Populate User and Group Names in Security Policy Rules
• Redistribute User-ID Information Between Prisma Access and On-Premises Firewalls

355
Configure User-ID and User-Based Policies with Prisma Access

Configure User-ID in Panorama Managed Prisma Access

This section provides the steps you perform to configure User-ID for Prisma Access.
STEP 1 | Configure IP address-to-username mapping for your mobile users and users at remote
network locations.
• For Mobile Users—GlobalProtect deployments, the GlobalProtect agent in Prisma Access
automatically performs User-ID mapping.
• For users at remote networks, configure User-ID for your remote network locations to map
IP addresses to User IDs.

STEP 2 | Configure username-to-user group mapping for your mobile users and users at remote
network locations.
For Mobile Users—GlobalProtect, Explicit Proxy, and remote network deployments, configure
the Directory Sync component of the Cloud Identity Engine to retrieve user and group
information from your Active Directory (AD); then, configure Group Mapping Settings in your
Mobile Users—GlobalProtect or remote network deployment
Alternatively, you can enable username-to-user group mapping for mobile users and users at
remote networks using an LDAP server profile.

We recommend using a Group Include List in the LDAP server profile, so that you can
specify which groups you want to retrieve, instead of retrieving all group information.

STEP 3 | Allow Panorama to use username-to-user group mapping in security policies by completing
one of the following actions:
• Configure the Directory Sync component of the Cloud Identity Engine to retrieve user
and group information from your Active Directory (AD); then, configure Group Mapping
Settings in your Mobile Users—GlobalProtect, Mobile Users—Explicit Proxy, or remote
network deployment.

The Cloud Identity Engine does not auto-populate user and group information to
security policy rules and to Panorama. To simplify rule creation based on user and
group information, configure a master device or the Cloud Identity Engine and
specify it during your Prisma Access configuration.
• Configure group-based policy by specifying the full distinguished name (DN) of the group.

STEP 4 | Redistribute HIP information to Panorama.

Prisma Access Administrator’s Guide (Panorama Managed) 356 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

Configure User-ID for Remote Network Deployments

Prisma Access requires that you configure IP address-to-username mapping to consistently
enforce user-based policy for users at remote network locations. In addition, you need to
configure username to user-group mapping if you want to enforce policy based on group
membership.
You can then configure your deployment to allow Panorama to retrieve the list of user groups
retrieved from the username-to-user group mapping, which allows you to easily select these
groups from a drop-down list when you create and configure policies in Panorama.
To configure User-ID collection and redistribution for users who are protected by Prisma Access
remote networks, use the following methods to enable user-based access and visibility to
applications and resources:

Prisma Access Administrator’s Guide (Panorama Managed) 357 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

STEP 1 | Map IP addresses to users in Prisma Access.

• To map users as they log in to your Exchange servers, domain controllers, eDirectory
servers, or Windows clients you must configure a User-ID agent:
• Configure User Mapping Using the PAN-OS Integrated User-ID Agent.
You can configure the agent on either a service connection or a remote network
connection.
To configure the agent on a remote network connection, select the
Remote_Network_Template when you create the agent.

Optionally, to configure the agent on a service connection, select the

Service_Conn_Template.

If you configure the agent on a service connection, you need to perform

additional steps to redistribute that information to the remote network; to
do so, create a Data Redistribution Agent in the Remote_Network_Template
and specify the User-ID Agent Address (Panorama > Cloud Services > Status
> Network Details > Service Connection > User-ID Agent Address) in the Host
field.
• Configure User Mapping Using the Windows User-ID Agent.
Whatever mapping method you use applies to all remote network connections across your
deployment.
• If you have users with client systems that aren’t logged in to your domain servers—for
example, users running Linux clients that don’t log in to the domain—you can Map IP
Addresses to Usernames Using Authentication Portal (formerly Captive Portal).

Kerberos is not supported for use with Authentication Portal in conjunction with
Prisma Access.

To perform IP to User Mapping using Authentication portal, Palo Alto Networks

recommends that you associate a local DNS entry with the Captive Portal Redirect IP

Prisma Access Administrator’s Guide (Panorama Managed) 358 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

Address (Panorama > Cloud Services > Status > Network Details > Service Infrastructure >
Captive Portal Redirect IP Address.

• To obtain user mappings from existing network services that authenticate users—such as
wireless controllers, 802.1x devices, Apple Open Directory servers, proxy servers, or other
Network Access Control (NAC) mechanisms—Configure User-ID to Monitor Syslog Senders
for User Mapping.
While you can configure either the Windows agent or the PAN-OS integrated User-ID
agent on to listen for authentication syslog messages from the network services, because
only the PAN-OS integrated agent supports syslog listening over TLS, it is the preferred
configuration.
• To include the username and domain in the headers for outgoing traffic so other devices in
your network can identify the user and enforce user-based policy, you can Insert Username
in HTTP Headers.

STEP 2 | Configure username-to-user group mapping for your mobile users and users at remote
network locations.
• Configure the Directory Sync component of the Cloud Identity Engine to retrieve user and
group information from the supported directory types; then, configure Group Mapping
Settings in your remote network deployment.
• Alternatively, you can enable group mapping using an LDAP server profile.

STEP 3 | Allow Panorama to populate users and groups drop-down lists in security policies by
completing one of the following actions:
• Configure one or more next-generation firewalls or the Cloud Identity Engine to populate
usernames and user groups in security policies.
• Configure group-based policy by specifying the full distinguished name (DN) of the group.

STEP 4 | (Optional) If you have on-premise firewalls in your deployment, redistribute the user-ID
information from Prisma Access to on-premise firewalls and from on-premise firewalls to
Prisma Access.

Prisma Access Administrator’s Guide (Panorama Managed) 359 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

Get User and Group Information Using the Cloud

Identity Engine
Prisma Access retrieves user and group information from your organization’s cloud directory
or Active Directory (AD), to enforce user- and group-based policy. Optionally, Prisma Access
retrieves user behavior-based risk signals from some cloud directory vendors, such as Azure
Active Directory, to enforce automated security actions. You can simplify the retrieval of user and
group information by using the Cloud Identity Engine.
In addition to simplifying user and group information retrieval, integrating the Cloud Identity
Engine with Prisma Access can free up the bandwidth and load on your cloud directory or AD.
You can use the Cloud Identity Engine to retrieve user and group information for Prisma Access
for mobile users, remote networks, or both, by completing the following steps.
The Cloud Identity Engine integration with Prisma Access has the following implementation
restrictions:
• Make sure that the groups you use with Cloud Identity Engine do not have any of the following
special characters, because Prisma Access does not support the use of following special
characters in groups and commit operations will fail:
• " (Double quotes)
• ' (Apostrophe)
• < (less than sign)
• > (greater than sign)
• & (ampersand)
• If you associate Cloud Identity Engine with Prisma Access, your user names must use the
NetBIOS format that includes the domain. You can specify usernames in email format
(username@domain), NetBIOS\sAMAccountName format, or User Principal Name (UPN)
format ([email protected]).
• Enter group names in the distinguishedName format (for example,
CN=Users,CN=Builtin,DC=Example,DC=com).
• Cloud Identity Engine does not apply any settings you specify in the group include list (Device
> User Identification > Group Mapping Settings > Group Include List); instead, it retrieves
user and group information from your entire configuration, including groups used in all device
groups and templates.
STEP 1 | Create a Cloud Identity Engine instance for Prisma Access, and make a note of the instance
name.
When you activate the Cloud Identity Engine, it creates an instance. You use the instance
name when you associate the Cloud Identity Engine with Prisma Access in a later step.
Optionally, if you need to create a separate instance for Prisma Access, create it and make a
note of the instance name.

Prisma Access Administrator’s Guide (Panorama Managed) 360 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

STEP 2 | Configure the Cloud Identity Engine to retrieve your directory data.

STEP 3 | (Deployments with on-premises Active Directory only) If you use an on-premises Active
Directory, Install and configure the Cloud Identity Agent to communicate with your on-
premises AD and configure mutual authentication between the Cloud Identity Engine service
and the agent.

STEP 4 | Enable the Cloud Identity Engine on Prisma Access.

1. On the Panorama that manages Prisma Access, select the username-to-user group
mapping setting tab.
• For a Mobile Users—GlobalProtect deployment, select Panorama > Cloud Services
> Configuration > Mobile Users—GlobalProtect, select the gear icon to edit the
settings, then select Group Mapping Settings.
• For a Mobile Users—Explicit Proxy deployment, select Panorama > Cloud Services
> Configuration > Mobile Users—Explicit Proxy, select the gear icon to edit the
settings, then select Group Mapping Settings.
• For a remote network deployment, select Panorama > Cloud Services >
Configuration > Remote Networks, select the gear icon to edit the settings, then
select Group Mapping Settings.
2. Select Enable Directory Sync Integration to enable Cloud Identity Engine with Prisma
Access.
3. Enter the following information:
• Enter the Primary Username. This field is required.
The Primary Username attribute controls the formatting that is used in logs and
reporting. If the primary username attribute is userPrincipalName (UPN), all the log
and reporting entries display the source user in that format. Many deployments use a
format of either UPN, sAMAccountName, or mail. If your organization uses another

Prisma Access Administrator’s Guide (Panorama Managed) 361 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

attribute, you can specify it here to ensure consistency for logging and reporting
across your organization.
If you configure Azure AD or Okta Directory as the identity provider (IdP) in the
Cloud Identity Engine, specify the Primary Username as userPrincipalName. Prisma
Access supports the userPrincipalName (UPN) attribute that is used with Azure AD
and Okta Directory.
• (Optional) Enter the E-Mail attribute (such as mail).
• (Optional) If you use alternate name attributes for the user, enter them. You can enter
up to three alternate user names (Alternate User Name 1, Alternate User Name 2,
and Alternate User Name 3).
4. Click OK when complete.

STEP 5 | Commit and push (Commit > Commit and Push) your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 362 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

Populate User and Group Names in Security Policy Rules

After you configure User-ID mapping in Prisma Access, you need to be able to retrieve the
current username-to-user group information for mobile users and users at remote networks.
While configuring Group Mapping in the Cloud Identity Engine performs username-to-user group
mapping, those user groups are not selectable in security policy rules. You can populate the
groups to allow them to be selected in security policy rule drop-down lists by either configuring
a next-generation firewall as a Master Device or configuring the Cloud Identity Engine to do so.
Alternatively, you can implement User-ID mapping in policies using long-form Distinguished Name
(DN) entries.
• Populate User Group Names in Security Policy Rules Using a Master Device
• Populate User Group Names in Security Policy Rules Using the Cloud Identity Engine
• Use Long-Form DN Entries to Implement User- and Group-Based Policy

Populate User Group Names in Security Policy Rules Using the

Cloud Identity Engine
In addition to using the Cloud Identity Engine to retrieve user and group information, you can use
the Cloud Identity Engine to populate user group names in security policy rules. This integration
eliminates the need to configure an on-premise or VM-series next-generation firewall as a Master
Device for this purpose; however, Master Devices are still supported.
You can also use Cloud Identity Engine to populate group names in Panorama Managed multi-
tenant deployments, which is not possible when using a Master Device.
To enable the Cloud Identity Engine to populate group names in security policy rules, complete
the following steps.
STEP 1 | In the Cloud Identity Engine, activate the Cloud Identity Engine and add an on-premises or
cloud-based directory, if you have not already done so.

Prisma Access Administrator’s Guide (Panorama Managed) 363 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

STEP 2 | Configure the Cloud Identity Engine as a mapping source.

1. From the Panorama that manages Prisma Access, select Panorama > User Identification
> Cloud Identity Engine and Add a profile.
2. For the Instance, specify the following parameters:
• Region—Select the regional endpoint for your tenant.

The region you select must match the region you select when you activated
your Cloud Identity Engine tenant.
• Cloud Identity Engine Instance—Select the Cloud Identity Engine instance to
associate with the profile.
• Domain—Select the domain that contains the directories you want to use.
• Update Interval (min)—Enter the number of minutes that you want Panorama to wait
between updates from the Cloud Identity Engine app to Panorama (also known as a
refresh interval). The default is 60 minutes and the range is 5—1440.
3. Verify that the profile is Enabled.

4. For the User Attributes, select the format for the Primary Username. You can optionally
select the formats for the E-Mail and an Alternate Username. You can configure up to
three alternate username formats if your users log in using multiple username formats.
When you view users in security policy rules, the username displays in the primary
username format you select here.

Prisma Access Administrator’s Guide (Panorama Managed) 364 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

5. For the Group Attributes, select the format for the Group Name.

6. Leave the Device Attributes as None.

7. Click OK then Commit and Push your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 365 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

STEP 3 | Attach your profile to your Prisma Access configuration.

1. Go to the Settings for the deployment you are adding.
• For a Mobile Users—GlobalProtect deployment, select Panorama > Cloud Services >
Configuration > Mobile Users—GlobalProtect and click the gear to edit the Settings.
• For a Mobile Users—Explicit Proxy deployment, select Panorama > Cloud Services >
Configuration > Mobile Users—Explicit Proxy and click the gear to edit the Settings.
• For a Mobile Users—Remote Networks deployment, select Panorama > Cloud
Services > Configuration > Mobile Users—Remote Networks and click the gear to
edit the Settings.
2. Select Cloud Identity Engine.
3. Select the Cloud Identity Engine profile you created.

STEP 4 | Select Commit > Commit to Panorama and Commit your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 366 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

STEP 5 | Verify that Prisma Access has the mapping information from the Cloud Identity Engine.
1. Select Panorama > Device Groups > <template-name>, where <template-name> is the
template for the deployment you are configuring, and verify that the Cloud Identity
Engine profile is attached to the device group.
The following example shows that the device group is successfully attached to the
Explicit_Proxy_Device_Group.

2. Select Objects > Security > Pre Rules, Add a security policy rule, and verify that the
groups are populated in the user area.

Prisma Access Administrator’s Guide (Panorama Managed) 367 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

Populate User Group Names in Security Policy Rules Using a

Master Device
While configuring Group Mapping in the Cloud Identity Engine performs username-to-user group
mapping, those usernames and user groups do not populate to security policies. To simplify the
creation or modification of user- and group-based policies, you can use a Master Device to add
the group names to drop-down lists in security policy rules. You need to designate a firewall as a
Master Device for each device group. After you add a Master Device, the device group inherits all
policies defined on the master device; for this reason, it should be a standalone, dedicated device
to be used for that device group.
To allow selection of group names in drop-down lists in security policies, Palo Alto Networks
recommends that you designate a Master Device for each device group. You can configure either
an on-premises firewall or a VM-series firewall as a master device.
The following figure shows a User-ID deployment where the administrator has configured an on-
premises device as a Master Device. Callouts in the figure show the process.
1. A next-generation on-premises or VM-series firewall that the administrator has configured as a
Master Device retrieves the latest username-to-user group mapping from the LDAP server and
User-ID agent in the data center.
2. Panorama gets the username-to-user group mapping from the Master Device.
Panorama uses this mapping only for the purposes of populating the group names in drop-
down lists in security policies, thus simplifying the creation of policies based on groups.

Prisma Access Administrator’s Guide (Panorama Managed) 368 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

Configure an on-premises or VM-Series Firewall as a Master Device

Use the following procedure to configure an on-premises or VM-series firewall as a Master
Device.

You can only use one Master Device per device group; if you need to configure a Master
Device for different device groups, you need to create a separate Master Device for each
device group.

STEP 1 | Make sure that the device you want to use as a Master Device is managed by the same
Panorama that manages Prisma Access.
You can check your managed devices under Panorama > Managed Devices.

Prisma Access Administrator’s Guide (Panorama Managed) 369 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

STEP 2 | Add the master device to your Prisma Access mobile user or remote network deployment.

• For a Mobile Users—GlobalProtect deployment, select Panorama > Cloud Services >
Configuration > Mobile Users—GlobalProtect, click the gear icon in the Settings, and
select the on-premise firewall you want to specify as a Master Device.

If you use the default Device Group Name (Mobile_User_Device_Group in this

case) and Parent Device Group (Shared in this case), any devices that are not
associated with another device group display in the drop-down choices. If you
have associated the master device with another device group, select the Parent
Device Group associated with that device group have it display in the drop-down.

• For a Mobile Users—Explicit Proxy deployment, select Panorama > Cloud Services >
Configuration > Mobile Users—Explicit Proxy, click the gear icon in the Settings, and
select the Master Device you created.

Prisma Access Administrator’s Guide (Panorama Managed) 370 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

• For remote network deployments, the device group with a remote network connection,
select Panorama > Cloud Services > Configuration > Remote Networks, click the gear
icon in the Settings, and select the Master Device you created.

Prisma Access Administrator’s Guide (Panorama Managed) 371 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

Prisma Access automatically populates username-to-user group mapping for the

device group that is associated with the master device only. For this example, the
auto-population would occur only in the Remote_Network_Device_Group device
group and would not populate to any other device groups.

STEP 3 | Click OK.

Use Long-Form DN Entries to Implement User- and Group-Based

Policy
If you have not configured a next-generation firewall as a master device or configured a Cloud
Identity Engine to populate users and groups in security policy rules, you can use long-form
distinguished name (DN) entries in Panorama instead. Prisma Access uses the DN entries to
evaluate the User-ID-based policies you have configured in Panorama.
For example, given a User named Bob Alice who works in IT and is located on the first floor,
a matching security policy may have cn=first_floor, ou=it_staff, dc=dev,
dc=example, dc=com if the policy is to be applied to all IT staff on the first floor, or cn=Bob
Alice, ou=it_staff, dc=dev, dc=example, dc=com if the policy is only to be applied
to Bob Alice.

Prisma Access Administrator’s Guide (Panorama Managed) 372 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

Redistribute User-ID Information Between Prisma

Access and On-Premises Firewalls
After you configure User-ID, you consistently enforce user-based policy for all mobile users and
users at remote network locations by redistributing the IP address-to-user name mapping from
Prisma Access to all next-generation firewalls that secure access to network resources.
Use one the following methods to redistribute IP address-to-user name mapping to mobile users
and users in remote networks from an on-premises next-generation firewall and vice versa:
• Redistribute User-ID Information From Prisma Access to an On-Premise Firewall
• Redistribute User-ID Information From an On-Premises Firewall to Prisma Access

Redistribute User-ID Information From Prisma Access to an On-

Premise Firewall
In cases where mobile users need to access a resource on a remote network location or HQ/
data center and the resource is secured by an on-premises next-generation firewall with user-
based policies, you must redistribute IP address-to-user name mapping from the Prisma Access
mobile users and users at remote networks to the on-premises firewall. When the user connects
to Prisma Access, it collects this user-to-IP address mapping and stores it.
The following figure shows two mobile users that have an existing IP address-to-username
mapping in Prisma Access. Prisma Access then redistributes this mapping by way of a either a
service connection (SC-CAN) or remote network connection (RN-SPN) to the on-premises firewall
that secures the HQ/data center.

Prisma Access uses the service connection or remote network connection as an IPSec
tunnel that serves as the underlay path to the Layer 3 network. You can use any route
path over an IPSec trusted tunnel for privately addressed destinations to redistribute this
mapping.

Prisma Access Administrator’s Guide (Panorama Managed) 373 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

To redistribute User-ID mappings from Prisma Access to an on-premises firewall, complete the
following steps.

Make sure you do not apply any SSL decryption on any connection that redistributes user
identity to the on-premises firewall (the SC-CAN or RN-SPN), including any firewalls that
are in the redistribution path. Alternatively, you can apply a decryption exclusion to the
redistribution traffic.

Prisma Access Administrator’s Guide (Panorama Managed) 374 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

STEP 1 | Make a note of the IP address to use when you configure the data redistribution agent.
• For remote network connections, find the EBGP Router address (Panorama > Cloud
Services > Status > Network Details > Remote Networks > EBGP Router).

• For service connections, find the User-ID Agent Address (Panorama > Cloud Services >
Status > Network Details > Service Connection > User-ID Agent Address).

Prisma Access Administrator’s Guide (Panorama Managed) 375 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

STEP 2 | Configure Prisma Access as a User-ID agent that redistributes user mapping information.
1. In the Panorama that manages Prisma Access, select Device > Data Redistribution >
Collector Settings.
To configure the collector on a service connection, select the Service_Conn_Template;
to configure the collector on a remote network connection, select the
Remote_Network_Template
2. Click the gear icon to edit the settings.
3. Provide a Collector Name and a Collector Pre-Shared Key to identify Prisma Access as a
User-ID agent.
4. Click OK to save your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 376 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

STEP 3 | Configure the on-premises firewall to collect the User-ID mapping from Prisma Access.
1. From the on-premises firewall, select Device > Data Redistribution > Agents.
2. Add a User-ID Agent and give it a Name.
3. Select Host and Port.
4. Enter the User-ID Agent Address (for a service connection) or EBGP Router Address (for
a remote network connection) from Prisma Access in the Host field.
5. Enter the Collector Name and Collector Pre-Shared Key for the Prisma Access collector
you created in Step 2.
6. Select IP User Mappings.
7. Click OK.
8. Repeat these steps for each service connection or remote network connection for which
you want to redistribute mappings.

Redistribute User-ID Information From an On-Premises Firewall to

Prisma Access
In cases where users are at a branch location or HQ that is secured by an on-premises next-
generation firewall with user-based policies, and they need to access resources at another branch
location that you have secured with Prisma Access, you must redistribute IP address-to-user name
mappings from the on-premises firewall to Prisma Access.
The following figure shows an HQ/Data center with an on-premises next-generation firewall
with existing IP address-to-username mapping. Prisma Access connects to the firewall with either
a service connection (SC-CAN) or remote network connection (RN-SPN), and the on-premises
firewall redistributes the mapping to Prisma Access.

Prisma Access Administrator’s Guide (Panorama Managed) 377 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

The following figure shows a Prisma Access service connection or remote network connection
being used to redistribute the mapping. You can use any route path over an IPSec trusted tunnel
for privately addressed destinations to redistribute this mapping.

To redistribute User-ID mappings from an on-premises firewall to Prisma Access, complete the
following steps.
STEP 1 | Configure the on-premises firewall to redistribute User-ID information to Prisma Access.
1. From the on-premises firewall, select Device > Data Redistribution > Collector Settings.
2. Click the gear icon to edit the settings.
3. Provide a Collector Name and a Collector Pre-Shared Key to identify the on-premises
firewall as a User-ID agent.
4. Click OK to save your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 378 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

STEP 2 | Configure Prisma Access to collect the User-ID mapping from the on-premises firewall.
1. From the Panorama that manages Prisma Access, select Device > Data Redistribution >
Agents.
Make sure that you have selected the Service_Conn_Template (for service connections)
or the Remote_Network_Template (for remote network connections) in the Templates
drop-down at the top of the page.
2. Add a User-ID Agent and give it a Name.
3. Select Host and Port.
4. Enter the IP address of the MGT interface or service route that the firewall uses to send
user mappings in the Host field.
For the MGT interface, you can enter a hostname instead of the IP address.
5. Enter a Port.
The default port is 5007.
6. Enter the Collector Name and Collector Pre-Shared Key, using the values for the
collector you used for the on-premises firewall in Step 1.
7. Select IP User Mappings.
8. Click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 379 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Configure User-ID and User-Based Policies with Prisma Access

Prisma Access Administrator’s Guide (Panorama Managed) 380 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma
Access
Quality of Service ( QoS) is a set of technologies that work on a network to guarantee its ability
to dependably run high-priority applications and traffic under limited network capacity. You
can configure QoS in Prisma Access to prioritize business-critical traffic or traffic that requires
low latency, such as VoIP or videoconferencing. You can also reserve a minimum amount of
bandwidth for business-critical applications.
Prisma Access uses the same QoS profiles and supports the same Differentiated Services
Code Point (DSCP) markings as next-generation Palo Alto Networks firewalls. However, the
configuration process is different than configuring QoS on next-generation firewalls, in particular
when your deployment allocates bandwidth by compute location.
Prisma Access can either mark ingress traffic using a security policy or it can honor DSCP
markings set by your organization's on-premises device.
Prisma Access for Clean Pipe also supports QoS.
Use the following sections to learn how QoS works, including examples, and how to configure it.
• QoS Examples
• Configure QoS in Prisma Access
• QoS for Remote Networks
• Configure Quality of Service in Prisma Access
• Configure Quality of Service for Clean Pipe

381
Quality of Service in Prisma Access

QoS Examples
The following examples show how Prisma Access marks and shapes traffic.
In the following example, the administrator created a security policy on the
Mobile_User_Device_Group to mark incoming mobile user traffic. These policies assign traffic an
IP precedence value of AF11.
The administrator also created QoS profiles with QoS policy rules, enabled QoS on the service
connection and remote network connection, and applied the profiles to those connections to
shape the traffic at the traffic’s egress point based on the QoS markings.

Prisma Access marks traffic at its ingress point based on security policies or honors
marking set by your on-premises devices, and shapes the traffic on egress to your service
connections or remote network connections using QoS profiles.

The following example shows the QoS traffic flow from a branch office to an HQ/data center.
The administrator creates a security policy on the Remote_Network_Device_Group to mark the
incoming traffic from the remote network connection and enabled QoS and applied a QoS profile
on the service connection to shape the outgoing traffic.

Prisma Access Administrator’s Guide (Panorama Managed) 382 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

The following example shows a hybrid deployment with an on-premises firewall at a branch that
is connected by Prisma Access with a remote network connection, and the on-premises firewall
marks the traffic. This deployment honors the marking set on the on-premises firewall. You must
enable QoS and apply a QoS profile on the service connection, so that Prisma Access can shape
the traffic at egress.
Prisma Access honors all DSCP marking from the on-premises device as long as that traffic does
not match an overriding security policy on Prisma Access.

The following example shows a Prisma Access for Clean Pipe Overview configuration that shapes
on ingress (from the internet to Clean Pipe side). See Configure Quality of Service for Clean Pipe
for configuration details.

Prisma Access Administrator’s Guide (Panorama Managed) 383 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

Prisma Access Administrator’s Guide (Panorama Managed) 384 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

Configure QoS in Prisma Access

Use the following workflow to configure QoS in Prisma Access. See Configure Quality of Service
in Prisma Access for the detailed steps.
STEP 1 | Mark the ingress traffic using a security policy or using marking from an on-premises device.
You can create PAN-OS security policies to mark traffic destined to Prisma Access for mobile
users and for remote network connections. For service connections, Prisma Access will honor
traffic marking from your organization’s on-premises devices. Optionally, you can also use on-
premises devices to mark traffic for remote networks.

To ensure predictable results, we recommend marking traffic using either security

policies in Prisma Access or your on-premises device, but not both. If there are
differences between the security policies in Prisma Access and the on-premises device,
the security policy in Prisma Access overrides the policy in the on-premises device.

STEP 2 | Map the traffic to classes using a QoS policy rule.

STEP 3 | Shape the traffic using a QoS profile.

You can create QoS profiles to shape QoS traffic for service connections and for remote
network connections and apply those profiles to traffic that you marked with PAN-OS security
policies, traffic that you marked with an on-premises device, or both PAN-OS-marked and on-
premise-marked traffic.

STEP 4 | Enable QoS on the service connection or remote network connection and bind the QoS
profile to the connection.
The following figure shows the available QoS deployments in Prisma Access.

Prisma Access Administrator’s Guide (Panorama Managed) 385 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

QoS for Remote Networks

New Prisma Access deployments onboard bandwidth for remote networks by compute location.
To use QoS with remote networks, you enable or disable QoS and specify the guaranteed
bandwidth at the compute location level. However, you can still tailor QoS and guaranteed
bandwidth at a per-location level by customizing bandwidth per site.

QoS for Remote Networks Using Guaranteed Bandwidth and

Bandwidth Allocation Ratios
Prisma Access divides compute location bandwidth using IPSec Termination Nodes. Each IPSec
termination node can provide you with a maxmum of 1,000 Mbps of bandwidth. If you allocate
more than 1,000 Mbps of bandwidth to a compute location, Prisma Access provides you with
additional IPSec termination nodes.

The QoS settings you specify here apply only to outbound traffic for remote networks, and
do not affect secure inbound access traffic.

In the following example, you have allocated 1500 Mbps bandwidth in the Canada Central
compute location, which is the compute location for the Canada Central and Canada East
locations.

Since you allocated 1500 Mbps for the compute location, Prisma Access gives you two IPSec
termination nodes.
You should now determine whether you want to allocate your locations to the same IPSec
termination node, or to use separate IPSec termination nodes. If you expect you will add more
remote network locations to this compute location, you could leave one IPSec termination node
available to onboard more remote networks at a later time.
For this example, you onboarded two remote networks, also known as Remote Network Security
Processing Nodes (RN-SPNs), one in Canada East (RN-8) and one in Canada Central (RN-9), using
the same IPSec termination node for both locations.

You Enable QoS in the QoS area by selecting Panorama > Cloud Services > Configuration >
Remote Networks > Settings, clicking the gear to edit the settings, selecting QoS, and enabling

Prisma Access Administrator’s Guide (Panorama Managed) 386 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

QoS for the Canada Central compute location. See Configure Quality of Service in Prisma Access
for the detailed steps.
In this example, you want the compute location to receive a guaranteed bandwidth ratio of
60%; to do so, enter a Guaranteed Bandwidth Ratio of 60% to the Canada Central compute
location. This action reserves 900 Mbps (60% of the overall bandwidth allocation) for guaranteed
bandwidth.

Prisma Access divides up the guaranteed bandwidth equally between IPSec termination nodes;
therefore, each IPSec termination node receives 450 Mbps of guaranteed bandwidth (900 Mbps
divided by the total number of IPSec termination nodes). When you select Customize Per Site,
you can view the bandwidth that is allocated for each location. By default, the Allocation Ratio
is divided equally between all remote networks in an IPSec termination node. In the following
example, since there are two remote networks in the IPSec termination node, each remote
network receives an Allocation Ratio of 50%.

If you select Customize Per Site and then onboard additional remote networks in the same
IPSec termination node, the newly-onboarded sites receive an allocation ratio of 0, and
you must manually rebalance the allocation ratio between existing sites and the newly-
onboarded site.
If you do not Customize Per Site, the bandwidth percentage automatically rebalances
when you add remote networks. For example, if you did not select Customize Per Site and
have four remote networks onboarded, each of those remote networks have an allocation
ratio of 25%. If you add a fifth remote network, all five sites rebalance and receive a
guaranteed bandwidth of 20%.

Change the Guaranteed Bandwidth For Remote Networks

If you have multiple remote network locations that are associated to one IPSec termination node,
you can change the guaranteed bandwidth for each site. In the following example, you want the

Prisma Access Administrator’s Guide (Panorama Managed) 387 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

Canada East location to receive more bandwidth then the Canada Central location; to do so,
complete the following steps.
STEP 1 | Select Panorama > Cloud Services > Configuration > Remote Networks > Settings.

STEP 2 | Click the gear to edit the settings and select QoS.

STEP 3 | Enable QoS, assign a QoS Profile (Default-Profile in this example) and a Guaranteed
Bandwidth Ratio to the Canada Central compute location.

Prisma Access Administrator’s Guide (Panorama Managed) 388 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

STEP 4 | Select Customize Per Site, enable Customize Per Site, then apply a higher bandwidth
Allocation Ratio for the RN-8 remote network (for the Canada East location) than the RN-9
remote network (for the Canada Central location).
The following example shows an Allocation Ratio of 70% for RN-8 and 30% for RN-9. The
Guaranteed Bandwidth (Mbps) changes accordingly, showing the new guaranteed bandwidth
amounts.

When complete, your configuration has the following guaranteed bandwidth allocation for the
two sites.

If you have a remote network that has ECMP enabled to use multiple IPSec tunnels for a single
remote network, you can change the Allocation Ratio for the IPSec tunnels you use for that
remote network location.

Prisma Access Administrator’s Guide (Panorama Managed) 389 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

STEP 5 | Save and Commit your changes.

The guaranteed bandwidth values display in the Panorama > Cloud Services > Status >
Monitor > Remote Networks area, in the Guaranteed Mbps area. If you did not specify a
bandwidth, it displays as 0.

Select QoS Profiles for Remote Networks

You can also assign different QoS profiles per remote network location.
To assign different profiles, enable the Customize Per Site capability, and select different QoS
profiles for each remote network location.

Prisma Access Administrator’s Guide (Panorama Managed) 390 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

When complete, the locations have the following QoS profiles attached.

Prisma Access Administrator’s Guide (Panorama Managed) 391 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

Configure Quality of Service in Prisma Access

Configure Quality of Service in Prisma Access by completing the following task.
STEP 1 | Add one or more security policy rules for remote networks and mobile users to mark the
ingress traffic for QoS.
You use these policies to match a traffic flow and assign it a selected DSCP value.
1. Select Policies > Security > Pre Rules.
Alternatively, select Policies > Security > Post Rules to add a rule at the bottom of the
rule order that is evaluated after a pre-rule.

Be sure that you select the correct Device Group. To create a security rule for a
remote network, select the device group for the remote network (for example,
Remote_Network_Device_Group); for mobile users, select the device group for
the mobile users (for example, Mobile_User_Device_Group).
2. Add a security policy rule.
3. Enter a Name for the rule.
4. Define the matching criteria for the source or destination fields in the packet.
See Create a Security Policy Rule for details.
5. Click Actions, then select a QoS Marking of either IP DSCP or IP Precedence.
6. Enter the QoS value in binary form, or select the value from the drop-down.
The following screenshot shows a security policy rule that matches traffic marked with
an IP DSCP value of af11.

Prisma Access Administrator’s Guide (Panorama Managed) 392 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

STEP 2 | Add one or more QoS policy rules.

You use QoS policies to bind DSCP marking to one of eight available classes. You use these
classes later when you create one or more QoS profiles.
1. Select Policies > QoS > Pre Rules.
Alternatively, use Post Rules (Policies > QoS > Post Rules) to add a rule at the bottom of
the rule order that is evaluated after a pre-rule.

Service connections do not support QoS Post Rules; use Pre Rules only with
Service Connections.

Be sure that you select the correct Device Group for the service connection (for
example, Service_Conn_Device_Group) or remote network connection (for example,
Remote_Network_Device_Group). If a rule in a Shared device group has defined values
other than the values in the General, DSCP/ToS, and Other settings areas, Prisma
Access does not apply the rule on the remote network and service connection.
2. Add a QoS policy rule.
3. Click General and enter a name for the policy rule.
4. Click the DSCP/ToS tab, then click Codepoints and Add one or more new codepoints.
For Clean Pipe deployments, you can specify additional QoS settings in policy, such as
source, destination, or application.
5. Specify a Name for the DSCP/ToS rule, then select a Type and Codepoint.

Alternatively, keep the default value (Any) to allow the policy to match to traffic
regardless of the Differentiated Services Code Point (DSCP) value or the IP Precedence/
Type of Service (ToS) defined for the traffic.
6. Click the Other Settings tab, then Choose the QoS Class to assign to the rule.
You define class characteristics in the QoS profile.
7. Click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 393 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

STEP 3 | Create one or more QoS profiles to shape QoS traffic on egress for service connections and
remote network connections.
You use profiles to shape the traffic at egress point by defining QoS classes and assigning a
bandwidth to them. You must select either an existing QoS profile or create a new QoS profile
when you enable QoS for Prisma Access.
1. Select the correct template the profile you want to create (Remote_Network_Template
or Service_Conn_Template); then, select Network > Network Profiles > QoS Profile and
2. Add a profile.
3. Enter a profile Name.
4. Set the overall bandwidth limits for the QoS profile rule.
• Enter an Egress Max that represents the maximum throughput (in Mbps) for traffic
leaving the service connection or remote network connection.
• For service connections, specify a number of up to 1 Gbps (1,000 Mbps).

Do not enter a number greater than 1 Gbps; Prisma Access calculates

service connection bandwidth per service connection IPSec tunnel and not
cumulatively across multiple tunnels.
• For remote network connections, enter a value of 0.
• Enter an Egress Guaranteed value. bandwidth that is the guaranteed bandwidth for
this profile (in Mbps).
• For service connections, enter an Egress Guaranteed bandwidth that is the
guaranteed bandwidth for this profile (in Mbps).
Any traffic that exceeds the Egress Guaranteed value is best effort and not
guaranteed. Bandwidth that is guaranteed but is unused continues to remain
available for all traffic.
• For remote network connections, enter a value of 0.
5. In the Classes section, Add one or more classes and specify how to mark up to eight
individual QoS classes.
• For QoS profiles used by remote networks that allocate bandwidth by compute
location, change the Class Bandwidth Type to Percentage and enter percentages for
the Egress Max and Egress Guaranteed values you enter in this area.
• For QoS profiles used by service connections or by remote networks that allocate
bandwidth by location, specify a type of Mbps.
• Select the Priority for the class (either real-time, high, medium, or low).
• Enter the Egress Max for traffic assigned to each QoS class you create.
• For remote networks that allocate bandwidth by compute location, enter 0.
• For bandwidth-based QoS profiles (used by service connections or remote
networks that allocate bandwidth by location), enter a value in Mbps. The Egress

Prisma Access Administrator’s Guide (Panorama Managed) 394 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

Max for a QoS class must be less than or equal to the Egress Max for the QoS
profile.
• Enter the Egress Guaranteed percentage or bandwidth in Mbps for each QoS class.
For QoS profiles for remote networks, enter a percentage.
Guaranteed bandwidth assigned to a class is not reserved for that class—bandwidth
that is unused continues to remain available to all traffic. When a class of traffic
exceeds the egress guaranteed bandwidth, Prisma Access passes that traffic on a
best-effort basis.
• Enter a Class Bandwidth Type for the profile.

6. Click OK.

STEP 4 | (Service Connections Only) Enable QoS for the service connection and apply the QoS profile
to the connection.
1. Enable QoS by selecting Panorama > Cloud Services > Configuration > Service Setup,
selecting a Connection Name, clicking the QoS tab; then Enable QoS.
If you allocate your remote network bandwidth by Prisma Access Remote Network
Deployments instead of by compute location, configure QoS in the same way as you
do service connections. Select Panorama > Cloud Services > Configuration > Remote
Networks, select the hypertext for a remote network connection Name, click the

Prisma Access Administrator’s Guide (Panorama Managed) 395 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

QoS tab, and Enable QoS. If you allocate bandwidth by compute location (the default
method), continue to Step 5 to configure QoS for remote networks.
2. Select a QoS profile and click OK.

STEP 5 | (Remote network deployments that allocate bandwidth by compute location only) Enable
QoS for your remote network locations.
1. Determine the Prisma Access locations where you want to deploy QoS; then find the
compute location that corresponds to each location.
Each location is allocated bandwidth from its compute location, and you must know the
name of the compute location for the locations where you want to allocate QoS. For a
list of compute location-to-location mapping, see Prisma Access Locations by Compute
Location, or select Panorama > Cloud Services > Configuration > Remote Networks

Prisma Access Administrator’s Guide (Panorama Managed) 396 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

> Aggregate Bandwidth and click the gear icon; the mappings display in the Compute
Location and Prisma Access Location columns.
2. Select Panorama > Cloud Services > Configuration > Remote Networks > Settings, click
the gear to edit the settings, and select QoS.
3. Enable QoS at a compute location level.
Whatever settings you enter apply to all locations that correspond to this compute
location.
4. Enter the QoS Profile, Guaranteed Bandwidth Ratio, and Reserved for Guaranteed
Bandwidth (Mbps).
• Enter the QoS Profile to use with this compute location.
If you want to use different QoS Profiles per remote networks, use Customize Per
Site as described in a later step.
• Enter the Guaranteed Bandwidth Ratio, which is a ratio based on the entire allocated
bandwidth for the compute location.
For example, If you have allocated bandwidth of 800 Mbps for the Canada Central
compute location, and you enter a Guaranteed Bandwidth Ratio of 60%, the
guaranteed bandwidth for that compute location is 480 Mbps.
• Enter the amount of bandwidth that is Reserved for Guaranteed Bandwidth (Mbps)
for the QoS profile and compute location you selected.
The following screenshot shows QoS enabled for the Canada Central, Ireland, and South
Korea compute locations.

5. (Optional) if you have multiple remote network connections per compute location and
want to change either the bandwidth ratio or QoS profile for each location, onboard your

Prisma Access Administrator’s Guide (Panorama Managed) 397 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

remote network locations; then, select Customize Per Site and change the bandwidth
allocation ratio, QoS profile, or both.
• To customize the guaranteed bandwidth, click the number in the Customize Per Site
area, select Customize Per Site, and change the Allocation Ratio.
By default, each remote connection is given a percentage that is equal to the number
of connections. For example, given 4 connections in a compute location and a total
guaranteed bandwidth of 100 Mbps, each location receives 25% of that bandwidth or
25 Mbps.

If you select Customize Per Site and then onboard additional remote
networks in the same IPSec termination node, the newly-onboarded sites
receive an allocation ratio of 0, and you must manually rebalance the
allocation ratio between existing sites and the newly-onboarded site.
If you do not Customize Per Site, the bandwidth percentage automatically
rebalances when you add remote networks. For example, if you did not select
Customize Per Site and have four remote networks onboarded, each of those
remote networks have an allocation ratio of 25%. If you add a fifth remote
network, all five sites rebalance and receive a guaranteed bandwidth of 20%.
• If you want to specify a QoS profile at a per-remote network level, select a different
QoS Profile for the remote network.

Prisma Access Administrator’s Guide (Panorama Managed) 398 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

STEP 6 | Check the QoS status.

• For remote networks, select Panorama > Cloud Services > Status > Monitor > Remote
Networks, select a region from the map, select QoS, then select a location.

Remote network statistics display for the 10 IPSec termination nodes that have the
highest throughput. Prisma Access uses the 95th percentile standard to gather statistics,

Prisma Access Administrator’s Guide (Panorama Managed) 399 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

which tracks bandwidth at peak utilization and ignores the top 5 percent of utilization
peaks and large bursts.
Select the time range (Last hour, Last 24 hours, Last 7 days, or Last 30 days) to view
statistics for that time period.

The remote networks with the highest egress bandwidth usage displays in the Site area,
along with the remote networks locations’ statistics for Guaranteed Bandwidth, Average

Prisma Access Administrator’s Guide (Panorama Managed) 400 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

Throughput, Average Packet Loss, and the IPSec Termination Node and QoS Profile used
by the remote network. You can also Search for a location.
To view the remote networks associated with a specific IPSec termination node, change
the drop-down at the top of the page from All to a specific IPSec termination node to
view statistics for that IPSec termination node and the remote networks for that site.

To view specific traffic for a site sorted by QoS class, slick the Site Name. The guaranteed
bandwidth, egress throughput, and throughput over time displays for the remote network

Prisma Access Administrator’s Guide (Panorama Managed) 401 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

site. You can also sort this information over the last hour, last 24 hours, last 7 days, or last
30 days.

Hover over the graph on the right to get detailed information for a specific period of time.

• For service connections, select Panorama > Cloud Services > Status > Monitor > Service
Connection, select a region, then Monitor the Statistics.
Click QoS to view a page with QoS statistics.

Prisma Access Administrator’s Guide (Panorama Managed) 402 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

This page displays a chart with real-time and historical QoS statistics, including the number of
dropped packets per class. This chart displays only for service connections or remote network

Prisma Access Administrator’s Guide (Panorama Managed) 403 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

connections that have QoS enabled, shows the last five minutes of the connection’s network
activity, and refreshes every 10 seconds.
The following figure shows traffic being passed for classes 1,2,3, and 4. The data below the
figure shows the number of packets dropped based on the QoS configuration for classes 2, 3,
and 4.

Prisma Access Administrator’s Guide (Panorama Managed) 404 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

Configure Quality of Service for Clean Pipe

For Clean Pipe deployments, you can create QoS policies to define the traffic that receives QoS
treatment and QoS profiles to define the classes of service, including priority, that the traffic can
receive. You can define QoS based on DSCP values or zones (Trust or Untrust). To implement
QoS with Clean Pipe, select the QoS Profile when you onboard the Clean Pipe. See Configure
Prisma Access for Clean Pipe for details.

Prisma Access Administrator’s Guide (Panorama Managed) 405 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Quality of Service in Prisma Access

Prisma Access Administrator’s Guide (Panorama Managed) 406 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in
Prisma Access
To allow you to create and manage multiple Prisma Access instances, Prisma Access offers
multitenancy, which enables you to create up to 200 instances (tenants) on a single Panorama
appliance (or 2 appliances in high availability (HA) mode), with each tenant having their own
separate templates and template stacks, device groups, and access domains.
Existing or future non-multitenant deployments are not affected by multitenancy and will
continue to function normally. We recommend that you enable multitenancy only if your
organization has a need to manage multiple tenants in Prisma Access.
Follow this workflow to create multiple tenants in Panorama for Prisma Access:
• Multitenancy Overview
• Multitenancy Configuration Overview
• Plan your Multitenant Deployment
• Enable Multitenancy and Migrate the First Tenant
• Add Tenants to Prisma Access
• Delete a Tenant
• Create Administrative Users for a Single Tenant
• Control Role-Based Access for Tenant-Level Administrative Users
• Sort Logs by Device Group ID for External Logging
This section only provides the tasks you perform to configure tenants for remote networks,
mobile users, or a combination of remote network and mobile user deployments. To configure the
Clean Pipe service, see Create and Configure Prisma Access for Clean Pipe.

407
Manage Multiple Tenants in Prisma Access

Multitenancy Overview
Enabling multitenancy allows you to host multiple instances of Prisma Access on a single
Panorama appliance. Each instance is known as a Tenant.
Prisma Access tenants get their own dedicated Prisma Access instances and they are not shared
between tenants.

Prisma Access Administrator’s Guide (Panorama Managed) 408 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Multitenancy Configuration Overview

Use the following workflow to configure the ability to manage multiple tenants in a single
Panorama appliance.
STEP 1 | Enable multitenancy. If you have an existing Prisma Access instance, enabling multitenancy
automatically migrates your existing Prisma Access configuration to the first tenant.
You give the first (migrated) tenant a name and specify an access domain. Prisma Access
migrates the templates, template stacks, and device groups associated with the existing
configuration and associates them with the access domain you create.
After you migrate your initial configuration, the administrative user in Panorama becomes a
superuser with the ability to create and manage all Prisma Access tenants.

Prisma Access Administrator’s Guide (Panorama Managed) 409 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 2 | Then, add tenants to Prisma Access.

To deploy multiple tenants, make sure that you have the following license minimums:

To determine the type of Prisma Access license you have from Panorama, select
Panorama > Licenses. See Determine Your Prisma Access License Type from
Panorama for details.

• If you have a Business, Business Premium, Zero Trust Network Access (ZTNA) Secure
Internet Gateway (SIG), or Enterprise license, use the following minimums as a guideline:
Prisma Access for Networks and Prisma Access for Users:
If you have a Local Edition, a minimum quantity of 200 units is required for each tenant, and
all tenants will be Local.
If you have a Worldwide Edition, a minimum quantity of 1,000 units is required to create a
Worldwide tenant. If you allocate between 200 and 999 units for a tenant, Prisma Access
creates a Local tenant; if you allocate 1,000 or more units for a tenant, then Prisma Access
creates a Worldwide tenant.
Units correspond to bandwidth in Mbps for Prisma Access for Remote Networks and the
number of mobile users for Prisma Access for Users.
• If your license type starts with GlobalProtect Cloud Service, use the following minimums as
a guideline:
Prisma Access for Networks—You must have a minimum of 200 Mbps available in your
license for each tenant.
Prisma Access for Users—You must have a minimum of 200 mobile users available in your
license for each tenant.
In both types of Prisma Access configurations, you can add additional licensing (above
these minimums) of either type. You can increase or decrease the bandwidth or mobile
user allocation for any tenants after onboarding, as long as you keep the minimum required
allocation per tenant, and the overall licensed capacity is not exceeded.
You can set up a multitenant configuration for only remote networks, only mobile users, or
both. You allocate licenses accordingly to each tenant when you enable multitenancy.
If you have a license for remote networks and mobile users, you can set up an individual
tenant with only mobile users or only remote networks. For example, if your Prisma Access
deployment has a Worldwide edition license for mobile users and remote networks, you could
set up a tenant for mobile users only, as long as you specify a minimum of 1,000 mobile users
for the tenant.
For each tenant you create after the first, Prisma Access automatically creates templates,
template stacks, and device groups for each tenant and associates them to the access domain
you create. Prisma Access creates this environment to allow you to create a tenant-level
administrative user using an administrative role based on the tenant’s device groups and
templates, then creating an administrative user based on that role. In this way, you create an

Prisma Access Administrator’s Guide (Panorama Managed) 410 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

administrative user that has access to a single tenant without allowing that user access to the
other tenants that are managed by the Panorama appliance.
Prisma Access creates template stacks, templates, and device group using the following naming
convention:
• A service connection template stack with the name of sc-stk-tenant, where tenant is the
tenant’s name.
• A service connection template with the name of sc-tpl-tenant.
• A service connection device group with the name of sc-dg-tenant.
• A mobile user template stack with the name of mu-stk-tenant.
• A mobile user template with the name of mu-tpl-tenant.
• A mobile user device group with the name of mu-dg-tenant.
• A remote network template stack with the name of rn-stk-tenant.
• A remote network template with the name of rn-tpl-tenant.
• A remote network device group with the name of rn-dg-tenant.
• An Explicit Proxy template stack with the name of ep-stk-tenant.
• An Explicit Proxy template with the name of ep-tpl-tenant.
• An Explicit Proxy device group with the name of ep-dg-tenant.
• A Clean Pipe template stack with the name of cp-stk-tenant.
• A Clean Pipe template with the name of cp-tpl-tenant.
• A Clean Pipe device group with the name of cp-dg-tenant.
Template stacks, templates, and device groups are created for all Prisma Access types, even
those for which you might not be licensed. For example, if you purchase a license for remote
networks, Prisma Access automatically creates template stacks, templates, and device groups
for remote networks, mobile users, and Clean Pipe.
If you add custom templates, they cannot take precedence over the Prisma Access-created
templates.
You allocate remote network and mobile user license resources for each tenant based on the
license that is associated with the Cloud Services plugin in Panorama.
The following figure shows a sample Prisma Access deployment using a license with a
20,000 Mbps remote network bandwidth pool and 20,000 mobile users. The administrator
allocated 5,000 Mbps in remote network bandwidth and 5,000 mobile users for the existing
configuration. After the administrator enabled multitenancy, the license allocation migrated
along with all other configuration to the first tenant. The administrator then created additional
tenants, each with a 5,000 Mbps bandwidth pool for remote networks and 5,000 mobile
users for each tenant. Prisma Access allocates the license resources from the overall license

Prisma Access Administrator’s Guide (Panorama Managed) 411 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

allocation. After you complete this configuration, there is 5,000 Mbps of remote network
bandwidth and 5,000 mobile users available in the license.

Prisma Access Administrator’s Guide (Panorama Managed) 412 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Plan Your Multitenant Deployment

Before you enable multitenancy, migrate the first tenant, and create additional tenants, make sure
that you have all required information and resources to do so by completing the following tasks:
If you are migrating an existing single-tenant deployment to a multitenant deployment, make
a note of the following Prisma Access features that are not supported. See the Palo Alto
Networks Compatibility Matrix for the list of unsupported features.
If don’t have an existing Prisma Access configuration, you Enable Multitenancy and add
your tenants; then, then configure the tenants after you create them. See Create an All-New
Multitenant Deployment for more information.
Make a note of your license allocation for remote networks and mobile users.
Open your license (Panorama > Licenses) and find the Prisma Access Total Mbps (remote
networks bandwidth pool) for remote networks and User Limit (total number of licensed users)
for mobile users.
When you create tenants, you assign resources for remote networks and mobile users from
this license allocation. If you run out of the minimum required licensed Mbps for remote
networks or mobile users, you cannot create additional tenants.

You should also make a note of the bandwidth and mobile users allocation for your
existing configuration. After you migrate your configuration to the first tenant, check
these values to verify that the first tenant migrated correctly.
Make a list of the names you will use to identify each tenant.

When you create tenant names, avoid using names like Tenant-1, Tenant-2, Tenant-3,
and so on. The system logs reserve a small number of characters for the tenant name
in the log output and, if tenants have similar names, it can be difficult to associate the
tenant with the logs. We recommend using a unique and short name for tenants (for
example, Acme or Hooli).
Make a list of the administrative users you will create and assign for each tenant, and note the
maximum number of administrative users that can be logged in concurrently.
When administrative users are performing normal multitenant operations such as configuration
changes and commit operations, we recommend having a maximum of 12 administrative users
logged in to Panorama concurrently.
An administrative user who can manage multiple tenants can provision up to 200 tenants at
the same time with a single commit operation.
Be sure that you have sufficient license resources to enable multiple tenants.
The minimum license allocation for each tenant is 200 Mbps for each remote network or 200
mobile users. You can also create a tenant with only remote networks or mobile users, and can
configure tenants in differing configurations on the same Panorama. For example, you could
create a tenant with remote networks only, a tenant with mobile users only, or a tenant with
both mobile users and remote networks, as long as each tenant meets the minimum license
allocation and the relevant licenses are activated and associated with the Panorama where you
configure the tenants.

Prisma Access Administrator’s Guide (Panorama Managed) 413 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

When configuring a tenant in multitenancy mode, create a unique name for each IPSec tunnel
and IKE gateway for service connections and remote network connections, and try to use a
name that will not be duplicated by another tenant. While there is no effect to functionality,
you cannot delete an IPSec tunnel or IKE gateway if another tenant is using a tunnel or
gateway with the same name.
This caveat applies to all objects, including QoS profiles (you cannot delete objects with
duplicate names in a multi-tenant deployment if one of the objects is being referenced by
another tenant).
Single-tenant users cannot view system logs; only superusers can. You can, however, sort logs
by tenant.
When a mobile user logs into a single Prisma Access tenant, the user consumes one license
unit. If a user logs into additional tenants under a single multitenant deployment, the user
consumes one license unit for each tenant they are logged in. For example, if a single user is
logged into five tenants, the user consumes five mobile user license units in total.
When using the multitenancy feature and logged in as a tenant-level administrative user,
opening the Panorama Task Manager (clicking Tasks at the bottom of the Panorama web
interface) shows all tasks for all tenants, including any tasks done at the superuser (Admin)
level.
Some Prisma Access features are not supported for use with multitenancy. See Multitenancy
Unsupported Features in the Palo Alto Networks Compatibility Matrix for details.
If you back up a Panorama configuration, then revert it to an earlier saved configuration,
Panorama cannot revert to the configuration you saved if you perform the following actions in
the following order:
1. Backup a Panorama configuration.
2. Delete a tenant.
3. Restore the configuration.
If you delete a tenant, you cannot use any of the previous backups you saved before you
deleted the tenant. However, you can use any backups you make after you delete the tenant.

Prisma Access Administrator’s Guide (Panorama Managed) 414 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Create an All-New Multitenant Deployment

If you want to create a multitenant deployment and don’t have an existing Prisma Access
configuration, you can Enable Multitenancy and add your tenants; then configure the tenants
after you create them.

If you have an existing single-tenant deployment and want to migrate to a multitenant

deployment, use the workflow to enable multitenancy and migrate the first tenant.

When you create the first tenant with no existing configuration, make sure of the following
differences and guidelines to follow:
• Since there is no configuration to move over, Prisma Access creates templates, template stacks,
and device groups for each tenant and associates them to the access domain you create during
tenant creation. See Multitenancy Configuration Overview for the naming convention that
Prisma Access uses.
• Optionally, after you create the tenant-level access domain, you could create an administrative
user that allows administration for a single tenant by associating an administrator with the
access domain.
• If you have any existing templates or device groups (for example, templates from an on-
premises device that is managed by Panorama that should also be used by Prisma Access),
be sure to add those device groups and templates domains to the Access Domain when you
create and configure it. If you do not add device groups and templates to the access domain,
you cannot view or select them when you configure the Prisma Access components in the
Cloud Services plugin.

Prisma Access Administrator’s Guide (Panorama Managed) 415 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Enable Multitenancy and Migrate the First Tenant

Use the following workflow to enable multitenancy and migrate your existing configuration to the
first tenant you create. If you don’t have any existing configuration, you can Enable Multitenancy
and add your tenants; then configure them.
When you enable multitenancy, Prisma Access migrates the following components of your
configuration:
• All service connection and remote network tunnel onboarding information, including tunnel
configuration.
• Existing mobile users onboarding information.
• Cortex Data Lake information.
• Existing Autonomous DEM (ADEM) configuration
• The templates, template stacks, and device groups for service connections, remote networks,
and mobile users.
You need to specify the number of users (for a mobile user deployment), bandwidth (for a remote
networks deployment), and Autonomous DEM (ADEM) to allocate for each deployment (if you
have purchased an ADEM license).
Because of these device group changes, you create an access domain and add the migrated device
groups, templates, and template stacks, as shown in the following workflow.

If you don’t have an existing Prisma Access configuration, and you are creating an all-new
multitenant deployment, do not use this workflow; instead, complete the steps in Add
Tenants to Prisma Access to create the first tenant.

STEP 1 | Determine the number of licensed units you want to allocate to this deployment.
While Prisma Access migrates your configuration to the first tenant, you need to specify:
• The Bandwidth to allocate for the tenant’s remote users deployment (if applicable).
• The Users to allocate for the tenant’s mobile users deployment (if applicable).
• The number of ADEM units to allocate for mobile uses and remote networks (if applicable).

STEP 2 | Select Panorama > Cloud Services > Configuration.

Prisma Access Administrator’s Guide (Panorama Managed) 416 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 3 | Select Enable Multitenancy (located on the upper right of the page).

After you enable multitenancy, Panorama displays a notification informing you that the
existing Prisma Access configuration are moved to the first tenant.

After you enable multitenancy, your deployment permanently changes to a

multitenant deployment, and you cannot revert to single tenant mode.

STEP 4 | Click OK to migrate the existing configuration to the first tenant.

The Tenants page displays, and pie charts in the center of the window display.
• If you have a remote networks or mobile users license, the available amount of licensed
remote network bandwidth and mobile users display.
• (Remote Networks and Mobile User Deployments Only) If you have purchased an
Autonomous DEM license, the available number of units for ADEM uses displays.
• If you have a Clean Pipe deployment, the amount of bandwidth for the tenant displays.

STEP 5 | Choose the type of deployment you want to use for the tenant.
• For a remote network, mobile user deployment, or to configure both deployment types for
a tenant, select Remote Networks/Mobile Users.
• For a clean pipe deployment, select Clean Pipe.
This section only describes how to configure tenants for remote network, mobile user,
or both remote network and mobile user deployment types. To configure the clean pipe
service, see Create and Configure Prisma Access for Clean Pipe.

Prisma Access Administrator’s Guide (Panorama Managed) 417 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 6 | Migrate the existing configuration to the first tenant.

1. Specify a Name for the first tenant.
2. Create a new Access Domain by clicking the down arrow selecting New Access Domain.
3. Enter a Name for the access domain and click OK.
Prisma Access adds the Mobile_User_Device_Group, Remote_Network_Device_Group,
and Service_Conn_Device_Group Device Groups to the new access domain.

4. (Optional) Click Templates to verify that Prisma Access added the following templates
and template stacks:
• Explicit_Proxy_Template

Prisma Access Administrator’s Guide (Panorama Managed) 418 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

• Explicit_Proxy_Template_Stack
• Mobile_User_Template
• Mobile_User_Template_Stack
• Remote_Network_Template
• Remote_Network_Template_Stack
• Service_Conn_Template
• Service_Conn_Template_Stack
These are the default template stacks and templates for a standard Prisma Access
deployment; if you added other templates, be sure that Prisma Access added them.

5. (Optional) If you have other templates associated with this configuration, select them.
6. Click OK to close the Access Domain page and return to the Tenants page.

Prisma Access Administrator’s Guide (Panorama Managed) 419 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 7 | Enter the values in Bandwidth (Mbps) for remote networks, Users for mobile users, and the
number of Autonomous DEM Users you want to allocate for each deployment type.
Use the following guidelines when allocating ADEM units for a tenant:
• The number of ADEM units you can allocate for mobile users and remote networks can be
only equal to or less than base license.
• The minimum number of units you can allocate is 200.
• After you allocate the ADEM units for a tenant, you can edit or remove those units.
• If you did not purchase an ADEM license for your deployment type (Mobile Users or
Remote Networks), that choice is grayed out.

STEP 8 | Click OK.

The Panorama > Cloud Services > Configuration page shows the first tenant successfully
migrated, and a Tenants drop-down is added above the Tenants area.

STEP 9 | Select the tenant you created in the Tenants drop-down to verify that all settings were
onboarded.

Prisma Access Administrator’s Guide (Panorama Managed) 420 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 10 | Select Commit > Commit to Panoramato save your changes locally on the Panorama that
manages Prisma Access.
If you do not perform a local commit, Prisma Access components do not display in the Push
Scope when you Commit and Push your changes.

STEP 11 | Commit and push your changes to make them active in Prisma Access.
1. Select Commit > Commit and Push and Edit Selections in the Push Scope.
2. Select Prisma Access, then select the tenant you created, Service Setup, Remote
Networks, and Mobile Users.

3. Click OK to save your changes to the Push Scope.

4. Commit and Push your changes.

STEP 12 | Select Panorama > Cloud Services > Status.

The status page shows the status of all tenants. Because you have created only one tenant,
that tenant is the only one that displays. If you select that tenant from the drop-down, you
show a detailed status of that tenant.

Selecting a tenant from the drop-down list returns you to the Status page for that tenant.

STEP 13 | Continue to add more tenants to Prisma Access.

Prisma Access Administrator’s Guide (Panorama Managed) 421 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Add Tenants to Prisma Access

After you migrate the existing information as a first tenant, you can create and configure
additional tenants. For each tenant you create after the first, Prisma Access creates a separate
access domain with its own set of template stacks and templates and its own domain groups.
Use this workflow to add more tenants to Prisma Access.

If you are creating an all-new multitenant deployment, use this workflow to add the first
tenant, as well as additional tenants. See Create an All-New Multitenant Deployment
for more information.

STEP 1 | Log in to Panorama as a superuser.

STEP 2 | Add and configure the tenant.

1. Select Panorama > Cloud Services > Configuration, then Add a new tenant.
Be sure that you select Remote Networks/Mobile Users; to create and configure a
Clean Pipe deployment, see Create and Configure Prisma Access for Clean Pipe.
2. Specify a descriptive Name for the tenant.
3. Add a new Access Domain, give it a descriptive Name, and click OK to return to the
Tenants window.
After you click OK, Prisma Access automatically creates templates, template stacks, and
device groups and associates them to the access domain you create.

STEP 3 | Specify the amount of Bandwidth (Mbps) to allocate for the Remote Networks and the
number of Users to allocate for the Mobile Users.

Prisma Access Administrator’s Guide (Panorama Managed) 422 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 4 | (Deployments with Autonomous DEM Only) If you have purchased an Autonomous DEM
(ADEM) license, select the number of units to allocate for ADEM.
Use the following guidelines when allocating ADEM units for a tenant:
• The number of ADEM units you can allocate for mobile users and remote networks can be
only equal to or less than base license.
• The minimum number of units you can allocate is 200.
• After you allocate the ADEM units for a tenant, you can edit or remove those units.
• If you did not purchase an ADEM license for your deployment type (Mobile Users or
Remote Networks), that choice is grayed out.

STEP 5 | Click OK to create the first tenant.

Prisma Access Administrator’s Guide (Panorama Managed) 423 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 6 | Make sure that Prisma Access applied the template stack, template, and device group service
settings to the service connection settings of the tenant you just created.
1. Select the tenant you created from the Tenant drop-down.

2. Select Panorama > Cloud Services > Configuration > Service Setup.
3. Click the gear icon to the right of the Settings area to edit the settings.
4. Make sure that Prisma Access has associated the template stack (sc-stk-tenant), template
(sc-tpl-tenant), and device group (sc-dg-tenant) to your service connection settings.
5. Make sure that the Parent Device Group is set to Shared and click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 424 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 7 | Make sure that Prisma Access applied the template stack, template, and device group to the
remote network settings.
1. Select Panorama > Cloud Services > Configuration > Remote Networks and click the
gear icon to the right of the Settings area to edit the settings.
2. Make sure that the Prisma Access has associated the template stack (rn-stk-tenant),
template (rn-tpl-tenant), and device group (rn-dg-tenant) to your remote network
settings.
3. Make sure that the Parent Device Group is set to Shared and click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 425 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 8 | Make sure that Prisma Access applied the template stack, template, and device group to the
mobile user settings.
1. Select Panorama > Cloud Services > Configuration > Mobile Users and click the gear
icon to the right of the Settings area to edit the settings.
2. Make sure that the Prisma Access has associated the template stack (mu-stk-tenant),
template (mu-tpl-tenant), and device group (mu-dg-tenant) to your remote network
settings.
3. Make sure that the Parent Device Group is set to Shared and click OK.

STEP 9 | Mobile User deployments only—Add an infrastructure subnet, then commit and push your
changes to make them active in Prisma Access.
These steps are required for the mobile user changes to take effect.
1. Select Panorama > Cloud Services > Configuration > Service Setup, click the gear icon
to edit the Settings, and configure an infrastructure subnet.
2. Select Commit > Commit and Push, Edit Selections in the Push Scope, and make sure
that Mobile Users is selected.
3. Click OK to save your changes to the Push Scope.
4. Commit and Push your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 426 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 10 | Select the new tenant you created by selecting Panorama > Cloud Services > Configuration
> tenant-name and continue the configuration of your tenant.
1. Configure the Service Infrastructure.
2. Create a Service Connection to Allow Access to Private Apps.
3. Onboard and Configure Remote Networks if you are licensed for remote networks.
4. Set Up GlobalProtect on Panorama Managed Prisma Access if you are licensed for
remote users.

Prisma Access Administrator’s Guide (Panorama Managed) 427 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Delete a Tenant
To delete a tenant, complete the following task.

While you can delete all tenants in a multitenant deployment, you cannot delete the
admin-level Prisma Access configuration where you add or delete tenants.

STEP 1 | Select the tenant, and delete all configuration associated with it.
This includes any Service Connection, Mobile User, Remote Network, or Clean Pipe
configuration.

STEP 2 | Commit and Push your changes to Prisma Access.

1. Select Commit > Push to Devices.
2. Edit Selections, and make sure that all the components you deleted (including Remote
Networks, Mobile Users, Service Setup, Explicit Proxy, and Clean Pipe, depending on
your deployment) are selected.

3. Click Push.

Prisma Access Administrator’s Guide (Panorama Managed) 428 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 3 | Select Panorama > Cloud Services > Configuration, select the tenant, then Delete it.

Deleting a tenant also deletes any public IP addresses Prisma Access has assigned for service
connections, remote networks, and mobile users.

When you delete a tenant, Prisma Access deletes the template and device group set
for which you are licensed, but does not delete the unlicensed set. For example, if you
have a Prisma Access for Users license and delete a tenant, Prisma Access deletes the
mobile user-related template stacks, templates, and device groups but does not delete
the set it created for the unlicensed Prisma Access for Networks. You can manually
delete these unused template and device group sets after you delete the tenant.

STEP 4 | Select Commit > Commit to Panorama and Commit your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 429 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Create a Tenant-Level Administrative User

You should create an administrative user for each tenant. In that way, a tenant-level administrator
can view and make changes to their tenant configuration but doesn’t have access to other
tenants. To create an administrative user for a specific tenant, complete the following task. For
more information about role-based access control (RBAC) for tenant-level administrative users,
see Control Role-Based Access for Tenant-Level Administrative Users.

Users who manage single tenants cannot see the system logs because the Monitor > Logs
> System choice is not available. This limitation applies to all Administrators who have an
administrative role of Device Group and Template. Only superusers can view system logs
in multitenancy mode.

Prisma Access Administrator’s Guide (Panorama Managed) 430 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 1 | Create an administrative role with a type of Device Group and Template.
1. Select Panorama > Admin Roles.
2. Add an Admin Role Profile with a Role of Device Group and Template.
3. Click OK.
You can create a single Admin Role Profile and share it across multiple tenants; however,
you must create a separate administrator for each tenant.

While you tailor the administrative role for the needs of your organization, we
recommend deselecting Commit for Other Admins. Deselecting this choice
allows a tenant-level user to commit only the changes they have made, and
prevents them from unintentionally committing other changes that other
tenant-level administrative users have made that are not yet committed.

Prisma Access Administrator’s Guide (Panorama Managed) 431 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Prisma Access Administrator’s Guide (Panorama Managed) 432 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 2 | Create and configure an Administrator for the tenant.

1. Select Panorama > Administrators.
2. Add an Administrator.
3. Enter and confirm a Password for the new Administrator.
4. Specify an Administrator Type of Device Group and Template Admin.
5. Specify the Access Domain that is associated with the device groups for that tenant.
6. Specify the Admin Role that you created in Step 1 for the tenant.

STEP 3 | Click OK.

STEP 4 | Repeat Steps 2 and 3 to add additional users to manage your tenants as required.

STEP 5 | Select Commit > Commit to Panorama and Commit your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 433 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Control Role-Based Access for Tenant-Level

Administrative Users
If you manage a multitenant deployment, you can use role-based access control (RBAC) to create
tenant-level administrative users.
To modify RBAC-level access for tenant-level administrative users in Panorama, you create a
tenant-level administrative user, use an Admin Role Profile with a Role of Device Group and
Template, and Enable, Disable, or give Read Only access to areas of the Panorama Web UI.
Use this method to manage access to all Panorama components for tenant-level users, with the
exception of access to the Cloud Services plugin where you manage Prisma Access.
If you want to restrict a tenant-level user from configuring the Prisma Access components in
Panorama, you cannot use Admin Roles. To disallow users from configuring Prisma Access-
specific configuration tasks, you must prevent the user from accessing the Cloud Services plugin,
which also prevents them from viewing it. Using this method, you can create an administrative
user for a security professional who has permissions to make changes to security policies and
push those changes to Panorama, but cannot view or make any changes to Prisma Access
configuration.

You can either enable or disable access to the Cloud Services plugin for a user, but you
cannot give a user read-only access; if a user has access to view the Cloud Services plugin,
the user can also make configuration changes to its components, including Prisma Access.

The following table shows sample tenant-level administrative roles and the steps you perform to
create those roles.

Sample Tenant-Level Configuration Configuration Task

Create a networking-focused user Create a tenant-level administrative user, enabling

who: Save and Commit permissions in the Admin Role
Profile, and disabling or making Read Only any
• Can edit plugin configurations
permissions that you don’t want the tenant-level
• Can commit to Panorama administrative user to have.
• Can push configuration to Prisma
Access

Create a security-focused user who: To prevent a tenant-level administrative user from

viewing or accessing the plugin, remove plugin
• Can view and make changes to
access for a tenant-level administrator. For all other
security policies
Panorama-related permissions, change the Admin Role
• Can commit to Panorama permissions for the user.
• Cannot view, or make changes to,
the Cloud Services plugin
• Cannot push configuration
to Prisma Access (requires

Prisma Access Administrator’s Guide (Panorama Managed) 434 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Sample Tenant-Level Configuration Configuration Task

the superuser to push the
configuration)

Create a hybrid user who: This configuration is not possible. You cannot make the
Cloud Services plugin read-only. You can only provide
• Has read-only access to the Cloud
access to admin users to view it and use it to make
Services plugin
configuration changes, or disallow them from viewing
• Has read-write access to the it.
security policy
• Cannot push the configuration
to Prisma Access (requires
the superuser to push the
configuration)

Remove Plugin Access for a Tenant-Level Administrative User

In normal multitenant configurations, you use access domains Add Tenants to Prisma Access and
associate each access domain with a tenant. To prevent a tenant-level administrative user from
viewing or making configuration changes to Prisma Access, you create an access domain, but you
do not associate it with a tenant.
Because you associated the access domain to the device groups and template stacks for the
tenant, the tenant-level administrative user has RBAC access at the tenant level and is able to
perform configuration for that tenant only. Because you did not associate the access domain with
a tenant in Prisma Access, the access domain is unable to view the Cloud Services plugin, which
provides access to Prisma Access. In this way, you create a user who can perform tenant-level
configuration tasks without being able to access, view, or make configuration changes to Prisma
Access.
To remove Prisma Access access for an administrative-level user, complete the following task.

This task assumes that you have Add Tenants to Prisma Access templates, template
stacks, and device groups for the tenant; you’ll be associating them to the tenant-level
administrative user.

Prisma Access Administrator’s Guide (Panorama Managed) 435 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 1 | Create an administrative role with a type of Device Group and Template.
1. Select Panorama > Admin Roles.
2. Add an Admin Role Profile with a Role of Device Group and Template.
3. Click OK.
You can create a single Admin Role Profile and share it across multiple tenants.

Prisma Access Administrator’s Guide (Panorama Managed) 436 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Prisma Access Administrator’s Guide (Panorama Managed) 437 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 2 | Select Panorama > Access Domain and Add an Access Domain.

Prisma Access Administrator’s Guide (Panorama Managed) 438 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 3 | Specify the Device Groups and Templates associated with the tenant.

If you created any device groups that are children or grandchildren of other device
groups under the Shared parent device group, select only the device group at the
lowest hierarchical level (child or grandchild); do not select the parent or you will have
errors on commit.

Prisma Access Administrator’s Guide (Panorama Managed) 439 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 4 | Create and configure an Administrator for the tenant-level administrative user, specifying the
Access Domain you just created.
1. Select Panorama > Administrators.
2. Add an Administrator.
3. Enter and confirm a Password for the new Administrator.
4. Specify an Administrator Type of Device Group and Template Admin.
5. Specify the Access Domain that is associated with the device groups for that tenant.
6. Specify the Admin Role that you created in Step 1 for the tenant.
When you complete this example, the abcd-tenant-no-plugin-access Administrative user
will have permissions based on what you defined in the Admin Role profile, but will not

Prisma Access Administrator’s Guide (Panorama Managed) 440 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

be able to view or configure the Cloud Services plugin (including Prisma Access). Note,
however, that they will not be able to push any changes that they make to the cloud.

STEP 5 | Select Commit > Commit to Panorama and Commit your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 441 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Sort Logs by Device Group ID in a Multitenant

Deployment
To sort the logs manually by tenant in Panorama, select Monitor > Logs and choose the Device
Group associated with that tenant to display the logs for that device group. However, if you are
forwarding your logs to an external device, you might have a need to sort those logs at the tenant
level. To do so, find the device group ID in the logs that is associated with the device group and
use that group ID-to-device group mapping to associate the logs with a tenant.
There are four fields associated with the device group in the logs: DG Hierarchy Level 1, DG
Hierarchy Level 2, DG Hierarchy Level 3, and DG Hierarchy Level 4. These fields show the device
group IDs in its hierarchy. The shared device group (level 0) is not included in this structure.
DG Hierarchy Level 1 refers to the first device group level in the hierarchy. If you added children
or grandchildren device groups, the DG Hierarchy Level 2 through DG Hierarchy Level 4 fields
show the hierarchy from the child group to the great-grandchild group, respectively.
To find logs by tenant, complete the following task.
STEP 1 | Find the device group IDs associated with the device group.
• To find this information using a CLI command, log into Panorama as a superuser (admin-
level user), enter the show readonly command in configuration mode, and view the
values in the device-group heading. The IDs for the device groups display under the device
group name. The following example shows that the device ID for the acme-sc device group
is 20.
Note that these device groups are at the first level in the hierarchy (DG Hierarchy Level 1);
you use that information in the query in the next step.

admin# show readonly

...
device-group {
acme-sc {
id 20;
}
acme-rn {
id 39;
}
acme-mu {
id 40;
}
hooli-rn {
id 56;
}
hooli-sc {
id 57;
}

Prisma Access Administrator’s Guide (Panorama Managed) 442 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

hooli-mu {

• To use an API query, enter the following API command:

/api/?type=op&cmd=<show><dg-hierarchy></dg-hierarchy></show>

For more information about using APIs with logs, see Retrieve Logs (API).

STEP 2 | Use the device group ID-to-device group name mapping to associate the logs with a tenant.
The following example shows an administrator retrieving the logs for Acme using the Log
Forwarding App to create a Syslog Forwarding Profile. Since the mapping example in Step 1

Prisma Access Administrator’s Guide (Panorama Managed) 443 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

retrieves the device group-to-device ID of 20 for Acme and the hierarchy is at Level 1, you use
that in the query, along with the following parameters:
• A descriptive Name for the profile.
• The Syslog Server IP address (you can also specify an FQDN).
• The Port on which the server is listening.
The default port for Syslog messages over TLS is 6514.
• The Facility selected from the drop-down.

Prisma Access Administrator’s Guide (Panorama Managed) 444 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

STEP 3 | Add the Forwarding parameters that select the logs you want to forward.
The following example shows the administrator creating a Traffic log using a Custom filter with
a Query that selects the logs for Acme, based on the hierarchy level (DG Hierarchy Level 1)
and the device group (20) you retrieved in Step 1.

Prisma Access Administrator’s Guide (Panorama Managed) 445 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Manage Multiple Tenants in Prisma Access

Prisma Access Administrator’s Guide (Panorama Managed) 446 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced
Deployments
Some Prisma Access routing and networking deployments require a thorough understanding of
your organization’s topology and routing devices, along with an understanding of how Prisma
Access routing works. Read about these advanced deployments and how to configure them in this
section.
Advanced Deployments that Apply to Service Connections, Mobile Users, and Remote Networks:
• Add a New Compute Location for a Deployed Prisma Access Location
• IPv6 Support for Private App Access
• DNS Resolution for Mobile Users—GlobalProtect and Remote Network Deployments
• How BGP Advertises Mobile User IP Address Pools for Service Connections and Remote
Network Connections
• Proxy Support for Prisma Access and Cortex Data Lake
Service Connection Advanced Deployments:
• Service Connection Multi-Cloud Redundancy
• Use Traffic Steering to Forward Internet-Bound Traffic to Service Connections
• Routing for Service Connection Traffic
• Create a High-Bandwidth Network Using Multiple Service Connections
Mobile Users—GlobalProtect Advanced Deployments:
• Configure Multiple Portals in Prisma Access
• Dynamic DNS Registration Support for Mobile Users—GlobalProtect
• Identification and Quarantine of Compromised Devices in a Prisma Access GlobalProtect
Deployment
• Sinkhole IPv6 Traffic In Mobile Users—GlobalProtect Deployments
• Redistribute HIP Information with Prisma Access
• View HIP Reports from Panorama
• Support for Gzip Encoding in Clientless VPN
Mobile Users—Explicit Proxy Advanced Deployments:
• Secure Users and Devices at Remote Networks With an Explicit Proxy
Remote Network Advanced Deployments:
• Provide Secure Inbound Access to Remote Network Locations
• Create a High-Bandwidth Network for a Remote Site

447
Prisma Access Advanced Deployments

Advanced Deployments that Apply to All Prisma Access

Types
Some advanced deployments apply to one or more Prisma Access deployment types (Service
Connections, Mobile Users, or Remote Networks), as shown in the following sections:
• Add a New Compute Location for a Deployed Prisma Access Location
• IPv6 Support for Private App Access
• DNS Resolution for Mobile Users—GlobalProtect and Remote Network Deployments
• How BGP Advertises Mobile User IP Address Pools for Service Connections and Remote
Network Connections
• Proxy Support for Prisma Access and Cortex Data Lake

Add a New Compute Location for a Deployed Prisma Access

Location
To optimize performance and improve latency, Prisma Access can introduce new compute
locations for locations you have already deployed as part of a plugin upgrade. When you upgrade
the plugin, the existing compute location-to-location mapping does not change, but you can
choose to take advantage of the new compute location. If you change the compute location,
Prisma Access changes the gateway and portal IP addresses (for mobile users) and Service IP
addresses (for remote networks and service connections) for the location or locations to which
the new compute location is associated. If you use allow lists in your network to provide users
access to internet resources such as SaaS applications or publicly accessible partner applications,
you need to add these new IP addresses to your allow lists.
To upgrade to a new compute location after it becomes available, complete the following task.
Since you need to allow time to delete and add the existing location and change your allow lists
(for mobile users) or peer IPSec tunnel IP address (for remote networks and service connections),
Palo Alto Networks recommends that you schedule a compute location change during a
maintenance window or during off-peak hours.

To reduce down time for mobile user deployments, use the API to pre-allocate the new
mobile user gateway and portal IP addresses before you perform these steps.

STEP 1 | (Remote Network deployments only) Add bandwidth for the new remote network compute
locations.
1. (Remote Network deployments that allocate remote network bandwidth by compute
locations only) Select Panorama > Cloud Services > Configuration > Remote Networks.
2. Click the gear icon in the Bandwidth Allocation area and add Bandwidth Allocation
(Mbps) for the new compute location.
3. Wait for the bandwidth to be reflected in the Allocated Total field at the top of the page;
then, click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 448 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 2 | Delete the Service Connection, Remote Network connection, or Mobile User location
associated with the new compute location.
For Mobile User—GlobalProtect deployments, if you have added the location to the Manual
Gateway Locations tab, be sure to delete it from there as well as the Locations tab.

STEP 3 | Commit and push your changes.

STEP 4 | Re-add the locations you just deleted.

STEP 5 | Commit and push your changes.

STEP 6 | (Mobile User deployments only) Retrieve the new gateway and portal IP addresses using the
API script and add them to your allow lists.

STEP 7 | (Remote Network and Service Connection deployments only) Change your CPE to point to
the new IP addresses for the IPSec tunnel for the remote network connection or service
connection.
For remote network connections, select Panorama > Cloud Services > Status > Network
Details > Remote Networks, make a note of the Service IP Address, and configure the new
Service IP Address as the peer address for the remote network IPSec tunnel on your CPE.
For service connections, select Panorama > Cloud Services > Status > Network Details >
Service Connection, make a note of the Service IP Address, and configure the new Service IP
Address as the peer address for the service connection IPSec tunnel on your CPE.

STEP 8 | Select Panorama > Cloud Services > Status > Network Details > Remote Networks, make
a note of the Service IP Address, and configure the new Service IP Address as the peer
address for the remote network IPSec tunnel on your CPE.
When you delete and re-add a remote network connection, the IP address of the IPSec tunnel
on the Prisma Access side changes.

IPv6 Support for Private App Access

If your organization uses IPv6 addressing for your internal resources, Prisma Access makes it
possible for you to access internal (private) apps that are behind IPv6 addresses. You can access
these apps either from a data center behind a service connection or from a branch office behind a
remote network connection.

You cannot access external SaaS or public apps using IPv6; IPv4 networking is still
required to access external apps.

Users access internal apps through GlobalProtect (for external GlobalProtect mobile users) or
through a remote network IPSec tunnel (for internal GlobalProtect mobile users in a branch
office accessing Prisma Access through a remote network connection). Either internal or external
GlobalProtect mobile users can access private apps over IPv6.
• External GlobalProtect mobile users connect to the Prisma Access network using an IPv4
VPN tunnel, and you configure internal IPv6 addressing in Prisma Access to allow the users to
access private apps behind an IPv6 network.

Prisma Access Administrator’s Guide (Panorama Managed) 449 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• Internal GlobalProtect mobile users at a remote network connect to Prisma Access using an
IPv4 IPSec tunnel, and you configure internal IPv6 addressing in Prisma Access so that those
users can access private apps behind an IPv6 network. See Private App Access Over IPv6
Examples for examples.
You configure IPv6 in the following Prisma Access network components:
• Enable IPv6 and specify an IPv6 subnet in your Infrastructure Subnet to establish an IPv6
network infrastructure to enable communication between your remote networks (branch
locations), mobile users, and service connections (data center or headquarters locations).
• For a Mobile Users—GlobalProtect deployment, specify whether or not IPv6 networking should
be utilized for the compute locations that are associated with your mobile user locations.
You can specify IPv6 mobile user IP address pools and IPv6 DNS server addresses as required.
• For service connections and remote network connections, you can specify IPv6 addressing for
the type of routing the connection uses (either static or BGP routes).
• For static routes, specify an IPv6 address for the subnets used for the static routes.
• For BGP routes, specify an IPv6 Peer Address and Local Address.
You can also specify the transport method used to exchange BGP peering information.
You can specify to use IPv4 to exchange all BGP peering information (including IPv4 and
IPv6), use IPv6 to exchange all BGP peering information, or use IPv4 to exchange IPv4 BGP
peering information and IPv6 to exchange IPv6 BGP peering information.
• For remote networks, you can add IPv6 addresses for DNS servers.
The following deployments do not support IPv6 addressing:
• Clean Pipe deployments
• Traffic Steering (using traffic steering rules to redirect internet-bound traffic using a service
connection)

Private App Access Over IPv6 Examples

The following figures provide examples of how you can access private apps using Prisma Access.
The following figure shows a mobile user accessing a private app at a branch location. The branch
is connected to Prisma Access by a remote network connection. If your network uses IPv6, you
can configure the Mobile User IP address pool (for mobile users), Infrastructure Subnet (for
service connections), and static or BGP routing (for the remote network connections) to use IPv6
addressing to access the app.

Prisma Access Administrator’s Guide (Panorama Managed) 450 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

The following figure shows a mobile user accessing a private app that is hosted at a data center
connected to Prisma Access by a service connection. You can configure the Mobile User IP
address pool (for mobile users) and Infrastructure Subnet (for service connections) to use IPv6
addressing to access the app.

The following figure shows an internal GlobalProtect user at a branch location connected to
Prisma Access by a remote network accessing a private app that is hosted at a data center
connected to Prisma Access by a service connection. You can configure the Infrastructure Subnet
(for service connections) and static or BGP routing (for the service connections and remote
network connections) to use IPv6 addressing to access the app.

Prisma Access Administrator’s Guide (Panorama Managed) 451 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

The following figure shows a user at a branch location connected to Prisma Access by a remote
network accessing a private app that is hosted at another branch location connected by a remote
network connection. You can configure IPv6 addressing for static or BGP routing for the remote
network connections to access the app.

The following figure shows a user at a branch location with IPv6 addressing accessing an external
app. In this case, IPv4 routing is required to access the external app, regardless of your Prisma
Access IPv6 configuration.

Prisma Access Administrator’s Guide (Panorama Managed) 452 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

The same IPv4 requirement applies for external GlobalProtect users who access a public app.

Enable and Configure IPv6 Networking and IP Pools in Your Prisma Access
Infrastructure
For any Prisma Access deployment, you need to enable IPv6 globally and specify an IPv6 subnet
in your Infrastructure Subnet so that Prisma Access can establish an IPv6 network infrastructure
between your remote network locations, mobile users, and service connections. To do so,
complete the following steps.
STEP 1 | Select Panorama > Cloud Services > Configuration > Service Setup and click the gear icon to
edit the Settings.

Prisma Access Administrator’s Guide (Panorama Managed) 453 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 2 | On the General tab, select Enable IPv6.

Enabling or disabling IPv6 results in a brief traffic interruption (up to 120 seconds) while the
dataplane prepares to accept or reject IPv6 routes on the Prisma Access backbone. Palo Alto
Networks recommends that you commit this configuration change during a maintenance
window or during off-peak hours.

If you need to delete IPv6, delete all configuration (including for mobile users, remote
network, and service connections as applicable) before deselecting the Enable IPv6
check box.

STEP 3 | Specify an IPv6 infrastructure subnet and an Infrastructure BGP AS.

• Specify a minimum subnet of /96.
• You must also enter an IPv4 subnet; Prisma Access requires IPv4 and IPv6 subnets in its
network infrastructure to use IPv6. See Configure the Service Infrastructure for details.
• Palo Alto Networks recommends that you use private (not public) IPv4 and IPv6 addresses.
• Do not use IPv6 link local addresses (fe80::/10).

Prisma Access Administrator’s Guide (Panorama Managed) 454 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 4 | Enter the Infrastructure BGP AS you want to use within the Prisma Access infrastructure.
If you want to use dynamic routing to enable Prisma Access to dynamically discover routes to
resources on your remote networks and HQ/data center locations, specify the autonomous
system (AS) number. If you do not supply an AS number, the default AS number 65534 will be
used.

STEP 5 | If you have not yet completed the service setup configuration, enter the Internal Domain
List, Cortex Data Lake, and Advanced settings.
See Configure the Service Infrastructure for details.

STEP 6 | (Mobile User Deployments Only) Add IPv6 IP address pools for your Mobile Users—
GlobalProtect deployment.
A Mobile Users—GlobalProtect deployment requires IP address pools. Both IPv4 and IPv6 IP
address pools are required to enable IPv6 functionality. You apply IPv4 addresses at a regional
or Worldwide level; you apply IPv6 addresses at a Worldwide level. Specify a minimum /80
subnet.
Prisma Access subdivides the Worldwide IPv6 addresses using the following method:
• Prisma Access assigns each location (gateway) a pool from a /112 subnet. Because each
GlobalProtect connection uses one IP address from the pool, this allocation allows over
65,000 available IPv6 addresses to be assigned to users’ endpoints per location.
If you experience an auto-scale event (if a large number of users log in to a single Prisma
Access location), Prisma Access can add another location with another /112 subnet.
• When you enable a location to use IPv6, Prisma Access assigns an IPv6 address pool to the
region to which the location belongs, and divides up the pool between the total number of
regions that have IPv6 enabled.

Do not use local-link addresses (fe80::/10) in an IP address pool.

1. Select Panorama > Cloud Services > Configuration > Mobile Users—GlobalProtect.
2. In the Onboarding section, select the portal Hostname or select Configure.
3. Select the IP Pools tab.
4. Enter an IP Pool IPv6.
• You must enter both IPv4 and IPv6 IP addresses for mobile users. Prisma Access
requires IPv4 and IPv6 addresses to support its internal infrastructure when using

Prisma Access Administrator’s Guide (Panorama Managed) 455 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

IPv6. See IP Address Pools in a Mobile Users—GlobalProtect Deployment for more

information about IPv4 IP address pools.
• Enter a minimum IPv6 subnet of /80.
• Prisma Access subdivides each subnet per region.

STEP 7 | Commit and Push your changes.

STEP 8 | Select Panorama > Cloud Services > Status > Network Details > Service Infrastructure and
make a note of the following IPv6 addresses:
• Captive Portal Redirect IP Addresses—Used with Authentication Portal-based User-ID
address mapping
• Tunnel Monitor IP Address—Used for Tunnel Monitoring
Because GlobalProtect mobile users require an IPv4 address for the VPN tunnels, loopback
addresses, whose IP addresses are taken from the Infrastructure Subnet, still use IPv4
addresses.

Enable IPv6 Networking for a Mobile Users—GlobalProtect Deployment

In addition to specifying mobile user IP address pools, you must configure IPv6 Availability for
your Mobile Users—GlobalProtect deployments. If your network uses IPv6 DNS servers to resolve
internal domains, you can also specify IPv6 addresses for primary and secondary DNS servers, as
shown in the following section.
STEP 1 | Plan if you want to deploy IPv6 across your entire Prisma Access deployment, or for only a
certain number of compute locations.

Prisma Access Administrator’s Guide (Panorama Managed) 456 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 2 | Configure IPv6 availability for the regions where you want to deploy IPv6.
1. In the IPv6 Availability tab, Enable IPv6 for the locations for which you want to enable
IPv6.
All locations are associated to a compute location. If locations in a compute location do
not have IPv6 enabled, leave that compute location deselected.

STEP 3 | (Optional) If your internal DNS servers use are reachable by IPv6 addresses, click the
Network Services tab, Add a rule or specify the default rule, and specify Custom DNS Server
IPv6 addresses for the Primary DNS and Secondary DNS server.
If you enter IPv6 addresses for DNS servers, you must also have IPv6 addresses in your mobile
user IP address pool.
You can enter any combination of IPv4 or IPv6 addresses for primary and secondary DNS
servers. If you enter an IPv6 address for the primary DNS server and an IPv4 address for the
secondary DNS server, and a DNS query is received from a compute location that does not
have IPv6 Availability enabled, Prisma Access uses the secondary DNS server because it uses
an IPv4 address.

IPv4 addresses use A records, while IPv6 addresses use AAAA records. Some DNS
servers can perform AAAA DNS lookups over IPv4 transport; therefore, you might not
need a server with an IPv6 IP address.

STEP 4 | (Optional) If you have not yet completed the your mobile users configuration, complete it
now. See Set Up GlobalProtect on Panorama Managed Prisma Access for details.

Prisma Access Administrator’s Guide (Panorama Managed) 457 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 5 | Commit and Push your changes.

Enable IPv6 Networking for Service Connections

For service connections, you can use IPv6 subnets for static or BGP routing. For BGP routing, you
can enter IPv6 peer addresses and specify IPv4 and IPv6 routing options.
To configure IPv6 networking for service connections, complete the following task.
STEP 1 | Select Panorama > Cloud Services > Configuration > Service Connection.

STEP 2 | Add a new service connection or select an existing service connection to edit it.

Prisma Access Administrator’s Guide (Panorama Managed) 458 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 3 | Set up IPv6 routing for the service connection.

1. (Static Routing Deployments Only) Enter one or more Corporate Subnets in the Static
Routes tab.

2. (BGP Routing Deployments Only) Specify the method to exchange IPv4 and IPv6 BGP
routes; then, enter an IPv6 Peer Address and Local Address.
• To use a single IPv4 BGP session to exchange both IPv4 and IPv6 BGP peering
information, select Exchange both IPv4 and IPv6 routes over IPv4 peering.
• To an IPv4 BGP session to exchange IPv4 BGP peering information and an IPv6
session to exchange IPv6 BGP peering information, select Exchange IPv4 routes over
IPv4 peering and IPv6 routes over IPv6 peering.
• To use a single IPv6 BGP session to exchange IPv6 BGP peering information, select
Exchange IPv6 routes over IPv6 peering.
3. If your secondary WAN uses a different peer or local address, deselect Same as Primary
WAN and enter the IPv6 Peer Address and Local Address for the secondary WAN.

Prisma Access Administrator’s Guide (Panorama Managed) 459 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 4 | If you have not yet completed the your service connection setup, complete it now. See
Create a Service Connection to Allow Access to Private Apps for details.

STEP 5 | Commit and Push your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 460 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 6 | Select Panorama > Cloud Services > Status > Network Details > Service Connection and
make a note of the IPv6 User-ID Agent Address and EBGP Router addresses.
After you commit your changes, you will have an IPv6 User-ID Agent Address (used for User-
ID retrieval and distribution) and EBGP Router addresses for service connections.
Because the IPSec tunnel used for the service connection uses IPv4 addressing, the Service IP
Address is an IPv4 address.

STEP 7 | If you have not yet completed the your mobile users configuration, complete it now. See
Create a Service Connection to Allow Access to Private Apps for details.

Enable IPv6 Networking for Remote Networks

For remote network connections, you can use IPv6 subnets for static routes. For BGP routing, you
can enter IPv6 peer addresses and specify that BGP use IPv6 routing only or both IPv4 and IPv6
routing.
To configure IPv6 networking for remote network connections, complete the following task.
STEP 1 | (Optional) Enter IPv6 addresses to your custom DNS server proxy configuration.
1. Select Panorama > Cloud Services > Configuration > Remote Networks and edit the
settings by clicking the gear icon in the Settings area.
2. In the DNS Proxy area, enter IPv6 Custom DNS Server addresses for your DNS proxy
settings.
See Onboard and Configure Remote Networks for more information about configuring
DNS proxy settings for remote networks.

STEP 2 | Select Panorama > Cloud Services > Configuration > Remote Networks.

STEP 3 | Add a new remote network connection or select an existing service connection to edit it.

Prisma Access Administrator’s Guide (Panorama Managed) 461 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 4 | Set up IPv6 routing for your remote network.

1. (Static Routing Deployments Only) Enter one or more Corporate Subnets in the Static
Routes tab.

2. (BGP Routing Deployments Only) Specify the method to exchange IPv4 and IPv6 BGP
routes; then, enter an IPv6 Peer Address and Local Address.
• To use a single IPv4 BGP session to exchange both IPv4 and IPv6 BGP peering
information, select Exchange both IPv4 and IPv6 routes over IPv4 peering.
• To an IPv4 BGP session to exchange IPv4 BGP peering information and an IPv6
session to exchange IPv6 BGP peering information, select Exchange IPv4 routes over
IPv4 peering and IPv6 routes over IPv6 peering.
• To use a single IPv6 BGP session to exchange IPv6 BGP peering information, select
Exchange IPv6 routes over IPv6 peering.
3. If your secondary WAN uses a different peer or local address, deselect Same as Primary
WAN and enter the IPv6 Peer Address and Local Address for the secondary WAN.

Prisma Access Administrator’s Guide (Panorama Managed) 462 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 5 | (Optional) If your internal DNS servers use are reachable by IPv6 addresses, select Panorama
> Cloud Services > Configuration > Remote Network > Settings, click the gear icon to edit

Prisma Access Administrator’s Guide (Panorama Managed) 463 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

the settings, select the DNS Proxy tab, Add a rule or specify the default rule, and specify
Custom DNS Server IPv6 addresses for the Primary DNS and Secondary DNS server.
Prisma Access allows you to specify DNS servers to resolve both domains that are internal to
your organization and external domains. If you do not specify any settings, Prisma Access does
not proxy DNS requests for remote networks. You also need to select a Region. See Onboard
and Configure Remote Networks for more information.
You can enter any combination of IPv4 or IPv6 addresses for primary and secondary DNS
servers.

IPv4 addresses use A records, while IPv6 addresses use AAAA records. Some DNS
servers can perform AAAA DNS lookups over IPv4 transport; therefore, you might not
need a server with an IPv6 IP address.

STEP 6 | If you have not yet completed the your remote network connection setup, complete it now.
See Onboard and Configure Remote Networks for details.

STEP 7 | Commit and Push your changes.

STEP 8 | Select Panorama > Cloud Services > Status > Network Details > Remote Networks and
make a note of the EBGP Router addresses.
After you commit your changes, you will have an IPv6 EBGP Router addresses for service
connections.
Because the IPSec tunnel used for the remote network connection uses IPv4 addressing, the
Service IP Address stays as an IPv4 address.

DNS Resolution for Mobile Users—GlobalProtect and Remote

Network Deployments
Prisma Access allows you to specify DNS servers to resolve both domains that are internal to
your organization and external domains. Prisma Access proxies the DNS request based on the

Prisma Access Administrator’s Guide (Panorama Managed) 464 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

configuration of your DNS servers. The following table shows the supported DNS resolution
methods for internal and external domains and indicates when Prisma Access proxies the DNS
requests.

Internal DNS Resolution External DNS Resolution Prisma Access Proxies the
Method Method DNS Request (Yes/No)

Single rule, DNS server Cloud Default Yes

configured for Internal
Domains

Single rule, DNS server Same as Internal Domains No

configured for Internal
Domains

Single rule, DNS server Custom DNS server Yes

configured for Internal
Domains

Single rule, Cloud Default set Cloud Default Yes

for a domain

Single rule, Cloud Default set Same as Internal Domains Yes

for a domain

Single rule, Cloud Default set Custom DNS server Yes

for domain

Multiple rules, DNS server Cloud Default Yes

configured for Internal
Domains

Multiple rules, DNS server Same as Internal Domains Yes

configured for Internal
Domains

Multiple rules, DNS server Custom DNS server Yes

configured for Internal
Domains

No configuration Custom DNS Server Yes

No configuration Cloud Default No

No configuration No configuration No

No DNS resolution specified No DNS resolution specified No

(default configuration is
present, which uses Cloud
Default)

Prisma Access Administrator’s Guide (Panorama Managed) 465 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

The source IP address of the DNS request depends on whether or not Prisma Access proxies the
DNS request.
• When Prisma Access does not proxy the DNS requests, the source IP address of the DNS
request changes to the IP address of the device that requested the DNS lookup. This source IP
address allows you to enforce source IP address-based DNS policies or identify endpoints that
communicate with malicious domains. This behavior applies for both mobile users and remote
network deployments.
• When Prisma Access proxies the DNS requests, the source IP address of the DNS request
changes to the following addresses:
• Mobile User deployments—The source IP address of the DNS request is an IP address taken
from the mobile user IP address pool for internal requests and the mobile user location’s
gateway IP address for external requests.
• Remote Network deployments—The source IP address of the DNS request is the EBGP
Router Address for internal requests and the Service IP Address of the remote network
connection for external requests.
The following guidelines and restrictions apply to using DNS resolution with Prisma Access:
• The maximum number of concurrent pending TCP DNS requests ( Max Pending Requests) that
Prisma Access supports is 64.
• For UDP queries, the DNS proxy sends another request if it hasn’t received a response in 2
seconds, and retries a maximum of 5 times before trying the next DNS server.
• Prisma Access caches the DNS entries with a time-to-live (TTL) value of 300 seconds. EDNS
responses are also cached.

DNS Resolution for Mobile Users—GlobalProtect Deployments

The following section provides examples of how Prisma Access processes the source IP address of
the DNS requests after you configure DNS resolution for mobile users and for remote networks.
The following figure show a deployment where you have assigned an internal DNS server to
resolve both internal and external domains. In this case, Prisma Access does not proxy the DNS
requests, and the DNS request is from Mobile User 1’s GlobalProtect client IP address. The
GlobalProtect client assigns this IP address to the mobile user and it is taken from the Mobile User
IP address pool.

Prisma Access Administrator’s Guide (Panorama Managed) 466 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

The following figure shows the DNS requests for internal domains being resolved by the DNS
server in the headquarters or data center location, while requests for external domains are
resolved by Prisma Access’ Cloud Default DNS server. In this case, Prisma Access proxies the
requests for the external request, and the source IP address is the mobile user location’s gateway
IP address (15.1.1.1 in this example), while the internal source IP remains as Mobile User 1’s
GlobalProtect client IP address.

The following figure shows the organization using a third-party or public DNS server accessible
through the internet for requests to external domains. Prisma Access proxies these requests as
well.

Prisma Access Administrator’s Guide (Panorama Managed) 467 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

DNS Resolution for Remote Networks

If you have an existing remote network deployment, you can continue to use the DNS resolution
methods that you already have in place, or you can use Prisma Access to proxy the DNS request.
Proxying the DNS requests allows you to send DNS requests for public domains to one server and
send DNS request for internal domains to another server.
The following figure shows a DNS request to a deployment where an internal DNS server is used
to process requests for both internal and external domains. The remote network IP address is
35.1.1.1 and the EBGP Router IP address is 172.1.1.1. In this case, Prisma Access does not proxy
the requests and, if the internal DNS server does not use NAT, the source IP of the DNS request
is 10.1.1.1 (the IP address of Client 1’s device in the remote network site).

Prisma Access Administrator’s Guide (Panorama Managed) 468 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

If Prisma Access proxies the DNS request, the source IP addresses of the proxied DNS requests
changes to the EBGP Router Address for internal requests and the Service IP Address of the
remote network connection for external requests, as shown in the following figure.

When you configure the DNS address in your network to use for Prisma Access proxied
external requests, specify the Remote Network DNS Proxy IP Address ( Panorama >
Cloud Services > Status > Service Infrastructure > Remote Network DNS Proxy IP
Address). In the following example, you would specify 172.1.255.254 in your network for
the DNS server.

Prisma Access Administrator’s Guide (Panorama Managed) 469 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

How BGP Advertises Mobile User IP Address Pools for Service

Connections and Remote Network Connections
If you enable BGP for service connections or remote network connections, after you Set Up
GlobalProtect on Panorama Managed Prisma Access, Prisma Access allocates the mobile user IP
address pools you specified using Class C (/24) address blocks. BGP therefore advertises allocated
mobile user subnets in blocks of /24, rather than the entire pool(s) associated with that region.
When Prisma Access adds a /24 subnet for a Prisma Access gateway, it automatically sends a BGP
advertisement. As subnets are added and removed, Prisma Access automatically updates its BGP
advertisements. This allocation method provides more flexibility when advertising BGP routes,
especially if you configured a Worldwide pool instead of allocating pools per region. Dividing the
IP address pool into smaller subnets allows the same subnet to be added, removed, or deleted and
then reused in different regions when allocated address space is exhausted.
The following screenshot, from Panorama > Cloud Services > Status > Network Details > Mobile
Users—GlobalProtect, shows three /20 IP pools for mobile users divided by region.

The RIB Out table, from Panorama > Cloud Services > Status > Network Details > Service
Connection > Show BGP Status (in the Branch AS and Router area), shows the mobile users
address pool divided into blocks of /24 subnets for BGP route advertisements. Note that the
entire /20 subnets are not advertised.

Prisma Access Administrator’s Guide (Panorama Managed) 470 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Proxy Support for Prisma Access and Cortex Data Lake

If you deploy a proxy server between Panorama, the Prisma Access infrastructure, and Cortex
Data Lake, refer to the following table for details on the expected behavior:

Functionality Support through a Proxy Support through a Proxy

Server that does not perform Server that performs SSL
SSL Decryption Decryption

Initial onboarding to Cortex Supported Only pass-through proxies

Data Lake with Certificate are supported; any proxy

Prisma Access Administrator’s Guide (Panorama Managed) 471 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Functionality Support through a Proxy Support through a Proxy

Server that does not perform Server that performs SSL
SSL Decryption Decryption
Revocation Status checks using SSL decryption is not
using OCSP supported.

Prisma Access Administrator’s Guide (Panorama Managed) 472 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Prisma Access Service Connection Advanced

Deployments
The following sections show you the advanced deployments that are available for Prisma Access
Service Connections:
• Service Connection Multi-Cloud Redundancy
• Use Traffic Steering to Forward Internet-Bound Traffic to Service Connections
• Routing for Service Connection Traffic
• Create a High-Bandwidth Network Using Multiple Service Connections

Service Connection Multi-Cloud Redundancy

Service connection multi-cloud redundancy is supported starting with Prisma Access 3.1
Innovation.

If you use service connections to provide mobile users and users at remote sites access to internal
resources and apps in an HQ or data center, you can ensure more resilient access to those
resources by creating active and backup service connections in different cloud providers. You can
specify these active and backup service connections in the same location or at different locations
in different geographical regions, which allows you to access resources via service connections
even when a cloud provider or region becomes unavailable.
You specify active and backup service connections in a site. A site is a customer data center or
headquarters location (on-premises or in the public cloud) where one or more service connections
terminate. After you create service connections, you create a site, add service connections to that
site, and then specify the service connections you added as either active or backup.
If a cloud provider or regional outage causes an active service connection in a site to go down,
Prisma Access reroutes the traffic using these rules, which lets your mobile users continue to
access the resources in that HQ or data center:
• If there is a single active service connection in a site, Prisma Access selects the backup service
connection in that site to route the traffic.
• If there are multiple active service connections in a site, Prisma Access selects another of the
active service connections to route the traffic, and the backup service connection is only used
to route traffic when all active service connections go down.
To utilize a site that uses active and backup locations in the same country, you onboard service
connections using in-country Preferred and Alternate locations, then create a site and add those
in-country locations to the site.
Prisma Access also provides you with status messages regarding the service connections you have
onboarded in a site (for example, if all the service connections in a site are deployed in a single
region).
The following examples show how you can take advantage of creating sites and adding service
connections to it:

Prisma Access Administrator’s Guide (Panorama Managed) 473 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• Different Cloud Providers in the Same Geographical Region—If you are an organization
(such as a bank) that requires your data to be accessed in a specific country, you can select a
Preferred location from that country and an Alternate location from that same country. The
following example shows an organization in the UK that onboards their service connections
in the UK to follow data location regulations. In this case, the organization’s administrator
onboards two service connections in UK, UK-Active in the UK location and UK-Backup in the
UK PA-A location. The UK location is hosted by the preferred cloud provider (GCP) in the UK,
and the UK PA-A location is hosted by the alternate cloud provider (AWS) in that country. The
list of in-country locations shows the preferred and alternate cloud provider for a country.
The administrator then creates a site and designates UK-Active as the active location and UK-
Backup as the backup location in that site.
During normal operation, mobile users access internal resources at the HQ or data center using
the UK-Active service connection.

If a GCP outage affects the UK-Active service connection, Prisma Access fails over to the UK-
Backup service connection, which is hosted on AWS. In this way, Prisma Access allows mobile

Prisma Access Administrator’s Guide (Panorama Managed) 474 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

users access to the resources at the data center or HQ, even in the event of a cloud provider
outage. The following diagram shows the traffic flow.

• Different Geographical Regions—If you want to ensure redundancy in case of a regional

outage, you can specify two or more service connections in different compute locations as well
as different cloud providers, which provide you with backup access in the event of an outage
in a geographical region. In the following diagram, the administrator has onboarded service
connections from locations in the United States (US-Active in the US Southwest location and

Prisma Access Administrator’s Guide (Panorama Managed) 475 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

US-Backup in the US Northwest PA-A location) and created a site making US-Active the active
service connection in the site and US-Backup the backup.
Since you have onboarded service connections that are in different compute locations as
well as different cloud providers, you have configured a site that provides you with both
geographical and cloud provider redundancy.

If the US-Active location goes down (either because of a cloud provider or regional outage), the
service connection fails over to the US-Backup location, which uses a different cloud provider

Prisma Access Administrator’s Guide (Panorama Managed) 476 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

and compute location from the US-Active service connection, as shown in the following
diagram.

• High-Bandwidth Connection Using Multiple Service Connections—If you require a higher-

bandwidth connection to your internal resources, you can create a site with multiple active
connections. The following diagram shows four sites being onboarded, with a mix of GCP and
AWS cloud providers being used:
• US-NW-GCP-Active, using the US Northwest (GCP) location
• US-NW-AWS-Active, using the US Northwest PA-A (AWS) location
• US-West-Active-GCP, using the US West (GCP) location
• US-West-Backup-AWS, using the US West PA-A (AWS) location
In the site, three of the service connections are designated as active service connections, with
a fourth service connection being designated as backup. Designating three service connections

Prisma Access Administrator’s Guide (Panorama Managed) 477 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

as active effectively gives you three times the bandwidth to your internal resources when
compared to a single service connection.

If one of the active service connections goes down, the backup connection is not put into use;
instead, Prisma Access diverts the traffic to the remaining active service connections that are
up, as shown in the following diagram.

If all the active service connections go down, then the backup service connection is put into
use and made the active connection.

If you configure multiple service connections as backup service connections, Prisma

Access puts all backup service connections in use and load shares the service
connection traffic.

Prisma Access Administrator’s Guide (Panorama Managed) 478 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Use the following guidelines when configuring redundant cloud provider service connections:
• You can add service connections using either Preferred or Alternate locations in a site.
Palo Alto Networks highly recommends that you use the preferred cloud provider as the active
service connection in a site.
• All service connections in a site must point to the same resource in the same HQ or data
center location. You cannot have service connections in a site pointing to different resources in
different locations.
• You must select at least one active service connection in a site; however, you can also have
multiple active service connections in a single site. The following site configuration is valid:
• US Central (active)
• US Central PA-A (backup)
• US East (active)
• US East PA-A (backup)
• If you have multiple active service connections in a site and an active service connection goes
down, traffic is diverted to the other active service connection (that is, the backup service
connection is not utilized as long as one of the active service connections is up).
• Use the following guidelines for static and dynamic service connection routing:
• If you use static routing for service connections, make sure that the subnets you specify for
the service connections point to the same subnets.
For example, if you have a site that uses 192.168.41.0/24, 192.168.44.0/24, and
192.168.47.0/24 as the subnets for the active service connections, make sure that you
specify the same subnets for the backup service connections.
• If you use dynamic (BGP) routing for service connections, make sure that all service
connections advertise the same prefixes to the same data center or HQ.
• Prisma Access uses BGP Multi Exit Discriminator (MED) values to distinguish between active
and backup service connections in a site as shown in the following table. Note that the MED

Prisma Access Administrator’s Guide (Panorama Managed) 479 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

values for active service connections change depending on whether or not you have enabled a
secondary IPSec tunnel for the active service connection. Prisma Access advertises these MED
values to the CPE (BGP peer).

Connection Type MED Value

Active IPSec Service Connections in a Site

Active service connection, no secondary IPSec 0

tunnel configured

Active service connection, secondary IPSec tunnel 100

configured, primary tunnel

Active service connection, secondary IPSec tunnel 200

configured, secondary tunnel

Backup IPSec Service Connections in a Site

Backup service connection, primary tunnel 500

(regardless of whether or not a secondary IPSec
tunnel is configured)

Backup service connection, secondary IPSec 600

tunnel configured, secondary tunnel

• You can add multiple sites in a single Prisma Access deployment, as shown in the following
diagram.

Prisma Access Administrator’s Guide (Panorama Managed) 480 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• You can still use a single, standalone service connection to access internal resources. You an
also mix standalone service connections with active and backup service connections, as shown
in the following diagram.

• Service Connection multi-cloud redundancy is not supported when using Hot Potato routing
for service connections.
• Do not use CLI to enable regional redundancy.

Configure and Activate Service Connection Cloud Provider Redundancy for Panorama
Managed Prisma Access
To configure multiple service connections for cloud providers, complete the following steps.
STEP 1 | (Existing Prisma Access Deployments Only) If you have upgraded your plugin to a version
that supports cloud provider redundancy, perform a Commit and Push operation after you
upgrade to the supported plugin.
Service connection multi-cloud redundancy is supported starting with Prisma Access 3.1
Innovation. After you upgrade the Cloud Services plugin, you must perform a Commit and
Push to have the cloud redundancy changes appear in the UI.
If you have a new deployment (not an upgrade), skip this step.

Prisma Access Administrator’s Guide (Panorama Managed) 481 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 2 | Create the service connections to be used as active and backup service connections in a site.
1. Select Panorama > Cloud Services > Configuration > Service Connection.
2. Add a service connection that you will designate as an active service connection in a site.
Select from either the list of Preferred or Alternate Locations.

To search for a location, start typing the Location name.

3. Add a service connection that you will designate as a backup service connection in a site.

4. (Optional) Continue to onboard service connections to be designated as active and

backup sites, as required.

Prisma Access Administrator’s Guide (Panorama Managed) 482 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 3 | Create a site; then, designate the service connections you added as active or backup service
connections in the site.
1. In Manage Sites, Add a new site.
2. Add the service connections you onboarded.
3. Designate the service locations you added as active and backup in the site.
You can create multiple active and backup sites. Specify at least one site to be an active
site.
4. Click OK.
5. (Optional) Continue to add sites for your active and backup service connections, as
required.

STEP 4 | Commit and Push your changes.

STEP 5 | Check the status of your sites.

1. Select Panorama > Cloud Services > Status > Network Details > Service Connection >
Redundancy Status.
2. Check the information in the Redundancy Status and Redundancy Assessment fields.
The redundancy status provides you with the status of the sites you deploy and the
redundancy assessment provides you with more detail about the deployed service
connections in the site.

Redundancy Status Redundancy Assessment

Info Your service connections might experience

congestion in the event of a regional failure.

Warning All Service Connections are deployed in a single

region. Please consider deploying in nearby locations.

Prisma Access Administrator’s Guide (Panorama Managed) 483 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Redundancy Status Redundancy Assessment

This message informs you that all your service
connections are deployed in a single region.

Caution All Service Connections connecting to the site

are deployed in a single region. Please consider
deploying in nearby locations.
This message informs you that all service
connections connecting to a site are deployed in a
single region.

Supported In-Country Active and Backup Cloud Provider Redundancy Locations

If you want to configure a deployment where the active and backup locations are in the same
country, select from this list of in-country Preferred and Alternate locations.

Preferred Locations Alternate Locations

Australia Southeast Australia Southeast PA-A

Bahrain PA-A Bahrain

Brazil South Brazil South PA-A

Canada East Canada East PA-A

France North PA-A France North

Germany Central Germany Central PA-A

India West India West PA-A

Prisma Access Administrator’s Guide (Panorama Managed) 484 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Preferred Locations Alternate Locations

Ireland PA-A Ireland

Japan Central Japan Central PA-A

Singapore Singapore PA-A

South Africa West PA-A South Africa West

South Korea PA-A South Korea

UK UK PA-A

United Arab Emirates PA-A United Arab Emirates

US Central US Central PA-A

US East US East PA-A

US Northwest US Northwest PA-A

US West US West PA-A

Use Traffic Steering to Forward Internet-Bound Traffic to Service

Connections
Prisma Access allows you to create traffic steering rules to specify targets for internet-bound
traffic from mobile users and remote network connections. You can specify the traffic to be
redirected to a service connection before sending to the internet, or you can specify the traffic to
directly egress to the internet. This functionality is known as Traffic Steering.
Alternatively, you can configure Prisma Access to accept a default route from your CPE to Prisma
Access so that Prisma Access forwards internet-bound mobile user traffic to the best service
connection in your deployment.
The following sections provide an overview of default routes and traffic steering, as well as the
steps you take to configure it.
• Default Routes With Prisma Access Traffic Steering
• Traffic Steering in Prisma Access
• Traffic Steering Requirements
• Default Routes with Traffic Steering Example
• Default Routes with Traffic Steering Direct to Internet Example
• Default Routes with Traffic Steering and Dedicated Service Connection Example
• Prisma Access Traffic Steering Rule Guidelines
• Configure Zone Mapping and Security Policies for Traffic Steering Dedicated Connections
• Configure Traffic Steering in Prisma Access

Prisma Access Administrator’s Guide (Panorama Managed) 485 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Default Routes With Prisma Access Traffic Steering

Use the default route capability in Prisma Access to accept default routes being advertised from
your CPE to service connections. You can use BGP or static routes to advertise the default route.
Prisma Access uses BGP to advertise these routes over multiple service connections, which allows
Prisma Access to route mobile user traffic through the best service connection for a given mobile
user location. To enable service connections to accept default routes, specify Accept Default
Route over Service Connections when you Configure Traffic Steering in Prisma Access.
After you enable default routes, your internet-bound traffic will be steered to service connections
instead of egressing from the mobile user locations. This functionality can be useful if you want to
redirect internet-bound traffic to the data center; for example, if you have a third-party security
stack in your data center and you want the stack to perform additional screening or inspection.
Use the following guidelines when implementing default routes:
• Default routes apply to mobile user deployments only; remote network connections operate
normally with no change when you enable default routes.
• You do not need to specify target service connections or traffic steering rules when you allow
default routes, although they are supported for use with default routes.
• When you specify the Accept Default Route over Service Connections setting, all Prisma
Access service connections, with the exception of dedicated service connections, accept
default routes and will use the routes in traffic steering decisions.
• Before you enable this setting, make sure that your data centers are sending default routes;
otherwise, routing through service connections will fail.
• Palo Alto Networks recommends that all data centers advertise a default route; when Prisma
Access receives the routes, it can then select the best service connection to use for the remote
network location.
• When you create service connections, use either static routes only or BGP only for the
connections. Palo Alto Networks does not recommend mixing service connections that use
BGP and static routes when using default routes.
• Using default routes is supported with multitenant deployments.
• Prisma Access does not forward Clientless VPN, portal, or gateway SAML authentication traffic
to a public identity provider (IdP) using the default route.
For more information and examples of implementing default routes with traffic steering, see
Default Routes with Traffic Steering Example, Default Routes with Traffic Steering Direct to
Internet Example, and Default Routes with Traffic Steering and Dedicated Service Connection
Example.

Traffic Steering in Prisma Access

In standard Prisma Access deployments, a service connection provides access to internal network
resources, such as authentication services and private apps in your headquarters or data center.
Service connections process internal traffic, where no internet access is required. In some cases,
you might want to redirect internet-bound traffic to the data center. Traffic steering allows you
to redirect mobile user or remote network traffic to a service connection before being sent to the
internet.
You can use traffic steering with mobile user deployments, remote network deployments, or a
combination of both. Use traffic steering to direct internet-bound network traffic based on many

Prisma Access Administrator’s Guide (Panorama Managed) 486 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

criteria including IP addresses, Custom URL categories, service type (HTTP or HTTPS), User-ID,
Dynamic Address Groups (DAGs) and IP-based External Dynamic Lists (EDLs).
There are two action types supported with traffic steering:
• Forward to the target—Use the criteria in traffic steering rules to forward internet-bound
traffic through a target you create that uses one or more service connections.
• Forward to the internet—Use the criteria in traffic steering rules to directly forward traffic
from its source (mobile user location or remote network connection) to the internet, without
being forwarded to a service connection.
If you forward to a target, you can choose to create two types of target groups: dedicated and
non-dedicated.
• A service connection that is used only for traffic steering-related traffic is a dedicated service
connection. To set a service connection to be used as a dedicated service connection, select
Dedicated for Traffic Steering Only when you Configure Traffic Steering in Prisma Access in
Panorama.
You might want to configure a dedicated service connection if you use a third-party security
stack that is outside of your organization’s internal network to process traffic before it is sent
to a public SaaS application or the internet. Because the security stack is not a part of your
organization’s network, you don’t want this service connection to process any internal network
traffic.
• A service connection that is used for traffic steering and for standard service connection-
related traffic (such as traffic going to an authentication server in the data center) is a non-
dedicated service connection.
Setting a service connection as a dedicated service connection causes the following changes to
your deployment:
• The zone for all service connections associated with this target changes from Trust to Untrust.
Check your zone mapping and Configure Zone Mapping and Security Policies for Traffic
Steering Dedicated Connections to make sure that your network reflects this change.
• Service connections that are configured as dedicated service connections do not participate in
BGP routing, either internally or externally.
• If your dedicated service connection uses BGP, the BGP status shows as Not Enabled
when you open the status page (Panorama > Cloud Service > Status > Monitor > Service
Connection), select a region, then select the Status tab. To check the BGP status of a service
connection, check the service connections configuration page (Panorama > Cloud Services >
Configuration > Service Connection).
• By default, the service connections apply source NAT to the forwarded traffic. The source IP
address is the User-ID Agent Address of the service connection (Panorama > Cloud Services >
Status > Network Details > Service Connection > User-ID Agent Address), which is taken from
the Infrastructure Subnet (Panorama > Cloud Services > Status > Network Details > Service
Infrastructure).
You can disable source NAT and use your organization’s source IP addresses for the dedicated
service connection; to do so, select Disable Source NAT for Dedicated SC when you Add a
target in the Target Service Connections for Traffic Steering area.

Prisma Access Administrator’s Guide (Panorama Managed) 487 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Traffic Steering Requirements

Before you implement traffic steering in your Prisma Access deployment, make sure that your
network environment has the following infrastructure requirements:
• Prisma Access must be able to connect to the IPSec-capable CPE (such as a router or SD-WAN
device) that your organization uses to terminate the service connection, and the IP address for
the device must be reachable from Prisma Access.
You create a service connection using standard IPSec and IKE cryptographic profiles between
the stack location and Prisma Access. You can use static routes, BGP, or a combination or both
when you create a service connection and use traffic steering. If you use default routes with
traffic steering, Palo Alto Networks recommends that you use either BGP only or static routes
only. If you use static routing, specify the public IP address used by the organization’s CPE as
the Peer Address when you create an IKE gateway.
• Prisma Access might not match the first few packets of a URL from a URL category in a traffic
steering rule, which means that the first few packets of a network session (for example, a TCP
handshake) might not match the rule. Palo Alto Networks recommends that, for URLs you use
in traffic steering rules, you create a security policy rule to allow them through the Untrust
zone so that the handshake can complete when a new session begins.
• If you are using this configuration with a security stack, the stack location must be reachable
from the service connection by a standard IPSec tunnel configuration.
Use the following guidelines when configuring traffic steering:
• You can specify up to 1,000 URLs (aggregated) in a traffic steering configuration, including
regular and wildcard (*.example.com) URLs in custom URL categories.
• Prisma Access prepends an asterisk to URLs in custom URL categories, if you use this category
in a traffic steering rule. If you use the same URL category policies for both traffic steering
and other security policy rules, these changes apply to both the traffic steering rules and other
security policy rules.
If you have custom URL categories that are not used in traffic steering rules, Prisma Access
does not change the URLs in those categories.
• Use all lower-case URLs when you enter URLs in a custom URL category.
• You can configure a maximum of 100 traffic steering rules.
• If you have primary and backup tunnels configured, traffic steering using traffic steering rules
will not work after a failover from the primary (active) to the backup tunnel. Default Routes
With Prisma Access Traffic Steering works in a failover scenario with primary and backup
tunnels.

Default Routes with Traffic Steering Example

The following example shows a sample Prisma Access deployment the following components:
• Two Prisma Access mobile user locations; one in the United States (US) and one in Europe (EU).
• Two Prisma Access service connections; one in the US and one in the EU, with both data
centers sending default routes to the service connections (Accept Default Route over Service
Connections is enabled).

Prisma Access Administrator’s Guide (Panorama Managed) 488 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• Two data centers; one in the US and one in the EU.

Each data center has a 3rd-party security stack; for this reason, you want all internet-bound
traffic to go through the data center before egressing to the internet.
When a mobile user sends data center traffic, Prisma Access checks its routing tables, determines
the closest service connection, and forwards the traffic to that service connection. In the
following example, Prisma Access sends data center traffic from the mobile users in the US to
Service Connection and traffic from the mobile users in the EU to Service Connection 2.

Do not use service connections that are Dedicated for Traffic Steering Only with default
routes; dedicated service connections do not participate in BGP routing, so they cannot
receive BGP advertisements from the HQ or data center.

To enable default routes, select Accept Default Route over Service Connections when you
configure traffic steering settings. After you configure this setting and commit and push your
changes, Prisma Access sends internet-bound traffic over the service connections.

Default Routes with Traffic Steering Direct to Internet Example

The following example shows you using more granular control for external SaaS application-
bound traffic. In this case, you want to send Office 365 traffic to egress to the internet directly
from the mobile user location, instead of sending it to the data center for further processing. Use
traffic steering along with default routes for this configuration.

Prisma Access Administrator’s Guide (Panorama Managed) 489 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

To allow Prisma Access to route Office 365 traffic directly to the internet, perform the following
actions:
• Create an EDL (Object > External Dynamic Lists) with IP addresses that match the Office 365
addresses.
• Create a Custom URL category (Objects > Custom Objects > URL Category) with URLs that
match Office 365 URL.
• create Configure Traffic Steering in Prisma Access and specify the EDL and URL category you
created as destination match criteria with an Action of Forward to the internet.
This configuration sends Office 365 traffic directly to the internet, while other internet-bound
traffic is sent to the data center for further processing before egressing to the internet.

Default Routes with Traffic Steering and Dedicated Service Connection Example
In this example, in addition to the previous configuration, you have a third-party internet security
service, and you want to send traffic from box.com to be processed by the security service before
egressing to the internet. You do not want to send any other internet-bound traffic to the security
service; for this reason, you create a dedicated service connection for the box.com traffic. After
your configuration is complete, Prisma Access sends *.box.com destination traffic to the stack.

Prisma Access Administrator’s Guide (Panorama Managed) 490 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

To enable this deployment, you perform the following actions in the Traffic Steering tab:
• Create a Target Service Connection group that assigns one or more service connections to
the target and select Dedicated for Traffic Steering Only, which makes the target service
connection or connections dedicated.

If you create a target with more than one service connection, Prisma Access chooses
the best service connection to forward the internet-bound traffic.

Prisma Access Administrator’s Guide (Panorama Managed) 491 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• Create a traffic steering rule that forwards traffic to the URL. The following screenshot shows
the traffic destination being assigned a custom URL category that contains the URL *.box.com.

• Create an Action in the traffic steering rule of Forward to the target and specify the target
group name you created (dedicated in this case).

Prisma Access Traffic Steering Rule Guidelines

Traffic steering can process a wide variety of possible configurations; however, it is important to
understand how Prisma Access processes rules, so you can create rules are easy to maintain and
manage. To help you create the rules that work best for your deployment, follow these guidelines:
• Prisma Access evaluates rules in the order that you create them (from top to bottom). Specify
more specific rules at the top and more general rules at the bottom.

Prisma Access Administrator’s Guide (Panorama Managed) 492 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• Create multiple rules with fewer matching criteria, instead of creating fewer rules with multiple
types of criteria. Creating simpler rules both speeds up rule creation and makes it easier to
modify a rule.
• Since you cannot move a rule up or down in a list after you create it, carefully plan your rule
order before you create the rules.
• Rules that specify Any source address and User, Any source destination and URL Category,
and Any service are not supported. Use more specific rules; for example, specify a rule with
Any source or destination traffic and a service of service-http and service-https.
• If you are going to specify rules for users in the Source User field, make sure that Prisma
Access can distinguish between users if the same username is shared between users who
authenticate locally and users who authenticate using LDAP by authenticating LDAP users in
the format of domain/username and authenticating local users in the format of username
(without the domain name).
• If an EDL (type IP List) is used in a Traffic Steering Rule, and the EDL source URL of the EDL is
updated to a URL that is not accessible, Prisma Access may continue to use the cached IP list
from the previous URL.
• Prisma Access bypasses Traffic Steering for rules with a service type of HTTP or HTTPS if you
use an application override policy for TCP ports 80 and 443.
In addition, traffic steering does not work for URLs from URL categories referenced in the
traffic steering rule if you have configured an application override policy for TCP ports 80 or
443.
• You can specify destination IP addresses and URL categories in the same rule. If you do, Prisma
Access uses a logical OR to process the destination criteria in the rule, but processes the URLs
and URL category traffic based on TCP ports 80 and 8080 for HTTP and TCP port 443 for
HTTPS.
For a rule with IP addresses and URL categories, traffic matches the rule if either the IP address
or the URL category matches, but processes the URL category traffic based on ports 80, 443,
and 8080 only. Palo Alto Networks does not recommend creating a rule of this type; instead,
create simpler rules.
For example, you want to enforce the following rules for your network traffic:
• You have an internal HTTP server with an IP address of 10.1.1.1 in the data center, and you
want to direct internal HTTP and HTTPS traffic to this server. The IP address of the server is
10.1.1.1.
Traffic to this server should not go to the internet and should be processed internally;
therefore, choose a non-dedicated target for this traffic, because this type of target processes
both internal and internet-bound traffic.
• You want office365.com traffic to be routed directly to the internet.
• You want traffic from *.example.com or any traffic defined in a custom URL category of
custom-social-networking to be routed to a dedicated connection.
• You want any other HTTP and HTTPS traffic to use the same non-dedicated service
connection target as that used for the internal HTTP server.
For this example, create the rules from the most specific to the least specific, as shown in the
following screenshot. Do not add the rule that allows all HTTP and HTTPS traffic first, or Prisma

Prisma Access Administrator’s Guide (Panorama Managed) 493 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Access would direct all HTTP and HTTPS traffic to the non-dedicated connection without
evaluating any of the other rules.

Configure Zone Mapping and Security Policies for Traffic Steering Dedicated
Connections
If you create a target that uses a dedicated service connection, the zone for the dedicated
service connection changes from Trust to Untrust (non-dedicated service connection targets
do not change their zones). Since you cannot create zones or configure zone mapping for
service connections, you make zone mapping and security policy changes for dedicated service
connections to the mobile users and device groups instead. Complete the following steps to
configure zone mapping for dedicated connections.

These steps show a sample configuration; you can tailor this example to suit your
deployment.

STEP 1 | Select Network > Zones.

STEP 2 | Select the correct Template from the drop-down list (either Mobile_User_Template for
mobile users or Remote_Network_Template for remote networks).
If you have a mobile user and a remote network deployment, you need to perform these steps
twice; once in the Mobile_User_Template and once in the Remote_Network_Template.

STEP 3 | Add two zones for your trusted and untrusted zones.
This example creates two zones called Trust and Untrust.

Prisma Access Administrator’s Guide (Panorama Managed) 494 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 4 | Create default policies for the zones you created.

1. Select Policies > Security > Post Rules.
2. Select the correct Device Group from the drop-down list (either
Mobile_User_Device_Group for remote networks or Remote_Network_Device_Group
for mobile users).
If you have a mobile user and remote network deployment, you need to perform
these steps twice; once in the Mobile_User_Device_Group and once in the
Remote_Network_Device_Group.
3. Add a default policy to use for Trust zone-to-Trust zone traffic.
This policy allows Any traffic to pass for all Source, User, Destination, Application, and
Service/URL Category traffic.

4. Add a default policy to use for Trust zone-to-Untrust zone traffic, using the same
parameters you used for the Trust-to-Trust policy.
When complete, you have two security policies, one for Trust-to-Trust traffic and one
for Trust-to-Untrust traffic.

Prisma Access Administrator’s Guide (Panorama Managed) 495 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 5 | Define Zone Mapping for the remote networks, mobile users, or both, as required for your
deployment.
1. Set the zone mapping for the remote networks, mobile users, or both.
• For mobile users, select Panorama > Cloud Services > Configuration > Mobile Users.
• For remote networks, select Panorama > Cloud Services > Configuration > Remote
Networks.
2. Click the gear icon next to Zone Mapping to edit the settings.

3. Set the Zone Mapping for your deployment, moving the zone for trusted traffic to the
Trusted Zones and the zone for untrusted traffic to the Untrusted Zones; then, click OK.

Configure Traffic Steering in Prisma Access

Traffic steering allows you to configure Prisma Access Access to create traffic steering rules to
specify targets for internet-bound traffic from mobile users and remote network connectons. You
can specify the traffic to be redirected to a service connecton before sending to the internet, or
you can specify the traffic to directly egress to the internet. Configure traffic steering for your
Prisma Access deployment by completing the following steps.
STEP 1 | Onboard your service connections, mobile users and remote networks, as applicable to your
deployment.

STEP 2 | Select Panorama > Cloud Services > Configuration > Traffic Steering.

STEP 3 | (Optional, mobile user deployments only) Allow Prisma Access to accept and install the
default route advertised over one or more service connections from the CPE by clicking
the gear icon to open the Settings and selecting Accept Default Route over Service
Connections.
Default routes have guidelines that you must follow when using them; for example, default
routes are supported for mobile user deployments only and have no effect on remote network

Prisma Access Administrator’s Guide (Panorama Managed) 496 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

deployments. Be sure to review these guidelines before implementing default routes with
traffic steering.

STEP 4 | (Optional) Create a target group and assign a service connection to it.
1. In the Target Service Connections for Traffic Steering area, Add a group and give it a
Group Name.
2. Add a Target for the traffic, specifying the Service Connection to use with the target;
then, click OK.
Palo Alto Networks does not recommend using multiple service connections (whether
dedicated or non-dedicated) in a target service connection group that is referenced in a
traffic steering rule. In addition, a given service connection can only exist in one target
and you cannot add a single service connection to two different targets.
3. Choose whether to make the service connections associated with this target a dedicated
service connection.
• You can use a dedicated service connection to steer traffic to a third-party security
stack or cloud that is not on your premises and does not need to participate in
routing. To set a service connection to be used as a dedicated service connection,
select Dedicated for Traffic Steering Only.

Dedicated service connections change their zones.

• Deselect Dedicated for Traffic Steering Only if you will send both normal service
connection-related and traffic steering traffic through the service connection; with
this choice, the zone for the service connection remains as Trust.
4. Choose whether to enable or disable source NAT.
To disable source NAT for Dedicated service connections, select Disable Source NAT for
Dedicated SC. Source NAT is enabled by default (the check box is deselected).
If you disable source NAT, Prisma Access uses your organization’s source IP addresses
for the dedicated service connection. If you enable source NAT, Prisma Access uses the
EBGP Router address of the service connection (Panorama > Cloud Services > Status >

Prisma Access Administrator’s Guide (Panorama Managed) 497 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Network Details > Service Connection > EBGP Router) as the source IP address, even
after the traffic egresses from the dedicated service connection.

Prisma Access Administrator’s Guide (Panorama Managed) 498 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 5 | Create rules for the target you created and apply them to the target.
1. In the Traffic Steering Rules area, Add a traffic steering rule.
2. in the General tab, Name the traffic steering rule.
3. In the Source tab, specify rules for source traffic.
• In the Source Address field, specify one or more of the following objects, or select
Any to have traffic from any source go to this target:
• An IP address
• An address object that you created in Panorama (Objects > Addresses)
• A Dynamic Address Group (DAG)
• An External Dynamic List (EDL) using IP addresses or URLs
• In the Source User field, specify rules for source user traffic. You can specify the
following user information:
• Users
Enter users in either the domain/user or the user@domain format.
• User groups
Use full distinguished names (DNs) when entering user groups.
• Users configured on Panorama (Device > Local User Database > Users)
• User groups configured on Panorama (Device > Local User Database > User
Groups)
If you use address objects, DAGs, EDLs, users, or user groups, specify them as Shared to
share them with all device groups in Prisma Access. In addition, do not enter 0.0.0.0/0 in
address objects, DAGs, or EDLs; instead, enter 0.0.0.0/0 directly in the rule.

Prisma Access automatically populates users from the mobile users device group
only.
4. In the Destination tab, specify the following values:
• In the Destination area, specify one of the following criteria, or select Any to have
traffic processed by the rules in the URL Category field:
• An IP address or prefix
• An address object that you created in Panorama (Objects > Addresses)
• A Dynamic Address Group (DAG)
• An IP address-based External Dynamic List (EDL)

Do not enter 0.0.0.0/0 in address objects, DAGs, or EDLs; instead, enter

0.0.0.0/0 directly in the rule.

Leave Any selected to pass all traffic to be processed by the rules in the URL
Category area. If you specify rules in the Destination, and URL Category areas,
Prisma Access processes the rules in the Destination category first.

Prisma Access Administrator’s Guide (Panorama Managed) 499 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• In the URL Category field, enter a custom URL category (Objects > Custom Objects >
URL Category) When you create a custom URL category, enter URLs in all lower case.
Traffic steering supports custom URL and predefined URL categories.
You can use wildcards with the URLs in URL categories. The following wildcard
formats are supported:
• *.example.com
• *.fqdn.example.com
The following formats are not supported:
• *
• *.*
• *example.com
• example.com/ (trailing slashes in URLs are not supported in URL categories that
are used with Traffic Steering)
• example.com/path (only domain names are supported)
• *fqdn.example.com
• fqdn.example.*
URLs in custom URL categories use the same URL pattern matching as that used by
next-generation firewalls.
Use the following guidelines when configuring destination options:
• If you specify a URL category, Prisma Access only matches HTTP and HTTPS traffic,
even when service is set to Any.
• Do not create a custom URL category with a type of Category Match.
• Do not create a custom URL category with the name Custom_URL_Category_TFR
because, for deployments that are migrated from Prisma Access 1.7 to 2.0, URLs
entered in the URL area from 1.7 are moved to a custom URL category named

Prisma Access Administrator’s Guide (Panorama Managed) 500 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Custom_URL_Category_TFRnumber, where number is a number appended to the

custom URL category.

5. In the Service tab, specify a service type.

Specify service-http to forward HTTP traffic and specify service-https to specify HTTPS
traffic. Select Any to forward traffic of any service type.
6. In the Action tab, select the Target Group Name that you want to apply to the traffic
steering rule.
7. Forward traffic to the specified service connection target, or send the traffic directly to
the internet without going through the service connection.
• To have Prisma Access forward traffic to a service connection target, select Forward
to the target; then select the Target Group Name.
• To have Prisma Access forward traffic directly to the internet without first sending it
to a service connection, select Forward to the internet.

Prisma Access Administrator’s Guide (Panorama Managed) 501 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

8. Click OK to save your changes.

STEP 6 | Optional Specify additional traffic steering rules.

Prisma Access processes multiple rules in the order that you create them (from top to bottom).

STEP 7 | Commit and push your changes to make them active in Prisma Access.
1. Select Commit > Commit and Push and Edit Selections in the Push Scope.
2. Select Prisma Access, then select Service Setup, Remote Networks, and Mobile Users.

3. Click OK to save your changes to the Push Scope.

4. Commit and Push your changes.

Routing for Service Connection Traffic

Where Can I Use This? What Do I Need?

• Panorama Managed Prisma Access Prisma Access license

Prisma Access uses BGP for dynamic routing, and uses BGP path selection to install routes in the
route table. When Prisma Access routes traffic to your headquarters or data center using service
connections, it uses routing methods that direct that traffic effectively. Prisma Access uses a
default routing model that was designed to fit the majority of network deployments; however,
not all organization’s networks are the same. To fit a wider range of deployments, Prisma Access
allows you choose another mode for service connection routing.

Changing the Prisma Access service connection routing method requires a thorough
understanding of your organization’s topology and routing devices, along with an
understanding of how Prisma Access works as described in this section. Read this section
carefully before changing the routing method from the default setting.

Prisma Access Administrator’s Guide (Panorama Managed) 502 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Prisma Access supports static routing and dynamic routing using BGP for service connections
and remote network connections. When you use BGP routing for your connections, your
organization’s network learns BGP information from Prisma Access.
Before you decide which service connection routing to use, you should understand how Prisma
Access routes traffic between mobile users, remote networks, and service connections, because
the routing used by mobile user traffic and remote network traffic between service connections is
different.
Mobile User-service connection routing—The mobile user connection forms an IPSec tunnel
with the nearest service connection. Prisma Access uses iBGP for internal routing and eBGP to
peer with the customer premises equipment at the data center. The following diagram shows
mobile users in Regions 1 and 2 being routed to the respective service connections in that region.
Mobile users in Region 1 are accessing applications A and B located at Data Center 1. If your
organization’s network uses BGP routing for their service connections and a service connection
experiences an ISP failure at Data Center 1, Prisma Access detects the failure and routes the
traffic for applications A and B to Data Center 2 after BGP convergence, providing redundancy to
your network’s data centers.

Prisma Access uses the following timing with BGP when it detects a failure: If you
configure BGP routing and have enabled tunnel monitoring, the shortest default hold
time to determine that a security parameter index (SPI) is failing is the tunnel monitor,
which removes all routes to a peer when it detects a tunnel failure for 15 consecutive
seconds. In this way, the tunnel monitor determines the behavior of the BGP routes. If you
do not configure tunnel monitoring, the hold timer determines the amount of time that the
tunnel is down before removing the route. Prisma Access uses the default BGP HoldTime
value of 90 seconds as defined by RFC 4271, which is the maximum wait time before
Prisma Access removes a route for an inactive SPI. If the peer BGP device has a shorter
configured hold time, the BGP hold timer uses the lower value. When the secondary tunnel
is successfully installed, the secondary route takes precedence until the primary tunnel
comes back up. If the primary and secondary are both up, the primary route takes priority.

Remote Network-service connection routing—Prisma Access creates a full mesh network with
other remote networks and service connections. As with mobile users, Prisma Access uses iBGP
for its internal routing and eBGP to peer with customer premises equipment to exchange routes.

Prisma Access Administrator’s Guide (Panorama Managed) 503 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

If a user in Branch 1 is accessing application A from Data Center 1 in your organization’s data
center and the link between Branch 1 and Data Center 1 goes down, Prisma Access routes the
traffic for application A to Data Center 2 after BGP convergence.

After you understand Prisma Access service connection routing and how it relates to your
network, you can choose one of the following routing modes for service connections:
• Default routing—This is the default routing model that Prisma Access uses.
Use this routing mode if you want Prisma Access to use BGP best path-selection mechanisms
without adjusting any of the BGP attributes. In this mode, Prisma Access will honor any
attribute advertised by the customer premises equipment (CPE).
• Hot Potato routing—Prisma Access hands off the traffic as quickly as it can to your
organization’s network.
Use this routing method if you want your organization’s network to perform the majority of
routing decisions.

Prisma Access Default Routing

The following figure shows an example of Prisma Access routing service connection traffic in
default routing mode. The organization’s network has three separate networks in three data
centers and does not have a backbone connecting the networks. In default routing mode, mobile
user pools are advertised equally on the three networks, as shown at the bottom of the figure.
Note that, when Prisma Access advertises mobile user routes, it divides the subnets into Class
C /24 address blocks before advertising them; thus, it advertises the /20 mobile user subnets in
chunks of /24 as prefixes are consumed by the gateways.
Make a note of how Prisma Access uses BGP route advertisements:
• Prisma Access does not adjust the default BGP attributes for mobile user advertised routes
(Prisma Access adds its AS number to the route advertisements).
• Prisma Access advertises mobile user routes in blocks of /24 subnets and adds BGP community
values in the routes it advertises through the service connection. The following figure shows
a mobile user deployment with three service connections and three different IP address
blocks specified for the mobile user IP address pool: 192.168.64.0/20 for the Asia,

Prisma Access Administrator’s Guide (Panorama Managed) 504 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Australia & Japan region, 192.168.72.0/20 for the Africa, Europe & Middle East region, and
192.168.48.0/20 for the North America & South America region. Prisma Access divides
these routes into block of /24 and advertises them with an AS number of 65534, but also
appends the BGP community values to the advertisements (Z for Asia, Y for EU, and X for US).
Those routes are shown in the middle of the figure. In this way, you can differentiate service
connections in your network, even though Prisma Access assigns the same AS number to them.

You can view the community string by selecting Panorama > Cloud Services > Status > Network
Details > Service Connection > Show BGP Status and find the Community field in the Peer tab.

The following figure shows a more common network with a full-mesh eBGP backbone. The figure
shows the routes that Prisma Access has learned from your organization’s network on the top
right. Note the extra routes that Prisma Access has learned through the Prisma Access backbone
(iBGP) and your organization’s backbone (eBGP).
For traffic between mobile users in the North America & South America region (US in the
diagram) and the data center in your organization’s Africa, Europe & Middle East region (EU in the
diagram), Prisma Access chooses the path through the EU service connection because it prefers
routes with a shorter AS-PATH.

Prisma Access Administrator’s Guide (Panorama Managed) 505 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

In deployments with a full-mesh eBGP backbone, asymmetry can arise when Prisma Access
cannot reach a particular data center due to an ISP/CPE failure at the customer’s data center.
The following figure shows what could happen when the link to the EU service connection goes
down. Your network detects the link failure and builds a new route table for AS 200. Traffic from
the US service connection to AS 200 uses the path through AS 100 because the eBGP route
for your backbone between AS 200 and AS 100 is preferred to the iBGP route between service
connections EU and US. However, return traffic is not guaranteed through the same path because
the on-premises CPE can choose either path (shown in red) to return the traffic.

The previous examples show a network whose routes have not been aggregated (that is, you
have not performed route summarization before you send the BGP route advertisements to
Prisma Access). The following example shows a network that summarizes its routes to 10.0.0.0/8
before sending to Prisma Access. If you select default routing, this configuration can lead to
asymmetric routing issues, because Prisma Access cannot determine the correct return path from
the summarized routes.

If your Prisma Access deployment has Remote Networks, Palo Alto Networks does not
recommend the use of route summarization on Service Connections. Route summarization
on service connections is for Mobile Users deployments only.

Prisma Access Administrator’s Guide (Panorama Managed) 506 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

If you use route aggregation for mobile users, we strongly recommend that you enable hot
potato routing instead of default routing, where Prisma Access hands off the traffic as quickly as
possible to your organization’s network; in addition, we recommend that you select a Backup SC
as described in the following section for each service connection to have a deterministic routing
behavior.

Prisma Access Hot Potato Routing

When you select Hot Potato Routing, Prisma Access egresses the traffic bound to service
connections/data centers from its internal network as quickly as possible.
With hot potato routing, Prisma Access prepends the AS path (AS-PATH) to the BGP prefix
advertisements sent from gateways. This prepending is performed when the prefixes are
advertised out of the service connection to your organization’s on-premises CPE. Prisma Access
prepends the AS-PATHs so that your CPE gives the correct preference to the primary and
secondary tunnels, so that if the primary tunnel goes down, your CPE chooses the secondary
tunnel as the backup.
If you specified a different IP address for the secondary (backup) BGP peer, Prisma Access adds
more prepends based on the tunnel type, as shown in the following table.

Prefix Type Service Connection Number of As-Path Total AS-PATHs

Tunnel Type Prepends Seen on the CPE

Gateway prefixes Primary or Secondary 0 1

from primary service tunnel with the same
connection BGP peer IP address

Gateway prefixes Primary or Secondary 3 4

from backup service tunnel with the same
connection BGP peer IP address

Gateway prefixes Primary or Secondary 6 7

from all other service tunnel with the same
connections BGP peer IP address

Gateway prefixes Secondary tunnel with 1 2

from primary service a different BGP peer IP
connection address

Prisma Access Administrator’s Guide (Panorama Managed) 507 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Prefix Type Service Connection Number of As-Path Total AS-PATHs

Tunnel Type Prepends Seen on the CPE

Gateway prefixes Secondary tunnel with 4 5

from backup service a different BGP peer IP
connection address

Gateway prefixes Secondary tunnel with 7 8

from all other service a different BGP peer IP
connections address

In hot potato routing mode, Prisma Access allows you to specify a backup service connection
during onboarding. Specifying a Backup SC informs Prisma Access to use that service connection
as the backup when a service connection link fails.
The following figure shows a hot potato routing configuration for traffic between the US service
connection and AS 200, with the EU service connection configured as the Backup SC of the
US connection. Using hot potato routing, Prisma Access sends the traffic from its closest exit
path through the US service connection. The return traffic takes the same path through AS100
because this path has a shorter AS-PATH to the mobile user pool in the US location. Prisma
Access prepends the AS-PATH to its prefix advertisements depending on whether the tunnel is a
primary tunnel, a backup tunnel, or not used for either primary or backup.

Because you have set up a backup service connection, if the link to the US service connection
goes down, hot potato routing sends the traffic out using its shortest route through the EU
service connection. This routing scenario also applies to networks that use route aggregation.

Prisma Access Administrator’s Guide (Panorama Managed) 508 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

You can also use backup service connections for multiple service connections in a single region.
The following figure shows a Prisma Access deployment with two service connections in the
North America region. In this case, you specify a Backup SC of US-E for the US-W service
connection, and vice versa, to ensure symmetric routing.

Configure Routing Preferences

Where Can I Use This? What Do I Need?

• Prisma Access (Panorama Managed) Prisma Access license

To enable routing preferences, complete the following steps.

To configure these routing preferences, you must use BGP routing and not static routing
for your service connections.

STEP 1 | Configure your service connection.

STEP 2 | (Optional) Select the routing to use for your service connections.
1. From the Panorama that manages Prisma Access, go to Panorama > Cloud Services >
Configuration > Service Setup and click the gear to edit the Settings.
2. In the Advanced settings, select your Routing Preference (either Default or Hot Potato).

Prisma Access Administrator’s Guide (Panorama Managed) 509 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 3 | (Optional, Hot Potato Routing Deployments Only) To specify a preferred service connection
to use if a link fails, configure a Backup SC when you configure a service connection.
You can select any service connection that you have already added. Prisma Access uses
the Backup SC you select as the preferred service connection in the event of a link failure.
Selecting a backup service connection can prevent asymmetric routing issues if you have
onboarded more than two service connections. This choice is available in Hot potato routing
mode only.
1. Go to Panorama > Cloud Service > Configuration > Service Connection
2. Select the service connection to configure, or Add a new one.
3. Select a service connection to use as the preferred backup (Backup SC).

STEP 4 | Commit your changes to Panorama and push the configuration changes to Prisma Access.
1. Click Commit > Commit and Push.
2. Edit Selections and, in the Prisma Access tab, make sure that Service Setup is selected in
the Push Scope, then click OK.

3. Click Commit and Push.

Prisma Access Administrator’s Guide (Panorama Managed) 510 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 5 | Verify that your service connection is up by selectin Panorama > Cloud Services > Status >
Status and checking that its Status is OK.
The Deployment Status area allows you to view the progress of onboarding and deployment
jobs before they complete, as well as see more information about the status of completed jobs.

If the status is not OK, hover over the Status icon to view any errors.
To see a graphical representation of the service connection along with status details, select
Service Connection on the Monitor tab.

Select a region to get more detail about that region.

Prisma Access Administrator’s Guide (Panorama Managed) 511 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Click the tabs below the map to see additional information about the service connections.
Status tab:
• Location—The location where your service connection is deployed.
• Remote Peer—The corporate location to which this s service infrastructure is setting up an
IPSec tunnel.
• Allocated Bandwidth—The number of service connections you have allocated multiplied by
300 Mbps.
This number does not reflect the available service connection bandwidth.

While each service connection provides approximately 1 Gbps of throughput, the

actual throughput is dependent on several factors, including:
• Traffic mix (for example, frame size)
• Latency and packet loss between the service connection and the headquarters
location or data center
• Service provider performance limits
• Customer termination device performance limits
• Other customer data center traffic
• ECMP—If you have equal cost multipath (ECMP) configured for this service connection.
Since ECMP is not used for service connections, this status is Disabled.
• Config Status—The status of your last configuration push to the service. If the local
configuration and the configuration in the cloud match, the Config Status is In sync. If
you have made a change locally, and not yet pushed the configuration to the cloud, this
may display the status Out of sync. Hover over the status indicator for more detailed

Prisma Access Administrator’s Guide (Panorama Managed) 512 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

information. After committing and pushing the configuration to Prisma Access, the Config
Status changes to In sync.
• BGP Status—Displays information about the BGP state between the firewall or router at
your corporate/headquarters location and Prisma Access where the service connection is
established. Although you might temporarily see the status pass through the various BGP

Prisma Access Administrator’s Guide (Panorama Managed) 513 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

states (Idle, Active, Open send, Open pend, Open confirm, most commonly, the BGP status
shows:
• Connect—The router at your data center/headquarters is trying to establish the BGP
peer relationship with Prisma Access.
• Established—The BGP peer relationship has been established.
This field will also show if the BGP connection is in an error state:
• Warning—There has not been a BGP status update in more than eight minutes. This may
indicate an outage on the firewall.
• Error—The BGP status is unknown.
• Tunnel Status—The operational status of the connection between Prisma Access and your
service connection.
Statistics tab:
• Location—The location where your service connection is deployed.
• Remote Peer—The corporate location to which the service connection is setting up an IPSec
tunnel.
• Ingress Bandwidth (Mbps)—The bandwidth from the HQ/data center location to Prisma
Access.
• Ingress Peak Bandwidth (Mbps)—The peak load from the HQ/data center location into the
cloud service.
• Egress Bandwidth (Mbps)—The bandwidth from Prisma Access into the HQ/data center
location.
• Egress Peak Bandwidth (Mbps)—The peak load from Prisma Access into the HQ/data
center location.
• QoS—Select this button to display a graphic chart that shows a real-time and historical QoS
statistics, including the number of dropped packets per class. This chart displays only for
service connections or remote network connections that have QoS enabled.
If you configured BGP, you can check its status by selecting Panorama > Cloud Services >
Status > Network Details > Service Connection > Show BGP Status.

The BGP Status dialog displays. This table provides you with the following information:
• Peer—Routing information for the BGP peer, including status, total number of routes,
configuration, and runtime statistics and counters. The total number of routes display in the
bgpAfiIpv4-unicast Counters area, in the Incoming Total and Outgoing Total fields.

Prisma Access Administrator’s Guide (Panorama Managed) 514 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• Local RIB—BGP routes that Prisma Access uses locally. Prisma Access selects this
information from the BGP RIB-In table, which stores the information sent by neighboring
networking devices, applies local BGP import policies and routing decisions, and stores the
Local RIB information in the Routing Information Base (RIB).
Note that only the first 256 entries are shown. To view additional entries, enter a subnet or
IP address in the Filter field and click Apply Filter to view a subset of the routing entries up
to a maximum of 256.

• RIB Out—Routing information that Prisma Access advertises to its peers through BGP
update messages.

Create a High-Bandwidth Network Using Multiple Service

Connections
If you have a headquarters or data center location that requires additional service connection
bandwidth, you can configure multiple service connections to that location.
Each Prisma Access service connection is not bandwidth capped, but Palo Alto Networks expects
that each service connection can provide approximately 1 Gbps of throughput. While this
bandwidth is usually sufficient to access internal resources in a headquarters or data center
location, you might have a deployment that requires additional bandwidth; for example, if you are
hosting an internal or private SaaS application in a data center.
To create a high-bandwidth service connection to a headquarters or data center site, you onboard
the site using multiple service connections to the same Prisma Access location. The following
diagram shows a Prisma Access remote network deployment with a headquarters or data center
site that has two service connections from the same Prisma Access location, effectively providing
2 Gbps of bandwidth between the site and the Prisma Access location.
In addition to the service connections being deployed for high-bandwidth access, the diagram
shows another set of service connections. These service connections provide normal routing
functions for Prisma Access (in this diagram, they provide internal routing access between
the remote network connections and the high-bandwidth service connections). Palo Alto
Networks recommends that, when you deploy a high-bandwidth connection, you reserve service
connections to provide access to the resource in the headquarters or data center location only,
and deploy additional service connections to use for internal routing between remote networks,
mobile users, and the resources in the data center.

Prisma Access Administrator’s Guide (Panorama Managed) 515 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Each service connection is active and has its own Service IP Address; you use that address
to terminate the IPSec tunnel for each service connection. Prisma Access does not limit the
maximum number of service connections you can onboard to a single headquarters or data center
remote network location.

While each service connection provides approximately 1 Gbps of throughput, the actual
throughput is dependent on several factors, including:
• Traffic mix (for example, frame size)
• Latency and packet loss between the service connection and the headquarters location
or data center
• Service provider performance limits
• Customer termination device performance limits
• Other customer data center traffic

Create a High-Bandwidth Connection to a Headquarters or Data Center Location

To configure multiple service connections to a single headquarters or data center location,
complete the following steps.
The steps in this section use a deployment example as shown in the following diagram. In this
example, the London headquarters location connects to two different service connections
(London 1 and London 2) using two different IPSec tunnels that are terminated on two different
customer premises equipment (CPE) interfaces (tunnel.1 and tunnel.2).

Prisma Access Administrator’s Guide (Panorama Managed) 516 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

This example, and the steps in this section, use a next-generation firewall to terminate the service
connections on the CPE; however, you can use any CPE that supports symmetric routing and PBF
or policy-based routing as the CPE.

Use these steps for guidance; each use case could require additional design and planning
that are beyond the scope of this document.

STEP 1 | Before you deploy multiple service connections from a single Prisma Access location to a
single site, make sure that your network has the following prerequisites:
• You must divide the subnets in the headquarters or data center location and advertise a
unique subnet on each service connection.
• Your customer premises equipment (CPE) must support, and you must be able to configure,
the following networking features:
• Policy-based forwarding (PBF) or policy-based routing—Your CPE must be able to
selectively pick a specific path for a specific local source IP address and subnet.
• Symmetric return—You must be able to configure your CPE to ensure symmetric traffic
flows to and from a specific IP address and subnet, and configure symmetric return for
failover tunnels if one of the tunnels goes down.

STEP 2 | Create the service connections and establish connectivity for the IPSec tunnels used for the
service connections.
1. On the Panorama that manages Prisma Access, Create a service connection, including
creating a new IPSec Tunnel configuration, IKE Gateway, IPSec Crypto Profile, and
Tunnel Monitoring settings.

Prisma Access offers predefined IPSec templates that you can use to simplify
the IPSec tunnel creation process.
2. Find the IP address to use as the remote side of the IPSec tunnel from your CPE to
Prisma Access by selecting Panorama > Cloud Services > Status > Network Details,

Prisma Access Administrator’s Guide (Panorama Managed) 517 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

clicking the Service Connection radio button, and noting the Service IP Address for the
site.

3. On your CPE, create an IPSec tunnel to the service connections

1. Verify that the IKE and IPSec tunnels use the same cryptographic profiles for
authentication and encryption between the peers.
2. Use the Service IP Address as the peer address for the tunnel.
If you use a next-generation firewall as the CPE, select Network > IPSec Tunnels and
create two tunnels for the service connections (tunnel.1 and tunnnel.2 in the following
screenshot).

STEP 3 | Create virtual router settings for the CPE.

You create BGP routing instances that advertise one subnet on one tunnel and the other
subnet on another tunnel, which ensures load balancing on the two active tunnels.
If you are using a next-generation firewall as the CPE, select Network > Virtual Routers, Add
virtual router settings, then Add a BGP Peer Group for each tunnel, specifying the following
settings:
• Specify a Router ID and AS Number of the CPE router (10.177.177.20 and 65517,
respectively, in this example).
• Specify the EBGP Router address of the service connections (Panorama > Cloud Services
> Status > Network Details > Service Connection > EBGP Router) as the Peer Address

Prisma Access Administrator’s Guide (Panorama Managed) 518 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

for the service connections (10.0.2.12 for Service Connection 1 and 10.0.2.6 for Service
Connection 2 in this example).
• For the Local Address, you can specify the loopback address of the CPE (192.168.177.20 in
this example).

STEP 4 | Create a summarized subnet for the IP addresses used for both tunnels.
Providing a summarized subnet guarantees redundancy. When both tunnels are up, the traffic
uses the most specific routes to reach their destination; for example, 192.168.171.0/24
uses tunnel.1 to reach its destination. Adding a summarized subnet that covers all advertised
subnets (192.168.168.0/21 in this example) ensures that traffic from 192.168.171.0/24 is

Prisma Access Administrator’s Guide (Panorama Managed) 519 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

reachable from tunnel.2 if tunnel.1 goes down and traffic from 192.168.172.0/24 is reachable
from tunnel.1 if tunnel.2 goes down.
If you are using a next-generation firewall as the CPE, complete the following steps.
1. Continue to modify the virtual router profile and Add route aggregation parameters
(Network > Virtual Routers > BGP > Aggregate).
2. Enter summary subnets for the subnets you are advertising for the service connections.
In this example, enter a Prefix of 192.168.168.0/21, which summarizes the two data
center subnets.

3. Enter Export settings to ensure that the tunnels advertise the correct subnets.
In this example, you specify an Action of deny and allow for the subnets so that the
first subnet (192.168.171.0/24) is reachable from tunnel.1 and the second subnet
(192.168.172.0/24) is reachable from tunnel.2.

Prisma Access Administrator’s Guide (Panorama Managed) 520 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 5 | (Deployments with more than two service connections only) If you require more than
two service connections to connect the users to private resources for more than 2 Gbps
bandwidth, add AS-PATH prepends for the exported routes so that the service connections
use symmetric routing to and from the data center in the event of a failover. See Configure
More than Two Service Connections to a Headquarters or Data Center Location for details.

STEP 6 | To ensure symmetric return (to make sure that traffic from 192.168.171.0/24 always uses
tunnel.1 and traffic from 192.168.172.0 always uses tunnel.2), enter PBF or policy-based
routing rules.
By default, BGP installs routes in the routing table for all different destinations regardless of
the preferred tunnel. The following screenshot shows that BGP advertises all destinations from

Prisma Access Administrator’s Guide (Panorama Managed) 521 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

the 192.168.168.0/21 subnet for tunnel.2, which might cause asymmetric routing for traffic
from 192.168.171.0/24.

To ensure symmetric routing, configure a set of PBF or route-based forwarding rules. If you
are using a next-generation firewall as the CPE, complete the following steps.
1. Select Policies > Policy Based Forwarding and Add a PBF policy rule.

2. Select Source and Add a Source Address to use for the PBF.
In this case, you want to create a PBF for tunnel.1, so you enter the 192.168.171.0/24
subnet.

3. Select Destination/Application/Service and select Any Destination Address and Any

application.

Prisma Access Administrator’s Guide (Panorama Managed) 522 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

4. Select Forwarding and specify the following parameters; then, click OK:
• Select an Action of Forward.
• Select an Egress Interface of the tunnel to which you want to forward the IP subnet
(tunnel.1 in this case).
• Select Monitor and select the following monitoring profiles:
• Select a Profile of default.
• Select Disable this rule if nexthop/monitor ip is unreachable.
• Specify an IP Address of the service connection’s EBGP Router address (Panorama
> Cloud Services > Status > Network Details > Service Connection > EBGP
Router).
Enabling monitoring and selecting the EBGP router address of the service connection
ensures that, if tunnel.1 goes down, the firewall disables the PBF policy and routes
the traffic on the tunnel that is still up (tunnel.2).

5. Repeat Step 6, substituting the EBGP Router address of Service Connection 1 with
the EBGP Router address of Service Connection 2 and the subnet of tunnel.1 with the
subnet of tunnel.2.
When complete, you have two PBF policies, one for tunnel.1 and one for tunnel.2.

Prisma Access Administrator’s Guide (Panorama Managed) 523 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 7 | Select Network > Virtual Routers > Static Routes and assign the EBGP Router address of
Service Connection 1 to the Interface of tunnel.1; then, assign the EBGP Router address of
Service Connection 2 to the Interface of tunnel.2
Entering specific static routes for each of the router BGP addresses ensures that tunnel
monitoring functions correctly, because the EBGP Router IP address of Service Connection
1 is reachable only by tunnel.1 and the EBGP Router IP address of Service Connection 2 is
reachable only by tunnel.2.

Configure More than Two Service Connections to a Headquarters or Data Center

Location
When you use two tunnels for a high-bandwidth service connection, there is only one traffic path
left available in case of a tunnel failure, which simplifies the configuration of a failover path. If you
use more than two connections for a high-bandwidth connection, you need to perform additional
configuration to ensure a consistent behavior for tunnel failovers.
Because you use a summarized subnet for tunnel failover, you need to explicitly state the service
connection tunnel to use if a failover occurs. Since BGP routing chooses the shortest number of
AS-PATHs for a route, you can prepend AS-PATHs to routes to have BGP prefer a tunnel in the
case of a failover.
The following example shows routing tables for a high-bandwidth service connection using three
service connections. If all three tunnels are up, Prisma Access uses the more specific routes
to reach the subnets in the headquarters or data center location. Since the user is accessing a
resource in the 192.168.172.0/24 subnet, the service connection closest to the mobile user
checks its routing table and selects Tunnel 2 as the path to the data center resource.

Prisma Access Administrator’s Guide (Panorama Managed) 524 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

If Tunnel 2 goes down, the more specific route to the resource in the 192.168.172.0/24
subnet is not available, so the service connection closest to the user uses the summarized
192.168.168.0/21 subnet. You have configured only one AS-PATH prepend for Service
Connection 1; therefore, Prisma Access chooses Tunnel 1 as the failover path because it has
fewer AS-PATH prepends.

To add prepends to routes if you are using a next-generation firewall as the CPE, complete the
following task.
STEP 1 | Select the virtual router BGP export profiles (Network > Virtual Routers > BGP > Export).

STEP 2 | Modify the export rule you created when you configured the service connections that has an
Action of Allow.

Prisma Access Administrator’s Guide (Panorama Managed) 525 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 3 | In the AS Path area, add a Prepend, then enter the number of AS-PATH prepends to add (2
in this example).

STEP 4 | Repeat Steps 2 and 3 for each export rule that has an Action of Allow, adding AS-PATH
prepends to match the failover scenarios you have planned for your deployment.
In the examples used in this section, you add an AS-PATH prepend of 1 for the tunnel to the
data center location for Service Connection 1 (tunnel.1), an AS-PATH prepend of 2 for the
tunnel used for Service Connection 2 (tunnel.2), and an AS-PATH prepend of 3 for the tunnel
used for Service Connection 3 (tunnel.3).
When complete, this example uses the following tunnels in the even of a failover:
• If tunnel.2 or tunnel.3 goes down, the traffic for the corresponding subnet fails over to
tunnel.1, which has the shortest advertised AS-PATH.
• If tunnel.1 goes down, the traffic for its subnet (192.168.171.0/24) fails over to tunnel.2,
which has the shortest advertised AS-PATH.

STEP 5 | Add backup PBF or policy-based routing policies to ensure symmetric return traffic in the
event of a tunnel failure.
While the AS-PATH prepends ensure that the traffic from Prisma Access to the data center
uses a specific tunnel in the event of a failover, you must also ensure a symmetric return path
for the traffic from the data center to Prisma Access. To ensure symmetric return, use PBF
or policy-based routing policies that mirror the failover scenarios you created for traffic from
Prisma Access to the data center.
In this example, for tunnel.1 traffic that has a source IP of 192.168.171.0/24, you create a
backup PBF Policy that forces return traffic to use tunnel.2 in the event of a failover. The first
PBF rule becomes disabled if the tunnel monitor IP address is not reachable; when this failover
occurs, the CPE (a next-generation firewall in this example) evaluates the next rule in the list.

You then add more PBF rules to match the failover scenarios you created for traffic from
Prisma Access to the data center.

Prisma Access Administrator’s Guide (Panorama Managed) 526 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Prisma Access Mobile Users—GlobalProtect Advanced

Deployments
The following sections show you the advanced deployments that are available in a Mobile Users—
GlobalProtect deployment:
• Configure Multiple Portals in Prisma Access
• Dynamic DNS Registration Support for Mobile Users—GlobalProtect
• Identification and Quarantine of Compromised Devices in a Prisma Access GlobalProtect
Deployment
• Sinkhole IPv6 Traffic In Mobile Users—GlobalProtect Deployments
• Redistribute HIP Information with Prisma Access
• View HIP Reports from Panorama
• Support for Gzip Encoding in Clientless VPN

Configure Multiple Portals in Prisma Access

You can configure two portals based on port numbers in the same tenant, with each portal
supporting a different authentication method. Enable this feature to migrate mobile users
from one authentication method to another without creating a new tenant. This configuration
enables greater authentication flexibility by allowing you to gradually move users to cloud-based
authentication, without the need for a separate instance.
with GlobalProtect multiple portals uses a different port number for each portal within the same
tenant. Configure the first GlobalProtect portal using the standard port 443. When you enable
the multiple portal feature, configures a second GlobalProtect portal using an alternative port
8443, and allows connections to the second portal using the same FQDN as the first. The multiple
portals feature supports only two portals per FQDN.
When a user connects to the portal using port 443, the traffic is sent to the first authentication
portal with no change to the IP address. This flow is unchanged from configurations without
the GlobalProtect multiple portals feature. When a user connects using port 8443, the traffic
instead hits a destination NAT rule. This leads the user to the second authentication portal at a
different IP address. After authenticating at either portal, the user is forwarded to the gateway
with the authentication override cookie. This feature depends on the authentication override
cookie settings, and these settings are enabled for both portals and on gateways.
The following table describes GlobalProtect multiple portals support with combinations of
authentication methods and certificates using legacy authentication (such as RADIUS or LDAP) on
the primary portal and cloud authentication (such as SAML or SAML with CAS) on the secondary
portal.

Primary Portal User Secondary Portal User Connection Method Options

Authentication Authentication

Legacy, No certificate Cloud, No certificate User logon (always-on, on-

demand)

Prisma Access Administrator’s Guide (Panorama Managed) 527 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Primary Portal User Secondary Portal User Connection Method Options

Authentication Authentication

Legacy, <auth profile Cloud, <auth profile User logon (always-on, on-
selection> AND Client selection> AND Client demand)
Certificate Certificate
Pre-logon (always-on, on-
Note: Certificate profile must Note: Certificate profile must demand)
be the same. be the same.

Legacy, No certificate Cloud, <auth profile User logon (always-on, on-

selection> OR Client demand)
Certificate

Legacy, <auth profile Cloud, No certificate User logon (always-on, on-

selection> OR Client demand)
Certificate
Pre-logon (always-on, on-
Multiple portal configurations demand), if certificate
don't support clients using
only client certificate for
authentication

Legacy, <auth profile Cloud, <auth profile User logon (always-on, on-
selection> OR Client selection> OR Client demand)
Certificate Certificate
Pre-logon (always-on, on-
Multiple portal configurations Multiple portal configurations demand), if certificate
don't support clients using don't support clients using
only client certificate for only client certificate for
authentication authentication

Ensure the following before you configure multiple portals:

• Both portals have the same certificate profiles or no certificate profiles
• Allowlist associated with the authentication profiles should be the same
• When you accept a cookie for authentication override on the portal, ensure the cookie lifetime
is the same on the portal as well as on the gateway
• Multiple portal configurations don't support using only client certificate-based authentication

When configuring multiple GlobalProtect portals with Traffic Steering, don't configure
Accept Default Routes over Service Connections (Panorama > Cloud Services >
Configuration > Traffic Steering > Settings > Accept Default Route over Service
Connection); if you do, mobile users can't connect to the secondary portal.

STEP 1 | Contact your Palo Alto Networks account team to activate this functionality.

Prisma Access Administrator’s Guide (Panorama Managed) 528 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 2 | Configure a mobile user and the authentication method for it.

The minimum required version of the GlobalProtect Client version is 6.1.

STEP 3 | Select Cloud Services > Configuration > Mobile Users—GlobalProtect > Settings >
Advanced.

STEP 4 | Enable Multiple Portal for Multiple Authentication Methods.

The new portal appears for the 8443 port for the same tenant. This portal inherits the
configuration settings from the original port, which is port 443.

Prisma Access Administrator’s Guide (Panorama Managed) 529 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 5 | Edit the portal configurations to update the authentication settings.

1. Click the portal hyperlink or select Panorama > Templates > Network > GlobalProtect >
Portals and click the portal hyperlink.
2. In the Authentication section, Add a Client Authentication with a different
Authentication Profile.
You can edit only the Client Authentication and Certificate Profile authentication settings.
If you use certificate-based authentication in both portals, ensure that the gateway does not
have certificate-based authentication.
This feature enables the authentication override settings to generate cookies for both portals
in the GlobalProtect app settings.

This feature enables the authentication override settings to generate and accept cookie for
both portals in the tunnel settings.

Prisma Access Administrator’s Guide (Panorama Managed) 530 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 6 | Commit all your changes to Panorama and push the configuration changes to Prisma Access.
1. Click Commit > Commit and Push.
2. Edit Selections and, in the Prisma Access tab, make sure that Mobile Users is selected in
the Push Scope, then click OK.

3. Click Commit and Push.

STEP 7 | Add the portals manually or using endpoint management software in the GlobalProtect app.

Prisma Access Administrator’s Guide (Panorama Managed) 531 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 8 | Verify if you can connect to both portals with different authentication profiles for the
gateway.
1. Log in to your Windows machine.
2. Connect to the portals in your GlobalProtect app.
When you change the connection between portals of different authentication methods,
authenticate the user login.

If the authentication cookie expires when you connect to the 8443 portal and
switch to the manual gateway, GlobalProtect connects to the Best Available
Gateway.
If your GlobalProtect app uses cached portal configurations, fall back to portal
does not work.
3. View logs for both portals in Monitor > Logs > GlobalProtect to see the portal and
authentication information.

If you're using SAML-based authentication for the secondary portal, enter the values as
follows while integrating:
• Single sign on URL: Enter https://Portal-FQDN:443/SAML20/SP/ACS
Portal-FQDN is the FQDN for the Prisma Access portal
Use portal 443 even if you have configured the secondary portal (8443).
• Audience URI (SP Entity ID): Enter https://Portal-FQDN:443/SAML20/SP

Prisma Access Administrator’s Guide (Panorama Managed) 532 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Dynamic DNS Registration Support for Mobile Users—

GlobalProtect
This functionality is available for Prisma Access deployments starting with Panorama
Managed Prisma Access 3.1.1.
This functionality is not available for Cloud Managed Prisma Access deployments.

When a mobile user connects remotely to Prisma Access using GlobalProtect, the DNS Servers
in your enterprise are not updated with the GlobalProtect gateway-assigned IP address. Before
enabling Dynamic DNS (DDNS), there is no mapping of tunnel IP addresses with the endpoint
name, which are logged as address and pointer (A and PTR) records. Hence, your IT administrator
or user management software cannot map the remote endpoint name to the IP address.
After you enable the DDNS feature on Prisma Access, Prisma Access Cloud Services plugin checks
GlobalProtect events in Cortex Data Lake every 15 minutes to capture endpoint hostname,
domain name and tunnel IP address. It dynamically creates A and PTR records in the DNS server
using NSUPDATE.

Dynamic DNS Workflow for Mobile Users—GlobalProtect

After you enable DDNS and when a mobile user logs in with the GlobalProtect app:
Read the following sections to get an overview of how DDNS works, guidelines and requirements,
and how to enable it.
1. GlobalProtect establishes an SSL tunnel between the GlobalProtect endpoint and an on-
premises or Prisma Access gateway.
2. GlobalProtect sends the mobile user device’s hostname, domain name, and tunnel IP address
information through the tunnel to the on-premises or Prisma Access gateway.
3. The on-premises gateway or Prisma Access forwards this information as GlobalProtect events
to Cortex Data Lake.
4. The Prisma Access Cloud Services plugin probes Cortex Data Lake every 15 minutes to update
the DNS server.
If the plugin does not receive the GlobalProtect events from Cortex Data Lake, it retries the
request a maximum of five times. If the retry requests were not successful, the plugin retries
the operation every 15 minutes for a maximum of four times. Therefore, the plugin can receive
updates for a time interval of one hour.
If you want more frequent updates, you can enter the debug plugins cloud_services
set-gp-ddns-interval command to change the update interval to five minutes. A is not
required to update the time interval. If you change the interval to five minutes, the Cloud
Services plugin can update a maximum of 15,000 records with a network latency of 50 msec
and can receive updates for a time interval of 20 minutes.

• No Commit is required after you change the time interval using the command.
• These numbers are from a controlled environment and real-world operating
conditions can affect these numbers.

Prisma Access Administrator’s Guide (Panorama Managed) 533 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

5. After receiving the updates from Cortex Data Lake, the Cloud Services plugin packages A and
PTR records as NSUPDATE, and updates the primary DNS server every 15 minutes.
If you changed the time interval to five minutes using the debug plugins
cloud_services set-gp-ddns-interval command, the plugin updates the DNS server
every five minutes.
If the plugin is unable to update the DNS server through NSUPDATE, the plugin retries the
update operation a maximum of five times. If the updates were not successful, the plugin
retries the update operation every 15 minutes, or every five minutes if you changed the
interval to five minutes, for a maximum of four times. Therefore, the plugin tries to update
the events that are logged for a maximum of one hour (if you use a 15-minute interval) or 20
minutes (if you use a five-minute interval), after which it starts afresh.
6. After the A and PTR records of GlobalProtect mobile users are available in the DNS server, an
IT administrator or an enterprise software uses these records through a DNS or RDNS lookup
and resolves the endpoint name or IP address.
7. The IT administrator or the endpoint management software uses this information to manage
the endpoint or push software updates.
The following figure illustrates this workflow.

To view the connection failure logs, select Dashboard > System Logs or Monitor > Logs >
System for Mobile_User_Device_Group.

Dynamic DNS Guidelines and Requirements

Before you enable DDNS, ensure that your deployment and DNS server meet the following
guidelines and requirements:

Prisma Access Administrator’s Guide (Panorama Managed) 534 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• Update your GlobalProtect client to the following GlobalProtect app versions based on your
OS:
• Windows: 5.2.11 or later
• Mac: 5.2.11 or later
• Linux: 5.3.3 or later
• Enable Cortex Data Lake if you use an on-premises gateway other than Prisma Access.
• An Infoblox DNS server with a minimum version of 8.6.1 or later that supports DDNS updates
through NSUPDATE is required.
• Multitenant Prisma Access deployments do not support DDNS.
• Save the authentication key from your DNS server in base64 format with a file extension
of .key. You can upload the key only in this format in Prisma Access.
• Enable NTP on your DNS server and ensure that it is same as that of Prisma Access.
• Create zones in Infoblox for reverse PTR and forward A addresses.

Enable DDNS for Mobile Users—GlobalProtect

To update your DNS server with A and PTR records of your GlobalProtect mobile users, complete
following steps.

Prisma Access Administrator’s Guide (Panorama Managed) 535 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 1 | Create an authentication key in your DNS server.

This example uses Infoblox as the DNS server.

1. Log in to your DNS server.

2. Select Data Management > DNS > Grid DNS Properties > Updates.
3. Allow updates from Set of ACEs.
4. Add a TSIG Key after filling details.

• Select the 256 key algorithm.

• Generate Key Data to create a new key. Select the 256 key data.

5. Copy the key data to a file in the following format and save the file with .key extension.

key "ddns-gp" {
algorithm hmac-sha256;
secret "wCJKVYUtQt644eVOWnowgw==";
};

You upload this key to Prisma Access Cloud Services plugin in a later step.

Prisma Access Administrator’s Guide (Panorama Managed) 536 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 2 | In your Prisma Access deployment, specify your DNS server as the primary DNS server.
1. Select Panorama > Setup > Services.
2. Edit the settings and update the primary DNS server details.

Prisma Access Administrator’s Guide (Panorama Managed) 537 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 3 | Configure the DDNS settings.

1. Select Panorama > Cloud Services > Configuration > Service Setup.
2. Select Service Operations > Dynamic DNS Configuration and Enable DDNS.
3. (Optional) Configure TTL, which is the time-to-live (TTL) value, to the frequency at which
you want Prisma Access to refresh FDQN in its cache.
The value is set to 9 hours by default.

4. Upload the DDNS authentication key that you created in Step 1 from your DNS server.

STEP 4 | Commit to Panorama.

Verify Dynamic DNS Configuration

After you have enabled DDNS, monitor the logs and troubleshoot any issues by checking the
following Prisma Access components.
Select Monitor > Logs > GlobalProtect. The gateway agent message contains the hostname,
domain name, and the tunnel IP address information. GlobalProtect sends the agent message only
if the endpoint is part of a domain or AD.

Prisma Access Administrator’s Guide (Panorama Managed) 538 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Check the gp_ddns_support.log command in Panorama CLI to view other DDNS logs.

Identification and Quarantine of Compromised Devices in a Prisma

Access GlobalProtect Deployment
Prisma Access allows you to identify and quarantine compromised devices that are connected
with the GlobalProtect app. You do this by either manually or automatically adding devices to
a quarantine list. After you quarantine the device, you can block the quarantined device from
accessing the network to ensure consistent policy.
Each Prisma Access mobile user location sends and receives its quarantine information between
the Panorama that manages Prisma Access and its nearest service connection. If you have
next-generation firewalls or gateways, you should have the service connection redistribute the
quarantine list information to and from Panorama and the on-premise firewalls or gateways. You
should also redistribute the quarantine list information from Panorama to the service connection
to ensure consistent policy enforcement for all mobile user locations (gateways) in Prisma Access.

Use Cases for Quarantine List Redistribution

The following section describes some common Prisma Access deployments where quarantine list
redistribution is useful for consistent policy enforcement for compromised devices.
• Quarantine List Redistribution between Mobile User Locations Connected to Same Service
Connection—In the following example, a GlobalProtect Mobile User who is connected to
Mobile User Location 1 becomes compromised and is auto-quarantined. Prisma Access blocks
or restricts the quarantined device per policy.

A service connection (Service Connection 1 in this example) redistributes the quarantine list
information between all mobile user locations to which it is connected. Since Mobile User

Prisma Access Administrator’s Guide (Panorama Managed) 539 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Location 2 receives the redistributed quarantine list information by way of Service Connection
1, the GlobalProtect mobile user attempt to connect to Mobile User Location 2 is also blocked.

• Quarantine List Redistribution between Mobile User Locations Connected to Different

Service Connections—In the following example, there are two mobile user locations, but they
connect to two different service connections. A GlobalProtect user attempted to connect to

Prisma Access Administrator’s Guide (Panorama Managed) 540 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Mobile User Location 1. Mobile User Location 1 detects the GlobalProtect user endpoint as
compromised and quarantines it.

To redistribute the quarantine list information from Mobile User Location 1 to Mobile User
Location 2, perform the following actions:
• Redistribute the quarantine list information from Service Connection 1 to Panorama.
• Redistribute the quarantine list information from Panorama to Service Connection 2.
With this configuration, when the GlobalProtect user connects to Mobile User Location 1 and
is quarantined, then the quarantine list information redistributes from Mobile User Location 1
to Mobile User Location 2 and any connection attempts to Mobile User Location 2 are blocked.

This configuration is also valid if the GlobalProtect user connects to Mobile User
Location 2 and is quarantined; the quarantine list information redistributes from
Mobile User Location 2 to Mobile User Location 1.

Prisma Access Administrator’s Guide (Panorama Managed) 541 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• Quarantine List Redistribution Between Prisma Access and a Next-Generation Firewall

or Gateway—In the following example, A GlobalProtect user attempted to connect to
Mobile User Location 1. Mobile User Location 1 detects the GlobalProtect user endpoint as
compromised and quarantines it. The mobile user then goes to the company’s headquarters
and attempts to log in again. The headquarters is protected with a next-generation firewall
configured as a GlobalProtect gateway using Internal Host Detection.
Mobile User Location 1 redistributes the quarantine list information to Panorama through
Service Connection 1, and Panorama redistributes the quarantine list information to the on-
premise internal gateway. When the user attempts to log in from the headquarters location,

Prisma Access Administrator’s Guide (Panorama Managed) 542 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

GlobalProtect detects that the on-premises gateway is configured as an internal gateway and
connects to the gateway without a tunnel.
Since the quarantine list information has been redistributed to the on-premises gateway, the
user is blocked at the gateway based on the configured user policies.

If you use a next-generation firewall or gateway with Prisma Access, you should configure
Panorama to redistribute quarantine list information to the firewall or gateway, all service
connections, and Panorama.
• Administrator Manually Quarantines Mobile User at Panorama—In this example, the Prisma
Access administrator has manually added a mobile user to the quarantine list at the Panorama
appliance that manages Prisma Access. The administrator has set up redistribution between
Panorama, the next-generation firewall, and the service connections. Panorama redistributes
the updated quarantine list information to the firewall and the service connections. The service
connections then redistribute the quarantine list information to the mobile user locations.
The mobile user was connected to Mobile User Location 1. After Mobile User Location 1
receives the updated quarantine list information, the user is disconnected. If the user attempts

Prisma Access Administrator’s Guide (Panorama Managed) 543 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

to connect to Mobile User Location 2, the connection is blocked and the mobile user receives a
quarantine notification.

• Mobile User is Auto or Manually Quarantined at the On-Premises Gateway—In this example,
there is a next-generation firewall that has been configured as an external gateway at
the headquarters or data center location. The administrator has manually quarantined a
mobile user at the external gateway. The external gateway redistributes the quarantine list
information from the external gateway to Panorama.
After Panorama has received the updated quarantine list information from the external
gateway, it redistributes that information to Service Connections 1 and 2, which then
redistributes it to Mobile User Locations 1 and 2. If a mobile user attempts to connect to either

Prisma Access Administrator’s Guide (Panorama Managed) 544 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Mobile User Location 1 or 2, Prisma Access blocks the connection and the user receives a a
quarantine notification.

Configure Quarantine List Redistribution in Prisma Access

To redistribute quarantine information to and from service connections, the Panorama that
manages Prisma Access, and next-generation firewalls, complete the following steps.

Prisma Access Administrator’s Guide (Panorama Managed) 545 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 1 | Make sure that the Panorama management IP address is able to communicate with the User-
ID agent address for all service connections to which you want to redistribute quarantine list
information.
Communication between the User-ID Agent address of the service connection and the
management IP address of Panorama is required for Prisma Access to send and receive
quarantine list information between Panorama and the service connections.
• To find the User-ID Agent Address, select Panorama > Cloud Services > Status > Network
Details > Service Connection > User-ID Agent Address.

• To find the management IP address of the Panorama that manages Prisma Access, note the
IP address that displays in the web browser when you access Panorama.

STEP 2 | Allow Prisma Access to redistribute quarantine list information.

1. In Panorama, select Panorama > Cloud Services > Configuration > Service Setup.
2. Click the gear icon to edit the settings.
3. In the Advanced tab, select Enable Quarantine List Redistribution.
Enabling quarantine list redistribution allows Prisma Access to redistribute the
quarantine list information received from one or more mobile user locations (gateways)
to service connections.

STEP 3 | Commit and Push your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 546 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 4 | Configure Panorama to receive quarantine list information from Prisma Access by
configuring management interface settings.
1. In the Panorama that manages Prisma Access, select Panorama > Setup > Interfaces.
2. Select the Management interface.
3. Select User-ID.

Prisma Access Administrator’s Guide (Panorama Managed) 547 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 5 | Configure a data redistribution agent that redistributes quarantine list information from the
service connections to Panorama.
1. From the Panorama that manages Prisma Access, select Panorama > Cloud Services >
Status > Network Details > Service Connection.
2. Make a note of the User-ID Agent Address (Panorama > Cloud Services > Status >
Network Details > Service Connection > User-ID Agent Address) for each service
connection.
3. Select Panorama > Data Redistribution > Agents.
4. Add a Data Redistribution agent, give it a Name and select Enabled.
5. Enter the User-ID Agent Address of the service connection as the Host and 5007 as the
Port.

Make sure that your network does not block access to this port between
Panorama and Prisma Access.
6. (Optional) If you have configured this service connection as a Collector (Device > Data
Redistribution > Collector Settings), enter the Collector Name and Collector Pre-Shared
Key
7. Select Quarantine List; then, click OK.

8. Repeat Step 5 for all the service connections in your Prisma Access deployment.

STEP 6 | Select Commit > Commit to Panorama to save your changes locally on the Panorama that
manages Prisma Access.

Prisma Access Administrator’s Guide (Panorama Managed) 548 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 7 | Configure a data redistribution agent that redistributes quarantine list information from
Panorama to the service connections.
1. Find the management IP address of the Panorama that manages Prisma Access.
This address displays by in the web browser address bar when you access Panorama.

2. Make sure that you are in the Service_Conn_Template template, then select Device >
Data Redistribution > Agents.

3. Add a Data Redistribution agent, give it a Name and select Enabled.

4. Enter the management IP address of the Panorama appliance. as the Host and 5007 as
the Port.

Prisma Access Administrator’s Guide (Panorama Managed) 549 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

5. Select Quarantine List; then, click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 550 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 8 | Configure a data redistribution agent that redistributes quarantine list information from the
service connections to mobile user gateways.
1. From the Panorama that manages Prisma Access, select Panorama > Cloud Services >
Status > Network Details > Service Connection.
2. Make a note of the User-ID Agent Address of the service connection from which you
want to redistribute quarantine list information.
Since all service connections have the same redistributed quarantine list information,
choose any service connection. You can also configure more than one service
connection.

3. Make sure that you are in the Mobile_User_Template, then select Device > Data
Redistribution > Agents.
4. Add a Data Redistribution agent, give it a Name, and select Enabled.
5. Enter the User-ID Agent Address of the service connection as the Host and 5007 as the
Port.

Make sure that your network does not block access to this port between
Panorama and Prisma Access.
6. (Optional) If you have configured this service connection as a Collector (Device > Data
Redistribution > Collector Settings), enter the Collector Name and Collector Pre-Shared
Key.
7. Select Quarantine List; then, click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 551 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

8. Commit and Push your changes.

STEP 9 | View your quarantine list information by selecting Panorama > Device Quarantine.
See View Quarantined Device Information in the GlobalProtect Administrator’s Guide for
details.

Sinkhole IPv6 Traffic In Mobile Users—GlobalProtect Deployments

In a dual stack endpoint that can process both IPv4 and IPv6 traffic, the GlobalProtect app sends
mobile user IPv4 traffic to be protected through the GlobalProtect VPN tunnel to Prisma Access.
However, mobile user IPv6 traffic is not sent to Prisma Access by default and is sent to the local
network adapter on the endpoint instead. To reduce the attack surface for IPv6-based threats,
Palo Alto Networks recommends that you configure Prisma Access to sinkhole IPv6 traffic.
Because endpoints can automatically fall back to an IPv4 address, you can enable a secure and
uninterrupted user experience for mobile user traffic to the internet.
In addition, Palo Alto Networks recommends that you configure GlobalProtect to completely
disable network traffic on the local network adapter. If you have a hybrid Prisma Access
deployment with on-premises next-generation firewalls configured as GlobalProtect gateways,
you can configure IPv6 sinkhole functionality on the on-premises GlobalProtect gateway.
You can configure Prisma Access so that it sinkholes all mobile user IPv6 traffic. When you enable
this functionality, Prisma Access assigns an IPv6 address to the connecting endpoint in addition

Prisma Access Administrator’s Guide (Panorama Managed) 552 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

to an IPv4 address; then, it routes the IPv6 traffic to Prisma Access and discards it using a built-in
security policy, as shown in the following figure.

To configure Prisma Access so that it sinkholes all mobile user IPv6 traffic, complete the following
steps.
STEP 1 | Open a secure CLI session with admin-level privileges, using the same IP address that you
use to log in to the Panorama that manages Prisma Access.

STEP 2 | Enter configure to enter configuration mode.

STEP 3 | Enter the set plugins cloud_services mobile-users ipv6 yes command.
If you need to disable this command in the future, enter set plugins cloud_services
mobile-users ipv6 no.

STEP 4 | Enter Commit to save your changes locally.

STEP 5 | Enter exit to exit configuration mode.

STEP 6 | Enter commit-all shared-policy include-template yes device-group

Mobile_User_Device_Group to commit and push your changes and make them active in
Prisma Access.

Configure GlobalProtect to Disable Direct Access to the Local Network

To make sure that all mobile user traffic is sent to Prisma Access, you can completely disable
outgoing connections, including local subnet traffic, from being sent to the local adapter. You can
deactivate all outgoing connections to the local adapter by making configuration changes to the
GlobalProtect gateway.
You can perform these steps on Panorama or on an on-premises firewall that has been configured
as a GlobalProtect gateway.

Enable the No direct access to local network setting to reduce risks in untrusted networks
such as rogue Wi-Fi access points.

Prisma Access Administrator’s Guide (Panorama Managed) 553 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 1 | Select Network > GlobalProtect > Gateways.

STEP 2 | Select an existing GlobalProtect gateway or Add a new one.

STEP 3 | Select Agent > Client Settings.

STEP 4 | Select the DEFAULT configuration or Add a new one.

STEP 5 | Select Split Tunnel; then, select No direct access to local network.

Disabling local network access causes all traffic, including IPv4 and IPv6 traffic, from
being sent to the local adapter. In addition, you won't be able to access resources
on your local subnet, such as printers. Split tunnel traffic based on access route,
destination domain, and application still works as expected.

STEP 6 | (Panorama and Prisma Access deployments only) Commit your changes locally to make them
active in Panorama.
1. Select Commit > Commit to Panorama.
2. Make sure that your change is part of the Commit Scope.
3. Click OK to save your changes to the push scope.
4. Commit your changes.

STEP 7 | Commit and Push your changes to make them active in Prisma Access.

Set Up an IPv6 Sinkhole On the On-Premises Gateway

If you have a hybrid deployment that uses next-generation firewalls configured as gateways with
Prisma Access, perform the following task on the on-premises gateway to drop the IPv6 traffic.

Prisma Access Administrator’s Guide (Panorama Managed) 554 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 1 | Add IPv6 IP pools to your GlobalProtect agent configuration.

1. Select Network > GlobalProtect > Gateways.
2. Select an existing GlobalProtect gateway or Add a new one.
3. Select Agent > Client Settings.
4. Select the agent configuration to modify or Add a new one.
5. Select IP Pools; then, Add an IPv6 pool to assign to the virtual network adapter on the
endpoints that connect to the GlobalProtect gateway uses for mobile network traffic and
click OK.

STEP 2 | Enable IPv6 on the interface.

1. Select Device > Interface > Tunnel and select the tunnel Interface that you use for the
mobile user’s traffic.
2. Select IPv6; then, select Enable IPv6 on the interface.

Prisma Access Administrator’s Guide (Panorama Managed) 555 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 3 | Add a security policy to set a TCP reset action that will terminate sessions with IPv6 source
traffic that matches the IP pools you configured in Step 1.
1. Select Policies > Security and Add a new security policy.
2. Set the Source Address in the rule to match the IP pools you configured in Step 1.

3. Select Actions; then, select an Action Setting of Reset Client and click OK.

STEP 4 | Commit your changes.

STEP 5 | (Optional) Perform this task on all the gateway firewalls in your deployment.

Redistribute HIP Information with Prisma Access

To ensure consistent Host Information Profile (HIP) policy enforcement and to simplify policy
management, you can redistribute HIP information received from mobile users and users at
remote networks that use the GlobalProtect app from Prisma Access to other gateways, firewalls,
and Panorama appliances in your enterprise, including the Panorama that manages Prisma Access.
To do so, you enable and configure HIP redistribution in Prisma Access.
• HIP Redistribution Overview
• Use Cases for HIP Redistribution
• Configure HIP Redistribution in Prisma Access

HIP Redistribution Overview

When a mobile user whose endpoint has the GlobalProtect app installed connects to Prisma
Access, Prisma Access collects the user’s HIP information from the endpoint’s GlobalProtect app,
which makes the HIP report available in Prisma Access.

To use HIP redistribution, users must have the GlobalProtect app installed on their
endpoint. While Prisma Access supports Clientless VPN, you cannot redistribute HIP
information for Clientless VPN users.

Prisma Access Administrator’s Guide (Panorama Managed) 556 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

HIP redistribution is applicable to both mobile users and users at remote networks. However, for
users at remote networks, an on-premises gateway must detect that the user is internal to the
organization’s network using internal host detection before the on-premises gateway can send
HIP information to Prisma Access.

In Prisma Access, you configure internal host detection when you configure your mobile
user deployment.

To assure consistent policy enforcement, you can use HIP redistribution to allow Prisma Access
to distribute users’ HIP information to other Panorama appliances, gateways, firewalls, and virtual
systems in your deployment, as well as distribute HIP information from those devices to Prisma
Access in some cases. This ability allows you to consistently apply HIP-based policy enforcement
for users’ traffic, including policies for internet-bound traffic or for traffic that is accessing an
internal application or resource in your organization’s headquarters or data center. Redistributing
HIP information to the Panorama appliance also lets you view detailed HIP information for Prisma
Access users from that appliance.

Use Cases for HIP Redistribution

The following section describes some common Prisma Access deployments where HIP
redistribution is useful for consistent policy enforcement and HIP report viewing.
• HIP redistribution from Prisma Access to a next-generation firewall—If you have a next-
generation firewall in your organization’s data center or headquarters location, and have
configured that firewall with HIP-based security policies, you cannot enforce those policies for
Prisma Access mobile users until you redistribute HIP redistribution from Prisma Access to the
firewall.
The following figure shows a mobile user whose endpoint is protected with the GlobalProtect
app. The user attempts to access an internal app at an HQ/data center whose access is
controlled by a next-generation firewall with HIP-based security policies. When the user logs
in to the GlobalProtect app, the app collects HIP information and sends it to Prisma Access;
however, Prisma Access does not redistribute this information to the on-premises firewall.

Prisma Access Administrator’s Guide (Panorama Managed) 557 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Since the firewall does not have the user’s HIP information, it blocks the user’s access to the
app.

HIP redistribution allows you to distribute the mobile users’ HIP information to the on-
premises firewall. The firewall can then check the user’s HIP information against its configured
security policies and grant the user access to the app.

Prisma Access Administrator’s Guide (Panorama Managed) 558 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

To redistribute HIP information from Prisma Access to the firewall, you you allow Prisma
Access to redistribute HIP information, then Add a User-ID Agent (Panorama > User
Identification > User-ID Agents for 9.1.x Panorama appliances or Panorama > Data
Redistribution for Panorama 10.x appliances) on the firewall, and specify the Prisma Access
User-ID Agent Address (Panorama > Cloud Services > Status > Network Details > Service

Prisma Access Administrator’s Guide (Panorama Managed) 559 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Connection > User-ID Agent Address) as the Host (10.1.1.1 in the following example) and
5007 as the Port.

• HIP redistribution from Prisma Access to Panorama—If you have multiple firewalls or
gateways in your organization with HIP-based security policies, you can redistribute the HIP
information from Prisma Access to the Panorama that manages Prisma Access by creating a
User-ID agent in Panorama and specifying the Prisma Access User-ID Agent Address as the
User-ID Host. You can then redisribute HIP reports from that Panorama appliance to the other
managed Panorama appliances, gateways, firewalls, and virtual systems in your enterprise,

Prisma Access Administrator’s Guide (Panorama Managed) 560 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

using the same workflow that you use to redistribute User-ID information to managed firewalls
and enforce consistent policy for internal apps and resources, as shown in the following figure.

Alternatively, you can configure each internal firewall or gateway in your enterprise to directly
collect HIP information from Prisma Access, without using Panorama as a central location,
by creating a User-ID Agent in each device. Note, however, that Prisma Access uses service
connections to send HIP information, and service connection bandwidth consumption might
increase if Prisma Access sends a large number of HIP reports.
• HIP redistribution from a user at a remote network to Prisma Access—The previous use cases
showed Prisma Access collecting HIP information from mobile users. If you want to apply HIP-
based policies in Prisma Access for a user at a remote network location, you need a way to
distribute the HIP information from the remote network user’s GlobalProtect app to Prisma
Access.
The following example shows a user at a remote network location whose internet access
is located on the remote network connection. In Prisma Access, you control the user’s

Prisma Access Administrator’s Guide (Panorama Managed) 561 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

internet access at the remote network location with security policies created in the
Remote_Network_Device_Group or in a shared device group. To properly enforce the policies
at the remote network location for the user, you need to configure Prisma Access to retrieve
the user’s HIP information from the internal gateway.
In this example, the GlobalProtect gateway at the HQ/data center that is configured as an
internal gateway using internal host detection checks the user’s HIP information from the

Prisma Access Administrator’s Guide (Panorama Managed) 562 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

user’s GlobalProtect app. The internal gateway detects that the user is inside the remote
network location and collects both User-ID and HIP information from the user.
To distribute this HIP information from the internal gateway to Prisma Access, create a User-ID
agent in Panorama and specify the IP address of the internal gateway as the host.

• View detailed HIP logs from Panorama—When mobile users log in using the GlobalProtect
app, the app sends the HIP information to Prisma Access. Panorama retrieves the log results
from Cortex Data Lake to view the results of the HIP Match logs (Monitor > Logs > HIP

Prisma Access Administrator’s Guide (Panorama Managed) 563 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Match); however, you cannot view detailed HIP reports until you configure Panorama to
redistribute HIP report details from Prisma Access to Panorama.

To redistribute detailed HIP information from mobile users to Panorama, create a User-ID
agent in Panorama and specify the User-ID Agent Address (Panorama > Cloud Services >
Status > Network Details > Service Connection > User-ID Agent Address) as the User-ID host.
See Configure HIP Redistribution in Prisma Access for details.
If you have configured an on-premises gateway as an internal gateway at a remote user
location, you can also send the HIP information for users at remote networks to Panorama
by creating a User-ID agent in Panorama and specifying the remote network EBGP Router

Prisma Access Administrator’s Guide (Panorama Managed) 564 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

address (Panorama > Cloud Services > Status > Network Details > Remote Networks > EBGP
Router) as the User-ID host. See Configure HIP Redistribution in Prisma Access for details.

Configure HIP Redistribution in Prisma Access

To allow Prisma Access to collect and redistribute HIP information, complete the following task.

Prisma Access Administrator’s Guide (Panorama Managed) 565 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 1 | Allow Prisma Access to redistribute HIP information.

1. In Panorama, select Panorama > Cloud Services > Configuration > Service Setup.
2. Click the gear icon to edit the settings.
3. In the Advanced tab, select Enable HIP Redistribution.
Enabling HIP Redistribution enables Prisma Access to redistribute the HIP reports
received from the GlobalProtect app to internal firewalls and to Panorama.

STEP 2 | Configure Panorama to receive HIP reports from Prisma Access.

1. Select Panorama > Setup > Interfaces.
2. Select the Management interface.
3. Select User-ID.

Prisma Access Administrator’s Guide (Panorama Managed) 566 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 3 | Configure Panorama to collect the User-ID mapping from Prisma Access.
1. From the Panorama that manages Prisma Access, select Panorama > Data Redistribution
> Agents (for Panorama 10.x appliances) or Panorama > User Identification > User-ID
Agents (for 9.1.x Panorama appliances).
2. Add a User-ID Agent and give it a Name.
3. Enter one of the following values in the Host field, depending on the types of HIP
information you want to collect.
• To collect HIP information for mobile users, enter the User-ID Agent Address
(Panorama > Cloud Services > Status > Network Details > Service Connection >
User-ID Agent Address).
• To collect HIP information from users at a remote network locations with an internal
gateway, enter the IP address of the internal gateway.
• To collect HIP information from users are a remote network connection, enter the
EBGP Router address (Panorama > Cloud Services > Status > Network Details >
Remote Networks > EBGP Router as the User-ID host.
4. Enter 5007 in the port field.
By default, the User-ID agent uses port 5007 to listen for HIP information requests.

Make sure that your network does not block access to this port between Prisma
Access and the Active Directory server or User-ID Agent.
5. Select Enabled to enable Panorama to communicate with the User-ID agent.
6. Select IP User Mappings and HIP to enable Panorama to receive IP address-to-username
mappings and GlobalProtect HIP data from all mobile user locations.
7. Click OK.

STEP 4 | Repeat Step 3 for each service connection to which you want to configure HIP report
collection.

Prisma Access Administrator’s Guide (Panorama Managed) 567 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

View HIP Reports from Panorama

After you configure Prisma Access to collect and redistribute HIP information to Panorama, use
the following workflow to view HIP information in Panorama.

Prisma Access Administrator’s Guide (Panorama Managed) 568 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 1 | Select Monitor > Logs > HIP Match to view HIP information.

Prisma Access Administrator’s Guide (Panorama Managed) 569 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 2 | Click the icon to the left of a record to view detailed HIP information.

Support for Gzip Encoding in Clientless VPN

GlobalProtect Clientless VPN provides secure remote access to common enterprise web
applications. Prisma Access Clientless VPN lets mobile users access Gzip-compressed websites to
use both internal and SaaS applications. Support for Gzip encoding ensures that the Gzip encoding
request within the HTTP header is accepted by the Clientless VPN portal. This ensures that the
content from the Gzip-compressed web pages is rendered correctly when accessed through the
Clientless VPN portal.

Prisma Access Administrator’s Guide (Panorama Managed) 570 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

The following diagram illustrates the extended support to allow users to access internal and SaaS
applications through Clientless VPN in Prisma Access.

The Clientless VPN can determine whether to use Gzip encoding based on the HTTP request from
the client and the corresponding response from the app. The gzip value must be included as one
of the Accept-Encoding header values so that it is accepted by the Clientless VPN.
For example, consider the following scenarios when the Clientless VPN uses Gzip encoding:
1. The browser sends an HTTP request to the website with the Accept-Encoding header values
set to gzip, deflate, and br, as shown in the following example.

Prisma Access Administrator’s Guide (Panorama Managed) 571 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

2. The Clientless VPN portal in Prisma Access parses the incoming HTTP request from the
browser and sets the Accept-Encoding header value to gzip that indicates support for Gzip
encoding, as shown in the following example.

3. If the website supports Gzip encoding in the HTTP response, the website sends the Content-
Encoding header as gzip that indicates the content is in Gzip format, as shown in the following
example.

4. The Clientless VPN forwards the response received from the website to the web browser in
the same format, as shown in the following example.

If the HTTP request received by the Clientless VPN does not include gzip as one of the
encoding methods, the Clientless VPN does not accept Gzip encoding either.

Prisma Access Administrator’s Guide (Panorama Managed) 572 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Prisma Access Mobile Users—Explicit Proxy Advanced

Deployments
The following sections show you the advanced deployments that are available for Prisma Access
Mobile Users—Explicit Proxy deployments:
• Secure Users and Devices at Remote Networks With an Explicit Proxy

Secure Users and Devices at Remote Networks With an Explicit

Proxy
If you want to forward traffic to Explicit Proxy from your branches through a secure IPSec tunnel,
you use Explicit Proxy in conjunction with a Prisma Access Remote Network. You integrate this
functionality by using anycast and unicast IP addresses that Prisma Access allocates from the
infrastructure subnet, and you specify these addresses to connect to Explicit Proxy from the
Remote Network IPSec tunnel. In this way, users and devices at a branch location or site can
securely access internet-based apps and resources using Explicit Proxy.
Integrating Explicit Proxy with a Remote Network deployment gives you the following
advantages:
• Prisma Access sends Internet-bound traffic without backhauling it to a data center or HQ site,
which provides a clear benefit over an on-site proxy solution.
• Prisma Access takes the IP addresses you use with Explicit Proxy from its infrastructure
subnet, which is a private IP address subnet. Prisma Access provides you with four anycast IP
addresses globally, and one unicast IP address per Remote Network, that you use to forward
traffic to Explicit Proxy.
• Since these anycast and unicast IP addresses are private, you don’t need to set up a route to
a public IP address, which simplifies Explicit Proxy configuration in networks that don’t have a
default route.
• If you onboard multiple Explicit Proxy locations during Explicit Proxy setup, the Remote
Network automatically forwards traffic to the closest onboarded Explicit Proxy location,
relative to the Remote Network's location.
In addition, if the compute location that corresponds to an Explicit Proxy goes down for any
reason (for example, in the event of a regional or cloud provider outage), Prisma Access fails
over to an active, onboarded Explicit Proxy in another compute location with no additional
configuration required.
• If you require more than 1000 Mbps of bandwidth for a Remote Network, you can create a
high-bandwidth network using multiple Remote Network connections and specify the Explicit
Proxy anycast and unicast addresses in each connection.
• If you want your Remote Network to be resilient between geographical locations, you can
create multiple Remote Networks with different locations and use them for the same site.
The following diagram shows a Remote Network that has been configured for a site that has no
default route configured. To protect users and headless devices at the site using Explicit Proxy,
the administrator has made the following configuration changes:

Prisma Access Administrator’s Guide (Panorama Managed) 573 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• You have onboarded Remote Networks and Explicit Proxy locations and have retrieved the
anycast and unicast IP addresses that Prisma Access takes from its infrastructure subnet.

You can also create a hostname for Explicit Proxy-directed traffic and add the Explicit
Proxy unicast and anycast IP addresses to that hostname.
• You have configured the CPE to forward Explicit Proxy traffic to these anycast and unicast
addresses.
Use the anycast IP addresses in the PAC file to have Prisma Access select from any onboarded
Remote Network tunnel to forward traffic to Explicit Proxy. Use the unicast address to have
Prisma Access forward traffic through a specific Remote Network tunnel. In this example, you
can use either anycast or unicast addresses, since the traffic is going only through one Remote
Network IPSec tunnel.
• You have specified these IP addresses in the PAC files of the users’ endpoints and in the
system proxy settings of the headless devices.
After configuration is complete, Prisma Access forwards the traffic from the Remote Network
tunnel to Explicit Proxy.

If you want to use a high-bandwidth connection with Explicit Proxy, create a high-bandwidth
remote network connection using multiple Remote Networks; then, add the anycast and,
optionally, unicast IP addresses to the PAC file on the remote users’ endpoints or headless
devices. The following diagram shows the traffic flow using anycast addresses; Prisma Access
chooses the Remote Networks based on the configuration on your CPE.

Prisma Access Administrator’s Guide (Panorama Managed) 574 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

To create a high-bandwidth, geographically diverse Remote Network-Explicit Proxy deployment,

add multiple Remote Network and Explicit Proxy deployments in different compute locations, as
shown in the following diagram.

The use of anycast addresses lets you use a consistent PAC file across a deployment that has a
wide geographic distribution, and lets you use ECMP on the CPE for high-bandwidth use cases. If
you want to target a specific Remote Network, use unicast addresses.
The following example shows two sites, one in Canada and one in the United States, connected
with a WAN link. The administrator wants to keep the Explicit Proxy traffic flow within each
country. To do so, the administrator uses the unicast addresses that are specific to the Remote
Network tunnel for the Canada East and the US Northeast locations. The use of Unicast IPs
ensures that users are always sent to the preferred regional Remote Network tunnel and Explicit
Proxy location.
Prisma Access uses the Remote Network EBGP Router address (Panorama > Cloud Services
> Status > Network Details > Remote Networks) as the unicast address. If you have changed
the EBGP router address in your Prisma Access configuration, you can retrieve the loopback IP
address using the Prisma Access API.

You can also use anycast addresses to provide regional isolation. For example, you could
specify anycast addresses only in Canada to deploy the Explicit Proxy solution only in
Canada.

Prisma Access Administrator’s Guide (Panorama Managed) 575 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Integrate Explicit Proxy With a Remote Networks Deployment In Panorama Managed

Prisma Access
To configure an Explicit Proxy deployments in a Remote Network deployment, complete the
following steps.
STEP 1 | Retrieve the anycast IP addresses you use for your Explicit Proxy/Remote Network
deployment.
1. Select Panorama > Cloud Services > Configuration > Mobile Users—Explicit Proxy.
2. Select the gear icon to edit the Settings.
3. Select Forward Remote Network traffic to Explicit Proxy.

4. Select Panorama > Cloud Services > Configuration > Remote Networks.
5. Onboard your Remote Network locations if you have not done so already.
6. Click Commit > Commit and Push.
7. Edit Selections and, in the Prisma Access tab, make sure Prisma Access for networks is
selected in the Push Scope, then click OK.
8. Commit and Push your changes.
You must perform a commit and push for your Remote Networks for Prisma Access to
retrieve the IP addresses used in an Explicit Proxy/Remote Network deployment.
9. Return to the Explicit Proxy Settings (Panorama > Cloud Services > Configuration
> Mobile Users—Explicit Proxy > Settings > Advanced) and make a note of the
ALLOCATED ADDRESSES that display in under Remote Networks Configuration.

Prisma Access Administrator’s Guide (Panorama Managed) 576 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 2 | (Optional) Find the unicast address you use for your Explicit Proxy/Remote Network
deployment.
Use the unicast IP address in the PAC file only if you want to target a specific Remote Network
to forward traffic to Explicit Proxy. If you want to use all deployed Remote Networks to
forward traffic to Explicit Proxy, use the anycast addresses.
1. Select Panorama > Cloud Services > Status > Network Details > Remote Networks.
2. Make a note of the EBGP Router address.
If you have IPv4 and IPv6 addresses, make a note of the IPv4 address.

This address is also known as the loopback address. If you have made
configuration changes that changed the EBGP router address, you can retrieve
the loopback IP address using the Prisma Access legacy API.

STEP 3 | Configure your Explicit Proxy deployment and onboard the Explicit Proxy locations you want
to add.

STEP 4 | Ensure that your Explicit Proxy PAC file does not bypass the anycast and unicast IP
addresses.
If you created a hostname for Explicit Proxy-directed traffic and added the Explicit Proxy
unicast and anycast IP addresses to that hostname, be sure that the PAC file does not bypass
this hostname and that it is sent to Explicit Proxy. Any traffic sent to the anycast and unicast IP
addresses must be sent to Explicit Proxy.

STEP 5 | Ensure that the CPE in your network is set up correctly for endpoints to forward traffic to
Explicit Proxy via the anycast and unicast IP addresses.

Prisma Access Administrator’s Guide (Panorama Managed) 577 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Prisma Access Remote Network Advanced Deployments

The following sections show you the advanced deployments that are available for Prisma Access
Remote Networks:
• Provide Secure Inbound Access to Remote Network Locations
• Create a High-Bandwidth Network for a Remote Site

Provide Secure Inbound Access to Remote Network Locations

If your organization hosts internet-accessible applications at a remote network site, providing
access to those applications exposes your network to all the threats posed by an open internet.
This section describes how Prisma Access provides a way to provide secure access to those
applications, when you should implement it, and how to configure it.
• Secure Inbound Access for Remote Network Sites
• Secure Inbound Access Examples
• Guidelines for Using Secure Inbound Access
• Configure Secure Inbound Access for Remote Network Sites

Secure Inbound Access for Remote Network Sites

Prisma Access for remote networks allows outbound access to internet-connected applications.
In some cases, your organization might have a requirement to provide inbound access to an
application or website at a remote site, and provide secure access to that application for any
internet-connected user—not just users who are protected by Prisma Access. For example:
• You host a public-facing custom application or portal at a remote network site.
• You have a lab or staging environment for which you want to provide secure access.
• You have a need to provide access to an application or website to users who are not members
of an organizational domain.
• You have IoT devices that require access to an internal asset management, tracking, or status
application.
To do this, create a remote network that allows secure inbound access. If you require outbound
access as well as inbound access for a remote network site, create two remote networks in the
same location—one for inbound access and one for outbound access.

While this solution can provide access for up to 50,000 concurrent inbound sessions per
remote network, Palo Alto Networks does not recommend using this solution to provide
access to a high-volume application or website.

To make internet-accessible applications available from a remote network site, you first make a
list of the applications to which you want to provide access, and assign a private IP, port number,
and protocol combination for each application. If you use the same IP address for multiple
applications, the port/protocol combination must be unique for each application; if you use the
same port/protocol combination for multiple applications, each IP address must be unique.

Prisma Access Administrator’s Guide (Panorama Managed) 578 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

To begin configuration, you choose how many public IP addresses you want to associate for the
applications. You can specify either 5 or 10 public IP addresses per remote network site. Each
public IP allocation takes bandwidth (units) from your Remote Networks license, in addition to the
bandwidth that you have allocated for the compute location associated to the remote network.
5 IP addresses take 150 Mbps from your remote network license allocation, and 10 IP addresses
take 300 Mbps.
After you choose the number of public IP addresses, you then enter the application, along with
its associated private IP/port number/protocol combination, for which you want secure inbound
access.
You can decide how you want to map your application to the public IP addresses. By default,
Prisma Access assigns the public IP addresses to the applications you specify, and multiple
applications can be assigned to a single IP address. If you need to map a single application to
a single public IP address, you can select Dedicated IP during system configuration. You can
configure up to 100 inbound applications for each group of provisioned public IP addresses (either
5 or 10).

Secure Inbound Access Examples

This section provides inbound access examples, along with the IP addresses that Prisma Access
assigns in various deployments.
The following example shows a sample configuration to enable inbound access for an application
(www.example.com) at a remote network site. You assign an IP address of 10.10.10.2, a port of
443, and a protocol of TCP to the application. You then enter these values in Prisma Access when
you configure inbound access. After you save and commit your changes, Prisma Access assigns a
public IP address to the application you defined, in this case 52.1.1.1.
Prisma Access performs source network address translation (source NAT) on the packets
by default. If the IPSec-capable device at your remote network site is capable of performing
symmetric return (such as a Palo Alto Networks next-generation firewall), you can disable source
NAT.
The following figure shows the traffic flow from users to applications. Since source NAT is
enabled, the source IP address in the routing table changes from the IP of the user’s device
(34.1.1.1) to the remote network’s EBGP Router address (Panorama > Cloud Services > Status >
Network Details > Remote Networks > EBGP Router). (172.1.1.1).

Prisma Access Administrator’s Guide (Panorama Managed) 579 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

The following figure shows the return path of traffic with source NAT enabled.

Prisma Access Administrator’s Guide (Panorama Managed) 580 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

If you disable source NAT, Prisma Access still performs destination NAT, but the source IP
address of the request is unchanged.

Prisma Access Administrator’s Guide (Panorama Managed) 581 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

For return traffic, SNAT is disabled, and the destination address for all routing tables is user’s IP
address (34.1.1.1).

Prisma Access Administrator’s Guide (Panorama Managed) 582 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

If you have a resource that is in a remote network site that has inbound access enabled and you
want users at non-inbound access sites to have access to that resource, you can Allow inbound
flows to other Remote Networks over the Prisma Access backbone when you configure the non-
inbound access remote network.

If you allow inbound flows from other remote networks, you must enable source NAT.

Guidelines for Using Secure Inbound Access

Use the following guidelines and restrictions when you configure a remote network to use secure
inbound access:
• When you configure a remote network for inbound access, you add units (Mbps) from your
license for the IP addresses you allocate (150 Mbps for 5 IP addresses and 300 Mbps for 10
IP addresses). For this reason, make sure that you have enough remaining licensed bandwidth
to onboard the inbound access remote networks before you start. To check your available

Prisma Access Administrator’s Guide (Panorama Managed) 583 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

bandwidth, select Panorama > Cloud Services > Configuration > Remote Networks and
view your licensed Bandwidth Allocation. This area shows the bandwidth you have already
allocated, along with the total licensed bandwidth.

• The following locations are supported:

• Australia Southeast
• Belgium
• Brazil South
• Canada East
• Finland
• Germany Central
• Hong Kong
• India West
• Japan Central
• Japan South
• Netherlands Central
• Singapore
• Switzerland
• Taiwan
• UK
• US Central
• US East
• US Northwest
• US Southeast
• US Southwest
• You cannot modify an existing remote network to provide secure inbound access; instead,
create a new remote network.
• The inbound access feature is not available on remote networks that use ECMP load balancing.
• Application port translation is not supported.
• The bulk import feature to onboard remote networks does not support inbound access. Use
Panorama to onboard new inbound access remote networks.
• Do not use remote network inbound access with traffic forwarding rules with service
connections.
• Outbound traffic originating at the branch is not allowed on the inbound remote network.

Prisma Access Administrator’s Guide (Panorama Managed) 584 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• User-ID and application authentication are not supported.

• Prisma Access enforces the following rate limiting thresholds to provide flood protection, and
measures the rate in connections per second (CPS):

Flood Protection Type Alarm Rate in CPS Activate Rate in CPS

SYN Flood 10000 15000

ICMP Flood 20 20

• Remote networks that are configured for secure inbound access can only be used for that
purpose. If you require outbound access as well as inbound access for a remote network
site, create two remote network sites in the same location—one for inbound access and one
for outbound access—as shown in the following figure. In this example, User 1 uses Remote

Prisma Access Administrator’s Guide (Panorama Managed) 585 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Network 1 for inbound access to www.example.com, while User 2 uses Remote Network 2 for
outbound internet access from the remote network location.

• If you have a custom Prisma Access deployment where one of the cloud providers is excluded,
inbound access might not be supported; in this case, you cannot choose the location during
remote network onboarding.
• Secure inbound access is not supported with evaluation licenses.

Configure Secure Inbound Access for Remote Network Sites

Your deployment might onboard bandwidth by compute location or by location; either method is
supported for configuring remote network inbound access. When you configure inbound access
for a remote network that allocates bandwidth by compute location, you specify bandwidth on a
per-location basis. To create a remote network sites that allows secure inbound access, complete
one of the following workflows:

Prisma Access Administrator’s Guide (Panorama Managed) 586 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• To configure secure inbound access for a remote network deployment that allocates
bandwidth by compute location, complete this workflow.
• To configure secure inbound access for a remote network deployment that allocates
bandwidth by location, complete this workflow.
Configure Secure Inbound Access for Remote Network Sites for Locations that Allocate
Bandwidth by Location
If you have a Prisma Access deployment that allocates remote network bandwidth by location,
configure inbound access by completing the following steps.
STEP 1 | Select Panorama > Cloud Services > Configuration > Remote Networks, Add a connection,
and configure the remote network, including routing and IPSec tunnel options.
See Onboard and Configure Remote Networks for details. Your deployment might onboard
bandwidth by compute location or by location; either method is supported for inbound access.

Make sure that you are selecting one of the supported locations for Inbound Access.

STEP 2 | Click the Inbound Access tab to configure inbound access options.
1. Select Enable to enable inbound access for the remote network.
If you selected a location that is unsupported for inbound access, Prisma Access prompts
you to select a supported one.
2. (Optional) To disable source NAT, deselect Enable Source NAT.
By default, source NAT is enabled. If the IPSec-capable device at your remote network
site is capable of performing symmetric return (such as a Palo Alto Networks next-
generation firewall), or if you have not selected Allow inbound flows to other Remote
Networks over the Prisma Access backbone, deselect Enable source NAT.

You must Enable source NAT in the Inbound Access tab if you select this check
box. Source NAT is a requirement to allow inbound flows to other remote
networks.

STEP 3 | Add the applications to provide secure inbound access.

You can configure up to 100 inbound applications for each group of provisioned public IP
addresses (either 5 or 10). Enter a unique Private IP address, Protocol, and Port combination

Prisma Access Administrator’s Guide (Panorama Managed) 587 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

for each application. It is acceptable to use duplicate private IP addresses and ports for two
applications, as long as you select TCP for one application and UDP for another application.
Provide the following values:
• Specify the name of the Application.
• Specify the Private IP address to use with this application.
• Specify the Protocol to use with the application (TCP or UDP).
• Specify the Port to use with the application.
• Choose whether you want to dedicate a single public IP address to a single application; to
do so, select Dedicated IP.

STEP 4 | Click OK to save your changes.

STEP 5 | Save and Commit your changes.

STEP 6 | Wait approximately 30 minutes for Prisma Access to generate the public IP addresses; then
select Panorama > Cloud Services > Status > Network Details > Remote Networks and
make a note of the Public Address that is associated with the App Name for application you
created.
If you selected Dedicated IP, find the single application that is associated with the Public
Address.

STEP 7 | Create security policies to allow traffic from the inbound internet users.
Because Prisma Access’ default security policy only allows untrust-to-untrust traffic, you
need to configure security polices to allow untrust-to-trust traffic for your inbound access
applications. Palo Alto Networks recommends that you limit the type of access you permit to

Prisma Access Administrator’s Guide (Panorama Managed) 588 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

inbound applications. The following examples provide access to SSH servers, web portals, and
RDP servers.
1. Select Policies > Security and Add a policy.
Be sure to create this policy under the Remote_Network_Device_Group device group.
2. Select the Source traffic as Untrust.

3. Create a policy to allow SSH server traffic by selecting the Destination Zone for
destination traffic as Trust and specifying a Destination Address of SSH-server-public.

Prisma Access Administrator’s Guide (Panorama Managed) 589 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

This is an Address or Address Group object you created that has a list of all the public IP
addresses that are used for SSH login.

4. Select an Application of ssh.

5. Select a Service/URL Category of application-default to allow or deny applications

based only their default ports as defined by Palo Alto Networks.
6. In Actions, select Allow.
7. Click OK to save the policy.
8. Create a policy to allow web portal access by creating a policy in the previous steps but
substituting the following settings in the Destination and Application tabs:
• Select a Destination Address of an Address or Address Group of Web-Portal-Public,
which contains all the public IP addresses of the web portal.

Prisma Access Administrator’s Guide (Panorama Managed) 590 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• Select an Application of web-browsing.

9. Create a security policy for RDP server access, using the same settings as you did for
the other policies but creating an Address or Address Group object called RDP-Server-

Prisma Access Administrator’s Guide (Panorama Managed) 591 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Public, which contains the public IP addresses for the RDP server, as the Destination
Address and webrdp as the Application.
When complete, you have three different policies to allow SSH server access, web portal
access, and RDP server access.

STEP 8 | Save and Commit your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 592 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 9 | Check that the remote network connection is operational and correctly processing inbound
traffic.
1. Select Panorama > Cloud Services > Status > > Status > Remote Networks and hover
over the Status and Config Status areas to see the tunnel’s status.

2. If you find issues, select Panorama > Cloud Services > Status > > Monitor > Remote
Networks, select the location of the remote network tunnel in the map, and hover over
the Tunnel Status area to determine the cause of the error.

Configure Secure Inbound Access for Remote Network Sites

If you have a Prisma Access deployment that allocates remote network bandwidth by compute
location, configure inbound access by completing the following steps.

Prisma Access Administrator’s Guide (Panorama Managed) 593 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 1 | Select Panorama > Cloud Services > Configuration > Remote Networks, and select Inbound
Access Remote Networks.

STEP 2 | Add a remote network to for inbound access.

STEP 3 | Specify settings for the inbound access remote network connection.
1. Enter a Name for the inbound access connection.
2. Enter a Location.
Inbound access supports a subset of locations.
3. Specify a Bandwidth to use for the inbound access connection.
You allocate bandwidth for inbound access connections on a per-location basis.
4. Specify the Number of Public IPs to use for the inbound access connection.
Specify either 5 or 10 public IP addresses. Each public IP allocation takes bandwidth
(units) from your Remote Networks license, in addition to the bandwidth that you have
allocated for the compute location associated to the remote network.
5. Select the IPSec tunnel to use with the inbound access connection.
6. Select whether or not you want to Allow inbound flows to other Remote Networks over
the Prisma Access Backbone.
If you have a resource that is in a remote network site that has inbound access enabled
and you want users at non-inbound access sites to have access to that resource, you can
Allow Inbound Flows To Other Remote Networks over the Prisma Access Backbone
when you configure the non-inbound access remote network. If you allow inbound flows
from other remote networks, you must enable source NAT.
7. (Optional) If you have a secondary WAN link at this location, select Enable Secondary
WAN and provide an IPSec Tunnel that is different than the primary IPSec tunnel.

STEP 4 | Configure Static Routes, BGP, and QoS for your deployment.
This configuration is the same as a non-inbound access remote network connection.

STEP 5 | Click the Inbound Access tab to configure inbound access options.
1. (Optional) To disable source NAT, deselect Enable Source NAT.
By default, source NAT is enabled. If the IPSec-capable device at your remote network
site is capable of performing symmetric return (such as a Palo Alto Networks next-

Prisma Access Administrator’s Guide (Panorama Managed) 594 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

generation firewall), or if you have not selected Allow inbound flows to other Remote
Networks over the Prisma Access backbone, deselect Enable source NAT.

You must Enable source NAT in the Inbound Access tab if you select this check
box. Source NAT is a requirement to allow inbound flows to other remote
networks.

2. Add the applications to provide secure inbound access.

You can configure up to 100 inbound applications for each group of provisioned public
IP addresses (either 5 or 10). Enter a unique Private IP address, Protocol, and Port
combination for each application. It is acceptable to use duplicate private IP addresses
and ports for two applications, as long as you select TCP for one application and UDP for
another application.
Provide the following values:
• Specify the name of the Application.
• Specify the Private IP address to use with this application.
• Specify the Protocol to use with the application (TCP or UDP).
• Specify the Port to use with the application.
• Choose whether you want to dedicate a single public IP address to a single
application; to do so, select Dedicated IP.

STEP 6 | Click OK to save your changes.

STEP 7 | Save and Commit your changes.

STEP 8 | Wait approximately 30 minutes for Prisma Access to generate the public IP addresses; then
select Panorama > Cloud Services > Status > Network Details > Remote Networks and

Prisma Access Administrator’s Guide (Panorama Managed) 595 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

make a note of the Public Address that is associated with the App Name for application you
created.
If you selected Dedicated IP, find the single application that is associated with the Public
Address.

STEP 9 | Create security policies to allow traffic from the inbound internet users.
Because Prisma Access’ default security policy only allows untrust-to-untrust traffic, you
need to configure security polices to allow untrust-to-trust traffic for your inbound access
applications. Palo Alto Networks recommends that you limit the type of access you permit to

Prisma Access Administrator’s Guide (Panorama Managed) 596 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

inbound applications. The following examples provide access to SSH servers, web portals, and
RDP servers.
1. Select Policies > Security and Add a policy.
Be sure to create this policy under the Remote_Network_Device_Group device group.
2. Select the Source traffic as Untrust.

3. Create a policy to allow SSH server traffic by selecting the Destination Zone for
destination traffic as Trust and specifying a Destination Address of SSH-server-public.

Prisma Access Administrator’s Guide (Panorama Managed) 597 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

This is an Address or Address Group object you created that has a list of all the public IP
addresses that are used for SSH login.

4. Select an Application of ssh.

5. Select a Service/URL Category of application-default to allow or deny applications

based only their default ports as defined by Palo Alto Networks.
6. In Actions, select Allow.
7. Click OK to save the policy.
8. Create a policy to allow web portal access by creating a policy in the previous steps but
substituting the following settings in the Destination and Application tabs:
• Select a Destination Address of an Address or Address Group of Web-Portal-Public,
which contains all the public IP addresses of the web portal.

Prisma Access Administrator’s Guide (Panorama Managed) 598 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

• Select an Application of web-browsing.

9. Create a security policy for RDP server access, using the same settings as you did for
the other policies but creating an Address or Address Group object called RDP-Server-

Prisma Access Administrator’s Guide (Panorama Managed) 599 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Public, which contains the public IP addresses for the RDP server, as the Destination
Address and webrdp as the Application.
When complete, you have three different policies to allow SSH server access, web portal
access, and RDP server access.

STEP 10 | Save and Commit your changes.

Prisma Access Administrator’s Guide (Panorama Managed) 600 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 11 | Check that the remote network connection is operational and correctly processing inbound
traffic.
1. Select Panorama > Cloud Services > Status > > Status > Remote Networks and hover
over the Status and Config Status areas to see the tunnel’s status.

2. If you find issues, select Panorama > Cloud Services > Status > > Monitor > Remote
Networks, select the location of the remote network tunnel in the map, and hover over
the Tunnel Status area to determine the cause of the error.

Create a High-Bandwidth Network for a Remote Site

If you want to secure your branch office or site for outbound internet access with a high-
bandwidth connection to Prisma Access, you can load balance traffic from your branch office or
site using multiple IPSec tunnels by completing the steps in this section.

Prisma Access Administrator’s Guide (Panorama Managed) 601 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

The following diagram shows four remote network connections that use the same remote site.
Before onboarding, assign 4 Gbps (4000 Mbps) to the compute location, which is South Korea
in this example and corresponds to the remote site. 4000 Mbps provides four IPSec termination
nodes and each IPSec termination node provides a maximum of 1000 Mbps of bandwidth. Assign
each remote network connection its own IPSec termination node during the onboarding process
to utilize the complete bandwidth.

This example shows four tunnels. The maximum number of tunnels you can use for a
high-bandwidth connection in Prisma Access is based on the maximum number of IPSec
tunnels your customer premises equipment (CPE) support with the load balancing protocol
you use.

Consider the following restrictions and recommendations before you deploy this configuration:
• Use BGP routing for the IPSec tunnels; static routing is not supported.
• Use this configuration for outbound internet access only.
• Do not use tunnel monitoring on either Prisma Access or the CPE. Availability of the IPSec
tunnel is determined by BGP peering between the CPE and Prisma Access’ remote network. If
an IPSec tunnel goes down and BGP connection is interrupted, the routes learned over BGP on
that tunnel are automatically removed from ECMP.
• Because you use BGP to determine when a tunnel goes down, consider the HoldTime value
you have configured on your CPE. The hold timer determines the amount of time that the
tunnel is down before removing the route. Prisma Access uses the default BGP HoldTime value
of 90 seconds as defined by RFC 4271. If you configure a lower hold time for the BGP CPE in
the remote network site, BGP uses the lower hold time value. Palo Alto Networks recommends
a KeepAlive value of 10 seconds and a HoldTime value of 30 seconds for your CPE with this
deployment.

Prisma Access Administrator’s Guide (Panorama Managed) 602 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Create a High-Bandwidth Remote Network Connection

To create a high-bandwidth remote network connection, complete the following task.

Prisma Access Administrator’s Guide (Panorama Managed) 603 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 1 | in Panorama, configure the Prisma Access remote network tunnels.

1. (Optional) if you haven’t already, set up IKE gateways, IKE crypto and IPSec crypto
profiles, and IPSec tunnels for the remote network connections you create.
Make a note of the IKE and IPSec cryptographic profiles; you specify the same settings
on the CPE you use to terminate the remote network connection in the remote network
location.
2. Determine the type of remote network deployment you have.
Prisma Access deployments allocate bandwidth by allocating bandwidth per compute
location or by allocating bandwidth by location.
3. Onboard the remote network.
• To onboard the remote network that allocates bandwidth by compute location:
1. Allocate bandwidth for the locations that you want to onboard by clicking the gear
icon in the Bandwidth Allocation area.

2. Enter the Bandwidth Allocation you want for each Compute Location that is
associated with the Prisma Access Locations you want to onboard.
3. Wait for the bandwidth to be reflected in the Allocated Total field at the top of the
page; then, click OK.
• To onboard the remote network that allocates bandwidth by location, continue to the
next step; you allocate bandwidth during remote network onboarding.
4. Select Panorama > Cloud Services > Configuration > Remote Networks and create four
remote network connections, specifying the following settings:
• Select the same Location for each connection.
• Select the IPSec Termination Node.
Select a separate IPSec termination node for each remote network connection.

If you have a deployment that allocates bandwidth by location, select a

Bandwidth of 500 Mbps.

The bandwidth you select cannot exceed the total amount of bandwidth you have
licensed. Use this setting to define the amount of the total licensed bandwidth you
want to allocate to this location.
• Enable BGP, Advertise Default Route, and Don’t Advertise Prisma Access Routes.
• Specify the same Peer AS for all remote network connections.

Prisma Access Administrator’s Guide (Panorama Managed) 604 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

This example shows a Peer AS of 2000; in this example, you select a Peer AS of 2000
for all four connections.
• (Optional) if you want to create a backup remote network, create one by selecting
Enable Secondary WAN; then, select the IPSec Tunnel you created for the backup
tunnel.
Configuring a Secondary WAN is not supported in the following deployments:
• If your secondary WAN is set up in active-active mode with the Primary IPSec tunnel.
• If your customer premises equipment (CPE) is set up in an Equal Cost Multipath
(ECMP) configuration with the Primary and Secondary IPSec tunnel.

When complete, you have four 1000 Mbps remote network connections for the same
location.
Since deployments that allocate bandwidth by location have a maximum bandwidth of
500 Mbps, this configuration would provide you with 500 Mbps for each location.

Prisma Access Administrator’s Guide (Panorama Managed) 605 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

If you configured backup tunnels, you also have four secondary tunnels to be used for
failover purposes.

5. Select Panorama > Cloud Services > Status > Network Details > Remote Networks and
make a note of the Service IP Address and EBGP Router addresses.
You use the Service IP Address as the peer IP address when you configure the IPSec
tunnel on the CPE in the remote network site, and you use these addresses and the
EBGP Router addresses when you create static routes on the CPE.

STEP 2 | On the CPE in the remote network site, configure the remote network tunnels.

• The configuration in these steps use Palo Alto Networks next-generation firewalls;
you can use any CPE device that supports IPSec tunnels and ECMP for this
deployment.
• Bandwidth balancing depends on CPE hashing for ECMP. However, Prisma Access
ensures symmetrical return of traffic.

1. Create four active tunnels from the active CPE to each of the four network connections.
For the Peer IP address, enter the Service IP Address of the remote network you
received from Prisma Access in Step 5.

2. (Optional) If you create backup tunnels, create them from the active CPE to each of the
four network connections. For the Peer IP address, enter the Service IP Address of the
remote network you received from Prisma Access in Step 5.

Prisma Access Administrator’s Guide (Panorama Managed) 606 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 3 | Configure ECMP on the CPE in the remote network site.

1. Select Network > Virtual Routers.
2. Select the default virtual router, or Add a new virtual router.
3. Select Router Settings > Enable > ECMP, then Enable ECMP with a Max Path of 4 and a
load balance Method of Balanced Round Robin.

STEP 4 | On the CPE in the remote network site, create static routes to the Prisma Access Service IP
Address and EBGP Router IP addresses you retrieved in Step 5.
As previously stated, dynamic routing with BGP is required for this configuration. To facilitate
BGP connection between the CPE and Prisma Access’ eBGP router, you need to add a static
route for the eBGP router IP address on the CPE, and the next-hop must be the tunnel
interface on the CPE. You must repeat this step for all other Remote Network eBGP router IP
addresses on remaining tunnels.
The following example shows the route on the active CPE. If you created backup tunnels on a
standby CPE, create the same routing on the standby CPE.
If you are configuring a Palo Alto Networks next-generation firewall, select Static Routes >
IPv4 to add the static routes.

Prisma Access Administrator’s Guide (Panorama Managed) 607 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 5 | Enable route redistribution on the CPE by selecting Redistribution Profile > IPv4, then Add
an IPv4 route redistribution profile.

STEP 6 | Select BGP > Peer Group, Enable BGP on the virtual router instance, then Add Remote
Network BGP peers.

STEP 7 | Select BGP > Redist Rules, then attach the route redistribution profile you created in Step 5.

STEP 8 | Validate that the CPE is passing traffic on all four of its tunnels.

Prisma Access Administrator’s Guide (Panorama Managed) 608 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

STEP 9 | Check the status of the ECMP-enabled connections from Prisma Access.
• Select Panorama > Cloud Services > Monitor > Remote Networks, select the region where
you deployed the ECMP connections, then select Status.

• In this area, ECMP displays as No. This is expected because you are not
configuring the Prisma Access ECMP load balancing feature.
• ECMP is directional from CPE to Prisma Access and Prisma Access ensures
symmetrical return of the traffic from the CPE.

• Select Statistics to see that traffic is passing through each remote network tunnel.

When you have completed this workflow, you have created a high-bandwidth configuration
for the remote network. Keep in mind that this solution is supported for outbound traffic only.

Prisma Access Administrator’s Guide (Panorama Managed) 609 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Prisma Access Advanced Deployments

Prisma Access Administrator’s Guide (Panorama Managed) 610 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma
Access for Clean Pipe
Use Prisma Access for Clean Pipe to quickly and easily configure multiple instances of clean
outbound internet connections.
• Prisma Access for Clean Pipe Overview
• Configure Prisma Access for Clean Pipe

611
Create and Configure Prisma Access for Clean Pipe

Prisma Access for Clean Pipe Overview

To allow organizations that manage the IT infrastructure of other organizations, such as service
providers, MSSPs, or Telcos, to quickly and easily protect outbound internet traffic for their
tenants, Palo Alto Networks provides Prisma Access for Clean Pipe. A service provider, MSSP, or
Telco can route their customers (configured as tenants) to Prisma Access for Clean Pipe using a
Partner Interconnect. After the traffic crosses the Partner Interconnect, it will be sent to a tenant-
dedicated instance of the Clean Pipe for security, and then routed to the Internet.
Prisma Access for Clean Pipe also provides an API that you can use to quickly and easily create
Clean Pipes for your tenants.
• Clean Pipe Use Cases
• Clean Pipe Examples
• Clean Pipe and Partner Interconnect Requirements

Clean Pipe Use Cases

Use Prisma Access for Clean Pipe if you meet all of the following use cases:
• You manage a network deployment with a large number of tenants.
For example, you are a service provider, Telco, or MSSP who manages and maintains the
networks of many different organizations (up to tens of thousands).
• You want a way for each tenant in your deployment to have their outbound internet traffic
secured.
• You need a fast and scalable way to onboard Clean Pipes for the organizations whose networks
you manage.
• With the exception of outbound internet security, you do not have additional requirements to
protect the mobile users, headquarters, or branch locations of the networks you manage.
If you have additional security requirements, we recommend creating multiple tenants in
Prisma Access instead of implementing Clean Pipe, which allows you to create and enforce
security profiles for separate groups of remote networks and mobile users.

Clean Pipe Examples

The following figure provides an example of Clean Pipes configured for a single tenant, with
multiple Clean Pipes configured for the tenant.
In this example, the service provider manages the internet connectivity for four organizations and
wants to protect outbound internet access for them. The service provider creates a Google Cloud
Platform (GCP) Partner Interconnect and creates a VLAN attachment for each tenant. The service
provider configures Prisma Access for Clean Pipe using Panorama to create security for the VLAN
attachment.
This example shows a single Clean Pipe per tenant. You can also create multiple Clean Pipes in a
single tenant. Make sure that each Clean Pipe you specify for a tenant uses a different location.

Prisma Access Administrator’s Guide (Panorama Managed) 612 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

The following figure shows a single Clean Pipe in more detail for a tenant who wants a clean
connection to the internet. The Customer Edge (CE) router provides WAN connectivity for the
tenant. The CE router connects to a cloud router, and the cloud router provides connectivity
for the Partner Interconnect. The service provider creates a VLAN attachment for the tenant,
and configures Prisma Access for Clean Pipe in Panorama to provide security for the VLAN
attachment, which protects the tenant’s internet-based traffic.

Clean Pipe and Partner Interconnect Requirements

Before you start, be aware of the following Clean Pipe deployment requirements, and be aware
of the following differences between Prisma Access for Clean Pipe and other Prisma Access
deployments:

Prisma Access Administrator’s Guide (Panorama Managed) 613 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

• You must have a Prisma Access for Clean Pipe license.

The Prisma Access for Clean Pipe license is a separate license from other Prisma Access
products. However, the same requirements for purchasing and installing Panorama and Cortex
Data Lake licenses apply to Clean Pipe.
• Prisma Access for Clean Pipe has the following GCP Partner Interconnect requirements:
• You must be able to create a Partner Interconnect in GCP.
• You must have the ability to create VLAN attachments in GCP.
• For Layer 2 (L2) partner interconnects, you must have access to the customer edge (CE)
router on the MSSP side and be able to make configuration changes to it.
For more information about GCP configuration, refer to the GCP documentation.
• Be aware of the minimum bandwidth requirements for the Clean Pipe deployment.
The minimum license you can purchase is 1000 Mbps. The minimum bandwidth allocation for
each Clean Pipe tenant is 100 Mbps.
After you create a tenant, you can create clean pipes in that tenant. Each clean pipe must be
a minimum of 100 Mbps. Each Clean Pipe shares the tenant’s access domain, templates and
template stack, and device group.
• If configuring multiple Clean Pipes for a single tenant, each Clean Pipe is required to be
a unique location. If you want to configure two VLAN attachments for a single Clean
Pipe location in an active/backup configuration for intra-zone redundancy, specify the
REDUNDANT choice when you add a new Clean Pipe instance.
• When creating a connection within a Clean Pipe tenant, match the bandwidth allocation to that
of the VLAN attachment. Do not create a VLAN attachment that has a bandwidth that is higher
or lower than the connection's bandwidth.
• After you enable multitenancy, do not configure your Clean Pipe deployment with any of the
other tabs in the Configuration area, with the exception of the Generate API key link in the
Service Setup tab, which lets you generate an API key to retrieve Clean Pipe IP addresses. All
configuration is unique to Prisma Access for Clean Pipe and separate from other Prisma Access
deployments, such as Prisma Access for Networks or Prisma Access for Users.
• Do not make changes to a Clean Pipe configuration after you commit it. If you change a Clean
Pipe after it’s been committed, you will receive a commit error when you re-commit it. Instead,
delete the existing Clean Pipe and add a new one. Schedule this change during a system
downtime window. If you already made changes and have not yet committed, you can revert
the changes by editing the Clean Pipe configuration back to their previous values.

Prisma Access Administrator’s Guide (Panorama Managed) 614 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

• Note that the locations used by Clean Pipe differ from other Prisma Access deployments.
Prisma Access for Clean Pipe supports the following locations:
• asia-east1
• asia-east2
• asia-northeast1
• asia-south1
• asia-southeast1
• australia-southeast1
• europe-north1
• europe-west2
• europe-west3
• europe-west4
• northamerica-northeast1
• southamerica-east1
• us-central1
• us-east1
• us-east4
• us-west1
• us-west2
• Note the following networking restrictions for Clean Pipe:
• QoS for Clean Pipe is supported on ingress (from internet to Clean Pipe direction) only.
• User-ID is not supported.
• Clean Pipe supports session affinity based on source and destination IP addresses and is not
configurable.
• Trust-to-Trust policies are invalid for Clean Pipe, because the traffic is always internet-
bound. Only use Trust-to-Untrust policies.

Prisma Access Administrator’s Guide (Panorama Managed) 615 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

Configure Prisma Access for Clean Pipe

To set up Prisma Access for Clean Pipe for your tenants, complete the following steps.
• Enable Multitenancy and Create a Tenant
• Complete the Clean Pipe Configuration

Enable Multitenancy and Create a Tenant

To begin the Clean Pipe configuration, you create a multitenant deployment in Panorama and
create one or more tenants.
STEP 1 | Install and activate Prisma Access for Clean Pipe.
Prisma Access for Clean Pipe requires a separate license, and activating it creates Clean Pipe-
specific tabs in the Cloud Services plugin. The procedure you use to install Prisma Access
for Clean Pipe is the same as the procedure you use to activate and install a standard Prisma
Access license, including installing the Cloud Services plugin.

Prisma Access Administrator’s Guide (Panorama Managed) 616 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

STEP 2 | Enable multitenancy if you have not done so already.

1. Select Panorama > Cloud Services > Configuration.
2. Select Enable Multitenancy (located on the upper right of the page).
3. Click OK.
The Tenants page displays.
4. In the Options area, select Clean Pipe.
To configure a tenant for remote networks, mobile users, or both, see Manage Multiple
Tenants in Prisma Access.

5. Enter a Name for the first tenant.

6. Create and configure a new Access Domain for the first tenant and click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 617 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

7. In the Clean Pipe area, enter a Bandwidth (Mbps) for This Tenant.
Enter a minimum of 100 Mbps for each tenant you create.
8. Click OK.

Prisma Access Administrator’s Guide (Panorama Managed) 618 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

STEP 3 | Create zones for the tenant and map those zones for the tenant.
1. Select Network > Zones.
Make sure that selected the Clean Pipe Template for the tenant you created (cp-
tpl-tenant).
2. Create zones for the tenant (for example, Trust and Untrust).
3. Select Panorama > Cloud Services > Configuration and select the Tenant from the drop-
down list.
4. Select the Clean Pipe tab.
5. Click the gear icon next to Zone Mapping to edit the settings.
6. Add and Remove the zones you created to map them to trusted and untrusted zones.

STEP 4 | Onboard a new Clean Pipe.

1. Select Panorama > Cloud Services > Configuration > Clean Pipe.
2. Add a new Clean Pipe instance for the tenant, entering the following information:
• Name—Specify a name for the clean pipe.
• Bandwidth—Select the Bandwidth to allocate for the clean pipe.
You can onboard Clean Pipe instances in increments of 100 Mbps, 200 Mbps, 300
Mbps, 400 Mbps, 500 Mbps, 1000 Mbps, 2000 Mbps, 5000 Mbps, and 10000
Mbps. The amount of bandwidth you specify must be within the licensed bandwidth

Prisma Access Administrator’s Guide (Panorama Managed) 619 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

allocation, and it must match the bandwidth of the VLAN attachment you create in
the Partner Interconnect.
• Edge Availability Domain—Select the availability domain you want for the clean pipe.
You can choose 1, 2, ANY, or REDUNDANT.
• Specify ANY for a non-redundant Clean Pipe deployment.
Make sure that your cloud provider supports this choice; you must also select
ANY on the cloud provider side of the partner interconnect. If that choice is not
available for your cloud provider, make another choice.
• To specify two VLAN attachments in the same location in an active/backup
configuration in the same location, select REDUNDANT.
Prisma Access creates two pairing keys for a REDUNDANT configuration (one for
each availability zone), and appends the clean pipe name with zone1 for the first
availability zone and zone2 for the second availability zone. For example, if you

Prisma Access Administrator’s Guide (Panorama Managed) 620 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

specify a Name of San Francisco, Prisma Access creates two zones named San
Francisco-zone1 and San Francisco-zone2.

Be sure that you configure the first availability zone (zone1) as the primary
zone on your CPE.

You can also build a pair of clean pipes for a single tenant redundancy in different
locations; to do so, specify 1 for the first clean pipe in one location and 2 for the
second clean pipe in a different location.
• BGP Peer ASN—Enter the BGP Autonomous System Number (ASN).
You can specify either a private or public BGP ASN.
Make a note of this value; you configure it on the customer edge (CE) router when
you complete the Clean Pipe configuration.
• Location—Select the location.
We recommend that you use the same location that you use when you create the
VLAN attachment for the partner interconnect.
• To enable QoS, select QoS, then select the QoS Profile to use with the clean pipe.
Clean Pipe QoS shapes on ingress.

STEP 5 | Add more Clean Pipe instances as required by repeating Step 4.

Be sure that each additional Clean Pipe uses a different location.

Prisma Access Administrator’s Guide (Panorama Managed) 621 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

STEP 6 | Commit and push your changes to make them active in Prisma Access.
1. Select Commit > Commit and Push and Edit Selections in the Push Scope.
2. Select Prisma Access, then select Clean Pipe.

3. Click OK to save your changes to the Push Scope.

4. Commit and Push your changes.

STEP 7 | Check that your Clean Pipe has been provisioned.

1. Select Panorama > Cloud Services > Status.
2. Select the Tenant from the drop-down list at the top of the page.
3. Click Status.
The Clean Pipe status displays.
4. Hover over the Clean Pipe Config Status and wait until the status changes from
Provisioning in Progress to Provisioned.
This provisioning can take up to 30 minutes.

STEP 8 | Click the Network Details tab, click the Clean Pipe radio button, and make a note of the
Pairing Key.
The MSSP CE and Cloud Router IP fields are blank when you start to configure the Clean Pipe.
These fields populate after you create the VLAN Attachment when you complete the Clean
Pipe configuration.
If you specified a REDUNDANT connection, Prisma Access creates two pairing keys, one for
each availability zone, and appends the clean pipe name with zone1 for the first availability

Prisma Access Administrator’s Guide (Panorama Managed) 622 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

zone and zone2 for the second availability zone. The following screenshot shows the
SanFrancisco clean pipe with a redundant configuration; Prisma Access has created two
pairing keys, one for SanFrancisco-zone1 and one for SanFrancisco-zone2.

Be sure that you configure the first availability zone (zone1) as the primary zone on
your CPE.

STEP 9 | Complete the Clean Pipe Configuration.

Complete the Clean Pipe Configuration

To complete configuration of Prisma Access for Clean Pipe, you perform configuration in the
Partner Interconnect and in Panorama.

Make sure that you can access and configure the CE and cloud routers on the Partner
Interconnect (non-Prisma access) side of the Partner Interconnect.

STEP 1 | In the Partner Interconnect side of the configuration, create a VLAN attachment, using the
Pairing Key that you retrieved from Panorama.
For more information about creating VLAN attachments with Partner Interconnects and
configuring customer edge (CE) routers to communicate with cloud routers, refer to the
Google Cloud documentation at https://cloud.google.com/interconnect/docs/
Make sure that the location and bandwidth you select matches the Location you specified
in Panorama. The service provider you use for the Partner Interconnect uses the pairing key,
along with your requested connection location and capacity, to complete the configuration of
your VLAN attachment.

STEP 2 | After the connection comes up, return to Panorama, select Panorama > Cloud Services >
Status > Network Details > Clean Pipe and make a note of the MSSP CE and Cloud Router
IP addresses.
These values populate after you enter the Pairing Key on the other side of the VLAN
attachment.

Prisma Access Administrator’s Guide (Panorama Managed) 623 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

STEP 3 | Log in to the CE router and perform the following configuration.

1. Enter the MSSP CE address as the local IP address.
2. Enter the Cloud Router IP address as the peer IP address.
3. Enter a BGP ASN that matches the BGP Peer ASN you entered when you configured the
Clean Pipe in Panorama.
Make sure that you enter these values correctly; you cannot change them.

Prisma Access Administrator’s Guide (Panorama Managed) 624 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

STEP 4 | Check the Clean Pipe status.

1. In Panorama, select Panorama > Cloud Services > Status, select the Tenant from the
drop-down, and check the Clean Pipe’s Status.
See the list of Prisma Access locations for acceptable values.
The Deployment Status area allows you to view the progress of onboarding and
deployment jobs before they complete, as well as see more information about the status
of completed jobs. See Prisma Access Deployment Progress and Status for details.

2. Select Panorama > Cloud Services > Status > Clean Pipe, and click the Monitor tab to
see a map with the status of the deployed Clean Pipes.

Prisma Access Administrator’s Guide (Panorama Managed) 625 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

Click the tabs below the map to see additional statistics for the Clean Pipes.
Status tab:
• Compute Region—The compute region where your cloud service infrastructure is
deployed for the clean pipe instance.
• Name—The name of the clean pipe instance.

Prisma Access Administrator’s Guide (Panorama Managed) 626 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

• Allocated Bandwidth (Mbps)—The amount of bandwidth you allocated for the clean
pipe instance.
• Config Status—The status of your last configuration push to the service. If you have
made a change locally, and not yet pushed the configuration to the cloud, the status
shows Out of sync. Hover over the status indicator for more detailed information.
After committing and pushing the configuration to Prisma Access, the Config Status
changes to In sync.
• BGP Status—Displays information about the BGP state between the firewall or router
at the clean pipe instance and Prisma Access. Although you might temporarily see the

Prisma Access Administrator’s Guide (Panorama Managed) 627 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

status pass through the various BGP states (idle, active, open send, open pend, open
confirm, most commonly, the BGP status shows:
• Connect—The router at the clean pipe instance is trying to establish the BGP peer
relationship with the cloud firewall.
• Established—The BGP peer relationship has been established.
This field will also show if the BGP connection is in an error state:
• Warning—There has not been a BGP status update in more than eight minutes.
This may indicate an outage on the firewall.
• Error—The BGP status is unknown.
• Status—The operational status of the connection between Prisma Access and the
clean pipe instance.
Statistics tab:
• Region—The region where your cloud service infrastructure is deployed for the clean
pipe instance.
• Name—The name of the clean pipe instance.
• Allocated Bandwidth (Mbps)—The amount of bandwidth you allocated for the remote
network location.
• QoS— Select QoS to display a page that contains graphical QoS statistics.
• Avg Egress Bandwidth 5 Min (Mbps)—The average amount of clean pipe egress
bandwidth averaged over 5 minutes.
• Avg Egress Bandwidth 60 Min (Mbps)—The average amount of clean pipe egress
bandwidth averaged over 60 minutes.
• Avg Ingress Bandwidth 5 Min (Mbps)—The average amount of clean pipe ingress
bandwidth averaged over 5 minutes.
• Avg Ingress Bandwidth 60 Min (Mbps)—The average amount of clean pipe ingress
bandwidth averaged over 60 minutes.
• Egress Peak Bandwidth 1 Hour (Mbps)—The amount of peak egress bandwidth for
the clean pipe instance for the last 1 hour.
• Egress Peak Bandwidth 24 Hour (Mbps)—The amount of peak egress bandwidth for
the clean pipe instance for the last 24 hours.
• Egress Peak Bandwidth 7 Days (Mbps)—The amount of peak egress bandwidth for
the clean pipe instance for the last 7 days.
• Egress Peak Bandwidth 30 Days (Mbps)—The amount of peak egress bandwidth for
the clean pipe instance for the last 30 days.
• Ingress Peak Bandwidth 1 Hour (Mbps)—The amount of peak ingress bandwidth for
the clean pipe instance for the last 1 hour.
• Ingress Peak Bandwidth 24 Hour (Mbps)—The amount of peak ingress bandwidth for
the clean pipe instance for the last 24 hours.
• Ingress Peak Bandwidth 7 Days (Mbps)—The amount of peak ingress bandwidth for
the clean pipe instance for the last 7 days.

Prisma Access Administrator’s Guide (Panorama Managed) 628 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

• Ingress Peak Bandwidth 30 Days (Mbps)—The amount of peak ingress bandwidth for
the clean pipe instance for the last 30 days.

Prisma Access Administrator’s Guide (Panorama Managed) 629 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation
Create and Configure Prisma Access for Clean Pipe

Prisma Access Administrator’s Guide (Panorama Managed) 630 ©2024 Palo Alto Networks, Inc.
Version 3.2 Preferred and Innovation