|
Disclaimer |
The information presented in this technical paper is intended solely for informational purposes. It does not represent any form of endorsement, recommendation, or guarantee of accuracy. The content within this document is based on interpretation and analysis without supporting material, and as such, should not be considered as a substitute for professional advice or comprehensive research. The authors bear no responsibility for any errors, omissions, or consequences resulting from the use of this information. Readers are advised to conduct their own thorough assessments and seek expert guidance where necessary. |
Architecture and Strategic Overview
Hardware Selection and Specification Guidelines
Software Form Factors and Virtual Deployment
Deployment and Operational Modes
Simplified Management and Operations
Prisma SD-WAN Portal Access (Strata Cloud Manager)
Accessing ION Devices via the Command Line Interface
Prisma SD-WAN automation and operations using API
Connecting IONs to the SD-WAN controller
Prisma SD-WAN Ports and Interfaces
Prisma SD-WAN integration and Cloudblades
Prisma SD-WAN Control Apps in Policy
Cloud Identity Engine (CIE) and User-ID / Group-ID Based Policies
DC-to-DC and Multicloud Connectivity
Simple Network Management Protocol (SNMP)
This guide captures Prisma SD-WAN Best Practices in the form of product settings, configurations, and procedures that have been shown by experience to produce optimal results and that can be established or proposed as suitable for widespread adoption.
It is intended for network architects, administrators, and engineers responsible for deploying, managing, and operating Prisma SD-WAN environments using Strata Cloud Manager (SCM). Topics covered include access and authorization, site and interface configuration (including Branch Gateway, High Availability, and Cloudblades), policy design (Path, QoS, NAT, Security, and Performance), routing (BGP, OSPF, and Multicast), network management, public cloud deployment (AWS, Azure, and GCP), branch security, IoT, and ADEM.
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.
For the latest product documentation, refer to the Prisma SD-WAN Administrator's Guide and the Strata Cloud Manager Getting Started Guide on the Palo Alto Networks documentation portal.
As enterprises transition to the "Cloud and AI Generation" of IT, legacy WAN edge infrastructure is no longer sufficient. Traditional networking relies on packet-routing, a hardware-centric approach where decisions are made based on rigid protocols and IP addresses. This legacy architecture typically backhauls traffic through a central data center, introducing latency and performance bottlenecks that degrade the user experience for cloud-native services like videoconferencing.
Prisma SD-WAN represents a fundamental shift toward an application-centric networking model. By steering traffic based on application identity (Layer 7) and business intent, we decouple the network from the physical transport. This enables a zero-routing architecture where the App-Defined Fabric becomes the strategic outcome, allowing organizations to utilize any transport MPLS, Broadband, 5G, or Satellite without the burden of manual routing complexity.
To successfully execute this transformation, architects must prioritize these three requirements:
Prisma SD-WAN is a core pillar of the Prisma SASE platform, working alongside Prisma Access (cloud-delivered security) and Autonomous DEM (end-user experience monitoring) to deliver a unified, cloud-managed SASE architecture. This integration allows organizations to converge networking and security into a single platform, eliminating the need for disparate point solutions at the branch.
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, and network-wide visibility. Strata Cloud Manager (SCM) provides the management interface to securely configure, provision, monitor, and troubleshoot the network. SCM is accessed at stratacloudmanager.paloaltonetworks.com and requires a Prisma SD-WAN license.
Prisma SD-WAN also includes Strata Copilot, an AI-powered assistant built on Palo Alto Networks Precision AI, available directly within SCM. Copilot provides real-time, actionable insights on network health and security, helps identify the root cause of degraded application experience, and can open support cases on demand.
For more information, see Prisma SD-WAN Security Architecture on the Palo Alto Networks website.
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 includes 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 the ION Datasheet.
Selecting the right Instant-On Network (ION) device is a prerequisite for a resilient branch architecture. ION devices utilize FIPS 140-2 or FIPS 140-3 validated cryptographic algorithms as a security baseline depending on the software version, and support high-frequency encryption key rotation to maintain a high security posture. From release 6.5.1 onwards, ION devices transition to FIPS-CC mode, combining FIPS cryptographic validation with Common Criteria (CC) security functions. Note that FIPS-CC mode requires an On-Premises controller solution.
ION Hardware Portfolio Specifications
|
Use Case |
Model |
WAN/LAN |
Bypass Pairs |
Encrypted Throughput (Branch / DC) |
|
Small office/ Home office/ Small Kiosk |
ION 1200 |
RJ45 (4) 4G LTE/5G |
N/A |
800 Mbps |
|
Small office/ Home office/ Small Kiosk with L2 switching or POE or bypass pair requirements |
ION 1200-S |
1 GE RJ45 (6) 1 GE RJ45/ SFP Combo ports (2) 1 GE RJ45 bypass ports (2) PoE++ ports (4) 4G LTE/5G |
1 pair: Ports 3/4 |
800 Mbps |
|
Medium Branch/DC |
ION 3200 |
1 GE RJ45 (6) 1 GE RJ45/ SFP Combo ports (2) 1 GE RJ45 bypass ports (2) PoE++ ports (4) |
1 pair (ports 3/4) |
1 Gbps / 1.4 Gbps |
|
Medium Branch/DC with temperature hardened appliance |
ION 3200H* |
1 GE RJ45 (5) 1 GE RJ45/ SFP Combo ports (2) 1 GE RJ45 bypass ports (2) |
1 pair (ports 3/4) |
1.3 Gbps / 1.7 Gbps |
|
Medium Branch/DC with temperature hardened appliance and cellular requirement |
ION 3200H-C5G-WW* |
1 GE RJ45 (5) 1 GE RJ45/ SFP Combo ports (2) 1 GE RJ45 bypass ports (2) 5G |
1 pair (ports 3/4) |
1.3 Gbps / 1.7 Gbps |
|
Large Branch / DC |
ION 5200 |
10 GE SFP+ (4) 10/100/1000 RJ45 (11) MGIG RJ45 (4 [1G/2.5G]) 1 GE RJ45 bypass ports (4) 802.3 bt PoE++ ports (4) |
2 pairs: Ports 1–2 and 3–4 |
2 Gbps / 4 Gbps |
|
Multigigabit remote office data center and large campus |
ION 9200 |
10 GE SFP+ (10) 10/100/1000 RJ45 (11) MGIG RJ45 (4 [1 G/2.5G/5]) 1 GE RJ45 bypass ports (8) 802.3 bt PoE++ ports (4) |
4 pairs: Ports 1–2, 3–4, 5–6, and 7–8 |
7.5 Gbps / 15 Gbps |
*Note: The ION 3200H is specifically designed for extended temperature environments (-40°F to 158°F) (DC power supply) and 32°F–140°F (0°C–60°C) (AC power supply)
Software form factors (vIONs) are recommended for virtualized customer premises equipment (vCPE) or cloud-native integration where hardware deployments are not feasible. vION instances run the same ION software as physical devices and support both Analytics and Control deployment modes.
Prisma SD-WAN eliminates the need for manual, site-by-site configuration through a centralized cloud management portal. All ION devices operate in one of three modes:
Analytics Mode provides granular visibility into application performance and network health without taking active control of traffic. In this mode, ION devices act as passive observers at the WAN edge, automatically identifying application sessions and measuring Key Performance Indicators (KPIs). This mode is ideal for baseline performance audits and monitoring application availability before transitioning to full SD-WAN control.
Control Mode enables the full power of the "App-Defined Fabric" and a zero-routing architecture. In this mode, the ION device takes intelligent, policy-based action on every flow, performing active traffic engineering, path selection, and prioritization. By integrating routing and security functions natively, Control Mode significantly reduces the branch hardware footprint while ensuring traffic adheres to business-defined SLAs.
Disabled Mode the ION device sits in-path but does not monitor traffic, apply policies, or make path selection decisions. This mode is typically used for staging or troubleshooting purposes only and is not recommended for production deployments.
Prisma SD-WAN natively supports Zero-Touch Provisioning (ZTP) for all new deployments, enabling devices to be automatically claimed and configured upon internet connection without the need for on-site technical expertise.
Prisma SD-WAN is shipped by default with an extensive suite of 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.
Prisma SD-WAN includes Copilot, an AI-powered virtual assistant built on Palo Alto Networks Precision AI. Copilot provides real-time, actionable insights on network health and security directly within the management interface. It can identify the root cause of degraded application experience, surface relevant technical documentation contextually, and open support cases on demand. The data and insights Copilot provides are based on your onboarded products and licenses. Copilot is accessible from any page within Strata Cloud Manager via the Copilot icon in the interface, and is available across all SCM-managed products including NGFWs, Prisma Access, and Prisma SD-WAN.
The Prisma SD-WAN Dashboard provides a unified view of controller connectivity, application utilization, link quality, and site-level alarms across all branch and data center sites. Key capabilities include Application Insights (application health scoring and transaction success/failure rates), and the Link Quality Dashboard (per-path quality metrics for all active WAN circuits).
Although all popular browsers are supported, the Chrome and Prisma Browser is the de facto browser that the Prisma SD-WAN QA team tests thoroughly.
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. Pre-defined roles simplify providing permissions to users in your organization by including a collection of the necessary system permissions required to perform a specific function. For details on available roles and permissions, refer to the Common Services: Identity and Access documentation.
The three levels are:
Monitor: dump, inspect, and file commands (display only)
Read-Only: adds debug and search commands
Super: full access including configure commands
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. Config from CLI will get overwritten by the controller. For the initial configuration, it is fine, but for any interface config, it is recommended to use the UI.
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.
For enterprise deployments, use TACACS+ for centralized administrator authentication to ION devices. TACACS+ integrates with your existing AAA infrastructure and provides full audit logging of admin sessions. Configure a TACACS+ profile (up to four servers for redundancy) under Configuration>Prisma SD-WAN>Profiles and Templates>AAA, then apply the profile to each device. The TACACS+ server must send the role attribute in the authorization reply (supported roles: super, readonly, monitor). If the TACACS+ server does not send a role, the default role assigned will be read-only.
Note: TACACS+ usernames are limited to 15 characters. Usernames exceeding this limit will fail authentication. Ensure your AAA server and username provisioning standards align with this constraint.
Note: if a user is present in both TACACS+ and the local database, local authentication takes priority. Supported protocols are CHAP and PAP. Available starting with ION Release 6.5.
★ Use the Device Offline Access One-Time Password (OTP) to recover access to offline ION devices.
If all Device Toolkit passwords are forgotten and the ION device has lost connectivity to the controller, use the OTP feature to regain access. The device must be in a claimed or assigned state and offline. From the device console, log in with a menu as the username to obtain a Challenge Phrase, then in SCM navigate to Configuration > Prisma SD-WAN > ION Devices, select the device, and choose Generate One-Time Password. The OTP is single-use — any failed or exited attempts are automatically invalidated and logged. Administrators can configure the maximum OTP attempts and expiration timeframe from Configuration > Prisma SD-WAN > System > Device Offline Access.
Prisma SD-WAN’s RESTful architecture enables seamless, programmatic control of your entire network through automation. Explore the Prisma SD-WAN API documentation for detailed integration guides.
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.
The service account needs to be granted appropriate roles and access to the applications and services that you intend to manage using APIs.
When assigning roles to a Service Account, select only the specific application (e.g., Prisma SD-WAN) and the minimum role required for the automation task. Avoid assigning broad roles such as Superuser or All Apps & Services unless absolutely necessary, as these grant unrestricted access across all managed products and tenants.
Once the service account with the appropriate roles is created, the client ID and client secret are used to generate the short-lived (15-minute) 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/
To claim an ION device, it must be powered on and connected to the Prisma SD-WAN Controller. The ION must be able to connect to the Internet and have a DNS server configured. By default, for the Gen 1 devices (ION 2000, 3000, 9000) the controller port of ION is set for DHCP. 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.
To claim an ION device in SCM, navigate to Configuration → Prisma SD-WAN → ION Devices → Unclaimed Devices. After activation and device allocation, it may take 15–60 minutes for devices to appear in the unclaimed list.
The ION just needs to be reachable over the Internet. The last column is the ports that can be used to connect to the internet and initiate the Zero Touch Provisioning (ZTP) service .
Use Device Shells for Day-0 pre-staging. A Device Shell allows you to build the complete site configuration interfaces, circuits, and policies in SCM before the physical ION arrives on-site. When the device is powered on, connects to the internet, and is claimed, it automatically pulls the pre-built configuration from the Device Shell. This significantly reduces deployment time and eliminates the need for on-site technical expertise during installation.
The following ION models table lists the interfaces shipped with DHCP enabled:
|
ION Model |
Controller Ports (default) |
DHCP-enabled Interfaces (default) |
Ports that can be used as Internet (default) |
|
ION 1200 |
N |
1-4 (All) |
All |
|
ION 1200-S |
N |
1-10 (All) |
1-2 |
|
ION3200, ION3200H |
N |
1-10 (All) |
1-2 |
|
ION5200 |
N |
1 - 19 (All) |
1-2 |
|
ION9200 |
N |
1 - 25 (All) |
1-2 |
vION CloudBlade deployment (AWS/Azure/GCP): The CloudBlade automatically provisions 3 interfaces — Controller, Internet, and Transit/LAN — using cloud subnets. All three interfaces are DHCP enabled by default.
vION Manual deployment (ESXi/Hyper-V/KVM): User defines all interfaces. Minimum 3 required, any L3 interface can be the controller. All three interfaces are DHCP enabled by default.
In all cases, any L3 interface can be used to communicate with the cloud controller.
The ION box may use a mix of L3 interfaces for the controller, stats, and remote access. This can be checked in CLI by dump controller status.
The Online-Restricted device status under the Unclaimed Devices list determines a successful connection to the SD-WAN service.
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 the ION Device to the On-Premises Controller.
With naming conventions, you can search and locate the Branch by its name in 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.
Site configuration template helps you to create tailored site templates that cater to your deployment requirements, allowing you to efficiently deploy branches and data centers at scale with ease.
Create a site with all essential configurations and validate its functionality. After the site is operational, it can serve as a foundation for a site template. Importing a site template involves downloading previously utilized templates, adjusting them per your requirements, and re-importing the updated versions.
Note: At the time of writing, site configuration templates do not support FIPS mode or CloudBlades. Verify current support status in the latest Prisma SD-WAN Administrator's Guide before deployment.
Always configure the site-level prefixes for DC Sites (this is not required for Branch sites). A Branch can use all DCs 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.
In Prisma SD-WAN, a WAN network is a reference to your service provider like AT&T, Verizon, Comcast, BT, etc. Service Providers you subscribe to for Internet access need to be defined under Internet Circuits.
Similarly, Service Providers you subscribe to for MPLS or Private WAN access need to be defined under Private WAN Circuits.
First, define all the providers across your entire estate, and then 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.
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.
As an example, for a site in Chicago that has 1 Verizon ISP and 1 ATT MPLS circuit, the circuit labels can be named “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.
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.
Make sure to configure the circuit speed (Up/Down BW) in the Site configuration, based on carrier-provided values. Do not use the system default values. .
It is recommended to use a slightly lower value (1-2 %) for the Download/Upload BW (i.e. Link Down and Link Up in the “Add Circuits/Change Circuits” site-level configuration) on each 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 and thereby ensure prioritization of the critical applications. For example, if the circuit is rated for 100Mbps down, 50Mbps up, you can configure the circuit settings for 99Mbps down, 49Mbps up. This ensures that the ION QoS starts kicking in at 99Mbps down, and 49Mbps up and starts prioritizing applications according to the configured QoS policies.
We can set circuit bandwidth on the DC, but it’s informational only no QoS shaping is applied.
VPNs Configs
The Prisma SD-WAN uses BFD and keep-alive to detect failures. The devices on version 5.4.1 and later use the VPN Keep Alive. The Prisma SD-WAN uses BFD for the MPLS underlay. Aggressive mode is the default mode and is recommended by Prisma SD-WAN for fast failure detection of links.
In Aggressive mode, the default keep-alive interval is 1000 ms with a fail count of 3, resulting in a 3-second failure detection time. These values can be overridden at the circuit or secure fabric link level if needed.
By default, Link Quality Monitoring (LQM) measures latency, loss, and jitter on branch-to-data center VPN paths. Enabling Use LQM for all Paths extends this measurement to internet underlay paths including branch-to-branch and direct internet circuits giving you full visibility into link quality across all WAN paths, not just hub-bound traffic. This is particularly important for sites using Direct Internet Access (DIA) or branch-to-branch traffic patterns where performance SLAs need to be enforced.
By default, BW Monitoring, LQ Monitoring, App Reachability Probes, and Controller Connections are enabled on all circuits. These settings work together to power Prisma SD-WAN's core intelligence:
BW Monitoring measures real-time circuit capacity and feeds into QoS enforcement
LQ Monitoring tracks latency, jitter, and packet loss to trigger path moves when SLAs are breached
App Reachability Probes detect Layer 7 application failures on a specific path and automatically move flows to a healthy path
Controller Connections ensures the ION device maintains controller reachability for policy updates and telemetry
Disabling any of these settings removes the data needed for intelligent path selection. For example, disabling App Reachability Probes means the system cannot detect application failures on a path and will not move flows even if the application is unreachable. Only disable these settings on metered or last-resort circuits such as LTE/5G, where minimizing non-user traffic is a priority.
★ Use "Minimize Cellular Usage" for metered LTE/5G circuits to prevent unplanned data costs.
Minimize Metered LTE Usage ensures LTE links are only used as a failover path when primary WAN links are unavailable. In this mode, LTE circuits are not actively considered for path selection based on LQM metrics, and traffic is not steered to LTE unless no other paths are available.
VPN keepalive timers can be adjusted to reduce control-plane traffic over LTE, helping minimize data usage. However, increasing keepalive intervals may delay tunnel failure detection and extend failover times. Since LTE is reserved for failover in this mode, LQM threshold tuning does not influence path selection toward LTE.
The Minimize Cellular usage will control the incoming traffic by increasing the cost and stop using this circuit for the controller Stas and connection. For the outgoing traffic, we need to use a Path policy to select this circuit as an L3 failure.
Note: Avoid setting keepalive intervals to excessively large values. When a DC failover occurs, the original ION retains VPN state until the keepalive timeout expires, causing both DC IONs to advertise routes to the branch simultaneously and resulting in a branch outage for the duration of the timeout. Set the keepalive interval based on the acceptable failover time for your deployment.
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.
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.
★ Always assign a Circuit Label to every WAN-facing interface.
The Circuit Label is what registers an interface as a valid WAN uplink with the path selection engine. Without it, the ION does not create a WAN interface context and no WAN paths will be selected regardless of tunnel state or policy configuration.
Note: This requirement applies universally, including in Standard VPN-only deployments with no Secure Fabric or DC connectivity. A common symptom of a missing Circuit Label is Flow Decision Data showing “Available WAN Networks: empty” and a reason of “All Active and Backup paths with a route for destination prefix are down or have L3 failures” even when IPSec tunnels show as tunnel_up. To verify, use dump waninterface summary from the ION CLI; if no WAN interfaces appear, check that a Circuit Label matching the circuit category referenced in the path policy is assigned to the WAN-facing interface.
Ports are the physical interfaces on the ION device and Interfaces are the logical interfaces on the ION device. Every port or interface has specific configuration steps that must be followed.
The various physical ports are :
The various logical interfaces are:
Note: The default MTU value is 1500. Keep in mind that the IP MTU value should be at least 1280 for IPv6. If it is less than 1280, IPv6 cannot be enabled.
Note: The default MTU for ION cellular interfaces is 1428 on models that support cellular. If a customer uses a cellular gateway like Cradlepoint for Ethernet connectivity, the MTU on the ION’s WAN-facing Ethernet port must be manually reduced to match — ION does not auto-detect this scenario.
Note: If we have a BGP or Static route for use on the LAN interface, we do not need to configure the Default Gateway.
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.
If the Speed and duplex are not an issue, we might see the interface drop for the RX /ingress traffic.
The most common types of reasons for the ingress drops are following which are related to the parsing error or unknown protocols:
This is especially important for bypass pair interfaces. Hardcoding speed/duplex on bypass pair ports can cause link failures during HA failover events when traffic is redirected through the hardware relay.
DNS (either external or internal, depending on the interface) must be configured under each interface. Controller bound traffic, on WAN, HA, or other Interfaces depends on reliable, configured DNS servers. Since DNS is UDP-based, failure to reach a DNS server can result in a blackout, therefore configure multiple DNS servers for resiliency.
On the Cellular interface (cwan), the Firmware page displays the current list of firmware versions available for 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 the controller inventory and then upgrades the carrier firmware on the modem.
On the DC ION Core (LAN side) facing interface, there is no need to configure a circuit label.
In a typical Prisma SD-WAN data center design, the LAN-facing interface of the DC ION does not require a default gateway when BGP is used with the core network. This is because reachability and next-hop information are dynamically learned via BGP from the core routers. However, in deployments where BGP is not configured between the DC ION and the core, a static default route must be configured to ensure proper traffic forwarding. As a best practice, BGP-based designs are preferred due to improved scalability, resiliency, and routing visibility.
As a best practice, we would recommend using a separate subnet for the LAN and Controller interfaces.
★ Always configure the External NAT Address and Port on internet-facing interfaces behind a NAT device.
If the ION device's internet port is assigned a private IP address behind a NAT firewall, you must configure the External NAT Address (the public IP that traffic is translated to) and External NAT Port (UDP 4500) on the interface. Without this, the ION device will advertise its private IP to other ION devices, preventing VPN tunnels from establishing correctly. Additionally, ensure your upstream firewall allows TCP 443 and UDP 4500 inbound for Prisma SD-WAN connectivity.
★ Use Port Channel (LAG/LACP) for increased bandwidth and redundancy on LAN and WAN interfaces where supported.
Port Channel combines multiple physical interfaces into a single logical interface using LAG (Link Aggregation Group) and LACP (Link Aggregation Control Protocol). This feature is supported starting in Release 6.5.2 on L3 ports for LAN-facing interfaces on ION 3200, ION 5200, and ION 9200 platforms. In Release 6.6.1, support expands to WAN interfaces for both Internet and Private WAN circuits.
Key configuration considerations:
A loopback IP provides a stable management address not tied to any physical interface. Traffic traverses the overlay maintaining access even if a specific physical link goes down. Configure the loopback as the source interface for SSH and Syslog services. Loopback supports only /32 subnet masks, does not support IPv6, and a maximum of 12 loopback interfaces are supported per ION device.
Configure the loopback as the VPN source with an associated physical interface as the underlay path. Ensure the loopback IP is advertised only on the associated interface and that the peer can reach it via that interface. Loopback interfaces cannot be used to establish Standard VPN tunnels.
For branch IONs set scope to Global to advertise the loopback prefix to BGP peers and the fabric. For DC IONs use a route map attached to the loopback prefix list for Core and Edge peers for Classic peers advertisement happens automatically when scope is Global.
Prisma SD-WAN provides High Availability (HA) solutions across all site types to ensure network resilience and business continuity.
Branch HA leverages fail-to-wire capabilities and HA group technology to deliver automatic failover between active and backup ION devices, maintaining full WAN capacity when a device experiences a software, hardware, or network failure.
Branch Gateway HA follows the same active-backup HA group configuration as branch HA with VPN tunnels to all branch sites in the domain automatically re-establishing through the new active device after failover. In all deployment types, HA configuration is managed centrally through Strata Cloud Manager.
Data Center HA operates in active-active mode where two DC ION devices simultaneously forward traffic and maintain BGP peering with the core network if one device fails, the other continues handling all traffic without interruption.
Prisma SD-WAN supports different High Availability (HA) topologies for ION devices at branch sites.
In HA deployments, the customer is expected to have two circuits. The circuits must be terminated directly on each of the 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.
Generation One ION devices (ION 1000, ION 2000, ION 3000, and ION 9000) use the control port for the exchange of HA heartbeat and manage the controller traffic between the active and the standby device. The Gen2 ION devices (ION 1200-S, ION 3200, ION 5200, ION 9200) do not need a dedicated controller port with the introduction of used-for-HA as a port type.
The used-for-HA interface (referred to as the used-for-control interface prior to Release 6.3.1) exchanges heartbeat between the two ION devices and also connects the standby device to the controller through the active ION device. You can use this interface to send management traffic like App Probe, NTP, SNMP, RADIUS, and IPFIX.
It is recommended not to use HA interfaces for any other services.
Starting with Release 6.3.1, the support for High Availability (HA) has been enhanced to include compatibility with various interface types.
Used-for-HA is supported on all ION platforms. Directly establishing the High Availability (HA) connection between devices is recommended only in cases where there are no southbound LAN switches present and exclusively only with 1200-S and 3200-L2 models with redundant ports.
For ION 1200-S and 3200-L2 deployments, both the LAN and used-for-HA interfaces share a trunk port connected to the southbound LAN switch. When configuring this trunk, ensure that the adjacent LAN switch uses MSTP (802.1s) or RSTP not Per VLAN Spanning Tree (PVST). The ION embedded Layer 2 switch operates via MSTP and is not compatible with PVST, which can cause spanning tree issues and network instability.
HA interfaces must be configured with static IP addresses and DNS servers. Configuring an HA interface to obtain an address via DHCP could cause instability and unpredictable behavior.
Track Availability
We have options to track LAN or WAN interfaces. 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.
Track availability for WAN tracks Layer 3 reachability for WAN circuits. If there is a transport issue causing middle mile failure, using track availability for WANs, an HA switchover can be induced by lowering the priority of the active device. This should only be enabled when using unique IP addresses on each WAN interface, it is not supported in Bypass Configurations.
Only WAN facing interfaces with an attached circuit label are listed for tracking Layer 3 reachability on the WAN.
The HA switchover from active to backup device occurs when the track availability fails. As soon as the interface is available again or when the Layer 3 reachability on the WAN is restored, an HA switchover is induced, restoring the devices to their original state. • We do not recommend enabling tracking of Layer 3 availability for: • A private WAN interface that has BGP peering configured. • Devices sharing a single circuit.
For ION 1200-S and 3200-L2 embedded switch platforms using a trunk port connected to a southbound LAN switch, enable interface tracking on the trunk switch ports. Set the tracking decrement value equal to the device's current HA priority so that a trunk port failure decrements the priority to zero and triggers an immediate failover. This step is not required when the two ION devices are connected back-to-back with no southbound switch present.
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.
The minimum gap of 40 ensures that a single non-critical process crash (which decreases priority by 25) on the active device does not cause its priority to fall below the backup device, preventing unintended failovers.
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.
Setting the Advertisement Interval to 1 second means the backup device will detect an active device failure within 3 seconds (3 consecutive missed advertisements × 1 second). This provides fast failure detection while avoiding false positives from momentary network delays.
As a best practice, preemption should be carefully enabled to avoid unnecessary failback events. In a failover scenario (e.g., due to interface failure or service crash), traffic shifts from the active ION (Device A) to the standby ION (Device B). If preemption is enabled, once Device A recovers, it will immediately reclaim the active role, causing an additional failover. This results in multiple traffic disruptions within a short period. Disabling preemption ensures that after a failover, the network remains stable on the standby device until a planned failback is performed.
Site-level configurations such as path policy, QoS policy, and NAT policy are automatically applied to both devices in an HA group. However, device-level configurations such as NAT port forwarding and security zone binding at the interface level must be manually applied to both the active and backup devices. Failing to do this will result in inconsistent behavior after a failover.
The Branch Gateway site type supports the same HA group configuration as a standard branch site since it operates in control mode. Configure used-for-HA interfaces, static IP addresses, priority settings, and track availability using the same best practices as branch HA. VPN tunnels to all branch sites in the domain will automatically re-establish through the new active Branch Gateway device after failover.
Unlike Branch HA which operates in active-backup mode, Data Center ION devices support active-active redundancy. Both DC ION devices are simultaneously active, forwarding traffic and maintaining BGP peering with the core network. In the event of a device failure, the remaining active ION device continues to handle all traffic without a failover event. Ensure both devices are assigned to the same cluster within the DC site so that branch sites can reach the data center through either ION device.
Note: While both DC ION devices are active-active within the cluster, each branch establishes fabric tunnels to both DC IONs simultaneously. However, only one DC ION is designated as Active per branch at any given time — and only that Active DC ION will advertise the branch prefix into the data center core network. This prevents asymmetric routing and duplicate prefix advertisement while still providing fast failover if the Active DC ION goes down.
Before performing the software upgrade, it is important to download the software properly. You can download the software ahead of time and then perform the upgrade during a change window. That will ensure the code is already downloaded and minimize the change window duration.
For environments with many ION devices, use the Bulk Software Upgrade feature under Configuration > Prisma SD-WAN > ION Devices > Claimed > Bulk Software Upgrades. You can upgrade up to 50 devices at a time and schedule separate Download Date and Upgrade Date to separate the download from the actual upgrade window. If a device is incompatible with the target version, you may need to upgrade to an intermediate version first.
When doing bulk upgrades for multiple Branch / Branch Gateway Sites with ION devices in an HA configuration, upgrade the backup device first. Once it upgrades and comes back online in the SCM portal, upgrade the Active device. This would trigger a failover event and brief interruption in services at the Site. Once the primary ION upgrades, and HA Pre-emption is configured, it will become active again. This failback will cause brief service interruption. If HA Pre-emption is not configured, the newly upgraded primary ION will remain in backup state.
When upgrading a single site, or validating the upgrade process for a Lab Site, or when it doesn't matter which ION is active; you could minimize the service interruption by upgrading the backup device first, then make it the active device by increasing its HA priority. Verify all tunnels are stable on the newly active device, then upgrade the original active device (now backup). Optionally, you can, restore the original priority values to return each device to its original role. Refer to the High Availability Settings section for the full procedure.
After scheduling an upgrade, monitor progress under Configuration > Prisma SD-WAN > ION Devices > Claimed > Device Options. Use Retry Upgrade if a failure occurs. To rapidly confirm upgraded versions, run dump software status from the device CLI to verify the installed version post-upgrade.
Prisma SD-WAN CloudBlades provide seamless integration with both Palo Alto Networks and third-party cloud services, enabling automated deployment and simplified connectivity. CloudBlades eliminate manual configuration by automatically provisioning tunnels and required settings, ensuring consistency across all sites. The following CloudBlade integrations are available:
Palo Alto Networks Integrations:
Note: For new deployments, Palo Alto Networks recommends using SASE Easy Onboarding instead of the Prisma Access CloudBlade. Existing customers currently using the CloudBlade should continue until a migration path is available. Do not run both simultaneously on the same tenant.
Third-Party Security Integrations:
Cloud Infrastructure Integrations:
Notification and Operations Integrations:
For the full and current list of available CloudBlades, refer to the Prisma SD-WAN CloudBlade Integrations documentation.
If a zone is not bound to an interface or subnet, it blocks all traffic. Ensure every interface participates in a security zone when using the Prisma Access CloudBlade integration.
CloudBlades are the authoritative source for any configuration settings they manage. Manually changing CloudBlade-managed configurations can cause inconsistencies, break integrations, and result in unexpected behavior during convergence. If you need to stop further changes without offboarding the integration, use the Paused state, do not use Disabled, as this initiates the offboarding process and should only be used when you intend to fully remove the integration.
Set the CloudBlade to Disabled, wait for configuration convergence, then select Uninstall. Note there is a convergence time period in each case refer to the specific CloudBlade Integration Guide for full offboarding details.
SASE Easy Onboarding (Prisma Access Native Integration)
SASE Easy Onboarding is the recommended method for connecting Prisma SD-WAN branch sites to Prisma Access. It replaces the Prisma Access CloudBlade for new deployments by providing a native, automated integration that automatically configures IPSec tunnels and BGP routing between Prisma SD-WAN and Prisma Access — without requiring manual tunnel and endpoint configuration. It works with both Prisma Access Cloud Managed and Panorama Managed deployments and requires ION device software version 5.6.X or higher.
SASE Easy Onboarding is the current recommended integration method. The Prisma Access CloudBlade is supported only for existing deployments until migration to Easy Onboarding is available. If you have an existing CloudBlade deployment and want to migrate to Easy Onboarding you must first deactivate the CloudBlade and contact Palo Alto Networks Customer Support before using the Easy Onboarding workflow.
This is a hard prerequisite. If they are in different TSGs the integration will not work. Verify TSG alignment before starting the onboarding process.
SASE Connectivity (Configuration > Resources > SASE Connectivity) is a one-time tenant-level configuration that sets the parameters used for all site onboardings. Key settings are:
Changes to Deployment Mode only affect new or modified tunnels; existing tunnels are not updated.
A maximum of four circuits per site can connect to Prisma Access. Each circuit creates a corresponding IPSec tunnel to the selected Prisma Access location. Plan the Tunnel Inner IP Pool size accordingly based on the total number of circuits across all sites to be onboarded.
When onboarding a site, configure both a Primary and Secondary Prisma Access location with corresponding IPSec Termination Nodes. Prisma Access recommends the closest location based on the site address entered during site creation. For Site-Based Licensing select the appropriate site type bandwidth tier (25Mbps, 50Mbps, 250Mbps, 1Gbps, or 2.5Gbps) that matches the site's requirements.
Easy Onboarding automatically creates Standard VPN endpoints for all Prisma Access regions with liveliness probes pre-configured (ICMP every 10 seconds, mark tunnel failed after 3 consecutive failures). However these endpoints still need to be manually added to the appropriate Service and DC Groups and Domains for path policy routing to function correctly. Verify endpoints under Configuration > Resources > Service and DC Groups > Manage Endpoints > Standard VPN.
When a service endpoint is created through native integration it is automatically set to Prisma Access Remote Networks High Performance (RN-HP). To enable LQM for Prisma Access tunnels navigate to Configuration > Resources > Service and DC Groups > Manage Endpoints, select Standard VPN, and enable the Prisma Access RN-HP LQM liveliness probe for the endpoint. Additionally enable Use LQM for Non-Hub Paths on the internet circuit categories used for Prisma Access connectivity to allow Performance Policy to influence path selection between Prisma Access tunnels and other internet paths.
To deploy vION in AWS there are two options. The first and most recommended is the AWS Transit Gateway CloudBlade, which automatically deploys a pair of ION 7108v instances and creates all required connectivity to the AWS Transit Gateway in each region you choose 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 (CloudFormation Template). This can be used in situations where the AWS CloudBlade may not meet all your requirements, for example when integrating with AWS Cloud WAN instead of Transit Gateway.
For more information refer to the following documents:
Virtual ION on AWS Deployment Guide
AWS Cloud WAN Integration Guide (Tunnel-less Connect)
The CloudBlade requires two non-overlapping CIDR blocks defined at configuration time that cannot be easily changed post-deployment. The VPC CIDR must be RFC 1918 space with a mask between /16 and /26. The TGW GRE Tunnel CIDR must not overlap the VPC CIDR and must use a mask of /8, /16, or /24. In multi-region deployments the same VPC CIDR is reused across all regions, so verify there are no conflicts with existing VPCs in any target region before deploying.
When integrating with AWS Cloud WAN without the CloudBlade, select the Tunnel-less (No Encapsulation) option for the Connect Attachment protocol. This eliminates the need to configure GRE Standard VPN interfaces on the IONs and simplifies the overall setup compared to the GRE-based approach.
Uninstalling without first disabling leaves orphaned AWS resources including VPCs, EC2 instances, Elastic IPs, and TGW Connect attachments. Set Admin State to Disabled and wait approximately 30–36 minutes before clicking Uninstall.
To deploy vION in Azure there are two options. The first and most recommended is the Azure Virtual WAN with vION CloudBlade, which automatically deploys a pair of ION 7108v instances and creates all required connectivity to the Azure vWAN Hub in each region you choose 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, for situations where the CloudBlade may not meet all your requirements.
For more information refer to the following document:
Virtual ION on Azure Deployment Guide
Brownfield is the most common and recommended deployment model. Use it when you already have an Azure Virtual WAN and associated vWAN Hub(s) in the target regions the CloudBlade will deploy a Transit VNET and connect the ION HA pair to the existing Hub. Only use Greenfield when no Virtual WAN exists in your environment at all.
The CloudBlade requires an App Registration with four values collected before configuration begins: Application (client) ID, Directory (tenant) ID, a client secret, and the Azure Subscription ID. The App Registration must be assigned the Contributor role at the subscription scope. Note that Azure BGP peering with the vWAN Hub must be explicitly enabled by contacting the Azure team with the Resource ID of your Virtual WAN resource before the CloudBlade can complete BGP configuration.
The CloudBlade must be set to Disabled before uninstalling. Wait for 2–3 integration run periods and confirm the Monitor tab shows no remaining resources before clicking Uninstall. Uninstalling with resources still present can prevent the CloudBlade from successfully redeploying into the same region in the future.
When the AWS/Azure/GCP CloudBlade deploys the vIONs and DC site, ensure the set the DC site-level prefixes. If we do not set site-level prefix or set any Static or BGP to Global, the prefixes will not be advertised into the Prisma SD-WAN fabric and branch sites will not be able to reach through the overlay. Then the ION will rely on DC and Service Group to route the traffic.
Adding the DC site to the Service and DC Group in the path policy is still recommended as an additional control, but the Global prefix scope is the critical requirement for proper routing.
When deploying vIONs in DC mode with any cloud provider CloudBlade (AWS Transit Gateway, AWS Cloud WAN, Azure vWAN, or GCP NCC), BGP is required on the Core/LAN side for route advertisement. In all three clouds, the BGP peer is not directly adjacent to the ION traffic traverses an intermediate construct (a GRE/Connect tunnel on AWS, a vNET spoke attachment on Azure, or a Transit VPC on GCP) before reaching the cloud router or hub. Because of this, the default Multihop Limit of 1 will always cause BGP peering to fail. The Multihop Limit must be set to 2 on every BGP peer configuration in the Prisma SD-WAN portal, and it must be configured individually on each ION in the HA pair it is never inherited automatically across devices. This is one of the most common causes of BGP peering failures reported across all cloud deployments.
Use manual Standard VPN (IPSec or GRE) as a last resort and only if Cloudblade integration is not available.
Prisma SD-WAN ION devices can communicate with other Prisma SD-WAN devices through Prisma SD-WAN Secure Fabric Links or communicate with standard VPN endpoints through traditional IPsec or GRE tunnels. Similar to all other paths, a standard VPN will be monitored for application reachability and best path selection. Traffic on a standard VPN is subject to QoS policies.
A Standard VPN can be of the following types:
A standard VPN has two endpoints: one endpoint is on the Prisma SD-WAN ION device and the other endpoint is on the remote peer. You can configure a combination of IPsec and GRE tunnels from an interface on the ION device to a standard VPN endpoint. However, there cannot be two tunnels of the same type to the same endpoint from the same interface. When you connect a Prisma SD-WAN branch with a non-Prisma SD-WAN branch through a private WAN and you select direct private WAN as a viable route, traffic flows seamlessly between these sites without any additional configuration. 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.
In case the CloudBlades are not an option before you configure the IPsec profile on Prisma SD-WAN, make sure you have the IPsec protocols and authentication details required to connect.
All new customer tenants have default IPSec profiles pre-allocated that match the best practices of common cloud partners. Use these as a foundation and copy/modify them to meet your specific Standard VPN requirements. If these default profiles are not present on your tenant, open a support case to have them allocated.
The set of parameters selected in the Proposals screen have to be identical to the set of parameters selected for the standard VPN endpoint. You can add a proposal by clicking Add Proposal. Up to 8 proposals can be added. While establishing the IPsec tunnel, the system checks for a proposal match with the standard VPN endpoint.
Note: Only IKEv2 supports the AES-GCM algorithms.
DPD detects when a remote peer is no longer reachable and triggers a tunnel re-establishment. For IKEv1, configure the DPD delay and timeout in seconds — if DPD fails within the timeout period, a new tunnel is attempted. For IKEv2, there is no DPD timeout; instead a series of 5 retransmissions is used before the peer is declared dead.
GRE tunnels are stateless by design and IPSec tunnels may not detect failures immediately. Configure ICMP and/or HTTP probing on each Standard VPN endpoint to detect link failures and prevent traffic from being sent over a down tunnel. Note that this configuration is handled automatically if you are using a CloudBlade integration. Manual configuration is only required when building standard VPN tunnels without a CloudBlade.
When using HTTP probes, you must enable DNS Liveliness on the endpoint's tunnel. By default, DNS requests are sent to all interfaces, and the system accepts the first response received. If your WAN interface DNS servers are misconfigured or unreachable, this default behavior can cause incorrect probe targeting or probe failures. Enabling DNS Liveliness in Tunnel forces DNS resolution for the HTTP probe to use the Standard VPN tunnel itself, ensuring the probe accurately reflects the health of the tunnel endpoint rather than the WAN DNS path.
GRE tunnels are stateless by design — the tunnel is established when the Standard VPN interface is created and the parent interface is up. Without a mechanism to detect peer failure, traffic can be black-holed silently. Enable GRE Keep-Alive and/or configure a Liveliness probe on the Standard VPN endpoint to ensure failures are detected promptly.
The default Keep-Alive Interval is 10 seconds and the default Keep-Alive Retry Count is 3, meaning the ION will attempt three keep-alive packets before declaring the interface down.
Be aware of the following constraints before enabling GRE Keep-Alive:
Standard VPN Endpoint
A Standard VPN Endpoint is a label representing a specific location or network service such as a Prisma SD-WAN data center for transit services, or a third-party cloud security service.
Branch sites must have an endpoint configured on the Standard VPN interface. This allows the endpoint to be referenced in path policies to direct traffic. Endpoints can optionally specify IP addresses or hostnames of the peer device(s). Data Center sites must provide a Peer IP directly.
Note that the Peer IP always overrides any IP addresses defined in the endpoint.
Endpoints also apply to IPSec tunnels, not just GRE. When using Easy Onboarding or the Prisma Access CloudBlade, endpoints are auto-populated and no manual configuration is required.
Endpoints alone are not sufficient to route traffic. Prisma SD-WAN uses an Endpoint → Group → Domain → Site mapping model to allow a single policy to work across different sites with different underlying endpoints. After creating an endpoint, assign it to a Service & DC Group, and ensure the correct domain is bound to the appropriate sites. Without this, path policy rules referencing the group will not be effective.
Note: Prisma SD-WAN DC endpoints cannot be deleted once configured. To remove them from path selection, uncheck Admin Up on the endpoint.
GRE does not provide encryption or authentication traffic traversing GRE over the Internet is sent in plaintext. Apply a Zone-Based Firewall (ZBFW) policy to any site using GRE over an insecure transport to enforce traffic inspection and access controls between zones.
As an additional measure, implement a Source NAT policy for traffic traversing the GRE tunnel. This obscures the internal IP addressing scheme from being visible in the unencrypted GRE payload, significantly reducing the attack surface at the site.
Note: When configuring GRE tunnels via a CloudBlade integration (e.g., Zscaler), associating a Security Zone with a Security Policy bound to the site is mandatory, CloudBlade will not allow GRE tunnel configuration without it.
Prisma SD-WAN uses application identity as the foundation for path, QoS, and security policy decisions. The system includes over 4,000 built-in system applications and supports custom application definitions for traffic unique to your enterprise. Custom applications can be defined using L3/L4 characteristics (port number and optional prefix filter) or L7 characteristics (domain name via SNI). In the event of a conflict, custom applications always take precedence over system applications.
Custom application definitions consume device memory during policy compilation. Poor definition hygiene stale applications, oversized prefix lists, and full port ranges can exhaust ION memory and cause Out of Memory (OOM) failures, especially on lower-end platforms.
Scanning tools such as Nessus, Qualys, or internal vulnerability scanners generate thousands of short-lived sessions that consume significant flow table resources. By explicitly defining these tools as a custom application and enabling Network Scan App, the ION gains two operational benefits: when the site approaches its concurrent flow limit, scanning sessions are aged out first, preserving flow table capacity for business-critical traffic; and the ION suppresses application health probe generation for scanning sessions, reducing unnecessary resource consumption.
When enabling the Network Scan App, two additional settings are required. First, deselect Use Unreachability Detection. Scanner traffic generates a high volume of connections that would otherwise trigger continuous path reachability probing. Because scanning tools probe by design, this traffic behavior is expected and does not indicate a path failure. Leaving unreachability detection enabled forces the ION to unnecessarily probe paths, resulting in false reachability events. Second, set Path Affinity to None. Because scanning traffic has no session continuity requirements, pinning subsequent connections to the same path wastes resources with no added benefit.
These three settings must be configured together. Enabling Network Scan App without the other two partially negates its benefit.
To prevent policy table bloat during compilation, avoid pairing excessive /32 prefixes with broad port ranges. Each /32 entry multiplies across every combination of source zones, destination zones, and port ranges.
Follow these two best practices to optimize performance:
Stale or unused custom application definitions consume memory during policy compilation even when no traffic matches them. Periodically audit custom applications and remove any no longer referenced in active policy rules.
Note: Removing a custom application definition eliminates both policy enforcement and traffic visibility for that application. If you need to reduce memory pressure while preserving visibility, decouple the application definition from policy references rather than deleting it entirely.
Prisma SD-WAN uses stacked policies as the fundamental construct for flow forwarding and traffic engineering. Unlike traditional networks that rely on routing constructs and static ACLs, Prisma SD-WAN steers, prioritizes, and enforces application traffic entirely through policy enabling centralized, application-aware control across all sites without touching individual ION devices.
A policy stack contains ordered policy sets that are evaluated from left to right, with the left-most set carrying the highest priority. Each stack can contain up to four policy sets plus a default policy set. Once a matching rule is found, evaluation stops so rule ordering and set ordering both matter.
The five policy types each serve a distinct role:
Simple stacks contain a single policy set and are the right starting point for most deployments as they are easier to build, audit, and troubleshoot. Move to Advanced stacks only when you need layered policy sets to handle different site types, geographic regions, or traffic classes.
In an Advanced stack, place unique or site-specific rules in the left-most policy sets, and common enterprise-wide rules in the right-most sets for reuse across multiple stacks. A recommended grouping model:
Prisma SD-WAN path policy is the primary mechanism for expressing business intent for application traffic forwarding. Rather than relying on traditional IP routing, the path policy steers flows at Layer 7 — per application, per circuit category, and per service group — enabling deterministic, SLA-aware traffic engineering across all WAN transports. Path selection is performed dynamically when a new flow is created, when a path goes up or down, when an application becomes unreachable, or when link quality or application performance thresholds are exceeded.
The path selection algorithm evaluates paths in the following order:
Each Path policy stack includes two built-in default rules: default (for internet-bound traffic) and enterprise default (for RFC1918/private address space). There is no need to create additional rules that broadly match all internet or enterprise traffic. Doing so adds unnecessary complexity and can accidentally shadow more specific rules placed below them.
Configure 4G/5G as a path of last resort, explicitly in a dedicated path policy rule or as an L3 failure path only. If cellular is included in the default or enterprise-default rule, any traffic including non-critical applications like streaming media or software updates could consume metered bandwidth and result in unplanned billing events. Use the Minimize Cellular Usage setting to ensure LTE circuits are held in reserve and only activated when all primary WAN paths are unavailable.
Please note that Minimize Cellular Usage setting only controls inbound and control plane traffic. To manage outbound traffic, you must also configure an explicit path policy rule that references the LTE circuit as a Layer 3 (L3) failure path.
Note: You have to use separate Circuit Categories per circuit at each site.
Each circuit at a site must have a unique circuit category. You cannot assign the same category to two circuits at the same site, even if they are provided by different carriers. Because the circuit category defines the label used in path policy rules, using identical categories makes it impossible to differentiate between the circuits in your policies. Prisma SD-WAN provides 30 Internet categories and 30 private/public categories, ensuring sufficient granularity for any deployment scenario.
Policy Example for a Branch Site with MPLS, Internet, and LTE
Each branch location should have a primary and secondary data center defined (if available). The following traffic steering model is recommended as a starting baseline:
Generic Internet traffic: if the customer requires internet traffic inspection, traffic should be steered to the data center via Prisma SD-WAN VPN overlay, or directly to Prisma Access (or a third-party service like Zscaler) via Standard VPN. If no inspection is required, traffic should go Direct Internet Access (DIA) on the public WAN. LTE should be excluded from this rule entirely.
Generic Enterprise traffic: use any available overlay (private or public VPN) to reach the data center; permit LTE only as a last-resort path when no other path is available.
Voice Traffic: Prefer the MPLS underlay or private WAN overlay, allow the internet overlay only when MPLS performance degrades, and use LTE only as a last resort if no other path is available.
SaaS applications: use DIA as primary for optimal performance; allow MPLS overlay as backup when performance degrades; use LTE only if no other path is available.
Video Conferencing: Use DIA as the primary path, allow the MPLS overlay as a backup only when DIA performance degrades, and completely exclude LTE due to its latency sensitivity.
When multiple internet circuits are available at a site, avoid configuring them in an Active/Backup arrangement unless a specific business reason requires it. Because the ION will not shift traffic to a backup circuit during periods of high utilization, failover only occurs during a physical link-down event or a Layer 3 reachability failure, causing the backup circuit's bandwidth to sit idle while the active circuit becomes congested.
Instead, configure both circuits as active paths by selecting Any Public (or the specific circuit categories) in the path policy, allowing the ION to leverage the Best Available Bandwidth selection algorithm to continuously evaluate available bandwidth across all active paths and distribute flows accordingly.
For example, if a site has a 100 Mbps circuit with lower latency and a 1 Gbps circuit with higher latency, configuring both as active allows the ION to automatically factor in both link quality and available capacity when placing each flow, preferring the 100 Mbps circuit for latency-sensitive applications like voice while directing bulk data transfers to the 1 Gbps circuit without manual intervention.
Note that the Best Available Bandwidth feature operates at the flow level rather than per-packet, ensuring that session symmetry is always preserved.
In traditional networks, an Active/Backup configuration means the backup path remains completely dormant and is only utilized when the active path goes physically down. Prisma SD-WAN behaves differently; the ION will dynamically move flows to the backup path even while the active path is still up if any of the following conditions are met:
This is by design, enabling the SD-WAN to self-heal and maintain application SLAs without waiting for a physical link failure.
If the intent is true legacy Active/Backup behavior where the backup path is only used on a hard link or L3 failure—and never for performance-based steering—configure the backup circuit under the L3 Failure path option in the path policy rule instead of the Backup path. This ensures the ION treats that circuit strictly as a last resort and will not move flows to it based on LQM or application reachability conditions.
This distinction is especially important for metered circuits like LTE, where unintended traffic migration due to LQM conditions can result in unexpected data consumption and billing.
DC Groups are the mechanism for controlling which data centers a branch uses for transit traffic and in what order. When the Required checkbox is selected for a DC Group in a path policy rule, traffic will always transit through the specified DC, completely excluding direct underlay paths. When Required is deselected, the DC Group acts as a preference: the system will use direct paths first and fall back to the DC transit paths only when direct paths are unavailable or breach SLA compliance.
The ION device uses DC Service Groups in the path policy only when it does not have a more specific route to the destination. If the DC is already advertising its prefixes into the Prisma SD-WAN fabric, the ION will route traffic to those prefixes directly without relying on the DC Service Group, rendering the Service Group redundant in that scenario.
However, when a DC does not advertise any prefixes—for example, in a dual-DC deployment where neither DC advertises specific subnets—the ION has no routing information to make a forwarding decision. In this scenario, the DC Service Group in the path policy rule is what tells the ION which DC to use for transit. By default, a default route ($0.0.0.0/0$) is advertised across all Prisma SD-WAN VPNs, so internet-bound traffic will always find a path; however, for specific enterprise destinations that are only reachable via a DC, the Service Group must be explicitly configured in the path policy rule to ensure deterministic forwarding.
Create an explicit path policy rule for the paloalto-prisma-sdwan-base application (and pan-db-cloud / paloalto-dns-security when Branch Security Cloud-Delivered Security Services are in use) that references all available paths as active. Place this rule above the default rules in the policy set. This ensures device-to-controller connectivity and application health probing are never interrupted by policy, regardless of WAN conditions.
If any WAN paths have security appliances performing SSL decryption, those paths must either be excluded from the control app rule, or the Prisma SD-WAN controller FQDNs/IPs must be added to the SSL decryption exclusion list on those appliances.
Application Reachability Probes are essential for Prisma SD-WAN path selection; without them, the ION cannot validate end-to-end application availability across different paths, causing path selection to fall back strictly to link-level metrics. Ensure Application Reachability Probe is enabled and the source interface is set to one that has connectivity to all user-accessible applications. On Gen1 ION devices, the controller port is used by default; however, on devices where the controller port is connected to an out-of-band management network, use a LAN port instead. An incident is automatically generated when application probes are disabled, providing immediate visibility into any misconfiguration.
Prisma SD-WAN does not actively probe all applications at all times. Application Reachability Probes are triggered reactively when the ION detects a TCP 3-way handshake failure (Init Failure) for LAN-initiated traffic on a specific path, it crafts a synthetic probe packet that mimics the original failed TCP SYN on that path. If the synthetic probe also fails to establish a TCP connection, the path is automatically marked as unusable for that specific application, destination prefix, and path combination. The ION then continues sending a probe every 60 seconds to check if reachability has been restored. Once the probe succeeds, that path is considered again for path selection for that application.
For UDP DNS traffic (supported from release 6.3.2), the ION starts a DNS probe when a DNS reachability failure is detected. If the DNS server does not respond, the ION probes once every minute for the first three probes, then drops to once every 5 minutes until reachability is restored.
If a circuit is configured as a last-resort path (such as LTE), consider disabling application probes on that circuit to prevent unnecessary probe traffic from consuming metered bandwidth. This behavior can be managed per circuit using the Use for Application Probes setting within the circuit configuration.
The ION monitors communication only for TCP flows initiated from the LAN side and triggers probes based on TCP three-way handshake failures. All TCP applications have unreachability detection enabled by default, which can optionally be disabled per custom application. UDP traffic is not monitored for reachability—the only exception is UDP DNS traffic, which is supported from release 6.3.2 onwards. For SSL or unknown applications that are not identified from the first packet, the probe still functions because it mimics the original TCP SYN on that path; the reachability check remains entirely TCP-based regardless of the final application classification.
Consequently, for voice and video applications that utilize UDP (such as RTP), the ION will not trigger application reachability probes if those flows fail. Path selection for UDP media traffic relies strictly on LQM metrics and Performance Policy SLA thresholds rather than application reachability probes. This is a critical distinction to understand when designing SLA enforcement for real-time media applications.
L3 Reachability Probes are distinct from Application Reachability Probes. They are triggered specifically when all VPNs on a WAN interface go down and there is no inbound traffic on that circuit; at that point, the ION has no way to determine if the underlying internet circuit itself is still functional. To verify the true usability of the circuit, the ION automatically generates probes to the following default endpoints:
If these probes fail, the circuit is considered down at L3 and is removed from path selection entirely. This is important to understand a circuit can appear physically up at Layer 1/2 but still be marked as unusable by the ION if none of these L3 reachability endpoints are reachable, for example in a captive portal scenario or when the ISP has a routing issue upstream.
Starting from release 6.4.1, L3 Reachability probes can optionally be configured to use the results of Service Health Probes instead of the default endpoints, giving administrators more control over what determines circuit reachability for example, using a customer-owned endpoint instead of public Google or Apple addresses.
In some enterprise environments, outbound ICMP or HTTPS to public internet addresses may be restricted by upstream security policies or firewalls. In these cases the default L3 probes will fail even when the circuit is healthy, causing the ION to incorrectly mark the circuit as down. From release 6.4.1 onwards, configure Service Health Probes pointing to known reachable endpoints and use those as the basis for L3 Reachability determination to avoid false circuit failures.
Path Affinity controls whether subsequent connections from the same client for the same application stay on the same path. This is important for applications that break when the NAT boundary changes mid-session for example, UCaaS, ERP, and database applications that maintain persistent server-side session state tied to the client IP. There are three affinity modes:
The system default is None for most applications, with the exception of HTTP, SSL, IPsec, and Ariba which default to Required. For applications where changing the NAT boundary mid-session causes failures such as VoIP registration, ERP sessions, or any stateful application configure affinity to Required or Required Strict. Avoid setting Required Strict broadly across all applications as it prevents the ION from moving flows to a better path even when quality degrades.
Network Context allows you to segment LAN traffic and apply different path policy rules for the same application depending on the originating LAN network. For example, guest traffic and corporate traffic can have completely different path policy rules for the identical application: guest internet traffic can be sent direct-to-internet, while corporate traffic is backhauled through a data center for security inspection. A rule with a configured Network Context always takes precedence over a rule without one. Note that an individual LAN network can only belong to a single Network Context.
The path selection algorithm evaluates rules from top to bottom and stops at the first match. If a flow does not match any explicit rule, it falls through to the built-in default rule (internet-bound) or enterprise-dafult rule (RFC1918-bound). This is by design and serves as a safety net. However, be aware that if all active paths within those default rules are unavailable and no backup paths are defined, the flow will be dropped. Always validate that the default and enterprise-dafult rules have appropriate active and backup paths defined for the site's actual WAN transport types.
If the path selection algorithm yields no valid paths—for example, if all paths are down or marked unreachable for that application—the flow is dropped. Instead of silently blackholing the traffic, the ION tracks the flow and re-evaluates it the moment a valid path becomes available again.
This behavior is important to keep in mind during troubleshooting: when a flow is not being placed on a path, it does not necessarily indicate a policy misconfiguration. Rather, it often means that all allowed paths are genuinely unavailable or are failing their respective reachability checks.
Prisma SD-WAN QoS prioritizes application traffic on WAN interfaces using the Hierarchical Fair Service Curve (HFSC) algorithm. Unlike traditional Class-Based Weighted Fair Queueing (CBWFQ), which treats all applications within a class identically, HFSC provides hierarchical link-sharing and can decouple bandwidth allocation from delay. This makes it particularly effective for latency-sensitive, real-time traffic. QoS is enforced exclusively on the WAN interfaces at the branch site level; it is not applied on the data center side, as DC circuits do not utilize a configured upload/download speed for shaping purposes.
The circuit Upload Speed and Download Speed settings configured at the branch site serve as the reference bandwidth thresholds that trigger QoS engagement. Once active, QoS distributes that available bandwidth across 16 distinct queues according to your configured bandwidth ratios. Accurate circuit speed configuration is therefore a strict prerequisite for QoS to function correctly—if the circuit speed is omitted, QoS will not engage.
Prisma SD-WAN QoS organizes traffic into 4 priority classes, each containing 4 transfer type sub-queues, resulting in 16 total queues:
The Application Category has no effect on how a flow is queued. Instead, the sub-queue is determined strictly by the Transfer Type configured within the application definition: Bulk, Transactional, Real-time Audio, or Real-time Video.
For example, a voice application assigned to the Platinum priority class will land in the Platinum-Audio queue only if its Transfer Type is explicitly set to Real-time Audio. If the Transfer Type is mistakenly left as Transactional, it will land in the Platinum-Transactional queue instead, which does not provide the same stringent delay guarantees. Always verify that the Transfer Type is correctly defined, especially when creating custom applications or applying system application overrides.
When you create a custom application, you must explicitly define its Transfer Type, which dictates its assigned sub-queue. However, the priority class is not mapped automatically; the custom application will inherit the default QoS policy rule (which maps to the Bronze priority class for best-effort treatment) until you create a dedicated QoS policy rule matching that application and assign it to your desired priority class.
This is a common administrative oversight: creating a custom application expecting it to be prioritized, but leaving it without a corresponding QoS policy rule, resulting in the traffic receiving standard best-effort treatment.
The Default QoS rule catches all flows that do not match any explicit rule and assigns them Bronze/best-effort priority. Any application that requires higher priority whether a system application or a custom application must have an explicit QoS policy rule created for it. The ION also performs continuous re-classification and re-queuing: if a flow is initially classified as SSL on the first packet and later re-identified as a specific SaaS application, it will be automatically re-queued into the correct queue for that application once the classification is updated.
The Flow Browser (Insights > Prisma SD-WAN > Branch Sites > Flows) shows per-flow details including the QoS Policy Set, QoS Policy Rule, Traffic Type, Priority Class, and DSCP markings in both LAN-to-WAN and WAN-to-LAN directions. This is the primary tool for verifying that flows are being queued as intended and for troubleshooting QoS misclassification.
By default, the ION classifies and prioritizes traffic based on App-ID rather than incoming DSCP markings. However, DSCP mapping can be configured within the QoS policy set to honor incoming DSCP values for unknown or unclassified flows, and QoS policy rules can be configured to re-mark DSCP on outgoing packets in the LAN-to-WAN direction. This capability is useful when a WAN carrier enforces QoS based on DSCP or when downstream devices must honor the ION's classification.
The default Prisma SD-WAN DSCP mapping follows standard industry recommendations:
|
Incoming/Outgoing DSCP |
Priority Class |
Transfer Type Sub-Queue |
|
EF |
Platinum |
Real-time Audio |
|
CS6 |
Platinum |
Transactional |
|
AF41 / AF31 |
Gold |
Real-time Video |
|
AF21 |
Silver |
Transactional |
|
AF11 |
Bronze |
Bulk |
QoS does not actively prioritize or queue traffic when a circuit has ample available bandwidth; it engages only when traffic utilization approaches the configured circuit Upload Speed or Download Speed thresholds. At that point, the ION begins enforcing bandwidth ratios and prioritizing higher-class queues over lower-class ones.
The primary enforcement occurs in the egress (LAN-to-WAN) direction, where the ION performs full prioritization, queuing, and shaping based on the configured upload circuit speed. Ingress QoS is also applied to traffic arriving from the WAN (WAN-to-LAN direction) based on the download circuit speed. This QoS enforcement is aggregated across all traffic traversing a WAN interface, meaning that direct underlay, SD-WAN VPN overlays, and Standard VPNs are all included in the same bucket.
Prisma SD-WAN provides an out-of-the-box Source NAT configuration that automatically translates outbound traffic destined to public internet interfaces using the IP address bound to that interface. For most branch deployments this default behavior is sufficient and requires no additional configuration. Additional NAT capabilities include Destination NAT, Static Source NAT, Static Destination NAT, and ALG Disable each addressing specific use cases as described below.
The Default NAT Policy Set Stack is automatically applied to all sites and contains a default internet rule that performs Source NAT (SNAT) on all outbound traffic destined for public internet interfaces. By default, the ION uses the specific IP address assigned to the outbound internet interface as the NAT pool. This configuration seamlessly covers the most common enterprise use case: enabling internal users with private IP addresses to access the internet without requiring any additional, manual configuration.
When external entities must reach internal servers or devices utilizing private IP addresses—such as a physical security camera system or an internally hosted web application—configure a Destination NAT (DNAT) rule. The ION will translate the publicly routable destination IP address to the internal private IP address of the target server. Additionally, the ION automatically transmits Gratuitous ARP (GARP) messages and responds to incoming ARP requests for any configured NAT pool addresses on that internet interface, ensuring upstream routers can successfully route the traffic to the device.
For inbound DNAT to work correctly both of the following must be in place:
If ZBFW is also enabled on the site, a security policy rule permitting the inbound traffic from the internet zone to the internal zone is additionally required. Missing any of these will result in traffic being dropped. Use the Flow Browser to verify which policy is blocking the traffic when troubleshooting inbound DNAT failures.
Static Source NAT and Static Destination NAT provide 1:1 mapping between a range of public IP addresses and a range of private IP addresses. This is needed when each internal server must have a unique persistent internet IP address, or when two overlapping RFC1918 address spaces need to communicate after a merger or acquisition.
Most UCaaS providers (Webex, Zoom Phone, RingCentral, Microsoft Teams Direct Routing) require that SIP ALG be disabled for any traffic crossing a NAT boundary destined for their SIP infrastructure. SIP ALG modifies SIP headers in ways that break phone registration and cause one-way audio issues. Create an explicit NAT policy rule with the ALG Disable action matching the SIP traffic source prefix and apply it to the relevant NAT stack. This rule should be placed in a separate NAT policy set alongside the default internet rule within the same stack.
If certain traffic must bypass NAT entirely—such as VPN-bound traffic or traffic routed between two private subnets—create an explicit NAT rule utilizing the No NAT action. When No NAT is selected for a rule, it stands alone, meaning no other NAT actions can be combined within that same rule. Always position No NAT rules higher in the policy set order than the default Source NAT rule to ensure they are matched and processed first.
NAT zones must be created and bound to the relevant interfaces for your NAT policy rules to become active.
It is important to note that the NAT zones used in NAT policy rules are completely separate from the security policy zones utilized in Zone-Based Firewall (ZBFW) rules; they are configured independently under Policies > NAT > NAT Zones. A common administrative mistake is creating NAT rules without binding the corresponding NAT zone to the physical or logical interface, which results in NAT failing to apply even though the policy rule itself is perfectly valid.
All NAT policy configurations—including Source NAT, Destination NAT, Static NAT, and Application Layer Gateway (ALG) Disable—apply exclusively to branch ION devices. Data center sites do not support NAT policies, and the policy binding step is completely unavailable when configuring a DC site; the SCM UI explicitly states "Policies apply only to branch sites" during DC site setup.
If NAT is required for traffic passing through a data center (for example, to support Direct Internet Access at the DC hub), this function must be handled by an upstream firewall or security appliance rather than the DC ION device itself.
When a branch has two internet circuits the default Source NAT translates the source IP to the IP address bound to whichever interface the traffic exits through. The ION guarantees path symmetry by keeping all packets belonging to the same flow on the same circuit from start to finish preserving the NAT boundary for the lifetime of the session. This is a fundamental difference from traditional router-based ECMP which load-balances at the packet level and can break NAT by sending return traffic through a different interface.
In Active/Active dual-internet deployments the ION load-balances at the flow level not the packet level each new flow is placed on the best available circuit, but once placed it stays there until the session ends or a path failure forces a move.
Performance Policy provides a flexible framework for the assurance of Application and Network SLAs. It is supported on ION devices running software version 6.3.1 and higher and is applied at the branch site level. The system automatically assigns a default policy stack to every site upon upgrade to 6.3.1 or higher providing basic SLA enforcement out of the box without any additional configuration required.
Performance Policy supports two rule types. App/Network SLA rules use Link Quality Metrics, Application Metrics, and Service Health Probe metrics to monitor and enforce path quality for application traffic. System Health rules use device and circuit resource metrics CPU, memory, disk, circuit utilization, and concurrent flows to generate incidents when device health thresholds are breached.
The available actions are Create Incident, Visibility, Move Flows (Graceful or Forced), FEC, Packet Duplication and app acceleration. These actions have dependencies Move Flows must be enabled before FEC or Packet Duplication can be used, and FEC and Packet Duplication are mutually exclusive with each other. FEC and Packet Duplication only apply to Prisma SD-WAN VPN paths and are triggered exclusively by packet loss via Link Quality Metrics. App Acceleration directly addresses the causes of poor application performance and acts in real-time to mitigate them, dramatically improving the user experience for Prisma SD-WAN users.
Performance Policy uses explicit rule ordering. More specific rules—such as those matching a specific application, path, or DC group—must be placed above less specific rules. A rule with no match criteria will match all traffic, shadowing and effectively neutralizing any rules configured below it.
Prior to release 6.3.1, performance-based path selection thresholds were configured through the Advanced menu within the individual circuit settings.
As of release 6.3.1, the device no longer uses that Advanced Menu configuration, and it is completely ignored. All threshold metrics must now be reconfigured as explicit Performance Policy rules within a policy set bound directly to the site. Failure to migrate these settings after upgrading to 6.3.1 or later means the device will operate without any performance-based path selection in place until these dedicated rules are created.
The system automatically creates three default rules that cannot be removed:
Any explicit rule you configure takes precedence over the defaults based on rule order. You can edit the SLA threshold values in the default rules but cannot delete the rules themselves.
Move Flows Graceful moves only new flows away from a path that violates the SLA; existing flows stay on their current path for up to 10 minutes before being moved. With Application Metrics SLA, only new flows are redirected. With LQM SLA, both new and existing flows are moved to the optimal path when performance degrades.
Move Flows Forced immediately moves both new and existing Fabric VPN flows regardless of the NAT boundary. If no better path is available it will still move the flow to the best available path even if that violates the NAT boundary. Use Graceful for most applications to avoid mid-session disruptions and reserve Forced for real-time applications where immediate remediation is critical.
Move Flows Forced is triggered by the following events: Layer 3 Unreachability, LQM SLA Violation, App Unreachable, Synthetic Probe SLA Violation, Service Link Up or Down, Flow Revalidation, and DC Core Reachability with Host Tracking. The Flow Decision Data in the Flow Browser shows whether a flow was forcefully moved and which event triggered it.
If a Performance Policy rule is configured with LQM SLA thresholds but the Move Flows action is not selected, the system will ignore Link Quality Metrics during path selection for that rule. Always pair LQM SLA thresholds with a Move Flows action for the thresholds to have any effect on traffic steering.
When configuring Application Metrics SLA thresholds the Monitoring Approach setting controls how much weight is given to recent measurements versus historical data. Aggressive approach gives more weight to recent traffic measurements making incident generation and path switching more sensitive to sudden changes — use this for real-time applications like voice where quick reaction is critical. Moderate is the default and provides a more balanced response — use this for most business applications to avoid unnecessary path switching from brief transient spikes.
Configuration > Prisma SD-WAN > Policies > Performance
LQM must be enabled on internet circuit categories for the ION to have accurate latency, jitter, and packet loss data on those paths. Without LQM enabled on internet circuits, Performance Policy thresholds will not trigger correctly for DIA or internet overlay paths.
Adaptive Mode enables FEC or Packet Duplication only when a Prisma SD-WAN VPN path exceeds the packet loss threshold specified in the SLA. This is the recommended approach as it conserves platform resources and only engages when needed.
Always ON Mode enables FEC or Packet Duplication continuously, regardless of link performance. Use this only for mission-critical applications where maximum protection is required at all times and platform resource capacity allows it. Be mindful of the platform VPN limits when using Always ON, as it will permanently consume encoding slots for those flows.
FEC is effective for packet loss between 1% and 10% and must be enabled together with Move Flows. Packet Duplication requires ION 6.4.1 or higher and replicates sessions across up to three VPN paths simultaneously. FEC and Packet Duplication are mutually exclusive. When both are applied simultaneously on traffic from the same VPN they count as a single VPN instance toward the platform limit. The maximum VPNs actively encoding recovery information varies by platform — ION 1000/1200/2000 supports 8 VPNs, ION 3000/3200 supports 16 branch VPNs, ION 5200/7000 supports 32 branch VPNs, and ION 9000/9200 supports 64 branch VPNs. ION device version 6.3.2 or higher is recommended for FEC and 6.4.1 or higher is required for Packet Duplication.
Two metrics determine whether a performance policy remains within platform limits: the total number of rules and the total number of application IDs matched across those rules. To calculate your current footprint, multiply the total rule count by the number of application IDs defined within each rule, and compare the result against the platform maximum.
Platform limits vary by model family:
|
ION Model |
Rule Count |
Max Rules x Apps |
|
1000 |
30 |
150 |
|
1200 |
50 |
250 |
|
1200-S |
200 |
1275 |
|
2000 |
50 |
1275 |
|
3000 |
255 |
1275 |
|
3200 |
255 |
1275 |
|
5200 |
255 |
1275 |
|
9000 |
255 |
1275 |
|
9200 |
255 |
1275 |
Additionally, be aware that if a specific function configured within a rule is not supported by the device's current software version, the ION will ignore the entire rule, rather than just disabling the unsupported function. Always verify feature compatibility across your deployment before pushing updated performance policies.
Service Health Probes allow you to actively measure reachability and performance to specific endpoints even when there is no active user traffic on that path. This is particularly useful for backup path health verification and monitoring third-party service endpoints. Supported probe types are HTTP/S, DNS, and ICMP. Requires ION 6.4.1 or higher.
App Acceleration is configured as a Performance Policy action and applies to direct internet path traffic only. It provides TCP optimization through L4 acceleration techniques improving throughput on high-latency or lossy internet paths without requiring client-side changes. SaaS app acceleration additionally provides L7 acceleration using predictive caching and API prefetching. Network optimization requires ION 6.4.2 or higher and SaaS app acceleration requires ION 6.5.2 or higher. Both require an App Acceleration license.
Prisma SD-WAN includes a stateful, application-aware Zone-Based Firewall (ZBFW) that secures the WAN perimeter and enables traffic segmentation within the branch. ZBFW policies supersede network (path) policies if a ZBFW rule denies traffic it will be dropped regardless of what the path policy allows. The ZBFW operates on the concept of zones where each zone maps to one or more physical or logical interfaces, and rules control traffic between zone pairs.
Every security policy set includes three default rules that cannot be edited or deleted: Intra-Zone (allows traffic within the same zone), Self-Zone (allows traffic to and from the ION device on trusted interfaces), and Default (denies all inter-zone traffic). These defaults provide a basic deny-by-default posture out of the box.
When no security policy stack is attached to a site, there is no active traffic filtering; all traffic is permitted with the sole exception of unsolicited inbound traffic on internet (public WAN) interfaces, which is always dropped by default.
This means a site without an attached security policy is not completely exposed—the internet perimeter remains inherently protected. However, all LAN-to-WAN, LAN-to-LAN, and VPN traffic will flow freely without restriction. The moment a security policy stack is attached to the site, the system enforces its three built-in default rules, and all inter-zone traffic that is not explicitly permitted will be denied.
If a zone is not bound to an interface or subnet, all traffic on that interface is blocked. An interface without a zone assignment will silently drop all traffic; this is one of the most common ZBFW deployment mistakes.
It is highly recommended to use device-level bindings. While both device-level and site-level bindings can technically be configured simultaneously, device-level bindings will take precedence in the event of a conflict. However, running both at the same time is not recommended as it can cause unexpected behavior and complicates troubleshooting.
Configuring rules with empty source or destination zones is not recommended. This creates a very large number of policy table entries during compilation and can lead to Out of Memory (OOM) issues and system instability particularly on lower-memory platforms such as the ION 1000, ION 1200, and ION 2000. Always explicitly specify source and destination zones in every rule.
The default deny rule blocks all inter-zone traffic that is not explicitly permitted. Without explicit allow rules for internet-bound and WAN-bound traffic, legitimate outbound traffic from LAN zones to the internet or VPN zones will be dropped.
To prevent this, define your zone model clearly—typically using three to four zones covering corporate LAN, guest LAN, internet/WAN underlay, and corporate WAN/VPN—then create explicit rules for each required traffic flow between zone pairs.
The ZBFW evaluates rules from top to bottom within a policy set and stops at the first match.
Because of this top-down execution, more specific rules—such as those matching specific applications, IP prefixes, or zone pairs—must be placed above broader, more general rules. The built-in Intra-Zone, Self-Zone, and Default rules are always evaluated last as a final catch-all.
Keep application-based rules and port/prefix-based rules in separate rules. Mixing them in the same rule makes the policy harder to manage, audit, and troubleshoot. It also complicates analysis when trying to understand why traffic was allowed or denied.
A Destination NAT rule alone is not sufficient when ZBFW is enabled. A ZBFW rule must also explicitly permit the inbound traffic from the internet zone to the internal zone. Without this rule the traffic will be dropped by the default deny rule even after successful NAT translation.
Before enforcing a new security policy rule in production use the Monitor Rule setting to observe traffic matching without blocking it. The Flow Browser (Insights > Prisma SD-WAN > Branch Sites > Flows) shows the Security Policy Rule applied to each flow, the source and destination zone, and the action taken making it the primary tool for validating that traffic is being handled as intended and for troubleshooting unexpected drops.
The most critical risk factor is combining "Any source zone" with "Any destination zone" alongside large prefix lists, which can be catastrophic for memory-limited devices. Furthermore, using full port ranges (1–65535) creates 65,535 individual port entries in the policy table, multiplying memory requirements by orders of magnitude. To mitigate this, aggregate prefixes into larger subnets where possible, and specify exact port ranges rather than wide-open defaults. You should also regularly audit and remove stale or unused custom application definitions, as they continue to consume memory during compilation even when no active traffic matches them.
Before making significant security policy changes, always assess current memory utilization using Strata Copilot, or navigate to Insights > ION Devices > Device Activity to review historical memory utilization graphs. Finally, apply changes incrementally and schedule updates during designated maintenance windows to minimize operational impact.
If an Out of Memory (OOM) condition occurs after applying a large security policy update, the device may reboot, become unstable, or lose connectivity to the controller. If this happens, follow these recovery steps in order:
Prisma SD-WAN supports identity-based policy enforcement, allowing path, QoS, and security policies to match specific users or user groups rather than IP addresses alone. A data center ION device learns IP-to-user mappings from a User-ID Agent running on a PAN-OS firewall and pushes them to the controller. The controller queries CIE for user-to-group mapping, then distributes the combined mappings to branch sites. Branch ION devices enforce the policies and tag site-to-site VPN traffic with user identity so remote branches can apply User-ID policies to inbound flows.
Note: User-ID based policies are supported for branch-to-branch traffic over direct SD-WAN tunnels only. Traffic originating from or transiting through a data center is not supported.
Both a PAN-OS firewall license and a Cloud Identity Engine activation must be present in the same TSG as Prisma SD-WAN. Cross-TSG configurations are not supported.
The User-ID client runs exclusively on data center ION devices. Configure the connection under Configuration > Prisma SD-WAN > Data Centers > [DC Site] > Configure User Agent. PAN-OS versions 10.1.7, 10.2.3, 11.0.x, or higher are required.
These two methods are mutually exclusive. User-ID Agent learns mappings from a PAN-OS NGFW. CUID fetches mappings directly from Cloud User Context via CIE and is configured under Configuration > Prisma SD-WAN > System > Cloud Identity Engine. Choose based on your architecture; CUID is preferred when Prisma Access is the identity source.Router ID
The controller distributes IP-to-user mappings to branch sites based exclusively on known prefixes. These prefixes must be learned through Global interfaces, site-level prefix additions, or Global BGP/OSPF routes.
Branches that do not have matching prefixes defined will not receive these user mappings, rendering User-ID policy enforcement completely ineffective for those locations.
An explicit username takes priority over a group name, which takes priority over Any/Known/Unknown. Selecting Any automatically disables the Group field. Place more specific rules above broader ones within the same policy set.
Branch Security extends Prisma SD-WAN with Cloud Delivered Security Services (CDSS) enforced directly on the ION device at the branch without requiring traffic to be backhauled to a data center or cloud security service for inspection. It is a subscription-based feature managed through Strata Cloud Manager and is supported starting with ION device software release 6.5.3-I.
The supported security services are Anti-Spyware, Vulnerability Protection, DNS Security, and URL Access Management. Note that Inline Cloud Analysis and Advanced URL Inline Categorization are not currently supported on ION devices.
A Branch Security subscription license is required to access Security Profile Group configuration and enforcement on ION devices. Additionally a separate Strata Logging Service (SLS) license is required to log traffic and security events centrally. Confirm both licenses are active before deploying.
All security service profiles used by Prisma SD-WAN must be created under Configuration > NGFW and Prisma Access > Security Services with the Configuration Scope set to Global. Profiles created under any other scope will not be available for use in Prisma SD-WAN security policy rules.
A Security Profile Group bundles Anti-Spyware, Vulnerability Protection, DNS Security, and URL Access Management profiles into a single, cohesive object that is applied to a ZBFW security policy rule.
Within the system architecture, you can only attach a Security Profile Group to an SD-WAN security policy rule; individual profiles cannot be attached directly to rules on their own. To streamline deployment, a default, best-practice Security Profile Group is automatically created for you and serves as an excellent starting point.
When Branch Security is enabled, create dedicated path policy rules for pan-db-cloud and paloalto-dns-security with higher priority than the default rule and allow on all paths. Without these rules connectivity to the cloud security services may be interrupted by path policy decisions causing threat prevention and DNS security enforcement to fail silently.
Send security event logs to Strata Logging Service (SLS) to maintain a comprehensive audit trail for compliance frameworks such as PCI, HIPAA, and GDPR.
You can utilize the Flow Browser (Insights > Prisma SASE > Branch Sites > Flows), which includes dedicated Branch Security fields. These fields provide visibility into threat IDs, categories, severities, actions taken, URL classifications, and DNS security details. You can also filter flows by Session End Reason to quickly identify sessions that were terminated specifically by security services.
To ensure events are reporting correctly, verify the connection status of both Cloud Security Services and the Logging Service under Configuration > Prisma SD-WAN > Devices > Claimed Devices.
Prisma SD-WAN ION devices support static routing, BGP, and OSPF at both branch and data center sites. The SD-WAN controller acts as the central routing intelligence routes learned at any site are advertised to the controller which distributes them across the fabric. Understanding the Local vs Global scope setting is critical throughout all routing configuration Local keeps routes on the device only, Global shares them with the rest of the fabric.
Learning a default route from a core BGP peer on the hub device is sufficient for normal operations. However, configuring a static default route with a higher administrative distance provides an important safety net; if the BGP-learned default route is withdrawn due to a misconfiguration, the static route ensures traffic continues to be forwarded to the core peer.
When configuring this backup static route, enable the Next Hop Reachability Probe feature. This allows the ION to continuously monitor the next hop via ICMP, automatically invalidating the route and preventing traffic from being blackholed if the next hop becomes unreachable.
Local scope means the route is used exclusively for local forwarding on that specific device and is not shared with the controller or remote sites.
Misconfiguring the scope to Local is one of the most common routing issues in an SD-WAN deployment. When this happens, the prefix will not be reachable from other branches, even if it is correctly installed in the local routing table.
L3 Direct Private WAN Forwarding must be explicitly enabled on the ION device (Configuration > ION Devices > Claimed > [Select Device] > Basic Info) before the device can establish a BGP peering relationship with a router via a private WAN interface.
Additionally, you must enable both L3 Direct Private WAN Forwarding and L3 LAN Forwarding when using dynamic routing on the LAN side of the deployment. Note that L3 LAN Forwarding cannot be enabled if Private Layer 2 bypass pairs are currently associated with any interface on the device; these pairs must be removed before the feature can be turned on.
MD5 authentication protects BGP sessions against hijacking and unauthorized route injection by creating a digest of each BGP packet exchanged. The receiving peer regenerates the digest using the same secret and rejects packets that do not match. Configure the MD5 secret in the BGP global configuration or per peer (1-32 characters).
Core Peers connect to the LAN core switch or router and attract branch-destined traffic by injecting more specific routes.
Edge Peers connect to the MPLS WAN edge router and are only necessary when traffic must flow natively over the MPLS underlay. If all MPLS traffic is sent securely over the encrypted SD-WAN overlay, Edge peering is not required. In these overlay-only deployments, the data center (DC) ION only needs Core peering to the LAN switch/router. If Edge peering is used, ensure the correct circuit label for the MPLS circuit is attached to the MPLS-facing interface on the DC ION.
Classic Peers behave like standard BGP peers. They are the only peer type supported at branch sites and do not auto-generate route maps.
Note that route maps are automatically generated by the system for Core and Edge peers, simplifying configuration.
For LAN-side peers set to Global the ION advertises learned routes to all other global scope LAN peers, WAN-side peers, and to the controller making them reachable from remote branches. For WAN-side peers set to Global the ION only advertises to LAN-side peers not to the controller or other WAN-side peers. Local scope on either side prevents routes from being shared beyond that peer.
After modifying a prefix list, AS path list, or IP community list associated with a BGP peer, always perform a soft reset. This forces BGP to re-evaluate its routing policies and apply the changes immediately without tearing down the underlying TCP session.
Conversely, a hard reset tears down the entire BGP session and flushes all learned routes from that peer, causing unnecessary traffic disruption.
You can redistribute BGP, connected, or static routes into OSPF and vice versa. Without redistribution prefixes learned from one protocol will not be available to the other.
From ION software version 6.6.1, the BGP Router ID is configured globally per VRF under Configuration > Prisma SD-WAN > ION Devices > [Device] > Routing > BGP Global Parameters > Router ID tab, rather than per individual peer. This ensures all BGP peers within the same VRF use a consistent Router ID, preventing configuration conflicts.
Availability and Compliance: OSPF is supported on the LAN side at both branch and data center (DC) sites starting with release 6.4.1, and is fully compliant with RFC 2328 for IPv4. Note that OSPF is not supported on Switched Virtual Interfaces (SVIs).
Protocol Coexistence: Branch site LANs support either BGP or OSPF, but both routing protocols cannot be enabled simultaneously on the same LAN segment.
Route Redistribution: Set the OSPF scope to Global when prefixes learned via OSPF need to be advertised and distributed to remote branch sites across the SD-WAN fabric.
Area Configuration: Select the correct area type (Normal, Stub, or NSSA) to properly match and integrate with your existing enterprise OSPF architecture.
VRF isolates traffic from different departments, locations, or security tiers over the same WAN overlay. When traffic enters a VRF-configured interface it only considers destinations within the same VRF. Traffic crossing the fabric is automatically encapsulated with a unique VRF identifier and decapsulated at the remote ION into the correct VRF. VRF Definitions and Profiles are configured globally under Configuration > Prisma SD-WAN > Profiles and Templates > VRF and then bound to sites. The Global VRF is the default and cannot be deleted. Ensure the correct VRF is selected when configuring interfaces, BGP peers, and static routes VRF context is set at the interface level.
Route Leak Rules allow specific prefixes to be shared between two VRFs without fully merging their routing tables. Specify the source VRF, destination VRF, and the exact IPv4 prefix to be leaked.
Prisma SD-WAN automatically enables internet access per VRF segment when a path policy rule for internet-bound traffic is configured. Stateful NAT is applied with full VRF and session context awareness ensuring return traffic routes correctly back to the originating client within the correct VRF segment.
Host Tracking monitors LAN reachability beyond the core BGP peer by sending ICMP probes to a designated downstream IP address. Branch ION devices maintain active tunnels to the data center (DC) ION as long as that tracked IP remains reachable. If the tracked IP becomes unreachable, the tunnels to that DC ION are marked inactive, causing branch traffic to automatically switch to the peer DC ION in the High Availability (HA) pair. Additionally, when core connectivity fails, the affected DC ION automatically redirects any remaining branch traffic to alternative overlay paths within the same data center, preventing traffic blackholes. To ensure optimal performance, always configure Host Tracking with a highly stable, representative IP address located beyond the immediate core peer—such as a core switch loopback or a reliable internal service—to accurately reflect true LAN reachability.
Asymmetry can occur when outbound and return traffic take different paths causing traffic to bypass security inspection or violate policy. This is automatically detected and corrected no additional configuration is required.
Routes learned via BGP or OSPF on the data center (DC) LAN are not automatically distributed to all branches. To enable this redistribution, you must explicitly configure it under Configuration > Data Centers > [Select Site] > Sites.
Conversely, global static routes and site prefixes are automatically distributed throughout the fabric by the controller and do not require this manual configuration.
When large prefix aggregation is configured on DC IONs the core router may treat summary advertisements from both DC IONs as ECMP and send traffic to the wrong DC ION. Configure the Intra Cluster Tunnel under Configuration > Data Centers > Advanced > Configure Intra Cluster Tunnel to redirect misrouted traffic to the peer DC ION that has the active VPN to the destination branch.
Secure Fabric tunnels between DC sites support HA, multi-pathing, and load sharing across multiple links and can connect on-premises and cloud environments including AWS, Azure, Equinix, and GCP. Configure under Configuration > Prisma SD-WAN > Data Centers > Overlay Connections > Add Secure Fabric Link. After upgrading to 6.5.1 all existing BGP peers on inter-DC tunnels are automatically set to Local scope to prevent routing loops change to Global explicitly if you need to distribute learned prefixes. Prisma SD-WAN never distributes prefixes learned on inter-DC VPNs to other DCs or to branch sites regardless of scope.
Prisma SD-WAN distributes global prefixes from the source DC ION to other DC sites over Secure Fabric tunnels. Prefixes eligible for distribution include global static routes, WAN path prefixes from branch or branch gateway sites with hop count of 1, site prefixes, and BGP/OSPF global learned prefixes. Configure an Overlay Prefix Filter using a prefix list on the source DC ION to control distribution.
For NAT-to-NAT scenarios, configure one site as Initiator Only (we need TAC engagement for this) and the other site with Passive Mode enabled. This prevents IKE collisions and ensures stable tunnel establishment.
Initiator-Only Site
On the site configured as Initiator Only:
This site only initiates traffic toward the remote endpoint.
Passive Site
On the site configured with Passive Mode:
This site acts as the stable responder endpoint.
NLB Configuration.
This mapping is required for correct IKE and NAT traversal behavior. We only need NBL for the listener/passive site.
Security Requirements.
Allow the following UDP ports on both sides:
Software Version Requirement.
Use ION software version 6.5.2 or later to leverage Passive Mode. Earlier versions may not support stable NAT-to-NAT operation.
Operational Guidance.
Only one side should initiate the tunnel. Avoid dual initiators to prevent retransmissions and instability.
Validate tunnel establishment using logs and packet captures.
SPT Switchover is enabled by default. Once the first multicast packet is received the ION chooses the optimal direct path from source to receiver. Disabling this forces all traffic through the Rendezvous Point increasing latency and RP load unnecessarily.
The Network Time Protocol (NTP) is recommended to be explicitly configured using a trusted time source and to use proper authentication.
Accurate and reliable time is required for syslog correlation and forensic investigations, as well as for successful VPN connectivity when using certificate-based authentication. Configure all devices with UTC for global deployments to ensure timestamps can be accurately correlated across sites. For regional deployments configure devices with the local time zone. NTP operates over UDP port 123; ensure this traffic is explicitly permitted through any upstream firewalls between the ION device and the NTP server to maintain accurate time synchronization.
NTP authentication uses a shared key to verify that time updates come from a trusted source. Configure NTP with MD5 or SHA-1 key authentication under Configuration > Prisma SD-WAN > ION Devices > Claimed > Configure the device > NTP Client.
Send Syslog messages over VPN or private underlay if allowed via policy. Use the Control port or an L3 loopback interface (from release 6.5.2) as the source interface. This ensures a stable source IP regardless of which physical interface is active and avoids exposing physical interface IPs. Syslog messages are transmitted over UDP in cleartext so they should always travel over an encrypted path. Configure Syslog Profiles under Configuration > Prisma SD-WAN > Profiles and Templates > Syslog.
Branch Security generates Threat Prevention, DNS Security, and URL Filtering logs separately from standard traffic flow logs. Because these specialized security logs are not forwarded by default, you must explicitly enable them by checking the corresponding security log checkboxes within your Syslog Profile. This manual configuration is critical for maintaining compliance trails when Strata Logging Service (SLS) is not deployed, or when you require a secondary log destination for redundancy.
SNMPv3 provides secure access to device health data by utilizing per-message authentication and optional encryption. To configure an SNMPv3 user, navigate to Configuration > Prisma SD-WAN > ION Devices > Claimed > [Select Device] > SNMP, check Enable V3, and select an Authentication Type (MD5 or SHA) and an Encryption Type (AES).
Conversely, community strings for SNMPv1 and SNMPv2c are transmitted in cleartext and should be avoided on production devices due to the inherent security risk. If SNMPv2c must be utilized for compatibility with legacy Network Management Systems (NMS), ensure that community strings are rotated regularly in compliance with your organization's security policy.
SNMP Traps push event notifications to the NMS when significant events occur such as link up/down, BGP peer state changes, and VPN tunnel failures without requiring polling. Configure Trap destinations under the SNMP > Agent/Traps tab on the ION device configuration page. This provides real-time visibility into network events without depending solely on the SCM dashboard or syslog.
IPFIX exports detailed per-flow records source and destination IPs, ports, protocol, bytes, packets, application ID, DSCP, and application performance metrics to a flow collector or SIEM. While the SCM Flow Browser provides in-portal visibility IPFIX enables longer-term retention, cross-platform correlation, and offline investigation. Configure IPFIX templates and collectors under Configuration > Prisma SD-WAN > ION Devices > Claimed > Configure the device > IPFIX. Add application performance fields such as CONNECTION_RTT, CONNECTION_SRT, MEDIA_MOS, and MEDIA_JITTER to the template when troubleshooting application experience issues.
The ION DNS Service acts as a local caching and forwarding DNS resolver. Configure it with split-DNS — send internal domain queries to enterprise DNS servers and all other queries to internet DNS servers. This enables SaaS applications to resolve via the internet path without hair pinning through the data center, and critically if the DC fails, SaaS services continue functioning because the ION resolves them locally. Configure DNS Service Roles and Profiles under Configuration > Prisma SD-WAN > Profiles and Templates > DNS, then enable the service on each ION device under the DNS Service tab.
DNSSEC adds an essential layer of security to DNS resolution by using cryptographic digital signatures to authenticate responses. To implement this on your network, you can configure the ION DNS Service in one of two modes under the DNS Service Profile > Cache and DNSSec proxy configuration:
The ION device can act as a DHCP server at branch sites responding to both broadcast and unicast DHCP requests and supporting up to 256 subnets per device. Leases persist across reboots ensuring clients retain their addresses after an ION restart. DHCPv6 is supported from release 6.2.1. Configure DHCP scopes under Configuration > Prisma SD-WAN > Branch Sites > Configure DHCP Scopes. Note that DHCP server is not supported on secondary IP addresses and is a branch-only feature.
Configure DHCP Relay directly on the LAN interface rather than deploying a separate, dedicated relay agent at the branch site. You can configure up to 16 distinct DHCP server IP addresses per interface to ensure redundancy.
When setting up the relay, set the source interface to the specific interface through which the DHCP server is reachable; if the DHCP server is located locally within the branch, explicitly select the local LAN interface instead of relying on the default controller port. Additionally, enable DHCP Option 82 if your downstream DHCP server relies on Circuit ID or Remote ID information to properly assign IP addresses to clients.
Prisma SD-WAN generates incidents and alerts when the system reaches defined thresholds or detects a fault. Incidents indicate an active fault of Critical, Warning, or Informational severity. Alerts indicate a specific degradation or loss of functionality. Navigate to Incidents > Prisma SD-WAN in SCM to view, filter, acknowledge, and investigate events. Configure notification rules to push alerts to your operations team via email or webhook without requiring manual dashboard monitoring. Use Incident Policy rules to suppress known low-value events or escalate priority on business-critical site incidents.
WAN Clarity Reports provide automated weekly insights into circuit utilization, hotspot identification, application volume per circuit, and traffic distribution across the AppFabric. The Utilization Quadrant report identifies circuits operating above 50th percentile at the 90th percentile threshold — a consistent appearance week over week signals a capacity or policy tuning opportunity. The Hotspot reports identify the top applications, source IPs, and undefined domains contributing to congestion, giving administrators the data needed to create custom application definitions or adjust QoS and path policies.
Prisma SD-WAN integrates with Palo Alto Networks IoT Security (Device Security) to provide automated discovery and enforcement for IoT and unmanaged devices at branch sites. The ION device acts as a visibility sensor — collecting DHCP, ARP, and SNMP data from branch networks and forwarding it to Strata Logging Service where IoT Security performs device classification and risk assessment. IoT integration requires an IoT Security license and a Prisma Access for Remote Networks license with Strata Logging Service in the same TSG as Prisma SD-WAN.
Create an IoT Discovery Profile under Configuration > Prisma SD-WAN > Profiles and Templates > IoT Discovery with Automated SNMP Discovery enabled. A single profile can be reused across all sites. Use SNMPv3 with Auth and Privacy for discovery credentials — not the default SNMPv2 community string of "public". Note that CDP is not supported — only LLDP is used for neighbor crawling.
The ZBFW deny-by-default behavior blocks SNMP unless explicitly permitted. Create a security policy rule permitting UDP port 161 with applications snmp-base and snmp-trap, add it to the security policy stack, and bind the stack to the site.
Once IoT Security classifies devices, incorporate Device-ID profiles into your Zone-Based Firewall (ZBFW) rules to enforce granular, category- or device-specific access control. This micro-segmentation effectively prevents compromised IoT endpoints from being exploited for lateral movement across your network. For a comprehensive, zero-trust enforcement framework, combine Device-ID with App-ID and User-ID in your security policies.
Because IoT devices are often managed by third-party vendors, you should restrict their DNS resolution to only the specific domains they legitimately require to function. To achieve this, configure the ION DNS Service to control and filter name resolution on a source-address basis, and deploy Zone-Based Firewall (ZBFW) rules to strictly limit which external DNS servers the IoT device subnets can reach. This layered approach prevents unauthorized or compromised endpoints from establishing outbound command-and-control (C2) communications.
Autonomous Digital Experience Management (ADEM) is natively integrated into the Prisma SD-WAN ION device no additional appliances or agents are required. ADEM continuously monitors every segment in the service delivery path from the branch ION device to the application, providing the segment-by-segment visibility needed to quickly isolate where a degradation occurred.
ADEM can monitor all three available paths for a Prisma SD-WAN site the Prisma Access path (for applications routed through Prisma Access), the Secure Fabric path (for SaaS, IaaS, or private applications accessed via the SD-WAN overlay to a data center ION), and the Direct Access path (for SaaS applications accessed directly over the internet). Configure synthetic tests that align with the forwarding policies on your SD-WAN testing a path your traffic does not actually use produces irrelevant data. Include backup paths in your test configuration so degradation on a backup path is detected before it becomes the active path.
ADEM synthetic tests continuously collect both network quality metrics (latency, jitter, and packet loss) and web performance metrics (DNS lookup time, TCP connect, SSL connect, HTTP response time, and time-to-first-byte) across every segment from the branch to the application. Because these tests are granularly layered across each network hop, they allow you to quickly visualize exactly when and where a performance degradation occurred, instantly isolating whether the issue resides in the local LAN, the WAN underlay, the SD-WAN overlay, Prisma Access, or the application itself. To maximize the effectiveness of this data, ensure you configure performance baselines during normal operating hours so that automated anomaly detection remains accurate and meaningful.
The ADEM agent running natively on the ION device continuously collects CPU utilization, memory utilization, and historical trends. When investigating a performance issue check the ION device health telemetry first to rule out resource exhaustion on the device before investigating network or application-layer causes.
|
Term |
Definition |
|---|---|
|
AppFabric |
The Prisma SD-WAN application-defined overlay network that virtualizes heterogeneous WAN transports into a unified, policy-driven fabric |
|
ADEM |
Autonomous Digital Experience Management — native end-to-end experience monitoring built into the ION device, requiring no additional agents or appliances |
|
App-ID |
Application identification engine that classifies network flows by application identity at Layer 7 |
|
BFD |
Bidirectional Forwarding Detection — a lightweight protocol used for fast failure detection on MPLS and private WAN underlay circuits |
|
CDSS |
Cloud-Delivered Security Services — subscription-based security services (Anti-Spyware, Vulnerability Protection, DNS Security, URL Filtering) enforced directly on the ION device |
|
CIE |
Cloud Identity Engine — Palo Alto Networks cloud service that provides IP-to-user and user-to-group mappings for identity-based policy enforcement |
|
CUID |
Cloud User ID — a method of obtaining IP-to-user mappings directly from Cloud User Context via CIE, without requiring a PAN-OS User-ID Agent |
|
DC |
Data Center — a Prisma SD-WAN site type that houses hub ION devices aggregating branch traffic |
|
Device Shell |
A pre-staged site configuration in SCM that allows full site setup to be completed before the physical ION device arrives, enabling zero-touch deployment |
|
DIA |
Direct Internet Access — internet-bound traffic forwarded directly from the branch without backhauling through a data center |
|
DPS |
Dynamic Path Selection — the Prisma SD-WAN algorithm that continuously evaluates and selects the optimal WAN path per application flow |
|
FEC |
Forward Error Correction — a loss recovery mechanism that adds redundant data to SD-WAN VPN flows so the receiver can reconstruct lost packets without retransmission |
|
HFSC |
Hierarchical Fair Service Curve — the QoS scheduling algorithm used by Prisma SD-WAN to enforce bandwidth allocation and latency guarantees across 16 priority queues |
|
ION |
Instant-On Network — the Prisma SD-WAN data plane device deployed at branch and data center sites |
|
LQM |
Link Quality Monitoring — continuous per-path measurement of latency, jitter, packet loss, and MOS score on all active WAN circuits |
|
MOS |
Mean Opinion Score — a composite voice/video quality score (1–5) computed from latency, jitter, and packet loss |
|
NAT |
Network Address Translation — source or destination IP address translation performed by the ION device on branch sites |
|
OOM |
Out of Memory — a critical failure condition on ION devices caused by excessive memory consumption during policy compilation |
|
OTP |
One-Time Password — a single-use credential used to recover console access to an offline ION device |
|
RBAC |
Role-Based Access Control — the permission model used in Prisma SD-WAN to control administrator access by assigned role |
|
SCM |
Strata Cloud Manager — the unified cloud management platform used to configure, monitor, and operate Prisma SD-WAN and other Palo Alto Networks products |
|
SLA |
Service Level Agreement — a defined performance threshold used in Performance Policy to trigger remediation actions such as path migration or FEC |
|
TACACS+ |
Terminal Access Controller Access Control System Plus — a protocol providing centralized authentication, authorization, and accounting for ION device administrative access |
|
TSG |
Tenant Service Group — the logical container in the Palo Alto Networks cloud platform that groups licenses, products, and users belonging to a single customer tenant |
|
VRF |
Virtual Routing and Forwarding — a mechanism for creating multiple isolated routing tables on the same ION device for traffic segmentation |
|
WAN Clarity |
A licensed reporting feature that generates weekly circuit utilization, hotspot identification, and traffic distribution reports across the Prisma SD-WAN AppFabric |
|
ZBFW |
Zone-Based Firewall — the stateful, application-aware firewall built into the Prisma SD-WAN ION device that enforces traffic policy between defined network zones |
|
ZTP |
Zero-Touch Provisioning — automated device onboarding that allows ION devices to claim and pull their full configuration from SCM upon first internet connectivity, without requiring on-site technical expertise |
|
Document |
Location |
|---|---|
|
Prisma SD-WAN Administrator’s Guide |
https://docs.paloaltonetworks.com/prisma-sd-wan/administration |
|
Prisma SD-WAN Release Notes |
https://docs.paloaltonetworks.com/prisma/prisma-sd-wan/prisma-sd-wan-release-notes |
|
Prisma SD-WAN Incidents and Alerts |
https://docs.paloaltonetworks.com/prisma-sd-wan/incidents-and-alerts |
|
Prisma SD-WAN ION Device CLI Reference |
https://docs.paloaltonetworks.com/prisma-sd-wan/ion-cli-reference/get-started-with-the-ion-cli |
|
Prisma SD-WAN Network Policy Guide |
|
|
Prisma SD-WAN Dynamic Path Selection Whitepaper |
|
|
Prisma SD-WAN QoS Whitepaper |
|
|
Prisma SD-WAN Security Architecture Whitepaper |
|
|
Strata Cloud Manager Getting Started Guide |
|
|
Cloud Identity Engine Getting Started |
|
|
Identity and Access Management Guide |
|
|
Prisma SD-WAN Compatibility Matrix |
https://docs.paloaltonetworks.com/compatibility-matrix/reference/prisma-sd-wan-compatibility-matrix |
