Known Issues in SD-WAN Plugin 2.2
Table of Contents
Expand all | Collapse all
-
-
-
-
- Features Introduced in Zero Touch Provisioning 2.0
- Known Issues in the Zero Touch Provisioning 2.0.4 Release
- Known Issues in the Zero Touch Provisioning 2.0.3 Release
- Known Issues in the Zero Touch Provisioning 2.0.2 Release
- Known Issues in the Zero Touch Provisioning 2.0.1 Release
- Known Issues in the Zero Touch Provisioning 2.0.0 Release
- Limitations
-
-
Known Issues in SD-WAN Plugin 2.2
List of known issues in SD-WAN 2.2 release.
The following list includes all known
issues that impact an SD-WAN 2.2 release. This list includes both
outstanding issues and issues that are addressed, as well as known issues
that apply more generally or that are not identified by a specific
issue ID. Refer to PAN-OS Release Notes for
additional known issues affecting SD-WAN Plugin 2.2.
PAN-221755
Description of PAN-221755.
In a Panorama high availability (HA) deployment, when you add a new VPN cluster or modify
an existing VPN cluster name, the SD-WAN plugin database goes out of sync between the
active and passive Panorama.
Workaround: Run commit force from CLI on the active Panorama after an HA
configuration sync on the passive Panorama from the active Panorama.
PAN-220919
Description of PAN-220919.
Auto VPN creates a virtual SD-WAN interface named sdwan.901 for direct internet access
(DIA) and creates a virtual SD-WAN interface named sdwan.9xx for VPN tunnels. When you
enable Auto VPN, the SD-WAN plugin creates the SD-WAN interfaces automatically. Hence,
it's not necessary for you to create SD-WAN interfaces manually. The SaaS quality
profile works only with one DIA interface that is sdwan.901.
Auto VPN also creates its own default route that uses the sdwan.901 interface as its
egress interface and uses a low metric of 5, so that the sdwan.901 interface is
preferred over the default route you created.
There might be scenarios where you want to create an SD-WAN interface manually (other
than what the SD-WAN plugin creates automatically) like the following:
- Configuring SD-WAN direct internet access (DIA) links only and no VPN connections between the hub and branch locations
- (Not recommended) Deploying SD-WAN manually between SD-WAN sites without Panorama management server
In such cases, you must configure the manually created SD-WAN interface outside of the
SDWAN.9xx range containing a route with a metric higher than the default value.
PAN-215897
Description of PAN-215897.
In a Panorama high availability (HA) deployment, the SD-WAN interface goes down and all
the tunnel interfaces disappear from the NetworkIPSec Tunnels tab when you push the configuration changes from the secondary
Panorama.
Workaround: If you have set up a HA pair in Panorama, don't push the configuration
from the secondary Panorama when the primary Panorama is active. Always push the
configuration changes from the primary Panorama when it's active.
PAN-190173
Pre-shared keys are not synchronized across the Panorama
management servers in a high availability (HA) configuration, leading
to tunnel flaps during an HA failover when you Push to
Devices (CommitPush to Devices or CommitCommit and Push).
This issue is addressed in SD-WAN plugin 2.2.3 and 3.1.0-h6.
PLUG-18422
Description of PLUG-18422.
If your high availability (HA) firewalls enter an inconsistent HA state, the Panorama
management server considers the state of those HA firewalls as active/active,
suspended/suspended, or passive-passive. In this case, commits on the Panorama
management server will succeed regardless of the state of the firewall. However,
Panorama will still display a warning message for an invalid HA pair and will not
generate a new configuration for those HA firewalls that are in an inconsistent state.
Any new SD-WAN configuration changes to the VPN cluster will not be applied to the
inconsistent HA firewalls.
Workaround: Recover the HA pair in correct state (active/passive). Verify that the
inconsistent HA firewalls return to an active/passive HA state by running the XML API
show devices all command. After the verification, you can
again commit your changes on the Panorama management server to push the changes to all
firewalls.
PLUG-17728
Description of PLUG-17728.
While upgrading from SD-WAN plugin 2.2.6 version to 2.2.7, you may encounter the
following commit error:
IP address from vpn address pool subnet/subnets are exhausted.
Workaround: Add a new VPN address pool.
PLUG-17704
Description of PLUG-17704.
The SD-WAN plugin enforces all the HA firewalls in the SD-WAN cluster to be in a complete
functional state. Due to this enforcement, even when one firewall goes nonfunctional,
the SD-WAN plugin prevents making configuration changes to any of the HA firewalls in
the SD-WAN cluster.
This issue is addressed in SD-WAN plugin 2.2.7.
PLUG-16507
Description of PLUG-16507.
(HA deployments only) You may observe SD-WAN tunnel flapping and changes to the
SD-WAN interfaces when you perform a commit operation after any of the following:
- HA failover
- PAN-OS upgrade or downgrade
- Reboot the HA pair
This issue is addressed in SD-WAN plugin 3.3.2,
3.3.1 , 3.2.2,
3.0.8
, and 2.2.7.
PLUG-16141
Description of PLUG-16141.
The SD-WAN log files are overwritten and the critical events does not get captured in the
system logs that cause difficulty in debugging the SD-WAN plugin-related issues.
This issue is addressed in SD-WAN plugin 2.2.7, 3.0.8
, 3.2.2, and 3.3.2. After the fix, the following
critical events are added to the system logs.
- PSK creation or PSK change for a VPN cluster
- Tunnel name, IP address creation, or IP address change
PLUG-16048
Description of PLUG-16048.
(HA deployments only) Passive Panorama makes changes to the SD-WAN plugin
database cache entries.
This issue is addressed in SD-WAN plugin 2.2.7, 3.0.8
, 3.2.2, and 3.3.2.
PLUG-15823
Description of PLUG-15823.
(Full mesh topology only) The SD-WAN devices neither go out-of-sync nor show up
in the commit scope when a new hub device gets added to the full mesh VPN cluster.
This issue is addressed in SD-WAN plugin 2.2.7,
3.0.7-h2, 3.0.8, 3.2.2,
3.3.1, and 3.3.2.
PLUG-15761
Description of PLUG-15761.
In some cases, after HA failover followed by a commit and commit push from the Panorama
will result in the tunnel going down. It's because a new tunnel IP address gets
generated for the firewall after a HA failover.
Workaround: After committing the configuration changes to Panorama, perform a
commit and push on the all the SD-WAN devices in the SD-WAN VPN cluster even if the
templates are in synchronization with the Panorama management server.
This issue is addressed in SD-WAN plugin 2.2.7, 3.0.8, 3.2.2, 3.3.1, and 3.3.2.
PLUG-15525
Description of PLUG-15525.
It's not possible to revert to any of the earlier pre-shared keys except the current
pre-shared key.
This issue is addressed in SD-WAN plugin 2.2.7, 3.0.8
, 3.2.2, and 3.3.2. After the fix, you can revert
to any of the earlier pre-shared keys (if it's available).
PLUG-15415
Description of PLUG-15415.
(HA deployments only) The HA synchronization failure occurs on the passive
Panorama when you either upgrade or downgrade the HA Panorama. The issue is caused due
to HA failover between the active and passive SD-WAN devices.
This issue is addressed in SD-WAN plugin 2.2.7, 3.0.8,
, 3.2.2, 3.3.1, and 3.3.2.
PLUG-14413
Description of PLUG-14413.
(HA Deployments only) If the HA environment is not configured correctly or when
either of HA pair is not present, then no proper commit failure is displayed for
troubleshooting.
This issue is addressed in SD-WAN
plugin 2.2.7, 3.0.8, 3.2.2,
and 3.3.2. After the fix, the improved failure message helps in identifying
the missing HA device in the HA deployment.
PLUG-14402
Description of PLUG-14402
The return merchandise authentication (RMA) process won't be successful if you delete the
replacement firewall without removing it from the SD-WAN plugin first.
This issue is addressed in SD-WAN plugin 2.2.6,
3.0.7, 3.2.1, and 3.3.0. Follow the instructions to replace an SD-WAN
device.
PLUG-13215
Description of PLUG-13215
While configuring SD-WAN Interface Profile (NetworkNetwork ProfilesSD-WAN Interface Profile) on the branch device, disabling VPN Data Tunnel
Support for MPLS Link Type will throw a commit
failure on the firewall.
This issue is addressed in SD-WAN plugin 2.2.5. After the fix, the commit failure is
not thrown on the firewall.
PLUG-13152
Description of PLUG-13152
The SD-WAN plugin creates predefined zones automatically that does not require any user
configuration. Hence, we have removed the following predefined zones tabs from the
SD-WAN plugin web interface:
- Zone Internet
- Zone to Hub
- Zone to Branch
- Zone Internal
This issue is addressed in SD-WAN plugin 2.2.5 and 3.0.5.
PLUG-12724
Description of PLUG-12724.
Configuration synchronization between Panorama HA peers fails after downgrading from the
following SD-WAN plugin releases.
- Downgrading from SD-WAN plugin 3.1.0-h6/2.2.4 to SD-WAN plugin 2.2.2 or earlier release.
- Downgrading from SD-WAN plugin 3.1.0-h6 to SD-WAN plugin 3.0.3 or earlier release.
- Downgrading from SD-WAN plugin 3.1.0-h6 to SD-WAN plugin 3.1.0 release.
Workaround: Before you downgrade the SD-WAN plugin, clear all the SD-WAN plugin
database collections on both active and passive Panorama. After the downgrade, make
changes to the cluster (for example, cluster name), commit the configuration changes
from the active Panorama, and push the changes to all the devices.
PLUG-12711
Description of PLUG-12711
A commit all from Panorama to an SD-WAN branch firewall configured with only one MPLS
will result in a commit failure.
This issue is addressed in SD-WAN plugin 2.2.5 and 3.0.5.
PLUG-12224
Description of PLUG-12224.
For an SD-WAN tunnel between a hub and a branch, the hub/branch tunnel interface should
have the same IP address on the HA active and passive firewalls, but the hub/branch has
different IP addresses on the HA active and passive firewalls.
This issue is addressed in SD-WAN plugin 2.2.4, 2.2.7,
3.0.4, 3.0.8, 3.1.0-h6
, 3.2.2, and 3.3.2. Tunnel ID changes will take
effect from SD-WAN plugin 2.2.4. If you are running SD-WAN plugin 2.2.2 and upgrade
to 2.2.4, you must regenerate the cluster configuration and push to devices to see
those changes.
PLUG-12156
Description of PLUG-12156
On the Hub-Spoke VPN cluster type, if you make any changes to an
existing cluster member configuration or add a new device to the cluster, the push gets
enabled for all the VPN cluster members.
This issue is addressed in SD-WAN plugin 2.2.6 ,
3.0.7-h2, 3.2.1
, and 3.3.0.
PLUG-12126
Description of PLUG-12126
The VPN cluster is recreated when the name of an existing VPN cluster is modified. As a
result, the pre-shared key and tunnel IP addresses changes causing failure to establish
the VPN tunnel (or tunnel flaps).
This issue is addressed in SD-WAN plugin 2.2.6, 3.0.7, and 3.1.3. After this fix,
you won't be able to modify the existing VPN cluster name.
PLUG-11789
Description of PLUG-11789.
Pre-shared keys are not synchronized across the Panorama management servers in a high
availability (HA) configuration, leading to tunnel flaps during an HA failover when you
Push to Devices (Commit > Push to Devices or Commit > Commit and Push).
This issue is addressed in SD-WAN plugin 2.2.3, 3.0.4, and 3.1.0-h6.
PLUG-11761
Description of PLUG-11761.
Prisma Access onboarding is unsuccessful using SD-WAN plugin 2.2.2 and after filling out
all the required information, the plugin shows the PHP bit error. Users are unable to
onboard Prisma Access on a branch firewall.
This issue is addressed in SD-WAN plugin 2.2.3, 3.0.4, and 3.1.0-h6.
PLUG-11453
Description of PLUG-11453.
A Zone Protection profile, log setting, and User-ID cannot be configured on
"zone-internet" created by the SD-WAN plugin on the firewall from Panorama.
This issue is addressed in SD-WAN plugin 2.2.3, 3.0.4, and 3.1.0-h6.
PLUG-11383
Description of PLUG-11383.
SD-WAN plugin fails to get Prisma Access connection details for the onboarding
process.
This issue is addressed in SD-WAN plugin 2.2.3 and 3.0.4.
PLUG-11277
Description of PLUG-11277
In an SD-WAN hub-and-spoke topology, where Prisma Access compute nodes (CNs) are
configured as a hub connecting to the PAN-OS firewalls, the session gets established on
only one compute node when ECMP is disabled. When more than one compute nodes are
connected to the PAN-OS firewalls, routes get added from one of the compute nodes only.
Even though the branch firewalls learn the routes through BGP from both the Prisma
Access compute nodes, the branch installs only one of the BGP routes based on the BGP
route selection criteria. Therefore, when a traffic passes from the other compute node,
the session does not get established.
This issue is addressed in SD-WAN plugin 2.2.6, 3.0.7, 3.1.3, and 3.2.1.
PLUG-11223
Description of PLUG-11223.
In a high availability (HA) deployment, the SD-WAN tunnel will go down due to a key ID
mismatch when the following events occur in sequence:
- An HA failover
- The SD-WAN plugin cache removes the current HA pair relation from the database when debug plugins sd_wan drop-config-cache all command is executed
- A commit and push fails on either the hub or a branch active node
In certain scenarios, replacing one of the HA devices during the RMA process can cause
the SD-WAN tunnel to go down due to a key ID mismatch. For more details, refer to Replace an SD-WAN Device.
Workaround: Resolve the Key ID mismatch by ensuring that the Peer
Identification of the hub firewall matches with the Local
Identification of the branch firewall and the Local
Identification of the hub firewall matches with the Peer
Identification of the branch firewall.
- Log in to the hub or a branch firewall where the SD-WAN tunnel is down due to Key ID mismatch and select NetworkNetwork ProfilesIKE Gateways.
- Select the IKE gateway of the hub firewall and click Override at the bottom of the screen.
- Copy the Local Identification value from the hub firewall to the Peer Identification value in the branch firewall.
- Copy the Peer Identification value from the hub firewall to the Local Identification value in the branch firewall.
- Click OK and Commit your changes.
This issue is addressed in SD-WAN plugin 2.2.5 ,
2.2.7, 3.0.8, 3.1.3
, 3.2.1,
3.2.2
, 3.3.0,
and 3.3.2.
After this fix, the key ID may
change after the Panorama commit. Therefore, you must ensure to commit and push to
all the devices in the VPN cluster or clusters.
PLUG-11062
Description of PLUG-11062.
When configuring upstream NAT on the SD-WAN plugin, the drop-down does not list AE
interface or subinterface, even though the firewall is configured with AE interface or
subinterface.
This issue is addressed in SD-WAN plugin 2.2.3 and 3.0.4.
PLUG-10796
On the Panorama management server, a
commit (CommitCommit
to Panorama) hangs at 99% and causes the
commit queue to fill up, preventing any subsequent commits on Panorama.
This issue is addressed in SD-WAN plugin 2.2.2 and 3.0.2.
PLUG-10457
After successful upgrade to SD-WAN 2.1.0
and later releases, the Panorama management server takes 10 minutes
to commit (CommitCommit
to Panorama) configuration changes regardless
of what configuration change was made.
This issue is addressed in SD-WAN plugin 2.2.2 and 3.0.2.
PLUG-10432
The SD-WAN plugin is unable to retrieve
the Prisma Service IP, preventing the onboard of Prisma Access tenants.
This is addressed in SD-WAN plugin 2.2.2 and 3.0.2.
PLUG-10165
On the Panorama management server, commits
(CommitCommit to Panorama)
fail if your SD-WAN firewalls associated with the SD-WAN plugin (PanoramaSD-WAN)
configuration are removed from Panorama management (PanoramaManaged DevicesSummary).
Workaround: Remove the SD-WAN configuration after you
remove your SD-WAN firewalls from Panorama management.
- Select PanoramaPlugins and search for sd_wan.
- Remove Config.
- Click OK to confirm removing the SD-WAN configuration from Panorama.
This is addressed in SD-WAN plugin 2.2.2 and 3.0.2.
PLUG-10047
This issue is resolved in SD-WAN version 2.1.2.
You cannot add a branch firewall configured with an MPLS, Satellite,
or Microwave/Radio interface (NetworkNetwork ProfilesSD-WAN Interface
Profile) to a VPN Cluster (PanoramaSD-WANVPN
Clusters) if the hub firewall or any branch
firewall in the VPN Cluster are not also configured with at least
one MPLS, Satellite, or Microwave/Radio interface.
For example, you cannot add a branch firewall configured with
MPLS and Wifi interfaces to a VPN Cluster where the firewall members
do not have at least one MPLS interface configured.
PLUG-9917
When adding an SD-WAN branch to be managed by Panorama, a message appears to "Please
configure AS number for the branch on the BGP tab first." However, the AS field should
be allowed to be left empty for manual routing configuration.
This issue is addressed in SD-WAN plugin 2.2.1.
PLUG-9421
The Panorama plugin for SD-WAN is unable to recognize
when the master key (PanoramaMaster Key and Diagnostics)
is updated on the Panorama management server.
Workaround: Select Commit and Commit
and Push to your managed firewalls leveraging SD-WAN
after updating the master key on Panorama.
This issue is addressed in PAN-OS 10.2.1-h1 and SD-WAN plugin
2.2.1.
PLUG-3343
The SD-WAN plugin fails to display any
of the monitoring for a site and cluster with a space in the name.
Workaround: Remove the space from the name and Commit.