SD-WAN Features
Focus
Focus

SD-WAN Features

Table of Contents

SD-WAN Features

What new SD-WAN features are in PAN-OS 11.2?

Post-Quantum IKEv2 VPNs Support

April 2025
  • Available in SD-WAN 3.3.3 with PAN-OS 11.2.5 and later 11.2 releases
Post-quantum VPNs resist attacks based on quantum computing and post-quantum cryptography (PQC). Palo Alto Networks post-quantum VPN support enables you to configure quantum-resistant IKEv2 VPNs and is based on the RFC 8784 standard to maximize interoperability with other vendors' equipment and with future standards. Multiple government agencies around the world, including the NSA and NIAP, recommend implementing RFC 8784 to improve quantum resistance. Implementing RFC 8784 is the simplest way to create quantum-resistant VPNs because you don't need to upgrade crypto elements.
Addressing the quantum threat immediately is critical to defend against Harvest Now, Decrypt Later attacks that target long-lived data because the development of cryptographically relevant quantum computers (CRQCs) will vastly reduce the amount of time required to break classical encryption.
Configuring quantum-resistant VPNs can prevent attackers from recording critical encrypted key material and thus prevent them from decrypting the data even if they steal it. If you have long-lived data, start planning now for the threat posed by quantum computers and quantum cryptography and for your network's transition to a post-quantum world. The first step is to make your VPN connections quantum-resistant.
RFC 8784 provides a transition from today's classical cryptography to PQC. Quantum-resistant VPNs based on RFC 8784 enable using post-quantum pre-shared keys (PPKs) that are not transmitted with the data, so harvesting attacks fail because they don't capture the key material that they need to decrypt the data later. A PPK is a complex, strong hexadecimal string that you statically program into the IKE peers at the ends of the VPN tunnel.
Adding a static PPK that's delivered out-of-band to the classical Diffie-Hellman (DH) key prevents Shor's algorithm from cracking the key because the key is no longer based on prime numbers. RFC 8784 enables using long, strong PPKs that meet the NIST Category 5 security level.
In addition, RFC 8784 provides the backward compatibility to fall back to classical cryptography if a peer can't support FRC 8784, so the implementation doesn't risk refusing legitimate connections. Palo Alto Networks implementation of RFC 8784 provides flexibility and quantum resistance for your IKEv2 VPNs:
  • You can add up to ten post-quantum (PQ) PPKs to each IKEv2 VPN. Each PQ PPK is associated with a PPK KeyID, which uniquely identifies the PPK, so you can configure up to ten PPK + KeyID pairs. You can configure PPKs yourself or use a built-in tool to generate strong PPK strings. Configuring multiple active PPKs enables the firewall that initiates the IKEv2 peering to randomly select one of the active PPKs to use with the peer.
  • You can configure PPK strings from 16-64 bytes (32-128 characters) in length. For best security, use PPK strings that are at least 32 bytes (64 characters) in length.
  • You can set the Negotiation Mode to control the ciphers used to establish the connection:
    • Mandatory—Require that the responding peer use RFC 8784 and abort the connection if it only uses classical cryptography.
    • Preferred—Allow the initiating device to fall back to classical cryptography if the peer doesn't support RFC 8784.
  • You can activate and deactivate individual PQ PPKs, so if a PQ PPK is lost or exposed, you can disable it and remove it from the negotiation pool.
In addition to implementing RFC 8784 now:
  • Migrate to tougher cipher suites. Follow RFC 6379 for Suite B Cryptographic Suites for IPsec, upgrade ciphers to Suite-B GCM-256, and avoid using weaker AES-128-bit algorithms.
  • Upgrade to larger hash sizes such as SHA-384 or SHA-512. Don't use MD5 or SHA-1.
  • Upgrade your CA to larger RSA key sizes. Use 4096-bit RSA key sizes and migrate VPN certificate authentication to new certificates.
The following example topology shows three VPN termination sites. Sites A and C support post-quantum VPNs based on RFC 8784. Site B supports only classical VPNs. Site A must be able to communicate with both Site B and Site C.
Site A uses both Mandatory and Preferred negotiation modes. When Site A communicates with Site B, which only supports classical cryptography, Site A falls back to classical negotiation. When Site A communicates with Site C, Site A uses a PQ PPK because Site C supports using PQ PPKs.

Add SD-WAN Capability to your Cellular Interfaces (4G/5G)

September 2024
  • Introduced in SD-WAN 3.3.1 with PAN-OS 11.2.3
As 5G becomes increasingly prominent, more organizations use or are considering wireless WAN links as the primary or secondary WAN transport to share the load. With wireless WAN 5G connectivity, you can achieve a reliable connection on 5G-capable firewalls.
On the cellular interface, you can enable SD-WAN support on your 5G-capable firewalls. When you enable SD-WAN on the 5G cellular interface, you are adding support for automatic traffic steering based on the collected metrics within qualified paths and links (which includes cellular and wireless WAN connections).
When you enable SD-WAN on a 5G cellular interface, you gain support for:
  • IPv4 SD-WAN cellular traffic
  • SD-WAN interface profile and upstream NAT

Multiple Virtual Routers Support on SD-WAN Branches

September 2024
  • Introduced in SD-WAN 3.3.1 with PAN-OS 11.2.3
SD-WAN deployments require strict routing separation and support for overlapping IP subnets to meet regulatory requirements and accommodate complex network architectures. Enabling multiple virtual routers (VRs) in your SD-WAN deployment logically separates the routing infrastructure over SD-WAN overlays, which helps you to comply with regulations and maintain network segregation while utilizing overlapping IP subnets.
With this new functionality, you can run multiple instances of routing protocols on your multiple VRs when connecting to neighboring routers. Those VRs can now use overlapping address spaces and still successfully route traffic to the appropriate destination based on the virtual router ID (VR-ID) associated with each virtual router. This provides you with the flexibility to maintain multiple segregated VRs for each connection.
To enable multiple virtual routers on an SD-WAN branch, you must first configure multiple virtual routers on the SD-WAN hub to which these branches connect. You can configure a maximum of 20 virtual routers on an SD-WAN branch. However, the maximum number of virtual routers varies based on the Palo Alto Networks Next-Generation Firewalls you use in your deployment.
This illustration contains three SD-WAN branches, each configured with two virtual routers. When you enable support for multiple VRs on the SD-WAN branches, those three branches connected to the same SD-WAN hub can use overlapping IP subnets or belong to different devices. In this configuration, these SD-WAN branches can function independently because the branch traffic goes to different virtual routers.

Monitor Bandwidth on SD-WAN Devices

May 2024
  • Introduced in SD-WAN 3.3.0 with PAN-OS 11.2.0 and later releases
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.
We’ve introduced bandwidth which is a primary measure of a link performance in addition to existing jitter, latency, and packet loss performance measures. 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. There is no configuration required from the user to view the bandwidth of a tunnel.

Multiple Virtual Routers Support on SD-WAN Hubs

February 2024
  • Introduced in SD-WAN 3.0.7 with PAN-OS 10.2.8 and later 10.2 releases.
May 2024
  • Available in SD-WAN 3.3.0 with PAN-OS 11.2.0 and later releases
  • Available in SD-WAN 3.2.1 with PAN-OS 11.1.3 and later releases
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 HubMultiple Virtual Routers Configuration on SD-WAN Hub
Overlapping IP addresses from different branches connecting to the same hubCustomers 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 routerCustomers 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.

Additional Private Link Types Support on SD-WAN Device

April 2024
  • Introduced in SD-WAN 3.1.3 with PAN-OS 11.0.4 and later 11.0 releases
May 2024
  • Available in SD-WAN 3.3.0 with PAN-OS 11.2.0 and later releases
  • Available in SD-WAN 3.2.1 with PAN-OS 11.1.3 and later releases
You can now configure additional point-to-point private link types, Private Link1, Private Link2, Private Link3, and Private Link4 along with the existing private link types (MPLS, Satellite, Microwave/Radio) for one to one connectivity while configuring the SD-WAN Interface Profile.
These private link types enable you to avail reliable providers for your remote regions to establish one to one connection with the overlay network and avoid provider outages.

Additional SD-WAN Hubs in VPN Cluster

April 2024
  • Introduced in SD-WAN 3.1.3 with PAN-OS 11.0.4 and later 11.0 releases
May 2024
  • Available in SD-WAN 3.3.0 with PAN-OS 11.2.0 and later releases
  • Available in SD-WAN 3.2.1 with PAN-OS 11.1.3 and later releases
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.