Palo Alto Networks SD-WAN REFERENCE ARCHITECTURE GUIDE
OCTOBER 2020
Table of Contents
Table of Contents Contents Preface ................. .................................. ................................... ................................... .................................. ................................... ................................... .................................. ................................... .......................... ........ 1 Purpose of This Guide .................................. .................................................... ................................... .................................. ................................... ................................... ..................................3 .................3 Audiencee ................ Audienc .......... ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ........... 3 Related Documentation .............................................................................................................................................. ......................................................................................................................................................................4 ........................4
Introduction ............... ................................. ................................... ................................... ................................... .................................. ................................... ................................... ..................................5 .................5 CloudGenix SD-WAN Design Model ............................................................................................................... ................................................................................................................................................. ..................................55 PAN-OS Secure SD-WAN Design Model .............................................................................................. ..........................................................................................................................................6 ............................................6 Palo Alto Networks SD-WAN Strategy ......................................................... ..................................................................................................................... ....................................................................................8 ........................8
WAN and Remote Remo te Site Concepts and Services Serv ices .................... .......... ................... .................. .................. .................. .................. ................... ................... .................. ............. 10 WAN Overview Ov erview ............. ...... .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ......... 11 Internet Access Options for Remote Sites ......................................................................................................................... ..................................................................................................................................... ............ 19 Secure Access Service Edge .................................................................................................................................................. .............................................................................................................................................................. ............ 23 SD-WAN Options ......................................................................................................................................................... ............................................................................................................................................................................... ......................23 23
CloudGenix Design Details......................................... .......................................................... .................................. ................................... ................................... ...................................28 ..................28 Constructs for CloudGenix SD-WAN ...................................................................... .................................................................................................................................. ........................................................................28 ............28 Managing CloudGenix SD-WAN Deployments..................................................... ................................................................................................................. ........................................................................44 ............44
Palo Alto Networks Design Details ........................ ......................................... ................................... ................................... .................................. ................................... ...................... 48 New Constructs for PAN-OS Secure SD-WAN .................................................................................... ............................................................................................................................. ......................................... 49 Managing SD-WAN Deployments with Panorama ............................................................................ ......................................................................................................................59 ..........................................59 Security Zones .......................................................................................................................................... ................................................................................................................................................................................... ......................................... 66 AutoVPN AutoVP N Overlay Overl ay ....... ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. ............. .............. ............. .........67 ...67 SD-WAN Routing ......................................................................................................................................................... ...............................................................................................................................................................................70 ......................70 Securing the Sites ........................................................................................................................................................ .............................................................................................................................................................................. ...................... 71
SD-WAN Design Models ................ ................................. .................................. ................................... ................................... ................................... ................................... .............................74 ............74 Choosing a Design Model .................................................................................................................................................................74 .................................................................................................................................................................74 Design Models .............................................................................................................................................................. ....................................................................................................................................................................................75 ......................75 CloudGenix with Prisma Access Design Model ............................................................................................................................76 ............................................................................................................................76 PAN-OS Secure SD-WAN Design Model ........................................................................................................ ........................................................................................................................................80 ................................80
Summary ................ ................................. .................................. ................................... ................................... ................................... ................................... .................................. ................................... ...................... 84
Palo Alto Networks
Preface
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 specic 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 Notes provide additional information.
Cautions warn about possible possible data loss, hardware hardware damage, or or compromise of security. security.
Blue text indicates a conguration variable for which you need to substitute the correct value for your
environment. In the IP box, enter 10.5.0.4/24 , and then click OK. Bold text denotes: •
Command-line commands. # show device-group branch-offices
User-interface elements.
•
In the Interface Type list, choose Layer 3. Navigational paths.
•
Navigate to Network > Virtual Routers. A value to be entered. ente red.
•
Enter the password admin.
Palo Alto Networks
1
Preface
Italic text denotes denotes the introduction of important terminology.
An external dynamic list is a le hosted on an external web server so that the rewall can import objects.
Highlighted Highlight ed text denotes emphasis. Total valid entries: 755
ABOUT PROCEDURES These guides sometimes describe other companies’ products. Although steps and screen-shots were up-to-date at the time of publication, those companies might have since changed their user interface, processes, or requirements.
GETTING THE LATEST VERSION OF GUIDES We continually continu ally update refere reference nce architecture archi tecture and deployment deplo yment guides. gui des. You can c an access the latest version of of this and all guides at this location: https://www.paloaltonetworks.com/referencearchitectures
WHAT’S NEW IN THIS RELEASE Palo Alto Networks made the following changes since the last version of this guide: Added an in-depth i n-depth design details deta ils section sectio n for CloudGenix Clo udGenix SDS D-WAN. WAN.
•
Removed the requirement to use only public IP addresses for PANPAN-OS OS® Secure SD-WAN central-site
•
devices. •
Introduced the VPN Data Tunnel Support feature and described the associated use cases for this
feature, including direct internet access (DIA) failover to multimulti-protocol protocol label switching (MPLS). •
Introduced the Hub Failover Priority feature and described its usage for transit sites. Removed the
associated limitation limitation to a single transit site. •
Made minor changes to improve readability and technical accuracy.
Palo Alto Networks
2
Purpose of This Guide
Purpose of This Guide This guide describes reference architectures for Palo Alto Networks software-dened software-dened wide-area wide-area network
(SD-WAN). This guide includes design guidance for connecting your remote sites to data centers or central (SD-WAN). sites via SD-WAN, as well as accessing software-as-a-service (SaaS) applications. This guide: Provides an overview of WAN and remoteremote-site site design concepts.
•
Describes the technical design aspects of the Palo Alto Networks SD-WAN oerings and explores
•
several technical design models. •
Describes the technical concepts for CloudGenix SD-WAN SD-WAN that enable policy enforcement based on business intent, enable dynamic path selection, and provide visibility into performance and availability availabili ty for applications and networks.
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 SD-WAN architectural discussions between Palo Alto Networks and your
•
organization. Is required reading prior to using the CloudGenix SD-WAN with Prisma Access: Deployment Guide . The
•
deployment guide provides decision criteria for deployment scenarios, as well as procedures for deploying CloudGenix SD-WAN. •
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. 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. PAN-OS.
Palo Alto Networks
3
Purpose of This Guide
RELATED DOCUMENTATION The following documents support this architecture guide: CloudGenix SD-WAN SD-WAN with Prisma Access: Deployment Guide —Details deployment scenarios and
•
step-by-step guidance for deploying CloudGenix SD-WAN. •
Palo Alto Networks PAN-OS Secure SD-WAN: SD-WAN: Deployment Guide—Details deployment scenarios and
step-by-step guidance for deploying PAN-OS Secure SD-WAN.
•
Prisma Access Access for Networks: Networks: Reference Reference Architecture Architecture Guide—Presents a detailed discussion of the
available design considerations considerations and options for Prisma™ Access for remote networks. •
Prisma Access Access for Networks: Deployment Guide—Details deployment scenarios and guidance for
deploying Prisma Access for remote networks.
Palo Alto Networks
4
Introduction
Introduction This reference architecture describes how SD-WAN SD-WAN allows organizations to use their WAN links more eciently and gain visibility and control over both remote-site user trac that is bound for the internet, as well as the organization organization’s ’s WAN trac bound for another remote site, large campus, or data center.
This reference architecture includes bestbest-practice practice recommendations that simplify and optimize the WAN design for your organization and concurrently provides secure direct internet access for cloud-based cloud-based applications. Palo Alto Networks provides organizations with two recommended design models for deploying SD-WAN: SD-WAN: CloudGenix SD-WAN with Prisma Access
•
PAN-OS Secure SD-WAN
•
In addition to a broad WAN overview, this guide covers the in-depth technical aspects of both CloudGenix SD-WAN and PAN-OS Secure SD-WAN, and it describes the best methods for integrating CloudGenix with Prisma Access. You can use this guide to determine which option is most eective in meeting the business
requirements of your organization.
CLOUDGENIX SDWAN DESIGN MODEL Palo Alto Networks acquired CloudGenix in April 2020. Its cloudcloud-delivered delivered branch capability and application-dened applicationdened approach accelerates the Palo Alto Networks vision for the secure access service edge.
The CloudGenix SD-WAN SD-WAN delivered by CloudGenix Instant-On 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.
Palo Alto Networks
5
Introduction
Once deployed at your sites, CloudGenix ION devices automatically establish establish a VPN to the data centers over every internet circuit. Additionally, Additionally, the ION devices establish VPNs over private WAN circuits that share a common service provider. You can then dene application policies for performance, security, and
compliance that are aligned with your organization’s business intent. ION devices automatically choose the best WAN path for your applications. ION devices use the business policy and real-time analysis of the application performance metrics and WAN links in order to determine the appropriate path. Figure 1 CloudGeni CloudGenixx SD-WAN
You perform perf orm all aspects asp ects of congurat conguration, ion, management, manage ment, and monitorin monitoring g of CloudGenix Cloud Genix ION IO N hardware hardwar e and
software devices from the multi-tenant, multi-tenant, CloudGenix cloud management portal, thereby eliminating the
need to individual individually ly congure devices at each location. The ION devices are pre-congured pre-congured to authenticate
to the portal and support zero-touch provisioning provisioning and deployment.
PANOS SECURE SDWAN DESIGN MODEL Palo Alto Networks next-generation rewalls running PAN-OS natively include a rich set of security and
SD-WAN SDWAN features that provide the highest level of security, visibility, and control for 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 consol idating multiple multi ple functions func tions into a single, integrated in tegrated multifuncti multifunction on security securi ty device devic e that includes inc ludes
Palo Alto Networks
6
Introduction
SD-WAN. The next-generation rewall 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™ App-ID™ capability. By inspecting the session and payload information of the trac traversing the rewall, App-ID identies applications and provides granular application control. This comprehensive
visibility is also essential for SD-WAN to provide intelligent per-application path selection. Figure 2 PAN-OS Secure SD-WAN
The PAN-OS Secure SD-WAN solution is orchestrated by Panorama™, which you use to congure and monitor the central-site central-site and remoter emote-site site devices. You use templates for network and device conguration and device groups for policy and object conguration including the new PAN-OS version 9.1 SD-WAN specic features. Panorama includes a SD-WAN plugin, which you use to build the IPSec tunnel-based overlay network, congure the dynamic routing between the sites, and provide centralized visibility of the
SD-WAN.
Palo Alto Networks
7
Introduction
In addition to SDSD-WAN WAN capabilities, Palo Alto Networks next-generation next-generation rewalls provide comprehensive
security that enables organizations to: Securely enable users, content, and applications, including SaaS applications, by classifying all trac irrespective of port.
•
Reduce risk of an attack by using a positive enforcement model—allowi model—allowing ng all desired applications
•
and blocking everything else. Apply security se curity policies p olicies to t o block known k nown vulnerability vulne rability exploits, viruses, ransomwar ransomware, e, spyware, spywa re,
•
botnets, and other unknown malware, ma lware, such suc h as advanced advanc ed persistent per sistent threats. thr eats. Apply consistent c onsistent security s ecurity across your yo ur on-premises and an d cloud environmen e nvironments, ts, as well wel l as branch
•
locations.
PALO ALTO NETWORKS SDWAN STRATEGY Palo Alto Networks SD-WAN strategy allows you to choose which SD-WAN architecture is right for your organization. We will continue to enhance both the existing CloudGenix SD-WAN technology and PAN-OS Secure SD-WAN technology. This two-pronged strategy for SD-WAN provides you the exibility to
implement SD-WAN on-premises or in the cloud, with your choice of platform. 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 v ia an industry-standard industr y-standard IPSec VPN-capable device. devic e. You use Panorama to t o manage Prisma P risma Access Acc ess for consistency and to enable the full suite of PAN-OS 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 require requirement ment to backhaul trac tr ac to a central c entral site. sit e. Functionally, Functio nally, there the re is no need to compromi compromise se
on remote-site remote-site security, because Prisma Access provides the exact same security, visibility, and control as provided by the Palo Alto Networks next-generation next-generation rewalls at the central site.
Palo Alto Networks
8
Introduction
CloudGenix SD-WAN, 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. Figure 3 Prisma Access for networks Cortex Data Lake
Data Center (Private Cloud) Prisma Prism a Access
Service Connection
Remote Network Connection
Remote Sites
Palo Alto Networks
9
Remote Network Connection
Remote Network Connection
WAN and Remote Site Concepts and Services
WAN and Remot Remote e Site Concepts and Services Many organizations use dierent approaches for securing central-site central-site networks as compared to securing
remote-site remotesite networks. The central site includes a highly visible network perimeter for the organization, which justies just ies a signicant signi cant investment inve stment in security infrastr infrastructure ucture to secure this t his perimeter. perim eter. The T he approach appro ach
used for the central site usually includes the network security “full stack,” complemented by the presence pre sence of on-site on-site security operations sta to manage and respond to security threats. The remote-site remote-site approach typically diers in multiple ways. It is rare to have on-site security operations sta at a remote site. There may be hundreds or thousands of remote sites, making it dicult to justify the cost of even a scaled-down scaled-down “full stack” solution. Most network trac 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 trac 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 inecient to rely on a legacy network and security architecture that requires you to send all network trac to a central site for inspection when users could access many of these same applications more eciently 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 lowlow-cost cost unied 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 rewall features in combination with simple network address
translation (NAT) on an existing e xisting 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 trac from WAN connected remote sites and the associated pros and cons of each
option.
Palo Alto Networks
10
WAN and Remote Site Concepts and Services
WAN OVERVIEW This section provides a brief review of WAN technologies and introduces technology and terms that support the in-depth discussions that follow. The purpose of a WAN is to interconnect local-area networks (LANs) at an organization’s central-site locations, such as headquarters and data centers, as well as remote-site locations. WAN transports and technology have evolved, and in the recent years, multi-protocol multi-protocol label switching (MPLS)( MPLS)-based based oerings
and the internet have displaced most other options. Most recently, SD-WAN has further continued this displacement, by enabling the commoditization of both MPLS and the internet. Each WAN technology described has its own pros and cons. Understanding the deciencies of each and the methods developed to overcome the deciencies provides the background information for and key drivers
of the development of SD-WAN. Figure 4 WAN design Central Site
Central Site
WAN
Remote Site
Remote Site
Remote Site
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.
Palo Alto Networks
11
WAN and Remote Site Concepts and Services
The central-site central-site and remote-site 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, trac engineering, virtual
private LAN service, pseudo wires, and multicast. Customer access to an MPLS network can use traditional timetime-division division multiplexing (T1, E1, and DS3), but now more typically uses Ethernet attachment at data rates ranging as high asservices multi-gigabit. Figure 5 MPLS VPN Central Site
Central Site
MPLS Provider Edge (PE)
MPLS VPN
Rem ote Site
Palo Alto Networks
Rem ote Site
12
Customer Edge (CE)
Rem ote Site
WAN and Remote Site Concepts and Services
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, tunnels , the internet inte rnet VPN WAN provides provid es a relatively rel atively inexpensiv in expensivee and secure sec ure alternative alte rnative to t o MPLS. Customer to the internet might use traditional methods, but now, more typically, uses Ethernet, DSL/cableaccess (with Ethernet hando), or 4G/LTE. Note
The term internet VPN implies implies that the network uses encryption to ensure data privacy and data integrity. The term MPLS VPN only 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.
Figure 6 Internet VPN WAN Central Site
Internet IPSec VPN tunnel
IPSec VPN tunnel
Remote Site
Remote Site
Many organizations have now adopted internet VPN for the WAN to some degree. The combined benets
of a relatively inexpensive service with data privacy provided through strong encryption are compelling.
Palo Alto Networks
13
WAN and Remote Site Concepts and Services
Early implementations of internet VPN were not only dicult to manage but also suered 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. Crypto-authentication using pre-shared keys—The large-scale usage of pre-shared keys is dicult
•
to manage, and the key distribution is cumbersome. Sites with dynamic addressing might require wildcard pre-shared keys, keys , which further fur ther magnies mag nies the impact of key rotation. ro tation. •
Crypto-authentication using digital certicates—This method is an industry best-practice, but Crypto-authentication until streamlined workows and tools become available to manage the public key infrastructure, organizations often nd digital certicates dicult to implement, maintain, and support.
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. pra ctices. When Wh en considering conside ring internet inte rnet VPN, VP N, you should ensure that your devices are able to minimize minimiz e the impact of IP fragmentation. A key option is Adjust TCP MSS, which you enable on your VPN endpoints
in order to ensure e nsure 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 explicitly block all ICMP message types, communication endpoints are unable to determine the most eective MTU by using ICMP path MTU
discovery.
If you use digital certicates, industry best-practices best-practices recommend that, when available, you enable automated processes for certicate enrollment and revocation, such as the simple certicate enrollment protocol and the online certicate status protocol. These automated processes streamline and simplify the overall certicate management workow. 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 publicfacing (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 trac 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.
Palo Alto Networks
14
WAN and Remote Site Concepts and Services
In this approach, you assign the public-facing public-facing interface of your y our device to the front door virtual router, which needs nee ds only a static default def ault route. route . All other othe r interfaces interf aces on your y our device, dev ice, including inclu ding the VPN V PN tunnels, continue to use the default virtual router. You can implement static or dynamic routing on the default virtual router. Figure 7 Front-door virtual router
WAN High Availability Although MPLS and the internet in ternet are a re both highly hi ghly reliable reli able in most mos t cases, when w hen a failure fail ure occurs, occu rs, the impact is signicant. WAN outages and disruptions might occur within a service provider’s backbone.
Though these outages are uncommon, they impact multiple customers. More commonly, WAN failures are associated with the local access link for a remote site, in which case the failure impacts only select locations for a few customers. An eective eecti ve approach appr oach to improve imp rove the overall reliability of the WAN is to incorporate inco rporate multiple links
and link diversity. You should connect to at least two WAN transports at all of your y our organization’s business-critical locations. loc ations. The chosen transports tr ansports should not share sh are any common c ommon infrastructu inf rastructure, re, such as power, physical media (ber), or equipment, and they should use dierent 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 y ou have two tw o or more mor e paths in your network, netw ork, you yo u must rely re ly on dynamic dyn amic routing routi ng protocols protoc ols to select se lect 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.
Palo Alto Networks
15
WAN and Remote Site Concepts and Services
A proper prope r WAN design desig n that uses multiple WAN transports transpor ts should rapidly r apidly detect de tect network ne twork failures f ailures and dynamically reroute trac to alternate paths. You typically congure traditional routed WAN networks by
using the following methods (assuming only two paths): Active/s Active/standby tandby —Forwards —Forwards all trac on a primary path and reroutes trac to a secondary path
•
during an outage. The standby path is idle at other times. Active/active Active/a ctive —Shares trac on both paths based on session information. If a path fails, trac from the failed path is rerouted to the remaining active path. Trac can always use both paths.
•
Figure 8 WAN Active/standby with MPLS MPLS VPN and internet internet VPN VPN Central Site Active path Standby path
MPLS VPN
Internet
(active)
(standby)
Remote Site
Remote Site
There are pros and cons associated with both methods. You may nd it dicult to justify the cost of a
WAN transport transpo rt used only o nly as a standby. st andby. Similarly, Sim ilarly, if you are designing to reduce reduc e the impact imp act of an outage, then each path used with the active/active method needs to have enough bandwidth to accommodate all trac 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 dierent 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 aect implementing WAN diversity include the complexity of the conguration. Your
service provider might require BGP when connecting to an MPLS network, and your VPN WAN might use a dierent routing protocol, such as OSPF. Eective load-sharing and planning for fault tolerance might not
be possible possib le if all paths don’t have the same bandwidth. bandw idth.
Palo Alto Networks
16
WAN and Remote Site Concepts and Services
Software-Defined WAN SD-WAN SDWAN provides increased exibility and control of WAN trac when using multiple WAN transports.
In general, SD-WAN SD-WAN solutions enable you to build a WAN overlay network or networking fabric using a variety of WAN transports with dierent bandwidth and performance characteristics characteristics.. SD-WAN typically shares the trac load across all paths in an active/active manner, based on the application. These
solutions have centralized virtually alllargeaspects of device management, including device onboarding and key-management keymanagement workows, making large-scale scale deployment relatively seamless. SD-WAN overcomes the limitations of MPLS VPN and internet VPN by providing ubiquitous data encryption, simple conguration, active utilization of all links, and rapid convergence while also reducing
cost through the expanded usage of low-cost WAN transports. Figure 9 SD-WAN overlay Central Site
SD-WAN Overlay MPLS
Internet
Remote Site
Remote Site
All SD-WAN oerings provide p rovide encrypt e ncryption ion for data d ata privacy privac y with the assumption that one or more transports use a public network. Some oerings might also include additional native security capabilities, but these are rarely rar ely more than basic rewalls. A common security strategy for a pure-play pur e-play SD-WAN
vendor is to integrate with a thirdthird-party party security vendor, such as Palo Alto Networks. If you are using standalone next-generation rewalls, you can place them in line with the SD-WAN device. Similarly, you might deploy a VM-Series rewall on the same host system as the SD-WAN virtual machine.
Each site requires an SD-WAN SD-WAN device that connects to the various WAN transports. A centralized SD-WAN management platform congures and manages the SD-WAN devices. Both on-premises and
cloud-based management platforms are commonly used. The monitoring and reporting capabilities of cloud-based 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 SD-WAN devices collect performance data by using passive and/or active monitoring and then use this information to determine the realreal-time time performance characteristics of the SD-WAN SD-WAN paths, such as delay, loss, and jitter. Palo Alto Networks
17
WAN and Remote Site Concepts and Services
The SD-WAN 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 lowlow-level level loss condition (< 10%) in one or
both directions. dire ctions. This fault is highly hi ghly impactful impac tful to voice vo ice and video v ideo applications app lications and an d might cause caus e retransmission for TCP applications. Delay —A —A partial failure often observed when round trip latency increases signicantly from the
•
average. This fault is highly impactful to voice and video applications above a certain threshold and might lower throughput for le transfers. Jitter —A partial failure often observed when round trip latency variance increases signicantly
•
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 per forming path. The SD-WAN device uses the policies along with performance data to control the ow of network trac through the SD-WAN. SD-WAN. Similarly, the SD-WAN SD-WAN device can use the performance data to rapidly reroute trac around failed or
degraded paths. SD-WAN devices can typically build VPN tunnels from any WAN interface. Rather than requiring a front-door frontdoor virtual router, the device uses interface-specic 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 SDSD-WAN 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-specic application-specic routing and rapid failure detection.
Traditional routing protocols, protocols, such as BGP, are typically unable to identify partial failures, such as blackholess or brownouts, blackhole brow nouts, within withi n the WAN because be cause their the ir convergence conve rgence mechanism mechanismss are dependent dep endent 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 SD-WAN fault detection is superior to the routing protocol based approaches app roaches used u sed by other ot her WAN architectur arc hitectures es in all cases. c ases.
Palo Alto Networks
18
WAN and Remote Site Concepts and Services
INTERNET ACCESS OPTIONS FOR REMOTE SITES Remote sites use the WAN to communicate with headquarters, data centers, and other remoteremote-site site locations. The networking industry typically consider WANs a private network, although only encryption provides true data privacy across a serviceservice-provider provider network. It is straightforward to encrypt data communication over the WAN; most approaches simply encrypt all trac leaving the site without regard
for the applications in use or communication endpoints. endpoints. This approach extends the security perimeter to include the remote sites and is eective for ensuring data privacy for network trac internal to the
organization. You must take tak e additional addition al steps when w hen considering consid ering network ne twork trac tr ac that leaves le aves your you r organization. organiz ation. External Exte rnal
connections might include communication to business partners, cloud-delivered cloud-delivered services, and general web access. acce ss. Encryption Encr yption alone alo ne is not sucient to t o secure external communica communications. tions. To protect p rotect 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 trac, identifying advanced attacks, or permitting only
the applications that have a valid business purpose. Along with encryption, you should also use nextgeneration rewalls to provide inspection and visibility for trac entering and leaving the network.
When considering consid ering external ex ternal communicatio c ommunications, ns, there are a variety var iety of options for f or remote remo te sites to access the internet for general web access, as well as SaaS and other cloud-delivered cloud-delivered services.
Centralized Internet Access All internet inter net trac is backhauled backhaul ed to a central c entral site, sit e, such as headquarte headquarters rs or a data center cente r location, locatio n, across
the private WAN. This location then provides secure access to the internet for the remote sites using the same security infrastructure that secures the central site. This option reduces or eliminates the need for network security infrastructure at the remote sites. You secure each remote r emote site with the network security infrastructure at the central site. This option, however, uses the central site’s network bandwidth ineciently, because you process internet bound trac from remote sites twice: once as it travels across the WAN from the remote site, and then again as the trac travels to the internet. Increased latency
might degrade the user experience at your remote site due to increased latency when accessing regional resources if the central site is far from your remote site.
Palo Alto Networks
19
WAN and Remote Site Concepts and Services
Figure 10 Centralized internet access Central Site
Central-site traffic Internet traffic
Private WAN
Internet
Remote Site
Customer-Provisioned, Cloud-Based Internet Access
With this option, op tion, you transport t ransport all internet inter net trac across the th e private privat e WAN to the t he closest closes t cloud-based
internet access facility. These internet access facilities contain the same stack of security infrastructure that you would use in the central site. Because you can deploy multiple cloud-based cloud-based facilities in a given geographic region, you can reduce the latency of backhauling internet bound trac. These internet-
access facilities are typically based in carrier facilities or carrier neutral facilities and have access to the service provider transport. The customer rents rackrack-space space and power for the security infrastructure equipment. The customer typically owns the security infrastructure equipment and is responsible for the cost of administrating, conguring, maintaining, and monitoring the equipment. Figure 11 Customer Customer-provisione provisioned, d, cloud-based internet access Central Site
Private WAN
Internet
Central-site traffic Internet traffic
Remote Site
Palo Alto Networks
Cloud-Based Security Stack
20
WAN and Remote Site Concepts and Services
Direct Internet Access All internet-based inter net-based application applicatio n trac travels t ravels directly dir ectly to t o the application’s app lication’s destination without traversing tr aversing
the private WAN. Each remote-site remote-site location provides local secure access to the internet with its own security infrastructure. 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 also uses the central-site’s central-site’s bandwidth eciently because only trac destined to the central site consumes bandwidth. Latency does not aect the user experience e xperience when accessing regional resources,
regardless of the distance to your central site. Primarily due to cost, when you choose to enable direct internet access (DIA), you might decide to implement a dierent 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 nextgeneration rewall. 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. Figure 12 Direct internet access Central Site
Central-site traffic Internet traffic
Private WAN
Internet
Remote Site
Trusted Direct Internet Access Only internet-based internet-based application trac, for trusted locations and SaaS applications, travels directly to
the application’s destination without traversing the WAN. Each organization must determine which applications to trust, such as Oce 365, G Suite, or Box. Each remote-site location provides local secure access for the trusted internet trac with its own security infrastructure. This method forwards all other internet trac to a central site, such as headquarters or a data center location, across the private
Palo Alto Networks
21
WAN and Remote Site Concepts and Services
WAN, which then th en provides provi des secure secur e access acce ss to the internet i nternet for the remote sites using the same security infrastructure that secures the central site. This option is a compromise that provides low-latency low-latency access to trusted resources that often have regional points of presence and concurrently reduces the total amount of trac that the network must forward to the central site.
Each remote-site remote-site location provides local secure access to the trusted locations and applications with its own security infrastructure. option relies infrastructure properly identify classify trusted locations andThis applications and upon applythe anysecurity additional user-based to policies. This optionand 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 eciently than the centralized internet access option, because only o nly trac destined to t o the central ce ntral site and untrusted untrus ted trac to the internet in ternet consumes c onsumes bandwidth. b andwidth. Remote-site to central-site latency does not aect the user experience when accessing trusted in-region
resources, regardless of the distance to your central site. Figure 13 Trusted direct internet access Central Site
Central-site traffic Internet traffic Trusted internet traffic
Private WAN
Internet
Internet
Remote Site
Primarily due to cost, you might decide to implement a dierent 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 potenti al threat exists even ev en with trusted tr usted applications. app lications. Although rare, rar e, hackers hacke rs might have h ave compromised comp romised trusted applications and converted them into malware delivery platforms.
Palo Alto Networks
22
WAN and Remote Site Concepts and Services
The key principle of a Zero Trust architecture is “never trust, always verify.” The most eective way to verify is to inspect and log all trac. As mentioned earlier in this guide, the Palo Alto Networks
recommendation is to provide consistent visibility—an 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 rewall.
SECURE ACCESS SERVICE EDGE As the enterprise en terprise evolves, and technology techno logy shifts where application a pplicationss reside and how customers cu stomers and a nd employees access them, networks must also evolve to support these changes. Digital transformation improves agility and your ability to compete; however, it also challenges how you connect to the data as well as how you secure secur e the data, da ta, whether whethe r on-premises or in the cloud. cl oud. A new concept concept,, secure access service edge (SASE), has emerged to describe this convergence of technologies required to secure the networks for organizations. SASE describes a category of services and products that oer transport and security in a cloud-native cloud-native
converged and managed solution. The common services include WAN edge/SDedge/SD-WAN, WAN, secure web gateway, cloud access security broker, Zero Trust network access, DNS security, and rewall as a service.
The elements in an SASE-enabled SASE-enabled network are: Converged WAN edge and network security —Provides —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 —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 pol icy enforcemen enfo rcementt with real-time re al-time conditions like lik e device-type, devic e-type, posture, posture , and location. locat ion. The shift to SASE forces existing networking and security models to evolve to integrated, cloud-delivered cloud-delivered services. Prisma Access provides an SASE-enabled SASE-enabled service with over 100 locations and the ability to fully migrate the WAN and security services to a cloud-native cloud-native architecture.
SDWAN OPTIONS As organizations organiz ations adopt adop t SD-WAN technology to replace traditiona traditionall WAN, they include remote-site r emote-site internet intern et access as a key design consideration. SD-WAN, SD-WAN, like other internet VPN solutions, extends the security perimeter to include the remote sites and is eective for ensuring data privacy for network trac internal to the organization. You must take additional steps when considering network trac that leaves your
organization. External connections might include communication to business partners, cloudcloud-delivered delivered services, and general web access.
Palo Alto Networks
23
WAN and Remote Site Concepts and Services
This section compares the design options for SD-WAN with DIA. When considering external communications, communication s, 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 cloud-delivered services. This discussion assumes that one or more WAN transports for the SD-WAN uses a public network.
SD-WAN Standalone with Direct Internet Access
The remote site connects to the SD-WAN by using an SD-WAN appliance. All central-site application trac travels directly to the application’s destination by using the SDSD-WAN, WAN, which provides intelligent path-selection. All internet-based application trac travels directly to the application’s destination
without traversing tr aversing the t he SD-WAN and is instead forwarde forwarded d directly direct ly to a public p ublic network netw ork through thro ugh the SD-WAN appliance. Figure 14 SD-WAN standalone with DIA Central Site
Central-site traffic Internet traffic
SD-WAN
Internet
Remote Site
Each remote-site 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 simplies the remote-site remote-site management. This option uses the centralsite’s bandwidth eciently because only trac destined to the central site across the SDSD-WAN WAN consumes bandwidth. Remote-site to central-site ce ntral-site latency does not aect the user experienc exp eriencee when accessing ac cessing
regional resources, regardless of the distance to your central site. The security capabilities of SDSD-WAN WAN appliances are not typically equivalent to the comprehensive protection of a nextnext-generation generation rewall. An SD-WAN appliance may implement only a limited subset of
functions, which might increase the risk to your organization.
Palo Alto Networks
24
WAN and Remote Site Concepts and Services
The Palo Alto Networks recommendation is to provide consistent visibility visibility by using the comprehensive protection of a nextnext-generation generation rewall. 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 trac, identifying advanced attacks, or permitting
only the applications that have a valid business purpose.
SD-WAN with Dedicated Security DIA This option is similar to the previous option, SD-WAN Standalone Standalone with Direct Internet Access, but each remote-site remotesite location provides local secure access to the internet by using the comprehensive protection of a next-generation rewall deployed in-line with the SD-WAN appliance. Figure 15 SDSD-WAN WAN with dedicated security Central Site
Central-site Central-si te traffic Internet traffic
SD-WAN
Internet
Remote Site
The next-generation next-generation rewall 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 trac, identifying advanced attacks, or permitting only the
applications that have a valid business purpose. You may also als o use the next-generation rewall r ewall to reduce the attack surface at your remote site through throug h segmentation. To reduce the scope of compliance and to limit data exltration, use segmentation to
partition the network into manageable, secure parts.
Palo Alto Networks
25
WAN and Remote Site Concepts and Services
As in the previous option, this th is option continues c ontinues to t o use the central-site’s bandwidth band width eciently eci ently because be cause only trac destined to the central site across the SD-WAN consumes bandwidth. Remote-site Remote-site to centralsite latency does not aect 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.
Next-Generation Firewall SD-WAN with DIA This option is similar to the previous option, the SD-WAN Standalone with Dedicated Security DIA, but does not require the SD-WAN appliance. In this option, the next-generation rewall provides SD-WAN
capabilities in addition to comprehensive security protection. pr otection. The SD-WAN SD-WAN features on the nextgeneration rewall use existing advanced security capabilities such as App-ID to provide per-application
intelligent path selection. Figure 16 Next-generation rewall with SD-WAN Central Site
Central-site traffic Internet traffic
SD-WAN Internet
Remote Site
The next-generation next-generation rewall 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 trac, identifying advanced attacks, or permitting only the
applications that have a valid business purpose. You can also use the next-generation n ext-generation rewall r ewall to reduce r educe the attack surface sur face at your remote re mote site through segmentation. To reduce the scope of compliance and to limit data exltration, use segmentation to
partition the network into manageable, secure parts.
Palo Alto Networks
26
WAN and Remote Site Concepts and Services
As in both of the previous pr evious options, opt ions, this option o ption continues con tinues to use u se the central-site’s ce ntral-site’s bandwidth bandwid th eciently ecien tly because only o nly trac destined to t o the central ce ntral site across the th e SD-WAN consumes bandwidth. ba ndwidth. Latency Lat ency does doe s not aect 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 simplies the remote-site management.
SD-WAN Standalone with Prisma Access DIA With this option, op tion, you connect c onnect your y our remote rem ote site to Prisma Access by using an IPSec I PSec tunnel tunn el from the standalone SD-WAN appliance. You use this tunnel to transport all internet trac to Prisma Access. All central-site application trac travels directly to the application’s destination by using the SD-WAN,
which provides pro vides intelligent inte lligent path p ath selection. select ion. Figure 17 SD-WAN standalone with Prisma Access DIA 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 trac to a central site. Functionally, there is
no need to compromise on remote-site remote-site security because Prisma Access provides the exact same security, visibility, and control as provided by nextnext-generation generation rewalls.
Palo Alto Networks
27
CloudGenix Design Details
CloudGenix Design Details Successful design and deployment of CloudGenix SD-WAN SD-WAN requires an introduction to the key design elements and constructs. This section of the guide introduces the components of the solution, describes their functions, and highlights the primary linkages between the components.
CONSTRUCTS FOR CLOUDGENIX SDWAN CloudGenix SD-WAN uses the following elements: Portal and controller—Cloud—Cloud-based based controller that you access through an intuitive web portal and
•
that provides SD-WAN control-plane services Sites
•
Data center sites—Central-site locations that contain SD-WAN hub devices
◦
Branch sites—Remote-site locations that contain SD-WAN branch devices
◦
Modes of operation—Analytics mode and control mode
•
Devices—Physical or virtual SD-WAN appliances that are assigned to sites
•
Interfaces—Physical or virtual device interfaces
•
Secure fabric links and service links—Link options for connection to other CloudGenix SD-WAN
•
endpoints and third-party endpoints Trac classes
•
Enterprise trac—Trac to destinations within your organization
◦
Non-enterprise trac—Trac to destinations external to your organization
◦
Endpoints, domains, and groups—Logical constructs that allow exibility when creating network
•
policy rules Network policies—Rule sets for SD-WAN path selection, QoS, and NAT
•
Security policies—Rule sets for security using the CloudGenix zone-based rewall (ZBFW)
•
Circuits—Public or private WAN transports that are used to interconnect the sites
•
CloudBlade framework —API-based —API-based integration of CloudGenix with external systems
•
Palo Alto Networks
28
CloudGenix Design Details
Portal and Controller You manage the CloudGenix CloudG enix SD-WAN and perform per form all congurati conguration on and monitoring moni toring by using the
CloudGenix portal. The controller orchestrates control-plane control-plane functions within the CloudGenix portal. The controller in your SD-WAN maintains maintains the network of public and private WAN paths and propagates routing information. The controller also automatically provisions VPN tunnels across WAN paths. After you have congured the SD-WAN, the controller con troller pushes the congurat congurations ions to devices de vices at each e ach site by using
APIs. The portal provides p rovides a centralized central ized administration admini stration point p oint for policy and an d analytics. analytic s.
The portal and controller are provided as a cloud-based cloud-based service. You do not need to deploy logical or physical infrastructure, and Palo Alto Networks manages all maintenance and upgrades.
Sites The overall SD-WAN architecture uses sites as the primary building blocks. When adding a new site to your SD-WAN, you must mu st assign a site s ite type, type , which then the n denes the behavior behav ior of devices de vices assigned ass igned to the t he site. Data center sites are SD-WAN central sites, or hubs, which are primarily used for aggregating connections
to remote sites. In addition, data center sites function as transit sites between discontiguous networks, which supports supp orts the interconn interconnection ection of sites connected con nected to t o regional-only regiona l-only MPLS providers. provide rs. Branch sites are SD-WAN SDWAN remote sites, which perform the primary monitoring and data collection functions that enable the analytics for the SD-WAN. To manage your SD-WAN, you bind network and security policies to each branch site. sit e. These SD-WAN policies are not bound to t o data center cen ter sites; site s; trac between data center cent er sites
and branch sites uses the branch policies. You must assign assi gn one or more IP prexe prexess to each site, and this prex informatio information n is used as a s the basis
for routing between sites. Rather than using dynamic routing protocols with peering between sites, the controller manages and propagates the routing information.
Modes of Operation You can deploy de ploy CloudGenix Clou dGenix SD-WAN site in one of two tw o operating opera ting modes—analytics modes —analytics mode m ode or control c ontrol mode: mo de: Analytics Analyti cs mode —In this site mode, you install an ION device into a new or existing branch site. You place the ION device between a WAN edge router and a LAN switch. The ION device monitors trac
•
and collects analytics that are reported to the CloudGenix portal. When sites are in analytics mode, the ION devices do not apply policies or make path selection decisions for applications. In this mode, a data center site is not required. Control mode—In this site mode, you install an ION device into a new or existing branch site. You
•
may either replace the WAN edge router with the ION device or place the ION device between a WAN edge router and a LAN switch. s witch. The ION device dev ice monitors monit ors trac and collects collec ts analytics analytic s that are
reported to the CloudGenix portal. When the site is in control mode, the ION device at the branch dynamically builds secure fabric VPN connections to all data center sites across all WAN paths. Sites in control mode forward trac, select the best paths from the available physical and secure
fabric links based on the applied network policies, and enforce security policy for applications. If you do not no t need access ac cess to internal i nternal data d ata center cente r applications, applica tions, then data center cent er sites are not require required. d. Palo Alto Networks
29
CloudGenix Design Details
Devices Each data center or branch site must include a CloudGenix ION hardware device or a CloudGenix virtual ION software device. The ION hardware devices have a unique serial number that is associated to your organization in the CloudGenix portal. ION software devices use tokens generated from the portal instead of a serial number. When you power on an ION device (hardware or software) and connect a controller port to a public network, the device authenticates to the controller and is automatical automatically ly assigned to
your CloudGenix Clou dGenix account ac count by using zero-touch zer o-touch provisioning. You may also use ports por ts that are congured
by default defau lt as internet inter net ports por ts for remote-device r emote-device management, man agement, but when possible, p ossible, Palo P alo Alto Networks Net works recommends that you use the controller port. When a new, new , unclaimed unclaime d device is initially connecte connected d and listed, liste d, it appears app ears in the t he portal with a status statu s of online-restricted. You claim the device and then assign it to a site. For claimed devices that have not been assigned assig ned to a site, you can perform per form only basic administrative admin istrative functions. After assigning a ssigning the device to a site, you can perform a complete device conguration. You perform all aspects of conguration,
management, and monitoring from the CloudGenix portal. Table 1 Specications for CloudGenix ION hardware devices
Typical usage
ION 1000
I ON 2 0 0 0
I O N 30 0 0
ION 7000
I ON 9 0 0 0
Small remote
Small remote
Remote oce
oce or home oce
oce
Data center or large remote oce
Large data center or large campus
Up to 100 Mbps
Up to 150 Mbps
Up to 5 G b p s (data center mode)
Up to 10 Gbps (data center mode)
Up to 1 Gbps (branch mode)
Up to 2.5 Gbps (branch mode)
Up to 500 Mbps
Throughput (recommended range) Controller ports (10/100/1000 Base-TX)
—
1
2
2
2
4
5
12
8
8
—
1 pa ir (p ort s 4/5)
Up to 6 pairs (any ports)
2 pairs (ports 5/6, 7/8)
4 pairs (ports 1/2, 3/4, 5/6, 7/8)
WAN/LA N/intern ern et ports N/int (10/100/1000 Base-TX)
(can be decoupled)
Bypass pairs Vir tu tual al by bypa pass ss pai p airr support
Yes
Yes
No
Yes
Yes
Alt ern ate cont rol roller ler ports (ports configured as internet by default)
Por t s 1-4
Por t s 2-3
Port s 3-6
Por t s 1-8
Por t s 1-8
WAN/LA N/int N/intern ern et ports (10GE SF P+ P+))
—
—
—
6
8
Palo Alto Networks
30
CloudGenix Design Details
Table 2 Specications for CloudGenix ION software devices ION 3102 v
ION 3104v
I ON 3 10 8 v
I ON 7 10 8 v
Throughput (recommended range)
up to 100 Mbps
up to 200 Mbps
up to 350 Mbps
Up to 500 Mbps
Controller ports
1
1
1
1
WAN/LA N/int N/intern ern et port p ort s
up to 9
up to 9
up t o 9
up t o 9
Vir tu tual al by bypa pass ss pai p airr suppo su pport rt
Yes
Yes
Yes
Yes
vCPU vCP U
2
4
8
8
RAM (GB (GB))
8
8
8
32
Disk (GB)
40
40
40
100
Interfaces Physical interfaces on ION hardware devices are automatical automatically ly assigned a link type and usage. Similar assignment is made for virtual interfaces on ION software devices. The port usage options dier between
data center and branch devices.
Controller ports are typically congured with DHCP, which makes them suitable for zerozero-touch touch deployments. You may congure the controller with a static IP address through the CloudGenix portal after deployment, which is a simple conguration option. However, if you want to use a static IP address for initial deployment, you must connect to the device through the console and make the conguration
change by using the ION device toolkit. On a data center device, ports can be used as internet ports or peering ports. Internet ports are connected to public networks, and peering ports are connected to private LAN and private WAN networks. When installing a data center device, you do not need to make signicant topology changes to your current data
center network topology. If your data center device is behind a NAT device, when you congure the internet port, you must provide
the external NAT IP address that maps to the private IP address assigned to the port.
Palo Alto Networks
31
CloudGenix Design Details
Figure 18 CloudGenix data center topology
On a branch device, ports can be used as internet ports, private WAN ports, or LAN ports: Internet ports connect to public networks.
•
Private WAN ports connect to the private WAN either directly as a router replacement or through an
•
existing router. LAN ports connect to the core, distribution distribution,, or accessaccess-layer layer LAN.
•
If your branch device is behind a NAT device and you plan on adding a secure fabric link to directly connect to another branch device, then when you congure the internet port, you must provide the external NAT
IP address that maps to the private IP address assigned to the port.
Palo Alto Networks
32
CloudGenix Design Details
Figure 19 CloudGenix branch topology
The ION devices maintain a separate forwarding information base (FIB) for each interface, which enables devices to support dierent default gateways on multiple interfaces. In most cases, you do not need to congure static routes because the interface-specic interface-specic routing information contained in the FIB is sucient to make proper routing decisions. On both data center and branch devices, all internet ports must be congured with a default gateway. On data center devices, you can simplify the routing conguration by using two separate ports in order to connect to the WAN edge and LAN, and you then congure a default gateway on the port connected to the WAN edge. On branch devices, you can simplify s implify the t he routing conguratio conguration n by setting sett ing a default def ault gateway gatewa y on
private WAN ports. Bypass Pairs
To improve the resiliency of the network, you can use bypass pairs. A bypass pair is is a pair of ports where one port is connected to a LAN network and the second port is connected to a WAN network. Bypass pairs can be congured only for branch ION devices.
Bypass pairs can be of the following types: Hardware Bypass Pair—A pair of ports or ethernet interfaces that can be associated with each other
•
and have underlying support for a hardware bypass relay. Each hardware device has strict pairing rules that allow only certain ports to be paired together. Virtual Bypass Pair Pai r—A pair of ports or ethernet interfaces that can be associated with each other
•
without any hardware capabilitie capabilities. s.
Palo Alto Networks
33
Palo Alto Networks
33
CloudGenix Design Details
If you do not want to use the bypass pair functionality, you can decouple a bypass pair into two individual ports and use the individual ports normally. Controller ports cannot be used within a virtual bypass pair. Depending on your network topology and high availability availability requirements, you can choose from the following bypass pair usages: Internet or private WAN—One interface of the bypass pair is WAN-facing, WAN-facing, and that interface has a
•
static or dynamic IP address. The other interface connects to the LAN. The ION device can actively participate in routing. Private layer 2 (L2)—One interface of the bypass is private WAN-facing, WAN-facing, and the other interface
•
connects to the LAN. The ION I ON device is transparently inserted within the existing network topology and does not participate in routing. No IP addresses are assigned. This type of deployment is considered a legacy deployment model. In most cases, Palo Alto Networks recommends layer 3 deployments, such as an internet WAN, private WAN, or LAN. LAN—Only one interface of the bypass pair is used. This usage is only required when conguring
•
the branch ION device as part of a high-availability cluster. Third-Party VPN
If you need to integrate your CloudGenix SD-WAN SD-WAN with cloud security services, partner networks, or existing legacy networks, you can congure a thirdthird-party party VPN connection by using either IPSec or GRE tunnel encapsulation. encapsulation. The CloudGenix portal includes default IPSec proles for many commonly used third parties and also allows you to congure custom proles. To manually congure a thirdthird-party party VPN connection, you rst create a new thirdthird-party party VPN interface and
associate it with a parent interface, which is used as the tunnel source. You then specify the peer details for IPSec or GRE respectively. You must also complete the corresponding peer conguration on the remote
device. For large-scale third-party VPN integration, Palo Alto Networks provides automation capabilities through the CloudBlade framework and recommends you perform the conguration by using the CloudBlade instance for your specic integration.
Circuits and Networks CloudGenix SD-WAN SD-WAN supports 32 public and 32 private circuit categories, which you can customize to match your organization’s requirements. A variety of default public and private circuit categories are precongured to match commonly used WAN transport options. The circuit category conguration includes settings for the VPN keep-alive timer interval and VPN keep-alive failure count, which you can adjust to ne-tune the link failure detection.
Palo Alto Networks
34
CloudGenix Design Details
Commonly used public circuit categories include: Internet Cable
•
Internet DSL
•
Unmetered 3G/4G/LTE Internet
•
Metered 3G/4G/LTE Internet
•
Ethernet Internet
•
Satellite Internet
•
Commonly used private circuit categories include: MPLS
•
Leased-Line
•
Metro Ethernet
•
Private Fiber
•
Similar to circuit categories, you can manage the public and private networks that interconnect your sites. The network names are used to dierentiate between service providers; however, you can only associate a
single network to each circuit category. If you use two service providers for the same circuit category, Palo Alto Networks Netw orks suggests sugg ests that you y ou rename renam e an unused circuit category c ategory in order to dierentiate diere ntiate between bet ween the
two providers. When you add ad d a site, you specify spec ify which interne internett circuits and which private WAN W AN circuits service the site. For each circuit, you provide the circuit category, network, and a sitesite-specic specic circuit name. You should also congure additional site-specic site-specic circuit details, including the settings for f or bandwidth, link quality
monitoring, QoS, and Bidirectional Forwarding Detection mode. As you add circuits for a site, sit e, the circuits ci rcuits are associated with the ION I ON devices device s deployed deploy ed at the site. On data d ata center devices, a public circuit may only be attached to a single port, but you can attach multiple private WAN circuits circuit s to a port. por t. On branch br anch devices, devic es, a circuit cir cuit may only be attached a ttached to a single port. p ort. The circuits available for an interface depend on the site type and the port usage. For specic usage details, see the
following tables. Table 3 Data center device circuit usage U s e t h i s p or t fo r
Ci r cu it (c ho os e f r om)
C o n n e c t t o i nt e r n e t
Inter net ci rcuit s (one)
Peer w it h a net work
Priv ate WA N circuit s (one or more)
Palo Alto Networks
35
CloudGenix Design Details
Table 4 Branch device circuit usage U s e t h i s p or t fo r
Ci r cu it (c ho os e f r om)
I n t e r ne t
I nt e r n e t c i r c u i t s
Pr ivate WA N
Priv ate WA N circuit s
P r i v a te L 2
Priv ate WA N circuit s
Secure Fabric Links and Service Links The method you use to connect your ION devices to remote endpoints depends on whether the remote endpoint is another ION device in your SDSD-WAN WAN or an external, third-party third-party device. A secure fabric link is an IPSec I PSec VPN overlay tunnel between ION devices that is orchestrated and monitored by the CloudGenix C loudGenix portal and controlle controller. r. While CloudGenix CloudG enix SD-WAN can forward for ward trac tra c between betwe en sites by using physical p hysical interfaces int erfaces connect connected ed to a private WAN network, typically, inter-site trac uses secure fabric links. When you switch a site’s
operating mode from analytics mode to control mode, secure fabric links are enabled on all public and private circuits between a branch and data center. Secure fabric links are never created between data center sites. Table 5 Secure fabric link
Branch public circuit
Branch private circuit
Data Da ta ce cent nter er pu publ blic ic ci circ rcui uitt
Data Da ta ce cent nter er pr priv ivat atee ci circ rcui uitt
Bra ranc nch h pu publ blic ic ci circ rcui uitt
Bran Br anch ch pr priv ivat atee ci circ rcui uitt
All to al l (Automatically enabled)
Non e
Su pp o r t e d (Selectively enabled)
None
None
A l l to a l l w i t h s a m e circuit category
Non e
S up p o r t e d (Selectively enabled)
(Automatically enabled)
As noted previousl previously, y, if your yo ur data center ce nter or branch device de vice is behind a NAT device, you must provide the external NAT IP address that maps to the private IP address assigned to the port. A third-party VPN connectio c onnection n uses a service se rvice link l ink to connect co nnect to a third-party endpoint endp oint by using us ing either an IPSec tunnel or a GRE tunnel. You can congure service links from both data center sites and branch
sites. A service link is automaticall automaticallyy created when you add a third-party third-party VPN interface. To complete the conguration of a service link, you must congure the proper settings on the third-party third-party device
separately.
Palo Alto Networks
36
CloudGenix Design Details
Traffic Classes When you congure c ongure your y our CloudGenix Cloud Genix portal, po rtal, one of your rst tasks is to manage your enterprise ent erprise global prex list. By default, the portal p ortal includes the RFC-1918 RFC-1918 private networks as your enterprise global prex list. If you use other, additional prexes, you must add them to this prex pre x list. If necessary, remove or
modify the private network ranges. Table 6 Default enterprise ent erprise global prex pre x list Pref i x
R a nge
10.0.0.0/8
10.0.0.0–10.255.255.255
172.16.0.0/12
172 .16.0.0–172.31.255.255
192.168.0.0/16
192 .168.0.0–192.168.255.255
Enterprise trafc includes all trac with a destination in the enterprise global prex list, and nonenterprise trafc includes trac to any other destinations. The CloudGenix SD-WAN SD-WAN network policies
dierentiate between enterprise trac and non-enterprise non-enterprise trac.
Endpoints, Domains, and Groups A service endpoint is is a label representing a specic location or network service. CloudGenix endpoints are data center sites. Third-party endpoints are cloud services, such as Prisma Access. The portal automatically adds CloudGenix endpoints when you create data center sites. You must manually create third-party third-party endpoints, and you can optionally include IP address ranges or FQDNs for the endpoint. Additionally, Additionally, you may enable liveliness probes to the third-party third-party endpoints in order to verify that they are active and reachable. When you create a third-party endpoint, you can also choose whether or not to allow enterprise trac to that specic endpoint.
A domain can be any logical grouping of sites, but domains are typically used to separate geographic locations into regions. The default conguration includes a preset domain, which is used for sites not explicitly mapped to congured domains. Domains are tightly coupled with service groups.
A service group is a label representing a set of common service endpoints. A CloudGenix service group contains only data center sites, and you can select which data center sites are included in a specic service
group within a domain. A third-party service group contains only third-party endpoints, and you can select which endpoints are included in a specic group within a domain. The primary benet of using domains and service groups is that you can build broad policies that apply to multiple domains, and these policies are interpreted dierently based on a site’s domain. This method simplies the creation of network policies and reduces the total number of network policies that you must
create.
Palo Alto Networks
37
CloudGenix Design Details
For example, you could separate the United States into two regions and congure two domains: East-US East-US and West-US. You could then congure two service groups: Primary-DC and Secondary-DC. For the
East-US domain, the Primary-DC group includes a data center endpoint located in the eastern US, and the Secondary-DC SecondaryDC group includes a data center endpoint located in the western US. Similarly, for the WestUS domain, the Primary-DC Primary-DC group includes a data center endpoint located in the western US, and the Secondary-DC SecondaryDC group includes a data center endpoint located in the eastern US. At the network policy level, a single common policy for both domains includes a Primary-DC and a Secondary-DC. Separate policy rules are not required. Table 7 Example domain do main and service serv ice group grou p conguration congur ation P res et do ma i n
E a s t US d o m a i n
We st US do ma i n
DC-East DC-West
DC-East
DC-West
Primary-DC service group
DC-West
DC-E ast
Secondary-DC service group
DC-East DC-West
Network Policies Path options are evaluated based on a hierarchy starting with the set of public and private WAN networks that provide service to a site. From this set, the paths are then ltered by policy and network reachability
to determine the active paths. Based on the availability and performance of active paths, best path selection is automatically enabled for each application. A backup path is selected only when an active path cannot be used for a given application session. A layer 3 (L3) failure path is selected only when all active and backup paths are unavailable due to the loss of L3 reachability. Path Types
When crafting craf ting your network path policy, polic y, you can c an choose from the following path type typ e options: Direct Internet—Physical connection to a public circuit
•
Internet VPN—Secure fabric link across a public circuit
•
Private WAN VPN—Secure fabric link across a private circuit
•
Direct Private WAN—Physical connection to a private circuit
•
Third-Party VPN—Service link to a third-party endpoint
•
The path policy rules for Direct Internet and Direct Private WAN can be generalized and apply to all circuits within a circuit category (example: Any Public or Any Private) or can be more specic and apply to specic circuits only.
Palo Alto Networks
38
CloudGenix Design Details
The path policy rules for Internet VPN, Private WAN VPN, and Third-Party Third-Party VPN can be generalized and apply to secure fabric links or service links enabled over all circuits within a circuit category (example: Any Public or Any Private), or these path policy polic y rules can be more mo re specic spec ic and apply ap ply to secure se cure fabric f abric links link s or service links enabled over specic circuits only. Policy Stacks, Policy Sets, and Policy Rules
Network policies include path, QoS and NAT policies. You congure each of these policies by using policy sets, which are evaluated in a priority order referred to as a policy stack. Each policy set includes one or more policy rules. You manage network policies for your organization by using separate policy stacks for
path, QoS, and NAT. Path and QoS Policies
The path and QoS policy stacks include a default policy set and up to 4 additional policy sets. Path policy rules and QoS policy rules can include the following match attributes: Order—The priority of the policy rule (between 1 and 65535). Rules use an explicit match if the
•
order values arethe unique use an implicit if multiple rules have the same order value.match With an implicit match, rule or is evaluated usingmatch the following match attributes; the most specic takes precedence. Network Context—A logical network segment. You typically use a network context to identify trac associated with a specic user community, such as guest users.
•
•
Source Prex—An IP prex list that matches trac source. Source prexes can be dened as either global or local in scope. A global prex has the same values across all sites. A local prex allows you to congure site-specic values.
Applicati Applications ons —The list of applications that match the policy rule. The applications are dened using either L7 or L3/L4 information and include both system and custom applications. System
•
applications are applications that Palo Alto Networks denes, manages, and maintains. These applications are preloaded and continuously updated in your system. Custom applications are
applications that you dene, manage, and maintain, and they are unique to your y our organization. You
assign each application a transfer type—real-time audio, real-time video, transactional, or bulk. Transfer types are used to determine the QoS queue assignment. Destination Prex—An IP prex list that matches trac destination. Destination Destination prexes can be dened as either global or local in scope. A global prex has the same values across all sites. A local prex allows you to congure site-specic values.
•
Palo Alto Networks
39
CloudGenix Design Details
Path policy rules can include the following actions: Paths—Dene the set of allowed paths for an application. These include active paths, backup paths,
•
and L3 failure paths used by a matching rule. Backup paths are only selected when no available active paths exist. L3 failure paths are used as a last resort when no available backup paths exist. Service and Data Center Groups —Dene the set of active and backup CloudGenix or third-party
•
service groups used as a transit destination destination by a matching rule. QoS policy rules can include the following actions: Priority —Assign —Assign a QoS priority category of platinum, gold, silver, or bronze. Within each category,
•
there are four queues that map to the application transfer type. The default values for the total amount of bandwidth allocated and queue sizing per-category are shown in Table 8. 8. •
DSCP—Mark or remark the trac with a specic DSCP value.
Table 8 Default QoS Qo S priority priori ty and queue congurat conguration ion Pl at i n u m
G old
Si l v e r
Bron z e
50% of circuit
25% of circuit
15% 15 % of circuit circ uit
10% of circuit
Bandwidth allocation
bandwidt band widt h
bandwidt band width h
bandwidt band widt h
bandwidt band width h
Real-time audio (queue size as % of a llocation)
20
20
20
20
Real-time video (queue size as % of a llocation)
30
30
30
30
Transactional (queue size as % of a llocation)
30
30
30
30
Bulk (queue size as % of a llocation)
20
20
20
20
NAT Policy
A NAT policy polic y stack includes up to four policy p olicy sets, se ts, which includes i ncludes a default d efault policy po licy set. Before you congure your NAT policy rules, you must create one or more NAT zones and bind them to device interfaces. By default, the internet zone is already created and bound to all interfaces congured as Internet . A default NAT policy set with a single destination zone rule is also created by default. The default
rule performs source NAT to the egress device interface.
Palo Alto Networks
40
CloudGenix Design Details
NAT policy rules can include the following match attributes: Order—The priority of the policy rule
•
Source zone—The zone from which ingress trac is sourced. If you specify a source zone, the rule
•
is created as a source zone rule. Destination zone—The zone to which egress trac is destined. If you specify a destination zone,
•
the rule is created as a destination zone rule. Source prexes—An IP prex list that matches trac source. A source prex can be dened as either global or local in scope. A global prex has the same values across all sites. A local prex allows you to congure site-specic site-specic values.
•
Source port ranges—Optional ranges of ports (up to 16), to further match on trac source
•
Destination prexes—An IP prex list that matches trac destination. A destination prex can be dened as either global or local in scope. A global prex has the same values across all sites. A local prex allows you to congure site-specic values.
•
•
Destination port ranges—Optional ranges of ports (up to 16), to further match on trac
destination
Protocol—Optional to further match specically on TCP, UDP, GRE, ESP, or other specied IP
•
protocol (by number) NAT rules can perform up to 4 actions. Some actions require that you create NAT pools. NAT policy rules can include the following actions: No NAT—Do not perform NAT on trac matching this rule. No other actions are congured.
•
Source NAT—Perform NAT source address translation to an address in the specied NAT pool.
•
•
Destination NAT—Perform NAT destination address translation to an address in the specied NAT
pool. You can optionally translate the destination port. Static Source NAT—Perform NAT source address translation for a range to a corresponding address range in the specied NAT pool.
•
Static Destination NAT—Perform NAT destination address translation translation for a range to a corresponding address range in the specied NAT pool.
•
ALG Disable Disabl e—This action supports a special set of use cases for protocols, such as SIP, that embed
•
port information with the packet payload and do not consistently work properly when NAT is congured. Use this option to disable the SIP application layer gateway.
Palo Alto Networks
41
CloudGenix Design Details
Security Policies Security policies control application access across zones by using the CloudGenix ZBFW. Security policies
are bound to branch sites only. If you want to apply a security policy for trac to or from a data center, you congure cong ure security secu rity policy poli cy rules on your branch devices. de vices. Applicatio ns are the Applications th e core element of the ZBFW, Z BFW, and you yo u use them to control contro l network networ k trac and a nd to implement security policies. You use the same application denitions for security policies that you use for
network policies. Security Zones and Links
Before you congure your security policy rules, you must create security zones and bind them to networks
on each branch device. A typical ZBFW deployment might contain the following zones: PRIVATE—Associated to private LAN networks at branch sites
•
•
PUBLIC—Associated to public network connections, such as internet
WAN—Associated to private WAN network connections
•
VPN—Associated with overlay VPN secure fabric tunnels
•
GUEST—Associated with guest networks
•
Depending on your organization’s security policy, create additional zones for a more granular security policy or use fewer zones for a less granular security policy. The ZBFW zone bindings use an internal link type classication for each network: port—Associated to physical or virtual interface used for LAN attachment
•
subinterface—Associated to a VLAN sub-interface
•
lan—Associated to IP prexes assigned to a site
•
privatewan—Associated to a circuit assigned to a physical or virtual interface used for a private
•
WAN publicwan—Associated to a circuit assigned to a physical or virtual interface used for an internet
•
connection service_link —Associated —Associated to a third-party VPN interface
•
vpn—Associated to the system-maintained set of all overlay tunnels
•
Palo Alto Networks
42
CloudGenix Design Details
Note
Before you create a security policy and bind it to a site, on the devices at the site, make sure to bind security zones to all the networks. The ZBFW drops trac to or from a network without a security zone.
Palo Alto Networks recommends that you perform zone binding at the device level instead of the site level.
Security Rules
Security policy rules can include the following match attributes: Order—The priority of the policy rule
•
Source zone—The zone from which the trac originates
•
Destination zone—The zone to which the trac is destined
•
Source prex lters—An optional IP prex list that matches the trac source. Prex lters can be
•
dened as either global or local in scope. A global prex lter has the same values across all sites. A local prex lter allows you to congure site-specic site-specic values. Destination prex lters—An optional IP prex list that matches the trac destination. Prex lters can be dened as either global or local in scope. A global prex lter has the same values across all sites. A local prex lter allows you to congure site-specic site-specic values.
•
Applicati Applications ons —The list of applications that match the policy rule. The applications are dened using
•
either L7 or L3/L4 information and include both system and custom applications. Security policy rules can include the following actions: Deny —The —The ZBFW silently drops trac that matches this rule, without sending a TCP reset or an
•
ICMP host unreachable message to the client or server. Reject—The ZBFW drops TCP trac that matches this rule and also sends a TCP reset to both the
•
client and server. Allow —The —The ZBFW forwards trac that matches this rule.
•
CloudBlade Framework CloudBlades enable API-based API-based integration of CloudGenix with external systems, such as Prisma Access. A CloudBlade CloudBlad e provides provi des an abstraction abst raction layer lay er between bet ween the CloudGeni CloudGenix x portal and a particular part icular cloud clo ud service, servic e, which simplies simp lies integration integ ration with wit h the service. ser vice. By using a CloudBlade Clo udBlade to congure your CloudGenix Clo udGenix SDS D-
WAN, you can ca n simplify and automate complex integrati integration on tasks and an d combine multi-vendor procedures proc edures into a single workow. The CloudBlade framework replaces the manual step-by-step step-by-step conguration
method with an intuitive tag-based approach.
Palo Alto Networks
43
CloudGenix Design Details
The CloudBlades use secure, authenticated APIs to orchestrate the conguration of both your CloudGenix
devices and the external systems. Using this approach, your organization can simplify the initial integration as well as ongoing maintenance and operations of the overall solution. CloudBlade for Prisma Access
The CloudBlade for Prisma Access orchestrates the integration of branch ION devices to Prisma Access for Networks. This integration requires API access to the CloudGenix portal, Prisma Access, and the Panorama system that is used to manage Prisma Access for Networks. This CloudBlade requires a Docker containercontainer-based based application: cloudgenix_prisma_access_panorama, cloudgenix_prisma_access_panorama, which is available av ailable to download from fr om the CloudGenix Clo udGenix repositor r epository. y. You must install this applicatio application n to either eithe r an on-premise on-premise Docker container or a public cloud container. This application communicates directly with the CloudGenix portal, Prisma Access, and your Panorama system. The CloudBlade does not require any direct communication between these systems. Access to the various systems is authenticat authenticated ed by using API keys generated from the respective system. After you y ou install and an d congure congur e the container con tainer application ap plication and enable the CloudBlade CloudB lade for Prisma Access Acc ess on
the CloudGenix portal, in the portal, you apply tags to the sites selected for integration. The application runs periodically and scans for sites with tags applied. When the application identies a new site, it congures Prisma Access in order to add the new site and then gathers required information from Prisma Access to t o complete comple te the conguration co nguration on the portal. po rtal. By removing a site’s tag, ta g, you can use the CloudBlade C loudBlade to
remove the site from Prisma Access. The primary benets of using the CloudBlade for Prisma Access is that it performs all required tasks to
onboard the sites to Prisma Access and that it creates the third-party endpoints and service links on the CloudGenix portal. Note that you still need to congure path policies in order to direct applications to
Prisma Access. Each Prisma Access location corresponds to a unique third-party third-party endpoint. The CloudBlade for Prisma Access automatically creates several service groups in order to simplify the remaining re maining policy conguration.
MANAGING CLOUDGENIX SDWAN DEPLOYMENTS The CloudGenix portal is the primary method for managing your CloudGenix SD-WAN SD-WAN deployment. Before you add sites sit es and devices de vices and before you congure con gure your network and security secur ity policies, polic ies, you should specify spe cify the global parameters that apply across all sites. These parameters include your enterprise prexes,
domains, and circuit categories. As part of your deployment plan, you should also identify your service providers, the bandwidth to each of the sites, IP addressing information, and zone assignments for both your NAT and a nd security securi ty policies. polici es.
Palo Alto Networks
44
CloudGenix Design Details
Controller Ports There are two valid methods for device management: you can use a data port that is factory-congured factory-congured
for internet usage with DHCP, or you can use the device’s controller port. All device types, except the ION 1000, contain a controller port, and Palo Alto Networks recommends you use this port when possible. At a central cent ral site, connect the controller contr oller port po rt to an internal network. n etwork. By default, def ault, you use us e the controller con troller port to communicate with the CloudGenix portal. In order to permit the CloudGenix control plane applications, you must create c reate security se curity policy p olicy rules rule s on the existing e xisting security se curity infrastruct in frastructure ure that controls c ontrols trac t rac to the th e
internet. It is more complex to manage a device located at a remote re mote site than a device located at a central site. If, at your remote re mote site, site , you have an existing existin g out-of-band out-of-band (OOB) (OOB ) network netwo rk dedicated dedic ated to device de vice management, manag ement, then t hen you can follow f ollow the same approach app roach that was previously prev iously discussed disc ussed for central site s ite devices. devic es. If this is a new ne w deployment and you want to perform a zero-touch deployment, then connect an alternate controller port to an internet circuit at your site. Refer to your platform as listed in Table 1 to 1 to identify alternate controller ports. Your device registers with the CloudGenix portal in the same way as it would with a connection directly to the controller port. You may continue co ntinue with wit h conguration congurat ion and management man agement using us ing the alternate alt ernate controller c ontroller port until unti l the device dev ice
is fully operational. At this time, you can connect the controller port to the internal LAN at the remote site. Your device devi ce transitions transi tions to management ma nagement through the controlle controllerr port once o nce this connectio c onnection n is active. active .
Sites and Devices For basic conguration, the portal is structured with a topology map and panes for sites and devices. You congure congur e a portion por tion of the congurati conguration on details at the site level and the remaining rem aining details deta ils at the device level. However, you should rst create and congure the sites. As part of the initial conguration, you designate desig nate the sites s ites as data center or or branch, assign them to a domain, and dene the circuits that are present at the site. Next, after you claim a device and assign it to a site, you congure the device interfaces. For each interface, you must set the usage, assign the circuit, congure the IP address, and, if necessary, congure the default gateway.
At new sites, si tes, you can c an connect conne ct the data dat a plane interface in terfacess at any time t ime during the deployment, dep loyment, and they become active once on ce they are congured. con gured. At existing sites, s ites, you may choose choos e to congure con gure the devices rst
before connecti connecting ng the data plane interface int erfaces. s. Depending Depend ing on the topology you choose, choos e, you may ma y need to t o use bypass pairs pa irs to transparent tr ansparently ly insert the device devi ce into the t he path. If I f you choose c hoose to replace r eplace your existing exi sting WAN router with an ION device, you should complete as much conguration as possible before you remove the
WAN router and move the connections conne ctions to the ION device. de vice.
Palo Alto Networks
45
CloudGenix Design Details
Routing At data center ce nter sites, site s, the ION device does not connect c onnect in i n the path for access acc ess to private pr ivate WAN and a nd internal interna l LAN networks. You must use either static routing or enable BGP dynamic routing in order to integrate the ION device into the topology. In an existing network, you use a single port that is congured to peer with
a network in order to connect with both the private WAN and internal LAN. This method can reduce the number of changes that you need to make. In a new deployment, you can use separate ports for the private WAN and internal inte rnal LAN connections co nnections.. In most data center sites, network security infrastructure already exists. Connect the internet port to the network security infrastructure that provides access to the internet. You must congure a default gateway on the internet port. However, for internal users and devices, the ION device is not used to forward trac
directly to the internet. At branch locations, if you choose ch oose to replace r eplace your existing exi sting WAN router rou ter with an ION device, dev ice, you yo u should connect interfaces directly to the internet, private WAN, and internal LAN network. You must congure
a default gateway on the internet port. You can use either static routing or enable BGP dynamic routing to the private WAN range through the private WAN port, or you can congure a default gateway to the
private WAN. Use either static routing or BGP dynamic routing to the internal LAN. Additional Routing Configuration Options for Data Center Devices
For data center devices, by default, branch-to-branch branch-to-branch trac is directly forwarded without leaving the data center ION device. If you want branch-to-branch branch-to-branch trac that traverses the data center ION device to be forwarded to an external data center device for inspection, monitoring, or ltering, then enable the Force VPN to VPN V PN Trac to Local Next N ext Hop feature. f eature. Additional Routing Configuration Options for Branch Devices
For branch devices, you can enable the following routing conguration options: •
WAN L3 Direct Private WAN bypass pair under underlay lay trac. trac . IfForwarding you do not —By use adefault, bypass pair, pBGP air, conguration you must explicitly expl uses icitlyaenable en able L3 Dirfor Direct ect private Priv ate Private
WAN Forwarding Forwar ding so that the private priv ate WAN port por t can communicate co mmunicate directly with a private pri vate WAN peer. pe er. You should also als o enable this feature featur e if you yo u want to use L3 LAN forwarding f orwarding.. L3 LAN Forwarding—If you want to enable layer 3 trac forwarding to and from LAN interfaces,
•
you must enable e nable L3 LAN L AN forwarding forwar ding on your yo ur device. devic e. This includes inc ludes interfaces inte rfaces that are not n ot bypass pairs. You must also congure L3 Direct Private WAN Forwarding in order to enable this feature. fe ature. Applicati Application on Reachability Reach ability Probes— If an ION device detects an unreachable prex for an application,
•
the device automatically initiates an application reachability probe to check the availabil availability ity of the application. By default, these probes are sourced from the controller port, but you can congure an
ION device to source the probes from any valid L3 LAN interface in order to support cases where the device either does not have a controller port or the controller port is not connected.
Palo Alto Networks
46
CloudGenix Design Details
Monitoring Your SD-WAN In addition to the conguration tasks listed previously, the CloudGenix portal also provides centralized
monitoring and reporting capabilities for your CloudGenix SD-WAN. The activity dashboard provides a monitoring pane for overall network performance, which you can also use to isolate sitesite-specic specic performance. Other activity panes include media performance and link quality,
where you y ou can isolate isol ate individual individ ual applications, applic ations, paths, path s, and sites. site s. If you yo u need to perfor perform m in-depth inspection inspect ion of specic sessions, use the ow pane, and if necessary, you can use advanced queries in order to lter and view specic ows.
You can also use the activity a ctivity dashboard d ashboard to monitor basic b asic system syste m health characteri c haracteristics, stics, such as CPU utilization,, memory utilization, and disk utilization. If you need to display IP routing details, you use the utilization activity pane for routing stats to view the routing peer status and prexes that your devices advertise and
learn. If you need to access the ION device toolkit, you can remotely access any claimed device directly from the CloudGenix portal. In Device Toolkit User Management, you must set the user credentials before accessing your devices. dev ices.
Palo Alto Networks
47
Palo Alto Networks Design Details
Palo Alto Networks Design Details PAN-OS version 9.1 introduces a number of new SD-WAN features that are included with your SD-WAN subscription. This section provides an in-depth discussion of the SD-WAN capabilities of the nextgeneration rewall and the design considerations associated with these capabilities. You can congure co ngure SD-WAN hub or branch functions fu nctions on your devices dev ices after aft er adding the SD-WAN subscription to any of the next-generation rewalls or VM-Series models listed in Table 9 and 9 and Table 10.
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 specications, see the SD-WAN datasheet. Table 9 SD-WAN remote-site branch device specications
Agg reg ate WAN
PA-220/ PA-220R
PA-820
PA-850
PA-32 20
PA-3250
PA-3 260
1-150 Mb Mbps ps
50-500
50-700 Mb M bp s
500-2000
1000-3100
2000-5000
Mbps
Mbps
Mbps
Mbps
bandwidth (recommended range) Maximum IPSec tunnels
1000
1000
1000
2000
3000
3000
Maximum concurrent sessions
64,000
128,000
196,000
1,000,000
2,000,000
3,000,000
Maximum IP v4 routes
2500
10,000
10,000
28,000
88,000
88,000
Table 10 SD-WAN central-site hub device specications PA-52 20
PA-5250
PA-5260
V M-300
V M-500
Agg reg ate IPS IPSec ec band b and wi width dth
8 G bp s
16 Gbps
2 4 G bp s
1 .8 G b p s
4 G bp s
Maximum IPSec tunnels
3000
4000
5000
1000
1000
Maximum concurrent sessions
4,000,000
8,000,000
32,000,000
819,200
2,000,000
Maximum IPv4 routes
200,000
200,000
200,000
2000
4000
Applicatio n-aware next-generation security Application-aware se curity is i s naturally complem complemented ented by networki networking ng functions functio ns like SD-WAN application-aware routing. The approach of running both SD-WAN and security on an integrated branch device de vice results re sults in more mo re ecient ecie nt management manage ment across acr oss networking networ king and security, se curity, with a lower lowe r chance of misconguration compared to a multi-device multi-device approach.
Palo Alto Networks
48
Palo Alto Networks Design Details
The next-generation next-generation rewalls continue to use IPSec to provide a WAN overlay tunneling technology coupled with strong encryption for data privacy. The rewalls extend the use of application and protocol
decoding within App-ID App-ID to rapidly and accurately identify applications running across the WAN. Other new capabilities specic to SDSD-WAN WAN include: path-health path-health monitoring for key path metrics such as latency, jitter and loss, and per-application policies p olicies for fo r path selection se lection and a nd trac distribution. d istribution. The next section
discusses new features and capabilities in-depth.
NEW CONSTRUCTS FOR PANOS SECURE SDWAN PAN-OS 9.1 adds several new constructs that are required to enable SD-WAN on your devices: SD-WAN interface prole—Characteristics and parameters that dene the SDSD-WAN 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 proles—Metrics and acceptable performance limits required for various
•
application classes using the SD-WAN •
SD-WAN trac distribution proles—Path selection methods used by SD-WAN policies SD-WAN trac policy rules—Rules that match security zones, IP addresses and applications which are then used to apply the SD-WAN SD-WAN trac distribution proles
•
SD-WAN Interface Profile Basic Settings
The SD-WAN SD-WAN interface prole denes the link type, link tag, upload/download bandwidth speed of the
link, and whether you should use aggressive or relaxed path monitoring for the link. After you have enabled SD-WAN SD-WAN for an interface, you must associate the interface prole with the interface. For path selection ordering, you use the link tag in the trac distribution prole. Link tags also group several
interfaces for session load-sharing or link bundling. If multiple interfaces are assigned SD-WAN interface proles with the same link tag, those links are logically bonded together for trac distribution.
The Panorama SD-WAN SD-WAN plugin uses the linklink-type 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, cable modem, Ethernet, ber, LTE/4G, or WiWi-Fi), Fi), then the SDSD-WAN WAN plugin congures 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 conguration for IPSec I PSec tunnels and do not initiate connections. SD-WAN SD-WAN branch devices at remote sites use dynamic peer conguration for IPSec tunnels to central sites. Note
PAN-OS version 9.1 software supports only hub-and-spoke topology for an overlay network. Multiple hubs are supported.
Palo Alto Networks
49
Palo Alto Networks Design Details
Table 11 SD-WAN link types
Li nk t y pe
Lin k c l ass
Tu n ne l p e er s
ADSL/DSL
publicc publi
ADSL/DSL Cablemodem
Path monitoring method (default)
Aggressi Agg ressive ve
Ethernet Fiber LTE/3G/4G/5G WiFi Ca bl em o d e m
publ ic
A DSL/DSL Cablemodem Ethernet Fiber LTE/3G/4G/5G WiFi
Aggressi Agg ressive ve
Et hernet
publ ic
A DSL/DSL Cablemodem Ethernet Fiber LTE/3G/4G/5G WiFi
Aggressi Agg ressive ve
Fib e r
publ ic
A DSL/DSL Cablemodem Ethernet Fiber LTE/3G/4G/5G WiFi
Aggressi Agg ressive ve
LTE/3G/4G/5G
publ ic
A DSL/DSL Cablemodem Ethernet Fiber LTE/3G/4G/5G
Relaxed
M PL S
pr ivate (MPLS)
WiFi M PLS
Microw av ave/Radio
pr iv ivate (microwave/radio)
M icrow av ave/R ad adio
Ag gr gressive
S at el l i t e
pr ivate (satel lite)
S a t e l l i te
Re l a xe d
WiFi
publicc publi
ADSL/DSL Cablemodem Ethernet Fiber LTE/3G/4G/5G WiFi
Aggressi Agg ressive ve
Ot her
pr ivate (ot her)
O t h er
A g g re ssive
A g g re ssive
Palo Alto Networks
50
Palo Alto Networks Design Details
When you select s elect the link type, type , a default path monitoring monito ring method metho d is automatically automat ically selected. se lected. Path monitoring is used to evaluate path health based on delay, loss, and jitter metrics, which are calculated from data collected from trac probes. The path monitoring assumes that you have a Palo Alto Networks
SD-WAN SDWAN device terminating the IPSec tunnels at both ends of a connection. The device, when congured to use aggressive mode, sends probe packets at a constant frequency of 5 probes per second. The device, when congured 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 restarti restarting ng the probes. pr obes. You may override over ride the default path p ath monitoring monitor ing method. Using aggressive aggre ssive 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 congurable for both modes, and the idle period pe riod is congurable 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 shoul d reduce reduc e the packet pac ket loss threshold in order to increase incre ase the likeliho likelihood od 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 benets of SD-WAN is the ability for your devices to move trac ows from degraded
paths to better-performing better-performing paths. Ideally, when a degraded path has recovered, your device reinstates r einstates ows to that path. To avoid the risk of path apping, where trac 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 SD-WAN devices reinstates ows to that path. The hold timer is congurable. Palo Alto Networks typically recommends that you use a unique SD-WAN SD-WAN interface prole 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 simplies the conguration required for basic load-sharing. VPN Data Tunnel Support
Although in most m ost cases Palo Alto Networks Ne tworks recomme recommends nds using data da ta encryption encry ption across acr oss all WAN links, li nks, when using an MPLS link type, you may choose to natively route certain trac directly over the MPLS network,
outside of the IPSec VPN tunnel.
Palo Alto Networks
51
Palo Alto Networks Design Details
If you want the trac to be directly routed over the MPLS network, in the SD-WAN SD-WAN interface prole
for MPLS links, you disable the VPN Data Tunnel Support feature. By default, this feature is enabled. Regardless of whether this feature is enabled or disabled, the SD-WAN SD-WAN plugin creates the VPN tunnel. Note
If you disable VPN Data Support, make sure to maintain a consistent conguration on both the SD-WAN central-site hub devices and SD-WAN
remote-site remotesite devices that use the MPLS link type. If the settings are mismatched between sites, trac is dropped.
SD-WAN Virtual Interface Typical Usage
You can congure co ngure the SD-WAN virtual interface inter face (VIF) (V IF) to contain c ontain SD-WAN–enabled physical interface i nterfacess
and IPSec tunnel interfaces as group members. All group members are typically the same type, with one exception, which is discussed later. Figure 20 SD-WAN virtual interfaces Ping probes (to default-gateway) Path-monitoring probes (end-to-end)
INET-1 (eth1/1)
DIA VIF
VPN VIF
INET-2 (eth1/2)
IPSec tunnels
VPN VIF
The VIF performs several key functions on an SDSD-WAN WAN device: 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 decisions Generates path-monitoring path-monitoring probes for each group member
•
Enables physical interface group members to maintain an interface-specic default gateway without requiring re quiring a specic entry in the IP forwardin f orwarding g table
•
Performs intelligent trac distribution across group member interfaces, depending on the trac distribution prole
•
Palo Alto Networks
52
Palo Alto Networks Design Details
In most cases, the Panorama SD-WAN plugin automatically creates the SD-WAN VIFs. Table 12 VIFs created by SD-WAN plugin DI A V I F con f ig u r at ion
V PN V I F c o n f i g u r at i o n
Single DIA VIF V IF that includes i ncludes al l SD-WAN SD-WAN– –
One VPN VIF for each remote site. Each includes
Central site
enabled physical interfaces as group members
all IPSec tunnels to a particular remote site as group members
Remote site
Single DIA VIF V IF that includes i ncludes al l SD-WAN SD-WAN– – enabled physical interfaces as group members
One VPN VIF for each central site. Each includes all IPSec tunnels to a particular central site as group members
On all SD-WAN 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 congured or assigned as a
DHCP option. Note
The SD-WAN SD-WAN plugin automatically includes private interfaces, such as MPLS, as DIA VIF group members. You should exclude the private interfaces from your SD-WAN SD -WAN trac distribu d istribution tion prole p role for f or DIA. DIA .
In some cases, you may also need to manually create a VIF with physical interface group members before complet completing ing the SD-WAN conguration congur ation with the Panorama Panora ma SD-WAN plugin. In these cases, cas es, when conguring 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 DIAVIF VIFisperforms monitoring, liketoother VIFs, but does notdefault have angateways. explicit peer to probe. the DIA created,path it sends ping probes the interface-specic interfacespecic At least one ofWhen 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 d efault gateways for your you r physical physica l interfaces interf aces respond re spond 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 trac.
Palo Alto Networks
53
Palo Alto Networks Design Details
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 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 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 t unnel for fo r a VPN VIF changes cha nges to an UP state st ate 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 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 r outing table. The best path in the routing ro uting table is installed installe d in the forwarding f orwarding table, or if equal-cost multipath multip ath (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 loadload-sharing 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 trac is forwarded to the VIF, it determines which path to follow based on the SD-WAN policy, trac distribution prole and real-time 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 simplies 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 congured to provide the default gateway using the router option, this results in two equal cost paths, with each path through a dierent interface. In this case, SD-WAN seamlessly solves this issue. If you congure your SDSD-WAN WAN device so that the default route is not installed in the routing table, the DIA VIF transparently retains each interfaceinterface-specic specic 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 th e VPN VIFs VI Fs are created cr eated and an d the tunnels tunne ls are active, ac tive, the SD-WAN devices can apply ap ply the SD-WAN policies and select the best paths per-application based on current real-time conditions of the SD-WAN.
Palo Alto Networks
54
Palo Alto Networks Design Details
DIA Failover to MPLS Usage
In SD-WAN networks that use both MPLS and the internet as WAN transports, you have an option to use the MPLS network as a backup path in case the internet connection at the remote site fails and cannot be used for DIA trac. The SDSD-WAN WAN plugin supports two variants of this option, which leverages the VPN
Data Tunnel Support feature. Table 13 DIA failover variants
VPN Dat a Tu nne nnell Suppo Su pport rt ena enable bledd (default)
VPN Dat a Tu nne nnell Suppo Su pport rt dis abl abled ed
Internal network traffic
DIA traffic backhaul to hub (failover path)
Uses VPN data tunnel
Directly routed on MPLS network
VPN VIF V IF include in cludess VPN tun tunnel nel to hub (over MPLS)
DIA VIF includes MPLS physical interface
Directly routed on MPLS network
Uses VPN data tunnel
VPN VIF V IF include in cludess MPLS physica phy sicall interface
DIA VIF includes VPN tunnel to hub (over MPLS)
The variant with VPN Data Tunnel Support disabled is the exception to the VIF membership rule r ule that all group members are the same type. If you choose this variant, both the VPN VIF and DIA VIF contain a mix of physical interfaces and VPN tunnels as group members. Note
If you use DIA failover to MPLS and select the variant with VPN Data Tunnel Support enabled, your MPLS network must include a default route that directs trac to the central site and that serves as the internet backup path.
SD-WAN Path-Quality Profiles Each SD-WAN path-quality prole (PQP) is composed of a set of ranked metrics and thresholds that an
application requires for optimal performance. You typically use a unique PQP for each set of businesscritical and latency-sensitive applications. The PQP is one of the key components of the SD-WAN path selection logic. The SD-WAN SD-WAN path-monitoring 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.
Palo Alto Networks
55
Palo Alto Networks Design Details
The metrics each PQP uses are: 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 delay for aevery data packet across a SD-WAN SDWAN tunnel (measured in ms). By default, the average jitter is calculated 200mssent by using a sliding
window that includes the last three thre e measurements. measure ments. •
Packet loss—The percentage of packets lost compared to total packets sent across a SD-WAN 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 qualied (operating normally) or is disqualied (operating in a degraded mode). The secondary function of the PQP is to determine which path to use when more mor e than one path is qualied, quali ed, and these t hese paths are otherwise othe rwise considered co nsidered equivalen equivalentt by the path
selection algorithm. The threshold forthe each metric is considered maximum upper that metric. If your SDSD-WAN WAN device measures value of any PQP metricafor a path and the limit valuefor exceeds the congured threshold, the path is disqualied. When a link is disqualied, this triggers your SD-WAN device to select an alternate qualied path. If a set of paths are all qualied, then the SDSD-WAN 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 congure a metric to have a higher sensitivity than the other metrics, then the path selection algorithm considers that metric rst. If all metrics have the same value, then the path selection algorithm rst considers packet loss, followed by latency, and then jitter.
SD-WAN Traffic Distribution Profiles An SD-WAN policy rule ru le denes dene s the criteria cri teria used use d by the SD-WAN S D-WAN path-selection path-selection algorithm. Each policy polic y rule includes both a PQP and a trac distribution prole (TDP), which are evaluated concurrently to determine
the path for an application.
Palo Alto Networks
56
Palo Alto Networks Design Details
Note When conguring co nguring a TDP, you use link tags ta gs instead inste ad of SD-WAN interface inter face prole p role
names. If you are using unique SD-WAN interface proles 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 dierentiate between t he physical
interfaces in your SDSD-WAN WAN policy. If you are using a shared SDSD-WAN 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 dierentiate between the physical interfaces in
your SD-WAN policy. policy .
As part of o f your SD-WAN S D-WAN policy, you use us e SD-WAN TDPs to assign which trac tra c distribution distribu tion method the
path-selection algorithm uses for an application. The path-selection algorithm uses the path metrics, thresholds, and sensitivities sensitivities as dened in the PQP referenced in the SDSD-WAN WAN policy rule. When you congure your TDP, you can choose from the following trac distribution methods: Best available path—This trac 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 pe rmitted paths that match m atch the link l ink tags. Only O nly qualied qualie d paths are ar e eligible for selection. If multiple paths are qualied, the pathpath-selection selection algorithm uses the sensitivity value assigned to the metrics to prioritize which metric is used rst 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 disqualied, the path selection algorithm moves aected sessions to the best qualied path remaining. When path conditions change and the best available path is again qualied and the Fallback Hold Time expires, the path selection algorithm moves aected sessions back to the best available path. Top-down Top-down priority—This trac distribution method requires you to create a prioritized list of permitted link tags. When using this method, the path-selection algorithm chooses a qualied path that matches the highest priority link tag. You typically use this method when there is a signicant cost dierential between paths. You assign a low priority to paths with high-cost high-cost link tags so the more expensive links are used only when paths with low-cost link tags are disqualied.
•
If the path conditions change and the highest priority path is disqualied, the path selection algorithm moves aected sessions to the next-highest next-highest priority qualied path remaining. When path conditions change and the highest priority path is again qualied and the Fallback Hold Time expires, the path selection algorithm moves aected sessions back to the highest priority path. Weighted session distri distribution— bution— This trac 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 p aths do not need to be qualied.
When a link tag reaches reache s its percentage pe rcentage limit, further furt her sessions sessi ons are distributed d istributed only to paths p aths with link tags that remain under the percentage limit. You typically use this method for nonnon-critical critical applications. This trac distribution distribution method does not rely on path metrics.
Palo Alto Networks
57
Palo Alto Networks Design Details
Note
The Weighted Session Distribution method does not reroute existing sessions when a path is disqualied. disqu alied. Existi Existing ng sessions sessi ons are only rerouted re routed when their th eir
path state changes to DOWN. Palo Alto Networks does not recommend using this method for businesscritical applications.
If you congure multiple physical interfaces with the same SD-WAN SD-WAN interface prole and link tag, then you adjust the behavior behavio r of these the se trac distributio distribution n methods. For each eac h method, if i f the path-selection pat h-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 trac distribution methods that was previously discussed, the
path-selection pathselection 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 qualied paths with the link tag. No qualied paths exist—This is a special case that commonly occurs in the early stage of an SD-WAN SDWAN deployment. If you don’t know the current loss, jitter, and latency for your WAN paths and you congure the PQP thresholds too low, this case may occur. In this case, the path-selection 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
Rather than relying on the implicit round-robin round-robin method for unmatched sessions, Palo Alto Networks recommends creating an “Unmatched” SD-WAN SD-WAN policy rule that matches any application with any service. You should create a PQP with high thresholds for all metrics and then reference this PQP within the policy rule. You can use any TDP that you prefer with this policy rule.
All VIFs are a re down— 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.
Palo Alto Networks
58
Palo Alto Networks Design Details
SD-WAN Policy Rules SD-WAN policy rules are similar to security policy rules, which makes SD-WAN policies easy to congure.
Both rule types match on source zone/address/user, destination destination zone/address, and application/service. However, the security policies are evaluated rst before applying the SD-WAN SD-WAN policy. If an application is
permitted by the security policy, the SD-WAN policy then processes the application. The SD-WAN policy rules are not processed for denied applications or ows.
After an applicati application on matches an SD-WAN policy rule, rule , the path-selection algorithm evaluates e valuates each e ach path from the TDP against the real-time path conditions and thresholds in the PQP to determine the appropriate path. Note
Palo Alto Networks SDSD-WAN WAN automatically enables the Symmetric Return feature in order to avoid asymmetric trac ows. You need nee d to congure c ongure an SD-WAN policy p olicy only o nly at the site si te that th at init iates the
connection. If you initiate a connection from a remote site to a central site and the SD-WAN policy at the remote site assigns the ow to an SD-WAN path, the central-site centralsite device automatically uses t he same path for the return trac.
MANAGING SDWAN DEPLOYMENTS WITH PANORAMA The best method for ensuring up-to-date rewall conguration is to use Panorama for central management of rewall policies. Panorama simplies consistent policy conguration across multiple independent rewalls through its device group and template stack capabilities. When multiple rewalls
are part of the same device group, they receive a common ruleset. Because Panorama enables you to control all of your rewalls—whether they be onon-premises premises or in the public cloud, a physical appliance or virtual—device groups also provide conguration hierarchy. With device group hierarchy, lower-level groups include the policies of the higherhigher-level level groups. This allows you to congure consistent rulesets that apply to all rewalls, as well as consistent rulesets that apply to specic rewall deployment
locations such as the public cloud.
Your SD-WAN conguration congurat ion is simplied simp lied by using u sing a minimum minim um of two sets of template templatess and device devi ce groups. group s.
Use one set for central-site 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.
Panorama and the SD-WAN Plugin In addition to the traditional Panorama capabilities based on device group and template stacks, the SD-WAN SDWAN plugin for Panorama also provides advanced conguration, monitoring, and reporting for SD WAN. Although Althoug h the SD-WAN plugin supports sup ports the congurati conguration on of existing ex isting browneld brow neld devices, dev ices, this guide
only covers the design details for new deployments.
Palo Alto Networks
59
Palo Alto Networks Design Details
After you y ou add your you r central-site centr al-site and remote-site devices dev ices to Panorama P anorama and associate them with the proper prop er template stacks and device groups, you complete the device congurations using the SD-WAN SD-WAN plugin for
Panorama. As you add devices to the SD-WAN plugin, you y ou must assign ass ign the devices de vices to a site and designate the site type as either Hub or branch. The site type determines which other sites to congure as IPSec peers. Palo
Alto Networks Netwo rks recommends rec ommends that t hat you enable en able dynamic dynam ic routing routin g with BGP for the site. As part p art of the t he BGP conguration, you must provide the following site-specic information: BGP router-ID, IPv4 loopback
address, and BGP autonomous system number. On central-site central-site hubs, you must also provide a list of IPv4 prexes for BGP to advertise. On remote-site remote-site devices, the list of IPv4 prexes for BGP is optional. After you y ou have added ad ded the devices, de vices, you yo u complete comple te the SD-WAN plugin congurati conguration on by creating cr eating an SD-WAN S D-WAN
VPN cluster. cluste r. Each VPN V PN cluster is a logical logic al grouping of central-site centr al-site and remote-site remote -site devices. The SD-WAN plugin uses VPN clusters as the top level for SD-WAN monitoring monitoring and reporting. Note
You must assign a ssign each ea ch device devi ce to a VPN cluster. clus ter. If you leave lea ve a device de vice unassigned un assigned,, the SD-WAN plugin does not generate and push the SD-WAN conguration to
the device.
The SD-WAN plugin simplies and automates several critical SD-WAN tasks through a process referred to AutoVPN PN . When the SD-WAN plugin runs AutoVPN, the following tasks are completed: as AutoV
Create predened security zones and required interfaces—If the predened 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 routerrouter-ID. ID. Create SD-WAN VIFs and congure IPSec tunnels —The plugin automatically creates the required VIFs for each SD-WAN device. device . The plugin plug in also generates gen erates the t he complete comple te conguration congur ation for the IPSec IPSe c tunnels, which includes the tunnel interfaces, IKE crypto prole, IKE gateways, IPSec crypto prole,
•
and the IPSec tunnels. The plugin assigns tunnel IP addresses from a customer provided pool. Conguration of BGP and static routes—The plugin automatically automatically enables BGP on all of the selected SD-WAN SD-WAN devices. The BGP conguration includes peer group setup and redistribution of the central-site central-site and remote-site prexes. 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 congure static routing. Note The SD-WAN plugin regenerates AutoVPN congurations each time new
devices are added to the plugin. Palo Alto Networks does not recommend performing local overrides of conguration elements that the SDSD -WAN plugin
manages.
Palo Alto Networks
60
Palo Alto Networks Design Details
In addition to the conguration tasks listed previously, the SDSD-WAN WAN plugin also provides centralized
monitoring and reporting capabilities for SD-WAN. SD-WAN. The monitoring dashboard provides application performance and link performance statistics for your SDSD-WAN WAN VPN clusters on a per-site basis. Applicatio n performance Application perf ormance monitoring includes a list of all al l observed observe d applications applic ations for each site, site , matching SD-WAN SDWAN 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 SD-WAN device is unable to identify a path that meets the dened 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 sp ecify the th e time interval in terval for f or the dashboard das hboard or customize the interval inter val to investigate inve stigate previous pr evious events. If you need more detail on an application or a link, you can drill down and get more specic
information.
Log Collection with Panorama The monitoring and reporting capabilities for SD-WAN SD-WAN require that you collect and store trac logs using Panorama in either a standalone or log-collector based conguration.
You can use either of the following follo wing two deployme d eployment nt mode options o ptions for Panorama which, w hich, if necessary, ne cessary, 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.
Palo Alto Networks
61
Palo Alto Networks Design Details
Figure 21 Panorama modes Panorama (Panorama Mode)
Panorama (Management Mode)
Panorama (Log Collector Mode)
Configuration Logging
The separation of management and log collection enables the Panorama deployment to meet scalability, organizational, organizationa l, and geographical requirements. You must have hav e one or more managed mana ged log collectors c ollectors (which may ma y include Panorama itself). i tself). On Panorama, Panoram a, you add each e ach log collector co llector a collecto collectorr group. As you add ad d new SD-WAN devices to Panorama, Panora ma, you must mus t assign each device to a collector group. On your SD-WAN devices, you must send system logs, conguration logs, and trac logs to Panorama. Otherwise, the SD-WAN SD-WAN monitoring screens on Panorama will be incomplete. To send the trac logs, you must create a log forwarding prole and reference this prole within each of your security policy rules. If you do not no t include a log forwarding forw arding prole, pr ole, the trac matching matc hing that security se curity policy p olicy rule ru le is not monitored m onitored..
Palo Alto Networks
62
Palo Alto Networks Design Details
Device Management You manage and monitor all devices devic es in your SD-WAN by using Panorama Panoram a and the Panorama P anorama 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 conguration 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
If you intend to manage your devices by using dataplane interfaces across a public network, then you must assign a public IP address to Panorama and each log collector.
Central-Site Device Management
You typically typic ally deploy deplo y Panorama Panoram a in a central cen tral site so that you yo u can manage manag e the next-generation ne xt-generation rewalls re walls
deployed within your organization. If you take this approach, managing your central-site 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 conguration 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. To permit the control plane applications that use cloud services, you must create c reate security se curity policy p olicy rules rule s on the existing e xisting security se curity infrastruct in frastructure ure that controls c ontrols trac t rac to the th e
internet. Figure 22 Central-site device management Configuration Logging
Internet
Updates
(eth1/1) dataplane flows (MGT)
(MGT)
Central Site
(eth1/x)
Palo Alto Networks
63
Palo Alto Networks Design Details
If you are deploying a new device, you can arrange for technical on-site personnel to perform the initial device conguration. The initial conguration tasks require a direct connection to the SDSD-WAN WAN device.
After the th e initial tasks ta sks are complete complete,, you can complet completee the remaining re maining tasks task s centrally, centr ally, using Panorama. Remote-Site Device Management
It is more complex to manage a device located at a remote re mote site than it is for a device located at a central site. If you have an existing out-ofout-of-band band (OOB) network dedicated to device management, then you can follow the same approach that was previously discussed for central site devices. Figure 23 Remote-site device management Configuration Logging
Internet
Updates
(MGT) (eth1/1) dataplane flows (MGT)
Central Site
(eth1/x)
Remote Site
Palo Alto Networks
64
Palo Alto Networks Design Details
The following methods are available for remote sites without an OOB management network: Manual device conguration performed by on-site personnel—This method is almost identical to the method discussed for central sites. The primary dierence is the conguration. For a
•
remote-site device without an OOB management network, you must manage the device in-band, through a dataplane interface (example: ethernet1/1). This method requires that you create service routes, NAT policy rules, and security policy rules for your device. When the basic conguration is
complete, you can connect the device to the network, and the device initiates contact to Panorama. You can complete co mplete the t he remaining remain ing tasks centrally c entrally,, using Panorama. Pano rama. The congurati conguration on that you
develop using this method may be used in the alternate methods that follow. In this method, when you add the device to Panorama and apply the centralized conguration, you overwrite over write certain c ertain several se veral local loc al device devic e parameters parame ters with wit h identical, centrally dened values. va lues. The centralized conguration also inserts new policies using Panorama pre-rules, pre-rules, preempting the
local policy rules. This approach allows you to maintain centralized control of the overall device conguration. USB bootstrap conguration— After you y ou have created cr eated and an d validated a working workin g remote-device remote -device conguration, you may use that remote-device remote-device conguration as a baseline conguration to simplify and automate the conguration process. First, you create an init-cfg.txt init-cfg.txt le that provides the basic
•
information that your device needs to connect to your network. Then, you must save and export a conguration snapshot snapshot from a working device. Next, you create a bootstrap package that includes both the init-cfg.txt in it-cfg.txt le and the conguration congu ration snapshot. snap shot. In order to bootstrap a SD-WAN SD-WAN device, you must rst install the bootstrap package onto a USB ash drive. To prepare the USB ash drive with the bootstrap package, you can use any running Palo Alto Networks next-generation rewall with a USB port. The on-site personnel can congure a factory-default factory-default SD-WAN SD-WAN device by inserting the USB ash drive and then powering on the device. The on-site on-site personnel do not need to perform any device conguration. 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 y ou have created c reated and a nd validated validate d a working work ing remote-device remot e-device conguration, congur ation, central-site personnel perform the SD-WAN device congurations 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 on-site personnel do not need to perform any device conguration. 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.
Palo Alto Networks
65
Palo Alto Networks Design Details
SECURITY ZONES Each SD-WAN SD-WAN device requires a specic 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 I f you don’t create the zones in advance, the SD-WAN plugin plugin creates any required zones that do not already exist.
Central Site At a minimum, minimu m, each central c entral site sit e must include inc lude the zones z ones listed liste d in Table 14. 14. Table 14 Required zones for SD-WAN central-site devices Z one n a me
Z one t y p e
SD-WA N u s age
zon onee-in intter ern nal
Layyer3 La
Req equi uire red d fo for dev deviice loo oop pba back ck in intter erfa facces use sed d fo for SD SD-WAN AN.. Zo Zone nam namee mus mustt match exactly.
zon zo ne-to to-br bran anch ch
Laye La yer3 r3
Requir Requ ired ed fo forr SD SD-WAN tu tunn nnel elss and and VP VPN N VIF VIFss to to rem remot otee si site tes. s. Zo Zone ne na name me mus ustt match exactly.
zon onee-publi licc
Layyer3 La
Req equi uire red d for WAN AN-fa faci cin ng in intter erfa facces an and d DIA VI VIF Fs. You may ch choo oosse th thee zon onee name.
zon onee-pri riva vatte
Layyer3 La
Req equi uire red d fo for LAN LAN-fa faci cin ng in inter erffac aces es at cen centr tral al sites es.. Yo You may may ch choo oosse th the zo zone name.
Figure 24 CentralCentral-site site security zones (eth1/3)
Zone: zone-pri zone-private vate
(loopback.901)
Zone: zone-internal
(eth 1/1) Zone: zone-public
(eth 1/2 )
DIA VIF
VPN VIF (to remote sites)
zone-to-branch e-to-branch Zone: zon
Palo Alto Networks
66
Palo Alto Networks Design Details
Remote Site At a minimum, minimu m, each remote r emote site sit e must include inc lude the zones listed liste d in Table 15. 15. If necessary, you may use additional private zones to provide segmentation at your remote sites. Table 15 Required zones for SD-WAN remote-site devices Z one n a me
Z on e t y p e
SD-WA N u s age
zone-inter na na l
L ay e r 3
Required for de vi vice loopback i nt nterface used for SD-WA N. Zone na me me must match exactly.
zone-to-hub
L ay e r 3
Required for SD-WA N t unnels and V PN PN V IF IFs to cent ral sites. Zone na me me must match exactly.
zone-public
L ay e r 3
Required for WA N-facing i nterfaces a nd DI A V IFs. You may choose t he zone name.
zone-priv at ate
L ay e r 3
Required for L AN AN-faci ng ng inter fa faces at remote sites. You may choose t he zone name.
Figure 25 Remote-site securit securityy zones VPN VIF (to central sites)
Zone: z on one-public e-public
DIA VIF
(eth1/1)
zone-internal ernal Zone: zone-int
Zone: zone-to-hub
(eth1/2)
(loopback.901)
(eth1/3)
Zone: zone-private
AUTOVPN OVERLAY The Panorama SD-WAN 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, ber, LTE/4G or Wi-Fi), then the SD-WAN plugin congures 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 r un AutoVPN, the SD-WAN plugin creates cre ates an overlay o verlay network n etwork between b etween each set of peers. pee rs. 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 link types of the tunnel source interfaces. The SD-WAN plugin uses the link class for the link type listed in Table 11 to 11 to determine the tunnel peers.
Palo Alto Networks
67
Palo Alto Networks Design Details
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 SD-WAN plugin does not create tunnels between public and private interfaces. The SD-WAN 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 trac and use the private interfaces for tunnel termination. Congure a trac distribution prole for DIA that includes only interfaces connected to public networks.
An SD-WAN path is equivalent equiv alent to a tunnel within wit hin a VPN VIF. VI F. The SD-WAN devices perfor perform m pathmonitoring for each path. Figure 26 AutoVPN (MPLS and internet)
INET (eth1/1)
MPLS (eth1/2)
VPN VIF (to remote site)
DIA VIF
source interface
DIA VIF
source interface
INET (eth1/1)
MPLS (eth1/2)
VPN VIF (to central site)
Palo Alto Networks
68
Palo Alto Networks Design Details
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. Figure 27 AutoVPN (dual internet)
INET-1 (eth1/1)
INET-2 (eth1/2)
VPN VIF (to remote site)
DIA VIF
source interface
DIA VIF
source interface
INET-1 (eth1/1)
INET-2 (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 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. Figure 28 SD-WAN (MPLS and dual internet)
VPN VIF (to remote site)
DIA VIF INET-1 (eth1/1)
MPLS (eth1/3) source interface
INET-2 (eth1/2)
INET-2 (eth1/2) INET-1 (eth1/1) DIA VIF
source interface
MPLS (eth1/3) VPN VIF (to central site)
Palo Alto Networks
69
Palo Alto Networks Design Details
SDWAN ROUTING The method you use to route trac to and from your Layer 3 LAN devices (Ethernet switch or router) at
your sites site s is independent indep endent of o f the routing ro uting method metho d used within wit hin the SD-WAN. In order ord er to enable e nable endend -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-specic routes across the SD-WAN. Note
Palo Alto Networks recommends that you use contiguous IP route blocks within your yo ur organization organ ization so that you y ou may summarize s ummarize the IP routes. r outes. This Thi s approach simplies the routing conguration for your SD-WAN.
Central-Site Routing At your central c entral sites, si tes, you must congure congu re routing routin g on your Layer 3 LAN L AN devices devic es in order ord er to send se nd trac
destined for remote sites to the LAN interface of your SD-WAN 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 prexes or include summary routes that match the remotere mote-site site prexes. If you y ou use BGP or OSPF, you must also congure the same protocol on your SDSD-WAN WAN device and create a redistribution prole for the virtual router (on your SD-WAN device) that includes the remote-site prexes or summary routes. The SD-WAN device then advertises prexes listed in the redistributio redistribution n prole to your LAN device. At each central c entral site, sit e, you must mu st also congure con gure routing ro uting on your yo ur SD-WAN device to t o send trac tr ac destined destin ed for
the site to the nearest interface of your Layer 3 LAN device. You can use either static routing, OSPF, or BGP on your SDSD-WAN WAN device. If you use static routing, you must include all centralcentral-site site prexes or include summary routes that match the central-site central-site prexes. If you use BGP or OSPF, you must also congure the same protocol on your Layer 3 LAN device and advertise the central-site central-site prexes or summary routes r outes to
your SD-WAN device. You use BGP BG P between betwee n the SD-WAN devices devic es to advertise adve rtise the site-specic routes rout es across the SD-WAN. As part of the AutoVPN process with the SD-WAN SD-WAN plugin, you congure a list of IPv4 prexes for BGP to advertise. This list of prexes must include the centralcentral-site site prexes 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 r emote site sit e is an SD-WAN device directly connecte connected d to a Layer Lay er 2 LAN switch. In this type of topology, the SD-WAN SD-WAN device is responsible for all routing at the remote site. You use BGP BG P between betwee n the SD-WAN devices devic es in order ord er to advertise adv ertise the t he site-specic routes r outes across acr oss the SD-
WAN. As part par t of the AutoVPN process pr ocess with wit h the SD-WAN plugin, you yo u enable BGP B GP at the remote site. The AutoVPN process p rocess automatically a utomatically congures the SD-WAN device to redistribute redist ribute the directly connecte connected d routes from its LAN-facing interfaces. interfaces. You may also congure a list of IPv4 prexes for BGP to advertise.
Palo Alto Networks
70
Palo Alto Networks Design Details
Remote-Site to Remote-Site Routing If you wish to enable routing for trac between your remote sites, you must explicitly enable it. The BGP routing conguration generated by the SDSD-WAN WAN plugin advertises central-site central-site prexes to remote sites and advertises remote-site remote-site prexes to central sites. If I f you need to route trac between remote sites, you must designate d esignate one o ne or more mo re central cen tral sites to act as transit sites site s and congure cong ure those sites to advertise
one or more remote-site summary routes to the remoteremote-site site devices. When using multiple transit sites, you use the t he hub failover failo ver priority pr iority feature f eature to prioritiz prioritizee the sites sit es so that only one transit site sit e is active. activ e. The SD-WAN SDWAN plugin uses the congured priority to manipulate the BGP local preference values for all prexes
that BGP advertises to the remote sites. When multiple routes to the same destination are available, the remote sites use the local preference to select a preferred route. Figure 29 Remote-site to remote-site routing Central Site INET-1 INET-2 MPLS
Local LAN 10.5.128.0/22
Dest IP Prefix 10.5.128.0/22 10.6.0.0/16 10.61.0.0/16 BGP Redist Rules
remote-remote traffic
remote-remote traffic ( sd wan.9 02 ) Local LAN 10.6.128.0/24
( sd wan.9 02 ) Local LAN 10.61.128.0/24
Routes
Dest IP Prefix 10.5.128.0/22 10.6.0.0/16 10.61.0.0/16 10.6.128.0/24
Routes
Interface sdwan.902 sdwan.902 sdwan.902 ethernet1/3
Dest IP Prefix 10.5.128.0/22 10.6.0.0/16 10.61.0.0/16 10.61.128.0/24
Interface sdwan.902 sdwan.902 sdwan.902 ethernet1/3
Remote Sites
SECURING THE SITES In addition to securing user trac, as part of your SDSD-WAN WAN deployment you must create security policies
to support control-plane functions such as remote-management, DNS, NTP, routing protocols, and security service updates. The SDSD-WAN WAN devices require a properly functioning control plane. Otherwise, they cannot forward user trac and provide consistent visibility and comprehensive protection.
Palo Alto Networks
71
Palo Alto Networks Design Details
Control-Plane Contro l-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 congure congur e the remote-site re mote-site SD-WAN devices to use their dataplane interfac interfaces es for remote-managemen remote-management, t, DNS, NTP and security service updates by using service routes. As part of the service route conguration,
you must create c reate a loopback interfac interfacee for the t he service servi ce routes route s 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 interfac interfacee IP address. addr ess. Additionally, Additi onally, you yo u must create cre ate security sec urity policy pol icy rules rule s to permit per mit remoteremo temanagement, DNS, NTP and security service updates to access the zone-public zone. You must also create security s ecurity policy rules r ules to permit p ermit BGP BG P to and from f rom central-site cen tral-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 o f the DIA congurat conguration, ion, you create c reate a set of NAT N AT policy rules—one for each eac h of the WAN WA N dataplane dataplan e interfaces. Each NAT rule translates trac from the zonezone-private private zone to a WAN dataplane interface IP
address. Additionally, Additionally, you must create the required security policy rules to permit applications to access the zone-public zone. Figure 30 NAT policy for SD-WAN DIA Zone: zone-public
(eth1/1) NAT T NA
(eth1/2)
DIA VIF
Zone: zone-private
(eth1/3)
Or igin al P acke t
Tran sl ated Packet
Name
Source Zone
Destinatio Destination n Zone
Destinatio Destination n Interface
DIA-NAT-eth1_1
zone-private
zone-public
et her net 1/ 1
Source Tr anslat anslation ion d ynami c-ip -and -p ort ethernet1/1
DIA-NAT-eth1_2
zone-private
zone-public
et her net 1/ 2
d ynami c-ip -and -p ort ethernet1/2
Palo Alto Networks
72
Palo Alto Networks Design Details
Site-Site Policies Trac between SD-WAN 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 trac path. All security policy rules use rule
type Universal except where noted: Central-site to remote-site trac—At the central site, create security policy rules to permit application trac from the zone-private zone to the zone-to-branch zone. At the remote site, create security policy rules to permit application trac from the zone-to-hub zone-to-hub zone to the zone-
•
private zone. Remote-site to central-site trac —At the remote site, create security policy rules to permit application trac from the zone-private zone to the zone-to-hub zone. At the central site, create security policy rules to permit application trac from the zone-to-branch zone to the zone-private
•
zone. Remote-site to remote-site trac —At the source remote site, create cr eate security policy rules to permit application trac 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 trac 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 trac from the zone-to-
hub zone to the zone-private zone-private zone.
Palo Alto Networks
73
SD-WAN Design Models
SD-WAN Design Models CHOOSING A DESIGN MODEL When choosing choosi ng a design model option, opt ion, consider consid er the following f ollowing factors: f actors: Security coverage— What level of visibility visibil ity is required? re quired? Does my organization o rganization require
•
comprehensive security at each remote site? Are compliance requirements such as Health Insurance Portability and Accountability Accountability Act and Payment Card Industry driving the need for segmentation? The CloudGenix SD-WAN model includes an application-aware ZBFW and provides detailed analytics for bandwidth utilization, transaction statistics, and application health and application response time. The PAN-OS Secure SD-WAN model uses next-generation rewalls at every site, which extends ext ends full security protect protection ion to all trac ows at all locations. loc ations. As required r equired,, you can
segment your remote-site LAN environment by using dedicated security zones and interzone security policies to meet regulatory requirements and reduce the scope of compliance. If your primary security consideration is only for cloud-based cloud-based applications, then consider the CloudGenix with Prisma Prism a Access model. If your primary pr imary consideratio co nsideration n is pervasive per vasive security, se curity, then t hen consider consid er the PAN-OS Secure SD-WAN model. Scale—Overall SD-WAN SD-WAN performance depends on three factors: central-site central-site capacity to terminate remote-site remotesite connections, trac forwarding capacity of individual devices, and the ability of the management platform to congure and monitor all devices deployed within the SD-WAN. The
•
CloudGenix with Prisma Access model uses CloudGenix ION devices at both central sites and remote sites. Consider the device throughput of the ION devices when deciding between the design models. The PAN-OS SD-WAN model uses next-generation rewalls as SD-WAN devices at both central
sites and at remote sites. At central sites, consider both the maximum limits for aggregate IPSec bandwidth, IPSec tunnels, tun nels, and concurre concurrent nt sessions. session s. At remote re mote sites, site s, consider conside r both the maximum limits for aggregate IPSec bandwidth and concurrent sessions. •
Complexity —The —The planning and design process for an SDSD-WAN WAN deployment can signicantl signicantly y aect the overall complexity of the project. After you begin your deployment, the initial deployment tasks
and ongoing monitoring and maintenance tasks also contribute to the overall complexity. The CloudGenix SD-WAN supports hub-and-spoke designs managed through a cloud-based portal. You can also congure direct connections between remote sites by using the portal. In
the CloudGenix with Prisma Access model, you must use separate management tools for each component of the design. You use Panorama to manage Prisma Access and use the CloudBlade framework to integrate Prisma Access with the CloudGenix portal. If your primary consideration is ease of use, then consider the CloudGenix with Prisma Access model. The PAN-OS SD-WAN model supports a simple hub-and-spoke topology, with support for multiple hubs. Hub-andHub-and-spoke spoke designs are well understood and are not overly complex. All deployment, monitoring, and maintenance tasks useconguration a Panorama system as a common management Panorama simplies consistent policy across rewalls through its device platform. group and template stack capabilities. If your organization has already deployed Panorama and is also familiar with next-generation next-generat ion rewalls, rewal ls, then the transition to PAN-OS Secure SD-WAN is straightforward. straightfor ward.
Palo Alto Networks
74
SD-WAN Design Models
DESIGN MODELS These design models describe how CloudGenix SD-WAN and PAN-OS Secure SD-WAN allow organizations to extend their security perimeter to include remote sites, ensure data privacy for network trac internal to the organization, and provide inspection and visibility for all trac entering and leaving the network.
For building your SD-WAN and securing your external connections, Palo Alto Networks provides a broad set of oerings from which you may select:
CloudGenix SD-WAN with ION devices
•
Prisma Access
•
Next-generation rewall with PAN-OS Secure SD-WAN
•
There are many ways to use the concepts discussed in the previous sections to build an SD-WAN and secure your DIA trac. This guide includes two specic design models. The primary dierence between the two models is how each model provides comprehensive security for the remote-site remote-site trac. The CloudGenix with Prisma Access model uses a cloud-delivered rewall as a service, and the PAN-OS Secure SD-WAN model uses an on-premises rewall: 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 fabric links. You centrally manage all devices by using the CloudGenix portal. You manage the Prisma Access conguration by using the cloud services plugin for Panorama.
This design model describes a network topology with two central sites and multiple remote sites deployed across two regions. Remote sites have either dual connections to a public network or single connections to both a public network and a private network. All physical connections are provided through a standard Ethernet hando. You use secure fabric links to interconnect sites
with hub-and-spoke, hub-and-spoke, partial-mesh, or full-mesh f ull-mesh topologies, depending on business and scale requirements. The SD-WAN provides per-application path selection across all possible paths. For DIA trac, 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 remotenetwork connections. Where multiple connections to the public network exist, the DIA trac shares both connections to the public network. In this model, the ION devices provide an applicationapplication-aware, aware, zone-based zone-based rewall at each remote
site. In addition, Prisma Access complements the ION onon-site site capabilities and provides additional visibility and inspection for DIA trac. The ION devices also support zerozer o-touch touch provisioning and
deployment. This model separates the SD-WAN 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 trac, Access provides the exact same security, visibility, and control as next-generation rewallPrisma at the remote site.
Palo Alto Networks
75
SD-WAN Design Models
Palo Alto Networks recommends this model if you require zero-touch provisioning and deployment for your remoteremote-site site devices and pervasive security for DIA and cloud-based 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. •
PAN-OS Secure SD-WAN—This design model uses the next-generation next-generation rewall for both central-
site and remote-site locations. You connect the sites using the natively integrated SD-WAN capabilities of the next-generation next-generation rewall. 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 hando. The SD-WAN interconnects the sites in a hub-and-spoke topology and provides per-application perapplication path selection across all possible paths. Each remote site is congured for DIA, and the DIA trac shares both connections to the public network. In this model, you can also use the next-generation next-generation rewall to provide segmentation in order to reduce the scope of compliance, to limit data exltration, and to reduce the attack surface.
This model consolidates the SD-WAN functions and security functions onto a single device at remote which andinspection cost. Because a next-generation next-generat ion rewallacross is deployed at everysites, site, you canreduces providecomplexity visibility and for all users and applications every
network segment. Although you may choose between hardware appliance and virtual form-factors, form-factors, you still self-manage s elf-manage and self-deploy self -deploy the devices devi ces in this model. Palo Alto Networks Networ ks recommends rec ommends this model if pervasive security is a high priority for your organization.
CLOUDGENIX WITH PRISMA ACCESS DESIGN MODEL In this model, each site connects to the CloudGenix SD-WAN, which is the primary WAN for the organization and provides access to the headquarters and data center locations. This model assumes that the central sites are already interconnected through an existing public or private WAN connection. At all sites, site s, you must use an ION device as an on-premises device. d evice. After A fter the basic device dev ice conguration cong uration is
complete, you transition the site to control mode. One key dierence from fr om the PAN-OS Secure SD-WAN SD-WAN model is that you use Prisma Access to secure DIA trac, and each remote site connects directly to Prisma Access by using third-party third-party VPN connections.
Palo Alto Networks
76
SD-WAN Design Models
Figure 31 CloudGenix with Prisma Access design model
All aspects aspec ts of the CloudGeni CloudGenix x SD-WAN are managed through t hrough the CloudGeni CloudGenix x portal. For Prisma Prism a Access, Panorama, and Cortex™ Data Lake manage all policy and monitoring centrally, and Palo Alto Networks manages the Prisma Access infrastructure. The SD-WAN SD-WAN protects your internal user trac by using secure fabric links, which use IPSec tunnels over
the public networks toyour ensure data privacy through strong encryption. ION time devices automatically choose the best WAN path for applications based on business policy and realreal-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, public network, and a private WAN network. For device management, connect the ION I ON controller port to an existing network that has access to the internet. The device connects to the CloudGenix portal and, once online, appears as an unclaimed device. On the CloudGenix portal, for each central site, you create a site and congure the site as a data
center. You then claim the device and assign it to the site.
Palo Alto Networks
77
SD-WAN Design Models
Congure an IP address for each interface and assign a circuit label. You may use either statically assigned
or DHCP-assigned 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 congure the interfaces. Congure BGP for each device to exchange routing information with peers on the private network.
Remote-Site Devices This model deploys ION devices into new greeneld networks at remote sites.
The devices at each remote site connect to the private network and either two public networks or a public network and a private WAN network. For device management, connect the ION internet ports to the public networks. The device connects to the CloudGenix portal and, once online, appears as an unclaimed device. On the CloudGenix portal, for each remote site, you create a site and congure the site as a branch. You
then claim the device and assign it to the site. Congure an IP address for each interface and assign a circuit label. You may use either statically assigned
or DHCP-assigned DHCP-assigned IP addresses. Palo Alto Networks recommends you use a statically assigned IP address for the connection to the private network, use DHCP-assigned DHCP-assigned IP addresses for the connections to the public networks, and use a statically assigned IP address for any connection to the private WAN network. If necessary, congure BGP for each device to exchange routing information with peers on the private
network.
Interconnecting the Sites The CloudGenix portal automatically congures secure fabric links between your sites after you switch
the sites to control mode. At this time, the portal also pushes security and application policies to all sites. By default, the portal builds a hub-and-spoke topology that also supports remote-site to remote-site communication by routing through a central site. You may optionally congure direct connections
between remote sites by using secure secu re fabric fabr ic links.
Configuring SD-WAN Application Policies Palo Alto Networks recommends that you monitor your network analytics and then use the information you have collecte collected d to develop deve lop an SD-WAN application applic ation policy poli cy for your organization. org anization. In I n a browneld brown eld deployment, you have the option to rst deploy your ION devices in analytics mode, which only monitors trac. However, in a greeneld deployment, you deploy your devices in control mode. You must congure co ngure SD-WAN policies polici es to match matc h your applications ap plications and explicitly expl icitly distribute dist ribute the applicatio application n trac across the public networks and which applications to send to Prisma Access.
Palo Alto Networks
78
SD-WAN Design Models
Connecting the Remote Sites to Prisma Access The CloudGenix application policies can supersede destinationdestination-routing routing based policies. Rather than just conguring a default route to Prisma Access, you instead treat Prisma Access as a set of third-party third-party
endpoints. You then create policies that match applications and assign them to use the Prisma Access endpoints. You have two tw o options for managing manag ing the integration int egration from CloudGenix Clo udGenix SD-WAN to Prisma Pris ma Access. Access . In small-scale small-scale or prototype p rototype deployments, typically less than 5 sites, you manually manage the integration to Prisma Access by using both Panorama and the CloudGenix portal. In all other deployments, you automate the Prisma Access integration through API-based integration by using the CloudBlade for Prisma Access. This CloudBlade allows you to automatically congure the CloudGenix portal, ION I ON devices,
Panorama, and Prisma Access. Manual Configuration Option
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 r emote network ne twork connection co nnection at the location loc ation nextnext -nearest your remote re mote site. site . Note
The active/active option consumes twice the licensed bandwidth of Prisma Access because both links are congur congured ed as primary p rimary tunnels tunnels..
On the CloudGenix portal, for each remote site, you create and congure a third-party third-party VPN from the
interface to the nearest Prisma Access location. If you are using an active/active connection, you create and congure an additional third-party third-party VPN from that interface to the next nearest Prisma Access
location. After you y ou create creat e the third-party thir d-party VPN connections, conn ections, you then use u se the CloudGenix Clo udGenix portal p ortal to congure c ongure the
associated SD-WAN policy to direct internet and cloud-based applications to Prisma Access. You must also congure security policy rules on Prisma Access for the associated applications. CloudBlade Configuration Option
The CloudBlade for Prisma Access automates the third-party VPN components of the manual conguration option, which makes this option highly-scalable. highly-scalable. This option requires that you deploy either
an on-premises on-premises Docker container or a publicpublic-cloud cloud container to facilitate the communication between the CloudBlade for Prisma Access and Panorama. On the CloudGenix portal, you also need to apply Prisma Access tags t ags to remote rem ote sites site s to identify ident ify the site s ite for the CloudBlade. CloudB lade. To specify s pecify the Prisma Access region r egion nearest the site and specify which interfaces to connect to Prisma Access, you apply region-specic region-specic
Prisma Access tags to remoteremote-site site device interfaces. The CloudBlade orchestrates both the thirdthird-party party VPN conguration con guration and the Prisma Access onboarding. o nboarding.
Palo Alto Networks
79
SD-WAN Design Models
After you y ou use the CloudBlade to create creat e the third-party thir d-party VPN connections, connec tions, you yo u then use the CloudGenix CloudG enix portal to congure the associated SD-WAN policy to direct internet and cloud-based applications to Prisma Access. You must also congure security policy rules on Prisma Access for the associated
applications.
PANOS SECURE SDWAN DESIGN MODEL In this model, each site connects to the SD-WAN, SD-WAN, which is the private WAN for the organization and provides access to the headquarters and data center locations. This model assumes that the central sites are already interconnected through an existing public or private WAN connection. The SD-WAN provides two key functions in this design model: Interconnection between central sites and remote sites by using VPN VIFs and IPSec tunnels
•
Direct internet access from remote sites by using DIA VIFs
•
Figure 32 PAN-OS Secure SD-WAN design model
The SD-WAN SD-WAN protects your internal user trac by using VPN VIFs that provide intelligent path control
with perper -applicati application on path selection. se lection. The IPSec IPSe c tunnels over the public networks ne tworks ensure e nsure data privacy through strong encryption. The SD-WAN also provides per-application path selection and load sharing for public network trac. At all locations, loca tions, the next-generation rewall r ewall provides pr ovides full f ull visibility of the users, us ers, applications, app lications, and a nd content conten t for all network trac. At your remote sites, you can also use the next-generation next-generation rewall to reduce the
attack surface through segmentation.
Palo Alto Networks
80
SD-WAN Design Models
In this model, you use next-generation rewalls as SD-WAN devices at both the central-site and remotesite locations. You use Panorama to centrally congure, manage, and monitor the SD-WAN. SD-WAN. Each device is rst 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 in Figure 32) 32) security infrastructure devices provide internet access at the central sites.
Central-Site Devices This model integrates SD-WAN SD-WAN hub devices into the existing networks at central sites. For device management, connect the management port to an existing e xisting network that has access to Panorama. At the central ce ntral sites, site s, you congure co ngure each e ach SD-WAN device as a hub. The devices at each site si te connect conne ct to the
private network and two public networks. On the interfaces that connect to the public networks, you should use public IP addresses with static address assignment, and each interface must have a Next Hop Gateway. If you use private IP addresses to connect to public networks, you must congure static NAT entries to map the public IP addresses to the private IP addresses on your devices. Congure 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 prexes or summary prexes, when adding addin g the device dev ice to the SD-WAN plugin. If you y ou want to enable remote-site r emote-site to remote-site re mote-site trac, choose one of your central sites to be a transit site and include the remote-site remote-site summary prexes in the prex list for the transit-site transit-site device. The SD-WAN SD-WAN devices at the central sites each use BGP to advertise their prex 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 congure an SD-WAN SD-WAN policy at that site. Note SD-WAN policies apply only to a single SD-W SD -WAN AN routing hop and are eective to control site-to-site site-to-site ows such as “remote-site to central-site” or “central-
site to remote-site”. To control site-to-site site-to-site ows such as remote-site to central-site to remotesite, you must apply SD-WAN policies that match the ow at both the remote-
site and the central-site.
Palo Alto Networks
81
SD-WAN Design Models
Remote-Site Devices This model consolidates the SD-WAN functions and security functions onto a single device, which reduces complexity and cost. Because a nextnext-generation generation rewall is deployed at every site, you can provide
visibility and inspection for all users and applications across every network segment. At the remote re mote sites, site s, you congure c ongure each e ach SD-WAN device as a s a branch. The devices devic es at each eac h site connect con nect 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 congure 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 SD-WAN hubs devices at the central sites. If you have additional prexes to add, specify them in a prex 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 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 SD-WAN policy, you only need to congure 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 conguration. You must include a PQP for the SD-WAN SD-WAN policies that control your DIA trac,
even though the DIA VIF does not perform end-to-end end-to-end path monitoring. The DIA VIF inherits the path monitoring state of the IPSec tunnels sourced from member interfaces. To support DIA trac, you must congure 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 trac from the zone-private zone to a public interface IP address. Additionally, Additionally, you must create the
required security policy rules to permit per mit applications to access the zone-public zone-public zone. If required, create multiple private security zones to provide segmentation at the remote r emote site. This approach allows you to partition the network into manageable, secure segments, which reduces the scope of compliance and limits data exltration. Create the required security policy rules to permit applications
to and from each additional security zone. Figure 33 Remote-site segmentat segmentation ion
Palo Alto Networks
82
SD-WAN Design Models
Interconnecting the Sites The SD-WAN plugin builds the VPN tunnels between sites. You must have at least one SD-WAN hub device at a central site and at least one SD-WAN branch device at a remote site. The SD-WAN plugin generates a conguration that builds an overlay network for the public network and for each type of private network
in your organization. If any SD-WAN device has multiple interfaces that connect to the same overlay network, then a full-mesh of VPN tunnels is created between the central site and the remote site for that overlay network. In this model, all of the sites are in a single logical region. You congure 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-specic application performance and link-performance statistics. After you y ou complete comple te the AutoVPN A utoVPN process pr ocess and push the plugin-generated p lugin-generated conguration, co nguration, the SD-WAN
remote-site devices initiate IPSec connections to the central sites and begin to apply the SD-WAN policies pushed from Panorama.
Configure SD-WAN Application Policies Palo Alto Networks recommends that you monitor your network trac and then use the information
you have collecte collected d to develop deve lop an SD-WAN application applica tion policy polic y for your y our organization. organ ization. In I n the absence abse nce of any a ny congured policies, trac ows across the SD-WAN by using traditional routing along with round-robin
load sharing. You must congure co ngure SD-WAN policies polici es to match matc h your applications ap plications and explicitly expl icitly distribute dist ribute the applicatio application n trac across the public networks. You build these policies and apply them to the SDSD-WAN WAN devices at the source sites. Because you use Panorama templates to congure these policies, you must create separate
policies for each Panorama device group—one set of policies for central-site central-site devices and another set of policies for remoteremote-site site devices.
Palo Alto Networks
83
Summary
Summary Palo Alto Networks provides organizations with several options for deploying SDSD-WAN. WAN. In addition to a broad WAN overview o verview,, this guide covere covered d the technical te chnical aspects asp ects of CloudGenix SD-WAN and PAN-OS Secure SD-WAN in-depth and described the methods for integrating CloudGenix with Prisma Access. You can
use this guide to determine which oering is most eective in meeting the business requirements of your
organization. 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 trac ows to central sites, cloud-based cloud-based applications and the internet.
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 benet from f rom the comprehe comprehensive nsive security se curity features f eatures of o f the next-generation ne xt-generation rewall. re wall. You can c an provide provid e visibility and inspection for all users and applications across every network segment, including trac ows to central sites, cloud-based cloud-based applications, and the internet.
With either design model, mod el, your organizati organization on can achieve ach ieve consistent con sistent security, se curity, regardless r egardless of location. locati on.
Palo Alto Networks
84
You can use the feedback form to send comments about this guide.
HEADQUARTERS Palo Alto Networks 3000 Tannery Way Santa Clara, CA 95054, USA
Phone: +1 (408) 753-4000 Sales: +1 (866) 320-4788 Fax: +1 (408) 753-4001
http://www.paloaltonetworks.com
[email protected]
© 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-20b
