Prisma SDWAN Best Practices

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
L4 Transporter
100% helpful (3/3)

Fig 1_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Prisma SDWAN 

Best Practices

Version  1.0

Date: May 2, 2024

 

Contributors

John Tzortzakakis
Sunil Cherukuri
Richard Gallagher
Mukhtiar Shaikh
Gary Matteson
Tanushree Kamath

 

 

Reading this guide

In this document a “Best Practice” is marked with a Star like the following example. The remainder text is for explaining the rationale and for extra information.

 

Fig 2_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

 

 

 

 

 

 

Fig 3_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

 

 

 

Introduction 

Access and Authorization 

Prisma SD-WAN Portal Access (Strata Cloud Manager) 

Accessing the ION Devices 

Tenant Access using APIs 

Strata Cloud Manager 

Legacy Prisma SD-WAN 

Tenants migrated to Strata Cloud Manager from Legacy SD-WAN Controller 

Connecting IONs to the SD-WAN controller 

Sites 

Create Sites (Branches) 

Create Sites (DC Sites) 

Interface Settings 

WAN Networks 

Circuit Settings 

High Availability Settings  

ION Software Upgrade 

Cloudblades  

VPNs and GRE Tunnels  

Policies 

Generic

Path policy

Defaults and Paths  

DC Group for Transit Traffic  

Prisma SD-WAN (CloudGenix) Control Apps in Policy 

QoS Policy

NAT Policy 

Security Policy (ZBFW) 

Performance Policy 

Routing 

Static Default Route 

BGP Peer Authentication 

BGP Edge Peer 

Multicast 

Network Management 

Network Time Protocol 

Syslog 

Simple Network Management Protocol (SNMP) 

IPFIX  

Public Cloud Deployment 

AWS Deployments 

Azure Deployments 

 

 

Introduction

 

This guide captures Prisma SD-WAN Best Practices in a form of product settings, configurations, procedures that have been shown by experience to produce optimal results and that can be established or proposed suitable for widespread adoption.

 

This document describes the administrator's tasks, actions, and guidelines for deploying Prisma SD-WAN. It is not a training or configuration guide nor replaces the product documentation or professional services recommendations.

 

Architecture Overview

The Prisma SD-WAN architecture comprises a cloud-based SaaS controller and multiple ION data plane endpoints deployed at customer sites. Distinct from conventional networking devices like routers and switches, ION devices are centrally managed and orchestrated via the controller, which serves as the single source of truth and definitive authority for policy configuration, network topology, etc. The Prisma SD-WAN Controller provides an interactive graphical user interface to securely configure, provision, monitor, and troubleshoot the network. 

 

See more at Prisma SD-WAN Security Architecture - Palo Alto Networks

 

ION Devices

The Prisma SD-WAN ION devices are responsible for handling data plane traffic. Before integrating into the network fabric and receiving policy configurations from the SaaS controller, each ION device must undergo an authentication and authorization process. This is achieved by using digital certificates to establish the initial secure TLS connection with the controller. The ION devices relay anonymized network and application metadata back to the controller through the secure TLS connection. The metadata include metrics such as bytes transferred, link capacity, voice MOS score, transaction error rate, transaction time, event notifications, alerts, alarms, etc. Note also that customer data traffic  is never sent to the controller. 

 

Find more in ION Datasheet

 

Simplified Management and Operations

The Prisma SD-WAN solution is shipped by default with numerous configuration and security best practices. For example, all public-facing WAN interfaces are fortified by default, disallowing any external inbound connections, thus enhancing network security. Features like VPN tunnel configurations, tunnel IP addressing, encryption profiles, and route propagation throughout the network fabric are automated, embedding best practices, thus eliminating the need for manual setup. The automatic generation of appropriate route maps while configuring the hub BGP core and edge peers further strengthens the integrity of the BGP routing domain, protecting it from potential routing issues. 

 

For more information visit the Prisma SD-WAN Documentation page

 

Access and Authorization

 

Prisma SD-WAN Portal Access (Strata Cloud Manager)

Use Chrome Browser as your preferred browser  Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.png

Although all popular browsers are supported the Chrome browser is the defacto browser that the Prisma SD-WAN QA team tests thoroughly. 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse SAML for logging in to the Prisma SD-WAN portal. Enable Role-Based Access Control (RBAC) for  granular access control specific to admin’s roles.

The Prisma SD-WAN Strata Cloud Manager (SCM) can be accessed using a locally created tenant account or SAML-based (Security Assertion Markup Language) authentication. Integrate the SCM portal access with an enterprise authentication system or known federated identity management solutions like OKTA, PingID, etc. The authentication system may be enhanced for stronger multi-factor authentication (MFA). SAML allows customer-specific authentication and authorization schemes to allow granular user access or deny access to the SCM SD-WAN instance at the tenant level. Prisma SD-WAN supports SAML 2.0-compliant IdP authorities, including ADFS, Okta, PingFederate, and Salesforce. 

 

Role Mapping and desired permissions are critical to the SAML-enabled authorization process. Before a user can access the Prisma SD-WAN as an authorized user, the role must be mapped to a Prisma SD-WAN role in the system. Through role mapping, user group memberships, as defined in the customer’s IdP system, will be mapped to Prisma SD-WAN authorized roles so that specific access can be granted to users at different levels.

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngWhen using local accounts, make sure you have the account and password setup in the Palo Alto Customer Support Portal https://support/paloaltonetworks.com 

 

Accessing the ION Devices

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngThe admin must create individual user accounts and maintain Role-Based Access Control (RBAC) for Superuser, Read-only, and Monitor roles.

 

All ION devices are shipped with the default username (elem-admin) and password. This password is changed to a randomized string when the device is claimed in the SCM portal. It is recommended that these login passwords be rotated every 60 or 90 days, depending on the customer’s info-sec policy. As a generic guideline, prefer to access the ION device with the portal UI option (ION Device Toolkit) over direct CLI access.

 

A limited number of configuration commands may be done on the ION devices directly, like Interface configs - IP, Speed/Duplex, Control Plane ciphers, etc. In the case of CLI access,  the only option is the SSHv2 method (Telnet access is not supported). The ION can accept SSH connections by using a direct IP method or remote access from the portal. The remote access from the portal will log the entries and timestamps for audit purposes. It is recommended to use the Remote Access method, which uses SSH over the TLS connection where the device is online. If the device is offline, direct SSH over IP method can be used as a fallback. By default, the IPs of public circuits will not allow a direct SSH to the device due to security reasons. 

 

Prisma SD-WAN systems use strong password authentication checks (avoiding weaker passwords) as a best practice. Note that portal UI configuration overwrites CLI commands.

 

Tenant Access Using APIs

Prisma SD-WAN’s RESTful architecture provides an ability to completely manage and control your network through automation. The instructions and APIs differ depending on the management platform being used: Strata CloudManger or the Legacy Prisma SD-WAN Management portal.

 

Strata Cloud Manager

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngCreate a Service Account for authentication purposes

Customers using Strata Cloud Manager to manage their Prisma SD-WAN network need to create a Service Account for authentication purposes. Strata Cloud Manager uses the OAuth2 standard of authentication. A service account first needs to be created using the Identity & Access Management menu.

 

Fig 5_Prisma-SDWAN-Best Practices_palo-alto-networks.png

Fig 6_Prisma-SDWAN-Best Practices_palo-alto-networks.png

The service account needs to be granted appropriate roles and access to the applications and services that you intend to manage using APIs.

 

Fig 7_Prisma-SDWAN-Best Practices_palo-alto-networks.png

Fig 8_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Once the service account with the appropriate roles is created, the client ID and client secret are used to generate the short-lived (15 minutes) JSON Web Token (JWT) which is used to authenticate the HTTPS request. This JWT is embedded as a Bearer token in the HTTPS header. Since the tokens are short-lived, they need to be renewed prior to expiration for a seamless RESTful transaction. More details on the Service Account can be found here https://pan.dev/sase/docs/service-accounts/

 

Legacy Prisma SD-WAN

Customers using the legacy Prisma SD-WAN controller to manage their Prisma SD-WAN network need to create an Authentication Token for authentication purposes. Before creating the auth token, it is important to understand the following security measure available in Prisma SD-WAN by default. 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDisable IP Session Lock for the users creating auth tokens

All user profiles have IP Session Lock enabled by default. When an auth token is created, these properties are inherited by the token as well. This means when an auth token is generated, the client IP is bound to the token as the IP Session Lock is enabled. Any API request originating from a session IP that doesn’t match the client IP at creation will be rejected. If the end user intends to use the auth token on a VM, a cloud environment or intends to share it to a different user in the monitoring group, it is recommended you set IP Session Lock to disabled or configure the appropriate prefixes that need to be allowed on the User Profile.

 

To disable IP Session Lock, go to System -> Access Management -> User Access -> User Management menu.

Fig 9_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Look for your user profile, click on edit and set IP Session Lock to disabled prior to creating the authentication token.

 

Fig 10_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngCreate an Authentication Token

To create an Authentication Token,  go to System -> Access Management -> Tenant Access -> Auth Tokens menu.

Fig 11_Prisma-SDWAN-Best Practices_palo-alto-networks.png

When creating an auth token, specify an appropriate role and expiry to enforce password rotation based on the enterprise's info-sec policy.

Fig 12_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDo not use username/password authentication

Do not use username/password authentication for automation when leveraging the legacy API’s Prisma SD-WAN API’s (https://pan.dev/sdwan/api/legacy/).

 

Tenants Migrated to Strata Cloud Manager From Legacy SD-WAN Controller

Tenants that were migrated to Strata Cloud Manager from the Legacy Prisma SD-WAN Controller, will have access to both sets of APIs and authentication mechanisms. It is recommended you migrate to using the auth token for authentication instead of username/password as the login API endpoint will be deprecated after migration to Strata Cloud Manager.

 

When an auth token is created, the user profile’s properties are inherited by the token as well. This means when an auth token is generated and the user profile has the IP Session Lock is enabled, the client IP is bound to the token. Any API request originating from a session IP that doesn’t match the client IP at creation will be rejected. If the end user intends to use the auth token on a VM, a cloud environment or intends to share it to a different user in the monitoring group, it is recommended you set IP Session Lock to disabled. 

 

To manage IP Session Lock Settings, go to  Manage -> Prisma SD-WAN -> Access Management -> Tenant Access -> Auth Token Session Lock.

Fig 13_Prisma-SDWAN-Best Practices_palo-alto-networks.png

Look for your email, click on edit and set IP Session Lock to disabled prior to creating the authentication token.

 

Fig 14_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

To create an authentication token to continue using tools, utilities and scripts written using Legacy Prisma SD-WAN APIs, go to Manage -> Prisma SD-WAN -> Access Management -> Tenant Access -> Auth Tokens

Fig 15_Prisma-SDWAN-Best Practices_palo-alto-networks.pngNote:

  1. API requests from tenants using Strata Cloud Manager are sent to the SASE API gateway endpoint https://api.sase.paloaltonetworks.com. This endpoint uses OAuth2 authentication and authorization standard.
  2. API requests from tenants using the Legacy Prisma SD-WAN management console are sent to the Prisma SD-WAN controller endpoint https://api.<region>.cloudgenix.com. This endpoint uses the auth token  for authentication and authorization.
  3. Tenants migrated to Strata Cloud Manager from the Legacy Prisma SD-WAN Controller have access to both sets of APIs. Their appropriate authentication and authorization mechanism needs to be followed when accessing these endpoints.

 

Connecting IONs to the SD-WAN controller

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngConnect the controller, Port1, or Internet1 port to a DHCP-enabled network to access the SD-WAN service over the Internet. 

 

To claim an ION device, it must be powered on and connected to Prisma SD-WAN service.  The ION must be able to connect to the Internet and have a DNS server configured. By default, the controller port of any ION is set for DHCP and is the preferred port.   Other ports that may be used in DHCP mode “out-of-the-box” depend on the device model. If the ION does not have a dedicated controller interface, use Port1 or Internet1.  

 

The following ION models table lists the interfaces shipped with DHCP enabled. The last column are the ports that can be used to connect to internet and initiate the Zero Touch Provisioning (ZTP) service:

 

ION Model

Controller Ports

(default)

DHCP enabled Interfaces (default) Ports that can be used as Internet (default)

ION 1000

N

1-4 (All)

1-2

ION 1200

N

1-4 (All)

All

ION 2000

Y

2-3

1-5

ION 3000

Controller-1 

(2 ports)

Internet 1-2

Internet 1-4

ION3200

N

1-8 (All)

1-2

ION5200

N

1 - 22 (All)

1-2

ION7000

Controller-1 

(2 ports)

Controller-1 & 2

1-2

ION 9000

Controller-1 

(2 ports)

Controller-1 & 2

1-2

ION9200

N

1 - 22 (All)

1-2

 

 

The Online-Restricted device status under the Unclaimed Devices list determines a successful connection to the SD-WAN service.

 

Fig 16_Prisma-SDWAN-Best Practices_palo-alto-networks.png

If DHCP is not enabled at a site,  you must use the console cable to connect to the ION console port and configure a static IP address, DNS and IP gateway through the CLI: Assign a Static IP Address Using the Console

 

The device status will also stay offline if the SD-WAN controller port 443 is unreachable. See more at  Allow IP Addresses in Firewall Configuration

 

Note that in the case of the On-Premises Controller deployment, you must  follow  the guide for  ZTP Service to Connect ION Device to On-Premises Controller.

 

Sites 

 

Create Sites (Branches)

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse the naming convention and use the address search.

With naming conventions, you can search and locate the Branch by its name on the list views. The site address search returns the latitude and longitude and correctly positions the site on the map. Sites without addresses appear in the middle of the map on the Atlantic Ocean.

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse an existing site configuration to create a template for large scale Day1 deployments 

Create a site with all essential configurations and validate its functionality. After the site is operational, this site can serve as a foundation for a site template. Importing a site template involves downloading previously utilized templates, adjusting them as per your requirements, and then re-importing the updated versions. 

 

Create Sites (DC Sites)

Configure Site-level prefixes for DC SitesFig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.png

Always configure the site-level prefixes for DC Sites (this is not required for Branch sites). A Branch can use all DC’s for transit traffic (to unknown private or public prefixes) and pick a DC based on the DC Groups in the Path Policy. To send traffic to prefixes inside a DC, we need to configure DC Site-level Prefixes. A Branch will then send traffic to that prefix to the specific DC.

 

 

 

Fig 17_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Interface Settings 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngSet the Speed and Duplex to “Auto,” which is the default configuration setting for every port.

In steady-state conditions, all interfaces on the ION devices should run clean without any drops or errors. Interface-level errors can trigger an undesired chain of events, causing performance issues and destabilizing the network. Determining the root cause of the interface of errors can be tricky. Some of the common reasons for interface errors are misconfiguration or speed and duplex, wrong or bad cable and/or bursty traffic conditions, etc. 

 

One common reason for interface-level errors is a speed and duplex mismatch. This usually results in CRC errors or drops. Prisma SD-WAN ION devices support both auto and hard-coded speed and duplex sensing. If interface errors are observed, ensure that the correct speed/duplex is configured.  

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngConfigure one or more DNS servers per interface.

Configure DNS (either external or internal, depending on the setup) under each interface. Since DNS is UDP-based, failure to reach a DNS server can result in a blackout, therefore configure multiple DNS servers for resiliency.

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUpgrade to the recommended Cellular model firmware

On the Cellular interface (cwan), the Firmware page displays the current firmwares available on the modem and the current recommended firmware and version. Upgrade the firmware when the recommended version is different from the current version for your specific carrier. The ION device downloads the new firmware from controller inventory and then upgrades the carrier firmware on the modem.

 

 

Fig 18_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDC ION Core (LAN) interface

On the DC ION Core (LAN side) facing interface, there is no need to configure a circuit label if there is no need to build any Standard VPN tunnels from this LAN interface. In this case, you also do not need to configure the default gateway on this interface, since the next-hop reachability is via BGP. The Core BGP peer provides reachability information on the LAN side to the DC ION. In case BGP is not used (DC IONs not in HA setup), you will need a static default route on the DC ION.

 

Fig 19_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

WAN Networks 

In Prisma SD-WAN, a WAN network is a reference to your service provider viz. AT&T, Verizon, Comcast, BT, etc. Service Providers you subscribe to for Internet access need to be defined under Internet Circuits.

Fig 20_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Similarly, Service Providers you subscribe to for MPLS or Private WAN access need to be  defined under Private WAN Circuits.

Fig 21_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDefine all the providers across your entire estate, and use these references when defining your circuits

First define all the providers across your entire estate, and use these references when defining your circuits (review section on Circuit Settings). This is important as it helps Prisma SD-WAN correlate incidents and performance degradation across different circuits and associate it with a specific service provider. Not having a consistent reference for a provider, may result in multiple incidents and inadequate correlation as the provider name is used as a key for correlation. 

 

Circuit Settings

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngProvide a meaningful name of the WAN circuit

When configuring the site-level circuit details, a default name is pre-populated. It is recommended that you provide a meaningful circuit name, which will help troubleshoot path-related flow details.

Use abbreviations that include Site Name, Circuit Type, and Circuit ProviderFig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.png

As an example, a site in Chicago that has 1 Verizon ISP and 1 ATT MPLS circuit, the circuit labels can be named as “CHI-INET-VZN” and “CHI-MPLS-ATT”. Similarly a DC site in New York can have the circuit labels “NYC-DC-INET-VZN” and “NYC-DC-MPLS-ATT”. When looking at flow browser details, the path taken (to which destination site and which circuits) will be easy to observe.Fig 22_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

 

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngAdd description and tags

Customers must add comments to configure a device, such as a site description, port labeling, and tags. The tags and descriptions help identify what the port is used for, and tags can also be used for automation purposes

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDo not change the default BFD mode

Aggressive mode is the default mode and is recommended by Prisma SD-WAN for fast failure detection of links.

 

 

Hard code the Circuit speed settingsFig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.png

Circuit speed hardcoding will prevent a port from being negotiated into a sub-optimal setting. The WAN circuit speeds must be matched with carrier-provided specifications and specifically configured. The default values should not be trusted.

 

It is recommended to use a slightly lower value (1-2 %) for the Download/Upload BW on the circuit, from the values given by the Provider. This is to ensure that the ION QoS kicks in slightly before the circuit limit is reached, so as to ensure prioritization of the critical applications. For example, if the circuit is rated for 100M down, 50M up, you can configure the circuit settings for 99M down, 49M up. This ensures that the ION QoS starts kicking in at 99M down, 49M up and starts prioritizing applications according to the configured QoS policies.Fig 23_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngAlways Select “Minimize Cellular Usage”

Fig 24_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Minimize the data usage of metered 5G/LTE backup links when other active paths are unavailable. With this best practice, you send data over metered links for business continuity only when the primary connection is unavailable, ensuring flexibility and agility at a lower cost.

 

By extending the VPN keepalive timer this will reduce the amount of data used on this cellular carrier, but by extending this timer it can reduce the failover time if the ION moves from using one DC ION to another DC ION in the DC Cluster. 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse separate Circuit Categories per Circuit

When Creating a circuit, you must select a circuit category and a WAN (Carrier). You CANNOT use the same category twice at a site.  

 

For example, you cannot designate two Internet Cable circuits at a site even if they are from different carriers. This is because the circuit category defines the Circuit Label and is used in path policy.  Having two circuits at a site with Ethernet Internet as the circuit category would not allow you to differentiate between those circuits in a path policy. There are 30 Internet categories and 30 public categories, including ~ 20 named public or Private.  These names can be changed,  so often, two or more circuit categories may be modified to a convention, such as ACME-INTERNET-1 and ACME-INTERNET-2.

 

Fig 25_Prisma-SDWAN-Best Practices_palo-alto-networks.png

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngPrivate circuits, WAN Networks need to match at the branch and data center 

Fig 26_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

If a path policy requires the use of Overlay over a Private path (e.g., MPLS), make sure the WAN network matches at the branch site and data center. On the data center side, there could be multiple MPLS circuits from different carriers. Each carrier will have its own WAN network assigned. So, to make sure connectivity comes over the correct carrier circuit, the WAN network needs to match; otherwise, the VPN status won’t come up. 

 

High Availability Settings

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngTerminate the WAN circuit connections on each ION when using Branch HA

In HA deployments, the customer is expected to have two circuits. The circuits must be terminated directly on each of both devices and indirectly through the Hardware Fail to Wire interface. This setup is particularly helpful when performing RMA on any one of the devices and ensures the site has at least one circuit available on the remaining device to handle the traffic seamlessly.

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngConnect the HA control interface on the same subnet and use static IP addresses 

DHCP IP address allocation can take longer resulting in longer switchover time. When using the site in Branch HA mode, make sure the interface IP is not DHCP enabled and it is statically configured. This is necessary to avoid situations when the DHCP server is not local and is not able to reach it.  This can cause instability in the HA states and can get unpredictable.

 

Directly establishing the High Availability (HA) connection between devices is preferred only in cases where there are no southbound LAN switches present and exclusively only with 1200-S and 3200-L2 models with redundant ports.

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngPerform a health check of a LAN interface for a proper failover (interface tracking).Fig 27_Prisma-SDWAN-Best Practices_palo-alto-networks.png

The interface tracking of a LAN interface depends on the design. Each device will automatically track the state of the HA-control interface. Upon a failure of the interface, the device will immediately transition to a failed state, giving way to the other device in the HA group to become active. In addition, an administrator can optionally configure up to four non-HA control interfaces to track, and for each interface that goes down, the HA priority of the device will be reduced by the configured value.

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngSet a minimum priority difference of at least 40 between an active and a backup ION device

Priority is assigned to devices to dictate preference during election. For example, certain topologies may require that a particular device be active while the other remains as a backup device. In such cases, an administrator can assign a higher priority to the device with higher preference to dictate which device becomes active during election, with the highest priority being 255.  In the event of a process crash, each non-critical process will decrement the priority by 25 while a critical process will decrement the priority by 255.

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngSet Preempt “Advertisement Interval” to 1 sec

The Advertisement Interval indicates how often the active device advertises its status to the backup. Three consecutive missed advertisements indicate that the active device has failed after which a backup device becomes active and takes over as the active device.

 

ION Software Upgrade

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDownload the ION software in advance before upgrading it.

Before performing the software upgrade, it is important to download the software properly. You should download the software first and then perform the upgrade during a change window. That will ensure the code is already downloaded and minimize the downtime. 

 

Cloudblades

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse Cloudblades for simplifying integration with Cloud Service Providers and SSE vendors connectivity.

For a streamlined autoconfiguration of IPSec or GRE tunnels, explore the available options provided by CloudBlade. If Cloudblade integration exists avoid using manual configs due to the risk of  misconfiguration and extra troubleshooting effort.

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDO NOT ever change Cloudblade generated auto-configs on either ends

The CloudBlades are designed to be the source of any configuration settings they manage. 

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse device level zone binding and make sure that all interfaces participate / have zones applied.

 If a zone or device is not bound to an interface or subnet, it blocks all the traffic.

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDo not manually change Cloudblades configurations or disable/enable them

In general it is not advisable to set the state of  any Cloudblade to “Disabled”  unless you want to offboard the specific integration you have enabled via the Cloudblade. For most situations if you need to stop further changes by the cloudblade you should only use the “Paused” state. 

 

If you do wish to gracefully offboard the specific Cloudblade then you should use the “Disabled” state and after some period of time “Uninstall”, please refer to the specific Cloudblade Integration guide for more details.

 

Note that there is a configuration convergence time period in each case.

 

VPNs and GRE Tunnels

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngSet GRE keep-alive to enabled

GRE tunnels are stateless by design, the GRE tunnel is established when the standard VPN interface is created, and the parent interface is up. With the GRE keep-alive enabled or having a liveness probe configured on the standard VPN endpoint such that a failure can be detected and avoid traffic being black-holed.

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngApply a Zone Based Firewall Policy to any traffic using GRE for transport over an insecure transport (Internet)

Prisma SD-WAN supports Generic Routing Encapsulation (GRE) tunnels from branch or data center sites to standard VPN endpoints to integrate with cloud security services. Due to the insecure nature of GRE consider protecting the site with ZBFW policy. As an additional measure, consider the implementation of a NAT policy. With NAT you hide the internal addressing scheme being visible over GRE and can significantly decrease the attack vector.

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse manual Standard VPN (IPSec or GRE) as last resort and only if Cloudblade integration is not available. 

When using an internet WAN, you can manually configure an IPSec or GRE tunnel to enable direct traffic flow between Prisma SD- WAN branch sites and non-Prisma SD-WAN sites.

 

Policies

 

Generic

Prisma SD-WAN provides two types of Policies - Simple and Advanced - for the Path, QoS, NAT, Security and Performance. Always consider starting with Simple policies, as this simplifies the policy management. 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngStart with Simple policies and move to advanced as you go

You may use the Advanced Policies in complex deployments where many variations of policies are needed for different SItes, or need to use inheritance and overloading of policies. With Advanced Policies, you can create Policy Sets and Policy Stacks which provide you more flexibility in grouping policy sets and rules, but can become complex.

 

Path Policy

Defaults and Paths

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.png“Default” simple path policies generally work “right out of the box” 

Paths for default rules should be modified according to the customer environment,  e.g. Paths should not reference “Any Private”  or specific private categories if they are dual internet sites i.e public wan.

DO NOT configure metered cellular services into the default or enterprise default rules. Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.png

Configure 4g/5g as a path of last resort in path policies, any traffic could be passed over those paths, including non-critical business applications or non-productive Internet traffic, like YouTube, Facebook or Spotify.  This could result in unplanned billing events

Policy Example of a Branch Site with MPLS, Internet and LTE for backup. Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.png

Each location should have a primary and secondary data center.

  • Generic Internet Bound traffic should be sent to the data center first for inspection, should go direct if the secure fabric is not working and should not utilize the LTE circuit.
  • Generic enterprise traffic should use any overlay to get to the data center, and can use LTE if there is no other path available
  • Voice traffic should prefer the MPLS path, and only use internet overlay if there are performance issues, or the LTE if no other path is available.
  • SaaS applications traffic like Salesforce and Office 365 Apps should use Internet and MPLS overlays,  direct internet if there is performance degradation and LTE if there is  no other path available.
  • Video conference traffic Zoom and Webex can utilize direct internet and can use the MPLS overlay if there is performance degradation.

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse the two default rules provided in the Path and QoS policies.

Each policy (Path and Qos) is configured with two default rules, a “Default”, used for internet bound traffic and an “Enterprise-Default”, used for all traffic destined to RFC1918 (private) address space. There is no need typically to configure additional rules that match ALL (internet or enterprise) traffic.

 

DC Group for Transit Traffic

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngEnsure traffic deterministically comes to the main DC only and uses the secondary DC as a backup.

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngConfigure DC groups If any path policy uses the DC as a transit point (e.g. shadow DCs, Internet Backhaul, Carrier Co-location Facilities)

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngCreate DC groups and domains If multiple DCs exist, and make sure all branches are in specific domains.

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngConfigure summarized DC prefixes at the site level, If traffic is destined to the DC where hub devices are located. 

 

Prisma SD-WAN (CloudGenix) Control Apps in Policy

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngConfigure Prisma SD-WAN (CloudGenix) Control Apps in a specific rule with higher priority than the default rule, and allow on all paths under the path policy.

This will ensure the device-to-controller connectivity and App health probing works without any interruption. 

 

If some of these paths have security appliances that are doing SSL decrypt in the path, then these paths should be excluded, or the Prisma SD-WAN controller FQDN/IPs are excluded as per the following document: Allow IP Addresses in Firewall Configuration

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse a control port or ION’s built-in controller port to send Application probes

Validate that Application Probing is configured. The ION cannot validate App reachability over different paths (end to end) without application probing and will use its controller port by default. ION devices need to designate one port as a control 

port to support application probing. A LAN port should be used for application probing if the ION controller port is connected to Out-Of-Band management. 

 

QoS Policy

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngApp Categories don’t matter - Transfer (traffic) Types do matter

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngCreating a custom application does not automatically assign it to a priority

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngCreating a customer application DOES automatically assign it to a Queuing mechanism

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngIf you want an application to have a non-default priority, add it to your QoS Policy

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse Flow browser to determine QoS policy used

 

NAT Policy 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngFor user-to-Internet traffic the default NAT Policy works.

A default Internet NAT rule is applied to all branches for supporting the outbound traffic from Enterprise to Global prefixes 

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDisable ALG (Application Layer Gateway) for all traffic destined to UCaaS system via SIP (Session Initiation Protocol)

UCaaS systems require that network solution providers disable the SIP ALG (Application Layer Gateway) for any traffic that crosses a NAT boundary destined for a SIP provider. The SIP traffic (via Path Policy) utilizes the internet link directly. As such, it uses the default NAT policy. Most of the UCaaS providers specified to disable SIP ALG. 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngWhen required to change ALG behavior, create a new Policy Set Stack. 

Once created, add the Default-NATPolicySet to the stack, then create a new NAT Set with a rule that disables ALG and bind it to the new NAT Set to the new NAT Stack.

 

Security Policy (ZBFW)

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse device level zone binding and make sure that all interfaces participate / have zones applied.  If a zone or device is not bound to an interface or subnet, it blocks all the traffic.

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngAvoid using both device and site level binding at the same time. If a site has both site-level bindings and device-level bindings, the two settings’ resulting configuration is united. In the event of a conflict between site-level bindings and device- level bindings, device-level bindings take precedence

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngCreate an explicit rule for traffic leaving and entering the site from anywhere, including the internet and / or WAN.

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse descriptive naming conventions. Add in the Description field the date and created by information

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngRule order matters (top-down process)

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngAvoid mixing in same rule application matching with port based traffic matching. It makes the management and tracking easier. 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngInbound rules require a NAT Policy

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngFor each rule use the “Monitor Rule” and Flow browser for validating a ZBFW policy

 

Performance Policy

Performance Policy provides a flexible framework for the assurance of Application and Network SLAs. 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngSimple Policy Sets: Use simple policy stacks unless the modular flexibility of advanced stacks is required.

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngRule Order: More specific (app match, path match, DC Group, etc) rules must be placed at the top of the policy set and less specific rules at the bottom. Performance Policy uses an explicit order and any match field left empty will be considered a match all.

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngPolicy Rule Configuration Limits: Each ION device model varies in system resources depending on the targeted use case for the appliance. 

* For Performance Policy there are two important metrics to consider; the total number of rules and the number of specific application IDs that match per rule. 

* Multiply the total number of rules by the total number of application IDs matched, and check this against the policy rule config limits for the ION platform being used. The limits can be obtained from the Field Sizing Guide

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngFunctional Limits for Forward Error Correction (FEC): FEC is adaptive and will only invoke when a Prisma SD-WAN VPN path exceeds the packet loss threshold specified in the SLA. As FEC is invoked, additional resources are required for processing the packet recovery information. 

* The branch ION determines if the SLA will be met in both the inbound and outbound direction on a per path basis. * * In the case that inbound (from the DC) loss exceeds the SLA the branch ION sends an in-band instruction attached to a packet to the DC ION instructing it to invoke FEC for the affected flow.

* If the number of VPNs actively invoking FEC meets the platform limit (above) then no further VPNs will be able to encode or decode recovery information. 

* ION Device version 6.3.2 or higher is recommended when using Forward Error Correction.

* See more at Best Practices and Recommendations

 

 

Routing 

Static Default Route

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngConfigure a static default route pointing to the BGP peer’s IP with a higher Administrative Distance.

Fig 28_Prisma-SDWAN-Best Practices_palo-alto-networks.png

For the most part learning a default route from a core BGP peer on the Hub device is sufficient. In case of a misconfiguration where the BGP learned default route is withdrawn, this static route will come into play ensuring the traffic gets routed to the core peer(s). It is recommended to enable next-hop tracking on this default route to ensure there is reachability to the appropriate next hop address.

 

BGP Peer Authentication

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngUse MD5 authentication while using BGP peering.

Peer authentication with MD5 creates an MD5 digest of each packet sent as part of a BGP session. Specifically, portions of the IP and TCP headers, TCP payload, and a secret key are used to generate the digest. The receiving BGP speaker uses the same algorithm and secret key to regenerate the message digest. If the received and computed digests are not identical, the packet is discarded.

 

Fig 29_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

BGP Edge Peer

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngBGP Edge peer is only needed if using MPLS underlay.

For an SD-WAN deployment where all traffic over MPLS needs to be encrypted - i.e only the MPLS overlay will be utilized, not the MPLS underlay - there is no need to setup BGP Edge peering on the DC/HUB IONs. The Edge peering on the DC ION to the MPLS router is only needed to learn Branch prefixes on the MPLS underlay. If no traffic is to be sent on the MPLS underlay, the DC ION does not need to learn the MPLS underlay prefixes. The DC ION needs to build the VPN tunnels for the MPLS overlay, so all it needs is reachability to the MPLS interfaces for the remote Branch IONs. This is accomplished by the next-hop gateway configuration on the MPLS facing interface on the DC ION. In such deployments, the DC ION only needs the BGP Core peering to the LAN Switch/Router, no BGP Edge peering is needed to the MPLS router. Make sure you have the circuit label (for the MPLS circuit) attached to the MPLS facing interface on the DC ION.

 

 

Fig 30_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

Multicast

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDo not disable SPT (Shortest Path Tree )

SPT Switchover is enabled by default. This indicates that once the first multicast packet is received, the multicast routing chooses the optimal path to relay information from the source to the receiver.

 

Network Management

 

Network Time Protocol

The Network Time Protocol (NTP) is recommended to be explicitly configured using a trusted time source and to use proper authentication. 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngEnsure that NTP traffic is allowed through Firewalls.

Accurate and reliable time is required for syslog purposes, such as during forensic investigations of potential attacks, as well as for successful VPN connectivity when depending on certificates for authentication.

 

When you configure NTP, the time zone needs to be configured so that timestamps can be accurately correlated. There are usually two approaches to configuring the time zone for devices in a network with a global presence. If the SD-WAN Network spans globally it is recommended to configure all network devices with the Coordinated Universal Time (UTC). For a regional SD-WAN deployment, the other approach is to configure network devices with the local time zone. 

 

Syslog

Send logging information to an enterprise syslog server. Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.png

Send the Syslog messages over VPN or private underlay if allowed via policy.  Use the Control port as the source interface.Fig 31_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

 

 This makes it possible to correlate and audit network and security events across network devices more effectively. syslog messages are transmitted using the UDP and in cleartext. For this reason, any protections that a network affords to management traffic (for example, encryption or out-of-band access) should be extended to include Syslog traffic. 

 

Simple Network Management Protocol (SNMP)

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngEnable SNMPv3, configure user with Auth and Encryption phrases 

Use the SNMP Version 3 (SNMPv3) agent which is an interoperable standards-based protocol for network management. SNMPv3 provides secure access to devices because it authenticates and optionally encrypts packets over the network. SNMP Traps can be sent directly to the SNMP servers.

 

Fig 32_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

SNMP Fig 33_Prisma-SDWAN-Best Practices_palo-alto-networks.pngmust be properly secured to protect the confidentiality, integrity, and availability of both the network data and the network devices through which this data transits. SNMP provides you with a wealth of information on the health of network devices. This information should be protected from malicious users who want to leverage this data to perform attacks against the network.

 

Community strings are passwords that are applied to an ION device to restrict access, both read-only and read-write access, to the SNMP data on the device.

 

These community strings, as with all passwords, should be carefully chosen to ensure they are not trivial. Community strings should be changed at regular intervals and per network security policies. For example, the strings should be changed when a network administrator changes roles or leaves the company.

 

 

IPFIX

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngEnable IPFix for offline viewing and analysis of the flow details.

IPFIX is a protocol that allows network administrators to export detailed flow information, such as source and destination IP addresses, ports, protocol types, and packet counts, from network devices to a collector or analyzer. This information can be used for network traffic analysis, performance monitoring, and security audits. Internet Protocol Flow Information Export (IPFIX) is an IETF standard export protocol for sending Netflow packets. IPFIX is based on Netflow version 9. Prisma SD-WAN portal has a graphical flow browser and other network analytics tools available but sometimes for offline viewing and detailed investigation, IPFix exported flow details can be very useful.

 

Benefits of using IPFIX:

  • Provides detailed flow information for network traffic analysis
  • Facilitates troubleshooting and identification of potential network issues or to isolate the network vs. application level issues
  • Enables network performance optimization and capacity planning
  • Helps meet regulatory compliance requirements for network security and data privacy

 

Default Flows:Fig 34_Prisma-SDWAN-Best Practices_palo-alto-networks.png

 

  • TIME_STAMPS
  • DST_IPV4_ADDRESS
  • DST_PORT
  • SRC_IPV4_ADDRESS
  • SRC_PORT
  • PROTOCOL
  • CONNECTION_UNIFLOW_BYTES
  • CONNECTION_UNIFLOW_PACKETS
  • DSCP_LAST
  • APP_DEF_ID

 

Additional Flow Fields:Fig 35_Prisma-SDWAN-Best Practices_palo-alto-networks.png

  • APPLICATION_HOST
  • CONNECTION_INIT
  • CONNECTION_BIFLOW_BYTES
  • CONNECTION_BIFLOW_PACKETS
  • CONNECTION_NTT
  • CONNECTION_RTT
  • CONNECTION_SRT
  • CONNECTION_UDPTRT
  • CONNECTION_XACT
  • DSCP_MAP
  • INTERFACES
  • MEDIA_CODEC
  • MEDIA_JITTER
  • MEDIA_LOSS
  • MEDIA_MOS
  • QOS_QUEUE
  • RTP_TRANSPORT_TYPE
  • TRANSPORT_TCP_WINDOWSIZE
  • TROUBLESHOOT_DECISION_MAP
  • TROUBLESHOOT_TCP
  • WAN_PATH

 

Options:Fig 36_Prisma-SDWAN-Best Practices_palo-alto-networks.png

  • APP_DEF_ID_TABLE
  • WAN_PATH_ID_TABLE
  • LINK_QUALITY_METRICS
  • DEVICE_IDENTIFICATION

 

 

 

 

 

 

Public Cloud Deployment

AWS Deployments

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDeploy Virtual IONs in an HA pair in different availability zones. 

To deploy vION in AWS there are two options, first and the most simple is to use the AWS Transit Gateway Cloudblade which will automatically deploy a pair of vION (7108) and create the connectivity to the AWS Transit GW in each region you chose to deploy. 

 

For more information refer to the following document:

AWS Transit Gateway CloudBlade Integration Guide

 

Optionally you can deploy a pair of HA vION in AWS using the Marketplace listing and specifically the “HA Greenfield'' CFT (Cloud Formation Template), this can be used in situations where the AWS Cloudblade may not meet all your requirements. 

 

For more information refer to the following documents:

Virtual ION on AWS Deployment Guide

AWS Cloud-WAN Integration Guide (Tunnel-less Connect)

 

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngBGP is required on the Core/LAN side

It’s important to remember that when using IONs in DC mode in HA that BGP is required on the Core/LAN side for route advertisement. In the case of AWS this is most commonly going to require BGP connections using a VPC Connect peering to a Transit Gateway or CloudWAN Edge Node.

 

Azure Deployments

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngDeploy Virtual IONs in an HA pair in different availability zones. 

To deploy vION in Azure there are two options, first and the most simple is to use the Azure vWAN with vION  Cloudblade which will automatically deploy a pair of vION (7108) and create the connectivity to the Azure vWAN Hub in each region you chose to deploy.

 

For more information refer to the following document:

Azure Virtual WAN with vION CloudBlade Integration Guide

 

Optionally you can deploy a pair of HA vION in Azure using the Marketplace listing and specifically the “Prisma SD-WAN vION HA'' Solution Template, this can be used in situations where the Azure Cloudblade may not meet all your requirements. 

 

For more information refer to the following document:

Virtual ION on Azure Deployment Guide

 

Fig 4_Prisma-SDWAN-Best Practices_palo-alto-networks.pngBGP is required on the Core/LAN side

It’s important to remember that when using IONs in DC mode in HA that BGP is required on the Core/LAN side for route advertisement. In the case of Azure this is most commonly going to require BGP connections to an ARS (Azure Route Server) or Azure vWAN Hub.

 

 

— END OF THE DOCUMENT—

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Rate this article:
(1)
  • 2007 Views
  • 0 comments
  • 5 Likes
  • 212 Subscriptions
Register or Sign-in
Contributors
Article Dashboard
Version history
Last Updated:
‎05-17-2024 10:41 AM
Updated by: