SD-WAN Features
Table of Contents
SD-WAN Features
What new SD-WAN features are in PAN-OS 11.1?
Post-Quantum IKEv2 VPNs Support
|
March 2025
|
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.
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.
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.
Additional Private Link Types Support on SD-WAN Device
|
April 2024
May 2024
|
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
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
|
You can now reduce complexity and increase resiliency by adding high availability to
your SD-WAN for next-generation firewall public cloud deployments. Configure up to
four IP addresses per SD-WAN
interface, allowing you to deploy SD-WAN on public clouds to achieve failover in
high availability active/passive configurations. Minimize the downtime and ensure
session survivability using the active/passive HA failover in public cloud SD-WAN
environments.
Currently, you can avail this feature on deployments using VM-Series in Azure and AWS
public cloud HA environments by configuring a second floating IP address on the
SD-WAN interfaces. The floating IP on the SD-WAN interface of the external zone must
match with that of the internal zone. In the illustration, observe that 10.0.2.100
is the common floating IP between the external and internal zones during a HA
failover.
This feature is supported on PAN-OS 11.1.0 and above and on IPv4 addresses
only.
The following illustration is an example of VM-Series deployment in Azure HA
A/P topology and shows how the secondary floating IP address is from
the same subnet and applied to both trust and untrust zones of the SD-WAN
interface.
In AWS instances, you can configure HA A/P failover using
multiple ways, one of which is using a second IP address that acts as the floating
IP.
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.