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:

In addition to implementing RFC 8784 now:

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.

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.

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.

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.

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:

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.

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.

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.

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 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:

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.