Updated March 31st, 2023

VMware SD-WAN Orchestrator Version R400-20211217-GA
VMware SD-WAN Gateway Version R400-20201124-GA-53090
VMware SD-WAN Edge Version R400-20201002-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 made available in this release. 

Compatibility

Release 4.0.0 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, please consult the warning below for additional details).

The following interoperability combinations were explicitly tested:

Orchestrator

Gateway

Edge

Hub

Branch/Spoke

4.0.0 

3.4.2 

3.4.2 

3.4.2 

4.0.0 

4.0.0 

3.4.2 

3.4.2 

4.0.0 

4.0.0 

4.0.0 

3.4.2 

4.0.0 

3.3.2 P2 

3.3.2 P2 

3.3.2 P2 

4.0.0 

4.0.0 

3.3.2 P2 

3.3.2 P2 

4.0.0 

4.0.0 

4.0.0 

3.3.2 P2 

4.0.0 

3.3.2 P1 

3.3.1 

3.3.1

4.0.0 

4.0.0 

3.3.1 

3.3.1

4.0.0 

4.0.0 

4.0.0 

3.3.1

4.0.0 

3.3.0 

3.3.0 

3.3.0 

4.0.0 

4.0.0 

3.3.0 

3.3.0 

4.0.0 

4.0.0 

4.0.0 

3.3.0 

4.0.0 

3.2.2 

3.2.2 

3.2.2 

4.0.0 

4.0.0 

3.2.2 

3.2.2 

4.0.0 

4.0.0 

4.0.0 

3.2.2 

4.0.0 

3.2.1 

3.2.1 

3.2.1 

4.0.0 

4.0.0 

3.2.1 

3.2.1 

4.0.0 

4.0.0 

4.0.0 

3.2.1 

4.0.0 

3.4.3 

3.4.3 

3.4.3 

4.0.0 

4.0.0 

3.4.3 

3.4.3 

4.0.0 

4.0.0 

3.4.3 

3.4.2 

4.0.0 

4.0.0 

3.4.2 

3.4.3 

4.0.0 

4.0.0 

4.0.0 

3.4.3 

4.0.0 

4.0.0 

3.4.3 

4.0.0 

Warning: VMware SD-WAN Release 2.x (e.g. 2.4.4, 2.5.2, etc.) is not compatible with Release 4.0.0 or later.

This will impact customers who deploy VMware SD-WAN Edges which use a 2.x Release. This impact begins after VMware SD-WAN upgrades its hosted Orchestrators and Gateways to 4.0.0 or higher. The exact dates will be announced on the Orchestrator two weeks prior. 

When an Orchestrator and Gateways are upgraded to Release 4.0.0, all SD-WAN control plane and data plane overlay services will be unavailable for a VMware SD-WAN Edge using 2.x software. The Gateways will be unable to accept VCMP tunnels from Edges running Release 2.x. With no control plane connection with the Gateway, Edges will not be able to form tunnels with other Edges.

In the event the above occurs, Edges will continue to forward traffic via the underlay.  Edges will also maintain a connection with the Orchestrator via the underlay using HTTPS/443.  This enables the administrator to upgrade the Edges to Release 3.x or 4.x Release even with SD-WAN overlay services unavailable.

For more information regarding Release 2.x, including next steps, please consult the following KB article:

Announcement: End of Support Life for VMware SD-WAN Release 2.x.x (77221)

Warning: VMware SD-WAN Releases 3.2.x and 3.3.x have reached the End of Support. Releases 3.2.x and 3.3.x reached End of General Support (EOGS) on December 15, 2021, and End of Technical Guidance (EOTG) March 15, 2022.

Warning: VMware SD-WAN Releases 3.4.x is approaching End of Support for the Orchestrator and Gateway. Release 3.4.x for the Orchestrator and Gateway will reach End of General Support (EOGS) on March 30, 2022, and End of Technical Guidance (EOTG) June 30, 2022.
Note: This is for the Orchestrator and Gateway only. 3.4.x for the Edge is scheduled to enter its End of Support window beginning on December 31, 2022.

For more information please consult the Knowledge Base article: Announcement: End of Support Life for VMware SD-WAN Release 3.x (84151)

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 Release 4.0.0. Once all their Edges are running 4.0.0, 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.

Alternate Super Gateway Automatically Assigned

When a VMware SD-WAN Orchestrator is upgraded to Release 4.0.0, all customer enterprises will have a Alternate Super Gateway automatically assigned to their enterprise if they do not already have one.

Custom Application Map Changes

VMware SD-WAN always recommends Operators use the latest Application Map that is made available with each new software release to ensure the most consistent and correct application identification. A new flag has been added to the Application Map with Release 4.0.0: mustNotPerformDpi, which prevents VMware SD-WAN's Deep Application Recognition from overwriting a custom application decision (e.g. when matching by IP address and port). This flag need not be set for custom applications with an Application ID >= 4000.

Deprecation of Microsoft Internet Explorer

Beginning in Release 4.0.0, VMware SD-WAN Orchestrator support for the browser Microsoft Internet Explorer is deprecated.  VMware SD-WAN fully supports the Internet Explorer replacement, Microsoft Edge.

Edge Licensing

Beginning in Release 4.0.0, Edge Licensing is enabled by default and it is mandatory for a user to assign an Edge license type when creating a new VMware SD-WAN Edge. This requirement helps VMware SD-WAN to track customer subscriptions and simplifies and standardizes the Edge activation report sent by partners. VMware does not enforce the license parameters and assigning an Edge license type does not change the behavior of the Edge in any way.

To learn more, please consult the Edge Licensing documentation.

Infrastructure Improvements

  • The VMware SD-WAN Orchestrator and Gateway virtual appliances are now based on Ubuntu 18.04 (LTS).
  • The VMware SD-WAN Orchestrator now stores statistics data in an optimized way, allowing for statistics queries (e.g. viewing statistics on the Orchestrator UI) to be performed more than 100x faster.
  • The Remote Diagnostics interface on the VMware SD-WAN Orchestrator now uses WebSockets to support synchronous communication with the VMware SD-WAN Edge, allowing Remote Diagnostics commands to be performed 10x faster.
  • The VMware SD-WAN Edge and Gateway now leverage:
    • VMware NSX FIPS 140-2 compliant IPsec libraries.
    • VMware NSX routing daemons.

Non-VeloCloud Sites are now Non SD-WAN Destinations

Beginning in Release 4.0.0, Non-VeloCloud Sites (IPsec tunnels to third-party destinations) are renamed as "Non SD-WAN Destinations". Customers with existing Non-VeloCloud Sites from 3.x would see their site called a "Non SD-WAN Destinations via Gateway" as this is how a 3.x Non-VeloCloud Site connected to a third-party destination. Newly added Edge-based instances are called "Non SD-WAN Destinations via Edge".

PKI Authentication is Enabled by Default for New Customer Enterprises

On an Orchestrator which has PKI (Public key infrastructure) enabled and is using Release 4.0.0, a newly created enterprise will have PKI enabled.

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). 

New Features

New Orchestrator User Interface

The VMware SD-WAN Orchestrator User Interface (UI) is being modernized using the Clarity Design System for a clean, consistent, and responsive user experience. The full UI will be migrated over the course of multiple releases. Release 4.0.0 includes a partial set of Monitoring Sections in the new UI.
Note: The QoE tab is not yet present in the new UI and will be added in an upcoming release. QoE is still visible in the legacy UI.

To take advantage of the new capabilities provided by the modernized UI framework, the following features are available exclusively in the new Orchestrator UI:

Path Visibility: The Transport tab on the UI (renamed “Links”) provides the ability to view statistics like packets, bytes, latency, jitter and packet loss for each WAN link connected to a VMware SD-WAN Edge. Path Visibility allows users to view the same metrics for each of the individual paths between VMware SD-WAN Edges and Gateways, as well as providing a QoE (Quality of Experience) score per path and per peer.

Enterprise Reporting: The reporting service has been augmented in several ways:

  • New Reporting Capabilities – The 4.0.0 Orchestrator now reports "top sites by applications" and two new traffic types are added for the "top applications by traffic" report pages.
  • Speed and Scale – Time range limitations have been removed and the overall report generation duration has decreased.
  • Scheduling – Reports may now be generated on a recurring basis.
  • Email – VMware SD-WAN will notify a list of users via email when the report is completed.
  • New User Interface – VMware SD-WAN has improved the look and feel as well as the usability of the Orchestrator user interface by:
    • Using VMware Clarity design guidelines.
    • Adding the ability to delete reports and recurring reports.
    • Making the interface wizard-based with multiple customization options.
    • Offering either fixed or recurring time range selection.
    • Specific Edge selection.
    • Report page selection.
    • Optional CSV export.

Non SD-WAN Destinations via Edge

In addition to Non SD-WAN Destinations via Gateway (previously known as "Non-VeloCloud Sites"), which allows IPsec tunnels to be built from the VMware SD-WAN Gateway to third-party destinations, IPsec tunnels to third-party destinations are now supported directly from the VMware SD-WAN Edge.

Bidirectional Forwarding Detection (BFD)

BFD is now supported for BGP and OSPF. BFD is a protocol used to detect route failures between two connected entities faster with low-overhead detection of failures.

Zscaler API Automation

VMware SD-WAN simplifies integration with the Zscaler Cloud Security Service (CSS) by automating the VPN connectivity from VMware SD-WAN Edges to the Zscaler cloud at scale. 

With Zscaler CSS automation, a customer can create VPN tunnels from multiple Edges to the Zscaler service with one simple click. 

A customer can control VPN tunnel traffic via detailed business policy rules at a segment, profile, and Edge level. 

The automation supports useful features for easy monitoring and troubleshooting. This includes monitoring of VPN tunnel status, and tracking events, alerts, and notifications from the Edge. 

Orchestrator Customizations

  • Role Customization: VMware SD-WAN Orchestrator Operators can now customize the default roles included in the Orchestrator (e.g. Superuser, Standard Administrator) by removing capabilities that they do not wish a particular role to have permission to perform.
  • Orchestrator Localization: The VMware SD-WAN Orchestrator UI now supports localization in Italian, Czech, and Simplified Chinese.

Feature Enhancements

Firewall Enhancements

The following firewall enhancements are included in Release 4.0.0:

Network and Flood Protection
The stateful firewall in the VMware SD-WAN Edge now protects against these additional attacks:

  • Ping of Death
  • TCP Land
  • Invalid IP Options
  • DoS attacks

FQDN Firewalling on VMware SD-WAN Edge
Fully Qualified Domain Names (FQDNs) can now be used in the destination match criteria for firewall rules, as well as in Object Groups. In addition to DNS parsing to learn the FQDN of traffic, Deep Packet Inspection (DPI) is now used to learn the destination FQDN for traffic traversing the VMware SD-WAN Edge (e.g. from HTTP header or SNI).

Stateful Failover for VPN Flows
Remote Routes and protocol state are now sync’d from the Active to Standby VMware SD-WAN Edge in a high-availability pair, which allows for VPN sessions to continue uninterrupted in case of HA failover when Stateful Firewall is enabled.

Security Enhancements

The following security enhancements are included in Release 4.0.0:

  • Support for SHA384 & SHA512 for hash algorithm.
  • Support for Diffie-Hellman Groups 15 (3072-bit modulus) & 16 (4096-bit modulus).
  • Support for Perfect Forwarding Secrecy group 14, 15, 16.
  • Removed MD5 algorithms support from CSS.
  • Added DES algorithm to encryption selection for countries that do not permit AES (if allowed by VMware SD-WAN Orchestrator System Property).
  • IKE and IPsec rekey timers are now adjustable.

Intermediate Certificate Authority (CA)

The VMware SD-WAN Orchestrator Certificate Authority can be subordinate to an external certificate authority. This allows the root of trust for data-plane and management-plane authentication to be chained to a customer owned CA.

Note: This feature is applicable to on-premise Orchestrators only and not applicable to Orchestrators hosted by VMware SD-WAN.

High Availability Support for Checkpoint VNF

High Availability is now supported when deploying Checkpoint Firewalls as Virtual Network Functions (VNFs) on VNF-enabled VMware SD-WAN Edge platforms.

Backup WAN Links

Two enhancements have been made to Backup WAN Link functionality:

  • Hot Standby Mode: In this new mode, tunnels are built over the backup link but remain unused. This allows for faster failover in case of active link failure at the cost of  additional bandwidth consumption by control traffic (increased from ~7.5 MB per peer, per month to ~60 MB per peer, per month).
  • Minimum Active Links: This setting allows a user to choose when a backup link becomes active in a deployment which uses 3 or more WAN links. For instance, in a VMware SD-WAN Edge with 3 WAN links, the backup link would previously become active only when both active links failed. By setting “Minimum Active Links” to 2, the backup link will become active if either active link fails.

Support for DHCP over VLAN in a routed interface

Previously, when using a VLAN tag on the parent routed interface only static IP addressing was supported, and in order to use a VLAN tag with DHCP a subinterface had to be configured. The VMware SD-WAN Orchestrator now supports configuration of a VLAN tag on the parent interface while using DHCP.

Configurable ARP Timeout

The VMware SD-WAN Orchestrator now allows overriding the default ARP timeouts via the Device Settings configuration:

  • ARP Stale Timeout - how long before an ARP entry should attempt to be refreshed (default 2 minutes).
  • ARP Dead Timeout - how long before an ARP entry should be considered no longer valid (default 25 minutes).
  • ARP Cleanup Timeout- how long before dead ARP entries should be removed from the system (default 4 hours).

Business Policy and Firewall Rules now allow selecting routed interfaces and subinterfaces as sources in addition to VLANs

This feature provides customers with the ability to match a rule to an interface or subinterface while creating a Business Policy or a Firewall rule. This enhancement simplifies mapping of the rule to all traffic on that interface.

Software Upgrades

Operators and Managed Service Providers can now delegate the capability to upgrade VMware SD-WAN Edges to Customer Enterprise Superusers, facilitating self-service of the software lifecycle of Edges.

Orchestrator Scale Improvements from Release 3.4.3

The VMware SD-WAN Orchestrator has been qualified to support up to 15,000 Edges.

Behavioral Changes on the VMware SD-WAN Orchestrator

The 4.0.0 release brings important changes to the default behavior of the Orchestrator, including the following:

  • The base OS for the 4.0.0 Orchestrator is a VMware compiled Ubuntu clone and has an internal package mirror. This may make it incompatible with some of packages hosted in the official Ubuntu mirror. As such the general-purpose Ubuntu repositories have been removed from the OS configuration. Use of external mirrors for any additional packages is not generally recommended and would need to be validated by VMware prior to any such use.
  • Introduction of a new statistics store changes out of the box retention values for some of the statistics data. Please refer to the documentation for additional details.
  • The MySQL version in the Orchestrator has been updated to the latest version and comes with files_per_table turned on. This allows MySQL to release truncated tablespace back to the operating system.
  • The Orchestrator disk volumes have been tuned and updated to better fit the data being stored. Please refer to the documentation for the details.

Remote Diagnostics in Release 4.0.0 Orchestrators

In environments where VMware SD-WAN Edges communicate with a VMware SD-WAN Orchestrator which is placed behind a NAT, a user may observe that when attempting to access Remote Diagnostics for an Edge which uses Release 4.0.0 software, that this page seems inaccessible. This is corrected by configuring the System Property network.portal.websocket.address to the actual IP/hostname used to access the Orchestrator UI in the browser.

Note: This 4.0.0 Orchestrator behavior change only affects Edges running software version 4.0.0 or higher.

In such environments, Edges communicate with the Orchestrator with the address set in the network.public.address System Property (possibly the virtual IP address) whereas the Orchestrator UI itself might be accessed from a different IP/hostname (possibly the DNS address or the actual IP within the network). The main reason for this change is to ensure WebSocket connections to the Orchestrator are secure from any XSRF attacks from a browser client.

Orchestrator API Changes

The complete 4.0.0 API reference is available via code.vmware.com.

Notable changes in this release include:

  • Introduction of support for an API rate-limiting mechanism (disabled by default at this time) whereby the API will reject requests from a user (or tenant) when it observes that the rate of requests originating from that user (tenant) exceeds one or more Operator-configured policy rates. When a user (or tenant) is rate-limited, the API responds to new requests originating from that user with HTTP 429 errors until the user performs a short back-off (i.e. ceases making requests for a short time). Operators can read more about rate-limiter capabilities and the management thereof in the Orchestrator Operator Guide. Additionally, the 4.0.0 API Reference (on code.vmware.com) has been updated with guidance for API end-users to assist them in producing more resilient applications and scripts when the rate-limiter is enabled.
  • Introduction of a method “system/getVersionInfo” that reports server version information
  • Introduction of new “aggregate” API methods to facilitate monitoring of Gateway and Edge “health stats” (system resource utilization metrics):
    • monitoring/getNetworkGatewayStatus
    • monitoring/getEnterpriseEdgeStatus
  • Introduction of new API methods which may be used to monitor SD-WAN Path Statistics:
    • edge/getEdgeSDWANPeers - Lists the SD-WAN peers (Gateways, Hubs, Edges) for a given Edge and reporting interval.
    • edge/getEdgeSDWANPeerPathMetrics - Fetch per-path aggregate metrics for a given Edge and reporting interval.
    • edge/getEdgeSDWANPeerPathSeries - Fetch per-path metric time series data for a given Edge and reporting interval.
  • Introduction of various new API methods to facilitate Customer management of Edge Software Images:
    • enterprise/addEnterpriseOperatorConfiguration - Assigns a single Software Image to multiple Customers
    • enterprise/assignEnterpriseOperatorConfigurations - Assigns/removes multiple Software Images to/from a Customer
    • configuration/removeOperatorConfigurationAssocFromEnterprises - Removes a Software Image from all Customers to which it is assigned
    • enterprise/getEnterpriseSpecificOperatorConfigurations - Lists Software Images assigned to a Customer
    • enterprise/setDefaultEnterpriseOperatorConfiguration - Sets default Software Image for a Customer
    • enterprise/updateEdgeImageManagement - Enables/disables Edge Image Management for a Customer (the same action may be performed for multiple customers concurrently using  enterprise/updateEdgeImageManagementForEnterprises)
  • Customer Admins are also now permitted to use the following methods to manage Edge Software Image assignments when Customer Edge Image Management is enabled:
    • edge/setEdgeOperatorConfiguration
    • edge/unsetEdgeOperatorConfiguration
  • When creating a new customer (or cloning an existing one), Partner and Operator Admins may now enable Customer Edge Image Management using the delegateEdgeImageManagmentToEnterprise boolean option and may assign an initial set of Software Images using the assignedOperatorProfileConfigurationIds parameter.
  • Introduction of new Operator-only methods used to manage Partner (or “Enterprise Proxy”) Capabilities, including:
    • enterpriseProxy/getEnterpriseProxyCapabilities
    • enterpriseProxy/insertOrUpdateEnterpriseProxyCapability
  • Introduction of various new APIs used in the creation and management of custom roles:
    • role/getEligiblePrivilegesForCustomization - List privileges that eligible for customization for a given role
    • role/getRoleCustomizationPrivileges - Given a role customization package identifier, lists effective privileges for each role
    • role/getRoleCustomizations - Returns the list of customizations configured for a given tenant
    • role/insertRoleCustomizationPackage is introduced that inserts a new role customization package using the customizations provided as input.
    • role/applyRoleCustomizationPackage - Modifies an already-applied role customization package and reapplies the changes in the system
    • role/saveAndApplyRoleCustomizationPackage - Modifies an already-applied role customization package and reapplies the changes in the system
    • role/removeEnterpriseCustomRoles - Removes all role customizations for a Customer.
    • role/removeEnterpriseProxyCustomRoles - Removes all role customizations for a Partner.
  • Introduction of new “linkMode” field on WAN link records which indicates whether a link is configured to operate in backup or hot-standby mode.
  • In order to prevent accidental deletions of large quantities of Edges, the VCO now enforces a limit on the number of Edges that may be deleted via a single invocation of the edge/deleteEdge API method.

As of Release 4.0.0, the following pieces of API functionality are deprecated. Developers are advised to discontinue any usage of these features.

  • The following legacy role customization API methods:
    • role/createRoleCustomization
    • role/deleteRoleCustomization
  • The “vpnState” field on WAN link records, which is now redundant (the “state” field serves the same function).
  • The “state” value reported by API methods that query link metrics (e.g. monitoring/getAggregateEdgeLinkMetrics, metrics/getEdgeLinkMetrics), which is no longer meaningful.
  • The MD5 “hash” option (as used in Edge Cloud Security VPN configurations).

SDK Deprecation

VMware SD-WAN intends to deprecate the support for VMware SD-WAN Orchestrator Software Development Kit (SDK) beginning with Release 4.2.0.

Note: This announcement is only for the SDK client libraries and not for the APIs. VMware SD-WAN will continue to support the Orchestrator APIs.

Document Revision History

September 30, 2020. First Edition.

October 2nd, 2020. Second Edition. 

  • Added Orchestrator Behavior Change "Remote Diagnostics in Release 4.0.0 Orchestrators".

October 3rd, 2020. Third Edition.

  • Added resolved Orchestrator issue #50580. 
  • Corrected the Orchestrator build to R400-20201001-GA, and the Gateway/Edge builds to R400-20201002-GA. 
  • The difference in these new builds is reflected in the new fixed ticket, and in the edited Important Note - Custom Application Map Changes, which now reads that VMware SD-WAN will automatically add the mustNotPerformDpi flag for custom applications versus requiring a customer to do so.

October 17th, 2020. Fourth Edition.

  • Added a new Orchestrator build: R400-20201014-GA; added an Orchestrator Resolved section for this build which includes the new ticket resolved in this build: #50975. 
  • Added Edge fixed ticket #50617 which was omitted from the third edition.

October 26th, 2020. Fifth Edition.

  • Added a new Orchestrator build: R400-20201023-GA; added an Orchestrator Resolved section for this build which includes the new ticket resolved in this build: #50978. 
  • Note: While #50978 appear very similar to #50975 in description and impact, there are difference in the cause of each issue that required a separate ticket and build with a fix for each issue.
  • Added Edge/Gateway fixed ticket #47382.  This issue had been omitted from prior editions as it had not previously been encountered by a customer in the field using an older (Release 3.4.3) build.

October 28th, 2020. Sixth Edition.

  • In the section SDK Deprecation, regarding the sentence: "VMware SD-WAN intends to deprecate the support for VMware SD-WAN Orchestrator Software Development Kit (SDK) beginning with Release 4.1.0."  The release where the SDK is deprecated is changed from 4.1.0, to 4.2.0.
  • Added Issue #33195 to the Edge/Gateway Open Issues as this was encountered in the field.

October 30th, 2020. Seventh Edition.

  • Added a new Orchestrator build R400-20201028-GA to Orchestrator Resolved Issues, and added a new resolved issue fixed in this new build: #51634.   
  • #51634 is the third in a series of tickets addressing data transfer issues when an Orchestrator configured for Disaster Recovery is upgraded to 4.0.0. 51634 addresses an issue with historic data.  
  • Moved #44640 from Open Edge/Gateway Issues to Resolved Edge/Gateway Issues as the fix for this ticket was included in the 4.0.0 GA build.  Also added detail to the ticket description.

November 18th, 2020. Eight Edition.

  • Added a new Orchestrator build R400-20201111-GA to Orchestrator Resolved Issues, and added a new resolved issue fixed in this new build: #52271.   

November 25th, 2020. Ninth Edition.

  • Added a new Gateway hotfix build: R400-20201124-GA-53090; added a Gateway Resolved section for this build which includes the new ticket resolved in this build: #53090.

November 26th, 2020.  Tenth Edition.

  • Under the section "Important Notes", added a note on "Edge Licensing" regarding two important behavior changes on a 4.0.0 and higher Orchestrator and that had been omitted from prior editions of the 4.0.0 Release Notes. 

December 7th, 2020. Eleventh Edition.

  • Corrected a wording error where the sentence "As of Release 4.0.0, the following pieces of API functionality are deprecated. Developers are advised to discontinue any usage of these features." was placed below the items that were being deprecated, causing obvious confusion.  This sentence is placed properly in this edition.

September 16th, 2021. Twelfth Edition. 

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

December 15th, 2021. Thirteenth Edition.

  • Added Issue #22131 to the Edge/Gateway Fixed Issues to make it explicitly clear this was fixed in 4.x and later builds.

December 21st, 2021. Fourteenth Edition.

  • Added a new Orchestrator build R400-20211217-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.

March 23rd, 2022, Fifteenth Edition

  • Added Issue #84825, to the Edge/Gateway Known Issues section.
  • Under the Compatibility section, added a new Warning that Release 3.4.x software is approaching End of Support for the Orchestrator and Gateway with End of General Support (EOGS) on March 30, 2022, and End of Technical Guidance (EOTG) June 30, 2022. This is for the Orchestrator and Gateway only. The 3.4.x Edge software is scheduled to enter its End of Support window beginning on December 31, 2022.

April 7th, 2022. Sixteenth Edition

  • Added a new Fixed Issue #38647 to the Edge/Gateway Resolved Issues section. This issue had been omitted from the original Release Notes in error.

Resolved Issues

The resolved issues are grouped as follows.

Gateway Resolved Issue

Resolved in Gateway Release R400-20201124-GA-53090

The below issue is resolved since Gateway version R400-20201002

  • Fixed Issue 53090: Tunnels to a Non SD-WAN Site via Gateway may fail after an IKE Phase 1 rekey or when a tunnel goes down and IKE Phase 1 must be reinitiated.

    When the VMware SD-WAN Gateway initiates tunnels to non SD-WAN sites, the security association (SA) involves a source and destination port. Once there is an SA, both these ports need to be populated correctly to ensure that IKE Phase 1 SA is recreated properly.  As referenced in the VMware SD-WAN Release 4.0.0 Release Notes, VMware SD-WAN Release 4.0.0 replaced the IPsec libraries with FIPS 140-2 compliant IPsec libraries. As part of this replacement, the SA destination port was inadvertently set incorrectly on the second and subsequent negotiation attempts for a given peer.  

    For some non SD-WAN sites, the peer discards this invalid port and returns a proper Traffic Selector (TS). For peer sites which do not correct this, the peer responds with the invalid port in the TS which the VMware SD-WAN Gateway rejects and this results in Gateway tunnels failing at rekey or when a tunnel goes down and IKE Phase 1 must be reinitiated.

    A customer is more likely to encounter this issue if the Non SD-WAN Site is misconfigured (e.g. the site is configured to use IKEv1 when the peer site uses IKEv2).

Edge/Gateway Resolved Issues

 

  • Fixed Issue 21281: 

    Some configuration updates pushed by the VMware SD-WAN Orchestrator VCO to the VMware SD-WAN Edge may be incompletely processed if the Edge is processing a high number of flows during the push.

  • Fixed Issue 22131: BGP restarts on a PIMD failure or restart.

    All routing protocol daemons (bgpd, ospfd, pimd) restart if any one of those daemons restarts or fails. This is true of any Release 3.4.x or earlier build due to the routing architecture those builds used. Release 4.0.0 and later include an improved routing architecture which resolves this issue as a failure or restart of one routing daemon will not affect the others.

    Note: Despite the improvements brought by this new routing architecture, an Edge service restart will continue to restart all routing daemons.

  • Fixed Issue 22990:

    A private NTP server which uses a VPN route (i.e. a non-cloud route) will not work.

  • Fixed Issue 23486:

    BGP on DHCP enabled interfaces is not supported on the VMware SD-WAN Edge.

  • Fixed Issue 24133:

    When a WAN link is down and other paths are UNUSABLE to a Partner Gateway, the Partner Gateway still redistributes Edge subnets to the Provider Edge Router, which causes asymmetric routing.

  • Fixed Issue 25302:

    If the Dataplane Service is disabled on the VMware SD-WAN Edge, a "Restart Services" does not work properly, and a 'Reboot' must be triggered to recover the Edge.

  • Fixed Issue 29092:

    1:1 NAT rule does not work if the WAN IP and LAN IP are the same.

  • Fixed Issue 30175:

    If the VMware SD-WAN Edge must send either a BGP or an OSPF route report to the VMware SD-WAN Orchestrator that is very large in size, the report may not successfully upload intact or may require multiple round trips to complete.

  • Fixed Issue 30953:

    On a VMware SD-WAN Edge, VLAN-tagged DHCP packets are not dropped by a routed interface that does not have a matching VLAN tag.

  • Fixed Issue 31389:

    If PIM on Overlay is enabled for a client-facing interface of a VMware SD-WAN Hub Edge, and then disabled PIM while traffic is flowing through that interface, when PIM is reenabled on this client-facing interface, the PIM register message is not sent and PIM on Overlay is not enabled.

  • Fixed Issue 31971:

    DHCP relay functionality on a VLAN-tagged routed interface does not work if the relay is configured on the sub-interface.

  • Fixed Issue 32018:

    A DHCP server on a sub-interface does not work if the relay is configured on the primary interface.

  • Fixed Issue 32641:

    On a customer enterprise with a large number of VMware SD-WAN Spoke Edges (>2000) and a large number of routes (>50K), the VMWare SD-WAN Gateway is slow in distributing the routes and bringing the routes into sync after the Gateway is restarted. This issue affects the recovery of Branch-to-Branch connectivity via a Hub Edge.

  • Fixed Issue 33415:

    When LAN-side NAT is configured with a single NAT IP for different LAN subnets, only one of the LAN subnets for which the static route is configured works.

  • Fixed Issue 34634:

    A Non SD-WAN Destination via Gateway to AWS requires an IPSEC rekey start from either the VMware SD-WAN Gateway or VMware SD-WAN Edge side.

  • Fixed Issue 36005:

    If a Port Forwarding rule with an outside IP address is configured for a PPPoE WAN link, the sub-interface is not created for the rule.

  • Fixed Issue 36091:

    If a private link is configured to be used as a Backup only, the link is set to 'Dead' instead of 'Standby'.

  • Fixed Issue 36460:

    The NetFlow Collector ID is not synced with the verbose and non-verbose output of debug.py.

  • Fixed Issue 37030:

    BGP default route is not revoked from a peer device when disabling the default route option in the VMware SD-WAN Orchestrator for a BGP uplink neighbor.

  • Fixed Issue 37308:

    If a user deletes all the links configured to build GRE tunnels to Zscaler (but does not disable Cloud Security Service), then changes the Zscaler IP addresses and re-configures the links, the Edge must be restarted to route traffic over the GRE tunnels.

  • Fixed Issue 37746:

    In rare scenarios, if a VMware SD-WAN Gateway develops stale NAT entries and a user flow has the same 5-tuple as the stale NAT entry, the user flow would be dropped at the Gateway.

  • Fixed Issue 37752:

    Changing the administrator password for a CheckPoint VNF appears to succeed but the password does not actually change.

  • Fixed Issue 37966:

    SNAT entry for existing flows is not removed from the NAT table when NAT IP is modified for a LAN side NAT rule.

  • Fixed Issue 38623:

    VRRP responds to ICMP for a virtual IP address.

  • Fixed Issue 38647: When a VLAN tag is configured on a VMware SD-WAN Edge interface, features dependent on the Edge's Linux kernel for networking (like ARP on an unactivated Edge or a DHCP server) send packets out without the VLAN tag which may cause connectivity issues.

    When a VLAN tag is configured on an Edge interface, the Edge would configure the IP address for the interface on both the physical and the VLAN interfaces associated with that interface in the Edge's Linux kernel. This would confuse the Linux kernel routing table and cause it to send packets out on the wrong interface. For example, packets that should be routed to a subinterface are instead routed to the main interface, and this results in connectivity issues.

  • Fixed Issue 38925:

    VPN flows are not synchronized properly between VMware SD-WAN Edges in a High Availability pair, which may cause stateful firewall sessions via VPN to stall on an HA failover.

  • Fixed Issue 39014:

    A VMware SD-WAN Edge service restart may be required when changing established Zscaler tunnels from IPsec to GRE to the same Zscaler IP address.

  • Fixed Issue 39132:

    When the inner DSCP Tag of the packet is “VA”, “copy from inner” business policy configurations do not copy the inner tag to the outer tag.

  • Fixed Issue 39167:

    When MPLS COS is configured with no user defined policy with a VMware SD-WAN Gateway configured for VPN, the outer DSCP tag is set as CS0 instead of copying from the inner DSCP tag.

  • Fixed Issue 39359:

    For a small group of older VMware SD-WAN Edge 3x00's (3400/3800), their IPMI port (labeled 'BMC') has an invalid MAC address. This impacts a customer only if they have multiple Edge 3x00's with this issue AND they are connecting up the IPMI ports to the same switch (for centralized IPMI management).

    Workaround: Other than upgrading the Edges to Release 4.0.0, the workaround would be to connect the Edge 3x00's respective IPMI ports to different switches.

  • Fixed Issue 39384:

    Traffic initiated on a WAN-overlay enabled interface may be double counted in NetFlow statistics. 

  • Fixed Issue 39464:

    When an SNMP agent is configured to listen on a non-default port, the SNMP Access firewall rule is not updated to that configured port. 

  • Fixed Issue 39609:

    Incorrect packet loss may be reported when MPLS Classes of Service are enabled on one VMware SD-WAN Edge but not the peer Edge and link steering via business policy is configured. 

  • Fixed Issue 39635:

    User is unable to check if Conditional Backhaul is enabled without editing the Cloud VPN settings at the Profile level and has no way to see if Conditional Backhaul is enabled at the Edge level.

  • Fixed Issue 39931:

    Auto-Negotiation status of a VMware SD-WAN Edge's SFP port is not displayed on the Remote Diagnostic "Interface Status".

  • Fixed Issue 39933:

    System generated NetFlow packets are not sent out when the MTU is configured for less than 1500. Packet fragmentation does not happen properly.

  • Fixed Issue 39965:

    Flow creation takes more time when creating many flows whose application type cannot initially be determined by the Deep Packet Inspection (DPI) engine.

  • Fixed Issue 40038:

    Some Copper SFPs when deployed in an Edge 610 will show the link as 'UP' even when no cable is inserted on the VMware SD-WAN Orchestrator UI.

  • Fixed Issue 40043:

    For a VMware Edge 840 with DPDK Enabled, if the Remote Diagnostic "Interface Status" is run, the speed for an SFP interface does not show.

  • Fixed Issue 40076:

    VMware SD-WAN Edge's diagnostic bundle is missing details about SFP's plugged into that Edge.

  • Fixed Issue 40348:

    For a VMware SD-WAN Edge using DNS to resolve Zscaler CSS endpoint names, when the Edge is not able to resolve the primary endpoint, the Edge does not try to resolve the secondary endpoint.

  • Fixed Issue 40350:

    Route flags are not displayed for routes with Non SD-WAN Destinations via Gateway peer locations (AKA Data centers) in the debug.py --verbose_routes output on a VMware SD-WAN Gateway.

  • Fixed Issue 40395:

    The Hub route is installed in the wrong order in a VMware SD-WAN Edge that is a spoke in one profile and a Hub in another profile.

  • Fixed Issue 40486:

    Under rare scenarios, a VMware SD-WAN Edge may experience a Dataplane Service Failure may occur while handling and applying BGP configurations pushed from the VMware SD-WAN Orchestrator.

  • Fixed Issue 40488:

    The VMware SD-WAN Edge establishes dynamic tunnels to other Edges that are not in the same profile although profile isolation is enabled.

  • Fixed Issue 40497:

    Downloading a VNF image from AWS S3 will not succeed if the S3 bucket only supports Signature V4 authentication.

  • Fixed Issue 40639:

    When an ICMP reply is received as the first packet from a remote client, the VMware SD-WAN Edge does not forward the packet, but does log it as a valid ICMP session.

  • Fixed Issue 40644:

    With Stateful Firewall enabled, UDP packets with port 0 are dropped as expected, but show up in the firewall session table as ICMP.

  • Fixed Issue 40696:

    Disabling BGP on a VMware SD-WAN Hub Edge that is active in a Cluster does not set the BGP route count for this Hub Edge to 0 and trigger an automatic failover as expected.

  • Fixed Issue 40777:

    Syslog export of VMware SD-WAN Edge events does not work to a server that is reachable over VPN only via a default (0.0.0.0/0) route. 

  • Fixed Issue 40852:

    A VMware SD-WAN Edge 520 may not save all kernel panics on the Edge for later inclusion in a diagnostic bundle.

  • Fixed Issue 40988:

    On VMware SD-WAN Edge models 500, 510, and 520, the Local UI may take a very long time to come up, or time out completely. 

  • Fixed Issue 41176:

    SNMP poll does not work for the outside address of a LAN side NAT rule when the inside address is the interface address.

  • Fixed Issue 41264:

    A VMware SD-WAN Edge in a Non-High Availability topology conducts unnecessary High Availability drop checks. 

  • Fixed Issue 41299:

    When an interface IP is used as the outside address for a LAN side NAT rule, the ping reply comes from the inside address instead of the outside address.

  • Fixed Issue 41892:

    The NetFlow logs will show a client's source MAC value as 00:00:00:00:00:00 for ICMP traffic on a non-global segment.

  • Fixed Issue 42314:

    Static routes with the preferred flag unchecked are not advertised into the overlay.

  • Fixed Issue 42479:

    A kernel panic Event does not show the full details of the logs on the VMware SD-WAN Orchestrator because the VMware SD-WAN Edge does not send the panic log details to the Orchestrator.

  • Fixed Issue 42480:

    When using telnet to connect to the console of a Checkpoint VNF deployed on a VMware SD-WAN Edge, carriage return characters are doubled.

  • Fixed Issue 42577:

    Dynamic Bandwidth Adjustment does not run for a wired link that is converted to wireless.

  • Fixed Issue 42877:

    Multi-rate optical SFPs do not work in 1G mode on VMware SD-WAN Edge models 620, 640, and 680.

  • Fixed Issue 42987:

    Peer initiated flows do not contain correct Application and Class ID which results in a VMware SD-WAN Hub Edge: a) reporting Orchestrator statistics for an application name different than the Spoke Edge, and b) the Hub is unable to match based on applications for peer flows.

  • Fixed Issue 43018:

    Remote Diagnostics on the SD-WAN Edge shows "Firewall" utilities even when the Stateful Firewall is disabled, resulting in confusion for customers.

  • Fixed Issue 43504:

    A log message is created when Realtime TCP is overridden from replicate to NACK.

  • Fixed Issue 43613:

    OSPF neighborship may not be established over a routed interface when the interface receives its DHCP IP after a delay.

  • Fixed Issue 43616:

    If a VMware SD-WAN Edge detects either disk corruption or disk hardware errors, these events are not reported to the VMware SD-WAN Orchestrator so that they may be posted in Events.

  • Fixed Issue 44212:

    For a site using a High-Availability topology, LAN connectivity may be lost when the Active VMware SD-WAN Edge is rebooted (causing the Standby Edge to be promoted), and the user is simultaneously disabling High-Availability for this Edge on the VMware SD-WAN Orchestrator. When this issue is encountered, the Standby Edge comes up as the now standalone Edge, but the HA interface is still there, and all LAN ports move to a blocked state.

  • Fixed Issue 44233:

    A VMware SD-WAN Edge will experience a Dataplane Service Failure while generating a diagnostic bundle if the command debug.py --remote_routes is run on a VMware SD-WAN Gateway to which the Edge is connected.

    Workaround: There is no workaround for this issue.

  • Fixed Issue 44259:

    SNMP walk failed on some VMware SD-WAN Edge interface combinations, including PPPOE with VLAN tagging, and Private WAN interfaces.

  • Fixed Issue 44531:

    Peer initiated flows do not contain the correct Application and Class ID.  This issue would have impact for a customer using a VMware SD-WAN Hub Edge/Spoke Edge topology.

  • Fixed Issue 44640:

    On a customer site which uses VMware SD-WAN Virtual Edges in a high-availability topology, under an extremely high flow load the Standby Edge may get into a state where it frequently disconnects and reconnects to the Active Edge, which may also result in the Standby Edge experiencing a Dataplane Service Failure and restarting.  The user will also observe a large number of HA_FAILED and HA_READY messages on the Orchestrator.

  • Fixed Issue 44706:

    Abrupt power loss events are not logged correctly on a VMware SD-WAN Edge model 520 or 540.

  • Fixed Issue 44880:

    A VMware SD-WAN Gateway may experience a Dataplane Service Failure when a MPLS COS configuration which includes a loose IP precedence is modified.

  • Fixed Issue 44964:

    The MTU is set to an invalid value for an ICMP fragmentation needed message generated for packets going via GRE tunnels.

  • Fixed Issue 45233:

    A VMware SD-WAN Hub Edge may drop packets when Edge-to-Cloud traffic switches over from an underlay path to an overlay path using Internet Backhaul via Business Policy.

  • Fixed Issue 45255:

    Syslog firewall logs display destination VLAN as 524287 when the VLAN is not configured.

  • Fixed Issue 45414:

     If a PPPoE interface has a password which contains "=", the VMware SD-WAN Edge may fail to start up with error ValueError: too many values to unpack seen in the vc_procmon.log of an Edge diagnostic bundle.

  • Fixed Issue 45542:

    When a VMware SD-WAN Hub Edge is removed from a Hub Cluster, the Spoke Edges remain associated with that removed Hub Edge and are not reassigned to other Hub Edges in the Cluster.

    Workaround: For the Hub Edge that is removed, go to Remote Diagnostic > Rebalance Hub Cluster and run the utility “Redistribute Spokes excluding this Hub”.

  • Fixed Issue 45661:

    For VMware SD-WAN Edge models 610, 620, 640, and 680, SFP ports 1 and 2 have the following LED behaviors: the 1G speed will show an amber LED,  and the 10G speed will show green.

  • Fixed Issue 45810:

    On A VMware SD-WAN Edge model 3400 or 3800 where the Intel X722 Controller uses older firmware, if the SFP1 and SFP2 interfaces are either empty, or populated with unsupported SFP modules, those SFP interfaces are not usable. This condition in turn prevents the Edge Dataplane Service from starting, resulting in no customer traffic traversing the Edge.

    Workaround: Disable the SFP1 and SFP2 interfaces on the Interfaces section of the Configure > Edge > Device page on the VMware SD-WAN Orchestrator UI.

  • Fixed Issue 45842:

    When there are multiple routes learnt for the same prefix on a VMware SD-WAN Edge, a remote route that has been previously advertised to the BGP peer might be revoked during a tunnel flap with the remote peer and may never get advertised again.

  • Fixed Issue 45903:

    A VMware SD-WAN Edge may experience a Dataplane Service Failure when 2040 outbound firewall rules are configured and traffic matching those rules is sent across 3 segments, 680 matches for each segment (1 global segment and 2 non-global segment).

  • Fixed Issue 46035:

    For a Non SD-WAN Destinations via Edge where the peer sends oversized IPsec packets that are then fragmented (AWS does this), the Edge does not handle the fragmented IPsec packets and they are dropped.

  • Fixed Issue 46361:

    The jitter and latency values measured on a sub-path is reset and re-measured only when the sub-path is used again for data transmission.

  • Fixed Issue 46794:

    User is unable to deploy Fortinet VNF with VM00 / VM01 licenses which require a single core CPU.

  • Fixed Issue 47020:

    A VMware SD-WAN Gateway using Release 3.4.0 may mark a Non SD-WAN Destinations via Gateway tunnel as UP even though the tunnel is down. 

  • Fixed Issue 47166:

    The snmpagent reports multiple datasets incorrectly from a VMware SD-WAN Edge, leading to incorrect measurements via SNMP polling which adversely affects a customer's monitoring service. 

  • Fixed Issue 47338:

    In some cases, the VMware SD-WAN Orchestrator pushes both a device configuration change and a control plane change which are simultaneously received by the VMware SD-WAN Edge on the same heartbeat and the Edge fails to update its configurations because the updates time out. This error is seen in an Edge Diagnostic bundle in the mgd.log with the message "CommunicationError("timeout('timed out',)".

  • Fixed Issue 47591:

    The first flow of a stream classified as Realtime that uses dynamic Edge-to-Edge tunnels may have packet loss due to asymmetric routing across VMware SD-WAN Gateways and VMware SD-WAN Spoke Edges. 

  • Fixed Issue 47731:

    A VMware SD-WAN Edge using release 3.3.2 P2 with a business policy configured to rate limit traffic does not actually enforce rate limiting for downstream traffic. 

  • Fixed Issue 47832:

    When a tunnel to a VMware SD-WAN Gateway goes down and flows fail over to direct, there is a small chance that the direct flow fails due to the NAT entry being erroneously removed during the cleanup of the tunnel to the Gateway. 

  • Fixed Issue 47925:

    A route which is learned over BGP will have an incorrect neighbor IP if the nexthop on the route is not the same as the neighbor’s IP.

  • Fixed Issue 47954:

    The Remote Action “Force HA Failover” does not work correctly for a customer site using VMware SD-WAN Edge models 5X0 or 6X0.  For this action, the failover is initiated but the original Active Edge persists as the Active in the HA pair and the Standby Edge is not promoted to the Active role.

    Workaround: There is no workaround for this issue. 

  • Fixed Issue 48060:

    If a VMware SD-WAN Edge with a relatively low available WAN link bandwidth capacity (1-2 Mbps total) attempts to download Edge upgrade software as part of the Edge upgrade, the download may stall for an indefinite period and never complete.

  • Fixed Issue 48159:  A site which deploys VMware SD-WAN Edges in a High Availability topology may find both Edges deactivated after an HA failover, and the Edges would need to be reactivated.

    This issue is the result of a rare condition where the site gets into a “split brain” scenario where both Edges act as Active after a failover caused by the Active Edge restarting. While both are Active, each Edge sends an incorrect serial number to the Orchestrator and the Orchestrator compares both incorrect serial numbers to the stored serial numbers it has and, when the Orchestrator sees a mismatch, it sends a deactivation command to each HA Edge.

  • Fixed Issue 48186:

    When BGP peering is configured between two VMware SD-WAN Edges over a private link and an ICMP probe is then configured to ping an Edge on the same private link, the Edge being pinged may experience a Dataplane Service Failure.

  • Fixed Issue 48391:

    When a Cloud Security Service (CSS) is configured with a domain name (instead of an IP address), the VMware SD-WAN Edge resolves the CSS via a locally generated DNS request and stores this in the Edge's DNS cache, which will be lost once the DNS cache times out.  However, the Edge does not also store the last resolved IP address in the event DNS resolutions fails.  As a result, if the Edge needs to resolve the CSS domain name again as part of a retry of an IPsec tunnel or IKE rekey due to a network issue the IPsec tunnel will not come up due to DNS failure.

  • Fixed Issue 48462:

    When a VMware SD-WAN Edge is upgraded to Release 3.4.1, the default routes (i.e. route destination = 0.0.0.0) are removed from the Edge’s routing table and will result in users using that Edge not being able to access the internet.

    Workaround: Restarting the Edge Service will restore the default routes. On the VMware SD-WAN Orchestrator for the affected Edge, go to Remote Actions > Service Restart.

  • Fixed Issue 48627:

    In rare instances, the VMware SD-WAN Edge may experience a Dataplane Service Failure while processing TCP_SYN packets which include an 'Options' payload as the packet processing may continue beyond 'End of Options List' and trigger an exception.

    Workaround: There is no workaround for this issue. 

  • Fixed Issue 48824:

    With 'Stateful firewall' and 'Syslog Forwarding' enabled, the VMware SD-WAN Edge may experience multiple Dataplane Service Failures due to asymmetric flows.

    Workaround: Please disable 'Syslog Forwarding' under the 'Firewall' tab of the VMware SD-WAN Orchestrator. 

  • Fixed Issue 49170:

    A VMware SD-WAN Edge may experience a Dataplane Service Failure when a retransmit flow switches from the overlay to the underlay due to a route reconvergence (e.g. public WAN link flap). 

  • Fixed Issue 49209:

    On the VMware SD-WAN Edge models 520 or 540, when a LAN port from LAN 1-4 and a LAN port from LAN 5-8 are each configured for the same VLAN, the ports do not forward packets to each other.

  • Fixed Issue 49485:

    First packet application classification does not work on a VMware SD-WAN Hub Edge for flows that were backhauled from other Edges.

  • Fixed Issue 49531:

    Policy Based NAT entries may disappear from a VMware SD-WAN Partner Gateway which, if it occurs, will cause customer outages.

  • Fixed Issue 49734:

    When running the Remote Diagnostic 'Troubleshoot BGP - List BGP Redistributed Routes', the output on the VMware SD-WAN Orchestrator UI does not display the entries correctly when filtered by segment.

  • Fixed Issue 50231:

    For a customer whose enterprise uses the special MGMT-IP build for their VMware SD-WAN Edges (i.e. where the Edge Management IP is enabled for customers with requirement for global segment loopback), the Edge Management IP Address is not redistributed to BGP/OSPF.

  • Fixed Issue 50617:

    When a client connected to the Wi-Fi on a VMware SD-WAN Edge 510 attempts to download a large file from the Internet, or multiple LAN clients connected to an Edge 510's Wi-Fi attempt simultaneous downloads of files from the internet, the download(s) will stall, and then all LAN clients will be unable to access the Internet.

Orchestrator Resolved Issues

Orchestrator version R400-20211217-GA

Orchestrator version R400-20211217-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 R400-20201111-GA

    The below issue has been resolved since Orchestrator version R400-20201028-GA

    • Fixed Issue 52271: When a VMware SD-WAN Orchestrator is upgraded to Release 4.0.0, a user is not able to change Edge-overridden Cloud Security Service (CSS) configurations if there is a business policy using that CSS present on any VMware SD-WAN Edge in a customer enterprise.

      The user would encounter this issue on Configure > Edge > Device, in the Cloud Security Service section.  This issue impacts a customer because the user is unable to change the CSS provider.  This issue is the result of an added UI validation on 4.0.0 that is designed to prevent a user from changing an Edge-overridden CSS provider if that CSS is being used for any Edge-level business policy of the same Edge.  However, instead of limiting the check to business policies of the configured Edge, the Orchestrator checks all of the Edges in the customer's enterprise.

    __________________________________

    Resolved in Version R400-20201028-GA

    The below issue has been resolved since Orchestrator version R400-20201023-GA

    • Fixed Issue 51634: When a VMware SD-WAN Orchestrator deployed in a Disaster Recovery (DR) topology is upgraded to Release 4.0.0, the following symptoms are observed: 
      (a) The Web UI will load slower than expected due to the system being overloaded with inefficient database queries.
      (b) API calls may time out on the UI with a message 'Gateway timeout error'.

      Release 4.0.0 changes the way statistical data is stored, from MySQL to ClickHouse. As a result of this change, part of the DR-based-upgrade procedure includes a data migration. Once DR has been setup, the pre-4.0.0 Orchestrator will remain as active and the newly upgraded 4.0.0 Orchestrator will be in STANDBY_RUNNING mode waiting to be promoted. While the 4.0.0 Orchestrator is in STANDBY_RUNNING mode, any new data that is uploaded to the Active Orchestrator will continue to get migrated to the 4.0.0 Standby Orchestrator. The migration for the historic data was using an inefficient query issued to the Active Orchestrator which could potentially lead to increased MySQL load on the Active Orchestrator running pre-4.0.0 code. The increased load will manifest itself as API slowness, UI sluggishness and time out errors.

    __________________________________

    Resolved in Version R400-20201023-GA

    The below issue has been resolved since Orchestrator version R400-20201014-GA

    • Fixed Issue 50978: When a VMware SD-WAN Orchestrator deployed in a Disaster Recovery (DR) topology is upgraded to Release 4.0.0, the following symptoms are observed:
      a) The Web UI will load slower than expected due to the system being overloaded with inefficient database queries. 
      b) API calls may time out on the UI with a message 'Gateway timeout error'.

      Release 4.0.0 changes the way statistical data is stored, from MySQL to ClickHouse. As a result of this change, part of the DR-based-upgrade procedure includes a data migration. Once DR has been setup, the pre-4.0.0 Orchestrator will remain as active and the newly upgraded 4.0.0 Orchestrator will be in STANDBY_RUNNING mode waiting to be promoted. While the 4.0.0 Orchestrator is in STANDBY_RUNNING mode, any new data that is uploaded to the Active Orchestrator will continue to get migrated to the 4.0.0 Standby Orchestrator. However, the migration for the new data was using an inefficient query issued to the Active Orchestrator, leading to increased MySQL load on the Active Orchestrator running pre-4.0.0 code. The increased load will manifest itself as API slowness, UI sluggishness and time out errors.

    __________________________________

    Resolved in Version R400-20201014-GA 

    The below issue has been resolved since Orchestrator version R400-20201001-GA.

    • Fixed Issue 50975:  When a VMware SD-WAN Orchestrator deployed in a Disaster Recovery (DR) topology is upgraded to Release 4.0.0, the following symptoms are observed: 
      (a) Data duplication is seen in the Orchestrator monitoring charts.
      (b) The Web UI will load slower than expected due to the system being overloaded with inefficient database queries.
      (c) API calls may be timed out on the UI with a message 'Gateway timeout error'.

      Release 4.0.0 changes the way statistical data is stored, from MySQL to ClickHouse. As a result of this change, part of the DR-based-upgrade procedure includes a data-migration. Once DR has been setup, the pre-4.0.0 Orchestrator will remain as active and the newly upgraded 4.0.0 Orchestrator will be in STANDBY_RUNNING mode waiting to be promoted. While the 4.0.0 Orchestrator is in STANDBY_RUNNING mode, any new data that is uploaded to the Active Orchestrator will continue to get migrated to the 4.0.0 Standby Orchestrator. However, the migration for the new data can end-up copying the same data that has already been migrated as part of the DR-setup phase, leading to data duplication and increased MySQL load on the Active Orchestrator running pre-4.0.0 code. The increased load will manifest itself as API slowness, UI sluggishness and time out errors.

    __________________________________

    Resolved in Version R400-20201001-GA 

    The below issues have been resolved since Orchestrator version R343-20200910-GA. 

    • Fixed Issue 25134:

      A VMware SD-WAN Spoke Edge that is configured for High Availability, the VMware SD-WAN Orchestrator does not detect the Standby Edge and shows a "Pending standby detect" message, even though the Spoke Edge that is Active is detecting the Standby.

    • Fixed Issue 28260:

      After a pair of VMware SD-WAN Edges are successfully established in a High Availability topology, the Edge will show as 'Pending Dissociation' for its HA status on the VMware SD-WAN Orchestrator Monitoring page.

    • Fixed Issue 29165:

      When running the Remote Diagnostic "List Paths" the column names overlap.

    • Fixed Issue 31410:

      If a VMware SD-WAN Edge is trying to push a large number of routes to the VMware SD-WAN Orchestrator, the Orchestrator UI page will display 504 Server Error: Gateway Time-Out when trying to load that Edge's page.

    • Fixed Issue 32267:

      On a VMware SD-WAN Orchestrator configured for Disaster Recovery, replication stops if there is a duplicate entry in the statistic tables.

    • Fixed Issue 32282:

      When an Operator attempts to Upgrade the Edge License Edition for a customer, the UI screen just stops with a pending circle spinning indefinitely.

    • Fixed Issue 32558:

      VMware SD-WAN Orchestrator allows a user to remove a Partner Gateway from a Gateway Pool when that Gateway is in use by one or more Customer Enterprise Profiles.

    • Fixed Issue 33001:

      When a user deletes learned routes from the Overlay Flow Control (OFC), the VMware SD-WAN Orchestrator UI will display the message "com.labels.itemsDeleted".

    • Fixed Issue 33157:

      The VMware SD-WAN Orchestrator displays the options 'Edge Inventory', 'Orchestrator Owner' and 'Manage Orchestrator' for a user with a role that does not have permissions to access these options.

    • Fixed Issue 33454:

      The VMware SD-WAN Orchestrator does not show an error message if the user creating a Azure Hub Non SD-WAN Destinations via Gateway
      site is using an IaaS subscription which has an expired or invalid client_secret.

    • Fixed Issue 33997:

      The getEdgeDeviceMetrics API is not optimized for performance due to the MySQL query lacking partition awareness.

    • Fixed Issue 34182:

      The Total Bytes value in the Links/Transport group section of the Monitor > Transport tab does not match the sum of the values individually listed by transport class.

    • Fixed Issue 35307:

      If a user disables SNMP settings at the VMware SD-WAN Edge level on a VMware SD-WAN Orchestrator UI, the SNMP settings pushed down as configurations fail to be applied due to the absence of a SNMP section in the segment-based device configuration.

    • Fixed Issue 35864:

      A Partner Administrator with the "Business Specialist" role cannot create new customers on the VMware SD-WAN Orchestrator.

    • Fixed Issue 36028:

      VMware SD-WAN Edge flow statistics older than four weeks are not automatically purged from the VMware SD-WAN Orchestrator.

    • Fixed Issues 36354:

      The VMware SD-WAN Orchestrator does not enforce the minimum supported Edge software version system property when used in Network Overview.

    • Fixed Issue 36363:

      The API method monitor/getEnterpriseEdgeStatus is limited to 64 Edges and does not contain all Edge metrics for the specified time.  This API is also inadequately documented in the swagger documentation.

    • Fixed Issue 36601:

      If a user changes a public WAN link to a private WAN link, the VMware SD-WAN Orchestrator still allows the user to configure a Cloud Security Service GRE tunnel.

    • Fixed Issue 36690:

      The API methods /monitoring/getAggregateEdgeLinkMetrics and /metrics/getEdgeLinkMetrics return a meaningless "state" value that is not properly documented in VMware SD-WAN API documentation.

    • Fixed Issue 38037

      VMware SD-WAN Orchestrator does not provide visual feedback as to whether the Stateful Firewall is enabled or disabled at the Edge level.

    • Fixed Issue 38178:

      User can disable a Cloud Security Service in the device settings of the Customer Profile even though a business policy is using that CSS. 

    • Fixed Issue 38180:

      When a route is updated from type "I" to type "EU", the VMware SD-WAN Orchestrator does not send a response with the recalculated route cost.

    • Fixed Issue 38417:

      Add Edge 3810 model type to not excluded list if it was not present in either of the supported and excluded models list

    • Fixed Issue 38504:

      The API method monitoring/getNetworkGatewayStatus returns a response that often does not contain all Gateway status metrics for the requested time. The API method is also unduly restrictive in its schema validation and its date/time validation.  Finally, this API method is not properly documented in the swagger documentation.

    • Fixed Issue 38826:

      On a VMware SD-WAN Orchestrator configured for Disaster Recovery (DR), the Standby Orchestrator may try to copy unavailable reports from the active because the containers for the data records are created before the physical file is created.

    • Fixed Issue 39032:

      When a user deletes a prefix from the Overlay Flow Control (OFC) section, the VMware SD-WAN Orchestrator does not provide clear messaging confirming the action.

    • Fixed Issue 39119:

      The VMware SD-WAN Orchestrator displays an incorrect Alert delivery time for "Edge Down" on the Monitor > Events page.

    • Fixed Issue 39146:

      User can configure two static routes with both having the same route and the same next hop.

    • Fixed Issue 39186:

      If a user tries to create a VMware SD-WAN Gateway using script injection, the VMware SD-WAN Orchestrator blocks the attempt, but does not display an error on the UI.

    • Fixed Issue 39474:

      User can enable RADIUS authentication for a WAN port even though the WAN overlay is still enabled.

    • Fixed Issue 39544:

      User does not have the option to disable Path MTU Discovery for a WAN link from the VMware SD-WAN Orchestrator UI.

    • Fixed Issue 39560:

      If a user provides invalid input for the Remote Diagnostic "Flush Flows", the error message is displayed under the Remote Diagnostic "Flush Firewall Sessions" instead.  Also if a user provides invalid input for the Remote Diagnostic "Flush Firewall Sessions" no error is returned.

    • Fixed Issue 39565:

      Injecting a script for Address/Port Group in an Object group makes VMware SD-WAN Orchestrator UI window continually load rather than throwing an error.

    • Fixed Issue 39635:

      User is not able to view a conditional backhaul configuration at either the Profile or Edge level.

    • Fixed Issue 39639:

      If a user provides invalid input for the Remote Diagnostic "NAT Table Dump", the VMware SD-WAN Orchestrator does not throw an error message even though the diagnostic will fail.

    • Fixed Issue 40000:

      A user may delete a VMware SD-WAN Hub Cluster even though there are Edge Hubs assigned to that cluster.

    • Fixed Issue 40239:

      A Partner Administrator with a Superuser role is able to configure the following properties through the updateEnterpriseProxy API Call: operateGateways, configurationId, gatewayPoolIds and gatewayPoolId.

    • Fixed Issue 40302:

      A user may delete a VMware SD-WAN Hub Cluster even though that Hub Cluster is configured for use in a Branch-to-Branch VPN.

    • Fixed Issue 40314:

      A user may delete a VMware SD-WAN Hub Cluster even though that Hub Cluster is configured for use as a Backhaul VPN Hub.

    • Fixed Issue 40422:

      Operator User is able to edit a customer enterprise using an API even though the enterprise was not configured to delegate that authority to an Operator.

    • Fixed Issue 40423:

      The VMware SD-WAN Orchestrator UI erroneously displays the message "Changes saved successfully" when it should display the message "No changes" for a Non SD-WAN Destinations via Gateway configuration dialog.

    • Fixed Issue 40493:

      User can delete a BGP filter at the Customer Profile level even though the filter is in use by a VMware SD-WAN Edge which is using that Profile.

    • Fixed Issue 40495:

      VMware SD-WAN Orchestrator does not have a validation check for invalid characters in the VLAN name field at the Customer Profile level.

    • Fixed Issue 40567:

      A user is able to clone a customer enterprise even though the customer's profile includes partner gateways (which cannot be cloned) and there is no clear error message about why attempting this will not work.

    • Fixed Issue 40576:

      VMware SD-WAN Orchestrator does not have a configuration parameter for Token Based Authentication.

    • Fixed Issue 40595:

      When an Operator changes both the Customer's Operator Profile and the Distributed Cost Calculation properties, there is a warning message for one of those changes, and not both.

    • Fixed Issue 40698:

      If a user tries to upgrade an Edge license edition from Enterprise edition to Premium edition the attempt is not successful, and the user sees the message "enterprise edition is the same as existing assignment".

    • Fixed Issue 40746:

      Connected subnets and static routes associated with subinterfaces may not show up as expected on the Configure > Overlay Flow Control screen of the VMware SD-WAN Orchestrator.

    • Fixed Issue 40793:

      On the Monitor > Overlay Flow Control page, the drop-down menu for selecting rows incorrectly shows 'Select All' as '0' versus the possible number of rows that are available to display.

    • Fixed Issue 40850:

      On the Monitor > Overlay Flow Control page, when making an error filtering routes, the error messages are not correct.

    • Fixed Issue 40880:

      Synchronous Flow Stats processing does not insert flows in VMware SD-WAN Edges using Release 3.3.2.

    • Fixed Issue 41568:

      The VMware SD-WAN Orchestrator shows several flowStats system properties that were deprecated prior to 3.3.x.  The Orchestrator also lacks a retention.flowstats.days property with a default value that makes it clear to customers what the default value is and that it can be modified.

    • Fixed Issue 42088:

      A user may enable High Availability for a VMware SD-WAN Edge even though the HA interface is disabled.

    • Fixed Issue 42125:

      User can configure a Business Policy with Link Steering that uses a Backup or Hot Standby WAN link.

    • Fixed Issue 42250:

      When updating a WAN link configuration using the API call configuration/updateConfigurationModule, the API does not perform type-sanity checking for the dynamicBwAdjustmentEnabled WAN link option.

    • Fixed Issue 42697:

      On the Events page of the VMware SD-WAN Orchestrator, if the user changes the time filter, any other event filter (ex. "Edge name is") will show on the page but is not actually applied to the results.

    • Fixed Issue 42816:

      It is possible to select the MD5 hash for a Zscaler CSS configuration.  MD5 is not a supported hash for Zscaler deployments.

    • Fixed Issue 42989:

      The API call to clone enterprises should report corresponding errors in its response in case the request is malformed and does not adhere to the specified schema.

    • Fixed Issue 43025:

      In a 510-LTE edge, VCO allows the CELL1 interface to be disabled from device settings even if it is associated to a business policy. This fix prevents CELL1 interface from being disabled if it is used in a business policy

    • Fixed Issue 43213:

      Azure Virtual Hub Non SD-WAN Destinations via Gateway deployment fails when the target Hub has an existing site-to-site VPN connection. 

    • Fixed Issue 43300:

      User is unable to create an API token when a token belonging to another tenant has the same name.

    • Fixed Issue 43466:

      The VMware SD-WAN Orchestrator generated netmask for a VLAN and interface address ranges is not consistent with user-specified CIDR prefix.

    • Fixed Issue 43551:

      The Alert Email sent by the VMware SD-WAN Orchestrator shows an incorrect "From" email address.

    • Fixed Issue 44002:

      A VMware SD-WAN Orchestrator will noticeably slow down if an enterprise on that Orchestrator enables Cloud-VPN Edge-to-Hub for 100+ VMware SD-WAN Edges.

    • Fixed Issue 44160:

      The VMware SD-WAN Orchestrator does not check the validity of 'type' inputs for VLAN addressing in Device Settings.

    • Fixed Issue 44255:

      There is no option to filter by destination IP address on Monitor > Edge > Destinations tab.

    • Fixed Issue 44345:

      On Configure > Device > VRRP Settings, the interface dropdown shows incorrect interfaces.

    • Fixed Issue 44648:

      On the Monitor > Edge Overview page, the 'Cloud Status' and 'VPN Status' are separate items when they should be consolidated under a single status called 'Link Status'.

    • Fixed Issue 44674:

      Traffic which matches Microsoft Teams or Skype for Business application is categorized as regular Skype traffic with a low priority and transactional class.

    • Fixed Issue 44737:

      An Operator with a Support role can edit The Orchestrator Upgrade page.

    • Fixed Issue 44739:

      If an Orchestrator Upgrade banner contains invalid character, the error message does not adequately explain the issue.

    • Fixed Issue 44741:

      The Orchestrator Upgrade Banner may disappear when a new customer is created.

    • Fixed Issue 44871:

      WLAN interfaces still have a checkbox for "Captive Web Portal", even though the feature was deprecated in 3.0.0 and completely removed in 3.3.0.

    • Fixed Issue 46186:

      The VMware SD-WAN Orchestrator deletes the Auto-Detected WAN Overlay even though the user has cancelled the change in the dialog screen and did not save the change on the WAN Overlay screen.

    • Fixed Issue 46267:

      If a Partner Administrator uses the API call getEdgeGatewayAssignments, the results include enterprises not assigned to that Partner.

    • Fixed Issue 46335:

      For a VMware SD-WAN Orchestrator configured in a Disaster Recovery topology, when the Standby Orchestrator is promoted, Alerts and Notifications may get disabled.

    • Fixed Issue 46836:

      The Orchestrator Upgrade banner cannot be removed after upgrading the VMware SD-WAN Orchestrator to Release 3.4.2.

    • Fixed Issue 46901:

      When heartbeat spread factor is configured on a VMware SD-WAN Orchestrator using a Disaster Recovery topology and a DR failover happens while a VMware SD-WAN Edge is offline, the Edge may not properly receive configuration updates when it comes back offline.

    • Fixed Issue 46982:

      In rare cases, long-running backend jobs (e.g. those that are used to carry out the Azure Virtual WAN) may be halted prematurely while in flight due to process 'auto-kill' policy.

    • Fixed Issue 47005:

      Different date/time formats are used for Webhook "test" alert payloads versus the date/time formats for actual alerts.

    • Fixed Issue 47718:

      A user who has been disabled on a VMware SD-WAN Orchestrator still has API token access.

    • Fixed Issue 48361:

      Stable links are being counted as 'Unstable' on the Network Overview page.

    • Fixed Issue 48790:

      Customer Profiles which have only VMware SD-WAN Virtual Edges cannot configure link steering under a Business Policy rule.

    • Fixed Issue 48951:

      Customer Administrators with a Standard role can still edit BGP settings even after the Standard role has been set to read-only for that setting through role customization.

    • Fixed Issue 50580:

      In rare conditions, the VMware SD-WAN Orchestrator's alert delivery mechanism encounters an unexpected error when delivering webhook alerts. This may cause delays in the delivery of future alerts of all types across all customers. If this issue occurs a sufficient number of times, it may also cause alert deliveries to fail altogether for all customers as the Orchestrator retries delivery of the failed alerts indefinitely.

    Known Issues

    Open Issues in Release 4.0.0

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

      PIM joins may fail on the VMware SD-WAN Hub when it has more than 1280 multicast neighbors.

    • 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 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 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.

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

      When a secondary IP address is deleted from a routed interface on a VMware SD-WAN Edge, the corresponding route may not be removed from the peer Edges.

      Workaround: Perform a Remote Actions > Restart Service for the Edge from which the secondary IP address was removed.

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

      If a site using VMware SD-WAN Edge 540’s configured in High-Availability is upgraded to Edge software release 3.4.1, the VMware SD-WAN Orchestrator will display this site’s HA status as “Standby Failed”.

    • Issue 47269:

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

    • Issue 47279:

      The IKE/IPSEC Template is not correct for the Non SD-WAN Destinations via Gateway type “Generic Firewall” (Policy Based VPN).

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

      When a Non SD-WAN Destinations via Gateway with type Checkpoint has its configuration modified through the Monitor > Network Services screen, the primary VPN goes down due to the VMware SD-WAN Orchestrator pushing a configuration update which includes the wrong NVS type.

    • 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.

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