>
    Strata Copilot
    Features Introduced in SD-WAN Plugin 3.2
    Focus
    Download PDF
    Focus
    1. Home
    2. SD-WAN
    3. Panorama Plugin for SD-WAN
    4. Panorama Plugin for SD-WAN 3.2
    5. Features Introduced in SD-WAN Plugin 3.2
    Download PDF
    SD-WAN

    Features Introduced in SD-WAN Plugin 3.2

    Table of Contents

    Features Introduced in SD-WAN Plugin 3.2

    New features for SD-WAN 3.2.
    The SD-WAN Administrator’s Guide 3.2 provides information about how to use the SD-WAN plugin features in this release.

    What’s New in SD-WAN Plugin 3.2.4

    Key features introduced with the SD-WAN plugin 3.2.4 release:
    New SD-WAN FeatureDescription
    Dedicated Tunnels for Panorama Connectivity
    To ensure uninterrupted connectivity between the SD-WAN devices and Panorama, the SD-WAN plugin introduces an option to configure the dedicated tunnel to Panorama. Unlike the SD-WAN overlay network connectivity to Panorama that may go down, which causes unreachability of SD-WAN devices to Panorama, the dedicated tunnel stays connected all the time.
    The dedicated tunnel to Panorama establishes a persistent and dedicated IPSec tunnels from your branch devices to Panorama through designated termination devices using direct internet access (DIA) interfaces. 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.

    What’s New in SD-WAN Plugin 3.2.3

    Key features introduced with the SD-WAN plugin 3.2.3 release:
    New SD-WAN FeatureDescription
    Post-quantum IKEv2 VPNs
    To protect your SD-WAN overlay against potential quantum computing attacks, Palo Alto Networks introduces post-quantum VPN support for Advanced next-generation firewall SD-WAN. This feature enables you to configure your SD-WAN overlay using post-quantum pre-shared keys (PQ PPK) safeguarding your network from ‘harvest now, decrypt later’ attacks. By implementing these quantum-safe encryption methods, you can ensure that your site-to-site VPNs remain secure even in the face of future quantum computing threats.
    The SD-WAN plugin now offers an option to enable post-quantum VPN under the VPN cluster configuration. When activated, all IPSec tunnels autogenerated by the plugin for the SD-WAN overlay will use PQ PPK, with the ability to automatically create and manage 10 strong PQ PPKs. The post-quantum pre-shared keys work with the existing IKEv2 and IPSec functionality, ensuring compatibility and ease of implementation.
    By adopting post-quantum VPN support, you position your organization at the forefront of cybersecurity, ready to face the challenges posed by emerging quantum computing technologies. This approach not only protects your current data transmissions but also safeguards against future threats, giving you a competitive edge in data security and compliance.

    What’s New in SD-WAN Plugin 3.2.2

    Key features introduced with the SD-WAN plugin 3.2.2 release:
    New SD-WAN FeatureDescription
    Monitor Bandwidth on SD-WAN Devices
    For a VPN cluster, you will now be able to view the bandwidth of a tunnel and a physical interface (in addition to existing jitter, latency, and packet loss performance measures) for a selected site by default. There is no configuration required from the user to view the bandwidth of a tunnel.
    SD-WAN Plugin Improvements
    Earlier to SD-WAN plugin 3.2.2 version, the SD-WAN generated configurations (such as the IKE ID and tunnel names) uses the active firewall's serial number. Therefore, whenever a HA failover occurs, the SD-WAN generated configurations would reset with the active firewall's serial number that results in temporary tunnel flaps.
    We have improved the SD-WAN plugin 3.2.2 version by using the lower serial number among the HA devices for generating the SD-WAN configurations that remove tunnel flaps. This improvement also introduces the following SD-WAN configuration changes:
    • the IKE key ID is formed with the lower serial number between the HA devices.
    • the SD-WAN generated configurations, such as route table entry in virtual router, tunnel name, IKE gateway name, BGP import rule name, routing profile, BGP peer, and BGP filtering profile will be reset.
    • Tunnel names and corresponding IP address would change as the tunnel names are created from a lower serial number among the two HA devices.
    After upgrading the firewall to SD-WAN plugin 3.2.2 version, you must push the configuration followed by Commit from Panorama to all the managed firewalls in the VPN cluster. Commit and push ensures a full and consistent synchronization, preventing configuration mismatches.
    MongoDB HA Synchronization CLI Commands
    We have introduced the following MongoDB related HA peer synchronization commands that must be executed only on the active HA peer:
    • debug plugins sd_wan mongo-db sync-db-to-peer—Use this command to synchronize the SD-WAN MongoDB from active HA peer with the passive HA peer. You must execute this command in the following cases:
      We recommend you to check the status of the operation log by executing debug plugins sd_wan mongo-db sync-status command before executing debug plugins sd_wan mongo-db sync-db-to-peer command. Because the SD-WAN MongoDB operation log synchronization must be successful before you synchronize the HA peers.
    • debug plugins sd_wan mongo-db sync-status—Use this command to check the synchronization status of the operation log (op log). This command only checks the operation logs.
    Monitor Remote Site Experience on NGFWs with ADEM
    Autonomous Digital Experience Management (ADEM) for SD-WAN addresses the challenge of maintaining visibility and control over application performance across distributed branch networks and provides comprehensive, end-to-end monitoring capabilities. ADEM functionality in your SD-WAN deployment enables you to proactively measure and optimize application experience from branch locations to data centers, cloud services, and SaaS applications.
    Leverage ADEM in your SD-WAN branch sites to gain insights into both underlay and overlay network performance, ensuring that your SD-WAN paths are operating efficiently. With ADEM integration, run synthetic tests across all available WAN links to make data-driven decisions about path selection and application routing.
    By implementing ADEM for SD-WAN, you can quickly identify performance bottlenecks, validate SLA compliance, and troubleshoot issues across your entire SD-WAN fabric. With ADEM for SD-WAN, you can ensure optimal application delivery, streamline branch connectivity, and maintain consistent performance across your distributed enterprise network.
    You need PAN-OS 11.1.9 or later 11.1 version or PAN-OS 11.2.6 or later 11.2 version with ADEM 1.0.1 or later version for monitoring remote site experience on next-generation firewalls.
    ADEM is supported only on the IPv4-enabled SD-WAN devices.
    Prerequisites
    • Enable DIA AnyPath at the cluster level, if the traffic to SaaS applications gets backhauled through the hub.
    • BGP connection must exist between the branch and the hub devices.
    • Add Security policy rule to match traceroute application for all upstream devices.
    Additionally, you can also use the ADEM-related CLI commands to monitor the remote site experience.

    What’s New in SD-WAN Plugin 3.2.1

    Key features introduced with the SD-WAN plugin 3.2.1 release:
    New SD-WAN FeatureDescription
    Additional SD-WAN Hubs in VPN Cluster
    The number of hubs to configure in a VPN cluster has been increased from 4 to 16. Do not configure the same priority for more than four SD-WAN hubs in a VPN cluster.
    Additional Private Link Types for SD-WAN Interface Profile
    The number of private link types to configure in an SD-WAN Interface Profile has been increased from 3 to 7.
    With PAN-OS 11.1.3 and later releases, SD-WAN plugin 3.2.1 and later releases support the following private link types in addition to the existing private link types (MPLS, Satellite, Microwave/Radio):
    • Private Link1
    • Private Link2
    • Private Link3
    • Private Link4
    We don't support plain text traffic from SD-WAN branch firewall to SD-WAN hub firewall for these new private link types. When you configure any of the new private link types, ensure that you have a SD-WAN policy rule on the hub that is configured only with public link type. Because when the internet-bound traffic backhauls or fails to the hub from the branch, it must match with this SD-WAN policy rule. Otherwise, the traffic gets dropped as these private links (Private Link1, Private Link2, Private Link3, and Private Link4) are part of the direct internet access (DIA) SD-WAN interface.
    Multiple Virtual Routers Support on SD-WAN Hubs
    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.

    What’s New in SD-WAN Plugin 3.2.0

    Key features introduced with the SD-WAN plugin 3.2.0 release:
    New SD-WAN FeatureDescription
    IKEv2 Certificate Authentication Support for Stronger Authentication
    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.
    Public Cloud SD-WAN High Availability (HA)
    You can now reduce complexity and increase resiliency by adding HA 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 HA active/passive configurations. Minimize the downtime and ensure session survivability using the active/passive HA failover in public cloud SD-WAN environments.
    SD-WAN IPv6 Support
    SD-WAN supports IPv6 interfaces, beginning with SD-WAN plugin 3.2.0. 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 enables 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 enables you to use addresses from an IPv4 VPN address pool or an IPv6 VPN address pool.
    • When a 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 web interface enables 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 a 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.

    © 2025 Palo Alto Networks, Inc. All rights reserved.