SD-WAN Features
Table of Contents
Expand All
|
Collapse All
Next-Generation Firewall Docs
-
-
-
-
-
-
-
- PAN-OS 12.1
- PAN-OS 11.2
- PAN-OS 11.1
- PAN-OS 11.0 (EoL)
- PAN-OS 10.2
- PAN-OS 10.1
- PAN-OS 10.0 (EoL)
- PAN-OS 9.1 (EoL)
- PAN-OS 9.0 (EoL)
- PAN-OS 8.1 (EoL)
-
- PAN-OS 12.1
- PAN-OS 11.2
- PAN-OS 11.1
- PAN-OS 10.2
- PAN-OS 10.1
SD-WAN Features
What new SD-WAN features are in PAN-OS 11.1?
Dedicated Tunnels for Panorama Connectivity
July 2025
|
When you have Panorama deployed without a public IP address, your SD-WAN devices rely
solely on the SD-WAN overlay network for connectivity to Panorama. This creates a
single point of failure that can result in significant outages when SD-WAN overlay
issues occur. The Dedicated Tunnel to Panorama feature
addresses this vulnerability by establishing persistent, dedicated IPSec tunnels
from your branch devices to Panorama through designated termination devices using
direct internet access (DIA) interfaces.
This feature is valuable in environments where Panorama can’t be exposed over the
internet using a public IP address. With dedicated tunnels in place, even if your
primary SD-WAN overlay network becomes unavailable, your devices can still reach
Panorama to receive configuration updates and troubleshooting commands. This
eliminates the need for manual recovery, significantly reducing downtime and
operational costs.
You can configure primary and secondary termination devices with preferred and
secondary DIA interfaces, ensuring redundant connectivity paths to Panorama. The
solution uses a separate VPN address pool for tunnel IP address assignments that
must not overlap with existing SD-WAN overlay configurations.
Post-Quantum IKEv2 VPNs Support
March 2025
|
Cryptographically relevant quantum computers (CRQCs) threaten traditional
cryptographic systems by dramatically reducing the time needed to break encryption
algorithms. VPN communications secured by IKEv2 are vulnerable to the threats posed by CRQCs because IKEv2 uses
Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) for key exchange.
Delays in implementing post-quantum cryptography (PQC) increase the risk of Harvest
Now, Decrypt Later attacks. In these attacks, adversaries capture and store
encrypted data today for future decryption when CRQCs become available. If you
handle sensitive data requiring long-term storage, you are especially
susceptible.
To future-proof VPN communications against this emerging threat, PAN-OS® 11.1
implements quantum-resistant IKEv2 VPNs based on
RFC
8784. RFC 8784 specifies the mixing of post-quantum pre-shared keys (PQ
PPKs) with DH keys to create quantum-resistant connections. The implementation
involves a PQ PPK and a public key ID associated with the secret. You must share the
secret with both VPN peers out-of-band. After the peers perform a standard DH key
exchange, one peer sends the key ID to the other in-band. Both peers use that key ID
to identify the PQ PPK to mix with the DH key material. This method creates a new,
quantum-resistant key that provides multiple layers of protection. CRQCs can't
compromise the resulting key because it isn't based on prime number factorization
that Shor's algorithm exploits. Harvesting attacks fail because the PPK itself never
leaves your IKEv2 peers; adversaries can't capture the key material required for
future decryption, even if they compromise the DH key.
Palo Alto Networks implementation of RFC 8784 ensures a seamless transition to PQC.
The standard doesn't require cryptography upgrades, so you can introduce PPKs into
existing IPsec VPN deployments without network disruption. It also supports falling
back to classical cryptography if a peer doesn't support RFC 8784. Further, the
standard is interoperable with multiple vendors and works with other standards such
as RFC 9370.
The following example topology shows three VPN termination sites. Sites A and C
support post-quantum VPNs based on RFC 8784, while Site B supports classical VPNs
only. Site A must be able to communicate with both Site B and Site C. When
communicating with Site B, Site A can either fall back to classical negotiation or
abort the connection, depending on your configured preference. When communicating
with Site C, Site A uses a PQ PPK because Site C supports this.

Monitor Bandwidth on SD-WAN Devices
May 2024
October 2024
|
Currently it's difficult for the network administrators to quickly identify the cause
for an application’s poor performance in an SD-WAN device. It's because there isn't
enough information available to identify the issue and the available limited
information (such as VPN statistics, Panorama's device health statistics, and link
health statistics) are located between Panorama® and firewalls. It becomes a time
consuming activity for the administrators to correlate this information and locate
the performance issues on an SD-WAN device.
For a VPN cluster, you will now be able to view the bandwidth of a tunnel and a
physical interface for a selected site by default. Bandwidth is a primary measure of
a link performance in addition to existing
jitter, latency, and packet loss performance measures. There is no configuration
required to view the bandwidth of a tunnel.
Additional Private Link Types Support on SD-WAN Device
April 2024
May 2024
|
The PAN-OS® SD-WAN plugin previously supported a limited number of private
link types, which complicated configurations for organizations using more than three
distinct private link providers. This limitation required administrators to
implement configuration workarounds, preventing the SD-WAN plugin from correctly
establishing one-to-one device peering based on the link type.
To address this, four additional link types are now
available: Private 1, Private 2, Private 3, and Private 4. These function
identically to the existing MPLS link type and inherit its aggressive path
monitoring characteristics. By allowing each distinct private link to be assigned a
unique type, this feature enables the SD-WAN plugin to correctly determine
one-to-one device peering for the overlay network, eliminating the need for
configuration workarounds.
Additional SD-WAN Hubs in VPN Cluster
April 2024
May 2024
|
The number of hubs to configure in a VPN cluster has been
increased from 4 to 16. Only four of the 16 hubs can have the same hub priority
within a VPN cluster due to ECMP.
Multiple Virtual Routers Support on SD-WAN Hubs
February 2024
May 2024
|
With earlier SD-WAN plugin versions, you can't have SD-WAN configurations on multiple
virtual routers. By default, a sdwan-default virtual router is created and it
enables Panorama to automatically push the router configurations. Due to this
restriction, customers faces difficulty and spends additional effort in some of the
SD-WAN deployments:
User Scenario (in SD-WAN Deployments) | Single Virtual Router Configuration on SD-WAN Hub | Multiple Virtual Routers Configuration on SD-WAN Hub |
---|---|---|
Overlapping IP addresses from different branches connecting to the same hub | Customers may need to reconfigure the overlapping subnets to unique address spaces. |
Enable Multi-VR Support on the
SD-WAN hub device.
The traffic from different branches is directed to
different virtual routers on a single hub to keep the traffic
separate.
|
Government regulations that disallow different entities to function on the same virtual router | Customers won’t be able to separate routing of different entities with a single virtual router. | Enable Multi-VR Support on the SD-WAN hub
device to keep the traffic of different entities separate.
Multiple virtual routers on the SD-WAN hub maps the branches
to different virtual routers on the hub that provides logical
separation between the branches. |
SD-WAN plugin now supports multiple virtual routers on the SD-WAN
hubs that enable you to have overlapping IP subnet addresses on branch
devices connecting to the same SD-WAN hub. Multiple virtual routers can run multiple
instances of routing protocols with a neighboring router with overlapping address
spaces configured on different virtual router instances. Multiple virtual router
deployments provide the flexibility to maintain multiple virtual routers, which are
segregated for each virtual router instance.
However, the number of virtual routers supported on the PAN-OS SD-WAN hub
varies by platform.
Benefits:
- A hub with multiple virtual router configuration logically separates the routing for each branch office that it is connected with.
- Branches sharing the same SD-WAN hub can reuse the same IP subnet address.
The following figure illustrates an SD-WAN hub with two virtual routers. By enabling
multiple virtual routers support on the SD-WAN hub, the four branches
connecting to the same SD-WAN hub (but different virtual routers) can have
overlapping IP subnets or belong to different entities and function independently
because their traffic goes to different virtual routers.

IKEv2 Certificate Authentication Support for Stronger Authentication
November 2023
|
The SD-WAN plugin now supports the certificate authentication type in addition to the
default pre-shared key type for user environments that have strong security
requirements. We support the IKEv2 certificate authentication type on
all SD-WAN supported hardware and software devices.
You can configure certificate-based authentication for the following topologies,
provided that you have configured all SD-WAN devices in the topology with the same
(or certificate) authentication type:
- VPN clusters (hub-and-spoke and mesh)
- PAN-OS firewalls connecting to Prisma Access compute nodes
Generate certificates for the SD-WAN
device using your own certificate authority (CA). Add and deploy the generated
certificates in bulk across your SD-WAN cluster and autogenerate the SD-WAN overlay
using the certificate-based authentication.
Public Cloud SD-WAN High Availability (HA)
November 2023
|
Maintaining network resiliency and session survivability for SD-WAN in public cloud
deployments presents unique challenges, often leading to service disruptions during
a device failure. To address this, Palo Alto Networks now supports high availability (HA) for SD-WAN on
VM-Series next-generation firewalls in public cloud environments.
This feature enables an active/passive HA configuration that uses a floating IP
address to ensure seamless failover between firewalls. By maintaining session state
during a failover event, it minimizes downtime and preserves application performance
for your users. This allows you to build resilient and reliable SD-WAN architectures
in the cloud, mirroring the high availability standards traditionally found in
on-premises deployments.
This HA capability is available for VM-Series firewalls in AWS and Microsoft Azure.

SD-WAN IPv6 Support
November 2023
|
SD-WAN supports IPv6 interfaces, beginning with SD-WAN plugin 3.2. You have the
flexibility to onboard branch locations in a hybrid IPv4/IPv6 environment or a full
IPv6 environment. SD-WAN IPv6 support uses intelligent application path steering
technology to provide application reliability and SLAs for IPv6 environments. SD-WAN
IPv6 support includes the following changes:
- You can configure a physical Ethernet interface to have a static IPv6 address.
- You can configure a static IPv6 route.
- The Advanced Routing Engine allows you to configure IPv6 BGP routing.
- SD-WAN provides health monitoring for the next hop from SD-WAN-enabled IPv6 interfaces and health monitoring for a VPN tunnel endpoint.
- Path monitoring now allows you to use addresses from an IP4 VPN address pool or an IPv6 VPN address pool.
- When an SD-WAN interface is enabled for IPv6, Auto VPN configuration creates a DIA interface named sdwan.9016, which has IPv6 physical interfaces as member interfaces. The default IPv6 route points to the sdwan.9016 interface. The user interface allows you to specify whether the virtual interface is a DIA IPv4 interface, DIA IPv6 interface, or tunnel interface (which can have a mix of IPv4 tunnel interfaces and IPv6 tunnel interfaces). An Ethernet interface can belong to both the sdwan.901 virtual interface and the sdwan.9016 virtual interface.
SD-WAN supports dual stack in the event that one ISP provides you with only an IPv4
address and another ISP provides you with only an IPv6 address. You will create
separate virtual SD-WAN interfaces. An IPv4 DIA virtual interface will have Ethernet
with an IPv4 address, while an IPv6 DIA virtual interface will have Ethernet with an
IPv6 address.
If a DIA link between a branch and a hub has only IPv6 addresses on the interfaces at
each end, the tunnel is created using IPv6 addresses. If the branch and hub have
IPv4 addresses on the interfaces, the tunnel is created using IPv4 addresses. If the
branch and hub use both IPv4 and IPv6 addresses on the interfaces, the tunnel is
created using IPv4 addresses only (IPv4 addresses are preferred). If there is a
mismatch of address family identifiers (AFI) between the hub and branch, no tunnel
configuration is generated for that pair of interfaces.
Similarly, a VPN address pool can have both IPv4 and IPv6 addresses configured, in
which case IPv4 addresses are preferred for the tunnel interface and tunnel
monitoring. If the IPv4 addresses in the VPN address pool are exhausted, then IPv6
addresses are used for the tunnel interface and tunnel monitoring.
You can also have independent IPv4 VPN address pools that contain IPv4 addresses and
IPv6 VPN address pools that contain IPv6 addresses.