DESIGN

GUIDE

SASE for Securing Private Applications

JUNE 2024
 Table of Contents

Table of Contents
Preface......................................................................................................................................................................................................... 3
Purpose of This Guide................................................................................................................................................................................ 5
Audience.............................................................................................................................................................................................. 5
Related Documentation........................................................................................................................................................................5
Introduction.................................................................................................................................................................................................. 7
On-Premises Solution Challenges........................................................................................................................................................ 7
Secure Access Service Edge...............................................................................................................................................................8
Palo Alto Networks SASE Solution...................................................................................................................................................... 8
Prisma Access Add-On Capabilities.................................................................................................................................................. 13
Design Details............................................................................................................................................................................................19
Prisma Access Design Details........................................................................................................................................................... 19
Prisma SD-WAN Design Details.........................................................................................................................................................55
Design Model.............................................................................................................................................................................................88
Securing Private Apps for Mobile Users............................................................................................................................................ 88
Securing Private Apps for Remote Sites..........................................................................................................................................103
Summary.................................................................................................................................................................................................. 106
Feedback..................................................................................................................................................................................................107

Palo Alto Networks 2

 Preface

Preface
GUIDE TYPES

Overview guides provide high-level introductions to technologies or concepts.

Design guides provide an architectural overview for using Palo Alto Networks® technologies to provide visibility, control, and
protection to applications built in a specific environment. These guides are required reading prior to using their companion
deployment guides.

Deployment guides provide decision criteria for deployment scenarios, as well as procedures for combining Palo Alto
Networks technologies with third-party technologies in an integrated design.

Solution guides provide add-on solutions for post-deployment use cases.

DOCUMENT CONVENTIONS

Blue text indicates a configuration variable for which you need to substitute the correct value for your environment.

In the IP box, enter 10.5.0.4/24, and then click OK.

Bold text denotes:

• Command-line commands.

# show device-group branch-offices

• User-interface elements.

In the Interface Type list, choose Layer 3.

• Navigational paths.

Navigate to Network > Virtual Routers.

• A value to be entered.

Enter the password admin.

Palo Alto Networks 3

 Preface

Italic text denotes the introduction of important terminology.

An external dynamic list is a file hosted on an external web server so that the firewall can import objects.

Highlighted text denotes emphasis.

Total valid entries: 755

ABOUT PROCEDURES
These guides sometimes describe other companies’ products. Although steps and screen-shots were up-to-date at the time
of publication, those companies might have since changed their user interface, processes, or requirements.

GETTING THE LATEST VERSIONS OF GUIDES

We continually update reference architecture guides. You can access the latest version of this and all guides at this location:

https://www.paloaltonetworks.com/referencearchitectures

WHAT'S NEW IN THIS RELEASE

Since the last version of this guide, Palo Alto Networks made the following changes:

• Added information for Prisma® SASE 3.0

• Added Remote Browser Isolation and App Acceleration to the Prisma Access Add-On section

• Updated naming of Cortex® Data Lake to Strata™ Logging Service

• Replaced SD-WAN CloudBlade integration with Prisma Access with the SD-WAN easy onboarding process

• Moved ADEM design details to a separate solution guide

• Changed phrasing, terminology, and diagrams for technical accuracy

Palo Alto Networks 4

 Purpose of This Guide

Purpose of This Guide

The Palo Alto Networks secure access service edge (SASE) solution is built on two components: Prisma Access and
Prisma SD-WAN. This guide describes reference architectures for integrating Prisma Access and Prisma SD-WAN into your
organization. The design includes guidance for securing internal application access for mobile users connecting through
Prisma Access and remote sites (or branches) connecting via SD-WAN.

This guide:

• Provides a framework for Prisma Access and Prisma SD-WAN architectural discussions between Palo Alto Networks
and your organization.

• Describes the technical design aspects of Prisma Access and how an organization uses it for secure access to private
applications.

• Provides a technical overview and design for the Prisma Access GlobalProtect® mobile-user connection method for
secure access to internal applications.

• Describes the technical concepts for Prisma SD-WAN that enable policy enforcement based on business intent,
enable dynamic path selection, and provide visibility into performance and availability for applications and networks.

This design guide focuses specifically on securing access to private applications. For a more complete discussion of how to
secure access to internet and SaaS applications, refer to the SASE for Securing Internet: Design Guide.

AUDIENCE
This guide is for technical readers, including system architects and design engineers, who want to deploy Prisma Access. It
assumes the reader is familiar with the basic concepts of applications, networking, routing, security, and high availability. The
reader should also have a basic understanding of network and data center architectures.

To be successful, you must have a working knowledge of networking and security policy.

RELATED DOCUMENTATION
The following documents support this guide:

• SASE: Overview—Introduces the benefits and components of Palo Alto Networks full-featured SASE solution.

• SASE for Securing Private Applications: Deployment Guide—Provides implementation details for using Prisma
Access and Prisma SD-WAN to secure access to private applications for mobile users and users located at
remote-site locations. Includes decision criteria for deployment scenarios, as well as step-by-step procedures for
programming features to achieve an integrated design.

• SASE for Securing Internet: Design Guide—Provides design and deployment guidance for using Prisma Access
and Prisma SD-WAN to secure internet access for mobile users and users located at remote-site locations.

Palo Alto Networks 5

 Purpose of This Guide

• SASE for Securing Internet: Deployment Guide—Provides implementation details for using Prisma Access and
Prisma SD-WAN to secure internet access for mobile users and users located at remote-site locations. Includes
decision criteria for deployment scenarios, as well as step-by-step procedures to achieve an integrated design.

• Identity-Based and Posture-Based Security for SASE: Solution Guide—Provides design and deployment
guidance for obtaining and applying identity-based and posture-based policies in Palo Alto Networks SASE platform.

• AI-Powered Autonomous Digital Experience Management: Solution Guide—Provides design, deployment, and
operational guidance for integrating ADEM and AI-Powered ADEM with the Palo Alto Networks Prisma SASE solution.

• SASE Network Segmentation: Solution Guide—Provides design and deployment guidance for network
segmentation in remote-site environments by using Palo Alto Networks Prisma SD-WAN solution.

• Securing Private Application Access with ZTNA Connector: Solution Guide—Provides design and deployment
guidance for securing private application access by using Palo Alto Networks Prisma Access and ZTNA Connector.

Palo Alto Networks 6

 Introduction

Introduction
As organizations shift towards new operational frameworks, they often encounter difficulties in providing network and security
services efficiently. Users demand quick and easy access to products and services. They want to use a diverse array of
devices to connect to applications from virtually any location. Additionally, companies are embracing digital technologies
across their operations in order to enhance efficiency, execution speed, and cost savings. This process is known as digital
transformation.

Historically, a sizable portion of employees would be based at a main office or a remote site, where IT organizations could
effectively manage network and security provisions. Employees increasingly demand the freedom to be productive from
anywhere while using any device and accessing any application. Homes, coffee shops, and mobile phones have become
seamless extensions of the corporate network. Many organizations also need to allow contractors or other third parties
access to applications or network resources.

The changing work locations of an organization's workforce highly influences the delivery of network and security services.
To support this, companies have turned to multiple secure access tools, network sensors, and management panes in place.
This creates challenges in maintaining operational efficiency, ensuring consistent security policy, and achieving a unified
view of your network security. The consequence of all these shifts is that they still often fail to offer satisfactory application
performance.

ON-PREMISES SOLUTION CHALLENGES

Traditionally, mobile users would connect through an on-site VPN concentrator, and the centralized security appliances
would govern their access. This model's advantage lay in its ability to enforce uniform security policies across all users and
devices. Nevertheless, complications arise with managing and scaling this infrastructure to accommodate access to private
applications and the internet, particularly when supporting multiple locations and the implications of backhauling user traffic.

Data traffic from users at branch offices destined to private applications or the internet was once straightforward to secure
and manage with a centralized arrangement of security appliances and a hub-and-spoke network topology that used
either a private MPLS WAN or a VPN WAN over public internet. Private WAN networks excel at providing access to private
applications. However, in most cases, using a private WAN network to provide centralized internet access does not provide
the best user experience.

Properly overcoming these challenges requires a different approach. For optimal performance in accessing both private
applications and the internet, a decentralized model is necessary. This involves providing localized service access and placing
security enforcement points near both mobile users and branch offices, ensuring consistent security policies for all users.
This strategy is also pertinent for hybrid workers who split their time between mobile work and on-site. The solution must be
easy to manage and scale, provide cost-effective and pervasive coverage, and deliver the best performance for applications,
regardless of their location.

Palo Alto Networks 7

 Introduction

SECURE ACCESS SERVICE EDGE

SASE is a concept in the industry that encapsulates the blend of technologies needed to safeguard access to data and
applications, no matter if users are in the office, at home, or working from another location. SASE represents a group of
services and products that combine both the delivery of data (transport) and its protection (security) into a single cloud-native
solution that is managed and integrated.

The main operational characteristics of a SASE-enabled network are the following:

• Cloud-native, cloud-based delivery—Uses many points of presence to reduce latency, with support of in-country or
in-region resources and regulatory requirements.

• Converged WAN edge and network security—Provides true integration of services, not service chains, with
combined services and visibility for all locations, mobile users, and the cloud.

• Broad network-edge support—Takes you beyond box-based access support with agent-based capability managed
as a cloud service.

• Identity and network location—Provides policy enforcement beyond IP address by using identity-based policy
enforcement with real-time conditions like device-type, posture, and location.

Organizations moving to a SASE-based deployment should look for integration across the following essential components of
the solution:

• Cloud secure web gateway (SWG)—Provides URL filtering, application control, and threat detection and prevention
for users' web sessions.

• Firewall as a Service (FWaaS)—Provides a cloud-native NGFW that allows advanced Layer 7 inspection, access
control, threat detection and prevention, and other security services.

• Cloud access security broker (CASB)—Monitors the use of sanctioned and unsanctioned SaaS applications,
provides malware and threat detection in SaaS applications, and provides sensitive-data visibility and control in order
to detect improperly-stored data in SaaS file repositories.

• Software-defined WAN (SD-WAN)—Provides an overlay network decoupled from the underlying hardware in order
to provide flexible, secure routes between sites.

Several security and network vendors deliver one or more components of a SASE solution. The challenge organizations
face is integrating those vendors and components. The key to an optimal SASE-based network and security deployment is
tight feature-and-service integration that improves operational efficiency. Such integration creates a solution that removes
performance-degrading bottlenecks and improves operational efficiency by reducing the number of vendors, systems, and
products that your IT staff must manage.

PALO ALTO NETWORKS SASE SOLUTION

The Palo Alto Networks SASE solution combines all essential elements of SASE into a single platform. With cloud-based
Prisma Access and Prisma SD-WAN, Palo Alto Networks delivers the industry's most complete SASE solution. Prisma
Access connects and protects mobile users, remote sites, and retail locations around the world and provides you a choice
of over 100 locations worldwide so that you can locate your security enforcement points close to your users. Prisma SD-

Palo Alto Networks 8

 Introduction

WAN provides secure WAN transport between offices, on-premises data centers, cloud-based data centers, and SaaS
applications. Prisma SD-WAN has fully orchestrated connectivity to Prisma Access in order to provide a secure transport to
SaaS applications.

Prisma SASE 3.0 enhances SASE by providing security, visibility, and control from any device to any application. With new
innovations such as Prisma Access Browser, AI-powered data security, and App Acceleration, Prisma SASE 3.0 offers a fully
integrated SASE solution with unified management and uncompromised application performance for both managed and
unmanaged devices.

Figure 1 Prisma SASE

Zero Trust Network Access 2.0

The Palo Alto Networks SASE solution provides the means to enable a ZTNA 2.0 compliant network. ZTNA 2.0 builds upon
the tenets of a Zero Trust by including the following capabilities:

• Least-privileged access—Granting users the minimum access they require in order to perform their tasks. You
achieve this by identifying applications at Layer 7, enabling precise access control at the app and sub-app levels,
independent of network constructs like IP and port numbers.

• Continuous trust verification—After access to an app is granted, trust is continually assessed based on changes in
device posture, user behavior, and app behavior.

• Continuous security inspection—Providing deep and ongoing inspection of all traffic, even for allowed connections,
to prevent all threats including zero-day threats.

• Protection of all data—Providing consistent control of data across all apps used in the enterprise, including private
apps and SaaS, with a single data-loss prevention (DLP) policy.

• Security for all apps—Safeguarding all applications used across the enterprise, including modern cloud-native apps,
legacy private apps and SaaS apps. This includes apps that use dynamic ports and apps that leverage server-initiated
connections.

Palo Alto Networks 9

 Introduction

To implement least-privileged access, you can use App-ID™, User-ID™, and Device-ID, all of which deliver rich context
and a granular approach to allowing access to applications. By enforcing least-privileged access, the organization can limit
authorization to individual applications and to specific user communities. Through continuous trust verification and continuous
inspection, the organization detects any change in security posture, user behavior, or application behavior. By combining
these techniques, your security infrastructure can make better security decisions and quickly react to changes.

Continuous monitoring includes a broad set of capabilities such as WildFire®, advanced URL security, advanced threat
prevention, SaaS security, and other cloud-delivered security services. When combined, these perform deep inspection for all
connections and can protect against both known and unknown threats, by leveraging AI and ML-powered threat-prevention
technologies.

Prisma Access
Powered by Palo Alto Networks operating system, PAN-OS®, Prisma Access is a cloud service that provides secure access
to internet and business applications hosted in SaaS, as well as access to corporate HQ or data center, or a public cloud.
Both managed and unmanaged devices can reach Prisma Access through multiple access methods. The FWaaS capabilities
of Prisma Access inspect all traffic, not just HTTP and HTTPS, in order to identify applications, threats, and content. As an
example, DNS security makes sure that malicious payloads aren't hidden within DNS transactions, and if you do attempt
to download an infected document that has not been previously identified as malicious, unknown files can be sent to
WildFire, the largest sandbox utility in the industry, for threat and malware scanning. Prisma Access offers the industry's most
comprehensive SASE solution, enabling your organization to connect and secure any user, device, or application.

Because Prisma Access is a cloud service, it avoids the challenges of sizing firewalls and compute resource allocation and
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 operationalizes security deployment to remote networks and
mobile users by leveraging a cloud-based security infrastructure delivered by Palo Alto Networks.

There are two options available as part of Prisma Access: Prisma Access for users and Prisma Access for networks.

Prisma Access for Users

Prisma Access for users provides security services, including App-ID, URL filtering, DLP, and threat prevention for mobile
users, as a service in the cloud, providing an alternative to the traditional on-premises deployment of GlobalProtect.
This cloud-delivered approach is well-suited for both new deployments across one or more global regions or as a hybrid
deployment with security provided by a combination of Prisma Access and on-premises firewalls.

Palo Alto Networks 10

 Introduction

Figure 2 Prisma Access for users

Prisma Access provides two mobile-user access connection methods for users with IT-managed endpoints:

• GlobalProtect—Extends Prisma Access's visibility and control of all network traffic, applications, ports, and protocols
to the user for secure access to internet or data center-based applications

• Explicit proxy—Allows SWG access to internet-based SaaS applications using HTTP and HTTPS protocols

For unmanaged devices, Prisma Access Clientless VPN allows endpoints to access secured on-premises applications.
Prisma Access uniquely provides an integrated security solution for web and non-web traffic that aligns with the SASE
industry architecture.

Prisma Access for Networks

Prisma Access for networks provides security services, such as App-ID, URL filtering, and threat prevention, for your remote
networks, safely enabling commonly used applications and web access. You connect remote sites to Prisma Access via
Prisma SD-WAN or an industry-standard IPSec VPN-capable device. This deployment model is suitable for remote sites with
one or more WAN links (or public WAN transports) and provides direct internet access through Prisma Access without the
requirement to backhaul traffic to the central site.

Palo Alto Networks 11

 Introduction

Figure 3 Prisma Access for networks

Prisma SD-WAN
To enable simplified deployment across your organization, Prisma SD-WAN provides next-generation, software-defined wide-
area networking combined with cloud-orchestration. The Prisma SD-WAN cloud-controller automatically provisions a secure,
encrypted transport between your sites, seamlessly connecting your remote offices to on-premises data centers, remote
sites, the public cloud, and to SaaS applications.

At the core of the system, Prisma SD-WAN uses built-in Layer 7 intelligence, providing application-aware networking, traffic
steering, and security policies in addition to the more traditional measures of jitter, latency, and packet loss. Prisma SD-
WAN also allows for complete visibility into the application health across all locations and collects granular application-driven
analytics, which you can use for monitoring and troubleshooting.

You enable the SD-WAN service by using Prisma SD-WAN Instant-On Network (ION) devices. Available as both hardware
devices or virtual software devices, the ION devices allow you to enforce policies based on business intent, enable dynamic
path selection, and provide visibility into performance and availability for applications and networks. You manage the ION
hardware and software devices from the multi-tenant cloud management portal, thereby eliminating the need to individually
configure devices at each location. The ION devices are pre-configured to authenticate to the portal and support zero-touch
provisioning and deployment.

After you deploy the Prisma SD-WAN ION devices at your sites, the devices automatically establish a VPN to the data centers
over every internet circuit. Additionally, the ION devices establish VPNs over private WAN circuits that share a common
service provider. You can then define application policies for performance, security, and compliance that are aligned with your
organization’s business intent. ION devices automatically choose the best WAN path for your applications. ION devices use
the business policy and real-time analysis of the application performance metrics and WAN links in order to determine the
appropriate path.

Palo Alto Networks 12

 Introduction

Figure 4 Prisma SD-WAN

When Prisma SD-WAN remote sites require secure internet access, you attain the most consistent and comprehensive
security for your organization by using Prisma Access. Using the Prisma SD-WAN easy onboarding process, Prisma SD-WAN
automates the remote site connectivity to Prisma Access for cloud-based protection. Prisma SD-WAN uses application-
aware policies to route traffic that is not destined for an internal site to Prisma Access, which then inspects the traffic,
performs threat detection, and enforces security policies.

PRISMA ACCESS ADD-ON CAPABILITIES

Prisma Access is based on Palo Alto Networks PAN-OS software, which allows your organization to add capabilities to your
Prisma Access network deployment without deploying additional equipment. You can enable enhanced threat-prevention
services, network-interconnect and service-connection options, data loss prevention services, and IoT device security
services.

SaaS Security Inline

The Prisma Access SaaS Security Inline service add-on offers SaaS visibility and control. The add-on uses cloud-based
machine learning to discover SaaS applications, and it provides advanced analytics and reporting so that your organization
has the insights to understand the data-security risks of sanctioned and unsanctioned SaaS application use on your network.
SaaS Security Inline provides complete control of SaaS application use from your corporate network and managed devices
that traverse Prisma Access. To provide a consistent management experience, SaaS Security Inline integrates with your
existing security.

Using both API-based and inline services, the Palo Alto Networks SaaS Security portfolio of services provides visibility and
control of your SaaS applications. Without reconfiguring your network, adding probes, and without any configuration on
endpoints, SaaS Security provides complete CASB services, with visibility across all users accessing a SaaS application.

Palo Alto Networks 13

 Introduction

A key part of Prisma Access and SaaS Security is Strata Logging Service (formerly known as Cortex Data Lake). Prisma
Access logs traffic-flow information on every application connection to Strata Logging Service (SLS), and when enabled on
your account, the SaaS Security application control engine is scanning the traffic logs for SaaS application access in your
Prisma Access tenant. The Prisma SaaS database contains over 15,000 SaaS application IDs. When SaaS Security sees
new or unknown SaaS applications, it uses machine learning to classify them. The benefit to every SaaS Security customer
is that as new SaaS applications are discovered and classified, they are added to the shared App-ID database. This gives
you enhanced visibility of the applications, the risk ratings of the applications, traffic volumes, and the identities of the users or
groups accessing the applications.

Prisma Access uses PAN-OS to deliver a robust application identification (App-ID) engine, which is shared across all PAN-OS-
based next-generation firewall (NGFW) platforms. App-IDs identify the applications flowing across Prisma Access—regardless
of port or protocol—even if the traffic is encrypted or tunneled. Because Prisma Access is inline with the user traffic, you can
configure security policies to control access to SaaS applications by using App-IDs, URL matches, and IP address ranges in
order to identify the application, as well as User-ID to control which users can access on-premises and SaaS applications.

Figure 5 Prisma Access SaaS Security Inline

SaaS Security Inline visibility is delivered as a SaaS service, so no footprint is required in the data center. The single SaaS
Security management application monitors and controls both in-line and API-based SaaS visibility and control. Because SaaS
Security provides visibility into stored data and historical activities, you can explore and investigate them on-demand. The
SaaS Security API (formerly known as Prisma SaaS) is licensed separately from SaaS Security Inline for Prisma Access.

Data Loss Prevention

DLP is a set of tools and processes that allows you to protect sensitive data against data breaches, regulatory compliance,
malicious users, and negligent users. Originally, only SaaS Security included DLP to detect sensitive information through
API-based scans of data stored in SaaS applications. Now, DLP is a centrally delivered cloud service with unified detection
policies that you can embed in your existing control points, giving you visibility and enforcement across the cloud with
Prisma Access and on-premises through NGFW support. Because Prisma Access is inline with your mobile and remote-site
user traffic, the DLP add-on provides you visibility of data-in-motion traversing the network and the ability to enforce your
organization's data distribution policies.

Palo Alto Networks 14

 Introduction

Figure 6 Prisma Access DLP

Prisma Access and SaaS Security both use the DLP cloud service to discover, and conditionally stop, data from being leaked
to unsanctioned web applications, or uploaded to sanctioned corporate apps through an advanced inline analysis. Prisma
Access DLP and SaaS Security add-on services are part of a cloud-delivered enterprise solution that provides a common
approach to preventing data loss with unified data policies and faster remediation.

Remote Browser Isolation

Remote Browser Isolation (RBI) is a service that isolates and transfers all browsing activity from the user’s managed devices
and corporate networks to an outside entity, such as Prisma Access, that secures and isolates potentially malicious code
and content within the platform. Natively integrated with Prisma Access, Palo Alto Networks RBI allows you to apply isolation
profiles easily to existing security policies. To keep sensitive data and information secure, isolation profiles restrict many
user controls, such as copy-and-paste actions, keyboard inputs, and sharing options such as uploading, downloading, and
printing files,.

RBI works by creating a no-code execution isolation channel between users and the browser, which mitigates zero-day
web threats by never allowing malicious files to execute on a user’s machine. Unlike other isolation solutions, the Palo Alto
Networks RBI solution uses next-generation isolation technologies to deliver near-native experiences for users accessing
websites—without compromising on security.

App Acceleration
App Acceleration improves the user experience by mitigating the effects of poor network conditions for TCP-
based applications. App Acceleration can provide an up to five times better performance for TCP-based applications as
compared to direct-to-internet traffic without the need for changes to the end-user client or application.

To do this, App Acceleration forecasts the user's next actions and computes the required dynamic content. This foresight
allows the system to preemptively request the content needed for that user session, initiating the loading and security
processing ahead of time. When the user makes the request, the content is already prepared. App Acceleration also
performs aggressive tuning of the TCP window to boost initial throughput for all connections. It then creates a custom packet
flow profile for every user session and updates it in real time. To mitigate the effects of conditions like packet loss, packet
corruption and jitter. App Acceleration takes into account network, device, and app context when it creates the profile,
enabling it to send the maximum amount of data to the user at all times,.

Palo Alto Networks 15

 Introduction

Autonomous Digital Experience Management

Autonomous Digital Experience Management (ADEM) is an add-on service that provides native, end-to-end visibility of the
entire service delivery path. ADEM provides two ways to monitor your SASE user's application experience:

• ADEM for mobile users—ADEM is integrated into the GlobalProtect app, and you do not need to deploy any
additional appliances or software. When your GlobalProtect app authenticates to the Prisma Access portal, the ADEM
service is enabled on the app according to the policies you have configured in Prisma Access.

• ADEM for remote networks—ADEM is integrated into the operating system of the remote site Prisma SD-WAN ION
device. ADEM for Remote Networks is available when a Prisma SD-WAN remote site is connected to Prisma Access
for internet access security.

ADEM continuously monitors each segment from the endpoint to the application and identifies baseline metrics for each
application. In addition, ADEM provides visibility into any deviations or events that degrade the user experience across each
segment between the end user and the application, whether it’s the endpoint, Wi-Fi, LAN, router, ISP, Prisma Access, or the
application (SaaS, IaaS, or data center). ADEM continuously monitors every segment in the service delivery path and provides
insights that help you quickly isolate the segment that is causing digital experience problems and simplify remediation,
including providing the user with recommendations to allow for self-remediation.

To determine baseline performance levels and alert you to changes in performance that might lead to a degraded user
experience, ADEM uses a variety of monitoring techniques:

• User traffic visibility—ADEM continuously provides visibility into real traffic usage between your users and the
applications they are accessing, including traffic to SaaS applications, Infrastructure as a Service applications, or other
internet-based applications, as well as traffic to applications in your own data center.

• Synthetic monitoring—ADEM uses synthetic tests to collect network performance metrics (availability, latency,
jitter, and loss) for each segment (LAN, internet, Prisma Access, and application), as well as end-to-end application
performance metrics (DNS resolution time, HTTP connect, SSL connect, HTTP latency, time to first byte, and time to
last byte).

• Endpoint monitoring—Available on ADEM for Mobile Users, the GlobalProtect app gathers health telemetry about
the device and its Wi-Fi connectivity in order to help determine whether the device or the Wi-Fi is the cause of any
performance issues.

Palo Alto Networks 16

 Introduction

Figure 7 ADEM add-on

AI-Powered Autonomous Digital Experience Management

AI-Powered ADEM is an integration of AIOps with ADEM. It combines artificial intelligence and machine learning capabilities
to automatically identify patterns, detect anomalies, perform event correlation, and generate alerts. It uses anonymized
crowdsourced data to generate insights for your deployment. For instance, if some of your users are living in a geographic
region where there is a problem with an ISP, and if that problem is detected by another organization that uses ADEM, then
AI-Powered ADEM isolates the problem of the ISP and raises it as an incident for you, thereby helping your IT operations to
perform root-cause analysis and incident detection and resolution.

Additionally, AI-Powered ADEM runs several in-built data models built by Palo Alto Networks, enabling it to find the best-fit
model for your remote and data center sites. Using this data model, AI-Powered ADEM forecasts bandwidth requirements for
your remote sites. All details about AI-Powered ADEM capabilities apply to both mobile users and remote networks.

AI-Powered ADEM uses ADEM as a foundation, and it enriches the data collected by ADEM by using AI/ ML models built by
Palo Alto Networks. You don’t need to configure anything for this capability, as it is enabled by default once it is activated. You
only need to configure ADEM and activate the AIOps license for this capability to function.

AI-Powered ADEM assists you in the following ways:

• Proactively monitor your application health—AI-Powered ADEM performs synthetic tests to your mobile users and
remote sites to configure SaaS applications and determines health of users, applications, and remote sites.

• Detect anomalies in your network—AI-Powered ADEM collects baseline data and detects anomalies in your
network.

• Manage capacity forecasting in your network—AI-Powered ADEM generates reports that assist you in forecasting
your remote network capacity.

• Troubleshoot complex network problems—AI-Powered ADEM can make complex queries using Access Analyzer
to assist you with identifying complex problems. For instance, it can create a query for a particular user accessing a
specific application and give a verdict.

Palo Alto Networks 17

 Introduction

Traffic Replication
On-premises network recorders have been a powerful tool when organizations perform forensic and breach analysis. It
is common in on-premises topologies to implement a parallel infrastructure of TAP ports, SPAN ports, or packet brokers
that would deliver a copy of the traffic to be used for such out-of-band analysis. Prisma Access Traffic Replication brings
this functionality to SASE. The Traffic Replication add-on is licensed on a per-user basis for both mobile users and remote
networks.

Traffic Replication uses the Prisma Access cloud to replicate traffic from Prisma Access and forward them to Google Cloud
storage buckets that you or third-party nodes can access for analysis. To reduce risk and keep your organization safe, Traffic
Replication provides access to packet captures of users' real-world traffic, thereby enabling the detection and remediation of
threats that could span multiple sessions or the identification and response to anomalous behaviors.

Palo Alto Networks 18

 Design Details

Design Details
This section discusses the Prisma Access and Prisma SD-WAN components that you use to secure private app access for
mobile users, remote-site users, and hybrid workers. Prisma Access and Prisma SD-WAN support additional capabilities that
secure access to the internet. This section introduces some of these additional capabilities for completeness but does not
discuss them in-depth.

Figure 8 Securing private applications for mobile users and remote sites

PRISMA ACCESS DESIGN DETAILS

Prisma Access enables you to have consistent application visibility and control for all users, regardless of their location.
Prisma Access can provide secure, enterprise-wide transport between remote offices, mobile users, and private or public
data center-based applications. The Prisma Access backbone interconnects a global network of more than 100 secure
access locations and uses this transport to carry traffic between your mobile users and enterprise locations. Prisma Access
licensing options allow the organization to choose how much enterprise traffic they want to transport over the Prisma Access
backbone. The Prisma Access backbone uses VPN technology to keep your enterprise traffic secure and separated from
other customers.

Prisma Access provides security services, such as App-ID and threat prevention, to your mobile users and remote-site users.
Data Centers connect to Prisma Access by using an IPSec VPN tunnel over the internet from an on-premises device, such as
a firewall, VPN router, or SD-WAN appliance. Prisma Access is a service that Palo Alto Networks deploys and manages.

Management Options
You have the following two options for provisioning and managing Prisma Access:

• Cloud-managed (through Strata Cloud Manager)

• Panorama® managed (through the Cloud Services plugin)

Palo Alto Networks 19

 Design Details

Because you cannot switch between them after you have activated your Prisma Access license, you must decide which
management interface you plan to use prior to provisioning your Prisma Access network. The two management interfaces
have different programming flows and different feature support matrices. Review the Palo Alto Networks compatibility matrix
to compare the two management interfaces. Regardless of which management interface you use, Prisma Access uses SLS
for log storage and Strata Cloud Manager for comprehensive monitoring, alerting and visibility.

Cloud Managed

You use Cloud Manager for cloud-based Prisma Access management. Cloud Manager uses task-driven workflows in order
to onboard mobile users and remote networks. Because the Cloud Manager provides a single user interface for your entire
SASE environment, you can easily navigate between Prisma Access, Prisma SD-WAN, and your cloud-delivered security
services. Inside Cloud Manager, you have direct access to several Prisma Access dashboards and log files from SLS.

The intuitive workflows make it easy to set up and test your environment and take little time to get operational. Cloud
Manager includes predefined options and workflows for the following:

• Internet access protection—Integrated security rules prevent access to and from known-malicious and high-risk
websites.

• Threat prevention—Tools such as anti-virus, WildFire, and anti-spyware are enabled by default in security rules and
configured with best practice-based settings.

• User-ID distribution—Prisma Access is configured to distribute User-ID information across the backbone and to
service connections for optional export to on-premises NGFWs.

• Directory services group sync—Easy, on-premises LDAP or cloud-based Microsoft Entra ID group maps via Cloud
Identity Engine integration allow for optimized security rules.

• IPSec setup—Default configurations match the most common IPSec devices that you would connect to your
network.

• URL categories—Default configurations allow SSL decryption based on best-practice settings.

Panorama Managed

You manage Prisma Access through the Cloud Services plugin on Panorama. Panorama does not interact with Prisma
Access security-processing nodes in the same way it does with the next-generation and VM-Series firewalls in your
organization. The Cloud Services plugin provides an abstraction layer between Prisma Access and Panorama, decoupling
Panorama from the specifics and versions of the security-processing nodes within Prisma Access. When Palo Alto Networks
provides an update for Prisma Access, you might need to update the Cloud Services plugin to get the latest Prisma Access
features; however, Panorama itself typically doesn’t require a software update.

You configure network and security policies for Prisma Access by using the Cloud Services plugin for Panorama and Prisma
Access-specific templates and device groups. This method of configuration enables you to provide consistent security policy
enforcement that meets your organization's usage guidelines.

Palo Alto Networks 20

 Design Details

If you plan to use an existing Panorama platform in order to manage your Prisma Access
instance, Palo Alto Networks recommends that you engage Palo Alto Networks professional
services. Before you add Prisma Access management, they can help you prepare your
Panorama platform and ensure that you follow best practices for Panorama stability and that
system sizing is correct. Alternatively, you can dedicate a new Panorama platform to this
task.

Prisma Access Dashboards

Within Cloud Manager, Prisma Access dashboards provide visibility into the health and performance of your infrastructure.
Dashboards are automatically available for every Prisma Access instance that your organization owns. Even if using
Panorama to manage Prisma Access, you can still access the dashboards on Cloud Manager for comprehensive monitoring,
alerting, and visibility.

Prisma Access dashboards provide the following:

• Health and performance monitoring for Prisma Access instances, whether you configure and manage your instance
with Cloud Manager or with Panorama and the Cloud Services plugin.

• A summary overview screen of the health and performance of your entire Prisma Access environment.

• Customizable alerts notifications, so that you can pinpoint issues or events that require your attention.

• Multiple dashboards for focused views of your different deployments, the corresponding alerts, and the health status
of the infrastructure.

• Flexible user interfaces that allow you to toggle and adjust views and statistics to evaluate trends over different
timeframes.

• The ability to drill down for details on specific users, sites, connections, or Prisma Access infrastructure components.

• Important Prisma Access system messaging, for example, upcoming system updates.

Components
When a mobile or remote-site user connects to a Prisma Access gateway, internet-bound application traffic automatically
exits the Prisma Access network at the closest internet access point. You must decide how to provide access to internal and
on-premises resources for your mobile users. In Prisma Access, you provide this access by using service connections that
pair to an IPSec-capable device, such as a router or a Palo Alto Networks NGFW at your data center or headquarters. You
can configure service connections to as many as one hundred sites depending on the licensing you choose.

Strata Logging Service

Prisma Access uses SLS to store logs. In addition to storing logs for Prisma Access, SLS can provide cloud-based,
centralized log storage and aggregation to the Cortex XDR® agent management service and on-premises and virtual (private
cloud and public cloud) firewalls. SLS is secure, resilient, and fault-tolerant, and because Palo Alto Networks delivers it as a
cloud service, you can easily add additional capacity and integrate it to the hub.

Palo Alto Networks 21

 Design Details

SLS not only provides public-cloud scalability across multiple secure locations, it enables AI-based innovations to normalize,
analyze, and stitch together your enterprise's data in order to detect hard-to-find security issues. SLS can use cloud-scale
compute resources to run advanced AI and machine learning on data from multiple Prisma Access flows and many other
inputs. Cortex is a scalable ecosystem of security applications that can apply advanced analytics in concert with Palo Alto
Networks enforcement points in order to prevent the most advanced attacks. Palo Alto Networks analytics applications such
as Cortex XDR and AutoFocus®, as well as third-party analytics applications that you choose, use SLS as the primary data
repository for all Palo Alto Networks offerings.

Mobile-User Connections

Prisma Access provides multiple methods for organizations to connect users to their Prisma Access instance. There are three
ways to connect mobile users:

• GlobalProtect app—The mobile user has the GlobalProtect application on their endpoint and connects to the
GlobalProtect portal to access the Prisma Access instance for internal, SaaS, and internet applications.

• Explicit-proxy connection method—The mobile users' web browser is configured to connect to the organizations'
Prisma Access explicit-proxy instance for HTTP or HTTPS access to internet-based SaaS applications.

• Clientless VPN—An organization with unmanaged users who require secured access to selected applications can
use Prisma Access to provide secured and controlled access to internal applications.

This guide focuses on the GlobalProtect connection method for managed users, which provides access to internal and
internet-based applications.

GlobalProtect Portal

Prisma Access provides the GlobalProtect portal functionality through resilient security-processing nodes deployed globally.
The service uses global DNS load-balancing to direct clients to the nearest portal. GlobalProtect portal is a secure web
service that provides for the distribution and management of GlobalProtect apps. The portal provides an authenticated
SSL web service for the download of the GlobalProtect app to end users for self-service deployment. Once connected, the
GlobalProtect app receives configuration information from the portal, including a list of Prisma Access locations, external
and internal GlobalProtect gateways, required certificates, connection methods, and app behavior. In addition to app
configuration, the portal can also distribute the GlobalProtect app to both macOS and Windows endpoints.

Prisma Access GlobalProtect Gateway Locations

Prisma Access uses gateways to connect mobile users to an organization's Prisma Access instance. GlobalProtect gateways
provide security enforcement for traffic from GlobalProtect apps. The endpoint app establishes a secure tunnel, using IPSec
or SSL, to the gateway.

Palo Alto Networks 22

 Design Details

Two types of GlobalProtect gateways exist:

• Internal gateway—An internal gateway is a next-generation or VM-Series firewall reachable from within the
organization's network. This gateway can be a dedicated device or collocated on a device serving other security
functions within the organization. When you use an internal gateway in conjunction with User-ID and/or host
information profile (HIP) checks, you can use the gateway to provide a secure, accurate method of identifying user-
to-IP mappings and the associated device state. You can share this information with other next-generation and VM-
Series firewalls in the organization so that they can enforce policy based on user and group information. You typically
configure internal gateways in non-tunnel mode, meaning they don’t terminate traffic but instead authenticate the user
and capture the user-to-IP mapping and HIP information.

• External gateway—An external gateway is reachable from outside of the organization's network and provides
security enforcement for mobile users. External gateways provide security for traffic from mobile users to the internet,
as well as remote access from mobile users to the organization's internal services and applications. The GlobalProtect
app tunnels traffic to the external gateways across IPSec or SSL.

Prisma Access provides the GlobalProtect external gateway functionality and distributes the functionality throughout the
world. You can choose the locations in which to enable the functionality, allowing you to distribute security close to your
mobile users. The configuration complexity of Prisma Access doesn't increase as you increase the number of locations
because you manage all Prisma Access locations through a single policy.

In some instances, such as when you have pre-existing GlobalProtect gateways at your data center, you might want mobile
users to connect to external gateways in addition to Prisma Access. You can configure the app with these external gateways
in Prisma Access, but you must deploy and manage additional gateways separately.

Although you cannot use Prisma Access as an internal gateway, within Prisma Access you can configure the app to use
internal host detection and connect to internal gateways deployed outside Prisma Access. This way, when mobile users are
on-site, they can bypass the connection to Prisma Access while still providing the organization with their user-to-IP mappings.

GlobalProtect App

The GlobalProtect app runs on Windows, macOS, Linux, iOS, Android, and Chrome. The GlobalProtect app is responsible
for connecting to Prisma Access to obtain configuration information and then choosing a Prisma Access location to which it
authenticates and tunnels traffic.

When users connect, the GlobalProtect app supplies User-IDs and device information such as the following:

• Operating system and application patch level

• Host anti-malware/firewall version and state

• Customized host conditions (examples: registry entries, running software)

Service Connections

Most organizations need to connect their mobile users to internal applications or data. Service connections provide secure
connectivity for mobile or remote-network users in Prisma Access to access internal applications and data in on-premises or
cloud-based data centers.

Palo Alto Networks 23

 Design Details

Prisma Access deploys corporate access nodes at locations with configured service connections. Corporate access nodes
do not enforce any security policies and only route traffic to Prisma Access-connected destinations. If you wish to enforce a
security policy on the service connection, for those enforcement policies you must configure the on-premises firewall located
behind the service-connection termination.

Prisma Access–connected service connections do not support internet-bound traffic that originates from the data center end
of the service connection. However, if a customer has additional on-premises security-processing that must be performed
on mobile-user internet-bound traffic, traffic steering or policy-based forwarding can direct internet-bound mobile-user traffic
to flow down a service connection to the organization's data center. Prisma Access licensing controls how many service
connections can be active in your network, and you can provision up to 100 service connections in a Prisma Access network.
The bandwidth used on a service connection is not rate-limited to a configured rate, but the service connection is designed to
handle approximately 1 Gbps of traffic.

Service connections in Prisma Access provide multiple functions. These functions include the following:

• Connecting Prisma Access to your organization's internal services and applications.

• Connecting the mobile users to applications, networks, and users inside of your organization behind an HQ or data
center link.

• Interconnecting mobile-user-to-mobile-user and mobile-user-to-remote-locations over the Prisma Access

infrastructure.

• Distributing User-ID information from Prisma Access to an on-premises NGFW or accepting User-ID information from
on-premises GlobalProtect gateways.

Licensing
The Prisma Access licensing model allows you to use the capabilities of Prisma Access in a way that delivers the fastest
return on investment. Prisma Access license editions address organizational issues such as your applications are migrating to
the cloud, your users are now working from anywhere, or if you are looking to gain operational efficiencies.

License Editions

Prisma Access now offers three editions of licenses to choose from: Business, Business Premium, and Enterprise. This
reference architecture is based on using the full suite of features provided by the Enterprise license edition. Both the cloud-
managed and Panorama-managed options support these licensing editions.

Table 1 Features available in Prisma Access license editions

Feature Business Business Enterprise

Premium

Internet security √ √ √

Threat prevention — √ √

URL filtering √ √ √

(Table 1 continues on the following page)

Palo Alto Networks 24

 Design Details

Table 1 (continued)

Feature Business Business Enterprise

Premium

DNS security √ √ √

WildFire — √ √

Number of service connections included 0 (add-on 0 (add-on only) 2 with Local Edition
only)
5 with Worldwide Edition

Additional service connections Add-on Add-on Add-on

Net interconnect for site-to-site and user-to- — — Add-on

site access

Enterprise DLP — Add-on Add-on

SaaS Security Inline Add-on Add-on Add-on

ADEM1 Add-on Add-on Add-on

Remote Browser Isolation Add-on Add-on Add-on

App Acceleration Add-on Add-on Add-on

Additional 10 TB of data transfer2 Add-on Add-on Add-on

1For mobile users, ADEM is delivered with GlobalProtect network security for endpoints.

2Every edition of Prisma Access provides up to 250 GB of data transfer per year, per unit purchased, averaged across the entire environment.

License Units

Prisma Access licenses mobile-user and remote-network capacity in units. A unit is either a mobile user in Prisma Access for
users or 1 Mbps bandwidth in Prisma Access for Networks. You can have a Prisma Access network of all mobile users, all
remote-network locations, or a combination of each. When you order a local or worldwide deployment edition, you license a
minimum number of units upon which you can build.

Table 2 Prisma Access units

Unit type Local minimum units Worldwide minimum units

Mobile user (user count) 200 1000

Remote-network bandwidth (Mbps) 200 1000

Palo Alto Networks 25

 Design Details

The mobile-user count requires 200 units in order to enable either GlobalProtect or explicit proxy access for local coverage;
enabling both simultaneously requires a minimum of 400 total licenses, 200 units each. GlobalProtect and explicit proxy share
the mobile-user unit pool.

Location Licensing

Prisma Access has more than 100 locations available to accommodate worldwide deployments and provide a localized
experience for the mobile user and the remote-network users. You select a Local or Worldwide edition based on your
organization's geographical spread. With a Local edition, you can choose any 5 locations worldwide. Some Prisma Access
locations share a common compute location. To increase resiliency and achieve optimal performance, you should choose
Prisma Access locations that use different compute locations. For more information, see the topic Prisma Access Locations
in the Prisma Access Administrator's Guide.

Table 3 Prisma Access locations

Local Worldwide

Up to 5 locations 100+ locations worldwide

When you onboard Prisma Access mobile-user gateway locations, you select the region or regions that you wish to activate,
and then you select the locations within a region where you wish to have local gateways for mobile users to connect to
Prisma Access. When a mobile user connects to a location, their internet-bound application traffic has the source IP address
translated to an IP address for that local gateway.

Prisma Access Infrastructure

Prisma Access is a global service, allowing mobile users and remote networks to connect to regional security-processing
nodes so that users have a good user-experience and they get properly localized applications when they access the internet.
To provide the global service, Prisma Access builds a unique virtual infrastructure for each customer/organization as the
service is onboarded.

Security Processing Nodes

The Prisma Access infrastructure is comprised of security-processing nodes, which are specialized virtual machines deployed
globally in the locations you specify. Prisma Access automatically provisions and configures the nodes with IP addressing,
routing, certificates, and DNS information.

There are different types of nodes, each serving a specific role in Prisma Access:

• Mobile-user security-processing node—The MU-SPN functions as a GlobalProtect gateway and is the attachment
point for mobile users using the GlobalProtect app.

• Portal security-processing node—The PT-SPN functions as the GlobalProtect portal, providing the operational
configuration for GlobalProtect mobile users and serving as the attachment point for GlobalProtect clientless VPN
users.

Palo Alto Networks 26

 Design Details

• Corporate-access node—The CAN functions as the attachment point for IPSec-based service connections to the
organization's data center or other privately hosted applications and services.

• Remote network security-processing node—The RN-SPN functions as the attachment point for IPSec-based
connections to remote site or branch networks.

• Explicit proxy security-processing node—The EP-SPN functions as the attachment point for HTTP secure web
gateway connections.

Customers onboard locations in order to meet the customers' requirements for service type, resiliency, latency, and capacity.
When Prisma Access provisions the infrastructure, security processing nodes are automatically deployed, and standby nodes
are provisioned for high-availability node types. The RN-SPN and CAN instances use high-availability primary/standby node
deployments, whereas resiliency for the other node types is based on the GlobalProtect application's ability to select alternate
nodes.

Prisma Access for users who use the GlobalProtect app for connectivity connect as follows:

• To a MU-SPN at the mobile-user gateway closest to the user, and when there is a failure, they can reconnect to an
alternate MU-SPN.

• To the PT-SPN closest to the user, and when there is a primary failure, they can reconnect to an alternate PT-SPN.

Prisma Access for users also monitors the MU-SPNs so that high loads cause the automatic deployment of additional nodes
to that location and adds the additional nodes to the list in Prisma Access.

Prisma Access Connections

Prisma Access for networks supports two connection types:

• Service connections—Connections to central site locations or data centers

• Remote network connections—Connections to remote sites

Service connections are IPSec tunnels between the Prisma Access infrastructure and central sites that contain resources to
which your remote-site users need access. These service connections are typically high-speed connections to a central site,
such as headquarters or a private data center, or to virtual networks that support workloads in the public cloud. You license
a number of service connections per Prisma Access edition, and you can add supplemental service connections. Prisma
Access does not limit the bandwidth over service connections, and the maximum performance is approximately 1 Gbps,
depending on packet size mix.

Prisma Access deploys corporate-access nodes at locations with configured service connections. Corporate-access nodes
do not enforce any security policies and only route traffic to Prisma Access-connected destinations. An on-premises resource
cannot originate a connection to the internet over a service connection. If you wish to enforce a security policy on the service
connection, for those enforcement policies you must configure the on-premises firewall located behind the service-connection
termination.

Palo Alto Networks 27

 Design Details

Palo Alto Networks recommends that you when you configure a Prisma Access service
connection, you terminate the IPSec tunnel to a dedicated remote-site device such as a
NGFW or IPSec-compliant routing device. Because you can only apply Prisma SD-WAN
network policies to remote sites, you should not terminate IPSec tunnels to ION devices at
Prisma SD-WAN data-center sites.

Remote-network connections are IPSec tunnels between an RN-SPN located at a Prisma Access compute location and the
IPSec-compliant remote-site device such as Prisma SD-WAN ION device. When onboarding remote sites, Prisma Access
deploys an RN-SPN at a compute location that has a configured remote-network connection and a minimum allocation of 50
Mbps bandwidth.

Prisma Access dynamically allocates the bandwidth based on load or demand per location by using an aggregate bandwidth
model. The aggregate-bandwidth model allows customers to estimate and manage egress remote-network bandwidth
requirements per Prisma Access compute location. You use the egress bandwidth estimate as a guide for scaling the
compute location with the correct number of RN-SPNs. In the aggregate-bandwidth model, all onboarded Prisma Access
locations mapped to a corresponding compute location share the configured egress aggregate-bandwidth for that compute
location.

The remote-network connections on the RN-SPN are not rate-limited per connection. They are part of an aggregate shared
pool of bandwidth assigned to the compute location. For example, if you have four sites collectively assigned to a compute
location allocated 200 Mbps of bandwidth, 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 operational in that compute location. Bandwidth allocated to a compute location counts for traffic in both directions;
for example, 50 Mbps allocated to a location supports 50 Mbps from the remote site to Prisma Access and 50 Mbps from
Prisma Access to the remote site.

Each RN-SPN can provide a maximum of 1 Gbps of egress bandwidth to remote networks (500 Mbps for Prisma Access
versions prior to 3.2) and is designed to perform at this rate with SSL decryption and threat prevention enabled. Depending
on the amount of bandwidth allocated to a compute location, Prisma Access deploys a single or multiple RN-SPNs in order
to adequately support the assigned bandwidth. As an example, with Prisma Access version 3.2, if you assign 1300 Mbps
to a remote-network's compute location, Prisma Access deploys two RN-SPNs in order to support the remote networks
assigned to that compute location (1 Gbps + 300 Mbps).

Palo Alto Networks 28

 Design Details

Figure 9 Aggregate bandwidth allocation with Prisma Access 3.2

The RN-SPNs enforce security policies for all traffic initiated from the remote site, and there is a maximum of 250 sites (with
a single tunnel per-site) or a maximum of 250 total IPSec tunnels (if using ECMP with multiple IPSec tunnels per-site) that
you can assign to an RN-SPN. NAT is enabled by default for all internet-bound user traffic without the need for explicit NAT
policy rules. If you have both service connections and remote-network connections in the same location, they do not share a
common processing node; instead, Prisma Access deploys two separate nodes.

The IPSec tunnels for Prisma Access service connections and remote-site connections should use the strongest encryption
and authentication in common between Prisma Access and the on-premises device.

The RN-SPNs can also use the service connections when they need access to central-site resources, such as when an on-
premises device redistributes User-ID information to Prisma Access.

Infrastructure IP Addressing

To provision the Prisma Access infrastructure, you must supply an IP address subnet. Prisma Access assigns an IP address
from this range to every node, regardless of whether it is serving as a security or corporate-access node. The nodes use
these IP addresses for internal communication between nodes, as well as communication from the nodes to your internal
on-premises services. Prisma Access now supports IPv6 for mobile-user access to internal or on-premises applications.
Discussion of this capability is currently beyond the scope of this guide, and this guide uses IPv4 addressing.

Prisma Access typically assigns the addresses used in the infrastructure as a /32-bit host. The supplied IP address
range must be at least a /24-bit subnet, and we recommend a /23-bit subnet for medium to large networks to allow the
infrastructure to grow. Because Prisma Access uses the infrastructure IP addresses to communicate with your on-premises
services, such as LDAP, this subnet cannot overlap with IP addresses in use in your organization. Palo Alto Networks
recommends that you use an RFC 1918-compliant subnet. Although Prisma Access supports the use of non-RFC 1918-
compliant (public) IP addresses, this practice is not recommended, because of possible conflicts with internet public IP
address space. The infrastructure subnet cannot overlap with the IP address pools that you assign for your mobile-users
deployment.

Palo Alto Networks 29

 Design Details

Do not specify IP subnets for infrastructure or mobile network IP ranges that overlap with the
following IP addresses and subnets:
• 169.254.169.253 and 169.254.169.254
• 100.64.0.0/10
• 169.254.201.0/24
• 169.254.202.0/24
Prisma Access reserves these IP addresses for internal use.

Prisma Access assigns each node any public IP addresses required for internet connections or tunnel establishment.

Security Zones and Policies

All security-processing nodes include a public interface that supports VPN tunnel termination from the internet and provides
internet access for users and devices that connect to Prisma Access through a VPN tunnel to the security-processing node.

Prisma Access implements the security policy with two security zones:

• Trusted—Internal interfaces

• Untrusted—External interfaces

Security policies in Cloud Manager use only the trusted or untrusted security zones. If you use Panorama to manage NGFWs
and Prisma Access, you can configure your security policies with more than two zones. However, when you configure Prisma
Access, you must map the zones used in your policy to either the trusted or untrusted zone. Typically, you consider remote-
site networks to be trusted, and you consider the internet to be untrusted.

With Panorama-managed Prisma Access tenants, all zones pushed to Prisma Access are
set to untrusted by default.

GlobalProtect App Mobile-User Endpoint Details

Application Deployment

There are a variety of ways you can install the GlobalProtect app on the endpoint. The simplest way to obtain the app on
Windows and macOS endpoints is to log into the Prisma Access portal and download the app directly. For iOS and Android
endpoints, you can download the app through their app stores. You can also deploy the app through systems management
software, such as Microsoft System Center Configuration Manager, and mobile-device management such as AirWatch.

When using systems management software, you can set parameters for the initial configuration, such as the hostname of the
portal, on Windows and macOS apps during the installation. After connecting to Prisma Access, the pushed configuration
overrides the initial configuration. Regardless of the installation method, Prisma Access can also transparently upgrade
Windows and macOS apps.

Palo Alto Networks 30

 Design Details

Obtaining Configuration

The primary function of the Prisma Access portal is to provide configuration information to the GlobalProtect app on the
endpoint. The app configuration that Prisma Access provides includes the following:

• Listing Prisma Access locations and external and internal GlobalProtect gateways

• Internal host detection

• Specifying connection methods (always-on, on-demand)

• Managing certificates (connection and decryption)

Before Prisma Access can provide a configuration to the app, the app must authenticate. The Prisma Access authentication
profile determines the authentication method that the app must use.

Authentication options include the following:

• Local authentication databases

• RADIUS servers

• Terminal access controller access-control system plus (TACACS+) servers

• LDAP servers

• Kerberos servers

• SAML 2.0 identity providers (IdPs)

Prisma Access can provide differentiated authentication profiles and methods based on the endpoint operating system, which
Prisma Access determines through the information pushed from the GlobalProtect app. For example, Windows endpoints
can use an LDAP authentication method, while Android endpoints use SAML. However, Prisma Access cannot distinguish
between managed and unmanaged endpoints of the same operating system when determining an authentication method.

When authentication is complete, Prisma Access provides the app with its configuration. Prisma Access can have multiple
app configurations defined. Prisma Access assigns the configurations to the endpoints based on their operating system
or user/user group membership. When multiple configurations apply to an endpoint, Prisma Access applies the first
configuration that matches the endpoint in a top-down approach.

The app caches the configuration in case a situation arises where Prisma Access is unreachable when it initiates a
connection. The app does not use the cached configuration when Prisma Access is reachable but authentication is failing.

Authentication

Certificates

With the optional client certificate authentication, the user presents a client certificate along with a connection request to
Prisma Access. Prisma Access can use either a shared or unique client certificate to validate that the user or endpoint
belongs to your organization.

Palo Alto Networks 31

 Design Details

RADIUS

RADIUS is a client/server protocol and software that enables remote access servers to communicate with a central server to
authenticate dial-in users and authorize their access to the requested system or service. In simplest form, the client can send
one Access-Request, which includes username and password, and the RADIUS server can respond with Access-Accept or
Access-Reject. RADIUS can also send one or more Access-Challenge message in order to get additional data, such as a
one-time password (OTP), PIN, or similar.

SSO

When you enable single sign-on (SSO), the GlobalProtect app uses the user’s Windows login credentials to authenticate and
connect to Prisma Access automatically. SSO relies on Windows using the GlobalProtect credential provider. When the user
logs in using the GlobalProtect credential provider, login credentials are passed both to the GlobalProtect app and Windows
local system authority.

SAML

When a SAML profile is enabled, Prisma Access returns a SAML request as a part of the response to the GlobalProtect app’s
pre-login message. The app then redirects to the SAML IdP and opens a window for the user to enter their credentials. The
app keeps the existing connection to Prisma Access and uses a second session to connect to the IdP.

When the user authenticates with the IdP, the app redirects back to Prisma Access. Similarly to the connection to the IdP, the
app uses a new session to forward the SAML assertion to Prisma Access. When Prisma Access validates the IdP assertion,
it returns the extracted username, authentication status, and cookie to the app. The app then resumes the initial connection
with Prisma Access and uses the cookie as proof of authentication.

Prisma Access Location Selection

When configured for an always-on connection method, the GlobalProtect app can use internal host detection in order to
determine whether the network currently connected is external or internal to the organization. Without internal host detection,
the app tries to connect to the internal gateway(s) first and then moves to Prisma Access or an external gateway(s) if an
internal gateway(s) is not available. Internal host detection speeds up the process of connecting to Prisma Access.

Figure 10 Prisma Access location selection

Based on the internal host detection determination, the app connects to Prisma Access, an internal gateway, or none at
all (if the network is internal, but there is no internal gateway defined). The app uses a reverse DNS lookup for internal host
detection. If the DNS query for the configured host detection IP address does not return the correct PTR record (as defined in
the configuration), then the app assumes the network is external.

Palo Alto Networks 32

 Design Details

You can configure internal gateways with source IP address ranges that provide the app a way to determine which internal
gateways to authenticate and send HIP reports. Additionally, you can configure site-specific internal gateways through DHCP
Option 43.

Based on the combination of gateway priority and gateway SSL latency, the GlobalProtect app selects a Prisma Access
location to which to connect. Because of the large number of Prisma Access locations, a location might be close (have a low
response time) but provide a challenging user experience, specifically around languages presented by applications or have
regulatory concerns. To provide a deterministic experience, Prisma Access adjusts the location priority values based upon the
endpoint location.

The endpoint location is determined based on the IP address presented to Prisma Access, which has IP-to-country
mappings, and returns a region to the app during the initial communication between the app and the service. This location-
based priority ensures endpoints connecting from or in New York prefer a location in the United States versus one in Canada,
even when the location in Canada has a better response time.

Connection

You can configure the GlobalProtect app to initiate tunnel connections to Prisma Access in the following ways:

• On-demand (manual user-initiated connection)—User initiates the connection when needed (meant for Prisma
Access and external gateways only).

• User-logon (always on)—The app starts the connection when the user logs into the machine and tries to keep the
tunnel up (if disconnected for some reason).

• Pre-logon (always on)—The app starts the connection when the machine boots up (before the user logs in); it
renames the tunnel when the user logs in.

• Pre-logon then on-demand—The app starts the connection when the machine boots up. Depending on the settings
(tunnel rename timeout), when the user logs in, the tunnel is terminated or kept up/renamed. If the tunnel disconnects
for some reason, the client must manually reestablish the connection.

Tunnel connections from the app to Prisma Access can use IPSec or SSL. When enabled, IPSec is always the preferred
connection method. The app attempts IPSec connections as a UDP-encapsulated encapsulating security payload packet
on port 4501. If there is no response from Prisma Access (because of traffic filtering between the endpoint and the security-
processing node), the app falls back to an SSL connection. You cannot disable SSL tunnel fallback.

After the endpoint connects to Prisma Access, the MU-SPN assigns the endpoint an IP address from the MU-SPN's IP pool.
You define the IP pools when onboarding the mobile-user instance in Prisma Access. You can define the IP pools as either
worldwide or regional. As you provision mobile-user locations, the Prisma Access service deploys MU-SPNs and assigns a
subnet from the pool for each one.

Palo Alto Networks 33

 Design Details

Traffic Forwarding

There are two ways you can configure the GlobalProtect app to send the endpoints traffic to Prisma Access:

• Full tunnel—This method is the default and most secure method of forwarding traffic. This method ensures that the
endpoint forwards all WAN and internet-bound traffic to Prisma Access for inspection and policy enforcement.

• Split tunnel—The endpoint forwards latency sensitive or high bandwidth consuming traffic outside of the VPN tunnel
and routes all other traffic through the VPN for inspection and policy enforcement by Prisma Access.

In full tunnel mode, the GlobalProtect app installs on the endpoint a default route that forwards traffic across the tunnel. To
ensure traffic doesn't bounce once the GlobalProtect app establishes the tunnel, when the app chooses a Prisma Access
location, but before it connects to the tunnel, it adds a host route (/32) to the MU-SPN's IP address. The app also adds host
routes for the DNS servers Prisma Access pushes. To ensure the OS chooses the correct routes, the GlobalProtect app set
routes that it adds with a metric of "1".

Even in full tunnel mode, endpoints can still use more specific local routes. You can enable no direct access to local network
in the Windows and macOS GlobalProtect apps to prevent direct access to local networks. With this setting enabled, the app
masks local routes. The app also monitors the routing table for changes, so it can dynamically mask routes added outside of
the app.

Prisma Access does not charge for or limit bandwidth for individual mobile users, and every license edition of Prisma Access
provides up to 250 GB of data transfer per year, per user purchased, averaged across the entire environment. Additionally,
because of the distributed and global nature of the service, the application user-experience should be high even when the
mobile users are distributed around the world.

Clientless VPN

For unmanaged personal, partner, and contractor endpoints that you can’t install a client on, the GlobalProtect clientless VPN
provides secure access to on-premise applications from SSL-enabled web browsers without installing the GlobalProtect app.
Clientless VPN proxies access for the web applications that you make available to them.

Figure 11 Clientless VPN

Service-Connection Details
Service connections to Prisma Access use IPSec tunnels. IPSec tunnels terminate on the public interface using public
IP addresses, allowing them to transit the internet. Prisma Access creates a corporate-access node and generates a
target IPSec tunnel interface IP address during onboarding of a new service connection. The on-premises network device

Palo Alto Networks 34

 Design Details

uses the target IPSec IP address as the IPSec gateway peer IP address. The Prisma Access CAN terminates the service-
connection IPSec tunnel and places the VPN tunnel payload in a trusted zone for access from the mobile users to on-
premises applications.

Figure 12 Service connection over IPSec

The service connection is a Layer 3 routed connection that you can connect to any IPSec-capable firewall, router, or SD-WAN
endpoint. You need to ensure that the remote IPSec endpoint has support for more recent encryption and authentication
algorithms, and to ensure secure transport, you should use the strongest available algorithms.

To minimize the impact of IP fragmentation, when designing your internet VPN links, you should ensure that your devices
include advanced features. A key feature is Adjust TCP MSS, which you can enable on your VPN endpoints in order to
ensure that communications endpoints negotiate the TCP maximum segment size to a value that eliminates the need for
fragmentation. Take advantage of techniques, such as internet control message protocol (ICMP) path MTU discovery, that the
communication endpoints use to identify the smallest MTU along a path.

If you explicitly block all ICMP message types, communication endpoints are unable to
determine the most effective MTU by using ICMP path MTU discovery.

If you use digital certificates, industry best practices recommend that, when available, you enable automated processes
for certificate enrollment and revocation, such as the simple certificate enrollment protocol and the online certificate status
protocol. These automated processes streamline and simplify the overall certificate management workflow. If you choose to
use pre-shared keys, use tools to generate strong, random keys and use unique keys for each service connection.

The service connection provides connectivity for outbound traffic from Prisma Access-connected mobile users to the
customers' premises-based application endpoints and inbound traffic destined for connected mobile users and remote
networks; however, the service-connection link does not support internet-bound connections originating from the service
connection. Internet connectivity for endpoints inside of the customer enterprise should connect to internet-based resources
through Prisma Access remote-network links or through an NGFW-protected internet gateway in your organization.

The service-connection link does not support internet-bound connections that originate from
the service connection.

Palo Alto Networks 35

 Design Details

In some situations, organizations need to do additional processing of mobile-user traffic. To route mobile-user traffic to a
data center or cloud service for additional security-processing, you can advertise a default route from the customer premises
to Prisma Access, or use traffic steering rules. Traffic steering can direct internet-bound mobile-user traffic to a service
connection based on many criteria including IP Address, custom URL categories, service type (HTTP or HTTPS), User-ID,
dynamic address groups, and IP-based external dynamic lists.

Service-Connection Location

You can configure a service connection to operate out of any Prisma Access location within the license edition that you
chose, allowing you to locate the resources closest to the users. The Prisma Access MU-SPNs connect to CANs in a hub-
and-spoke fashion. If you have internal application locations on multiple continents, you should consider a worldwide service-
connection license and use multiple service connections so that users in-region can connect to the local resources directly.
Regardless of the geographic location of your service connection, user traffic can transit the Prisma Access backbone to
reach the internal application. By default, mobile users connect to the closest Prisma Access location for access and policy
enforcement, and then connect locally to the internet or travel the most efficient route over the Prisma Access backbone to a
service connection and the internal application.

Service-Connection Characteristics

There are different characteristics of a service connection and a remote-network link that you should consider when designing
your Prisma Access deployment:

• Bandwidth—The bandwidth over a service connection is not rate limited. The maximum performance depends on
average packet size and is approximately 1 Gbps. The number of service connections in your Prisma Access instance
is determined by the licensing options you chose.

• Function—Service connections connect mobile users and remote networks to internal applications. Service
connections terminate on Prisma Access corporate-access nodes. Corporate-access nodes also are route points for
interconnecting mobile-user and remote-network sites. Remote networks can also connect to other remote sites and
to internal applications served by a service connection. Additionally, they can be reached by mobile users and can
connect outbound to the internet.

• Policy—You consider the service connection a trusted link. You use a NGFW on the on-premises side of the service
connection in order to control what traffic is allowed from the internal network into the service. The MU-SPN security
policy controls mobile-user-to-mobile-user and mobile-user-to-internet traffic.

Service Connections to Enable and Optimize Mobile-User Traffic Flow

In some scenarios, an organization might not require access to a data center/HQ network while still using Prisma Access for
users and/or networks. In a Prisma Access network that has no service connection, by default, mobile users can connect to
the internet and to other mobile users connected to a common location and MU-SPN, if allowed by the mobile-user security
policy.

To enable mobile-user-to-mobile-user connectivity across MU-SPNs, you need to activate at least one service connection
in order to deploy a CAN that interconnects the MU-SPNs and allow traffic with the appropriate security policy. If the Prisma
Access network includes remote networks and you license Net Interconnect, the corporate-access node also connects the
remote-network mesh to the mobile user's access.

Palo Alto Networks 36

 Design Details

Figure 13 Corporate-access node interconnecting MU-SPNs

Service connections enable additional mobile-user traffic routing scenarios. Prisma Access
security policies allow or deny mobile-user-to-mobile-user, mobile-user-to-remote-location,
and mobile-user-to-data-centers traffic flows at the MU-SPNs and RN-SPNs.

You can use additional service connections, with or without a data center connection, to deploy corporate-access nodes for
the following purposes:

• To optimize traffic flow in mobile-user-to-mobile-user applications where groups of users are in different geographies.

• To optimize traffic flow for mobile-user-to-remote-network closer to the geographic location of a group of users/
locations.

Figure 14 Service connection per region

You define service connections that have no connection to a data center similarly to the service connections that have
connectivity to on-premises facilities, except that the former does not have IPSec tunnels programmed. MU-SPNs connect to
the CANs terminating a service connection in a hub-and-spoke topology. A service connection that connects to a data center
activates a corresponding CAN that serves as an MU-SPN interconnect, as well.

Palo Alto Networks 37

 Design Details

Routing for Service Connections

The service connection can use static routing or dynamic routing using BGP. This architecture recommends dynamic routing
in order to automate the announcement of new IP address subnets in the Prisma Access infrastructure or on the customer
side of the connection. Another advantage of dynamic routing is to provide resilience by routing around failed links when
multiple paths between the customer network and Prisma Access exist.

When you provision the Prisma Access service infrastructure, in addition to the infrastructure IP subnet, you assign a BGP
autonomous system (AS) to Prisma Access for dynamic routing. Prisma Access uses a single BGP AS when using dynamic
routing for service connections or remote networks. The assigned BGP AS is typically a private AS as defined in RFC-6996,
and if you retain the default BGP AS, the BGP AS is 65534. The customer BGP AS must be different than the BGP AS you
assigned to Prisma Access; Prisma Access only accepts an external BGP (eBGP) peer definition for service connections or
remote-network connections.

Prisma Access configures the default BGP timers for keep alive (30 seconds) and hold time (90 seconds). If you configure
more aggressive timers on the customer BGP peer for faster convergence, for example keep alive (10 seconds) and hold time
(30 seconds), the Prisma Access corporate-access node adopts the faster timer settings.

In current Prisma Access releases, you can enable service connection backbone routing options via the Prisma Access app
or Panorama. The advanced routing options allow you to enable asymmetric routing between service connections and to
optionally enable load sharing in the Prisma Access backbone to service connections.

Take care when enabling or changing service connection asymmetry and load-sharing
settings on a production Prisma Access instance, because those changes might have
unexpected consequences. To minimize disruptions, it is recommended that you consult
your Prisma Access specialist or test the changes in a lab or during off-hours.

Mobile-User Routing to Service Connections

When designing your network, you should understand how mobile-user connections route to a service connection. The
mobile user connects to an MU-SPN, and a service connection connects to a corporate-access node. When the MU-SPN
is first deployed for a location, Prisma Access creates an IPSec peer connection between the security-processing node and
the closest corporate-access node. Corporate-access nodes are inter-connected across the Prisma Access backbone. The
Prisma Access backbone directs the mobile-user traffic to use the closest service connection to route to a data center and
discover if there are alternate routes. If the closest service connection to a data center link fails, the mobile-user traffic can
transit the Prisma Access backbone and egress an alternate service connection.

Palo Alto Networks 38

 Design Details

Figure 15 Mobile-user-to-service-connection traffic

Prisma Access Routing Modes for Service Connections

Prisma Access provides two routing modes specifically for routing mobile-user traffic to service connections:

• Default—Use this routing mode if you have simple connectivity to a data center, with no connectivity between data
centers, or in scenarios with more complex designs where your organization wants to control traffic flow leaving
Prisma Access by advertising BGP attributes from your network. In this mode, Prisma Access honors any BGP
attributes sent from the customer premises equipment (CPE).

• Hot-potato routing—In this mode, Prisma Access hands off mobile-user traffic as quickly as possible to the closest
service connection. This is the preferred routing mode for mobile-user networks. Use this method when you want
Prisma Access to set BGP attributes to control traffic leaving Prisma Access over a service connection toward your
customer premises and use a symmetric return.

When controlling the IP traffic flow path over the service connections in a multi-homed environment, like the one depicted in
Figure 16, there are multiple BGP attributes to bias the paths.

Figure 16 Multi-homed organization with inter-data center connections

Palo Alto Networks 39

 Design Details

Using BGP Routing Attributes to Control Service-Connection Traffic

When connecting multi-homed network environments to Prisma Access, you can use routing methods to control traffic flows
so that they flow predictably and symmetrically over the service connections between Prisma Access and your network.

You can select the hot-potato routing mode and allow Prisma Access to set the BGP attributes in the network, or you can
configure the BGP attributes used for service-connection routing on your remote-site device to control routing.

The most commonly used attributes include the following:

• BGP local-preference—The local preference influences the exit point of traffic from your BGP AS for traffic headed to
a neighbor BGP AS.

• BGP AS path length—The number of BGP autonomous systems in a path influences the preferred path to a
neighbor AS.

• BGP multi-exit discriminator—You send a MED to the BGP neighbor AS to influence the entrance point of traffic to
your BGP AS.

When an AS has multiple direct connections or paths to another AS, the local preference indicates the degree of preference
for one exit path from the AS over the other. In the BGP routing information base, if the same IP prefix has multiple entries or
routes, the path with the highest local preference wins. To select the best exit for traffic outbound to the neighbor BGP AS,
such as a remote site or data center, use local preference.

The path length of the AS is the number of autonomous systems through which a route path must traverse from its origin.
When the organization's BGP AS is directly adjacent to that of Prisma Access, the AS path length is always 1 unless modified
by the remote-site device when advertised. Your AS is associated with all routes advertised to Prisma Access. If you prepend
the AS path on a route advertisement, you make the route less desirable than the original value. For example, a prepend of 3
results in the original plus three more: {65501, 65501, 65501, 65501}. The AS path length is useful in multi-homed networks
where your network has one or multiple autonomous systems.

BGP MED is a way for an AS to influence an external entities’ path selection into a multi-homed AS. MED is a 32-bit number,
with a lower number used for preferred path. MED is an optional configuration parameter, and a MED of <none> or 0 are
equivalent. When a single AS (65501) is sending routes to another single AS (65534), BGP MED is an appropriate tool.

The use of BGP MED in the Prisma Access corporate-access node is disabled on service
connections that have multiple BGP peers on a single service-connection.

Longest IP Prefix Match

Layer 3 routing uses the longest prefix match in the route table, regardless of the routing protocol, to determine the best path
to route traffic. BGP advertises the on-premises IP prefixes to Prisma Access so that mobile users can reach applications and
users that are behind the on-premises connections. In the example network shown in Figure 16, each data center advertises
the IP prefixes found in Table 4 to the service connection.

Palo Alto Networks 40

 Design Details

Table 4 Organization IP prefixes advertised to Prisma Access

IP prefix Organization location

10.5.0.0/16 Data Center-1

10.6.0.0/16 Data Center-2

10.7.0.0/16 Data Center-3

If advertising the same routes and prefixes up each data center link to Prisma Access, traffic from the mobile users takes
the shortest path from the MU-SPN (where the mobile user connected) to the nearest corporate-access node. The prefix
and path selection are fundamental to IP routing and BGP is advertising the IP routing information. To force traffic out a
service connection using IP prefix length, you can advertise individual prefixes out of Data Center-2. For example, you can
advertise all of the individual /24 subnets for every segment in the data centers or remote-site subnets from Data Center-2.
This method works but can generate thousands of routes in the cloud in larger organizations.

Multiple Service Connections to a Single Data Center

A service connection connects to a corporate-access node which supports approximately 1 Gbps throughput for the
connection. Some organizations require more than 1 Gbps throughput into a data center. Prisma Access supports
multiple service-connections from a data center to a location in order to scale throughput up to 5 Gbps using five service-
connections.

In this scenario, the following design details apply to the configuration of the organization's on-premises routing equipment:

• The equipment can advertise the data center summary subnet across all service-connections, and is not required to
break it into smaller routes and advertise them over different service-connection tunnels.

• The equipment is not required to return traffic symmetrically on the same service-connection tunnel on which the
traffic came in.

• The equipment can use one or more Layer 3 routers in order to terminate the service connections and can use equal-
cost multi-path routing to return traffic.

• The equipment can use a single high-throughput firewall in order to terminate the service connections and use policy-
based forwarding to return the traffic symmetrically.

Prior to Prisma Access release 2.0, if you deployed multiple service-connections from a
single data center to Prisma Access, the service connections required that traffic returned
symmetrically on the same service-connection.
To prevent asymmetric flows from being dropped at the corporate-access nodes, the
default Prisma Access routing setting for traffic flows on service connections requires
symmetric routing. To support this design, you can configure your Prisma Access instance
to allow asymmetric flows over service connections. On-premises firewalls might not permit
asymmetric traffic flows.

Palo Alto Networks 41

 Design Details

Figure 17 Multiple service-connections to a single data center

Recall that MU-SPNs connect to corporate-access nodes (CANs), and CANs terminate service connections. When you
provision mobile users in the same regional locations as your service connections, Prisma Access automation distributes
the MU-SPNs to connect to the closest CANs. In the scenario where there are multiple CANs in the same location, as
would happen in the case where multiple service-connections connect to a single data center scenario, then Prisma Access
automation distributes the load on the service connections by distributing the MU-SPNs across the CANs for the location.
In this scenario, it is recommended that you do not summarize mobile-user subnet advertisements from Prisma Access
on those service connections so that the mobile-user subnet advertisement used in hot-potato routing mode will serve to
distribute the mobile-user return traffic load in a more uniform manner. To balance outbound traffic toward the data center,
advertise the same data center summary route (example: 10.5.0.0/16) up each link from the data center to Prisma Access.

When you enable multiple service-connections to a single data center in your mobile-user
network, and you use hot-potato routing mode, we recommend that you do not enable
summarization of the mobile-user subnets as they are advertised from Prisma Access. This
results in a more balanced traffic-load across the service connections for traffic bound for
Prisma Access.

Resiliency
Prisma Access is a cloud-based secure-access service, designed with redundancy and resilience in order to provide a highly
available service. This section provides options for increasing the resilience of how you connect to your Prisma Access
instance.

Palo Alto Networks 42

 Design Details

GlobalProtect Connect Method Resilience

The Prisma Access GlobalProtect mobile-user connection method consists of three major components: the GlobalProtect
app running on your endpoint, the Prisma Access GlobalProtect portal, and the Prisma Access GlobalProtect gateway
location. The Prisma Access GlobalProtect connection method has resilience built into the design, some of which you can
customize for your environment. Prisma Access offers more than one hundred GlobalProtect mobile-user gateway locations
that you can enable based on your mobile-user locations and licensing. For the purposes of providing primary and fallback
services, the GlobalProtect connect locations are divided into three geographic regions.

MU Portal Redundancy

The Prisma Access GlobalProtect portal is a secure web service that provides for the distribution of the configuration and
management information for the GlobalProtect app on a mobile-user device. Prisma Access provides the GlobalProtect portal
functionality through multiple portal security processing nodes deployed regionally or globally. To direct clients to the nearest
portal, Prisma Access uses global DNS load-balancing.

Prisma Access provisions portal locations based on the following criteria:

• If all of your Prisma Access mobile-user gateway locations are deployed in a single region, you have two portals
deployed in that region.

• If you have Prisma Access mobile-user gateways deployed in two regions, you have one portal deployed in each
region.

• If you have Prisma Access mobile-user gateways deployed across three regions, you have one portal deployed in
each region.

Because Prisma Access is a cloud-native service, you do not need to control the portal deployment. Prisma Access
automation pre-determines portal deployment. Global DNS load balancing determines the portal to which the GlobalProtect
mobile user connects, based on lowest-latency metrics of the mobile user's location relative to the portals. A single portal
hostname (FQDN) allows you to reach any of the portals in your Prisma Access instance. If a portal fails, a watchdog process
removes that portal from the DNS resolution list, and the client then connects to an alternate portal in your instance. After
the GlobalProtect app is connected, it receives configuration information from the portal, including a list of Prisma Access
locations

Mobile-User Gateway Location Redundancy

For secure connectivity to internet-based and internal applications, the Prisma Access GlobalProtect mobile user connects to
a MU-SPN at a gateway location. The MU-SPN gateway locations are deployed in cloud provider compute locations, based
on which of the 100+ Prisma Access gateway edge locations you choose to onboard. Prisma Access deploys a single MU-
SPN at a compute location in order to accommodate connections from Prisma Access gateway locations that are mapped
to that compute location. If additional MU-SPNs are required at a compute location in order to handle an increased user-
connection load, Prisma Access automatically adds new MU-SPNs in order to provide horizontal scaling in the compute
location.

MU-SPNs are not deployed in pairs for redundancy. Instead, failover is handled by the GlobalProtect app's ability to failover
to the next best gateway, if the primary choice is unavailable. You do not need to program individual connections on the
GlobalProtect app. The Prisma Access portal passes the list of mobile-user gateway locations that you have enabled, and

Palo Alto Networks 43

 Design Details

the GlobalProtect app connects to the most appropriate gateway available. Based on the observed mobile user's source
IP address, the portal passes a prioritized list of GlobalProtect locations to which the connecting mobile user is eligible to
connect.

In the Prisma Access Administrator's Guide topic How the GlobalProtect App Selects a
Prisma Access Location for Mobile Users, you can find up-to-date lists for:
• Available GlobalProtect mobile-user gateway locations by region and by compute location.
• Fallback (alternative) locations and manual-select-only locations.

The automatic Prisma Access GlobalProtect client gateway-selection process is as follows, top-to-bottom flow:

• If the mobile user connects in a country that has a Prisma Access location, the user connects to the location in that
country. Location is determined by the device's source IP address.

• If no in-country location is available, the client selects a location based on the Prisma Access region in which it is
connecting:

Asia, Australia, and Japan—Hong Kong

Africa, Europe, and Middle East—Netherlands Central

North America and South America—US Northwest

For redundancy purposes, Palo Alto Networks recommends that during the Prisma Access
GlobalProtect mobile user onboarding, you add these locations in their respective regions.

• If none of the gateway locations above are programmed for your tenant and available, your client attempts to connect
to one of the following fallback (alternative) gateway locations: Bahrain, France North, Ireland, South Africa West, or
South Korea.

Palo Alto Networks strongly recommends that you enable at least one of the fallback
gateway locations during the Prisma Access GlobalProtect mobile-user onboarding.
For redundancy purposes, Palo Alto Networks recommends that you enable locations in
more than one compute location.

If no gateways are available through automatic gateway-selection, and if manual gateway selection is enabled for your
user account, you can manually select a gateway in the GlobalProtect app client. Certain Prisma Access locations are not
included 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 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. For more information about
setting a preferred location, see the topic Support for Preferred Gateways in the GlobalProtect App New Features Guide.

Palo Alto Networks 44

 Design Details

If you use on-premises GlobalProtect gateways with Prisma Access locations, you can specify priorities in Prisma Access in
order to let mobile users connect to either a specific on-premises GlobalProtect gateway or a Prisma Access location.

Service-Connection Resilience

When your Prisma Access for users deployment relies on accessing data centers for private applications or services, your
Prisma Access service-connection design must ensure that your mobile users can function without disruption. Service
connections terminate on corporate-access nodes in the Prisma Access infrastructure. When you configure Prisma Access
to deploy a corporate-access node in a location, Prisma Access deploys a second standby corporate-access node at the
same location but in a different availability zone, for resilience. Prisma Access monitors the operation of the corporate-access
nodes, and failover between nodes does not require customer action.

When your deployment requires multiple service connections, if possible, you should deploy service connections across
multiple Prisma Access compute regions. This reduces the possibility of a cloud-service provider facility failure interrupting
access to on-premises applications and services.

Service-Connection-to-Mobile-User and Portal-Security Processing Nodes Network Redundancy

When an organization is using Prisma Access for mobile users with the GlobalProtect access method, the GlobalProtect app
on the user’s device manages key aspects of high availability when connecting to Prisma Access. The GlobalProtect app
automatically chooses the closest available portal or gateway and chooses an alternate if the primary choice is unavailable.
Although the ability to connect to alternative locations addresses most of the high-availability requirements for GlobalProtect
mobile-user connectivity, customers can benefit from resilient connectivity within the Prisma Access infrastructure itself when
mobile users require access to private, on-premises applications and services.

When you are initially onboarding your Prisma Access for users tenant with GlobalProtect gateways, Prisma Access
deploys two or three PT-SPNs, each with a single connection to a service connection CAN. Likewise, when you onboard
GlobalProtect mobile-user gateways, Prisma Access deploys an MU-SPN, each MU-SPN with a connection to a service
connection CAN, if one exists in the tenant. When there is more than one CAN in your Prisma Access tenant, the PT-SPN or
MU-SPN is connected to the closest CAN. The definition of closest is based on geographical location, as determined during
Prisma Access provisioning.

To increase resilience in your Prisma Access deployment, when you have two or more service connections in your
deployment, you should enable an additional connection between the MU-SPN or PT-SPN and a second service-connection
CAN in order to reduce single points of failure. This additional connectivity is referred to as MU-SPN and PT-SPN network
redundancy, and the Prisma Access infrastructure automates it when you enable it.

Palo Alto Networks 45

 Design Details

Figure 18 Network redundancy for a Prisma Access mobile-user gateway

When you deploy your Prisma Access instance with network redundancy for MU-SPN and PT-SPN, the Prisma Access
infrastructure automatically creates a second tunnel to an additional CAN, if more than one exists. During initial MU-SPN or
PT-SPN onboarding, the first tunnel provisioned to the closest CAN is always the primary tunnel used between the Prisma
Access nodes. If a secondary tunnel is created, that secondary tunnel is always the backup. The Prisma Access infrastructure
automatically selects the secondary tunnel connection based on metrics that consider criteria such as the closest CAN that
is in-country, alternate cloud provider, or alternate compute region. If your Prisma Access deployment is using hot-potato
routing mode with backup service-connections defined, the preference for the secondary tunnel connection selection is to
connect to the hot-potato-routing-backup-service connection CAN.

The secondary tunnel is the backup whether the secondary tunnel is created during initial onboarding, after more than one
CAN is created during service connection onboarding, or after upgrading to the version of Prisma Access supporting this
network redundancy feature. For stability and consistency, the secondary tunnel is created without any reevaluation of the
primary tunnel, even if the creation of the secondary tunnel is triggered after events over time, which results in provisioning a
closer CAN in the service infrastructure than the CAN connection for the primary tunnel.

Given sufficient CAN resources deployed in appropriate locations during mobile-user onboarding, you can achieve resilient
connectivity. Prisma Access automatically handles the IPSec tunnel creation and additional BGP peering requirements.
However, in the case that there are multiple service connections to a single customer resource, such as a data center, you
must accommodate asymmetric routing behavior for the multiple ingress and egress points by enabling the asymmetric-
routing-with-load-share advanced routing option for service connections within the service. For cloud-managed Prisma
Access, this configuration requirement is addressed automatically because asymmetric-routing-with-load-share is required to
be configured before it will deploy the network redundancy configuration, and for Panorama-managed Prisma Access, this
configuration requirement is enforced when committing the configuration.

When you enable asymmetric-routing-with-load-share in Prisma Access, make sure that

your on-premises network device supports asymmetric traffic flows.
To provide a more predictable traffic flow, when you enable MU-SPN and PT-SPN network
redundancy, it is recommended that you are running hot-potato routing mode with backup
service-connections defined.

Palo Alto Networks 46

 Design Details

Network redundancy for MU-SPN and for PT-SPN is share the following design details:

• It is possible only with two or more CANs in the Prisma Access instance.

• It is supported on all Prisma Access license editions, with appropriate number of service connections included or
ordered as add-on.

• It is supported with either cloud-managed or Panorama-managed Prisma Access deployments.

• It is available in a multi-tenant environment.

Service-Connection to On-Premises Using Active/Standby Link Resilience

In some scenarios, the service connection to a data center does not require more bandwidth than a single service connection
can supply, but the design requires resilience by using a primary and a backup path, each path over different internet
providers. A service connection can consist of a single IPSec tunnel, or a pair of IPSec tunnels operating in a primary/
secondary setup where the primary link is active, and the secondary link is in backup. Prisma Access does not consider
the primary/secondary IPSec tunnel option a dual-homed data center, because both IPSec tunnels terminate on the
same platform at each end and operate in a primary/standby mode for the active data path. When using BGP routing, the
recommended design uses active BGP peers across the primary IPsec tunnel and across the secondary IPsec tunnel.

Figure 19 Resilient service-connection with standby IPSec WAN link

To detect a failure on the primary link, the primary/standby service connection design uses tunnel monitoring. Tunnel monitor
probes on the active link (with probes every 3 seconds to the defined on-premises IP address) and failover designed to trigger
after a loss of 5 probes can detect a failure in approximately 15 seconds and immediately switch the service traffic over to
the secondary link. To detect failures on the primary link, you should set up both Prisma Access and the on-premises IPSec
tunnel definitions with monitoring probes.

Palo Alto Networks 47

 Design Details

Figure 20 Tunnel monitor probes

Tunnel monitoring probes use native policy-based forwarding and do not require explicit routes for the probe target. You do
not need to add the tunnel IP addresses as prefixes for Prisma Access. Tunnel monitoring probes do not create sessions nor
are they visible in traffic logs or packet captures. Insights in the Prisma Access app can display tunnel-monitor status for the
Prisma Access end of the links or use CLI commands on the on-premises NGFW.

Service-Connection to On-Premises Using Active/Active Link Resilience

In Prisma Access network designs where you must maintain 1 Gbps or more throughput into a data center, you can use
multiple service connections operating in an active/active mode. As discussed earlier in the "Routing for Service Connections"
section, Prisma Access supports multiple service-connections from a data center to a location in order to scale throughput
up to 5 Gbps using five service-connections.

In this scenario, the organization's premises routing equipment connects to multiple active corporate-access nodes and can
load share for more bandwidth. This design uses BGP for dynamic routing between Prisma Access and the data center. If
one of the VPN links fails, BGP detects the failure and uses the remaining links for the traffic. The routing for this scenario is
covered earlier in this guide, in the "Multiple Service Connections to a Single Data Center" section.

Figure 21 Resilient active/active service-connections to a single data center

Palo Alto Networks 48

 Design Details

Routing
You configure Prisma Access to route traffic to and from a remote site by using static routing, BGP dynamic routing, or a
combination of both. When making your decision, be sure to consider both directions of the network traffic flow.

Static Routing Only

You typically use static routing when you have only a single path to a site and the site has only a limited number of prefixes.
Additionally, you can use static routing if you don't anticipate many modifications in the IP address space that would
require a manual update to the routing tables. The primary benefit of static routing is that it is easy to configure and has a
simple, predictable behavior. The drawback of static routing is that you must perform all routing changes manually, which is
cumbersome and error prone if the changes apply to multiple remote sites.

For each statically routed remote site on Prisma Access, you must configure a full list of prefixes. To support direct internet
access (DIA) from the remote site, the remote site typically has a static default route directing internet-bound traffic to Prisma
Access. In the single-path remote-site scenario, the static default route is enough to direct traffic to the internet and your
Prisma Access-connected data centers and to other remote sites for enterprise-based connectivity.

Figure 22 Static routing for a remote-network connection

The static routing option is compatible with resilient primary and secondary IPSec tunnels. By using tunnel monitoring, Prisma
Access handles failover transparently. The remote-site device has a corresponding pair of tunnels for primary and secondary.
On your remote-site device, you need to configure two static default routes with different routing metrics. The primary tunnel's
static default route should use a more preferred routing metric, and the secondary tunnel's static default route should use a
less preferred routing metric. To improve failure detection, you should enable tunnel monitoring or an equivalent feature.

Dynamic BGP Routing

Use BGP routing when the remote-site uses a large number of prefixes or you anticipate multiple modifications in the IP
address space. The primary benefits of dynamic BGP routing are automatic prefix learning and support for multiple paths.
In a single-path network, the BGP configuration is fairly simple. In larger, multi-path designs, the BGP configuration can be
somewhat more complex. The BGP principles for connecting remote sites to RN-SPNs, or data centers to corporate-access
nodes, are the same. However, data center connections can be more complex and use more BGP routing features.

Palo Alto Networks 49

 Design Details

The VPN tunnel from the remote site to Prisma Access uses a point-to-point IP subnet with a /31 subnet mask. When
you are onboarding the remote site, you use the VPN tunnel IP addresses as BGP peer addresses, and then Prisma
Access automatically configures a route to your remote-site or service-connection BGP peer address. In the Prisma Access
onboarding for the remote site, you do not have to explicitly add the peer address as a remote-site IP subnet.

Figure 23 BGP routing for a remote-network connection

The Prisma Access infrastructure uses a single BGP AS with a default assignment of 65534. Prisma Access supports
external BGP only for dynamic routing over service connections and remote-network connections. You assign a unique BGP
AS to each of your remote sites if you require the remote site to communicate with other remote sites, data centers, or mobile
users. BGP loop prevention ensures that sites do not accept routing updates that contain their own AS number. If you reuse
the same AS number for remote sites, those sites can support DIA traffic. However, they are unable to communicate with
each other over the Prisma Access network.

After you configure BGP peering between your remote site and Prisma Access, your remote-site device learns all routes.
These routes include both BGP and static routes from service connections and remote-network connections. You can filter all
routes from Prisma Access to be blocked and send only a default route to the remote site.

Prisma Access configures the default BGP timers for keep alive (30 seconds) and hold time (90 seconds). If you configure
more aggressive timers on the customer BGP peer for faster convergence, for example keep alive (10 seconds) and hold time
(30 seconds), the Prisma Access RN-SPN or corporate-access node adopts the faster timer settings.

The BGP routing option is compatible with resilient primary and secondary IPSec tunnels. Prisma Access handles failover
transparently by using tunnel monitoring. The remote-site device has a corresponding pair of tunnels for primary and
secondary, and each VPN tunnel from the remote site to Prisma Access uses a point-to-point IP subnet with a /30 subnet
mask. You configure two BGP peers, one on each of the primary and secondary tunnels, and then Prisma Access advertises
routes to the remote site with a BGP AS prepend over the secondary tunnel so that traffic uses the primary tunnel. To
improve failure detection, you should enable tunnel monitoring or an equivalent feature.

When routing to remote networks, you can enable Prisma Access to advertise the default route to the remote site in the BGP
setup. You can make your default route path to Prisma Access more resilient with primary and secondary tunnels and tunnel
monitoring or an equivalent feature.

Palo Alto Networks 50

 Design Details

You can configure Prisma Access to advertise a default route by using BGP over a remote-
network link to a remote site. If you advertise a default route to your remote site, ensure that
your remote network does not have a way to pass on the default route beyond the site and
potentially create a routing loop.

Figure 24 BGP routing using primary and secondary tunnels

Remote-Site Resiliency and Bandwidth Scale

When Prisma Access deploys security-processing nodes in a location, by default the nodes operate in a high availability
active/standby design. You can configure both service connections and remote-network connections to use a secondary
WAN IPSec tunnel. You must have a second internet connection on your on-premises device to use the secondary WAN. If
the primary WAN IPSec tunnel fails, the secondary WAN IPSec takes tunnel over as the active tunnel. This design uses an
active/standby method.

To determine the health of their peers, IPSec endpoints configured with IKEv2 use a liveness check. Prisma Access uses
the IKEv2 default settings for the liveness check, and if the link is idle, Prisma Access sends informational packets every 5
seconds. If Prisma Access receives no response, it repeats the liveness check up to 10 times. If you rely on the liveness
check, you can expect to wait 50 seconds in order to determine that a tunnel is down.

Equal-Cost Multiple Path Links

To increase bandwidth and link resilience, you can use multiple links between a remote site and a Prisma Access location.
The resilience provided by primary and secondary IPSec tunnels to a single location leaves half of your bandwidth unused.
When you have multiple links with equal bandwidth capabilities, you can use all of the links to actively forward traffic to and
from Prisma Access. Equal-cost multi-path routing (ECMP) is a routing strategy where next-hop packet forwarding to a single
destination can occur over multiple "best paths" which tie for top place in routing metric calculations. Prisma Access designs
support two ECMP use cases:

• Large remote network high DIA-only bandwidth scale—This use case is for DIA traffic only and can scale up to 2
Gbps of DIA traffic from the remote site.

• Remote network with resilience and bandwidth scale—This use case is for DIA and private traffic up to 500 Mbps
over ECMP links to a single RN-SPN.

Palo Alto Networks 51

 Design Details

Large Remote-Network High DIA-Only Bandwidth

Some large remote-network locations require more bandwidth for DIA-only traffic than a single link to an RN-SPN can
provide. In this use case, you can connect up to four 500 Mbps links, one link per Prisma Access RN-SPN, for a total of 2
Gbps of DIA traffic from the remote site. The RN-SPNs that terminate the links can be in the same location and should be in
the same region for language considerations and link latency.

Figure 25 Equal-cost load-balancing of DIA traffic from the remote site

To make sure that the user-count and session-count at the location are within current Prisma
Access guidelines, you must review (with a Prisma Access SE specialist) this use case for
each large site for which you would like to use this design.
To support this use case, you must enable overlapped subnets on Prisma Access remote-
networks settings.

ECMP is configured on the remote-network device and not on Prisma Access, and ECMP must perform load-balancing at
the session level, not at the packet level. At the start of a new session, the remote-network device's ECMP process chooses
an equal-cost path. The return path of a traffic flow from Prisma Access to the remote is symmetric because source NAT
(SNAT) is performed on internet traffic and each SPN has a unique IP address for SNAT. This design uses BGP routing
between the remote-site device and each Prisma Access SPN. 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, the Prisma
Access BGP peer uses the lower hold-time value. To detect a VPN link outage in the ECMP group faster, set a KeepAlive
value of 10 seconds and a HoldTime value of 30 seconds on your remote device.

Remote Network with Resilience and Bandwidth Scale

The ECMP load-balancing feature that you provision on Prisma Access for remote networks supports up to four links
between the remote-site network device and the Prisma Access RN-SPN at a compute location. All IPSec tunnel links in
an ECMP bundle must terminate at the same location on the same RN-SPN. If you terminate a remote network with four
ECMP links on an RN-SPN, there are no other remote networks assigned to that RN-SPN. The aggregate bandwidth for that
compute location allocates 500 Mbps to that RN-SPN, and then each ECMP link could transmit traffic at 25% of the RN-
SPN total bandwidth (for example 125 Mbps per ECMP link). With security and threat prevention enabled, the RN-SPN can
support up to 500 Mbps of SSL traffic. Prisma Access does not rate-limit or shape per ECMP link or the ECMP bundle at this
time. When using Prisma SD-WAN to connect to Prisma Access with multiple links, you must use an ECMP configuration.

Palo Alto Networks 52

 Design Details

To make sure that your user and session counts at the location is within current Prisma
Access guidelines, you should review (with your Prisma Access SE specialist) remote sites
with high user counts. Prisma Access is constantly improving and optimizing security
network performance.

Figure 26 Equal-cost load-balancing for the remote site

ECMP performs load-balancing at the session level, not at the packet level. In this use case, you configure ECMP on the
Prisma Access RN-SPN and on the remote-site device. The network device chooses an equal-cost path at the start of
a new session. Equal-cost paths to a single destination are considered ECMP path members or ECMP group members.
ECMP determines which one of the multiple paths to a destination in the forwarding information base (FIB) table to use for an
ECMP flow. The RN-SPN uses a round robin load-balancing algorithm. The Prisma Access RN-SPN maintains a traffic flow
on the same link, and for more effective load-balancing, symmetric return on the same link is preferred. If a link fails, ECMP
rebalances the sessions across the remaining links in the group.

When using ECMP on Prisma Access, you must use BGP routing. Prisma Access automatically configures routes to your
BGP peer address.

For the BGP peer for each IPSec tunnel in the ECMP group, the Prisma Access user
interface requires a unique IP address.

Securing the Remote Site

Prisma Access is a highly effective method for securing your remote sites instead of deploying and managing a network-
security infrastructure at the remote sites. The Prisma Access app and SLS manage all policy and monitoring centrally, and
Palo Alto Networks manages the infrastructure.

As discussed earlier, Prisma Access uses PAN-OS to deliver a robust App-ID engine, which is shared across all PAN-OS-
based NGFW platforms. Through continuous trust verification and continuous inspection, Prisma Access detects any change
in security posture and any behavioral change by the user or application.

Palo Alto Networks 53

 Design Details

Securing Traffic Flows with Prisma Access

All security-processing nodes used to connect remote sites to Prisma Access use an identical security policy. This policy
includes the zones, address objects, and security policy rules. The value of this approach is that you guarantee that all
locations always have a consistent policy. You cannot customize the policy for any specific remote-network node or remote-
network connection.

Security-policy rules in Prisma Access are always in effect by default, for all dates and times.
If you create a security policy with a schedule-based object to enable and disable a Prisma
Access security policy at recurring times, the time in the policy schedule is based on the
local time at each Prisma Access compute location.

The security-processing nodes used to connect the remote site to Prisma Access protect the flows listed in Table 5. Security-
processing nodes protect only flows initiated from the mobile users or remote sites. For completeness, this table includes all
possible destinations, but this guide is primarily focused on flows to internal resources.

Table 5 Traffic flows from the remote site secured by Prisma Access

Destination Source zone Destination zone Rule type Connection flow sequence

Internet trust untrust Interzone Security-processing node

Central site trust trust Interzone Security-processing node

Prisma Access backbone

Corporate-access node

Remote site trust trust Interzone Security-processing node

(same node)

Remote site trust trust Interzone Security-processing node

(different node or Prisma Access backbone

location)
Security-processing node

Mobile user trust trust Interzone Security-processing node

Prisma Access backbone

Corporate-access node

Prisma Access backbone

Security-processing node

Palo Alto Networks 54

 Design Details

Figure 27 Securing traffic flows

Prisma Access forwards all network traffic from the remote site to internal networks, other remote sites, and mobile users
connected to Prisma Access, without NAT. You have full control of the security policy for this traffic flow.

PRISMA SD-WAN DESIGN DETAILS

SD-WAN provides increased flexibility and control of WAN traffic when you use multiple WAN transports. In general, SD-WAN
solutions enable you to build a WAN overlay network or networking fabric using a variety of WAN transports with different
bandwidth and performance characteristics. SD-WAN typically shares the traffic load across all paths in an active/active
manner, based on the application. These solutions have centralized virtually all aspects of device management, including
device onboarding and key-management workflows, making large-scale deployment relatively seamless.

SD-WAN overcomes the limitations of MPLS VPN and internet VPN by providing ubiquitous data encryption, simplified
configuration, active utilization of all links, and rapid convergence while also reducing cost through the expanded usage of
low-cost WAN transports.

In addition to the basic SD-WAN functions previously mentioned, Prisma SD-WAN provides next-generation software-defined
wide-area networking by using built-in Layer 7 intelligence, providing application-aware networking, while also monitoring
for and mitigating jitter, latency, and packet loss. Prisma SD-WAN also provides complete visibility into the application health
across all locations and collects granular, application-driven analytics that you can use for monitoring and troubleshooting.
The Prisma SD-WAN devices include an embedded, application-aware zone-based firewall (ZBFW) that enables you to
enforce security policy rules across your remote sites. The ZBFW shares a common App-ID database with PAN-OS NGFW,
allowing for consistent security policy across both.

Palo Alto Networks 55

 Design Details

Constructs for Prisma SD-WAN

Prisma SD-WAN uses the following elements:

• Portal and controller—Cloud-based controller that you access through Cloud Manager and that provides SD-WAN
control-plane services

• Sites:

Data-center sites—Central-site locations that contain SD-WAN hub devices

Branch sites—Remote-site locations that contain SD-WAN remote-site devices

• Modes of operation—Analytics mode and control mode

• Devices—Physical or virtual SD-WAN appliances that are assigned to sites

• Interfaces—Physical or virtual device interfaces

• Secure fabric links and service links—Link options for connection to other Prisma SD-WAN endpoints and
standard VPN endpoints

• Traffic classes:

Enterprise traffic—Traffic to destinations within your organization

Non-enterprise traffic—Traffic to destinations external to your organization

• Endpoints, domains, and groups—Logical constructs that allow flexibility when creating network policy rules

• High availability and scaling—Methods for deploying additional devices at sites in order to increase resiliency and
scale

• Network policies—Rule sets for SD-WAN path selection, QoS, and NAT

• Security policies—Rule sets for security using the Prisma SD-WAN ZBFW

• Circuits—Public or private WAN transports that are used to interconnect the sites

Portal and Controller

You manage the Prisma SD-WAN and perform all configuration and monitoring by using Cloud Manager. The controller
orchestrates control-plane functions within the portal. The controller in your SD-WAN maintains the network of public and
private WAN paths and propagates routing information. The controller also automatically provisions VPN tunnels across WAN
paths. After you have configured the SD-WAN, the controller pushes the configurations to devices at each site by using APIs.
The portal provides a centralized administration point for policy and analytics.

The portal and controller are provided as a cloud-based service. You do not need to deploy logical or physical infrastructure,
and Palo Alto Networks manages all maintenance and upgrades.

Palo Alto Networks 56

 Design Details

Sites

The overall SD-WAN architecture uses sites as the primary building blocks. When adding a new site to your SD-WAN, you
must assign a site type, which then defines the behavior of devices assigned to the site. Data-center sites are SD-WAN
central sites, or hubs, which are primarily used for aggregating connections to remote sites. In addition, data-center sites
function as transit sites between discontiguous networks, which supports the interconnection of sites connected to regional-
only MPLS providers. Branch sites are SD-WAN remote sites, which perform the primary monitoring and data collection
functions that enable the analytics for the SD-WAN. To manage your SD-WAN, you bind network and security policies to
each remote site. These SD-WAN policies are not bound to data-center sites; traffic between data-center sites and remote
sites uses the remote-site policies. Because you cannot bind network policies to data-center sites, Palo Alto Networks
recommends that you only use data-center sites to interconnect Prisma SD-WAN remote sites.

You must specify global IP prefixes for each site, and this prefix information is used as the basis for routing between sites.
Rather than using dynamic routing protocols with peering between sites, the controller manages and propagates the routing
information.

The Prisma SD-WAN topology is essentially hub-and-spoke, and by using default path policies, all remote sites can
communicate with all hub sites. You can also enable communication between remote sites through hub sites that you specify.
If you require direct communication between remote sites, you can explicitly configure secure links between remote sites that
bypass the hub sites.

Modes of Operation

You can deploy Prisma SD-WAN sites in one of two operating modes—analytics mode or control mode:

• Analytics mode—In this site mode, you install an ION device into a new or existing remote site. You place the ION
device between a WAN edge router and a LAN switch. The ION device monitors traffic and collects analytics that are
reported to the Prisma SD-WAN portal. When sites are in analytics mode, the ION devices do not apply policies or
make path selection decisions for applications. In this mode, a data-center site is not required.

• Control mode—In this site mode, you install an ION device into a new or existing remote site. You may either replace
the WAN edge router with the ION device or place the ION device between a WAN edge router and a LAN switch.
The ION device monitors traffic and collects analytics that are reported to Cloud Manager. When the site is in control
mode, the ION device at the remote site dynamically builds secure fabric VPN connections to all data-center sites
across all WAN paths.

Sites in control mode forward traffic, select the best paths from the available physical and secure fabric links based on
the applied network policies, and enforce security policy for applications. If you do not need access to internal data
center applications, then data-center sites are not required.

Devices

Each data center or remote site must include a Prisma SD-WAN ION hardware device or a Prisma SD-WAN virtual ION
software device. The ION hardware devices have a unique serial number that is associated to your organization in Cloud
Manager. ION software devices use tokens generated from the portal instead of a serial number. When you power on an ION
device (hardware or software) and connect a controller port to a public network, the device authenticates to the controller and
is automatically assigned to your Prisma SD-WAN account by using zero-touch provisioning (ZTP).

Palo Alto Networks 57

 Design Details

Some ION hardware devices do not include a dedicated controller port. To manage these devices, use a ZTP-capable
port instead of a controller port. ZTP-capable ports are configured by default as internet ports and use DHCP for address
assignment. You can use either controller ports or ZTP-capable ports for remote-device management, but if you are
connecting your ION device to an existing network, Palo Alto Networks recommends that you use the controller port if your
device includes one.

When a new, unclaimed device is initially connected and listed, it appears in the portal with a status of online-restricted. You
claim the device and then assign it to a site. For claimed devices that have not been assigned to a site, you can perform only
basic administrative functions. After assigning the device to a site, you can perform a complete device configuration. You
perform all aspects of configuration, management, and monitoring from Cloud Manager.

Table 6 Specifications for Prisma SD-WAN remote-site ION hardware devices

Property ION 1000 ION 1200 ION 1200-S ION 2000

Typical usage Small remote site or Small remote site Small remote site with Small remote site with
home office high availability high availability

Throughput Up to 100 Mbps Up to 250 Mbps Up to 250 Mbps Up to 250 Mbps

(recommended range)

Controller ports — — — 1

(10/100/1000 Base-TX)

WAN/LAN/internet ports 4 4 — 5

(10/100/1000 Base-TX)

WAN/internet ports — — 4 —

LAN ports — — 6 —

Bypass pairs — — 1 pair (ports 3/4) 1 pair (ports 4/5)

(can be decoupled) (can be decoupled)

ZTP-capable ports Any Ports 1-2 Ports 1-2 Ports 2-3

(ports configured as DHCP

by default)

SFP/RJ-45 combo ports — — Ports 1-2 —

PoE ports — — Ports 7-10 —

Integrated LTE/5G — ION 1200-C-NA ION 1200-S-C-NA —

ION 1200-C-ROW ION 1200-S-C-ROW

ION 1200-S-C5G-WW

Palo Alto Networks 58

 Design Details

Table 7 Specifications for Prisma SD-WAN ION data-center hardware devices

Property ION 3000 ION 3200 ION 5200 ION 9000 ION 9200

Typical usage Remote site or Remote site Large data Large data center Large data
small data center or small data center or large or large campus center or large
center campus campus

Throughput Up to 600 Mbps Up to 600 Mbps Up to 1.5 Gbps Up to 6 Gbps Up to 6 Gbps

(data center (data center (data center
(recommended range) (data center (data center
mode) mode) mode)
mode) mode)
Up to 500 Mbps Up to 500 Mbps Up to 1 Gbps
Up to 3 Gbps Up to 3 Gbps
(branch mode) (branch mode) (branch mode)
(branch mode) (branch mode)

Controller ports 2 — — 2 —

(10/100/1000 Base-TX)

WAN/LAN ports 12 10 15 8 15

Bypass pairs Up to 6 pairs (any 1 pair (ports 3/4) 4 pairs (ports 4 pairs (ports 1/2, 4 pairs (ports
ports) 1/2, 3/4, 5/6, 3/4, 5/6, 7/8) 1/2, 3/4, 5/6,
(can be
7/8) 7/8)
decoupled)

ZTP-capable ports — Ports 1-2 Ports 1-2 — Ports 1-2

(ports configured as DHCP by

default)

WAN/LAN/internet ports — — 4 8 10

(10GE SFP+)

SFP/RJ-45 combo ports — Ports 1-2 Ports 1-2 — —

PoE ports — Ports 7-10 Ports 7-10 — Ports 9-12

Table 8 Specifications for Prisma SD-WAN ION software devices

Property ION 3102v ION 3104v ION 3108v ION 7108v

Throughput up to 100 Mbps up to 200 Mbps up to 350 Mbps Up to 3 Gbps

(recommended range)

Controller ports 1 1 1 1

WAN/LAN/internet ports up to 9 up to 9 up to 9 up to 9

Virtual bypass pair support Yes Yes Yes Yes

(Table 8 continues on the following page)

Palo Alto Networks 59

 Design Details

Table 8 (continued)

Property ION 3102v ION 3104v ION 3108v ION 7108v

vCPU 2 4 8 8

RAM (GB) 8 8 8 32

Disk (GB) 40 40 40 100

Interfaces

Physical interfaces on ION hardware devices are automatically assigned a link type and usage. Similar assignment is made for
virtual interfaces on ION software devices. The port usage options differ between data center and remote-site devices.

Controller ports are typically configured with DHCP, which makes them suitable for zero-touch deployments. You can
configure the controller port with a static IP address through Cloud Manager after deployment, which is a simple configuration
option. However, if you want to use a static IP address for initial deployment, you must connect to the device through the
console and make the configuration change by using the ION device toolkit.

On a data-center device, ports can be used as internet ports or peering ports. Internet ports are connected to public
networks, and peering ports are connected to private LAN and private WAN networks. When installing a data-center device,
you do not need to make significant topology changes to your current data center network topology.

If your data-center device is behind a NAT device, when you configure the internet port, you must provide the external NAT IP
address that maps to the private IP address assigned to the port.

Figure 28 Prisma SD-WAN data-center topology

Palo Alto Networks 60

 Design Details

On a remote-site device, ports can be used as internet ports, private WAN ports, or LAN ports:

• Internet ports connect to public networks.

• Private WAN ports connect to the private WAN either directly as a router replacement or through an existing router.

• LAN ports connect to the core, distribution, or access-layer LAN.

If your remote-site device is behind a NAT device and you plan on adding a secure fabric link to directly connect to another
remote-site device, then when you configure the internet port, you must provide the external NAT IP address that maps to the
private IP address assigned to the port.

Figure 29 Prisma SD-WAN remote-site topology

The ION devices maintain a separate forwarding information base (FIB) for each interface, which enables devices to support
different default gateways on multiple interfaces. In most cases, you do not need to configure static routes, because the
interface-specific routing information contained in the FIB is sufficient to build links between ION devices. After links are active
on an ION device, it chooses the best path based on the path policy.

On both data center and remote-site devices, all internet ports must be configured with a default gateway. On data-center
devices, you can simplify the routing configuration by using two separate ports in order to connect to the WAN edge and
LAN, and you then configure a default gateway on the port connected to the WAN edge. On remote-site devices, you can
simplify the routing configuration by setting a default gateway on private WAN ports.

Bypass Pairs

To improve the resiliency of the network, you can use bypass pairs. You typically use a bypass pair in a high availability design
in a topology that contains two ION devices in parallel.

Palo Alto Networks 61

 Design Details

Figure 30 Hardware bypass pair

A bypass pair is a pair of ports where one port is connected to a WAN network and the second port is connected to a LAN
network. You can configure bypass pairs for remote-site ION devices only.

There are two types of bypass pairs:

• Hardware bypass pair—A pair of ports or ethernet interfaces that can be associated with each other and have
underlying support for a hardware bypass relay. Each hardware device has strict pairing rules that allow only certain
ports to be paired together.

• Virtual bypass pair—A pair of ports or ethernet interfaces that can be associated with each other without any
hardware capabilities.

If you do not want to use the bypass pair functionality, you can decouple a bypass pair into two individual ports and use the
individual ports normally. Controller ports cannot be used within a virtual bypass pair.

Depending on your network topology and high availability requirements, you can choose from the following bypass pair
usages:

• Internet or private WAN—One interface of the bypass pair is WAN-facing, and that interface has a static or dynamic
IP address. The other interface connects to the LAN. The ION device can actively participate in routing.

• Private Layer 2 (L2)—One interface of the bypass is private WAN-facing, and the other interface connects to the
LAN. The ION device is transparently inserted within the existing network topology and does not participate in routing.
This type of deployment is considered a legacy deployment model. In most cases, Palo Alto Networks recommends
layer 3 deployments, such as an internet WAN, private WAN, or LAN.

• LAN—Only one interface of the bypass pair is used. This usage is only required when configuring the remote-site ION
device as part of a high-availability cluster.

Palo Alto Networks 62

 Design Details

Standard VPN

If you need to integrate your Prisma SD-WAN with cloud security services like Prisma Access, partner networks, or existing
legacy networks, you can configure a standard VPN connection by using either IPSec or GRE tunnel encapsulation. Cloud
Manager includes default IPSec profiles for many commonly used third parties and also allows you to configure custom
profiles.

To manually configure a standard VPN connection, you first create a new standard VPN interface and associate it with a
parent interface, which is used as the tunnel source. You then specify the peer details for IPSec or GRE respectively. You
must also complete the corresponding peer configuration on the remote device.

Although you can manually configure Standard VPN connections on any data-center ION device or any remote-site ION
device, Palo Alto Networks recommends that you only configure Standard VPN connections on ION devices at remote sites,
because you cannot apply network policies to data-center sites.

Circuits and Networks

Prisma SD-WAN supports 32 public and 32 private circuit categories, which you can customize to match your organization's
requirements. A variety of default public and private circuit categories are pre-configured to match commonly used WAN
transport options. The circuit category configuration includes settings for the VPN keep-alive timer interval and VPN keep-
alive failure count, which you can adjust to fine-tune the link failure detection.

Commonly used public-circuit categories include the following:

• Internet cable

• Internet DSL

• Unmetered 3G/4G/LTE internet

• Metered 3G/4G/LTE internet

• Ethernet internet

• Satellite internet

Commonly used private-circuit categories include the following:

• MPLS

• Leased-line

• Metro ethernet

• Private fiber

Similar to circuit categories, you can manage the public and private networks that interconnect your sites. The network
names are used to differentiate between service providers; however, you can only associate a single network to each circuit
category. If you use two service providers for the same circuit category, Palo Alto Networks suggests that you rename an
unused circuit category in order to differentiate between the two providers.

Palo Alto Networks 63

 Design Details

When you add a site, you specify which internet circuits and which private WAN circuits service the site. For each circuit, you
provide the circuit category, network, and a site-specific circuit name. You should also configure additional site-specific circuit
details, including the settings for bandwidth, link quality monitoring, QoS, and Bidirectional Forwarding Detection mode.

As you add circuits for a site, the circuits are associated with the ION devices deployed at the site. On data-center devices,
only a single public circuit can be assigned to a port, but you can assign multiple private WAN circuits to a port. On remote-
site devices, you can assign a circuit to a single port only. The circuits available for an interface depend on the site type and
the port usage. For specific usage details, see the following tables.

Table 9 Data-center device circuit use

Use this port for Circuit (choose from)

Connect to internet Internet circuits (one)

Peer with a network Private WAN circuits (one or more)

Table 10 Remote-site device circuit use

Use this port for Circuit (choose from)

Internet Internet circuits (one)

Private WAN Private WAN circuits (one)

Private L2 Private WAN circuits (one)

Secure Fabric Links and Service Links

The method you use to connect your ION devices to remote endpoints depends on whether the remote endpoint is another
ION device in your SD-WAN or an external, third-party device.

A secure fabric link is an IPSec VPN overlay tunnel between ION devices that is orchestrated and monitored by the Prisma
SD-WAN portal and controller.

Although Prisma SD-WAN can forward traffic between sites by using physical interfaces connected to a private WAN
network, typically, inter-site traffic uses secure fabric links. When you switch a site's operating mode from analytics mode to
control mode, secure fabric links are enabled on all public and private circuits between a remote site and data center.

Secure fabric links are never created between data-center sites.

Palo Alto Networks 64

 Design Details

Table 11 Secure fabric link

Circuit Data-center public Data-center private circuit Remote-site public Remote-site private
circuit circuit circuit

Remote-site All to all N/A Supported None

public
(Automatically enabled) (Selectively enabled)

Remote-site N/A All to all with same circuit N/A Supported

private category
(Selectively enabled)
(Automatically enabled)

As noted previously, if your data center or remote-site device is behind a NAT device, you must provide the external NAT IP
address that maps to the private IP address assigned to the port.

A standard VPN connection uses a service link to connect to a standard VPN endpoint by using either an IPSec tunnel or
a GRE tunnel. You can configure service links from both data-center sites and remote sites. A service link is automatically
created when you add a standard VPN interface. To complete the configuration of a service link, you must configure the
proper settings on the third-party device separately.

Protocol Support

IPv4

Prisma SD-WAN supports IPv4 on all device interfaces. On your ION device, when you assign an IPv4 address on an internet
or private WAN interface, any secure fabric links from that device use IPv4 addresses for source and destination.

LAN interfaces support only IPv4 addresses.

IPv6

Prisma SD-WAN also supports IPv6 on WAN-facing interfaces. However, before assigning an IPv6 address on an internet or
private WAN interface, you must first assign an IPv4 address to the interface. A configuration that uses only an IPv6 address
is unsupported.

On an ION device with IPv6 interfaces, when connecting to other sites with IPv6 interfaces, the secure fabric links from that
device use both IPv4 and IPv6 addresses for source and destination. When the secure fabric links are active over both IPv4
and IPv6, Prisma SD-WAN prefers the IPv4-based path. If a network failure affects the IPv4-based path, Prisma SD-WAN
activates the IPv6-based path.

IPv4 Multicast

Prisma SD-WAN supports IPv4 multicast on both WAN and LAN interfaces. An ION device deployed as a branch site
supports LAN multicast senders and receivers but can only receive WAN multicast traffic. An ION device deployed in a data
center receives multicast from peers and transmits multicast to connected branch sites over public VPNs.

Palo Alto Networks 65

 Design Details

To configure LAN multicast routing, you need to configure a rendezvous point (RP) and enable multicast on at least one Layer
3 interface in the network. To configure WAN multicast, routing, you need to create a WAN multicast profile, associate it with
a branch site, and enable multicast on the data-center ION device.

Traffic Classes

When you configure your Prisma SD-WAN, one of your first tasks is to manage your enterprise global prefix list. By default,
the portal includes the RFC-1918 private networks as your enterprise global prefix list. If you use other, additional prefixes,
you must add them to this prefix list. If necessary, remove or modify the private network ranges.

Table 12 Default enterprise global prefix list

Prefix Range

10.0.0.0/8 10.0.0.0–10.255.255.255

172.16.0.0/12 172.16.0.0–172.31.255.255

192.168.0.0/16 192.168.0.0–192.168.255.255

Enterprise traffic includes all traffic with a destination in the enterprise global prefix list, and non-enterprise traffic includes
traffic to any other destinations. The Prisma SD-WAN network policies differentiate between enterprise traffic and non-
enterprise traffic.

Endpoints, Domains, and Groups

A service endpoint is a label representing a specific location or network service. Prisma SD-WAN endpoints are data-center
sites. Standard VPN endpoints are cloud services, such as Prisma Access.

The portal automatically adds Prisma SD-WAN endpoints when you create data-center sites. You must manually create
standard VPN endpoints, and you can optionally include IP address ranges or FQDNs for the endpoint. Additionally, you can
enable liveliness probes to the standard VPN endpoints in order to verify that they are active and reachable. When you create
a standard VPN endpoint, you can also choose whether or not to allow enterprise traffic to that specific endpoint.

A domain can be any logical grouping of sites, but domains are typically used to separate geographic locations into regions.
The default configuration includes a preset domain, which is used for sites not explicitly mapped to configured domains.
Domains are tightly coupled with service groups.

A service group is a label representing a set of common service endpoints. A Prisma SD-WAN service group contains only
data-center sites, and you can select which data-center sites are included in a specific service group within a domain. A
standard VPN service group contains only standard VPN endpoints, and you can select which endpoints are included in a
specific group within a domain.

The primary benefit of using domains and service groups is that you can build broad policies that apply to multiple domains,
and these policies are interpreted differently based on a site's domain. This method simplifies the creation of network policies
and reduces the total number of network policies that you must create.

Palo Alto Networks 66

 Design Details

For example, you could separate the United States into two regions and configure two domains: East-US and West-US. You
could then configure two service groups: Primary-DC and Secondary-DC. For the East-US domain, the Primary-DC group
includes a data center endpoint located in the eastern US, and the Secondary-DC group includes a data center endpoint
located in the western US. Similarly, for the West-US domain, the Primary-DC group includes a data center endpoint located
in the western US, and the Secondary-DC group includes a data center endpoint located in the eastern US. At the network
policy level, a single common policy for both domains includes a Primary-DC and a Secondary-DC. Separate policy rules are
not required.

Table 13 Example domain and service group configuration

Service group East US domain West US domain

Primary-DC DC-East DC-West

Secondary-DC DC-West DC-East

Network Contexts

If you have multiple user communities using a common application and want to apply community-specific network policies
for the application, you can use network contexts. Similarly, if you need to isolate certain user communities and keep their
network traffic logically separate, you can provide isolation by using network contexts along with ZBFW.

Using Cloud Manager, you must first create the network context as a policy setting and then assign the network context to
specific interfaces on your remote-site ION devices. After you have completed the context set up, you can apply policies that
are context specific. Any interfaces that do not have a context assignment remain in the default context.

You do not automatically achieve traffic isolation by creating and assigning a network
context. By default, inter-context traffic is permitted
To restrict access from a network context, you must also assign a security zone and apply a
security policy.

Palo Alto Networks 67

 Design Details

You can use network contexts for multiple purposes:

• Guest user access—By assigning an interface to a guest network context, you can keep guest traffic that enters
the ION device on that interface logically separate from internal-user (non-guest) traffic. If you want to enable guest
networking across multiple sites and reuse the same IP subnet for the guest network at each site, you can set the
interface scope to local. If your guest user-access policy limits access only to the internet and does not need to
traverse a secure fabric link, you can apply a network policy that forwards all guest user traffic to a directly connected
internet path. To enforce isolation and block access to internal networks requires ZBFW.

• Differentiated network policy for source networks within a context—Instead of creating path prefix lists to identify
specific sources, you assign an interface to an application-based network context, such as IP-telephony. You can then
craft an application policy for any traffic sourced from an interface assigned to this context and specify a preferred
path or QoS prioritization.

• Differentiated network policy for a common application—If you have an application that multiple communities use,
such as SSL, and want to apply a differentiated policy based on a particular source community, you can assign an
interface to a community-based network context, such as IOT. You can then craft an application policy that applies a
less preferred QoS policy for SSL for IOT devices.

High Availability and Scaling

Remote-Site High Availability

If your organization's business requirements for a remote site include device resiliency, you can design the site using ION
devices in a high availability (HA) topology. At each site, you create an HA group that includes two ION devices, which you
bind to the HA group.

To ensure deterministic behavior, when you configure the HA group members, you assign a priority (1-254) to each ION
device. Assign a higher priority to the device that you prefer to be the active device and a lower priority to the device that you
prefer to be the backup device (example: active priority 50, and backup priority = 45).

Palo Alto Networks 68

 Design Details

Figure 31 High-availability design

The design shown in Figure 31 requires that you use external LAN switches to terminate the WAN links from ISP-1 and ISP-2.
You must physically cable each ION device directly to each external LAN switch.

The HA group members should both be the same platform to ensure equivalent performance during a failure scenario.

The ION devices in the HA group communicate with each other using a HA control interface. Palo Alto Networks
recommends you use the controller port on your ION devices as the HA control interface if your device includes a controller
port. If your device does not include a controller port, the HA control interface can be any Layer 3 interface on the ION device
with a statically configured IP address.

If you intend to use the controller port as the HA control interface, to maintain
communication to Cloud Manager, you should manage your ION device through a ZTP-
capable port.
If you connect the HA control interfaces to a dataplane subnet with access to the internet,
you can use the controller port for communication to Cloud Manager after your site
configuration is complete.

Requirements for HA control interface configuration include the following:

• Both HA control interfaces must be on the same IPv4 subnet.

• HA control interfaces should use unique static IP addresses.

Palo Alto Networks 69

 Design Details

• Connect both HA control interfaces to an external LAN switch or to two separate external LAN switches with a
common VLAN for the HA control interfaces.

• When using an SVI as the control interface, you must interconnect the ION devices in the HA group through an
external LAN switch. You must configure the switch ports in trunk mode, and the VLAN-allow-list for the trunk ports
must include the VLAN assigned to the control SVI.

Do not directly interconnect the ION device control interfaces with an Ethernet cable. If the
active device is powered off, the HA control interface link state for the backup device will be
down and the backup device will not transition to the active state.

On the active device, all interfaces are active. On a backup device, for most ION hardware platforms, the IP configuration is
suppressed for interfaces assigned as LAN port, internet port, or private WAN port. When suppressed, the interface status is
up, but the interface does not have an active IP address and does not transmit or receive.

If you are using a static IP configuration for an interface, you should configure the IP address of the backup device as a
duplicate of the active device. For remote-site devices, you would typically use static IP addresses on LAN ports and private
WAN ports. If your Internet ports can receive an IP address from DHCP and the DHCP server pool can support multiple
devices, you can configure both the active and backup device to use DHCP.

If you are using an ION 1000 or ION 1200 as a backup device, the IP configuration is
not suppressed for any interfaces assigned as an internet port. If using this design, you
must assign a minimum of a /29 subnet for each WAN circuit to allow for each ION device
(backup and primary) to have a unique IP address on the WAN subnet.

After you complete the basic configuration and connect the HA control interfaces, the devices negotiate active/backup
status.

If your device configuration includes any duplicate IP addresses, you must complete the HA setup and interface configuration
on both devices before you connect the LAN and WAN interfaces.

HA groups are intended to be used with hardware bypass pairs. On an active device, if you configure the bypass pair port
for Internet or private WAN, the bypass pair WAN port is active and the associated bypass pair LAN port is isolated. On a
backup device, if you configure the bypass pair port for Internet or private WAN, the bypass pair WAN port is inactive and is
bridged through to the associated bypass pair LAN port.

Palo Alto Networks 70

 Design Details

Figure 32 High-availability design using hardware bypass

You can cross-connect the HA group members into a topology that allows you keep both WAN links active and forwarding,
regardless of which device is active. Hardware bypass pairs do not require an external LAN switch for the WAN interfaces.

When using hardware bypass, after a device failure, all WAN links remain active on newly active devices.

Figure 33 High-availability design using hardware bypass (after device failure)

Palo Alto Networks 71

 Design Details

Data-Center Site High Availability

By default, when you create a data-center site and assign ION devices to the site, Cloud Manager automatically creates a
data-center cluster and assigns the devices to this cluster. In most cases, you only need to use the automatically created
cluster, and the portal does not display any cluster details in the site configuration unless you enable the advanced view.

ION devices at data-center sites do not support HA groups, so you cannot use the same techniques that you use in a remote
site for a data center high-availability design. Instead, you can achieve site resiliency without requiring any special high-
availability protocols. To improve the fault tolerance in your data center, you need to deploy data-center ION devices in pairs
and use BGP routing in order to detect a device failure and reroute traffic to the alternate data-center ION device.

Each data-center ION device is independent and does not peer, synchronize, or share other state information with other data-
center ION devices. A branch ION device negotiates secure fabric links to both of the ION devices at the data-center site, and
the branch device determines which data-center ION device is active for the branch site. The active data-center ION device
typically corresponds to the first secure fabric link that the branch device successfully establishes. At any moment, all active
branch connections might use a single data-center ION device, or the active branch connections might be distributed across
both data-center ION devices. To achieve high availability, in the data center, you must deploy ION devices with sufficient
capacity for a single device to support all branch sites active. Otherwise, during failure conditions, the SD-WAN operates in
degraded mode.

Figure 34 Data-center high availability

Palo Alto Networks 72

 Design Details

In a data-center high-availability configuration, each ION device that you assign to the site operates in active mode and you
must assign unique IP addresses to each device. You must also create a BGP peering session from each core-LAN routing
device to each ION device. To achieve fast convergence in case of a device failure, Palo Alto Networks recommends that you
set the BGP keepalive timer to 1 second and the BGP holder timer to 3 seconds. The data-center ION devices advertise the
global scope prefixes for their active branch sites to the core-LAN.

When using a pair of DC ION devices in a high-availability configuration, each branch site
selects one DC ION device (within a cluster) to be active. To ensure IP reachability between
branch sites active to different DC ION devices, each DC ION device must have either a
default route or a WAN summary route directing traffic to the core router.

You do not require any additional configuration on the branch-site ION devices.

Data-Center Site Scaling

In a single cluster data-center design, you should choose the DC ION platform with sufficient performance to support your
current requirements and any planned growth. If you intend on using data-center high availability, within a cluster you deploy
your devices in pairs.

In most data center designs, a single cluster is sufficient to connect all remote sites. However, for an SD-WAN with many
remote sites, you might want to consider a multi-cluster data center design. The primary reason you deploy a multi-cluster
design is to distribute Prisma SD-WAN branch sites across multiple data-center clusters in order to manage scale and reduce
the impact of a data-center device failure. As an example, you could logically group branches in different regions by assigning
them to region-specific clusters within their data-center hubs. If you implement a multi-cluster design primarily for scaling
purposes, you can configure a cluster soft limit. With a soft limit, Cloud Manager notifies you that you have exceeded the limit
but does not prohibit you from exceeding the limit.

Palo Alto Networks 73

 Design Details

Figure 35 DC multi-cluster design

The high-availability design previously discussed applies to a data-center IONs within a single cluster or in a multi-cluster
topology. In a multi-cluster design, you duplicate the single-cluster high-availability model for each cluster.

The first data center cluster that Prisma SD-WAN automatically creates at a site is also the default cluster for the site. When
you add new remote sites, the branch IONs connect to the default cluster unless you specifically assign them to an alternate
cluster. If you create any additional clusters, you can designate one of them as the new default cluster. To manage data
center clusters, in Cloud Manager you must configure the advanced site settings to show the DC clusters view.

In a multi-cluster design, when you assign an ION device to a data-center site, you should
assign the device directly to the designated cluster using the DC clusters view.
If you use the traditional device view to assign the new ION device to a data center, Cloud
Manager automatically assigns the device to the default cluster. In this case, you would need
to unassign the device and then assign the device to the designated cluster.

When adding a new branch site, you can specify the cluster in each data-center site to which you want the site to connect.
For an existing environment, after creating a new cluster, you can manually migrate connected branch sites to the new
cluster. There is a brief disruption when you reassign the branch site from one cluster to another. Although it is not a common
configuration in most Prisma SD-WAN deployments, you can configure a branch site to connect to no cluster for a particular
data center. When configured for no cluster, a branch ION device does not establish VPNs with that data-center site.

Network and Security Policies

Prisma SD-WAN path-forwarding behavior is unlike in traditional destination-based-routing networks. ION devices do not
make their path-selection decisions based only on a single table of route destinations.

Palo Alto Networks 74

 Design Details

You can apply Prisma SD-WAN network policies only to remote sites. ION devices at Prisma
SD-WAN data-center sites automatically enforce routing symmetry for sessions initiated from
a remote site and return data traffic on the same path on which it was originally received.

Path options are evaluated based on a hierarchy starting with the set of public and private WAN networks that provide service
to a site. From this set, the paths are then filtered by policy and network reachability to determine the active paths. Based
on the availability and performance of active paths, best path selection is automatically enabled for each application. A
backup path is selected only when an active path cannot be used for a given application session. A Layer 3 (L3) failure path is
selected only when all active and backup paths are unavailable due to the loss of L3 reachability.

Path Types

When crafting your network path policy, you can choose from the following path type options:

• Direct Internet—Physical connection to a public circuit

• Internet VPN—Secure fabric link across a public circuit

• Private WAN VPN—Secure fabric link across a private circuit

• Direct Private WAN—Physical connection to a private circuit

• Standard VPN—Service link to a standard VPN endpoint using standard IPSec.

The path policy rules for Direct Internet and Direct Private WAN can be generalized and apply to all circuits within a circuit
category (example: Any Public or Any Private) or can be more specific and apply to specific circuits only.

The path policy rules for Internet VPN, Private WAN VPN, and Standard VPN can be generalized and apply to secure fabric
links or service links enabled over all circuits within a circuit category (example: Any Public or Any Private), or these path
policy rules can be more specific and apply to secure fabric links or service links enabled over specific circuits only.

Policy Stacks, Policy Sets, and Policy Rules

Network policies include path, QoS, Security, and NAT policies. You configure each of these policies by using policy sets,
which are evaluated in a priority order referred to as a policy stack. Each policy set includes one or more policy rules. You
manage network policies for your organization by using separate policy stacks for path, QoS, Security, and NAT.

Palo Alto Networks 75

 Design Details

Path and QoS Policies

The path and QoS policy stacks include a default policy set and up to 4 additional policy sets. Path policy rules and QoS
policy rules can include the following match attributes:

• Order—The priority of the policy rule (between 1 and 65535). Rules evaluate the four match-attributes below and then
use an explicit match if the priority value is unique or use an implicit match if multiple rules have the same priority order
value. With an implicit match, the most specific match takes precedence.

• Network context—A logical network segment. You typically use a network context to identify traffic associated with a
specific user community, such as guest users.

• Source prefix—An IP prefix list that matches traffic source. Source prefixes can be defined as either global or local in
scope. A global prefix has the same values across all sites. A local prefix allows you to configure site-specific values.

• Destination prefix—An IP prefix list that matches traffic destination. Destination prefixes can be defined as either
global or local in scope. A global prefix has the same values across all sites. A local prefix allows you to configure site-
specific values.

• Applications—The list of applications that match the policy rule. The applications are defined using either L7 or L3/
L4 information and include both system and custom applications. System applications are applications that Palo
Alto Networks defines, manages, and maintains. These applications are preloaded and continuously updated in
your system. These definitions are shared using a common App-ID database with the PAN-OS NGFW, allowing for
consistent security policy across both. Custom applications are applications that you define, manage, and maintain,
and they are unique to your organization. You assign each application a transfer type—real-time audio, real-time video,
transactional, or bulk. Transfer types are used to determine the QoS queue assignment.

Path policy rules can include the following actions:

• Paths—Define the set of allowed paths for an application. These include active paths, backup paths, and L3 failure
paths used by a matching rule. Backup paths are only selected when no available active paths exist. L3 failure paths
are used as a last resort when no available backup paths exist.

• Service and data-center groups—Define the set of active and backup Prisma SD-WAN or standard VPN service
groups used as a transit destination by a matching rule.

Palo Alto Networks 76

 Design Details

QoS policy rules can include the following actions:

• Priority—Assign a QoS priority category of platinum, gold, silver, or bronze. Within each category, there are four
queues that map to the application transfer type. The default values for the total amount of bandwidth allocated and
queue sizing per-category are shown in Table 14.

• DSCP—Mark or remark the traffic with a specific DSCP value.

Table 14 Default QoS priority and queue configuration

Property Platinum Gold Silver Bronze

Bandwidth allocation 50% 25% 15% 10%

(percentage of circuit
bandwidth)

Real-time audio 20% 20% 20% 20%

(queue size as percentage of

allocation)

Real-time video 30% 30% 30% 30%

(queue size as percentage of

allocation)

Transactional 30% 30% 30% 30%

(queue size as percentage of

allocation)

Bulk 20% 20% 20% 20%

(queue size as percentage of

allocation)

Security Policies

The security policy stacks include a default security policy set and up to four additional security policy sets.

Security policies control application access across zones by using the Prisma SD-WAN ZBFW. Security policies are bound to
remote sites only. If you want to apply a security policy for traffic to or from a data center, you configure security policy rules
on your remote-site devices.

Applications are the core element of the ZBFW, and you use them to control network traffic and to implement security
policies. You use the same application definitions for security policies that you use for network policies.

Palo Alto Networks 77

 Design Details

Security Zones and Links

Before you configure your security policy rules, you must create security zones and bind them to networks on each remote-
site device. A typical ZBFW deployment might contain the following zones:

• PRIVATE—Associated to private LAN networks at remote sites

• PUBLIC—Associated to public network connections, such as internet

• WAN—Associated to private WAN network connections

• VPN—Associated with overlay VPN secure fabric tunnels

• GUEST—Associated with guest networks

Depending on your organization's security policy, create additional zones for a more granular security policy or use fewer
zones for a less granular security policy.

The ZBFW zone bindings use an internal link type classification for each network:

• port—Associated to physical or virtual interface used for LAN attachment

• subinterface—Associated to a VLAN sub-interface

• lan—Associated to IP prefixes assigned to a site

• privatewan—Associated to a circuit assigned to a physical or virtual interface used for a private WAN

• publicwan—Associated to a circuit assigned to a physical or virtual interface used for an internet connection

• service_link—Associated to a standard VPN interface

• vpn—Associated to the system-maintained set of all overlay tunnels

Before you create a security policy and bind it to a site, on the devices at the site, make
sure to bind security zones to all the networks. The ZBFW drops traffic to or from a network
without a security zone.
Palo Alto Networks recommends that you perform zone binding at the device level instead of
the site level.

Security Rules

Security policy rules can include the following match attributes:

• Order—The priority of the policy rule

• Source zone—The zone from which the traffic originates

• Destination zone—The zone to which the traffic is destined

Palo Alto Networks 78

 Design Details

• Source prefix filters—An optional IP prefix list that matches the traffic source. Prefix filters can be defined as either
global or local in scope. A global prefix filter has the same values across all sites. A local prefix filter allows you to
configure site-specific values.

• Destination prefix filters—An optional IP prefix list that matches the traffic destination. Prefix filters can be defined as
either global or local in scope. A global prefix filter has the same values across all sites. A local prefix filter allows you
to configure site-specific values.

• Services—An optional list of predefined or custom IP protocols and source and destination port ranges that match
the policy rule.

• Applications—The list of applications that match the policy rule. The applications are defined using either L7 or L3/L4
information and include both system and custom applications.

Security policy rules can include the following actions:

• Deny—The ZBFW silently drops traffic that matches this rule, without sending a TCP reset or an ICMP host
unreachable message to the client or server.

• Reject—The ZBFW drops TCP traffic that matches this rule and also sends a TCP reset to both the client and server.

• Allow—The ZBFW forwards traffic that matches this rule.

NAT Policies

A NAT policy stack includes up to four policy sets, which includes a default policy set.

Before you configure your NAT policy rules, you must create one or more NAT zones and bind them to device interfaces. By
default, the internet zone is already created and bound to all interfaces configured as Internet. A default NAT policy set with a
single destination zone rule is also created by default. The default rule performs source NAT to the egress device interface.

NAT policy rules can include the following match attributes:

• Order—The priority of the policy rule

• Source zone—The zone from which ingress traffic is sourced. If you specify a source zone, the rule is created as a
source zone rule.

• Destination zone—The zone to which egress traffic is destined. If you specify a destination zone, the rule is created
as a destination zone rule.

• Source prefixes—An IP prefix list that matches traffic source. A source prefix can be defined as either global or local
in scope. A global prefix has the same values across all sites. A local prefix allows you to configure site-specific values.

• Source port ranges—Optional ranges of ports (up to 16), to further match on traffic source

• Destination prefixes—An IP prefix list that matches traffic destination. A destination prefix can be defined as either
global or local in scope. A global prefix has the same values across all sites. A local prefix allows you to configure site-
specific values.

Palo Alto Networks 79

 Design Details

• Destination port ranges—Optional ranges of ports (up to 16), to further match on traffic destination

• Protocol—Optional to further match specifically on TCP, UDP, GRE, ESP, or other specified IP protocol (by number)

Each NAT rule can perform up to 4 actions. Some actions require that you create NAT pools. A NAT policy rule can include
the following actions:

• No NAT—Do not perform NAT on traffic matching this rule. No other actions are configured.

• Source NAT—Perform NAT source address translation to an address in the specified NAT pool.

• Destination NAT—Perform NAT destination address translation to an address in the specified NAT pool. You can
optionally translate the destination port.

• Static Source NAT—Perform NAT source address translation for a range to a corresponding address range in the
specified NAT pool.

• Static Destination NAT—Perform NAT destination address translation for a range to a corresponding address range
in the specified NAT pool.

• ALG Disable—This action supports a special set of use cases for protocols, such as SIP, that embed port information
with the packet payload and do not consistently work properly when NAT is configured. Use this option to disable the
SIP application layer gateway.

Managing Prisma SD-WAN Deployments

Cloud Manager is the primary method for managing your Prisma SD-WAN deployment. Before you add sites and devices
and before you configure your network and security policies, you should specify the global parameters that apply across
all sites. These parameters include your enterprise prefixes, domains, and circuit categories. As part of your deployment
plan, you should also identify your service providers, the bandwidth to each of the sites, IP addressing information, and zone
assignments for both your NAT and security policies.

ION Device Controller Ports

There are two valid methods for ION device management: you can use a data port that is factory-configured for internet
usage with DHCP, or you can use the device's controller port. All device types, except the ION 1000 and the ION 1200,
contain a controller port, and Palo Alto Networks recommends you use this port when possible.

At a central site with existing security infrastructure in place to secure traffic to the internet, connect the controller port to an
internal network. By default, you use the controller port to communicate with Cloud Manager. If necessary, in order to permit
the Prisma SD-WAN control plane applications, you might need to create additional security policy rules to permit traffic from
the ION device to the internet.

It is more complex to securely manage a device located at a remote site than a device located at a central site, because
you can typically use the device controller port when the device is at the central site. If, at your remote site, you have an
existing out-of-band network dedicated to device management, then you can follow the same approach that was previously
discussed for central site devices. If this is a new deployment and you want to perform a zero-touch deployment, then

Palo Alto Networks 80

 Design Details

connect an ZTP-capable port to an internet circuit at your site. To identify ZTP-capable ports, refer to your platform as listed
in Table 6. Your device registers with Cloud Manager in the same way as it would with a connection directly to the controller
port.

Using the ZTP-capable port, you can continue with configuration and management until the device is fully operational. At
this time, you can connect the controller port to the internal LAN at the remote site. Your device transitions to management
through the controller port once this connection is active.

Sites and Devices

For basic configuration, the portal is structured with a topology map and panes for sites and devices. You configure a portion
of the configuration details at the site level and the remaining details at the device level. However, you should first create and
configure the sites. As part of the initial configuration, you designate the sites as data center or branch and define the circuits
that are present at the site. For branch sites, you can also assign each one to a domain. Next, after you claim a device and
assign it to a site, you configure the device interfaces. For each interface, you must set the usage, assign the circuit, configure
the IP address, and, if necessary, configure the default gateway.

At new sites, you can connect the data plane interfaces at any time during the deployment, and they become active once
they are configured. At existing sites, Palo Alto Networks recommends that you configure the devices first before connecting
the data plane interfaces. Depending on the topology you choose, you might need to use bypass pairs to transparently insert
the device into the path. If you choose to replace your existing WAN router with an ION device, you should complete as much
configuration as possible before you remove the WAN router and move the connections to the ION device.

Routing

At data-center sites, the ION device does not connect in the path for access to private WAN and internal LAN networks. You
typically enable BGP dynamic routing in order to integrate the ION device into the topology. In an existing network, you use
a single port that is configured to peer with a network in order to connect with both the private WAN and internal LAN. This
method can reduce the number of changes that you need to make. In a new deployment, you can use separate ports for the
private WAN and internal LAN connections.

BGP routing on ION devices supports eBGP only.

In most data-center sites, network security infrastructure already exists. Connect the internet port to the network security
infrastructure that provides access to the internet. You must configure a default gateway on the internet port. However, for
internal users and devices, the ION device is not used to forward traffic directly to the internet.

At remote-site locations, if you choose to replace your existing WAN router with an ION device, you should connect interfaces
directly to the internet, private WAN, and internal LAN network. You must configure a default gateway on the internet port.
You can use either static routing or enable BGP dynamic routing to the private WAN range through the private WAN port, or
you can configure a default gateway to the private WAN. You do not need to configure any additional routing for the network
directly connected to your internal LAN port. If you have other internal networks, configure a static route or you can use BGP
dynamic routing to the internal LAN.

Palo Alto Networks 81

 Design Details

Depending on the site type and topology, Prisma SD-WAN ION devices support multiple BGP peer types. Each peer type
uses a different default configuration, as described in the sections that follow.

Classic Peer

Both data center and remote-site ION devices support the BGP classic peer type. When you configure a BGP classic
peer, the Prisma SD-WAN portal does not auto-generate any route-maps, prefix-lists, AS-path lists, or community lists.
You typically use this peer type in a remote-site design for router replacement. If you require any modifications to the peer
configuration, you can customize the parameters.

Figure 36 BGP classic peer

Core Peer

Only data-center ION devices support the BGP core peer type. When you configure a BGP core peer, Cloud Manager auto-
generates route-maps to control route advertisement and route learning to and from the core peer. By default, the data-
center ION device advertises only IP prefixes from currently connected remote sites. Because you do not physically insert the
data-center ION device into the forwarding path, the BGP route advertisement attracts traffic from the core network that is
egressing the data center.

On a data-center ION, after you have configured a BGP core peer (or a BGP classic peer), Prisma SD-WAN monitors the
status of the peer. If the peer status is down, Prisma SD-WAN marks all secure fabric links to the data-center site as unusable
and branch IONs drop traffic flows to or through the data-center site. If you have configured multiple peers, Prisma SD-WAN
marks the secure fabric links to the data-center site as usable only if at least one peer has a status of up.

With this peer type, when there are no prefixes learned from an edge peer, the data-center ION device advertises IP prefixes
from currently connected remote sites by using the prefix lengths configured for the sites' IP prefixes. If your core device is
also learning the same prefix from another routing peer, such as an MPLS CE router, you must modify the configuration on
your core device to prefer the prefix advertised from the data-center ION.

Palo Alto Networks 82

 Design Details

Figure 37 BGP core peer

With this peer type, when the data-center ION device learns the same prefix as a currently connected remote site from an
edge peer, the data-center ION device advertises a set of longer-match IP prefixes for the matched prefix to the core peer,
using a technique known as prefix splitting. As an example, if the data-center ION learns the prefix 10.130.0.0/21 from an
edge peer and you have configured a currently connected remote site with the same IP prefix, then the data-center ION uses
prefix splitting and advertises both 10.130.0.0/22 and 10.130.4.0/22 to the core peer.

When using prefix splitting, if your core device is also learning the same prefix from another routing peer, the longer prefix
lengths advertised from the data-center ION device are preferred over the original prefix advertisement. You do not typically
require any additional configuration on your core device to prefer the prefixes advertised from the data-center ION.

Edge Peer

Only data-center ION devices support the BGP edge peer type. With this peer type, the data-center ION learns IP prefixes
from an edge device such as an MPLS CE router. The data-center ION does not advertise any prefixes to the edge peer, and
this peer type is also referred to as listen only. When you have both edge peers and core peers, you might observe prefix
splitting towards the core when the appropriate conditions are met.

Palo Alto Networks 83

 Design Details

Figure 38 BGP core peer with edge peer

Additional Routing Configuration Options for Data Center Devices

For data-center devices, by default, traffic between remotes sites is directly forwarded without leaving the data-center ION
device. If you want traffic between remote sites that traverses the data-center ION device to be forwarded to an external
data-center device for inspection, monitoring, or filtering, then enable the Force VPN to VPN Traffic to Local Next Hop feature.

Because you cannot apply network policies to data-center sites, Palo Alto Networks recommends that you only use ION
devices at data-center sites for aggregating remote-site ION devices.

Palo Alto Networks 84

 Design Details

Additional Routing Configuration Options for Remote-Site Devices

For remote-site devices, you can enable the following routing configuration options:

• L3 Direct Private WAN Forwarding—By default, BGP configuration uses a bypass pair for private WAN underlay
traffic. If you do not use a bypass pair, you must explicitly enable L3 Direct Private WAN Forwarding so that the private
WAN port can communicate directly with a private WAN peer. You should also enable this feature if you want to use
L3 LAN forwarding.

• L3 LAN Forwarding—If you want to enable layer 3 traffic forwarding to and from LAN interfaces, you must enable L3
LAN forwarding on your device. This includes interfaces that are not bypass pairs. You must also configure L3 Direct
Private WAN Forwarding in order to enable this feature.

• Application Reachability Probes—If an ION device detects an unreachable prefix for an application, the device
automatically initiates an application reachability probe to check the availability of the application. By default, these
probes are sourced from the controller port, but you can configure an ION device to source the probes from any valid
L3 LAN interface in order to support cases where the device either does not have a controller port or the controller
port is not connected.

Monitoring Your SD-WAN

In addition to the configuration tasks listed previously, Cloud Manager also provides centralized monitoring and reporting
capabilities for your Prisma SD-WAN.

The activity dashboard provides a monitoring pane for overall network performance, which you can also use to isolate site-
specific performance. Other activity panes include media performance and link quality, where you can isolate individual
applications, paths, and sites. If you need to perform in-depth inspection of specific sessions, use the flow pane, and if
necessary, you can use advanced queries in order to filter and view specific flows.

You can also use the activity dashboard to monitor basic system health characteristics, such as CPU utilization, memory
utilization, and disk utilization. If you need to display IP routing details, you use the activity pane for routing stats to view the
routing peer status and prefixes that your devices advertise and learn.

If you need to access the ION device toolkit, you can remotely access any claimed device directly from Cloud Manager. In
Device Toolkit User Management, you must set the user credentials before accessing your devices.

Prisma SD-WAN Licensing

Prisma SD-WAN is licensed via subscription and according to the model of ION device, whether the appliance is physical
hardware or virtual. There are two subscriptions available: data center and bandwidth. The data center subscription is for the
ION 7000, 7100V, and 9000 and enables unlimited bandwidth. The bandwidth subscription is for any ION device deployed at
a remote site. The bandwidth license options are detailed in Table 15.

Palo Alto Networks 85

 Design Details

Table 15 ION bandwidth subscriptions by model

Platform Bandwidth subscription options

ION 1000 25 Mbps, 50 Mbps

ION 1200 25 Mbps, 50 Mbps, 150 Mbps, 250 Mbps

ION 1200-S 25 Mbps, 50 Mbps, 150 Mbps, 250 Mbps

ION 2000 25 Mbps, 50 Mbps, 150 Mbps, 250 Mbps

ION 3000 25 Mbps, 50 Mbps, 150 Mbps, 250 Mbps, 500 Mbps

ION 3200 25 Mbps, 50 Mbps, 150 Mbps, 250 Mbps, 500 Mbps

ION 7000 25 Mbps, 50 Mbps, 150 Mbps, 250 Mbps, 500 Mbps, 1 Gbps

ION 9000 25 Mbps, 50 Mbps, 150 Mbps, 250 Mbps, 500 Mbps, 1 Gbps, 2.5 Gbps

ION 3102V 25 Mbps, 50 Mbps

ION 3104V 25 Mbps, 50 Mbps, 150 Mbps

ION 3108V 25 Mbps, 50 Mbps, 150 Mbps, 250 Mbps

Palo Alto Networks 86

 Design Details

In addition to the bandwidth-based licenses, there are three optional software licenses available for remote-site bandwidth
subscriptions:

• Zone-based firewall—Application-aware, stateful, zone-based firewall that creates, manages, and enforces security
policies that protect internet connections in the remote site and propagate those policies to all remote sites.

• Prisma SD-WAN DVR license (Clarity Network DVR)—Provides a comprehensive real-time and historical view of
your network and application performance. You can gain better insight into traffic outliers and network anomalies,
which helps with better capacity planning, speeds troubleshooting, and improves compliance posture with access to
up to 90 days of statistics, policy, configuration, alarm, and alerts.

• Prisma SD-WAN Report license (WAN Clarity Reports)—Provides an auto-generated report that allows
administrators a deep understanding of how the circuits in the WAN application layer are being used from the
perspective of an entire fabric, site, circuit, application, or user. The report provides actionable insights you can use
for capacity planning, path policy adjustments, QoS policy adjustments, and enforcement of proper use of network
resources by the end-user community.

Prisma SD-WAN DVR and Prisma SD-WAN Report licenses are features enabled at the
customer level but must be purchased for every remote-site device.
Prisma ZBFW is licensed per remote-site device.

Palo Alto Networks 87

 Design Model

Design Model
This design model focuses on securing access to private applications for mobile users, remote-site users, and hybrid
workers. It describes how Prisma Access and Prisma SD-WAN extend protection to mobile and remote-site users, as well as
to hybrid-worker traffic destined for internal applications and services.

Figure 39 Securing private apps for mobile users and remote sites

SECURING PRIVATE APPS FOR MOBILE USERS

You use GlobalProtect on managed endpoints and the Prisma Access Enterprise edition, enabling access to the private
applications protected by the most comprehensive security feature set.

Prisma Access provides both visibility into the use of applications on the network and the ability to control user access to
those applications. Key to both visibility and control is the service's App-ID capability. By inspecting the session and payload
information of the traffic traversing the service, App-ID identifies applications and granular application functionality.

If you also want to leverage additional ZTNA 2.0 capabilities by integrating user identity and combining user, content, and
application inspection features to enable multi-mode cloud access security broker functions, you can follow the details in
Identity-Based and Posture-Based Security for SASE.

IP Address Assignment
When you configure Prisma Access for mobile-user gateways, you assign a block of IP addresses per region and a worldwide
pool for overflow. Prisma Access allocates a /24 subnet to each mobile-user gateway location that you enable, and then it
advertises each /24 subnet block in BGP individually (example: 10.10.10.0/24) to the customer network. For growth and
flexibility, the typical allocation of IP address aggregate pools per region assigns twice the number of IP addresses. For
example, a worldwide deployment of 10,000 users, with a sizing guidance of 20,000 IP addresses, will begin with an example
subnet of 10.10.0.0 with a /17 address mask for a contiguous block of up to 32,000 IP addresses. Instead of assigning the
entire block to a single worldwide pool, you divide it into three regional blocks and one worldwide block.

Palo Alto Networks 88

 Design Model

The following are an example of dividing the block of addresses:

• North America and South America—10.10.0.0/19

• Africa, Europe, and Middle East—10.10.32.0/19

• Asia, Australia, and Japan—10.10.64.0/19

• Worldwide—10.10.96.0/19

DNS Resilience
When you configure the GlobalProtect mobile-user DNS configuration, we recommend that you configure the internal
domains to be resolved by an internal DNS server and all external domains to be resolved by the Prisma Access default
DNS servers. With this configuration, an external DNS request is proxied to the Prisma Access default servers by using the
address of the mobile user's location gateway as the source. This ensures that in the event of a loss of connectivity to the
internal DNS, mobile users are still able to access the internet.

For a detailed explanation of the various deployment options for DNS resolution for mobile
users, see the Prisma Access Administrator's Guide.

Authentication and Connection

You deploy the GlobalProtect app on managed endpoints consisting of Windows, macOS, iOS, Linux, Google Chrome, and
Android devices. After the user enters the portal address into the app, the initial connection from the user initiates an on-
demand connection to Prisma Access.

Prisma Access authenticates all users and endpoints against a SAML provider, such as Okta or Azure Active Directory.
Prisma Access redirects the app to the SAML provider and opens a window for authentication. After authentication is
complete, including optional OTP support within the SAML authentication flow, the app sends the authentication status
cookie to Prisma Access. Prisma Access is unaware of the number of authentication factors the SAML provider uses.

The configuration at the SAML provider decides how long the SAML cookie is valid. While the SAML cookie persists and is
valid, the user experiences transparent authentication to Prisma Access.

When connected to Prisma Access, the GlobalProtect app obtains its configuration, which defines several things, including
the following:

• Internal gateway—Provides the IP address or FQDN of one or more internal gateways along with the internal IP
addresses that are allowed to connect to them. Prisma Access does not deploy or manage the internal gateway
but allows for the client configuration so that IP-to-user mapping occurs when the mobile users connect to an on-
premises network.

• Internal host detection—Provides an IP address and hostname pair that only resolves correctly when the endpoint
connects to an on-premises network. When the endpoint does not connect to an internal network, it bypasses the
connection attempt to the internal gateway.

Palo Alto Networks 89

 Design Model

• External gateways—Pre-populates the list of Prisma Access locations deployed as part of the service. You can also
add gateways that you deployed on-premises at your locations.

• Connection method—Sets the user-login (Always On) so that once the user logs on to the endpoint, a tunnel
connects to one of the locations. This connection method ensures that Prisma Access is always protecting the
endpoint when the user is mobile.

When the GlobalProtect app receives its configuration from Prisma Access, it authenticates and builds a VPN tunnel to the
nearest location. The MU-SPN associated with the location uses the same SAML provider as the portal, and if the cookie
obtained when authenticating to the portal hasn't expired, the node authenticates the client transparently. If the cookie has
expired because there has been a significant amount of time since the original authentication, then the node authenticates the
user through the SAML provider in the same way as the portal.

During the connection, the node provides the endpoint an IP address obtained from the IP pool that Prisma Access assigned
it during deployment. The node also generates an IP-to-user mapping.

Securing Traffic to Internal Resources

Traffic from the mobile endpoint to internal applications and services traverses the VPN to Prisma Access, then travels across
the service infrastructure to the service connection that has the best route to the internal network. There is no translation of
the source or destination IP address within the service infrastructure.

Prisma Access supports traffic between mobile endpoints. In most instances, mobile-to-mobile communication requires a
corporate-access node. Prisma Access deploys corporate-access nodes when you activate a service connection. The MU-
SPNs use the corporate-access node to interconnect within the Prisma Access infrastructure. Without a corporate-access
node, mobile-to-mobile communication can only happen when the endpoints connect to a common MU-SPN.

The default Prisma Access security policy allows mobile-to-mobile traffic, mobile-to-Prisma Access connected remote sites,
and traffic between mobile endpoints to internal applications and services because all of the tunnels and service connections
are members of the "trusted" zone.

You must select the Prisma Access Editions Net Interconnect license option in order to
enable mobile-to-Prisma Access connected remote-site traffic flows. Licensed service
connections enable the mobile endpoints to access internal applications in the data center.

Palo Alto Networks 90

 Design Model

Figure 40 Internal traffic

The Prisma Access security policy can control traffic from the mobile endpoint to the internal resources. Typically, you
implement a broad security policy in Prisma Access, and a more detailed policy on the devices that have visibility into the
application resources, such as a NGFW at the data-center edge that has visibility into the data center infrastructure and can
build dynamic address groups. You build the security policy for mobile-user and remote networks by using IP address blocks
because they share the same security zone.

When a NGFW is at the edge of an internal data center, you can use User-ID information derived from Prisma Access in
the firewall's security policy. Data-center firewalls can pull the aggregated User-ID information from the corporate-access
nodes. Additionally, for your most sensitive applications and services, you should use authentication policies to validate
that the expected user is initiating the traffic to the application. Authentication policies that match the traffic from specific
users to the application zone can force an MFA of the user before allowing access to ensure that the originator isn’t using
stolen credentials. The authentication policy in use forces MFA transparently to the application and is especially useful for
administrative access that doesn’t natively support or is challenging to configure for MFA.

Using MFA with a mobile endpoint connected to Prisma Access requires the following app configuration settings in Prisma
Access:

• Enable inbound authentication prompts from MFA gateways—To support MFA, you must configure the
GlobalProtect app to receive and acknowledge UDP prompts that are inbound from the gateway.

• Trusted MFA gateways—You can also configure the IP address and port (6082 by default) for the data-center firewall
that is acting as the MFA gateway. To act as the MFA gateway, the data-center firewall requires a GlobalProtect
license.

Additionally, all security devices between the data-center firewall and the endpoint, including the firewall policy on the
endpoint, must allow the authentication prompt traffic (UDP port 4501 by default).

Palo Alto Networks 91

 Design Model

Service Connections
Service connections provide secure access from Prisma Access to internal applications and services. The service-connection
options in this section begin with an initial attachment to Prisma Access from an on-premises facility using a single IPSec
tunnel, or pair of tunnels, for resilience. For larger, more complex environments, the designs progress into multiple service-
connections for increased resilience and/or optimized routing to on-premises applications or services. Although the examples
in this section refer to on-premises data centers, the applications or services could be cloud-hosted with dedicated access
into your Prisma Access network via a service connection.

The service-connection termination point can be a Palo Alto Networks NGFW or any IPSec capable firewall, router, or SD-
WAN endpoint. When terminating the tunnel on a non-Palo Alto Networks device, ensure that the remote IPSec endpoint has
support for more recent encryption and authentication in order to ensure secure transport.

Recall from the earlier “Service Connections to Enable and Optimize Mobile-User Traffic Flow” section that service
connections enable mobile-user communication between MU-SPNs and optimize MU-SPN traffic flow to service connections
in remote regions. In some scenarios, you might deploy a service connection with no VPN connection to a premises, using it
merely to optimize traffic flow in your Prisma Access network.

The service-connection options in this section differ in how they provide scale, flexible connectivity, and resilience. The
designs represent a growth path that organizations can use as they scale in their Prisma Access connectivity. This guide
describes the following service-connection options:

• Single service-connection—Proof-of-concept, initial network rollout, DIA-only environments with on-premises admin
servers, or the only required connection for an all cloud-based organization

• Multiple-Service-connections to multiple-autonomous-systems—Resilient design with optimized routing and

backup paths to and from Prisma Access to an organization's network that uses multiple BGP autonomous systems
for scale and fault isolation

• Multiple-service-connections to single-AS—Resilient design with optimized routing and backup paths to Prisma
Access from smaller networks with a single BGP AS

Choosing a Service-Connection

There is no strict rule for using one service-connection design over the other. You can choose to use one option multiple
times in your networks when connecting to Prisma Access. When choosing an option, consider the following factors:

• Connectivity—How many connections to HQ or data centers do you require for your network?

• Resilience—If you have a single HQ or data-center connection, do you want a resilient connection to Prisma Access?
If you plan to have multiple service connections, are your network peering points to Prisma Access connected
internally, as well?

• Scale—If you have multiple service-connections and you interconnect your network internally, as well, will your
network peer to Prisma Access as a single AS or as multiple autonomous systems?

Palo Alto Networks 92

 Design Model

Single Service-Connection Option

In this connection option, Prisma Access has a single connection from the customer premises HQ or data center. The
destination of the service connection is called on-premises; however, the location could be a cloud-based data center in
which your organization has resources, as well.

The single service-connection option differs from the other service-connection options described in this guide in that there
are no intra-organization network connections outside of those provided by Prisma Access. This means that an organization
could have a single HQ or data center service-connection for the entire organization, or it could have multiple islands of data
centers, cloud data centers, or regional service-connections. In this scenario, the organization does not have interconnectivity
of those centers outside Prisma Access.

Figure 41 Multiple single service-connections

The IPSec tunnels from Prisma Access to the organization's internal resources are Layer 3 routed links, and you can control
traffic with static or dynamic routing. Because this design supports Prisma Access for users only, set the Prisma Access
infrastructure service routing preference to hot-potato routing mode.

When you select a location from which to source your service connection, to reduce the latency of long-distance packet
transit, you typically select a location close to your on-premises location. An IPSec tunnel and an IPSec gateway definition
configure how the service connection routes to your on-premises device.

Prisma Access supports dynamic routing using the BGP routing protocol. When using dynamic routing, you advertise which
IP networks you have on your end of the service connection, versus statically defining your entire network on the Prisma
Access firewall. After you configure Prisma Access for BGP, it automatically advertises all infrastructure and mobile-user
address ranges to the on-premises peer.

On the Prisma Access end, there is no need to statically define a route to the IP address and subnet of the BGP peer of
the on-premises network device. Cloud Manager automatically configures a route to the BGP peer that you defined in the
onboarding process, pointing to the VPN tunnel that connects to on-premises devices.

Palo Alto Networks 93

 Design Model

Figure 42 Dynamic routing over service connection

You assign a BGP AS number to Prisma Access to use for routing to service connections and remote networks. This BGP AS
is typically a private AS number as defined in RFC-6996, and if you retain the default, the BGP AS is set to 65534. You must
also configure the BGP AS number in use on the on-premises BGP peer router, as well as the BGP RID. As a best practice,
configure the secret passphrase for the BGP peer to use to authenticate communications. After you onboard the service
connection in the chosen location, the Prisma Access console shows which infrastructure IP address it assigned for the BGP
peer.

The Prisma Access BGP AS number must not be the same as your on-premises BGP AS
number. Prisma Access accepts only eBGP connections.

At the on-premises network device, an IPSec tunnel, Layer 3 VPN tunnel, and an IPSec gateway definition on your
organization's device configure how to connect to the Prisma Access corporate-access node. You must configure BGP to
advertise to Prisma Access your organization's subnets that you require mobile users and the Prisma Access infrastructure to
reach.

For resilience, you should assign the BGP RID as a loopback interface in the on-premises network device. The BGP peer
defined on the on-premises device should point to the Prisma Access BGP AS, and the service connection's BGP peer ID.
You should configure BGP to advertise an aggregate of the IP addresses in the organization versus all downstream routes
and subnets. For example, the on-premises device would advertise 10.5.0.0/16 for all data-center routes.

Multiple-Service-Connections to Multiple-Autonomous-Systems Option

Many organizations use BGP to scale a large network by summarizing IP prefixes at regional or autonomous system borders.
This use of BGP provides fault isolation by containing network link or site failures inside of the AS. In these scenarios, the
organization can peer to Prisma Access with multiple BGP private AS numbers.

In this option, the following design details apply:

• Prisma Access has three connections from the organization's on-premises headquarters or data center.

• The organization's network has IP transport between the service-connection termination points, providing alternate
paths based on network location and state.

• The organization's network connection to Prisma Access is multiple BGP autonomous systems with inter-AS
connectivity within the organization's network.

Palo Alto Networks 94

 Design Model

We refer to the destination of the service connection as on-premises; however, this destination could be a cloud-based data
center in which your organization has resources, as well.

Figure 43 Multiple-AS WAN design

The goal of this option is for an organization with multiple BGP autonomous systems to do the following:

• Route Prisma Access mobile-user connection traffic to a service connection, then to the target application host or
user in the organization, with symmetrical return traffic.

• Converge Prisma Access mobile-user organization traffic over an alternate path in the event of a single service-
connection outage.

• Assign two data centers in the same geographic region as a backup to each other when routing mobile-user traffic
from Prisma Access.

This design uses three data centers as an example, each acting as the hub of a unique AS. Two of the data centers operate
as backup to each other with one in the West area of a region and the second in the East area of that region. The data
centers interconnect with links for intra-organization transport between data centers.

This design uses BGP to advertise the IP subnets that each regional data center connects and aggregates to Prisma Access.
In BGP, you advertise the aggregate or summary route for all of the subnets in each of the data centers. Prisma Access
sees three summary routes, one per data center, and prefers the path with shortest AS path length. Each data center is also
advertising the respective summary routes to the opposite data center, which then advertises them to Prisma Access with the
BGP AS of that data center added; this becomes a backup path due to the longer AS path.

Prisma Access also adds a BGP community string to each mobile-user subnet route advertisement that identifies from
which service-connection and corporate-access node the mobile-user connection originates. Recall that when you provision
a mobile-user gateway location, Prisma Access creates an MU-SPN that connects to the closest service-connection
corporate-access node.

Palo Alto Networks 95

 Design Model

Figure 44 Multiple-AS WAN routing

In a network with an interconnected backbone running eBGP between data centers, as shown in Figure 44, the mobile-user
traffic originating in the US-West location MU-SPN, connecting to a service in the US-East data-center IP address range
10.6.0.0/16, would prefer a path via the US-East service connection based on the shortest AS-Path list, AS-65502. Return
traffic would flow symmetrically across the US-East service connection, then across the Prisma Access backbone to the US-
West corporate-access node, and then to the US-West MU-SPN with the mobile-user connection. To maintain symmetric
routing when service connections fail in this mobile-user-only scenario, this network design enables the hot-potato routing
mode in Prisma Access.

To prevent asymmetric flows from being dropped at the corporate-access nodes, the default
Prisma Access routing setting for traffic flows on service connections requires symmetric
routing. You can configure your Prisma Access instance to allow asymmetric flows; however,
it is recommended that you use BGP metrics, like those set by hot-potato routing mode, to
provide a predictable traffic flow between Prisma Access and your organization. Doing so
prevents overloading a network link and provides a consistent user experience.

Prisma Access Routing for the Multiple-AS Option

When you enable the hot-potato routing mode in your Prisma Access network, mobile-user traffic bound for your
organization's network egresses the Prisma Access network as quickly as possible via the closest service connection. To
ensure that traffic from a directly connected mobile-user gateway egresses to the closest service connection, the Prisma
Access corporate-access node marks incoming routes originating from the service-connection–connected data center with

Palo Alto Networks 96

 Design Model

BGP local preference and weight. The Prisma Access corporate-access node uses AS prepends on the AS-Path list when
advertising directly connected mobile-user IP address prefixes to the service-connection–connected data center to drive
predictable and symmetric routing.

When the hot-potato routing mode is enabled, Prisma Access prepends the BGP AS-Path when advertising mobile-user
subnets as follows:

• The corporate-access node and service connection directly connected to a mobile-user gateway advertises the
associated mobile-user subnet(s) without any prepend to the AS-Path.

• If there is a backup service-connection assigned, the associated corporate-access node prepends the AS-Path three
times when advertising the mobile-user gateway subnets that are connected to the service connection it is assigned
to back up.

• All other corporate-access nodes assigned to service connections in the network prepend the AS-Path for the mobile-
user gateway IP subnets six times.

Figure 45 shows the BGP path attributes set by the hot-potato routing mode for the traffic path for the traffic flow from the
primary egress service-connection, as well as the return path. The BGP attributes for local preference and weight on the
data-center subnets advertise inbound drive traffic to egress at the nearest service-connection. The shorter AS-Path in the
routing table drives the desired return traffic. It is recommended that you not summarize the mobile-user subnets advertised
from Prisma Access, because doing so can lead to asymmetric routing.

Figure 45 Hot-potato routing path symmetry

Palo Alto Networks 97

 Design Model

When your Prisma Access network is running in hot-potato routing mode, you can assign a backup service-connection, as
shown in Figure 46. Hot-potato routing mode and backup service-connections work in networks where the organization
summarizes the entire IP address range advertised to Prisma Access (example: 10.0.0.0/13), as well as when each data
center in the organization advertises its own IP address range (example: 10.5.0.0/16).

Figure 46 Hot-potato routing failover to backup service-connection

On-Premises Routing for the Multiple-AS Option

You configure your on-premises network devices to connect to Prisma Access by using BGP routing. Prisma Access assigns
the BGP peer router ID (RID) for a service connection as the Prisma Access cloud automation deploys it for the chosen
location.

You define an eBGP peer between the on-premises device and Prisma Access corporate-access nodes. BGP routing has an
eBGP peer between data center on-premises devices to reflect the multiple-AS design for the organization. Each data center
advertises the assigned IP address range to Prisma Access and to the opposite data center. You should allow the BGP peers
to pass on private AS numbers in route advertisements, because you are using private AS in the data centers and to Prisma
Access.

When you are connecting multiple service connections from your organization to Prisma
Access, it is recommended that you inter-connect your own BGP peers internally so that you
pass routing information regarding all connections to and from Prisma Access.

Palo Alto Networks 98

 Design Model

Prisma Access advertises the mobile-user subnets to your network, with AS prepended, to control the return traffic
symmetry. This process removes the need for you to set BGP attributes on the on-premises device to control routing
between the data centers and the Prisma Access mobile-user subnets.

Multiple-Service-Connections to a Single-AS Option

In smaller organizations, you might have a single BGP AS between your two data centers.

In this option, the following design details apply:

• Prisma Access has two connections from the organization's on-premises headquarters or data center.

• The organization's network has IP transport between the service-connection termination points, providing alternate
paths based on network location and state.

• The organization's network connection to Prisma Access is a single BGP AS.

We refer to the destination of the service connection as on-premises; however, the destination could be a cloud-based data
center in which your organization has resources, as well.

The goal of this option is for a single BGP AS to do the following:

• Route Prisma Access mobile-user connection traffic to a service connection, then to the target application host or
user in the organization, with symmetrical return traffic.

• Converge Prisma Access mobile-user organization traffic over the alternate path in the event of a single service-
connection outage.

• Assign the two data centers in the same geographic region as a backup to each other when routing mobile-user traffic
from Prisma Access.

This option uses BGP to control traffic flow out of and into the Prisma Access network from the organization's network. This
design uses two data centers, one in the West region (Data Center-1) and the second in the East region (Data Center-2). The
two data centers interconnect with network links for intra-organization transport between data centers.

Both data centers are using the same BGP AS and have BGP peer links between them, making them iBGP neighbors.
Prisma Access requires eBGP routing to the organization network.

Palo Alto Networks 99

 Design Model

Figure 47 Single BGP AS peering to Prisma Access

You configure BGP to advertise the IP networks on your end of the service connection and define how to reach them rather
than defining your entire network statically on Prisma Access. After you configure Prisma Access for BGP, it automatically
advertises all infrastructure, MU-SPN address ranges, and Prisma Access-connected remote networks to the on-premises
peer(s).

This mobile-user-only design uses the hot-potato routing mode in Prisma Access to provide efficient traffic routing and reduce
the number of BGP configurations that you need to create to connect Prisma Access mobile users to your network. This
guide covers hot-potato routing mode in depth earlier, in the "Using Prisma Access Hot-Potato Routing-Mode" section.

The design scenario in this guide does not support a customer premises design that has more than two data centers, using
iBGP on the inter-data center links, and having more than two links connecting to Prisma Access.

Prisma Access Routing for the Single AS Option

On Prisma Access, you use Cloud Manager in order to configure the service connection onboarding parameters. To reduce
latency, this design uses two service connections, one per data center, located in the closest Prisma Access location.

On the Prisma Access end, there is no need to statically define a route to the IP address and subnet of the BGP peer of
the on-premises network device. Cloud Manager automatically configures a route to the BGP peer pointing through the
VPN tunnel that connects to the on-premises device. It is a best practice to define the firewall's RID on a loopback interface
allowing the BGP peer to reach it via multiple interfaces versus tied to a single interface.

You define the BGP AS for Prisma Access and hot-potato routing in the initial service setup of your infrastructure. Prisma
Access uses a single BGP AS across all locations, making it a single BGP AS peering to the organization's single BGP AS,
which establishes an eBGP routing relationship between the two autonomous systems. Beyond configuring BGP, the hot-
potato routing mode, and the service connections on Cloud Manager, there are no other configuration variables to define for
traffic to flow to the on-premises network device.

On-Premises Routing for the Single AS Option

You configure your on-premises network devices to connect to Prisma Access using BGP routing. Prisma Access assigns the
BGP peer RID for a service connection as the Prisma Access cloud automation deploys it for the chosen location.

Palo Alto Networks 100

 Design Model

You define an eBGP peer between the on-premises device and Prisma Access corporate-access nodes. To reflect the single
AS for the organization, BGP routing has an iBGP peer between the two on-premises devices. Each data center advertises
the assigned IP address range to Prisma Access and to the opposite data center. When advertising routes received from
Prisma Access between the iBGP peers, each network device sets the next hop to its own address so that the receiving
iBGP peer device knows that the path for the advertised route is via the device passing on the route. You should allow the
BGP peers to pass on private AS numbers in route advertisements, as you are using private AS in the data centers and to
Prisma Access.

When you are connecting multiple service connections from your organization to Prisma
Access, it is recommended that you inter-connect your own BGP peers internally so that you
pass routing information regarding all connections to and from Prisma Access.

Prisma Access advertises the mobile-user subnets to your network, with AS prepended, to control the return traffic
symmetry. This process removes the need for you to set BGP attributes on the on-premises device in order to control routing
between the data centers and the Prisma Access mobile-user subnets.

When the hot-potato routing mode is enabled, Prisma Access prepends the BGP AS path as follows:

• The corporate-access node with the service connection directly connected to the mobile-user gateway is the primary
egress path and advertises the associated mobile-user subnet(s) without any prepend to the AS-Path.

• If you assign a backup service-connection, the associated corporate-access node prepends the AS-Path three times
when advertising the mobile-user gateway subnets that are connected to the service connection it is assigned to back
up.

To prevent asymmetric flows from being dropped at the corporate-access nodes, the default
Prisma Access routing setting for traffic flows on service connections requires symmetric
routing. You can configure your Prisma Access instance to allow asymmetric flows; however,
it is recommended that you use BGP metrics, like those set by hot-potato routing mode, to
provide a predictable traffic flow between Prisma Access and your organization. Doing so
prevents overloading a network link and provides a consistent user experience.

By default, Prisma Access users connect to their closest Prisma Access location for internet access and access to service-
connection–based applications. With hot-potato routing mode, the corporate-access node marks the locally received data-
center subnets with BGP local preference and weight, so the mobile-user traffic headed for a data center egresses the local
service-connection. As shown in Figure 48, if mobile-user traffic from the US-West is destined for the Data Center-2 in the
east, under normal circumstances the traffic egresses to the closest service-connection to west Data Center-1 and transits
the inter-data-center link. Return traffic follows the same path in reverse because the AS path is preferred crossing the inter-
data center link.

Palo Alto Networks 101

 Design Model

Figure 48 Mobile-user traffic return based on AS-Path prepend from Prisma Access

If there is a service-connection link failure between Prisma Access and Data Center-1, as shown in Figure 49, mobile-
user traffic from the US-West destined for Data Center-2 would transit the Prisma Access backbone to egress the service
connection connected to Data Center-2.

Palo Alto Networks 102

 Design Model

Figure 49 Mobile-user traffic routing around failed service-connection

SECURING PRIVATE APPS FOR REMOTE SITES

Prisma SD-WAN allows organizations to extend protection to remote-site user traffic destined for central sites and other
remote sites, as follows:

• Prisma SD-WAN interconnects your central-site and remote-site locations, secures your data traffic across public and
private WAN links, enables application-aware path selection, and provides visibility into application health.

• Prisma Access provides protection with deep visibility, secure access, and threat prevention for DIA traffic from the
remote sites.

• Prisma SD-WAN zone-based firewall provides Layer 7 control of remote-site-to-data-center and remote-site-to-
remote-site traffic.

Prisma SD-WAN ION devices are deployed for remote-site locations. You connect the sites by using Prisma SD-WAN secure
fabric links and centrally manage all devices by using Cloud Manager.

Palo Alto Networks 103

 Design Model

This design describes a network topology with multiple remote sites deployed across two regions. Remote sites have either
dual connections to a public network or single connections to both a public network and a private network. All physical
connections are provided through a standard Ethernet handoff. Secure fabric links interconnect sites with hub-and-spoke,
partial-mesh, or full-mesh topologies, depending on business and scale requirements. The SD-WAN provides per-application
path selection across all possible paths.

The ION devices provide an application-aware, zone-based firewall at each remote site.

Palo Alto Networks recommends this design if you require zero-touch provisioning and deployment for your remote-site
devices and deep visibility into the performance of applications running across the SD-WAN.

Each site connects to the Prisma SD-WAN, which is the primary WAN for the organization and provides access to the
headquarters and data center locations. This design assumes that the central sites are already interconnected through an
existing public or private WAN connection. At all sites, you must use an on-premises ION device to terminate the SD-WAN
tunnels. After the basic device configuration is complete, you transition the site to control mode.

You centrally manage all policy and monitoring of the Prisma SD-WAN by using Cloud Manager.

The SD-WAN protects your internal user traffic by using secure fabric links, which use IPSec tunnels over the public networks
to ensure data privacy through strong encryption. ION devices automatically choose the best WAN path for your applications
based on business policy and real-time analysis of the application performance metrics and WAN links.

Central-Site Devices
You integrate ION devices into the existing networks at central sites.

The devices at each central site connect to the private network, public network, and a private WAN network. For device
management, connect the ION controller port to an existing network that has access to the internet. The device connects
to Cloud Manager and, once online, appears as an unclaimed device. On Cloud Manager, for each central site, you create a
site and configure the site as a data center. You then claim the devices and assign them to the site. For high availability, you
deploy a pair of ION devices at each central site.

Configure an IP address for each interface and assign a circuit label. You can use either statically assigned or DHCP-assigned
IP addresses. Palo Alto Networks recommends you use statically assigned IP addresses for the connections at central sites.
You can place the ION devices behind a NAT device. If you do, you must provide the public IP addresses when you configure
the interfaces.

Configure BGP for each device to exchange routing information with peers on the private network.

Remote-Site Devices
You deploy ION devices into new greenfield networks at remote sites.

The devices at each remote site connect to the private network and either two public networks or a public network and a
private WAN network. For device management, connect the ION internet ports to the public networks. The device connects
to Cloud Manager and, once online, appears as an unclaimed device. On Cloud Manager, for each remote site, you create a
site and configure the site as a branch. You then claim the device and assign it to the site.

Palo Alto Networks 104

 Design Model

Configure an IP address for each interface and assign a circuit label. You can use either statically assigned or DHCP-assigned
IP addresses. Palo Alto Networks recommends you use a statically assigned IP address for the connection to the private
network, use DHCP-assigned IP addresses for the connections to the public networks, and use a statically assigned IP
address for any connection to the private WAN network.

If necessary, configure BGP for each device to exchange routing information with peers on the private network.

Interconnecting the Sites

Cloud Manager automatically configures secure fabric links between your sites after you switch the sites to control mode. At
this time, the portal also pushes security and application policies to all sites. By default, the portal builds a hub-and-spoke
topology that also supports remote-site to remote-site communication by routing through a central site. You can optionally
configure direct connections between remote sites by using secure fabric links.

Configuring SD-WAN Application Policies

Palo Alto Networks recommends that you monitor your network analytics and then use the information you have collected
to develop an SD-WAN application policy for your organization. In a brownfield deployment, you have the option to first
deploy your ION devices in analytics mode, which only monitors traffic. However, in a greenfield deployment, you deploy your
devices in control mode.

You must configure SD-WAN policies to match your applications and explicitly distribute the application traffic across the
public networks and which applications to send to Prisma Access.

Palo Alto Networks 105

 Summary

Summary
Prisma Access is a major part of the Palo Alto Networks SASE offering and combines with other Prisma offerings to create
the most comprehensive and integrated SASE solution in the industry. Prisma Access provides a scalable and secure method
for extending security to your mobile users. Prisma Access provides full inline traffic inspection with the security features
you use on your on-premises NGFW appliances and VM-Series firewalls. You can achieve consistent security, regardless of
location, throughout your entire organization.

Prisma Access is a highly effective means of securing mobile-user access to private applications. This guide details the
technical aspects of Prisma Access for mobile users and Prisma SD-WAN for remote-site access to private applications. This
design combines industry-leading SD-WAN and security capabilities with the cloud-delivered security capabilities of Prisma
Access for mobile users. This combination provides the most comprehensive SASE design in the industry.

Because Prisma Access is a service, Palo Alto Networks manages the deployment and maintenance of the infrastructure,
and all you must do is manage the policies. Using Strata Cloud Manager, you can centrally manage Prisma Access, SLS, and
Prisma SD-WAN.

Palo Alto Networks 106

 Feedback

Feedback
You can use the feedback form to send comments about this guide.

Palo Alto Networks 107

HEADQUARTERS
Palo Alto Networks Phone: +1 (408) 753-4000
3000 Tannery Way Sales: +1 (866) 320-4788
Santa Clara, CA 95054, USA Fax: +1 (408) 753-4001
https://www.paloaltonetworks.com [email protected]

©2024 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at https://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies. Palo Alto Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

You can use the feedback form to send comments about

this guide.

P-2143P-24062024