Prisma SDWAN Best Practices (2024)

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.

Prisma SDWAN Best Practices (1)

Prisma SDWAN Best Practices (2)

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

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 bydefault, 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 browserPrisma SDWAN Best Practices (3)

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

Prisma SDWAN Best Practices (4)Use 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.

Prisma SDWAN Best Practices (5)When 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

Prisma SDWAN Best Practices (6)The 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

Prisma SDWAN Best Practices (7)Create 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.

Prisma SDWAN Best Practices (8)

Prisma SDWAN Best Practices (9)

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

Prisma SDWAN Best Practices (10)

Prisma SDWAN Best Practices (11)

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.

Prisma SDWAN Best Practices (12)Disable 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.

Prisma SDWAN Best Practices (13)

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

Prisma SDWAN Best Practices (14)

Prisma SDWAN Best Practices (15)Create an Authentication Token

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

Prisma SDWAN Best Practices (16)

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

Prisma SDWAN Best Practices (17)

Prisma SDWAN Best Practices (18)Do 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.

Prisma SDWAN Best Practices (19)

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

Prisma SDWAN Best Practices (20)

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

Prisma SDWAN Best Practices (21)Note:

  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

Prisma SDWAN Best Practices (22)Connect 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.

Prisma SDWAN Best Practices (23)

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)

Prisma SDWAN Best Practices (24)Use 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.

Prisma SDWAN Best Practices (25)Use 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 SitesPrisma SDWAN Best Practices (26)

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.

Prisma SDWAN Best Practices (27)

Interface Settings

Prisma SDWAN Best Practices (28)Set 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.

Prisma SDWAN Best Practices (29)Configure 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.

Prisma SDWAN Best Practices (30)Upgrade 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.

Prisma SDWAN Best Practices (31)

Prisma SDWAN Best Practices (32)DC 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.

Prisma SDWAN Best Practices (33)

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.

Prisma SDWAN Best Practices (34)

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

Prisma SDWAN Best Practices (35)

Prisma SDWAN Best Practices (36)Define 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

Prisma SDWAN Best Practices (37)Provide 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 ProviderPrisma SDWAN Best Practices (38)

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.Prisma SDWAN Best Practices (39)

Prisma SDWAN Best Practices (40)Add 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

Prisma SDWAN Best Practices (41)Do 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 settingsPrisma SDWAN Best Practices (42)

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.Prisma SDWAN Best Practices (43)

Prisma SDWAN Best Practices (44)Always Select “Minimize Cellular Usage”

Prisma SDWAN Best Practices (45)

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.

Prisma SDWAN Best Practices (46)Use 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.

Prisma SDWAN Best Practices (47)

Prisma SDWAN Best Practices (48)Private circuits, WAN Networks need to match at the branch and data center

Prisma SDWAN Best Practices (49)

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

Prisma SDWAN Best Practices (50)Terminate 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.

Prisma SDWAN Best Practices (51)Connect 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 DHCPenabled 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.

Prisma SDWAN Best Practices (52)Perform a health check of a LAN interface for a proper failover (interface tracking).Prisma SDWAN Best Practices (53)

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.

Prisma SDWAN Best Practices (54)Set 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.

Prisma SDWAN Best Practices (55)Set 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

Prisma SDWAN Best Practices (56)Download 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

Prisma SDWAN Best Practices (57)Use 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.

Prisma SDWAN Best Practices (58)DO NOT ever change Cloudblade generated auto-configs on either ends.

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

Prisma SDWAN Best Practices (59)Use 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.

Prisma SDWAN Best Practices (60)Do 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

Prisma SDWAN Best Practices (61)Set 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.

Prisma SDWAN Best Practices (62)Apply 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.

Prisma SDWAN Best Practices (63)Use 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.

Prisma SDWAN Best Practices (64)Start 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

Prisma SDWAN Best Practices (65)“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.Prisma SDWAN Best Practices (66)

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.Prisma SDWAN Best Practices (67)

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.

Prisma SDWAN Best Practices (68)Use 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

Prisma SDWAN Best Practices (69)Ensure traffic deterministically comes to the main DC only and uses the secondary DC as a backup.

Prisma SDWAN Best Practices (70)Configure DC groups If any path policy uses the DC as a transit point (e.g. shadow DCs, Internet Backhaul, Carrier Co-location Facilities)

Prisma SDWAN Best Practices (71)Create DC groups and domains If multiple DCs exist, and make sure all branches are in specific domains.

Prisma SDWAN Best Practices (72)Configure 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

Prisma SDWAN Best Practices (73)Configure 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

Prisma SDWAN Best Practices (74)Use 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

Prisma SDWAN Best Practices (75)App Categories don’t matter - Transfer (traffic) Types do matter

Prisma SDWAN Best Practices (76)Creating a custom application does not automatically assign it to a priority

Prisma SDWAN Best Practices (77)Creating a customer application DOES automatically assign it to a Queuing mechanism

Prisma SDWAN Best Practices (78)If you want an application to have a non-default priority, add it to your QoS Policy

Prisma SDWAN Best Practices (79)Use Flow browser to determine QoS policy used

NAT Policy

Prisma SDWAN Best Practices (80)For 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

Prisma SDWAN Best Practices (81)Disable 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.

Prisma SDWAN Best Practices (82)When 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)

Prisma SDWAN Best Practices (83)Use 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.

Prisma SDWAN Best Practices (84)Avoid 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

Prisma SDWAN Best Practices (85)Create an explicit rule for traffic leaving and entering the site from anywhere, including the internet and / or WAN.

Prisma SDWAN Best Practices (86)Use descriptive naming conventions. Add in the Description field the date and created by information

Prisma SDWAN Best Practices (87)Rule order matters (top-down process)

Prisma SDWAN Best Practices (88)Avoid mixing in same rule application matching with port based traffic matching. It makes the management and tracking easier.

Prisma SDWAN Best Practices (89)Inbound rules require a NAT Policy

Prisma SDWAN Best Practices (90)For 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.

Prisma SDWAN Best Practices (91)Simple Policy Sets: Use simple policy stacks unless the modular flexibility of advanced stacks is required.

Prisma SDWAN Best Practices (92)Rule 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.

Prisma SDWAN Best Practices (93)Policy 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

Prisma SDWAN Best Practices (94)Functional 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

Prisma SDWAN Best Practices (95)Configure a static default route pointing to the BGP peer’s IP with a higher Administrative Distance.

Prisma SDWAN Best Practices (96)

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

Prisma SDWAN Best Practices (97)Use 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.

Prisma SDWAN Best Practices (98)

BGP Edge Peer

Prisma SDWAN Best Practices (99)BGP 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.

Prisma SDWAN Best Practices (100)

Multicast

Prisma SDWAN Best Practices (101)Do 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.

Prisma SDWAN Best Practices (102)Ensure 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.Prisma SDWAN Best Practices (103)

Send the Syslog messages over VPN or private underlay if allowed via policy. Use the Control port as the source interface.Prisma SDWAN Best Practices (104)

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)

Prisma SDWAN Best Practices (105)Enable 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.

Prisma SDWAN Best Practices (106)

SNMP Prisma SDWAN Best Practices (107)must be properly secured to protect the confidentiality, integrity, and availability of both the network data and thenetwork 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

Prisma SDWAN Best Practices (108)Enable 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:Prisma SDWAN Best Practices (109)

  • 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:Prisma SDWAN Best Practices (110)

  • 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:Prisma SDWAN Best Practices (111)

  • APP_DEF_ID_TABLE
  • WAN_PATH_ID_TABLE
  • LINK_QUALITY_METRICS
  • DEVICE_IDENTIFICATION

Public Cloud Deployment

AWS Deployments

Prisma SDWAN Best Practices (112)Deploy 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)

Prisma SDWAN Best Practices (113)BGP 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

Prisma SDWAN Best Practices (114)Deploy 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

Prisma SDWAN Best Practices (115)BGP 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—

Prisma SDWAN Best Practices (2024)

References

Top Articles
Latest Posts
Recommended Articles
Article information

Author: Patricia Veum II

Last Updated:

Views: 6150

Rating: 4.3 / 5 (44 voted)

Reviews: 83% of readers found this page helpful

Author information

Name: Patricia Veum II

Birthday: 1994-12-16

Address: 2064 Little Summit, Goldieton, MS 97651-0862

Phone: +6873952696715

Job: Principal Officer

Hobby: Rafting, Cabaret, Candle making, Jigsaw puzzles, Inline skating, Magic, Graffiti

Introduction: My name is Patricia Veum II, I am a vast, combative, smiling, famous, inexpensive, zealous, sparkling person who loves writing and wants to share my knowledge and understanding with you.