Updated July 11th, 2022

VMware SD-WAN Orchestrator Version R402-20220113-GA
VMware SD-WAN Gateway Version R402-20220614-GA
VMware SD-WAN Edge Version R402-20220614-GA

Check regularly for additions and updates to these release notes.

What's in the Release Notes

The release notes cover the following topics:

Recommended Use

This release is recommended for all customers who require the features and functionality first made available in Release 4.0.0, as well as those customers impacted by the issues listed below which have been resolved since Release 4.0.1.


Release 4.0.2 Orchestrators, Gateways, and Hub Edges supports all previous VMware SD-WAN Edge versions greater than or equal to Release 3.0.0 
Note: this means releases prior to 3.0.0 are not supported.

The following interoperability combinations were explicitly tested:































3.4.3, 3.4.4, 3.4.5


 3.3.2 P3 *

 3.3.2 P3 *

 3.3.2 P3 *



 3.3.2 P3 *

 3.3.2 P3 *




3.3.2 P2, 3.3.2 P3 *



 3.3.2 P2 *



  3.2.2 * 

 3.2.2 * 

 3.2.2 *



 3.2.2 *

  3.2.2 * 




 3.2.2 *



 3.2.2 *






















Note: Interoperability with Release 3.x was explicitly tested as part of Release 4.0.0 testing, and there are no protocol changes between Release 4.0.0 and Release 4.0.2 that required explicitly re-testing more combinations than is shown in the above table.

* Warning: VMware SD-WAN Releases 3.2.x and 3.3.x are approaching End of Support.
Releases 3.2.x and 3.3.x will reach End of General Support (EOGS) on December 15, 2021, and End of Technical Guidance (EOTG) March 15, 2022.
For more information please consult the Knowledge Base article: Announcement: End of Support Life for VMware SD-WAN Release 3.x (84151)

* Warning: VMware SD-WAN Releases 4.0.x and 4.2.x are approaching End of Support. 

  • Release 4.0.x will reach End of General Support (EOGS) on September 30, 2022, and End of Technical Guidance (EOTG) December 31, 2022. 
  • Release 4.2.x Orchestrators and Gateways will reach End of General Support (EOGS) on December 30, 2022, and End of Technical Guidance (EOTG) March 30, 2023.   
  • Release 4.2.x Edges will reach End of General Support (EOGS) on June 30, 2023, and End of Technical Guidance (EOTG) September 30, 2023.
  • For more information please consult the Knowledge Base article: Announcement: End of Support Life for VMware SD-WAN Release 4.x (88319)

Compatibility Note

Release 3.x did not properly support AES-256-GCM, which meant that customers using AES-256 were always using their Edges with GCM disabled (AES-256-CBC). If a customer is using AES-256, they must explicitly disable GCM from the Orchestrator prior to upgrading their Edges to a 4.x Release. Once all their Edges are running a 4.x release, the customer may choose between AES-256-GCM and AES-256-CBC.

Doing the above will prevent interoperability issues between 3.x and 4.x Edges.

Important Notes

BGPv4 Filter Configuration Delimiter Change for AS-PATH Prepending

Through Release 3.x, the VMware SD-WAN BGPv4 filter configuration for AS-PATH prepending supported both comma and space based delimiters. However, beginning in Release 4.0.0 and forward, VMware SD-WAN will only support a space based delimiter in an AS-Path prepending configuration.
Customers upgrading from 3.x to 4.x need to edit their AS-PATH prepending configurations to "replace commas with spaces" prior to upgrade to avoid incorrect BGP best route selection.

Extended Upgrade Time for Edge 3x00 Models

Upgrades to this version may take longer than normal (3-5 minutes) on Edge 3x00 models (i.e., 3400 and 3810). This is due to a firmware upgrade which resolves issue 53676. If an Edge 3400 or 3800 had previously upgraded its firmware when on Release 3.4.5, then the Edge would upgrade within the expected time.  For more information, please consult Fixed Issue 53676.

Reverse-Path Forwarding (RPF) Enabled by Default

In previous releases, packets with an unknown source were allowed from the LAN interface of a VMware SD-WAN Edge. This behavior was the result of the Edge's LAN interfaces not having reverse-path forwarding (RPF) enabled by default. As part of Fixed Issue 52628, this behavior is changed with RPF enabled on all Edge LAN interfaces, and packets from LAN interfaces would be allowed only if the packets are sourced from the configured LAN subnet.

Limitation When Disabling Autonegotiation on VMware SD-WAN Edge Models 520, 540, 620, 640, 680, 3400, 3800, and 3810

When a user disables autonegotiation to hardcode speed and duplex on ports GE1 - GE4 on a VMware SD-WAN Edge model 620, 640 or 680; on ports GE3 or GE4 on an Edge 3400, 3800, or 3810; or on an Edge 520/540 when an SFP with a copper interface is used on ports SFP1 or SFP2, the user may find that even after a reboot the link does not come up.

This is caused by each of the listed Edge models using the Intel Ethernet Controller i350, which has a limitation that when autonegotiation is not used on both sides of the link, it is not able to dynamically detect the appropriate wires to transmit and receive on (auto-MDIX). If both sides of the connection are transmitting and receiving on the same wires, the link will not be detected.

If the peer side also does not support auto-MDIX without autonegotiation, and the link does not come up with a straight cable, then a crossover Ethernet cable will be needed to bring the link up.

For more information please see the KB article Limitation When Disabling Autonegotiation on VMware SD-WAN Edge Models 520, 540, 620, 640, 680, 3400, 3800, and 3810 (87208).

Document Revision History

February 24th, 2021. First Edition.

April 13th, 2021. Second Edition.

  • Added Fixed Issue 53676 to Edge/Gateway Resolved Issues section.  This issue was erroneously omitted from the original Release Notes.
  • Added an Important Notes section that addresses the extended upgrade time a 3x00 would experience if their firmware needed to be upgraded as part of the fix for 53676.

June 6th, 2021. Third Edition.

  • Added "Reverse-Path Forwarding (RPF) Enabled by Default" entry to the Important Notes section to explicitly call out the change in behavior that results from Fixed Issue 52628.
  • Added Issue 44526 to the Known Issues under Edge/Gateway.

September 16th, 2021. Fourth Edition. 

  • Added to Important Notes the Note: BGPv4 Filter Configuration Delimiter Change for AS-PATH Prepending.

December 21st, 2021. Fifth Edition.

  • Added a new Orchestrator build R402-20211216-GA to Orchestrator Resolved Issues. This Orchestrator build remediates CVE-2021-44228, the Apache Log4j vulnerability, by updating to Log4j version 2.16.0. For more information on the Apache Log4j vulnerability, please consult the VMware Security Advisory VMSA-2021-0028.5.
  • Added to Important Notes the Note: Limitation When Disabling Autonegotiation on VMware SD-WAN Edge Models 520, 540, 620, 640, 680, 3400, 3800, and 3810. This note covers an issue that may be encountered when configuring a forced speed on some Ethernet ports of the listed Edge models.

January 28th, 2022. Sixth Edition.

  • Added a new Orchestrator build R402-20220113-GA to Orchestrator Resolved Issues. This Orchestrator build remediates Apache Log4j vulnerabilities CVE-2021-44228 (which was first addressed in Orchestrator build R402-20211216-GA with Log4j version 2.16.0) and CVE-2021-45046, by updating to Log4j version 2.17.0. For updated information on the Apache Log4j vulnerabilities and their impact on VMware products, please consult the VMware Security Advisory VMSA-2021-0028.9.

March 24th, 2022, Seventh Edition

  • Added Issue #84825, to the Edge/Gateway Known Issues section.

July 11th, 2022. Eighth Edition.

  • Added a new Edge/Gateway build R402-20220614-GA to the Edge/Gateway Resolved Issues section. These are the new Edge and Gateway GA builds for Release 4.0.2. The Edge and Gateway builds add no additional fixed tickets, but do contain performance and troubleshooting updates required by VMware Engineering.
  • Added a new warning in the Compatibility section regarding Release 4.0.x and 4.2.x approaching End of Support.

Resolved Issues

The resolved issues are grouped as follows.

Edge/Gateway Resolved Issues

Resolved in Edge/Gateway Version R402-20220614-GA

Edge/Gateway version R402-20220614-GA was released on 07-01-2022. 

These Edge and Gateway builds add no new fixed issues since Edge and Gateway version R402-20210218-GA, but do contain performance and troubleshooting updates required by VMware Engineering.

    Edge/Gateway Resolved Issues

    Resolved in Version R402-20210218-GA

    The below issues are resolved since Edge version R401-20201110 and Gateway version R401-20201124-GA-53090.

    • Fixed Issue 32917: The output is not accurate for the Multicast PIM Neighbors monitoring page on the VMware SD-WAN Orchestrator.

      The inaccurate output for Multicast PIM Neighbors on the Edge monitoring page may include the PIM interface for some of the Edges showing a garbage value instead of an actual interface and PIM neighborship still showing in monitoring even after it gets deleted from the Edge. 

    • Fixed Issue 36956: When the Remote Diagnostic “Flush Firewall Sessions” is run or a diagnostic bundle is generated for a VMware SD-WAN Edge where a firewall is enabled and there are at least 22K firewall flows present, the Edge may experience a Dataplane Service Failure and restart the service to recover.

      This issue is extremely rare in the field, and VMware Engineering cannot consistently recreate it. When Engineering does recreate the issue, it is as outlined in the Symptom section. The reason generating a diagnostic bundle can trigger this issue for an Edge using a firewall is that the diagnostic bundle includes the debug log: user_firewall_dump, and generating this log is linked to issue 36956. 

    • Fixed Issue 48612: VMware SD-WAN Virtual Gateways and Edges using a X710/XL710 network adapter strip all Rx packet VLAN tags.

      This issue would have a major impact for customers using a Gateway as configured which also has DPDK enabled as they would not be able to process VLAN tagged traffic on its handoff interface. This issue was traced to the i40evf DPDK driver which sent opcode VIRTCHNL_OP_ADD_VLAN to the Physical Function (PF) to add VLAN filtered tags, however, the PF driver enabled VLAN tag stripping as part of the command to enable VLAN tag filtering and consequently all VLAN tags were stripped.

    • Fixed Issue 49139: A VMware SD-WAN Virtual Edge that is deployed and activated without an accompanying initial software update can run out of disk space (inodes).

      When deploying a Virtual Edge, if the activation of the Edge does not also immediately update the edge to a GA software version, it is possible for the Edge to run out of inodes during operation after a few additional files are created.

    • Fixed Issue 49598: When a VMware SD-WAN Gateway has a large amount of traffic backhauled and several tunnels to the Gateway are unstable, the VMware SD-WAN Edges connected to that Gateway will observe degraded performance in the form of intermittent packet loss.

      A large amount of backhaul traffic should be understood as ~700k backhauled flows to a Gateway with ~6K tunnels. At that scale, if ~100 Edges have unstable connections that cause tunnels to be repeatedly torn down and rebuilt to the Gateway, the result will be a hash table collision which leads to high CPU usage for a particular thread and intermittent packet loss for connected Edges. When looking in the Gateway logs or using debug.py --handoff a user would observe an exceptionally large number of handoff queue drops for vc_queue_vcmp_ctrl and vc_queue_vcmp_bottom handoffs.

    • Fixed Issue 51108: VMware SD-WAN Edge continues to send traffic to the VMware SD-WAN Gateway of a Non SD-WAN Destination (NSD) even when the NSD tunnels on the Gateway are down.

      The Gateway does not send the NSD reachability event to Edges when the NSD public IP address is changed on the VMware SD-WAN Orchestrator and that was causing the Edge to continue to forward traffic to the NSD via Gateway. Without the fix the only corrective action is to bounce the NSD tunnel on the Gateway.  

    • Fixed Issue 51116: Remote flows are not classified correctly using Application Map IP subnets.

      This affects traffic for two Edges that are using Edge to Edge via Gateway.  On the remote edge, the flow table flips the source IP address/port and the destination IP address/ port and because the Application map lookup is using only destination IP address/port, the flows get classified incorrectly.

    • Fixed Issue 51166: On a VMware SD-WAN Edge 610, if GE2 is configured as a routed interface and a VLAN is configured on it, traffic on that VLAN gets dropped. 

      Due to an incorrect programming of the Edge 610’s switch, the VLAN tables were not properly set up when GE1 or GE2 are converted to routed interfaces. An Edge 610 without this fix should only use GE3 through GE6 as routed interfaces with VLANs.

    • Fixed Issue 51881: When a Direct Non SD-WAN Destination via Edge is deleted, the memory is not freed up properly on the VMware SD-WAN Edge.

      For Direct Non SD-WAN Destinations (NSD) via Edge, the references on a internal data structure were being incorrectly counted and hence were not freeing the memory post deletion of an NSD provider. The increase in memory would be seen only if multiple NSD via Edge providers are deleted and new ones added.  The memory leak would impact lower Edge models with smaller memory footprints (e.g. Edge 510, 520, 610, etc.) and worst case would cause a one-time Edge service restart to clear the memory leak.  This issue does not affect customers who delete a Non SD-WAN Destination via Gateway, this is specific to the NSD via Edge type.

    • Fixed Issue 51915: For a site where the SD-WAN Edges are deployed in a High-Availability topology, should the site have an HA failover, Cloud via Gateway traffic switches to Direct to Cloud traffic.

      After HA failover, if the path to the VMware SD-WAN Gateway is not up when the traffic reaches the Edge, the traffic goes 'Direct to Cloud' instead of 'Cloud via Gateway'. Direct to Cloud traffic does not utilize VMware SD-WAN’s Dynamic Multipath Optimization (DMPO) and traffic sensitive to loss or jitter would not benefit from these enhancements when sent Direct.

    • Fixed Issue 52102: Symptom: For an enterprise using a Hub/Spoke topology, existing flows are dropped on a VMware SD-WAN Spoke Edge when recovering from a Hub Edge failover for a given tuple. 

      Description: The sequence of events leads to this issue when a primary Hub Edge recovers from failover: 

      1. When the primary Hub Edge goes down, the route is removed from the FIB for that primary Hub Edge while retaining the routes in the RIB. 

      2. Existing flows will now switch to the secondary Hub Edge. 

      3. When the primary Hub comes back up, a tunnel is immediately established between the primary Hub from the Spoke Edge. 

      4. Routes in the RIB which were previously learned from the primary Hub via the Gateway are scanned and routes are installed in the FIB pointing to this primary Hub. 

      5. Traffic will switch back to the primary Hub whereas the primary Hub would not have learned the routes from its BGP neighbor. 

      6. This causes route lookup to match on the default route and return traffic is marked with a backhaul flag. 

      7. The Spoke Edge is not expecting return traffic with a backhaul flag set and this leads to traffic being dropped. 

      Absent this fix, the only way to address this issue is to run the Remote Diagnostic ‘Flush Flows’ on the Hub Edge for the given tuple. 

    • Fixed Issue 52141: If the TCP socket that connects a VMware SD-WAN Edge's OSPF process and SD-WAN process goes down and must recover, the Edge’s OSPF default route may not get refreshed, leading to traffic failure for that site. 

      If there is a flap in the Zebra channel (the TCP socket) between the OSPF process (ospfd) and the SD-WAN process (edged). Around the same time there was a link-state advertisement (LSA) refresh scheduled for the default route in OSPF. Due to the timing, ospfd found that the Zebra channel is not set up and hence it skipped the regeneration of the LSA when its timer expired around the same time. After this the LSA was removed (since it was not refreshed) with the result that no traffic could be passed in the network using this Edge. The fix forces the OSPF process to refresh the entire configuration and ensure that the default route is always present.

    • Fixed Issue 52342: The Remote Diagnostics page on the VMware SD-WAN Orchestrator UI may fail to load.

      For Release 4.x, VMware introduced WebSocket to replace the live-heartbeat previously used in Remote Diagnostics. However, the VMware SD-WAN Edge sourced the WebSocket connection on the default WAN IP, causing random traffic drop on the middleware or the Edge itself. Binding the WebSocket with a VMware-specified IP resolves the issue.

    • Fixed Issue 52628: Packets with an unknown source are allowed from the LAN interface of a VMware SD-WAN Edge.

      For this issue, packets which are sourced from a subnet different from the LAN subnet are allowed to pass through the Edge. This is caused by the Edge LAN interfaces not having reverse-path forwarding (RPF) enabled. The fix enables RPF on all Edge LAN interfaces and packets from LAN interfaces would be allowed only if the packets are sourced from the configured LAN subnet. 

    • Fixed Issue 52659: When a VMware SD-WAN Edge is configured as a DHCP relay agent, the Edge does not forward the DHCP NAK packets to a client.

      If the DHCP server sends DHCP NAK packets, the Edge which is configured as DHCP relay will drop the packets without forwarding them. 

    • Fixed Issue 52954: For a customer enterprise where Multicast is being used, PIM (Protocol-Independent Multicast) neighbors do not scale to the supported limit of ~1600.

      This issue occurs in a particular scenario where there are 4000 Spoke Edges separated by two Spoke profiles, one with Multicast disabled and the other with Multicast enabled. If pimd (the process that manages PIM) goes down and then comes back up, the Hub Edge will not reestablish the expected 1600 PIM neighbors.

    • Fixed Issue 53019: A VMware SD-WAN Edge may experience a Dataplane Service Failure when receiving a corrupted packet. 

      The Edge my interpret the corrupted packet (e.g., an invalid message sent by a peer) as a VeloCloud Management Control packet (NACK) which the Edge has no ability to process properly and thus experiences the Dataplane Service failure and restarts the service to recover. The packet in the field case was sent by a peer device.

    • Fixed Issue 53176: When a VMware SD-WAN Edge 610 undergoes a VRRP state transition from Backup to Active, there is LAN to WAN traffic loss for ~4 minutes.

      The Edge 610 does not learn the VRRP MAC address after it becomes Active, so traffic is dropped until the Edge 610 learns the MAC address, which takes ~4 minutes. 

    • Fixed Issue 53243: Traffic may drop to a Non SD-WAN Destination (NSD) that uses a Check Point type because the Gateway does not delete the Phase 2 Security Association (SA). 

      Peers would be out of sync in terms of the SA and the link would be down until the SA expires. In an NSD using a Check Point firewall type, when the link is not stable it is possible to end up with a situation when the peer sends a Delete Notify, but the Gateway cannot delete Phase 2 SA because the corresponding Phase 1 SA has already been deleted. 

    • Fixed Issue 53426: The local underlay BGP route is not correctly sorted in the VMware SD-WAN Edge’s forwarding information base (FIB) relative to the BGP routes from the Hub Edge(s), and the overlay preferred route on an Edge is not correctly redistributed to the underlay BGP. 

      When the DCC flag is enabled, the route's preference and advertise values are changed but the underlay route is not being correctly re-sorted in the Edge FIB.  Also, when the underlay BGP route is initially preferred in the Edge FIB and later, an overlay BGP route is preferred over the locally learned route, due to an issue in the redistribution logic, the overlay route is not being correctly redistributed to the underlay BGP. Without the fix, the Edge must be forced to relearn either the underlay or overlay BGP route as appropriate. 

    • Fixed Issue 53439: A VMware SD-WAN Gateway stops attempting a VPN's IKE rekey after several unsuccessful attempts.

      This issue may impact customers using Non SD-WAN Destinations via Gateway that are policy-based (route-based VPNs are not affected). For a policy based VPN (e.g., Cisco ASA, Generic Firewall), user traffic sent via the VPN must initiate a new security association (SA) if for whatever reason the previous SA was deleted. When this happens, the IKE rekey uses the wrong traffic selectors, which causes the new SA creation to fail. In this situation traffic to the Non SD-WAN Destination will be down indefinitely until a new configuration change is pushed from the VMware SD-WAN Orchestrator. If the previous SA has not been deleted when rekey happens there is no issue, meaning not all customers and all rekeys will be impacted by this issue.

    • Fixed Issue 53477: When VMware SD-WAN Edges configured in a High Availability topology are moved to a different configuration profile, the Edges experience repeated Edge service restarts.   

      For this issue, one of the HA Edges is configured to have more LAN or WAN interfaces than the other HA Edge (e.g., a WAN port is disabled one of the Edges), and then if these Edges are moved to a different profile, the Edges will experience continuous Edge service restarts.

    • Fixed Issue 53546: If MPLS CoS (Class of Service) is enabled and if one of the CoS in the private link has loss, packets in the other CoS can be dropped due to oversubscription. 

      If one or more sub-paths in the private link enters an unstable state due to loss, the entire bandwidth of the private link will be excluded from the device bandwidth cap calculation. As a result, some of the packets in the other sub-paths may be dropped if the current bandwidth usage exceeds the device bandwidth cap. The device bandwidth cap is calculated by finding the sum of bandwidth of the stable links. 

    • Fixed Issue 53656: User cannot login into a VMWare vSphere VM deployed from either a VMware SD-WAN Orchestrator or VMware SD-WAN Gateway OVA.

      After deploying an Orchestrator or Gateway OVA in vSphere, the system fails to parse vApp metadata and apply the provided password and network configuration.

    • Fixed Issue 53676: On the VMware SD-WAN Edge 3x00 platform, very brief periods of input voltage instability, as short as 4 milliseconds, can cause the Edge to reboot.

      This issue is typically seen when using an Uninterruptible Power Supplies (UPS) that experiences slight output voltage instability when switching from line to battery. The fix for this issue upgrades the Edge’s firmware to tolerate 20-30ms of voltage instability prior to the Edge rebooting.

      Note: Upgrading the 3x00's firmware will extend the Edge's upgrade time to 3-5 minutes if the Edge did not previously have their firmware upgraded when using Release 3.4.5 or 4.0.2.

      For an Edge 3x00 model without this fix, the customer’s only option is to use a more sophisticated UPS that can switch its input without any output voltage instability. 

    • Fixed Issue 53809: For a customer deploying VMware SD-WAN Edges in an Enhanced High Availability topology, in the event of a failover, the HA failover event will always specify the reason for failover as peer heartbeat failure - "Standby going active, peer heartbeat failure" irrespective of the actual reason.

      In the case of Enhanced HA, if the LAN or WAN interface go down and there is an HA failover, the events will describe the reason as "Standby going active, peer heartbeat failure" instead of "Standby going active, Peer WAN interface(s) down" or "Standby going active, Peer LAN interface(s) down".

    • Fixed Issue 53837: Remote Diagnostics page does not load on the VMware SD-WAN Orchestrator UI with the web page staying at "Entering into live mode".

      This issue is linked with Orchestrator issue 52342 (also in these Release Notes), and the fix here addresses an issue on the VMware SD-WAN Edge side of things and together both issues ensure that the Remote Diagnostics page will always load.

    • Fixed Issue 53864: The local underlay OSPF route is not correctly sorted in the VMware SD-WAN Edge’s forwarding information base (FIB) relative to the OSPF routes from the Hub Edge(s), and the overlay preferred route on an Edge is not correctly redistributed to the underlay OSPF. 

      When the DCC flag is enabled, the route's preference and advertise values are changed but the underlay route is not being correctly re-sorted in the Edge FIB.  Also, when the underlay OSPF route is initially preferred in the Edge FIB and later, an overlay OSPF route is preferred over the locally learned route, due to an issue in the redistribution logic, the overlay route is not being correctly redistributed to the underlay OSPF. Without the fix, the Edge must be forced to relearn either the underlay or overlay OSPF route as appropriate. 

    • Fixed Issue 53977: An Azure VM created from VMware SD-WAN Orchestrator or VMware SD-WAN Gateway images may fail to boot.

      After creating a VM from an Azure Orchestrator or Gateway image, the VM may fail to boot with "Cannot open root device" error on the serial console.

    • Fixed Issue 54001: A VMware Edge is unable to send traffic after a Tx queue hang on SFP interfaces.

      In rare cases, when the Edge sends an invalid sized packet (less than 17 bytes or greater than 1526 bytes) to DPDK, the transmit queue becomes stalled and causes any further traffic to not be forwarded by the Edge. Rebooting the Edge temporarily corrects the issue, but the problem can happen again when an invalid sized packet is sent from the Edge service to DPDK. Only upgrading to a level with the fix avoids this problem. 

    • Fixed Issue 54493: An Operator or Partner administrator may observe an increasing number of handoff queue drops for Edge traffic on a VMware SD-WAN Gateway.

      For this issue the Gateway would not have CPU utilization issues or DPDK drops. The issue is triggered by a control plane event (for example, route recalculation) and the Gateway begins to drop Edge packets during handoff to different threads in the Gateway's pipeline. The cause of the issue is an insufficiently large queue size queue size for packet buffering.

    • Fixed Issue 54519: In instances where a Non SD-WAN Destination with a Generic Firewall is misconfigured, a user may observe an error related to an SA leak.

      This is not a security issue as the leak is internal and does not involve leaking SA information to the outside. The SA leak is caused by a traffic selector misconfiguration for a Generic Firewall policy. Some peers do not check traffic selector range and reply back to IPSEC SA negotiation. By receiving the reply the VMware SD-WAN Gateway checks it and if there is an error it returns without zeroing out the SA content and the SA counter keeps mounting because of the on-going renegotiation.

    • Fixed Issue 54800: During an IKE rekey with the VMware SD-WAN Gateway, a Non SD-WAN Destination via Gateway may have a tunnel drop which does not recover.

      When a VMware SD-WAN Gateway triggers an IKE rekey with a Non SD-WAN Destination (NSD) and during this rekey the IKE link goes down or the tunnel establishment fails for any reason, the Gateway will not be able to retrigger a new IPsec tunnel because the triggering logic assumes that a Security Policy ID should be available. As a result the tunnel will not re-establish even when data traffic is sent. Without the fix, the only way to recover the tunnel is to bounce it by changing the NSD configuration on the VMware SD-WAN Orchestrator.

    • Fixed Issue 54947: For a Non SD-WAN Destinations (NSD) via Edge, a user is unable to ping from the NSD IP to the VMware SD-WAN Edge self_ip for monitoring purposes.

      For Direct NSD via Edge, the support for pinging to or from any Edge interface via the NSD IP was not previously supported. Support for this method of monitoring is part of this ticket. With this fix, a customer should be able to ping from the Edge to the NSD IP or vice-versa.

    • Fixed Issue 55181: For a customer enterprise that uses a Hub/Spoke network topology where the VMware SD-WAN Spoke Edge backhauls traffic to the Hub Edge, should the Spoke Edge’s tunnel to the Hub Edge go down, the traffic continues to be marked as ‘backhaul’ and is routed to the Hub versus being routed direct branch-to-branch. 

      Immediately after a Spoke to Hub failover or after recovering from a WAN connectivity loss on all overlay links, routes may not be learned, and flows may be considered as internet flows and match a backhaul business policy. However, once the correct routes are learned, sometimes the business policies are not re-evaluated for these flows and do not recover from this state. 

    • Fixed Issue 55196: For a Non SD-WAN Destination (NSD) via Gateway, in some scenarios when a peer is constantly rekeying, inbound IPsec Security Association (SA) accumulation can be detected.

      Customer impact is minimal as the SA's will persist until their expiration time and then be deleted and there is no security risk arising with this. When an IKE rekey happens, an outbound IPsec SA is detached from the IKE descriptor and new one is attached. This forces the outbound SA to be deleted. When the peer sends a "delete notify", the VMware SD-WAN Gateway cannot find the outbound SA to delete. This causes the inbound SA to stay around until its expiration time. If the peer keeps rekeying often then the Gateway may keep creating and retaining new Inbound SA till each expiration time.

    • Fixed Issue 55788: Tunnels to a Cloud Security Service or a Non SD-WAN Destination may go down and come back up in quick succession (i.e., "flap") and then go down completely and do not recover with a large quantity of outbound stale Security Association (SA) entries found on the VMware SD-WAN Gateway.

      When a burst of control packets needs to be sent out of a Gateway, the packets will be put into a cryptographic queue and a reference counter will be incremented one per packet. If there is no space on the cryptographic queue, the packets will be dropped but the reference counter linked with these packets will not be reduced, so even though the packets are dropped because the reference count is non-zero, the associated SA will not be deleted, leading to a stale SA in the system. Over a period of time with enough of these type of events, the Gateway will fill up to capacity with SA's and the Gateway will not initiate outbound Phase 2 IKE connections, leading to tunnels not rebuilding but staying down.  Without the fix on the Gateway, the only way to temporarily resolve this issue is to restart the Gateway to clear all the SA's out.

    • Fixed Issue 55853: In a customer enterprise that uses a Non SD-WAN Destinations (NSD) via Edge, a VMware SD-WAN Edge may experience a Dataplane Service Failure with a resulting service restart.

      When an Edge has traffic to a NSD via Edge and that traffic switches from the NSD via Edge path to some other path (e.g. the NSD path goes down temporarily) and then switches back to the NSD via Edge path, some flows may end in a corrupt state. Eventually when these flows are timed out, this triggers a Dataplane Service failure on the affected Edge.

    • Fixed Issue 55929: When customer disables and then enables the tunnels on a policy based Non SD-WAN Destination via Gateway using the VMware SD-WAN Orchestrator UI, and IKE negotiation is blocked on the 4500 port, it is possible to see inbound Security Association (SA) accumulation on the VMware SD-WAN Gateway.

      This issue requires the administrator to  disable and enable a policy-based Non SD-WAN Destination (e.g., Zscaler) where the IKE negotiation can create an SA, but there is no inbound traffic from the peer. In such a case, it is possible to see inbound SA accumulation on the VMware SD-WAN Gateway. The SAs will be deleted when there is inbound traffic. However, if there is no inbound traffic and the administrator keeps enabling/disabling the policy-based NSD, each time this is done there will remain an inbound SA on the Gateway. These SAs will stay until their expiration time. The customer impact is negligible.

    • Fixed Issue 55949: In some scenarios a Non SD-WAN Destination (NSD) via Gateway tunnel goes down and does not recover for a period of time.

      In a situation when a VMware SD-WAN Gateway triggers an IKE rekey with any other NSD destination and the rekey attempt does not succeed due to a networking issue in the middle of the negotiation, the IKE rekey will keep retrying. When a link establishes back, it is possible that Dead Peer Detection (DPD) event will delete a newly created Phase1 Security Association (SA). This causes the IPsec SA to be deleted as well with some peers, most notably with Zscaler. When a peer deletes IPsec SA, the Gateway will not be able to detect it and a tunnel will be down until the next rekey time.  Without the fix, the only way to force this rekey is to bounce the tunnel by disabling and reenabling the affected NSD through the VMware SD-WAN Orchestrator.

    • Fixed Issue 56276: If an Application Map is modified, saved, and then a Application Map Push is executed, this may cause a BGP Neighbor to drop on a customer enterprise.

      When an Application Map is modified and then pushed, all flows for the affected enterprises are flushed. This leads to the creation of new flows for BGP. When a new flow is created, it has the TCP state reinitialized to LISTEN.  With this state no BGP packets can be received and sent, only TCP syn packets can be received and sent.  All the keepalive packets from BGP are dropped leading to a BGP flap.

    • Fixed Issue 56436: Non SD-WAN Destination (NSD) via Gateway tunnels are observed to go down and up (i.e., "flap") every 30 seconds.

      Because of an unexpected failure to recognize the change in a NSD configuration within the heartbeat, the NSD configuration is sent to the VMware SD-WAN Gateway on every heartbeat (the heartbeat interval is every 30 seconds). When the configuration is received on the Gateway, the connection is restarted and this results in the flapping of the NSD tunnels every 30 seconds.

    Orchestrator Resolved Issues

    Orchestrator version R402-20220113-GA

    Orchestrator version R402-20220113-GA was released on 01-27-2022. This Orchestrator build remediates Apache Log4j vulnerabilities CVE-2021-44228 (which was first addressed in Orchestrator build R402-20211216-GA with Log4j version 2.16.0) and CVE-2021-45046, by updating to Log4j version 2.17.0. For updated information on the Apache Log4j vulnerabilities and their impact on VMware products, please consult the VMware Security Advisory VMSA-2021-0028.9.


      Orchestrator version R402-20211216-GA

      Orchestrator version R402-20211216-GA was released on 12-20-2021. This Orchestrator build remediates CVE-2021-44228, the Apache Log4j vulnerability, by updating to Log4j version 2.16.0. For more information on the Apache Log4j vulnerability, please consult the VMware Security Advisory VMSA-2021-0028.5.


        Resolved in Version R402-20210219-GA

        The below issues have been resolved since Orchestrator version R401-20201215-GA.

        • Fixed Issue 48706: Users may not be able to save changes on the Configure > Edge > Device tab with the source interface selected under the Syslog configuration.

          The error the user would see on the VMware SD-WAN Orchestrator is "Provided source interface is not present in the segment on segment: <Segment Name>." The is caused by the user creating and deleting a number of segments in such a way the segment sequence is no longer sequential.

        • Fixed Issue 50590: The VMware SD-WAN Orchestrator sends out Cloud Security Service (CSS) tunnel alerts with a UTC timestamp versus the VMware SD-WAN Edge’s local time zone. 

          The issue occurs when CSS tunnel alerts are triggered and sent via email, webhook, etc. This issue should not have any functional impact but is annoying for customers not interested in converting UTC to several different time zones depending on the Edge’s location.

        • Fixed Issue 50719: When a pair of VMware SD-WAN Edges configured in a High Availability topology are upgraded to Release 3.4.1 or 3.4.2 or 3.4.3, the Standby Edge will no longer be detected.

          When the Edges are upgraded, the HA interface (i.e. LAN1 or GE1) is programmed as a trunk port when it should be configured as an access port and this results in the HA interface failing to come up.  The fix adds a validation to ensure the HA interface is configured as an access port.  Without the fix, the only workaround is to reconfigure the HA port to “Access” using the VMware SD-WAN Orchestrator. 

        • Fixed Issue 53333: Non SD-WAN Destination (NSD) via Gateway Azure Virtual WAN network service IPsec/IKE Lifetime parameters mismatch with Azure default values.

          The issue occurs when the user creates an NSD via Gateway Azure Virtual WAN network service using the VMware SD-WAN Orchestrator UI. This issue is not present when the NSD is created or updated via the Orchestrator API.

        • Fixed Issue 54586: For a VMware SD-WAN Edge which has static routes configured, when a new business policy is created on the VMware SD-WAN Orchestrator, several of the static routes may be removed. 

          The issue is caused by an Edge function that uses segmentId as an index which causes an issue when one of the segmentId's is missing. 

        • Fixed Issue 52033: For Partners who have deployed VMware SD-WAN Partner Gateways, they may observe: a) The Gateways page on the VMware SD-WAN Orchestrator show an error, and b) A request to `enterpriseProxy/getEnterpriseProxyGateways` public API return an error.

          The issue prevents the retrieval of data related to Partner Gateways. Gateways page on UI won't be loaded. `getEnterpriseProxyGateways` public API will not retrieve any data. Any workflow related to Partner Gateways may be affected.

        • Fixed Issue 52241: When a Non SD-WAN Destination (NSD) via Edge tunnel is disabled through the VMware SD-WAN Orchestrator by using Configure > Edge > Device Settings, the Edge Monitoring page will continue to show the NSD via Edge tunnel status as up.

          The issue occurs after unchecking the "Enable" checkbox of an NSD via Edge service or tunnel.  While the tunnel is in fact torn down, the Edge Monitoring page, in the column "Edge Tunnels" for the Edge in question, will show the tunnel as up and connected.

        • Fixed Issue 52306: When using the New UI on a VMware SD-WAN Orchestrator, on the Network Overview > Links page if a VMware SD-WAN Edge is using more than one WAN link, only the first WAN link will show the correct link state.

          The other WAN links will show a gray dot for link status versus showing an actual status like Green for up, or Red for down.

        • Fixed Issue 52721: When a customer enterprise has deployed either a Non SD-WAN Destination (NSD) via Edge or a Cloud Security Service (CSS), the user is unable to change network service provider on the Edge > Device Settings, when another Edge in the customer enterprise has a business policy using the same network service provider.

          This is an Orchestrator validation issue caused by code which does not account for the Edge ID when validating a configuration change for either an NSD via Edge or a CSS.

        • Fixed Issue 53104: When an operator tries to migrate an enterprise from one VMware Orchestrator to another Orchestrator using the migration tool, and the enterprise includes with some kind of blob data configured, the migration will fail on the import stage.

          Since the blob data should not be available on the destination Orchestrator, the migration tool should drop the blob data and not import it to the destination Orchestrator.

        • Fixed Issue 53524: If the SIM card is removed from a VMware SD-WAN Edge 510-LTE, when viewing the Monitor > Edge page on the VMware SD-WAN Orchestrator's New UI, the corresponding link is shown as standby and not as down/offline.

          Issue is connected to link state when link stops sending data and the API does not have any data to send to the front-end so the link is shown as standby.  The older UI uses a different method for monitoring link status and is not affected by this issue.

        • Fixed Issue 55244: When migrating a VMware SD-WAN Orchestrator deployed in a Disaster Recovery (DR) topology from a 3.4.x release to a 4.x.x release, there is the potential the migration may slow down significantly and potentially not complete.

          During the migration on a DR Orchestrator, the Orchestrator's MySQL could get an unexpected increase in the number of connections that deal with queries to retrieve a large number of flows, playing a large burden on MySQL. When MySQL gets overloaded, it has an effect on rest of the systems by way of slow API responses, affecting the overall user experience. The migration job does not account for such slowness and has an aggressive timeout for the task. Due to the aggressive timeout, the job logs a failure but the query continues to run in MySQL. Thus as the next job gets triggered, more and more MySQL queries start accumulating eventually affecting system performance.

        • Fixed Issue 56485: When a VMware SD-WAN Orchestrator is upgraded to any 4.x versions and using the New UI, when consulting the Edge Monitoring page, the path stats tab is not visible to a user logged in as a Partner Administrator with a superuser role.

          An Orchestrator with this fix corrects the path stats visibility issue for Partner superusers.

        • Fixed Issue 57001: On a VMware SD-WAN Orchestrator using Release 4.x.x or higher and also using the New UI, on the Monitor >Edges page, the Average Throughput shows the same data as Bytes Received/Sent.

          This is only when using the new Angular UI.  There a user would navigate to Monitor > Edges > [choose an edge], and then choose the Paths tab, and then select "Average Throughput" from the dropdown.

        • Fixed Issue 57063: If the start and end time for an API call overlaps exactly with the time at which a VMware SD-WAN Edge exports data to the VMware SD-WAN Orchestrator, two behaviors will be observed: a) Link metrics API calls issued from the Orchestrator UI or SDK clients will observe a value higher than normal being returned back in the response. b) Link series API calls issued from the Orchestrator UI or SDK clients will observe the last time series value to be higher than usual.

          A User could observe this discrepancy when consulting the Monitor > Transport tab on the Orchestrator UI, or when an SDK client invokes getEdgeLinkMetrics, getEdgeLinkSeries, getAggregateLinkMetrics API calls.  In either case, the actual times this would be observed are rare given the requirements noted in the Symptom description.

        Known Issues

        Open Issues in Release 4.0.2

        The known issues are grouped as follows.

        Edge/Gateway Known Issues
        • Issue 14655:

          Plugging or unplugging an SFP adapter may cause the device to stop responding on the Edge 540, Edge 840, and Edge 1000 and require a physical reboot.

          Workaround: The Edge must be physically rebooted.  This may be done either on the Orchestrator using Remote Actions > Reboot Edge, or by power-cycling the Edge.

        • Issue 25504:

          Static route costs greater than 255 may result in unpredictable route ordering.  

          Workaround: Use a route cost between 0 and 255

        • Issue 25595:

          A restart may be required for changes to static SLA on a WAN overlay to work properly.  

          Workaround: Restart Edge after adding and removing Static SLA from WAN overlay

        • Issue 25742:

          Underlay accounted traffic is capped at a maximum of the capacity towards the VMware SD-WAN Gateway, even if that is less than the capacity of a private WAN link which is not connected to the Gateway.  

        • Issue 25758:

          USB WAN links may not update properly when switched from one USB port to another until the VMware SD-WAN Edge is rebooted.  

          Workaround: Reboot the Edge after moving USB WAN links from one port to another.

        • Issue 25855:

          A large configuration update on the Partner Gateway (e.g. 200 BGP-enabled VRFs) may cause latency to increase for approximately 2-3 seconds for some traffic via the VMware SD-WAN Gateway.

          Workaround: No workaround available.

        • Issue 25921:

          VMware SD-WAN Hub High Availability failover takes longer than expected (up to 15 seconds) when there are three thousand branch Edges connected to the Hub.  

        • Issue 25997:

          The VMware SD-WAN Edge may require a reboot to properly pass traffic on a routed interface that has been converted to a switched port.  

          Workaround: Reboot the Edge after making the configuration change.

        • Issue 26421:

          The primary Partner Gateway for any branch site must also be assigned to a VMware SD-WAN Hub cluster for tunnels to the cluster to be established.  

        • Issue 28175:

          Business Policy NAT fails when the NAT IP overlaps with the VMware SD-WAN Gateway interface IP.  

        • Issue 31210:

          VRRP: ARP is not resolved in the LAN client for the VRRP virtual IP address when the VMware SD-WAN Edge is master with a non-global CDE segment running on the LAN interface. 

        • Issue 32731:

          Conditional default routes advertised via OSPF may not be withdrawn properly when the route is turned off. Re-enabling and disabling the route will retract it successfully. 

        • Issue 32960:

          Interface “Autonegotiation” and “Speed” status might be displayed incorrectly on the Local Web UI for activated VMware SD-WAN Edges.

        • Issue 32981:

          Hard-coding speed and duplex on a DPDK-enabled port may require a VMware SD-WAN Edge reboot for the configurations to take effect as it requires disabling DPDK.

        • Issue 34254:

          When a Zscaler CSS is created and the Global Segment has FQDN/PSK settings configured, these settings are copied to Non-Global Segments to form IPsec tunnels to a Zscaler CSS.

        • Issue 35778:

          When there are multiple user-defined WAN links on a single interface, only one of those WAN links can have a GRE tunnel to Zscaler. 

          Workaround: Use a different interface for each WAN link that needs to build GRE tunnels to Zscaler.

        • Issue 35807:

          A DPDK routed interface will be disabled completely if the interface is disabled and re-enabled from the VMware SD-WAN Orchestrator. 

        • Issue 36923:

          Cluster name may not be updated properly in the NetFlow interface description for a VMware SD-WAN Edge which is connected to that Cluster as its Hub.

        • Issue 38682:

          A VMware SD-WAN Edge acting as a DHCP server on a DPDK-enabled interface may not properly generate “New Client Device" events for all connected clients.

        • Issue 38767:

          When a WAN overlay that has GRE tunnels to Zscaler configured is changed from auto-detect to user-defined, stale tunnels may remain until the next restart.

          Workaround: Restart the Edge to clear the stale tunnel.

        • Issue 39134:

          The System health statistic “CPU Percentage” may not be reported correctly on Monitor > Edge > System for the VMware SD-WAN Edge, and on Monitor > Gateways for the VMware SD-WAN Gateway.

          Workaround: Users should use handoff queue drops for monitoring Edge capacity not CPU percentage.

        • Issue 39374:

          Changing the order of VMware SD-WAN Partner Gateways assigned to a VMware SD-WAN Edge may not properly set Gateway 1 as the local Gateway to be used for bandwidth testing.

        • Issue 39608:

          The output of the Remote Diagnostic “Ping Test” may display invalid content briefly before showing the correct results.

        • Issue 39624:

          Ping through a subinterface may fail when the parent interface is configured with PPPoE.

        • Issue 39659:

          On a site configured for Enhanced High Availability, with one WAN link on each VMware SD-WAN Edge, when the standby Edge has only PPPoE connected and the active has only non-PPPoE connected, a split brain state (active/active) may be possible if the HA cable fails.

        • Issue 39753:

          Disabling Dynamic Branch-to-Branch VPN may cause existing flows currently being sent using Dynamic Branch-to-Branch to stall.

        • Issue 40096:

          If an activated VMware SD-WAN Edge 840 is rebooted, there is a chance an SFP module plugged into the Edge will stop passing traffic even though the link lights and the VMware SD-WAN Orchestrator will show the port as 'UP'. 

          Workaround: Unplug the SFP module and then replug it back into the port.

        • Issue 40421:

          Traceroute is not showing the path when passing through a VMware SD-WAN Edge with an interface configured as a switched port.

        • Issue 42278:

          For a specific type of peer misconfiguration, the VMware SD-WAN Gateway may continuously send IKE init messages to a Non-SD-WAN peer. This issue does not disrupt user traffic to the Gateway; however, the Gateway logs will be filled with IKE errors and this may obscure useful log entries.

        • Issue 42388:

          On a VMware SD-WAN Edge 540, an SFP port is not detected after disabling and reenabling the interface from the VMware SD-WAN Orchestrator.

        • Issue 42488:

          On a VMware SD-WAN Edge where VRRP is enabled for either a switched or routed port, if the cable is disconnected from the port and the Edge Service is restarted, the LAN connected routes are advertised.

          Workaround: There is no workaround for this issue.

        • Issue 42872:

          Enabling Profile Isolation on a Hub profile where a Hub cluster is associated does not revoke the Hub routes from the routing information base (RIB).

        • Issue 43373:

          When the same BGP route is learnt from multiple VMware SD-WAN Edges, if this route is moved from preferred to eligible exit in the Overlay Flow Control, the Edge is not removed from the advertising list and continues to be advertised.

          Workaround: Enable distributed cost calculation on the VMware SD-WAN Orchestrator.

        • Issue 44526: For an enterprise where two different sites deploy their VMware SD-WAN Edges as Hubs while also using a high-availability topology, and each site uses the other Hub site as a Hub in its profile.  If one of the Hub sites triggers an HA failover, it may take up to 30 minutes for both Hub Edges to reestablish tunnels with each other. 

          On an HA failover, both Hub Edges try to initiate a tunnel with each other at the same time and neither replies to the peer, the packet exchange between both Hubs occurs, but IKE never succeeds. This leads to a deadlock that has been observed to take up to 30 minutes to resolve on its own. The issue is intermittent and does not occur after every HA failover. 

          Workaround: To prevent this issue from occurring, the customer should configure only one of the two HA Hub sites to use the other Hub site as a Hub for itself.  For example, where there are two HA Hub sites, Hub1 and Hub2, Hub1 could have Hub2 as a Hub for itself in its profile, but Hub2 must not use Hub1 as a Hub in its profile.

        • Issue 44832:

          Traffic from one Non SD-WAN Destinations via Edge to another Non SD-WAN Destinations via Edge (i.e. 'hairpinning' or 'NAT loopback'), is dropped on the VMware SD-WAN Edge.

        • Issue 44995:

          OSPF routes are not revoked from VMware SD-WAN Gateways and VMware SD-WAN Spoke Edges when the routes are withdrawn from the Hub Cluster.

        • Issue 45189:

          With source LAN side NAT is configured, the traffic from a VMware SD-WAN Spoke Edge to a Hub Edge is allowed even without the static route configuration for the NAT subnet.

        • Issue 45302:

          In a VMware SD-WAN Hub Cluster, if one Hub loses connectivity for more than 5 minutes to all of the VMware SD-WAN Gateways common between itself and its assigned Spoke Edges, the Spokes may in rare conditions be unable to retain the hub routes after 5 minutes. The issue resolves itself when the Hub regains contact with the Gateways.

        • Issue 46053:

          BGP preference does not get auto-corrected for overlay routes when its neighbor is changed to an uplink neighbor.

          Workaround: An Edge Service Restart will correct this issue.

        • Issue 46137:

          A VMware SD-WAN Edge running 3.4.x software does not initiate a tunnel with AES-GCM encryption even if the Edge is configured for GCM.

        • Issue 46216:

          On a Non SD-WAN Destinations via Gateway or Edge where the peer is an AWS instance, when the peer initiates Phase-2 re-key, the Phase-1 IKE is also deleted and forces a re-key.  This means the tunnel is torn down and rebuilt, causing packet loss during the tunnel rebuild.

          Workaround: To avoid tunnel destruction, configure the Non SD-WAN Destinations via Gateway/Edge or CSS IPsec rekey timer to less than 60 minutes.  This prevents AWS from initiating the re-key.

        • Issue 46391:

          For a VMware SD-WAN Edge 3800, the SFP1 and SFP2 interfaces each have issues with Multi-Rate SFPs (i.e. 1/10G) and should not be used in those ports.

          Workaround: Please use single rate SFP's per the KB article VMware SD-WAN Supported SFP Module List (79270).  Multi-Rate SFPs may be used with SFP3 and SFP4.

        • Issue 46628:

          The GE5 and GE6 ports on a VMware SD-WAN Edge 620/640/680 do not detect a link if the ports are configured with 100 Mbps and duplex.

        • Issue 46918:

          A VMware SD-WAN Spoke Edge using the 3.4.2 Release does not update the private network id of a Cluster Hub node properly.

        • Issue 47084:

          A VMware SD-WAN Hub Edge cannot establish more than 750 PIM (Protocol-Independent Multicast) neighbors when it has 4000 Spoke Edges attached.

        • Issue 47244:

          On an activated VMware SD-WAN Edge 6x0 with DPDK enabled, some Copper SFPs, the Edge will show the link as 'UP' even when no cable is inserted on the VMware SD-WAN Orchestrator UI.

          Workaround: Plugging and unplugging a cable removes the false state.

        • Issue 47355:

          When the same route is learned via local underlay BGP, Hub BGP and/or statically configured on the Partner Gateway, the sorting order of the routes is incorrect with the Hub BGP being preferred over the underlay BGP.

        • Issue 47664:

          In a Hub and Spoke configuration where Branch-to-Branch via Hub VPN is disabled, trying to U-turn Branch-to-Branch traffic using a summary route on an L3 switch/router will cause routing loops.

          Workaround: Configure Cloud VPN to enable Branch-to-Branch VPN and select “Use Hubs for VPN”.

        • Issue 47681:

          When a host on the LAN side of a VMware SD-WAN Edge uses the same IP as that Edge’s WAN interface, the connection from the LAN host to the WAN does not work.

        • Issue 47787:

          A VMware SD-WAN Spoke Edge configured with a backhaul business policy incorrectly sends traffic via the VMware SD-WAN Gateway path if that flow is initiated from the Hub Edge to that Spoke Edge.

        • Issue 48166:

          A VMware SD-WAN Virtual Edge on KVM is not supported when using a Ciena virtualization OS and the Edge will experience recurring Dataplane Service Failures.

        • Issue 48175:

          A VMware SD-WAN Edge running Release 3.4.2 will form an OSPF adjacency on a non-global segment if the non-global segment has an interface configured in the same IP range as an interface configured on the global segment

        • Issue 48488:

          Business policy rule is not overridden if the outbound traffic box is not checked (for the Traffic initiated from remote peer and allowed by 1:1 NAT rule).

          Workaround: Please check “Outbound Traffic” in 1:1 NAT.

        • Issue 48502:

          In some scenarios, a VMware SD-WAN Hub Edge being used to backhaul internet traffic may experience a Dataplane Service Failure due the improper handling of backhaul return packets.

        • Issue 48530:

          VMware SD-WAN Edge 6x0 models do not perform autonegotiation for triple speed (10/100/1000 Mbps) copper SFP's.

          Workaround: Edge 520/540 supports triple speed copper SFPs but this model has been marked for End-of-Sale by Q1 2021.

        • Issue 48666:

          IPsec-fronted Gateway Path MTU calculation does not account for 61 Byte IPsec overhead, resulting in higher MTU advertisement to LAN client and subsequent IPsec packet fragmentation.

          Workaround: There is no workaround for this issue.

        • Fixed Issue 49055: VMware SD-WAN Edge may drop in-flight packets during the handoff between different threads in the data path and at DPDK send.

          If one of the Edge's WAN links is oversubscribed, the Edge starts to drop packets at DPDK and during handoff to different threads in the pipeline. The fix helps in mitigating the problem with increased queue size for packet buffering and tunable reorder buffer size.

        • Issue 49172:

          A Policy Based NAT rule configured with the same NAT subnet for two different VMware SD-WAN Edges does not work.

        • Issue 49738:

          In some cases, when a VMware SD-WAN Spoke Edge is configured to use multiple Hub Edges, the Spoke Edge may not form tunnels to one of the Hubs configured in the Hub list.

        • Issue 50518:

          On a VMware SD-WAN Gateway where PKI is enabled, if >6000 PKI tunnels attempt to connect to the Gateway, the tunnels may not all come up because inbound SAs do not get deleted.

          Note: Tunnels using pre-shared key (PSK) authentication do not have this issue.

        • Issue 53219: After a VMware SD-WAN Hub Cluster rebalances, a few Spoke Edges may not have their RPF interface/IIF set properly.

          On the affected Spoke Edges, multicast traffic will be impacted. What happens is that after a cluster rebalance, some of the Spoke Edges fail to send a PIM join.

          Workaround: This issue will persist until the affected Spoke Edge has an Edge Service restart.

        • Issue 84825: For a site deployed with a High-Availability topology where BGP is configured, if the site has greater than 512 BGPv4 match and set rules configured, the customer may observe the HA Edge pair continuously failing over without ever recovering.

          Greater than 512 BGPv4 match and set rules is understood as a customer configuring more than 256 such rules on the inbound filter and 256 rules on the outbound filter. This issue would be disruptive to the customer as the repeated failover would cause flows for real time traffic like voice calls to be continuously dropped and then recreated. When HA Edges experience this issue, the process that synchronizes Edge CPU threads fails causing the Edge to reboot to recover, but the promoted Edge also experiences the same issue and reboots in turn with no recovery reached at the site.

          Workaround: Without a fix for this issue, the customer must ensure that no more than 512 BGPv4 match and set rules are configured for an HA site.

          If a site is experiencing this issue and has more than 512 BGP/v4 match and set rules configured, the customer must immediately reduce the number of rules to 512 or less to recover the site.

          Alternatively, if the customer must have more than 512 BGPv4 match and set rules, they can downgrade the HA Edges to Release 3.4.6 where this issue is not encountered, but at the cost of Edge features found in later releases. This can only be done if their Edge model is supported on 3.4.6 and the customer should confirm that is so before downgrading.

        Orchestrator Known Issues
        • Issue 19566:

          After High Availability failover, the serial number of the standby VMware SD-WAN Edge may be shown as the active serial number in the Orchestrator.

        • Issue 20900:

          If the MaxMind geolocation service is enabled and cannot reach the MaxMind server, new VMware SD-WAN Edge activations will not work.

        • Issue 21342:

          When assigning Partner Gateways per-segment, the proper list of Gateway Assignments may not show under the Operator option "View" Gateways on the VMware SD-WAN Edge monitoring list.

        • Issue 24269:

          Monitor > Transport > Loss not graphing observed WAN link loss while QoE graphs do reflect this loss. 

        • Issue 25932:

          The VMware SD-WAN Orchestrator allows VMware SD-WAN Gateways to be removed from the Gateway Pool even when they are in use.

        • Issue 32335:

          The ‘End User Service Agreement’ (EUSA) page throws an error when a user is trying to accept the agreement.

          Workaround: Ensure no leading or trailing spaces are found in Enterprise Name.

        • Issue 32435:

          A VMware SD-WAN Edge override for a policy-based NAT configuration is permitted for tuples which are already configured at the profile level and vice versa.

        • Issue 32856:

          Though a business policy is configured to use the Hub cluster to backhaul internet traffic, the user can unselect the Hub cluster from a profile on a VMware SD-WAN Orchestrator that has been upgraded from Release 3.2.1 to Release 3.3.x.

        • Issue 32913:

          After Enabling High Availability, Multicast details for the VMware SD-WAN Edge are not displayed on the Monitoring Page. A failover resolves the issue.

        • Issue 33026:

          The ‘End User Service Agreement’ (EUSA) page does not reload properly after deleting the agreement.

        • Issue 34828:

          Traffic cannot pass between a VMware SD-WAN Spoke Edge using release 2.x and a Hub Edge using release 3.3.1.

        • Issue 35658:

          When a VMware SD-WAN Edge is moved from one profile to another which has a different CSS setting (e.g. IPsec in profile1 to GRE in profile2), the Edge level CSS settings will continue to use the previous CSS settings (e.g. IPsec versus GRE). 

          Workaround: Disable and then reenable GRE at the Edge level to resolve the issue.

        • Issue 35667:

          When a VMware SD-WAN Edge is moved from one profile to another profile which has the same CSS setting but a different GRE CSS name (the same endpoints), some GRE tunnels will not show in monitoring.

          Workaround: Disable and then reenable GRE at the Edge level to resolve the issue.

        • Issue 36665:

          If the VMware SD-WAN Orchestrator cannot reach the internet, user interface pages that require accessing the Google Maps API may fail to load entirely.

        • Issue 38056:

          The Edge-Licensing export.csv file not show region data.

        • Issue 38843:

          When pushing an application map, there is no Operator event, and the Edge event is of limited utility.

        • Issue 39633:

          The Super Gateway hyper link does not work after a user assigns the Alternate Gateway as the Super Gateway.

        • Issue 39790:

          The VMware SD-WAN Orchestrator allows a user to configure a VMware SD-WAN Edge’s routed interface to have greater than the supported 32 subinterfaces, creating the risk that a user can configure 33 or more subinterfaces on an interface which would cause a Dataplane Service Failure for the Edge.

        • Issue 40341:

          Though the Skype application is properly categorized on the backend as Real Time traffic, when editing the Skype Business Policy on the VMware SD-WAN Orchestrator, the Service Class may erroneously display “Transactional”.

        • Issue 41691:

          User cannot change the 'Number of addresses' field although the DHCP pool is not exhausted on the Configure > Edge > Device page.

        • Issue 43276:

          User cannot change the Segment type when a VMware SD-WAN Edge or Profile has a partner gateway configured.

        • Issue 44153:

          The VMware SD-WAN Orchestrator does not consistently send alert emails to the email addresses configured in the 'Alerts and Notifications' section.

        • Issue 46254:

          During a VMware SD-WAN Edge activation, the VMware SD-WAN Orchestrator does not detect a changed WAN link MTU or the presence of a VLAN ID for DHCP configured interfaces.

        • Issue 47269:

          The VMware SD-WAN 510-LTE interface may appear for Edge models that do not support an LTE interface.

        • Issue 47713:

          If a Business Policy Rule is configured while Cloud VPN is disabled, the NAT configuration must be reconfigured upon enabling Cloud VPN.

        • Issue 47820:

          If a VLAN is configured with DHCP disabled at the Profile level, while also having an Edge Override for this VLAN on that Edge with DHCP enabled, and there is an entry for the DNS server field set to none (no IP configured), the user will be unable to make any changed on the Configure > Edge > Device page and will get an error message of ‘invalid IP address []’ that does not explain or point to the actual problem.

        • Issue 48085:

          The VMware SD-WAN Orchestrator allows a user to delete a VLAN which is associated with an interface.

        • Issue 48737:

          On a VMware SD-WAN Orchestrator which is using the Release 4.0.0 new user interface, If a user is on a Monitor page and changes the Start & End time interval and then navigates between tabs, the Orchestrator does not update Start & End interval time to the new values.

        • Issue 49225:

          VMware SD-WAN Orchestrator does not enforce a limit of 32 total VLANs.

        • Issue 49790:

          When a VMware SD-WAN Edge is activated to Release 4.0.0, the activation is posted twice in Events.

          Workaround: Ignore the duplicate event.

        • Issue 50531:

          When two Operators of differing privileges use the same browser window when accessing the New UI on a 4.0.0 Release version of the VMware SD-WAN Orchestrator, and the Operator with lesser privileges tries to login after the Operator with higher privileges, that lesser privileged Operator will observe multiple errors stating that the "user does not have privilege".

          Note: There is no escalation in privileges for the Operator with lower privileges, only the display of error messages.

          Workaround: The next operator may refresh that page prior to logging in to prevent seeing the errors, or each Operator may use different browser windows to avoid this display issue.

        • Issue 51722: On the Release 4.0.0 VMware SD-WAN Orchestrator, the time range selector is no greater than two weeks for any statistic in the Monitor > Edge tabs.

          The time range selector does not show options greater than "Past 2 Weeks" in Monitor > Edge tabs even if the retention period for a set of statistics is much longer than 2 weeks.  For example, flow and link statistics are retained for 365 days by default (which is configurable), while path statistics are retained only for 2 weeks by default (also configurable).  This issue is making all monitor tabs conform to the lowest retained type of statistic versus allowing a user to select a time period that is consistent with the retention period for that statistic.

          Workaround: A user may use the "Custom" option in the time range selector to see data for more than 2 weeks.

        • Issue 53652: The VMware SD-WAN Orchestrator Web UI's Application viewer displays a random name for a custom application created prior to the Orchestrator upgrading to Release 4.0.1.

          Whenever a custom application is configured with an appId which already exists as part of the default initial application map, the custom application always shows the display name of the default initial application map and overrides the customer defined name. Even when the Orchestrator is upgraded from a lower version to a higher version and the higher version's default initial application map has appIds that conflicts with the appIds of a custom application created in a lower version, then after upgrade for those custom applications, the display name is shown incorrectly (showing the display name of the higher Orchestrator version's default initial application map against the display name of the lower version custom application).

          Workaround: Download the application map, hand-fix the appIds of the custom application (i.e., change the appIds of the custom application starting from 7000, 7001, and so on). Upload the newly modified Application Map. Duplicate the current operator profile and just change the application map to newly modified application map and then assign this duplicate operator profile to the Edges in the customer enterprise.

        check-circle-line exclamation-circle-line close-line
        Scroll to top icon