Documente Academic
Documente Profesional
Documente Cultură
JUNE 2020
Table of Contents
Table of Contents
Preface..................................................................................................................................................................... 1
Related Documentation....................................................................................................................................................................... 3
Introduction...........................................................................................................................................................4
WAN Overview.......................................................................................................................................................................................9
SD-WAN Options................................................................................................................................................................................22
Security Zones.....................................................................................................................................................................................43
AutoVPN Overlay.................................................................................................................................................................................45
SD-WAN Routing................................................................................................................................................................................48
Summary...............................................................................................................................................................62
Preface
GUIDE TYPES
Overview guides provide high-level introductions to technologies or concepts.
Reference architecture 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.
DOCUMENT CONVENTIONS
Cautions warn about possible data loss, hardware damage, or compromise of security.
Blue text indicates a configuration variable for which you need to substitute the correct value for your
environment.
• Command-line commands.
• User-interface elements.
• Navigational paths.
• A value to be entered.
An external dynamic list is a file hosted on an external web server so that the firewall can import objects.
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.
https://www.paloaltonetworks.com/referencearchitectures
This guide:
• Introduces CloudGenix, a Palo Alto Networks company, and describes CloudGenix SD-WAN.
• Describes the technical design aspects of the Palo Alto Networks SD-WAN offerings and explores
several technical design models.
• Describes the technical concepts for PAN-OS® Secure SD-WAN that enable per-application path
selection with path health monitoring.
• Provides a framework for SD-WAN architectural discussions between Palo Alto Networks and your
organization.
• Is required reading prior to using the Palo Alto Networks PAN-OS Secure SD-WAN: Deployment Guide.
The deployment guide provides decision criteria for deployment scenarios, as well as procedures for
deploying PAN-OS Secure SD-WAN.
AUDIENCE
This design guide is for technical readers, including system architects and design engineers, who want
to deploy the Palo Alto Networks SD-WAN. It assumes the reader is familiar with the basic concepts of
applications, networking, routing, security, and high availability, as well as a basic understanding of
network and data center architectures.
To be successful, you must have a working knowledge of networking and policy in PAN-OS.
RELATED DOCUMENTATION
The following documents support this architecture guide:
• Palo Alto Networks PAN-OS Secure SD-WAN: Deployment Guide—Details deployment scenarios and
step-by-step guidance for deploying PAN-OS Secure SD-WAN.
• Prisma Access for Networks: Reference Architecture Guide—Presents a detailed discussion of the
available design considerations and options for Prisma™ Access for remote networks.
• Prisma Access for Networks: Deployment Guide—Details deployment scenarios and guidance for
deploying Prisma Access for remote networks.
Introduction
This reference architecture describes how SD-WAN allows organizations to use their WAN links more
efficiently and gain visibility and control over both remote-site user traffic that is bound for the internet,
as well as the organization’s WAN traffic bound for another remote site, large campus, or data center.
This reference architecture includes best-practice recommendations that simplify and optimize the WAN
design for your organization and concurrently provides secure direct internet access for cloud-based
applications.
Palo Alto Networks provides organizations with two recommended design models for deploying SD-WAN:
In addition to a broad WAN overview, this guide covers the technical aspects of PAN-OS Secure SD-WAN
in-depth and describes the best methods for integrating CloudGenix with Prisma Access. You can use
this guide to determine which option is most effective in meeting the business requirements of your
organization.
PAN-OS version 9.1 introduces a native SD-WAN subscription in order to provide intelligent and dynamic
path selection on top of the industry-leading security that PAN-OS already delivers. Beginning with this
release, your organization can avoid the growing complexity of a multivendor, multifunction approach
by consolidating multiple functions into a single, integrated multifunction security device that includes
SD-WAN. The next-generation firewall provides both visibility into the use of applications on the network
and the ability to control users’ 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 firewall, App-ID identifies applications and provides granular application control. This comprehensive
visibility is also essential for SD-WAN to provide intelligent per-application path selection.
Central Site
INET-1
INET-2
MPLS
Direct Direct
Internet Internet
Access Access
SD-WAN
Remote Sites
The PAN-OS Secure SD-WAN solution is orchestrated by Panorama™, which you use to configure and
monitor the central-site and remote-site devices. You use templates for network and device configuration
and device groups for policy and object configuration including the new PAN-OS version 9.1 SD-WAN
specific features. Panorama includes a SD-WAN plugin, which you use to build the IPSec tunnel-based
overlay network, configure the dynamic routing between the sites, and provide centralized visibility of the
SD-WAN.
In addition to SD-WAN capabilities, Palo Alto Networks next-generation firewalls provide comprehensive
security that enables organizations to:
• Securely enable users, content, and applications, including SaaS applications, by classifying all
traffic irrespective of port.
• Reduce risk of an attack by using a positive enforcement model—allowing all desired applications
and blocking everything else.
• Apply security policies to block known vulnerability exploits, viruses, ransomware, spyware,
botnets, and other unknown malware, such as advanced persistent threats.
• Apply consistent security across your on-premises and cloud environments, as well as branch
locations.
The CloudGenix Autonomous SD-WAN delivered by CloudGenix Instant-On Network (ION) devices allows
you to enforce policies based on business intent, enables dynamic path selection, and provides visibility
into performance and availability for applications and networks.
You connect your sites using AppFabric, a secure application fabric, which you establish amongst all ION
devices. AppFabric creates a VPN over every WAN link. You can define policies that are aligned with your
organization’s business intent. Based on the performance, compliance, and security policies for your
applications, 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 to
determine the appropriate path.
Central Site
INET-1
INET-2
MPLS
CloudGenix
Portal
Direct Direct
Internet Internet
Access Access
SD-WAN
Remote Sites
CloudGenix Portal, fully delivered from the cloud, is the management and monitoring platform for
the CloudGenix SD-WAN. The portal manages the policies for application performance, security, and
compliance. The ION devices are pre-configured to authenticate to the portal and support zero-touch
provisioning and deployment.
Prisma Access for networks provides security services and threat prevention for your remote networks,
safely enabling commonly used applications and web access. You connect remote networks to Prisma
Access via an industry-standard IPSec VPN-capable device. You use Panorama to manage Prisma Access
for consistency and to enable the full suite of PAN-OS features. Prisma Access is ideally suited for any
remote site with one or multiple internet links and provides direct internet access and connectivity to
another enterprise remote site through Prisma Access. Prisma Access provides direct internet access
without the requirement to backhaul traffic to a central site. Functionally, there is no need to compromise
on remote-site security, because Prisma Access provides the exact same security, visibility, and control as
provided by the Palo Alto Networks next-generation firewalls at the central site.
CloudGenix SD-WAN, even prior to the acquisition by Palo Alto Networks, had a strong integration with
Prisma Access. The combination of these two technologies allows you to have a lightweight remote-site
footprint while still being able to provide comprehensive security.
Cortex Data
Lake
Data Center
(Private Cloud)
Prisma Access
Service
Connection
Remote Sites
The remote-site approach typically differs in multiple ways. It is rare to have on-site security operations
staff at a remote site. There may be hundreds or thousands of remote sites, making it difficult to justify
the cost of even a scaled-down “full stack” solution. Most network traffic from a remote site is bound for
the central site or the internet. If security concerns are paramount, organizations can mandate that the
network forwards all internet traffic to the central site for inspection.
To accommodate evolving business requirements, organizations have adopted SaaS applications and
moved internal applications and workloads to the public cloud. It is inefficient to rely on a legacy network
and security architecture that requires you to send all network traffic to a central site for inspection when
users could access many of these same applications more efficiently with direct access through public
networks. However, you might increase the overall risk to your organization by permitting access to
public networks from a multitude of remote sites without providing security capabilities equivalent or
comparable to that of the central site.
Some organizations might make a business decision to accept some additional risk to reduce costs.
Typically, this approach involves deploying a low-cost unified threat management (UTM) system, which
often lacks features and capabilities when compared to the systems deployed at the central site. Another
common approach is to enable stateful firewall features in combination with simple network address
translation (NAT) on an existing WAN router.
To provide the background for the design discussions that follow, this section of the guide provides an
overview of commonly used WAN technologies and their evolution. It also discusses available options
for securing internet traffic from WAN connected remote sites and the associated pros and cons of each
option.
WAN OVERVIEW
This section provides a brief review of WAN technologies and introduces technology and terms that
support the in-depth discussions that follow.
Each WAN technology described has its own pros and cons. Understanding the deficiencies of each and the
methods developed to overcome the deficiencies provides the background information for and key drivers
of the development of SD-WAN.
WAN
MPLS VPN
The networking industry considers MPLS services a private WAN service, in that the service provider
provides segmentation and isolation between customers even though they share a common infrastructure
across the provider’s network. The MPLS service provider’s network uses a high-speed core network
to interconnect provider edge (PE) devices that the service provider uses for customer access. The
service provider can share PE devices across multiple customers; the service provider creates a MPLS
virtual private network (VPN) for each customer, which provides logical separation. The PE devices use
multiprotocol BGP to distribute routing information for each customer in a MPLS VPN.
The central-site and remote-site locations use customer edge (CE) devices to connect to PE devices in
the MPLS network. Whereas multiple customers share PE devices, each CE device is dedicated to a single
customer. You can use either BGP or static routing for the PE-CE connections.
The MPLS network supports a variety of advanced capabilities, such as QoS, traffic engineering, virtual
private LAN service, pseudo wires, and multicast. Customer access to an MPLS network can use traditional
time-division multiplexing services (T1, E1, and DS3), but now more typically uses Ethernet attachment at
data rates ranging as high as multi-gigabit.
MPLS VPN
Customer Edge (CE)
Internet VPN
The internet is a public network with no explicit assurance of data privacy. This restriction alone makes
the internet unsuitable for use as a private WAN transport, besides the fact that it also lacks the advanced
capabilities of MPLS, most importantly QoS. However, when paired with IPSec to create encrypted
VPN tunnels, the internet VPN WAN provides a relatively inexpensive and secure alternative to MPLS.
Customer access to the internet might use traditional methods, but now, more typically, uses Ethernet,
DSL/cable (with Ethernet handoff), or 4G/LTE.
Note
The term internet VPN implies that the network uses encryption to ensure data
privacy and data integrity.
The term MPLS VPN only implies that the MPLS service provider keeps
customer data logically separate from other customers. If the customer desires
encryption, the customer typically implements it on their own on-premises
equipment.
Central Site
Internet
IPSec VPN IPSec VPN
tunnel tunnel
Many organizations have now adopted internet VPN for the WAN to some degree. The combined benefits
of a relatively inexpensive service with data privacy provided through strong encryption are compelling.
Early implementations of internet VPN were not only difficult to manage but also suffered from poor
performance due to a variety of reasons, including the lack of hardware accelerated encryption and poorly
understood technical characteristics. These technical characteristics include:
• Overhead due to tunnel encapsulation—This overhead decreases the maximum transmission unit
(MTU) size on the tunnels and often causes IP fragmentation resulting in packet loss.
• Tunnel instability when using a common routing information base—Keep dynamic routing within
the overlay (tunnel) network separate from the routing used to build the overlay, especially when
using default routes.
Current implementations of internet VPN perform well when you enable advanced features and follow
best practices. When considering internet VPN, you should ensure that your devices are able to minimize
the impact of IP fragmentation. A key option is Adjust TCP MSS, which you enable on your VPN endpoints
in order to ensure that the communication endpoints negotiate the TCP maximum segment size (MSS) to
a value that eliminates the need for fragmentation. The communication endpoints should take advantage
of techniques, such as internet control message protocol (ICMP) path MTU discovery, to identify the
smallest MTU along a path.
Note
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 remote site.
If supported, you should also use multiple virtual router instances on your VPN endpoints. The public-
facing (or “front door”) virtual router provides the routing information that the endpoints use to build
the VPN tunnels between endpoints. The internal virtual router provides the routing information for
traffic passed inside the VPN tunnels. The use of multiple virtual routers separates the routing control
planes and permits you to use multiple default routes, while also preventing instability when the VPN
endpoint learns duplicate routes through VPN tunnels.
In this approach, you assign the public-facing interface of your device to the front door virtual router,
which needs only a static default route. All other interfaces on your device, including the VPN tunnels,
continue to use the default virtual router. You can implement static or dynamic routing on the default
virtual router.
40.91.121.247 (eth1)
(tunne l.1)
VR-Default
An effective approach to improve the overall reliability of the WAN is to incorporate multiple links
and link diversity. You should connect to at least two WAN transports at all of your organization’s
business-critical locations. The chosen transports should not share any common infrastructure, such as
power, physical media (fiber), or equipment, and they should use different service providers. The cost
of improved diversity can be high, so you should compare this cost with the associated business risk of
downtime for your organization’s remote sites.
After you have two or more paths in your network, you must rely on dynamic routing protocols to select
the optimal paths through the network. Dynamic routing protocols use a variety of parameters to calculate
a routing table, including link speed, shortest path, or autonomous system. You might use static routing
for sites with only a single path, but otherwise you should avoid using static routing.
A proper WAN design that uses multiple WAN transports should rapidly detect network failures and
dynamically reroute traffic to alternate paths. You typically configure traditional routed WAN networks by
using the following methods (assuming only two paths):
• Active/standby—Forwards all traffic on a primary path and reroutes traffic to a secondary path
during an outage. The standby path is idle at other times.
• Active/active—Shares traffic on both paths based on session information. If a path fails, traffic
from the failed path is rerouted to the remaining active path. Traffic can always use both paths.
Central Site
Active path
Standby path
There are pros and cons associated with both methods. You may find it difficult to justify the cost of a
WAN transport used only as a standby. Similarly, if you are designing to reduce the impact of an outage,
then each path used with the active/active method needs to have enough bandwidth to accommodate all
traffic and should never exceed 50% utilization when both paths are active.
The design and implementation of WAN diversity is further complicated when mixing and matching
different transports, such as MPLS and VPN WAN over internet, that don’t support the same capabilities,
such as QoS. Applications that require QoS might continue to operate during a failover scenario when the
applications reroute to the internet, but without QoS, they might operate in a degraded mode.
Other factors that affect implementing WAN diversity include the complexity of the configuration. Your
service provider might require BGP when connecting to an MPLS network, and your VPN WAN might use a
different routing protocol, such as OSPF. Effective load-sharing and planning for fault tolerance might not
be possible if all paths don’t have the same bandwidth.
Software-Defined WAN
SD-WAN provides increased flexibility and control of WAN traffic when using 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, simple configuration, active utilization of all links, and rapid convergence while also reducing
cost through the expanded usage of low-cost WAN transports.
Central Site
SD-WAN
Overlay
MPLS Internet
All SD-WAN offerings provide encryption for data privacy with the assumption that one or more
transports use a public network. Some offerings might also include additional native security capabilities,
but these are rarely more than basic firewalls. A common security strategy for a pure-play SD-WAN
vendor is to integrate with a third-party security vendor, such as Palo Alto Networks. If you are using
standalone next-generation firewalls, you can place them inline with the SD-WAN device. Similarly, you
might deploy a VM-Series firewall on the same host system as the SD-WAN virtual machine.
Each site requires an SD-WAN device that connects to the various WAN transports. A centralized
SD-WAN management platform configures and manages the SD-WAN devices. Both on-premises and
cloud-based management platforms are commonly used. The monitoring and reporting capabilities of
the management platform include complete visibility of all connected sites and which transports each
uses for access. In many cases, both the WAN terminating devices and management platforms can be
virtualized. The SD-WAN devices collect performance data by using passive and/or active monitoring and
then use this information to determine the real-time performance characteristics of the SD-WAN paths,
such as delay, loss, and jitter.
The SD-WAN devices use this performance data to identify faults, such as:
• Link failures—The complete failure of an attached link, often detected through a line protocol
change.
• Blackholes—A partial failure often observed when there is complete packet loss in one direction.
• Brownouts—A partial failure often observed with a low-level loss condition (< 10%) in one or
both directions. This fault is highly impactful to voice and video applications and might cause
retransmission for TCP applications.
• Delay—A partial failure often observed when round trip latency increases significantly from the
average. This fault is highly impactful to voice and video applications above a certain threshold and
might lower throughput for file transfers.
• Jitter—A partial failure often observed when round trip latency variance increases significantly
from the average. This fault is highly impactful to voice and video applications above a certain
threshold.
The advanced capabilities of SD-WAN enable an organization to craft routing policies that match
applications with strict performance requirements to the best performing path. The SD-WAN device uses
the policies along with performance data to control the flow of network traffic through the SD-WAN.
Similarly, the SD-WAN device can use the performance data to rapidly reroute traffic around failed or
degraded paths.
SD-WAN devices can typically build VPN tunnels from any WAN interface. Rather than requiring a
front-door virtual router, the device uses interface-specific default routes. These provide the routing
information that the endpoints use to build the VPN tunnels between endpoints.
The SD-WAN overlay network integrates with central-site and remote-site networks using static routing
or standard routing protocols, typically BGP and OSPF. However, the SD-WAN overlay network itself may
use routing protocols or a centralized SD-WAN controller to distribute routing information. Proprietary
methods, such as probes, are used to support application-specific routing and rapid failure detection.
Traditional routing protocols, such as BGP, are typically unable to identify partial failures, such as
blackholes or brownouts, within the WAN because their convergence mechanisms are dependent on the
loss of multiple hello messages. Aggressive tuning of routing protocol timers might improve detection
times for some outage events, but otherwise SD-WAN fault detection is superior to the routing protocol
based approaches used by other WAN architectures in all cases.
You must take additional steps when considering network traffic that leaves your organization. External
connections might include communication to business partners, cloud-delivered services, and general
web access. Encryption alone is not sufficient to secure external communications. To protect your
organization properly, you must have full visibility of the users, applications, and content traversing
corporate networks, the cloud, and endpoints. Only then is it possible to implement security policies
and take actions, such as blocking unknown traffic, identifying advanced attacks, or permitting only
the applications that have a valid business purpose. Along with encryption, you should also use next-
generation firewalls to provide inspection and visibility for traffic entering and leaving the network.
When considering external communications, there are a variety of options for remote sites to access the
internet for general web access, as well as SaaS and other cloud-delivered services.
Central Site
Central-site traffic
Internet traffic
Private
Internet
WAN
Remote Site
Cloud-Based
Central Site Security Stack
Private
Internet
WAN
Central-site traffic
Internet traffic
Remote Site
Primarily due to cost, when you choose to enable direct internet access (DIA), you might decide to
implement a different security solution than at the central site or implement only a limited subset
of functions, which might increase the risk to your organization. However, the Palo Alto Networks
recommendation is to provide consistent visibility by using the comprehensive protection of a
next-generation firewall. An organization is unable to protect against what it cannot see. As previously
mentioned, to protect your organization properly, you must have full visibility of the users, applications,
and content traversing corporate networks, the cloud, and endpoints.
Central Site
Central-site traffic
Internet traffic
Private
WAN
Internet
Remote Site
Each remote-site location provides local secure access to the trusted locations and applications with its
own security infrastructure. This option relies upon the security infrastructure to properly identify and
classify trusted locations and applications and apply any additional user-based policies. This option is
costly both from the network security infrastructure perspective and the management and operational
perspective, especially as the total number of remote sites increases.
This option uses the central site’s bandwidth more efficiently than the centralized internet access option,
because only traffic destined to the central site and untrusted traffic to the internet consumes bandwidth.
Remote-site to central-site latency does not affect the user experience when accessing trusted in-region
resources, regardless of the distance to your central site.
Central Site
Central-site traffic
Internet traffic
Trusted internet traffic
Private
Internet
WAN
Internet
Remote Site
Primarily due to cost, you might decide to implement a different security solution at your remote site
than at the central site or implement only a limited subset of functions such as those provided by a
UTM platform. This decision might seem somewhat more acceptable due to the trusted nature of the
applications you choose to permit; however, this option might still increase the risk to your organization.
A potential threat exists even with trusted applications. Although rare, hackers might have compromised
trusted applications and converted them into malware delivery platforms.
The key principle of a Zero Trust architecture is “never trust, always verify.” The most effective way
to verify is to inspect and log all traffic. As mentioned earlier in this guide, the Palo Alto Networks
recommendation is to provide consistent visibility—an organization is unable to protect against what
it cannot see. We suggest you provide consistent visibility by using the comprehensive protection of a
next-generation firewall.
SASE describes a category of services and products that offer transport and security in a cloud-native
converged and managed solution. The common services include WAN edge/SD-WAN, secure web gateway,
cloud access security broker, Zero Trust network access, DNS security, and firewall as a service.
• 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 cloud.
• 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.
• 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.
The shift to SASE forces existing networking and security models to evolve to integrated, cloud-delivered
services. Prisma Access provides an SASE-enabled service with over 100 locations and the ability to fully
migrate the WAN and security services to a cloud-native architecture.
SD-WAN OPTIONS
As organizations adopt SD-WAN technology to replace traditional WAN, they include remote-site internet
access as a key design consideration. SD-WAN, like other internet VPN solutions, extends the security
perimeter to include the remote sites and is effective for ensuring data privacy for network traffic internal
to the organization. You must take additional steps when considering network traffic that leaves your
organization. External connections might include communication to business partners, cloud-delivered
services, and general web access.
This section compares the design options for SD-WAN with DIA. When considering external
communications, there are a variety of methods for remote sites to access the internet for general web
access, as well as SaaS and other cloud-delivered services. This discussion assumes that one or more WAN
transports for the SD-WAN uses a public network.
Central Site
Central-site traffic
Internet traffic
SD-WAN
Internet
Remote Site
Each remote-site location provides local secure access to the internet by using only the native security
capabilities of the standalone SD-WAN appliance. No additional security resources are located at the
remote site, which reduces cost and simplifies the remote-site management. This option uses the central-
site’s bandwidth efficiently because only traffic destined to the central site across the SD-WAN consumes
bandwidth. Remote-site to central-site latency does not affect the user experience when accessing
regional resources, regardless of the distance to your central site.
The security capabilities of SD-WAN appliances are not typically equivalent to the comprehensive
protection of a next-generation firewall. An SD-WAN appliance may implement only a limited subset of
functions, which might increase the risk to your organization.
The Palo Alto Networks recommendation is to provide consistent visibility by using the comprehensive
protection of a next-generation firewall. An organization is unable to protect against what it cannot see.
To protect your organization properly, you must have full visibility of the users, applications, and content
traversing corporate networks, the cloud, and endpoints. Only then is it possible to implement security
policies and take actions, such as blocking unknown traffic, identifying advanced attacks, or permitting
only the applications that have a valid business purpose.
Central Site
Central-site traffic
Internet traffic
SD-WAN
Internet
Remote Site
The next-generation firewall provides full visibility of the users, applications, and content traversing
corporate networks, the cloud, and endpoints. With this visibility, you can implement security policies
and take actions, such as blocking unknown traffic, identifying advanced attacks, or permitting only the
applications that have a valid business purpose.
You may also use the next-generation firewall to reduce the attack surface at your remote site through
segmentation. To reduce the scope of compliance and to limit data exfiltration, use segmentation to
partition the network into manageable, secure parts.
As in the previous option, this option continues to use the central-site’s bandwidth efficiently because
only traffic destined to the central site across the SD-WAN consumes bandwidth. Remote-site to central-
site latency does not affect the user experience when accessing regional resources, regardless of the
distance to your central site. However, in this option, you have additional security resources located at
the remote site. The requirement to separately manage both an SD-WAN device and a security device
increases cost and complicates the remote-site management.
Central Site
Central-site traffic
Internet traffic
SD-WAN
Internet
Remote Site
The next-generation firewall provides full visibility of the users, applications, and content traversing
corporate networks, the cloud, and endpoints. With this visibility, you can implement security policies
and take actions, such as blocking unknown traffic, identifying advanced attacks, or permitting only the
applications that have a valid business purpose.
You can also use the next-generation firewall to reduce the attack surface at your remote site through
segmentation. To reduce the scope of compliance and to limit data exfiltration, use segmentation to
partition the network into manageable, secure parts.
As in both of the previous options, this option continues to use the central-site’s bandwidth efficiently
because only traffic destined to the central site across the SD-WAN consumes bandwidth. Latency does not
affect the user experience when accessing regional resources, regardless of the distance to your central
site. However, in this option, you have a single device at the remote site providing both security and
SD-WAN functions, which decreases cost and simplifies the remote-site management.
Central Site
Central-site traffic
Internet traffic
Internet
SD-WAN
Prisma Access
Remote Site
Prisma Access for networks provides security services, such as App-ID and threat prevention, for your
remote networks, safely enabling commonly used applications and web access. Prisma Access provides
direct internet access without the requirement to backhaul traffic to a central site. Functionally, there is
no need to compromise on remote-site security because Prisma Access provides the exact same security,
visibility, and control as provided by next-generation firewalls.
You can configure SD-WAN hub or branch functions on your devices after adding the SD-WAN
subscription to any of the next-generation firewalls or VM-Series models listed in Table 1 and Table 2.
These tables indicate a suggested role of branch or hub for each device model, but you may use any device
model in either role as long as the device model meets the performance requirements for the location. For
the latest platform and performance specifications, see the SD-WAN datasheet.
PA-220/
PA-220R PA-820 PA-850 PA-3220 PA-3250 PA-3260
The next-generation firewalls continue to use IPSec to provide a WAN overlay tunneling technology
coupled with strong encryption for data privacy. The firewalls extend the use of application and protocol
decoding within App-ID to rapidly and accurately identify applications running across the WAN. Other
new capabilities specific to SD-WAN include: path-health monitoring for key path metrics such as latency,
jitter and loss, and per-application policies for path selection and traffic distribution. The next section
discusses new features and capabilities in-depth.
• SD-WAN interface profile—Characteristics and parameters that define the SD-WAN behavior for
physical ethernet interfaces
• SD-WAN virtual interfaces—Logical grouping of Ethernet interfaces or IPSec tunnel interfaces used
for SD-WAN
• SD-WAN path quality profiles—Metrics and acceptable performance limits required for various
application classes using the SD-WAN
• SD-WAN traffic policy rules—Rules that match security zones, IP addresses and applications which
are then used to apply the SD-WAN traffic distribution profiles
For path selection ordering, you use the link tag in the traffic distribution profile. Link tags also group
several interfaces for session load-sharing or link bundling. If multiple interfaces are assigned SD-WAN
interface profiles with the same link tag, those links are logically bonded together for traffic distribution.
The Panorama SD-WAN plugin uses the link-type information to determine which device peers are used
for a link’s overlay network. If you designate a device interface as connected to any public link type
(ADSL/DSL, cablemodem, Ethernet, fiber, LTE/4G, or WiFi), then the SD-WAN plugin configures the
device to connect to the overlay network for that link type. If a device has multiple interfaces with the
same link class, each interface has a connection to the overlay network.
The overlay network is composed of IPSec point-to-point tunnels. SD-WAN hub devices at central sites
use passive configuration for IPSec tunnels and do not initiate connections. SD-WAN branch devices at
remote sites use dynamic peer configuration for IPSec tunnels to central sites.
Note
When you select the link type, a default path monitoring method is automatically selected. Path
monitoring is used to evaluate path health based on delay, loss, and jitter metrics, which are calculated
from data collected from traffic probes. The path monitoring assumes that you have a Palo Alto Networks
SD-WAN device terminating the IPSec tunnels at both ends of a connection.
The device, when configured to use aggressive mode, sends probe packets at a constant frequency of 5
probes per second. The device, when configured to use relaxed mode, sends probe packets at a frequency
of 5 probes per second for a duration of 7 seconds and then pauses probing for an idle period of 60 seconds
before restarting the probes. You may override the default path monitoring method. Using aggressive
mode detects degraded paths quickly, but it also consumes more bandwidth for probes. Using relaxed
mode consumes less bandwidth but also takes longer to detect a degraded path. The probe frequency is
configurable for both modes, and the idle period is configurable for relaxed mode.
Note
If you modify the default probe frequencies, you have to adjust your packet
loss thresholds. The packet loss calculation is based on the default probe
frequencies. If you reduce the probe frequency, it may take longer to detect a
loss condition. Because the application lifetimes may be relatively short lived,
you should reduce the packet loss threshold in order to increase the likelihood
of detecting a lost probe.
Example:
Probe frequency set to default 5 probes/sec. Packet loss threshold for
application set to 5%.
If you reduce probe frequency to 2 probes/sec, you should reduce the
packet loss threshold for that application to 2%.
One of the primary benefits of SD-WAN is the ability for your devices to move traffic flows from degraded
paths to better-performing paths. Ideally, when a degraded path has recovered, your device reinstates
flows to that path. To avoid the risk of path flapping, where traffic is continuously moved from path
to another, the SD-WAN device enforces a fallback hold time. The hold timer ensures that a path has
remained healthy for 120 seconds, before the SD-WAN devices reinstates flows to that path. The hold
timer is configurable.
Palo Alto Networks typically recommends that you use a unique SD-WAN interface profile and link tag
for each physical interface. This approach gives you the greatest amount of granularity in crafting your
SD-WAN policies.
However, if you have a set of physical interfaces that are functionally equivalent, you may share a single
link tag across the set of interfaces. This approach allows you to emulate a link bundle and simplifies the
configuration required for basic load-sharing.
Ping probes
(to default-gateway)
• Provides a Layer 3 virtual interface to be used as an IP forwarding table destination interface and
decouples the underlying physical or tunnel interfaces from the Layer 3 IP-forwarding decisions
• Performs intelligent traffic distribution across group member interfaces, depending on the traffic
distribution profile
In most cases, the Panorama SD-WAN plugin automatically creates the SD-WAN VIFs.
Single DIA VIF that includes all SD-WAN– One VPN VIF for each remote site. Each includes all
enabled physical interfaces as group members IPSec tunnels to a particular remote site as group
Central site members
Single DIA VIF that includes all SD-WAN– One VPN VIF for each central site. Each includes all
enabled physical interfaces as group members IPSec tunnels to a particular central site as group
Remote site members
On all SD-WAN devices, the plugin creates a single VIF that includes the physical interface group
members. This VIF is typically used for DIA and is commonly referred to as a DIA VIF. The plugin also
creates a static default route with this VIF as a destination using a route metric of 5. The physical interface
group members must each have a default gateway that is either statically configured or assigned as a
DHCP option.
Note
In some cases, you may also need to manually create a VIF with physical interface group members
before completing the SD-WAN configuration with the Panorama SD-WAN plugin. In these cases, when
configuring a static default route with the manually created VIF as a destination interface, use a route
metric greater than 5 so that this route is less preferred compared to the static default route created by the
plugin.
The DIA VIF performs path monitoring, like other VIFs, but does not have an explicit peer to probe. When
the DIA VIF is created, it sends ping probes to the interface-specific default gateways. At least one of the
default gateways must respond; otherwise the DIA VIF itself is considered down. The SD-WAN devices do
not collect any performance metrics from the ping probes.
Note
Verify that the default gateways for your physical interfaces respond to ICMP
echo requests. If an interface does not respond to an ICMP echo request, the
DIA VIF marks the physical interface as DOWN and does not use it to forward
traffic.
On central-site SD-WAN hub devices, the plugin creates a VPN VIF for each remote site, with the IPSec
tunnels that connect to that remote site as group members for the VIF. On remote-site SD-WAN devices,
the plugin creates a VPN VIFs for each central site, with the IPSec tunnels that connect to the central site
as group members for the VIF. Each IPSec tunnel for a VPN VIF is considered to be a potential path to a
destination site.
The VPN VIFs perform path monitoring by sending path-monitoring probes through the tunnel. Probes
are sent across each active IPSec tunnel to the far-end peer. The SD-WAN devices collect path-monitoring
probe data that is used to calculate path performance metrics used for path selection.
Note
After an IPSec tunnel for a VPN VIF changes to an UP state and path
monitoring is active, the DIA VIF suspends its ping path monitoring. Each
physical interface group member in the VIF inherits the path monitoring state
of the IPSec tunnel sourced from that interface.
If multiple tunnels are sourced from that interface, for the path monitoring
state, the physical interface group member uses the average of all tunnels
sourced from that interface.
The SD-WAN device uses VIFs to simplify IP routing. Without the VIF logical interface, if your device has
multiple paths to a destination, then its virtual router contains multiple entries in the routing table. The
best path in the routing table is installed in the forwarding table, or if equal-cost multipath (ECMP) is
enabled, the virtual router performs load sharing across these paths, and multiple paths are installed in
the forwarding table. You may choose the load-sharing method used by ECMP, but none of the methods
use real-time performance metrics like you could with SD-WAN.
By using a VIF, the virtual router requires only a single entry in the routing and forwarding tables. After
traffic is forwarded to the VIF, it determines which path to follow based on the SD-WAN policy, traffic
distribution profile and real-time conditions of each path. The VIF can add active member interfaces when
their state changes to UP and remove inactive member interfaces when their state changes to DOWN. The
virtual router does not experience any changes to its routing and forwarding tables as these interface
transitions occur.
The DIA VIF simplifies another routing issue related to the treatment of default routes with DHCP
assigned default gateways. If you have two interfaces that are both using DHCP address assignment, and
the DHCP servers are also configured to provide the default gateway using the router option, this results
in two equal cost paths, with each path through a different interface. In this case, SD-WAN seamlessly
solves this issue. If you configure your SD-WAN device so that the default route is not installed in the
routing table, the DIA VIF transparently retains each interface-specific default gateway. You can then
use the DIA VIF as the destination interface for a default route, without needing to specify a next-hop IP
address for the static route.
After the VPN VIFs are created and the tunnels are active, the SD-WAN devices can apply the SD-WAN
policies and select the best paths per-application based on current real-time conditions of the SD-WAN.
The SD-WAN path-monitoring probes are used to calculate the PQP metrics for a path. Each IPSec tunnel
in a VPN VIF measures and calculates its metrics independently.
• Latency—The round-trip delay time for a data packet sent across a SD-WAN tunnel (measured in
ms). By default, the latency is calculated every 200ms by using a sliding window that includes the
last three measurements.
• Jitter—The variance in the delay compared to the average delay for a data packet sent across a
SD-WAN tunnel (measured in ms). By default, the jitter is calculated every 200ms by using a sliding
window that includes the last three measurements.
• Packet loss—The percentage of packets lost compared to total packets sent across a SD-WAN
tunnel. The packet loss is calculated every 200ms using a sliding window that includes the last 100
measurements.
The primary function of the PQP is to determine if a path is qualified (operating normally) or is disqualified
(operating in a degraded mode). The secondary function of the PQP is to determine which path to use
when more than one path is qualified, and these paths are otherwise considered equivalent by the path
selection algorithm.
The threshold for each metric is considered a maximum upper limit for that metric. If your SD-WAN
device measures the value of any PQP metric for a path and the value exceeds the configured threshold,
the path is disqualified. When a link is disqualified, this triggers your SD-WAN device to select an
alternate qualified path.
If a set of paths are all qualified, then the SD-WAN device’s path selection algorithm considers the
sensitivity of the metrics to determine the best available path. You can select from three sensitivity
settings to rank the importance of a metric: low, medium, or high. If you configure a metric to have a
higher sensitivity than the other metrics, then the path selection algorithm considers that metric first. If
all metrics have the same value, then the path selection algorithm first considers packet loss, followed by
latency, and then jitter.
Note
When configuring a TDP, you use link tags instead of SD-WAN interface profile
names.
If you are using unique SD-WAN interface profiles and link tags for each
physical interface, the link tag corresponds to all paths sourced from that
physical interface. You can use the tags to differentiate between the physical
interfaces in your SD-WAN policy.
If you are using a shared SD-WAN link tag that is assigned to multiple physical
interfaces, the link tag corresponds to all paths sourced from any of the
physical interfaces. You cannot differentiate between the physical interfaces in
your SD-WAN policy.
As part of your SD-WAN policy, you use SD-WAN TDPs to assign which traffic distribution method the
path-selection algorithm uses for an application. The path-selection algorithm uses the path metrics,
thresholds, and sensitivities as defined in the PQP referenced in the SD-WAN policy rule. When you
configure your TDP, you can choose from the following traffic distribution methods:
• Best available path—This traffic distribution method requires you to create a list of permitted link
tags. When using this method, the path-selection algorithm uses the PQP exclusively to choose the
best path from the list of permitted paths that match the link tags. Only qualified paths are eligible
for selection. If multiple paths are qualified, the path-selection algorithm uses the sensitivity value
assigned to the metrics to prioritize which metric is used first in the selection process. You typically
choose this method when link cost is not a factor for the application.
If the path conditions change and the best available path is disqualified, the path selection
algorithm moves affected sessions to the best qualified path remaining. When path conditions
change and the best available path is again qualified and the Fallback Hold Time expires, the path
selection algorithm moves affected sessions back to the best available path.
• Top-down priority—This traffic distribution method requires you to create a prioritized list of
permitted link tags. When using this method, the path-selection algorithm chooses a qualified path
that matches the highest priority link tag. You typically use this method when there is a significant
cost differential between paths. You assign a low priority to paths with high-cost link tags so the
more expensive links are used only when paths with low-cost link tags are disqualified.
If the path conditions change and the highest priority path is disqualified, the path selection
algorithm moves affected sessions to the next-highest priority qualified path remaining. When
path conditions change and the highest priority path is again qualified and the Fallback Hold Time
expires, the path selection algorithm moves affected sessions back to the highest priority path.
• Weighted session distribution—This traffic distribution method requires you create a list of
permitted link tags and to assign a percentage weight to each entry in the list. The total percentage
allocated across all link tags must add to 100. When using this method, the path-selection algorithm
performs session distribution across paths for each link tag, the paths do not need to be qualified.
When a link tag reaches its percentage limit, further sessions are distributed only to paths with
link tags that remain under the percentage limit. You typically use this method for non-critical
applications. This traffic distribution method does not rely on path metrics.
Note
The Weighted Session Distribution method does not reroute existing sessions
when a path is disqualified. Existing sessions are only rerouted when their
path state changes to DOWN.
Palo Alto Networks does not recommend using this method for business-
critical applications.
If you configure multiple physical interfaces with the same SD-WAN interface profile and link tag, then
you adjust the behavior of these traffic distribution methods. For each method, if the path-selection
algorithm chooses the shared link tag, it distributes sessions evenly across all paths with the link tag. In
addition to the behavior of the various traffic distribution methods that was previously discussed, the
path-selection algorithm also has implicit behavior for the following special cases:
• Multiple physical interfaces with the same link tag—This is a special case in which multiple
physical interfaces share the same SD-WAN link tag. In this case, if the path-selection algorithm
chooses this link tag, it distributes sessions evenly across all qualified paths with the link tag.
• No qualified paths exist—This is a special case that commonly occurs in the early stage of an
SD-WAN deployment. If you don’t know the current loss, jitter, and latency for your WAN paths
and you configure the PQP thresholds too low, this case may occur. In this case, the path-selection
algorithm chooses the path that has the best metrics.
• No matching SD-WAN policy—This is a special case that commonly occurs in the early stage of an
SD-WAN deployment. If you don’t include SD-WAN policy rules for all applications running across
the WAN this case may occur. In this case, the path-selection algorithm distributes the sessions that
do not match any of the SD-WAN policy rules across all available paths, including high-cost paths.
Note
• All VIFs are down—This is a special case that occurs only rarely, such as during a widespread
network outage. In this case, the device no longer follows SD-WAN policy rules and falls back to
path selection based on traditional IP routing if an active path still exists.
After an application matches an SD-WAN policy rule, the path-selection algorithm evaluates each
path from the TDP against the real-time path conditions and thresholds in the PQP to determine the
appropriate path.
Note
Your SD-WAN configuration is simplified by using a minimum of two sets of templates and device groups.
Use one set for central-site hub devices and a second set for remote-site devices. If you have remote sites
grouped across multiple regions, you may want to separate your remote-site devices across additional
templates and device groups.
After you add your central-site and remote-site devices to Panorama and associate them with the proper
template stacks and device groups, you complete the device configurations using the SD-WAN plugin for
Panorama.
As you add devices to the SD-WAN plugin, you must assign the devices to a site and designate the site
type as either Hub or branch. The site type determines which other sites to configure as IPSec peers. Palo
Alto Networks recommends that you enable dynamic routing with BGP for the site. As part of the BGP
configuration, you must provide the following site-specific information: BGP router-ID, IPv4 loopback
address, and BGP autonomous system number. On central-site hubs, you must also provide a list of IPv4
prefixes for BGP to advertise. On remote-site devices, the list of IPv4 prefixes for BGP is optional.
After you have added the devices, you complete the SD-WAN plugin configuration by creating an SD-WAN
VPN cluster. Each VPN cluster is a logical grouping of central-site and remote-site devices. The SD-WAN
plugin uses VPN clusters as the top level for SD-WAN monitoring and reporting.
Note
You must assign each device to a VPN cluster. If you leave a device unassigned,
the SD-WAN plugin does not generate and push the SD-WAN configuration to
the device.
The SD-WAN plugin simplifies and automates several critical SD-WAN tasks through a process referred to
as AutoVPN. When the SD-WAN plugin runs AutoVPN, the following tasks are completed:
• Create predefined security zones and required interfaces—If the predefined security zones do
not already exist, the plugin automatically creates them. If you have enabled BGP, the plugin also
creates a loopback interface for use as the BGP router-ID.
• Create SD-WAN VIFs and configure IPSec tunnels—The plugin automatically creates the required
VIFs for each SD-WAN device. The plugin also generates the complete configuration for the IPSec
tunnels, which includes the tunnel interfaces, IKE crypto profile, IKE gateways, IPSec crypto profile,
and the IPSec tunnels. The plugin assigns tunnel IP addresses from a customer provided pool.
• Configuration of BGP and static routes—The plugin automatically enables BGP on all of the
selected SD-WAN devices. The BGP configuration includes peer group setup and redistribution of
the central-site and remote-site prefixes. The plugin also creates static routes to BGP peers through
the appropriate VPN VIFs and a default route through the DIA VIF. For sites that do not run BGP, you
may configure static routing.
Note
In addition to the configuration tasks listed previously, the SD-WAN plugin also provides centralized
monitoring and reporting capabilities for SD-WAN. The monitoring dashboard provides application
performance and link performance statistics for your SD-WAN VPN clusters on a per-site basis.
Application performance monitoring includes a list of all observed applications for each site, matching
SD-WAN policy rule and link tags, application health status and total sessions (impacted/total). The App
Performance screen lists applications as Impacted only if the SD-WAN device is unable to identify a path
that meets the defined application thresholds in the PQP.
Link performance monitoring includes a list of paths for each site (IPSec tunnel or physical interface),
link tag and type, link status, and path health (latency/jitter/packet loss).
You can specify the time interval for the dashboard or customize the interval to investigate previous
events. If you need more detail on an application or a link, you can drill down and get more specific
information.
You can use either of the following two deployment mode options for Panorama which, if necessary,
allows for the separation of management and log collection.
• Panorama mode—Panorama controls both policy and log management functions for all of the
managed devices.
• Log Collector mode—One or more Log Collectors collect and manage logs from the managed
devices. This assumes that another deployment of Panorama is operating in Panorama Mode or
Management Only Mode.
Panorama Panorama
(Panorama Mode) (Management Mode)
Panorama
(Log Collector Mode)
Configuration
Logging
The separation of management and log collection enables the Panorama deployment to meet scalability,
organizational, and geographical requirements.
You must have one or more managed log collectors (which may include Panorama itself). On Panorama,
you add each log collector a collector group. As you add new SD-WAN devices to Panorama, you must
assign each device to a collector group.
On your SD-WAN devices, you must send system logs, configuration logs, and traffic logs to Panorama.
Otherwise, the SD-WAN monitoring screens on Panorama will be incomplete. To send the traffic logs, you
must create a log forwarding profile and reference this profile within each of your security policy rules. If
you do not include a log forwarding profile, the traffic matching that security policy rule is not monitored.
Device Management
You manage and monitor all devices in your SD-WAN by using Panorama and the Panorama SD-WAN
plugin. There are two valid methods for device management. The default method is to use the
management interface of your device to communicate with Panorama. This method is suitable for devices
deployed to sites that already have an existing network connection to Panorama. An alternate method is to
use a dataplane interface on your device to communicate with Panorama. This method requires additional
configuration on your device, but it does not require an existing connection to a site and is suitable for
remote-site management across a WAN.
Note
You typically deploy Panorama in a central site so that you can manage the next-generation firewalls
deployed within your organization. If you take this approach, managing your central-site devices is
straightforward because you can use the existing network. After you connect the management interfaces
of your devices to the internal network, no additional configuration is required. By default, you use the
management interface to communicate with Panorama and for control plane functions such as DNS,
NTP, logging, and security service updates. You must create security policy rules on the existing security
infrastructure that control traffic to the internet to permit the control plane applications that use cloud
services.
Configuration
Logging
Internet
Updates
(eth1/1)
dataplane
flows
(MGT) (MGT) (eth1/x)
Central Site
If you are deploying a new device, you can arrange for technical on-site personnel to perform the initial
device configuration. The initial configuration tasks require a direct connection to the SD-WAN device.
After the initial tasks are complete, you can complete the remaining tasks centrally, using Panorama.
It is more complex to manage a device located at a remote site than it is for a device located at a central
site. If you have an existing out-of-band (OOB) network dedicated to device management, then you can
follow the same approach that was previously discussed for central site devices.
Configuration
Logging
Internet
Updates
(MGT)
(eth1/1)
dataplane
flows
(MGT) (eth1/x)
The following methods are available for remote sites without an OOB management network:
In this method, when you add the device to Panorama and apply the centralized configuration,
you overwrite certain several local device parameters with identical, centrally defined values. The
centralized configuration also inserts new policies using Panorama pre-rules, preempting the
local policy rules. This approach allows you to maintain centralized control of the overall device
configuration.
• USB bootstrap configuration—After you have created and validated a working remote-device
configuration, you may use that remote-device configuration as a baseline configuration to simplify
and automate the configuration process. First, you create an init-cfg.txt file that provides the basic
information that your device needs to connect to your network. Then, you must save and export a
configuration snapshot from a working device. Next, you create a bootstrap package that includes
both the init-cfg.txt file and the configuration snapshot.
In order to bootstrap a SD-WAN device, you must first install the bootstrap package onto a USB
flash drive. To prepare the USB flash drive with the bootstrap package, you can use any running
Palo Alto Networks next-generation firewall with a USB port. The on-site personnel can configure
a factory-default SD-WAN device by inserting the USB flash drive and then powering on the device.
The on-site personnel do not need to perform any device configuration. As the device boots up, they
must also connect the device to the network so that the device can initiate contact to Panorama.
You can complete the remaining tasks centrally, using Panorama.
• Centralized staging—After you have created and validated a working remote-device configuration,
central-site personnel perform the SD-WAN device configurations for each remote-site device at a
central staging site. After the staging process is complete, the device is repacked and shipped to the
remote-site.
The on-site personnel do not need to perform any device configuration. They are required only to
power on the device and connect the device to the network so that the device can initiate contact to
Panorama. You can complete the remaining tasks centrally, using Panorama.
SECURITY ZONES
Each SD-WAN device requires a specific a set of security zones. You must create some of these zones
manually, for which you typically use Panorama templates. The Panorama SD-WAN plugin uses several
of the zones, so their names must match exactly. You should create all the zones in advance if you want
to reference them in the security and NAT policies within Panorama device groups. If you don’t create the
zones in advance, the SD-WAN plugin creates any required zones that do not already exist.
Central Site
At a minimum, each central site must include the zones listed in Table 5.
zone-internal Layer3 Required for device loopback interfaces used for SD-WAN. Zone name must match
exactly.
zone-to-branch Layer3 Required for SD-WAN tunnels and VPN VIFs to remote sites. Zone name must match
exactly.
zone-public Layer3 Required for WAN-facing interfaces and DIA VIFs. You may choose the zone name.
zone-private Layer3 Required for LAN-facing interfaces at central sites. You may choose the zone name.
(eth1/1) (eth1/2)
VPN VIF
Zone: zone-to-branch
(to remote sites)
Remote Site
At a minimum, each remote site must include the zones listed in Table 6. If necessary, you may use
additional private zones to provide segmentation at your remote sites.
zone-internal Layer 3 Required for device loopback interface used for SD-WAN. Zone name must match
exactly.
zone-to-hub Layer 3 Required for SD-WAN tunnels and VPN VIFs to central sites. Zone name must match
exactly.
zone-public Layer 3 Required for WAN-facing interfaces and DIA VIFs. You may choose the zone name.
zone-private Layer 3 Required for LAN-facing interfaces at remote sites. You may choose the zone name.
VPN VIF
Zone: zone-to-hub
(to central sites)
(eth1/1) (eth1/2)
AUTOVPN OVERLAY
The Panorama SD-WAN plugin uses the link type information to determine which device peers are used
for a link’s overlay network. If you designate a device interface as connected to any public link type
(ADSL/DSL, cablemodem, Ethernet, fiber, LTE/4G or WiFi), then the SD-WAN plugin configures the device
to connect to the overlay network for that link type. If a device has multiple interfaces with the same link
class, each interface has a connection to the overlay network.
When you run AutoVPN, the SD-WAN plugin creates an overlay network between each set of peers. On
each peer, a VPN VIF terminates the overlay network, which is composed of the set of tunnels to each
peer. The number of tunnels required depends on SD-WAN link types of the tunnel source interfaces. The
SD-WAN plugin uses the link class for the link type listed in Table 3 to determine the tunnel peers.
If you have two WAN links at each site, one public (ADSL/DSL) and one private (MPLS), the SD-WAN
plugin creates one tunnel between the public interfaces and a second tunnel between the private
interfaces. The SD-WAN plugin does not create tunnels between public and private interfaces.
The SD-WAN plugin automatically includes private interfaces, such as MPLS, as DIA VIF group members.
Unless your private network has a path to the internet, you should exclude the private interfaces from
sending DIA traffic and use the private interfaces for tunnel termination. Configure a traffic distribution
profile for DIA that includes only interfaces connected to public networks.
An SD-WAN path is equivalent to a tunnel within a VPN VIF. The SD-WAN devices perform path-
monitoring for each path.
VPN VIF
INET MPLS (to remote site)
(eth1/1) (eth1/2)
source
DIA VIF inte rface
source
DIA VIF inte rface
INET MPLS
(eth1/1) (eth1/2)
VPN VIF
(to central site)
If you have two WAN links at each site, both public (ADSL/DSL and cablemodem), the SD-WAN plugin
creates a full mesh of tunnels between the public interfaces.
VPN VIF
INET-1 INET-2 (to remote site)
(eth1/1) (eth1/2)
source
DIA VIF inte rface
source
DIA VIF inte rface
INET-1 INET-2
(eth1/1) (eth1/2)
VPN VIF
(to central site)
If you have three WAN links at each site, two public (ADSL/DSL and cablemodem), and one private
(MPLS), the SD-WAN plugin creates a full mesh of tunnels between the public interfaces and a single
tunnel between the private interfaces. The SD-WAN plugin does not create tunnels between public and
private interfaces.
VPN VIF
DIA VIF
(to remote site)
INET-1 MPLS
(eth1/1) (eth1/3)
source
INET-2 inte rface
(eth1/2)
INET-2 source
(eth1/2) inte rface
INET-1 MPLS
(eth1/1) (eth1/3)
VPN VIF
DIA VIF
(to central site)
SD-WAN ROUTING
The method you use to route traffic to and from your Layer 3 LAN devices (Ethernet switch or router) at
your sites is independent of the routing method used within the SD-WAN. In order to enable end-to-end
routing across your SD-WAN, you must share routing information from the SD-WAN with your LAN
devices and you must advertise site-specific routes across the SD-WAN.
Note
Palo Alto Networks recommends that you use contiguous IP route blocks
within your organization so that you may summarize the IP routes. This
approach simplifies the routing configuration for your SD-WAN.
Central-Site Routing
At your central sites, you must configure routing on your Layer 3 LAN devices in order to send traffic
destined for remote sites to the LAN interface of your SD-WAN device. You can use either static routing,
OSPF, or BGP on your LAN device. If you use static routing, you must include all remote-site prefixes
or include summary routes that match the remote-site prefixes. If you use BGP or OSPF, you must also
configure the same protocol on your SD-WAN device and create a redistribution profile for the virtual
router (on your SD-WAN device) that includes the remote-site prefixes or summary routes. The SD-WAN
device then advertises prefixes listed in the redistribution profile to your LAN device.
At each central site, you must also configure routing on your SD-WAN device to send traffic destined for
the site to the nearest interface of your Layer 3 LAN device. You can use either static routing, OSPF, or BGP
on your SD-WAN device. If you use static routing, you must include all central-site prefixes or include
summary routes that match the central-site prefixes. If you use BGP or OSPF, you must also configure the
same protocol on your Layer 3 LAN device and advertise the central-site prefixes or summary routes to
your SD-WAN device.
You use BGP between the SD-WAN devices to advertise the site-specific routes across the SD-WAN. As part
of the AutoVPN process with the SD-WAN plugin, you configure a list of IPv4 prefixes for BGP to advertise.
This list of prefixes must include the central-site prefixes or summary routes.
Remote-Site Routing
In many organizations, the remote sites are relatively small and may have only a few networking devices.
A common network topology for a remote site is an SD-WAN device directly connected to a Layer 2 LAN
switch. In this type of topology, the SD-WAN device is responsible for all routing at the remote site.
You use BGP between the SD-WAN devices in order to advertise the site-specific routes across the SD-
WAN. As part of the AutoVPN process with the SD-WAN plugin, you enable BGP at the remote site. The
AutoVPN process automatically configures the SD-WAN device to redistribute the directly connected
routes from its LAN-facing interfaces. You may also configure a list of IPv4 prefixes for BGP to advertise.
Central Site
Local LAN INET-1
10.5.128.0 /22 INET-2
Dest IP Prefix MPLS
10.5.128.0/22
10.6.0.0/16
10.61.0.0/16
BGP Redist
Rule s
remote-remote remote-remote
traffic traffic
(sdwan.902) (sdwan.902)
Remote Sites
Control-Plane Policies
The central-site SD-WAN devices use their management interfaces for remote-management, DNS, NTP,
and security service updates. However, you must create security policy rules to permit BGP to and from
other SD-WAN devices.
You configure the remote-site SD-WAN devices to use their dataplane interfaces for remote-management,
DNS, NTP and security service updates by using service routes. As part of the service route configuration,
you must create a loopback interface for the service routes and then a set of NAT policy rules—one for
each of the WAN dataplane interfaces. Each NAT rule translates the loopback interface’s IP address to a
WAN dataplane interface IP address. Additionally, you must create security policy rules to permit remote-
management, DNS, NTP and security service updates to access the zone-public zone.
You must also create security policy rules to permit BGP to and from central-site SD-WAN devices. You
can use the SD-WAN plugin to automatically generate BGP rules for your SD-WAN device groups, or you
can create the BGP rules manually using your preferred settings.
DIA Policies
The DIA policies are required only on the remote-site SD-WAN devices. This assumes that internet access
at the central sites is not provided through the SD-WAN devices.
As part of the DIA configuration, you create a set of NAT policy rules—one for each of the WAN dataplane
interfaces. Each NAT rule translates traffic from the zone-private zone to a WAN dataplane interface IP
address. Additionally, you must create the required security policy rules to permit applications to access
the zone-public zone.
Zone: zone-public
(eth1/1) (eth1/2)
ethernet1/1
ethernet1/2
Site-Site Policies
Traffic between SD-WAN sites requires only security policy rules and does not require any NAT policy
rules. However, because each session must pass through multiple SD-WAN devices, you must create
complementary security policy rules for each device in the traffic path. All security policy rules use rule
type Universal except where noted:
• Central-site to remote-site traffic—At the central site, create security policy rules to permit
application traffic from the zone-private zone to the zone-to-branch zone. At the remote site,
create security policy rules to permit application traffic from the zone-to-hub zone to the zone-
private zone.
• Remote-site to central-site traffic—At the remote site, create security policy rules to permit
application traffic from the zone-private zone to the zone-to-hub zone. At the central site, create
security policy rules to permit application traffic from the zone-to-branch zone to the zone-private
zone.
• Remote-site to remote-site traffic—At the source remote site, create security policy rules to
permit application traffic from the zone-private zone to the zone-to-hub zone. At the central
site, create security policy rules with Rule Type intrazone, to permit application traffic from the
zone-to-branch zone. These rules implicitly include the destination zone of zone-to-branch. At the
destination remote site, create security policy rules to permit application traffic from the zone-to-
hub zone to the zone-private zone.
For building your SD-WAN and securing your external connections, Palo Alto Networks provides a broad
set of offerings from which you may select:
• Prisma Access
There are many ways to use the concepts discussed in the previous sections to build an SD-WAN and
secure your DIA traffic. This guide includes two specific design models. The primary difference between
the two models is how each model provides comprehensive security for the remote-site traffic.
• PAN-OS Secure SD-WAN—This design model uses the next-generation firewall for both central-
site and remote-site locations. You connect the sites using the natively integrated SD-WAN
capabilities of the next-generation firewall. You use Panorama to centrally manage all devices.
This design model describes a network topology with two central sites and multiple remote sites
in a single region. All sites have dual connections to a public network provided through a standard
Ethernet handoff. The SD-WAN interconnects the sites in a hub-and-spoke topology and provides
per-application path selection across all possible paths. Each remote site is configured for DIA, and
the DIA traffic shares both connections to the public network.
In this model, you can also use the next-generation firewall to provide segmentation in order to
reduce the scope of compliance, to limit data exfiltration, and to reduce the attack surface.
This model consolidates the SD-WAN functions and security functions onto a single device at
remote sites, which reduces complexity and cost. Because a next-generation firewall is deployed
at every site, you can provide visibility and inspection for all users and applications across every
network segment. Although you may choose between hardware appliance and virtual form-factors,
you still self-manage and self-deploy the devices in this model. Palo Alto Networks recommends
this model if pervasive security is a high priority for your organization.
• CloudGenix with Prisma Access—This design model uses the CloudGenix ION devices for both
central-site and remote-site locations. You connect the sites by using CloudGenix SD-WAN secure
application fabric, AppFabric. You centrally manage all devices by using the CloudGenix Portal. You
manage the Prisma Access configuration by using the cloud services plugin for Panorama.
This design model describes a network topology with two central sites and multiple remote sites
in a single region. All sites have dual connections to a public network provided through a standard
Ethernet handoff. You use AppFabric to 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. For DIA traffic, each remote site is connected
to Prisma Access, which is treated as a third-party endpoint. The ION devices use third-party VPN
interfaces to build IPSec tunnels to Prisma Access remote-network connections. The DIA traffic
shares both connections to the public network.
In this model, the ION devices provide an application-aware, zone-based firewall at each remote
site. In addition, Prisma Access complements the ION on-site capabilities and provides additional
visibility and inspection for DIA traffic. The ION devices also support zero-touch provisioning and
deployment.
This model separates the SD-WAN functions from security functions for the remote sites. Cost and
complexity remain low because both functions are managed and delivered from the cloud. For DIA
traffic, Prisma Access provides the exact same security, visibility, and control as next-generation
firewall at the remote site.
Palo Alto Networks recommends this model if you require zero-touch provisioning and deployment
for your remote-site devices and pervasive security for DIA and cloud-based applications is a high
priority for your organization. This model also provides deep visibility into the performance of
applications running across the SD-WAN.
• Interconnection between central sites and remote sites using VPN VIFs and IPSec tunnels
INET-1
INET-2
Direct Direct
Internet Internet
Access Access
SD-WAN
The SD-WAN protects your internal user traffic by using VPN VIFs that provide intelligent path control
with per-application path selection. The IPSec tunnels over the public networks ensure data privacy
through strong encryption. The SD-WAN also provides per-application path selection and load sharing for
public network traffic.
At all locations, the next-generation firewall provides full visibility of the users, applications, and content
for all network traffic. At your remote sites, you can also use the next-generation firewall to reduce the
attack surface through segmentation.
In this model, you use next-generation firewalls as SD-WAN devices at both the central-site and remote-
site locations. You use Panorama to centrally configure, manage, and monitor the SD-WAN. Each device
is first added to Panorama as a managed device and then added to the Panorama SD-WAN plugin as an
SD-WAN device.
This model assumes that other (not shown) security infrastructure devices provide internet access at the
central sites.
Central-Site Devices
This model integrates SD-WAN hub devices into the existing networks at central sites. For device
management, connect the management port to an existing network that has access to Panorama.
At the central sites, you configure each SD-WAN device as a hub. The devices at each site connect to the
private network and two public networks. On the interfaces that connect to the public networks, you must
use public IP addresses with static address assignment and each interface must have a Next Hop Gateway.
Configure BGP on the virtual router for each device to exchange routing information with peers on the
private network.
For each central-site SD-WAN device, include a complete list of central-site prefixes, or summary
prefixes, when adding the device to the SD-WAN plugin. If you want to enable remote-site to remote-site
traffic, choose one of your central sites to be a transit site and include the remote-site summary prefixes
in the prefix list for the transit-site device.
The SD-WAN devices at the central sites each use BGP to advertise their prefix lists to all other sites. On
Panorama, you create security policy rules to permit BGP to and from other SD-WAN devices.
On Panorama, you should create a set of SD-WAN policies to control applications initiated from the
central sites. Each policy should include the zone-private source zone and the zone-to-branch destination
zone. For sessions that are initiated from the central site, to control those sessions with an SD-WAN
policy, you only need to configure an SD-WAN policy at that site.
Note
SD-WAN policies apply only to a single SD-WAN routing hop and are effective
to control site-to-site flows such as “remote-site to central-site” or “central-
site to remote-site”.
To control site-to-site flows such as remote-site to central-site to remote-
site, you must apply SD-WAN policies that match the flow at both the remote-
site and the central-site.
Remote-Site Devices
This model consolidates the SD-WAN functions and security functions onto a single device, which
reduces complexity and cost. Because a next-generation firewall is deployed at every site, you can provide
visibility and inspection for all users and applications across every network segment.
At the remote sites, you configure each SD-WAN device as a branch. The devices at each site connect to the
private network and two public networks. On the interfaces that connect to the public networks, you may
use either public IP addresses or private IP addresses behind a NAT device. You can configure each public
interface with either DHCP address assignment or static address assignment, and each interface must
have a next-hop gateway.
The SD-WAN devices at the remote sites each use BGP to advertise their directly connected LAN networks
and learn routes from the SD-WAN hubs devices at the central sites. If you have additional prefixes to add,
specify them in a prefix list for the site. On Panorama, you create security policy rules to permit BGP to
and from central-site SD-WAN devices.
On Panorama, you create a set of SD-WAN policies to control applications initiated from the remote
sites. Each policy should include the zone-private source zone and the zone-to-hub destination zone. For
sessions that are initiated from the remote site, to control those sessions with an SD-WAN policy, you
only need to configure an SD-WAN policy at that site. For each SD-WAN policy, you must choose a PQP
and a TDP and reference them in an SD-WAN policy rule. Where possible, you should use built-in PQPs to
simplify your configuration. You must include a PQP for the SD-WAN policies that control your DIA traffic,
even though the DIA VIF does not perform end-to-end path monitoring. The DIA VIF inherits the path
monitoring state of the IPSec tunnels sourced from member interfaces.
To support DIA traffic, you must configure each public interface to perform NAT. On Panorama, you
should create a set of NAT policy rules—one for each of the public interfaces. Each NAT rule translates
traffic from the zone-private zone to a public interface IP address. Additionally, you must create the
required security policy rules to permit applications to access the zone-public zone.
If required, create multiple private security zones to provide segmentation at the remote site. This
approach allows you to partition the network into manageable, secure segments which reduces the scope
of compliance and limits data exfiltration. Create the required security policy rules to permit applications
to and from each additional security zone.
VPN VIF
Zone: zone-to-hub
(to central sites)
(eth1/1) (eth1/2)
(eth1/3) (eth1/4)
Zone: zone-private2 Zone: zone-private
(PCI) (non-PCI)
In this model, all of the sites are in a single logical region. You configure the SD-WAN plugin with a
single VPN cluster that maps to the region. A VPN cluster is the highest level organizational structure for
grouping used by the monitoring dashboard. Within the cluster, you can compare site performance and
view site-specific application performance and link-performance statistics.
After you complete the AutoVPN process and push the plugin-generated configuration, the SD-WAN
remote-site devices initiate IPSec connections to the central sites and begin to apply the SD-WAN policies
pushed from Panorama.
You must configure SD-WAN policies to match your applications and explicitly distribute the application
traffic across the public networks. You build these policies and apply them to the SD-WAN devices at the
source sites. Since you use Panorama templates to configure these policies, you must create separate
policies for each Panorama device group - one set of policies for central-site devices and another set of
policies for remote-site devices.
One key difference from the PAN-OS Secure SD-WAN model is that you use Prisma Access to secure DIA
traffic, and each remote site connects directly to Prisma Access by using third-party VPN connections.
CloudGenix Portal
SD-WAN
AppFabric
Third-party VPN
All aspects of the CloudGenix SD-WAN are managed through the CloudGenix Portal. For Prisma Access,
Panorama, and Cortex™ Data Lake manage all policy and monitoring centrally, and Palo Alto Networks
manages the Prisma Access infrastructure.
The SD-WAN protects your internal user traffic using AppFabric, which uses IPSec tunnels over the public
networks 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.
This model assumes that other (not shown) security infrastructure devices provide internet access at the
central sites.
Central-Site Devices
This model integrates ION devices into the existing networks at central sites.
The devices at each central site connect to the private network and two public networks. For device
management, connect the ION controller port to an existing network that has access to the internet. The
device connects to CloudGenix Portal and, once online, appears as an unclaimed device. On CloudGenix
Portal, for each central site, you create a site and configure the site as a data center. You then claim the
device and assign it to the site.
Configure an IP address for each interface and assign a circuit label. You may 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
This model deploys ION devices into new greenfield networks at remote sites.
The devices at each remote site connect to the private network and two public networks. For device
management, connect the ION internets port to the public networks. The device connects to CloudGenix
Portal and, once online, appears as an unclaimed device. On CloudGenix Portal, 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.
Configure an IP address for each interface and assign a circuit label. You may 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 and DHCP-assigned IP addresses for the connections to the
public networks.
If necessary, configure BGP for each device to exchange routing information with peers on the private
network.
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.
You have two options for managing the integration from CloudGenix SD-WAN to Prisma Access.
In small-scale deployments, typically less than 20 sites, you manually manage the integration to Prisma
Access by using both Panorama and CloudGenix Portal. In large-scale deployments, you automate the
Prisma Access integration through API-based integration by using CloudGenix CloudBlades Platform.
A CloudBlade provides an abstraction layer between CloudGenix Portal and a particular cloud service,
which simplifies integration with the service. The Prisma Access for Networks CloudBlade allows you to
automatically configure the CloudGenix Portal, ION devices, Panorama, and Prisma Access.
On Panorama, for each remote site, you create a Prisma Access remote network connection at the location
nearest your remote site. If you are using an active/active connection, you create an additional Prisma
Access remote network connection at the location next-nearest your remote site.
Note
On CloudGenix Portal, for each remote site, you create and configure a third-party VPN from the interface
to the nearest Prisma Access location. If you are using an active/active connection, you create and
configure an additional third-party VPN from that interface to the next nearest Prisma Access location.
After you create the third-party VPN connections, you then configure the associated SD-WAN policy to
direct internet and cloud-based applications to Prisma Access. You must also configure security policy
rules on Prisma Access for the associated applications.
The Prisma Access CloudBlade automates the third-party VPN components of the manual configuration
option, which makes this option highly-scalable. This option requires that you deploy either an on-
premises Docker container or a public-cloud container to facilitate the communication between the
Prisma Access CloudBlade and Panorama. On CloudGenix Portal, you also need to apply regional Prisma
Access tags to remote-site device interfaces. The CloudBlade orchestrates both the third-party VPN
configuration and the Prisma Access onboarding.
After you create the third-party VPN connections, you then configure the associated SD-WAN policy to
direct internet and cloud-based applications to Prisma Access. You must also configure security policy
rules on Prisma Access for the associated applications.
Summary
Palo Alto Networks provides organizations with several options for deploying SD-WAN. In addition to a
broad WAN overview, this guide covered the technical aspects of PAN-OS Secure SD-WAN in-depth and
described the best methods for integrating CloudGenix with Prisma Access. You can use this guide to
determine which offering is most effective in meeting the business requirements of your organization.
The PAN-OS Secure SD-WAN design model consolidates the SD-WAN functions and security functions
onto a single device at remote sites, which reduces complexity and cost. All sites within your organization
benefit from the comprehensive security features of the next-generations firewall. You can provide
visibility and inspection for all users and applications across every network segment, including traffic
flows to central sites, cloud-based applications, and the internet.
The CloudGenix with Prisma Access design model combines the industry-leading SD-WAN capabilities
of CloudGenix SD-WAN with the cloud-based comprehensive security capabilities of Prisma Access. The
native SD-WAN and security functions of the ION devices are complemented by additional cloud-delivered
security. You can provide visibility and inspection for all users and applications across including traffic
flows to central sites, cloud-based applications and the internet.
With either design model, your organization can achieve consistent security, regardless of location.
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
http://www.paloaltonetworks.com info@paloaltonetworks.com
© 2020 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our
trademarks can be found at http://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.
B-000221P-1-20a