times

Updated 17 February, 2023

VMware SASE™ Orchestrator Version R450-20220502-GA
VMware SD-WAN™ Gateway Version R450-20211123-GA-74198-70416-74482-30022
VMware SD-WAN™ Edge Version R450-20220413-GA
VMware Cloud Web Security™ using Orchestrator Version R450-20220502-GA
VMware Secure Access™ Version using Orchestrator Version R450-20220502-GA
VMware Edge Network Intelligence™ using Orchestrator Version R450-20220502-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
Compatibility
Upgrade Paths for Orchestrator, Gateway, and Edge
Important Notes
New SD-WAN Features
SD-WAN Feature Enhancements
New SASE Features
New Edge Network Intelligence Features
Support for New Hardware Platforms
Feature Enhancements
Orchestrator API Changes
Support for New Hardware Platforms
Revision History
Resolved Issues
Known Issues

Recommended Use

This release is recommended for all customers who require the features and functionality first made available in Release 4.5.0.

Compatibility

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

The following SD-WAN interoperability combinations were explicitly tested:

Orchestrator	Gateway	Edge
Orchestrator	Gateway	Hub	Branch/Spoke
4.5.0	4.2.1	4.2.1	4.2.1
4.5.0	4.5.0	4.2.1	4.2.1
4.5.0	4.5.0	4.5.0	4.2.1
4.5.0	4.5.0	4.2.1	4.5.0
4.5.0	3.4.5	3.4.4	3.4.3
4.5.0	4.5.0	3.4.4	3.4.3
4.5.0	4.5.0	4.5.0	3.4.3
4.5.0	4.5.0	3.4.4	4.5.0
4.5.0	3.3.2 P2 *	3.3.2 P2 *	3.3.2 P2 *
4.5.0	4.5.0	3.3.2 P2 *	3.3.2 P2 *
4.5.0	4.5.0	4.5.0	3.3.2 P2 *
4.5.0	4.5.0	3.3.2 P2 *	4.5.0
4.5.0	4.3.0	4.3.0	4.3.0
4.5.0	4.5.0	4.3.0	4.3.0
4.5.0	4.5.0	4.5.0	4.3.0
4.5.0	4.5.0	4.3.0	4.5.0
4.5.0	4.5.0	3.2.2 *	3.2.2 *
4.5.0	4.5.0	4.5.0	3.2.2 *
4.5.0	4.5.0	3.2.2 *	4.5.0

Note: The above table is only valid for customers using SD-WAN services. Customers requiring access to VMware Cloud Web Security or VMware Secure Access need their Edges upgraded to Release 4.5.0.

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

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

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

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

Upgrade Paths for Orchestrator, Gateway, and Edge

The following lists the paths for customers wishing to upgrade their Orchestrator, Gateway, or Edge from an older release to Release 4.5.0

Orchestrator

Due to infrastructure changes in the Orchestrator beginning in Release 4.0.0, any Orchestrator using a 3.x Release needs to be first upgraded to 4.0.0 prior to being upgraded to 4.5.0. Orchestrators using Release 4.0.0 or later can be upgraded to Release 4.5.0. Thus, the upgrade paths for the Orchestrator are as follows:

Orchestrator using Release 3.x → 4.0.0 → 4.5.0.

Orchestrator using Release 4.x → 4.5.0.

Gateway

Gateway upgrades from 3.x to 4.5.0 are not supported. In place of upgrading, a 3.x Gateway needs to be freshly deployed with the same VM attributes, and the old instance is then deprecated.

Upgrading a Gateway using Release 4.0.0 or later is fully supported for all Gateway types.

Edge

An Edge can be upgraded directly to Release 4.5.0 from any Release 3.x or later.

Important Notes

Potential Issue With Sites Using a High-Availability Topology

A site where a pair of Edges are deployed in a High-Availability topology may encounter an issue where the Standby Edge reboots one or more times to resolve an Active-Active state. The Standby Edge reboot(s) can cause a disruption of customer traffic with the impact greater on sites using an Enhanced HA topology as the Standby Edge also passes customer traffic. The issue is being tracked by Issue #85369 under the Edge/Gateway Known Issues section of these Release Notes.

Accessing Cloud Web Security and Secure Access

A customer wishing to access VMware Cloud Web Security or VMware Secure Access must upgrade their Edges to Release 4.5.0. These services are inaccessible on Edges using a release earlier than 4.5.0.

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 only supports a space based delimiter in an AS-Path prepending configuration.
Customers upgrading from 3.x to 4.x need to edit their AS-PATH prepending configurations to "replace commas with spaces" prior to upgrade to avoid incorrect BGP best route selection.

Extended Upgrade Time for Edge 3x00 Models

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

Limitation with BGP over IPsec on Edge and Gateway, and Azure Virtual WAN Automation

The BGP over IPsec on Edge and Gateway feature is not compatible with Azure Virtual WAN Automation from Edge or Gateway. Only static routes are supported when automating connectivity from an Edge or Gateway to an Azure vWAN.

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

Mixing Wi-Fi Capable and Non-Wi-Fi Capable Edges in High Availability Is Not Supported

Beginning in 2021, VMware SD-WAN introduced Edge models which do not include a Wi-Fi module: the Edge models 510N, 610N, 620N, 640N, and 680N. While these models appear identical to their Wi-Fi capable counterparts except for Wi-Fi, deploying a Wi-Fi capable Edge and a Non-Wi-Fi capable Edge of the same model (for example, an Edge 640 and an Edge 640N) as a High-Availability pair is not supported. Customers should ensure that the Edges deployed as a High Availability pair are of the same type: both Wi-Fi capable, or both Non-Wi-Fi capable.

New SD-WAN Features

IPv6 LAN to WAN Underlay

This feature provides support for the following:

IPv6 on LAN:
- IPv6 support on the routed interface (static, DHCPv6 stateless, DHCPv6 stateful)
IPv6 Routing, the SD-WAN Edge supports:
- BGPv6 (multi-hop)
- BFDv6 (multi-hop)
- IPv6 static routes
- IPv6 Reverse Path Forwarding (strict/loose/disable)
IPv6 Monitoring:
- IPv6 underlay accounting
- BGPv6 and BFDv6 monitoring
- Remote Diagnostics for IPv6

Gateway NAT Tracking

The NAT tracking feature provides service to stream NAT tracking details of every flow being NAT'd by the Gateway or Partner Gateway to an external log server where data can be retained and analyzed.

Gateway Migration

This feature provides customers with a self-service capability to migrate Gateways. Partners and Customers can use this functionality to migrate Non SD-WAN Destination via Gateway tunnels and rebalance Gateways using a guided workflow.

SD-WAN Feature Enhancements

Unified Administration

Release 4.5.0 provides support for new out-of-the-box roles for more granular administration of SASE services. Custom roles can be created using the new Role Builder available on the Orchestrator's New Angular User Interface. Cloud Web Security and Secure Access services can have their own dedicated roles to provide separation of roles and users across SD-WAN, Edge Network Intelligence, Cloud Web Security, and Secure Access.

Zscaler Integration GRE Automation on the SD-WAN Edge

The GRE tunnel creation from SD-WAN Edge-to-Zscaler is now automated using APIs. The automated workflow selects the nearest two Service Edges. Layer 7 Health Check can be enabled as part of the automated workflow.

New SASE Features

Data Loss Prevention (DLP)

Data Loss Prevention (DLP) protects a Cloud Web Security customer against loss from accidental or intentional sharing of restricted data. The DLP feature is available for Cloud Web Security customers with an Advanced Package. Cloud Web Security DLP includes the following capabilities:

Prevents data loss to ensure compliance with HIPAA, PCI, GDPR, and other data privacy laws.
Over 350 out-of-the-box dictionaries for inspecting traffic.
Custom dictionaries may be configured using regular expression or strings.
Non-compliant activity is reported to designated administrators.

Note: This feature is accessible beginning with VMware SASE Orchestrator build R450-20220315-GA. A 4.5.0 Orchestrator build earlier than R450-20220315-GA is limited to the new SASE features listed below.

Cloud Access Security Broker (CASB)

Cloud Access Security Broker (CASB) provides visibility and control on user activities while accessing SaaS applications. Cloud Web Security CASB includes the following capabilities:

Application Visibility (part of both Cloud Web Security standard and advanced packages): A customer has the ability to view the different SaaS applications being accessed by users within their network.

For each application, a customer using CASB Application Visibility can observe:

The risk score for each application.
The number of times users have accessed an application.
The application’s category.

Application Control (part of the Cloud Web Security advanced package only): A customer has the ability to control specific actions that can be performed on each SaaS application. Out-of-the-box predefined controls are available for all SaaS applications with application specific controls provided at a per-application level. These controls can be customized and configured per application and based on User and User Group.

For each application, a customer using CASB Application Control can control:

Initial access to the application site (Allow or Block).
Additional actions including Login, Upload/Download Content, Search, Edit, Share, Create, Delete, Like, or Post.

Customers can see the currently available actions for the applications they would like to control.

Brownfield Support for Hybrid Deployments

Customers in existing deployments using Release 4.3.0 or earlier which use Partner Gateways on VMware Hosted or Partner Hosted Orchestrators can now access SASE services like Cloud Web Security and Secure Access when all components (Orchestrator, Gateway, and Edge) are upgraded to Release 4.5.0.

Once the customer is fully upgraded to 4.5.0 they could access Cloud Web Security and Secure Access services through VMware Hosted SASE PoPs.

New Edge Network Intelligence Features

Edge Network Intelligence Client Application

Edge Network Intelligence client application is now generally available. The client application can be used to determine if an end-user has issues accessing applications due to local Wi-Fi, internet, or VPN connectivity. It is available on macOS X and Windows 10.

Partner Access to Edge Network Intelligence

Partners can access Edge Network Intelligence from the Orchestrator and will be able to launch Application and Branch Analytics.

Automatic Annotation of Orchestrator Events

Edge Network Intelligence network history will automatically annotate key events from the Orchestrator. This can used to identify if events on the Orchestrator have impacted baseline performance of an Edge.

Webhooks for Alerts

Webhooks can be configured for alert notification. The notification will provide details on the priority, number of affected devices, root cause and suggested next steps for the alert.

Self-service Activation for Zoom Integration

Customer can now go to My Account > Feeds and find the link that is required to activate the Zoom integration.

Down AP impact Report

AP impact report will provide a summary of which APs had down events that impacted clients.

Support for New Hardware Platforms

Edge 510N, Edge 610N, Edge 620N, Edge 640N, and Edge 680N

VMware plans to introduce several new SD-WAN Edge hardware models that do not include integrated Wi-Fi. These include the Edge 510N, 610N, 620N, 640N, and 680N. These Edge models will be supported in this release. Any Wi-Fi configurations made in the VMware SD-WAN/SASE Orchestrator’s settings will not impact these Edge models.

Orchestrator API Changes Since Release 4.3.x and 4.4.x

New Home for VMware SASE Platform API Documentation

Comprehensive API reference documentation for the services that comprise the VMware SASE Platform (including SD-WAN, Cloud Web Security, and Secure Access) is now available via VMware’s new developer portal, developer.vmware.com.

Changes to the Orchestrator SD-WAN Portal API ("v1")

A comprehensive API changelog is available alongside the 4.5.0 Orchestrator Portal API Reference on code.vmware.com.

The following changes may require action on the part of those who maintain API clients in order to prevent disruptions to client applications:

66011: The linkQualityEvent/getLinkQualityEvents API method previously exhibited non-deterministic behavior with respect to the inclusion of sample-level scoring information in time series samples. Following this change, the “individualScores” request parameter must be specified in order to trigger sample-level score reporting.

68447: The 4.3.0 release established a cloud security “sublocations” schema in the Cloud Security options section (“css”) within the deviceSettings configuration module (model “device_settings_cloud_security” in the API Reference) for the purpose of configuring Zscaler sublocations. This has been migrated to a new “zscaler” section of the deviceSettings configuration schema (see updated model “segmentBasedDeviceSettingsData”). Upon upgrade to the 4.5.0 Orchestrator release, a system patch is executed which converts deviceSettings configuration modules that adhere to the old schema to the new one. The Orchestrator no longer honors the old schema, and clients that produce sublocation configuration options consistent with the old schema will need to be updated to ensure they produce data that accords with the new schema.

70202: As a result of a change in the underlying database that is used to record link QoE data (and an accompanying change in processing behavior intended to improve query performance and produce behavior more closely aligned with other metrics APIs) users querying “up-to-the minute” QoE data using the linkQualityEvent/getLinkQualityEvents API method may observe lower fidelity scoring information over the most recent 15-minute period. We recommend using a query interval no shorter than 20 minutes in duration when querying for up-to-the-minute data.

Stricter syntax validation was added for the following API methods for security reasons. Developers that depend on these methods are advised to review their usage of these API methods and ensure that parameter syntax conforms to the syntax documented in the API reference.

configuration/getConfiguration

edge/deleteEdge

Changes to the Orchestrator SD-WAN API v2

The issues 66011 and 70202 also apply to users of the APIv2 methods that query link quality events.

Document Revision History

September 30th, 2021. First Edition

October 8th, 2021. Second Edition

Added a new Orchestrator build R450-20211006-GA that includes CASB functionality for users of Cloud Web Security.
Added a description of the CASB feature in the New Cloud Web Security Features section of the Release Notes.
Added Fixed Issue #71278 to the Orchestrator fixed issue for R450-20211006-GA.
Added Fixed Issue #72485 to the Cloud Web Security Fixed Issues section as making CASB available was contingent on having this issue resolved. This fix is included as part of the R450-20211006-GA build.
Added a new GA Edge build R450-20211007-GA-72423.
Add new Fixed Issue #72493 as part of the new section for Edge build R450-20211007-GA-72423.
Removed the Feature Enhancement "Reduce SD-WAN Management and Control Traffic on Wireless Links" as this was included erroneously and this feature is not included in the GA version of Release 4.5.0.

October 13th, 2021. Third Edition

Added a new Orchestrator build R450-20211012-GA.
Added Fixed Issues #72386 and #72424 to the Orchestrator fixed issues for R450-20211012-GA.

October 25th, 2021. Fourth Edition

Added a new Gateway build R450-20211022-GA-74198 to the Edge/Gateway Resolved section. This build is the new Gateway GA build for Release 4.5.0.
This Gateway build adds the fixed issue #74198, which is documented in this section.
Removed Open Issue #52104 as it was resolved in 4.2.x and Open Issue #52483 as it was closed prior to this release.

November 2nd, 2021. Fifth Edition

Added a new Orchestrator build R450-20211101-GA to the Orchestrator Resolved section.
Added Fixed Issues #63110, #64762#, #69570, #69912, #72041, #73910, #74038, #74106, #74187, #74460, and #74491 to the Orchestrator fixed issues for R450-20211029-GA.
Added a new Gateway build R450-20211029-GA-74198-70416 to the Edge/Gateway Resolved section. This build is the new Gateway GA build for Release 4.5.0.
This Gateway build adds the fixed issue #70416, which is documented in this section.

November 8th, 2021. Sixth Edition

Added a new Gateway build R450-20211104-GA-74198-70416-74482 to the Edge/Gateway Resolved section. This build is the new Gateway GA build for Release 4.5.0.
This Gateway build adds the fixed issue #74482, which is documented in this section.

November 10th, 2021. Seventh Edition

Added a new Orchestrator build R450-20211109-GA to the Orchestrator Resolved section.
Added Fixed Issues #69196, #72018, #72020, #75311, and #75433 to the Orchestrator fixed issues for R450-20211109-GA.
Added Issue #75188 to Orchestrator Known Issues.

November 22nd, 2021. Eighth Edition

Added a new Orchestrator build R450-20211120-GA to the Orchestrator Resolved section.
Added Fixed Issues #71490, #75188, #75781, and #75859 to the Orchestrator fixed issues for R450-20211120-GA.

November 30th, 2021. Ninth Edition

Added a new Gateway build R450-20211123-GA-74198-70416-74482-30022 to the Edge/Gateway Resolved section. This build is the new Gateway GA build for Release 4.5.0.
This Gateway build adds now new fixed issues, but does contain troubleshooting changes required by VMware Engineering. Specifically, improvements to Gateway debug log formatting.

December 21st, 2021. Tenth Edition

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

January 28th, 2022, Eleventh Edition

Added a new Edge build R450-20220120-GA to the Edge Resolved section. This build is the new Edge GA build for Release 4.5.0.
This Edge build includes the fixed issues #72413, #74313, #76173, which are each documented in this section.
Edited Edge Fixed Issue #58791 to clarify the conditions where the issue can occur and also simplified the language regarding the description of why the issue happens.

February 10th, 2022, Twelfth Edition

Added a new Edge build R450-20220203-GA to the Edge Resolved section. This build is the new Edge GA build for Release 4.5.0.
This Edge build includes the fixed issues #34234, #53951, #76196, #72423, #77525, are #81672, which are each documented in this section.
Amended the descriptions for #72423 as found in the R450-20211007-GA-72423 and R450-20220120-GA builds to note that there was the potential for a rare corner case scenario even with the fix that is fully resolved in the R450-20220202-GA build.

February 17th, 2022, Thirteenth Edition

Added a new Orchestrator build R450-20220215-GA to the Orchestrator Resolved section. This build is the new Orchestrator GA build for Release 4.5.0.
Added Fixed Issues #64410, #64438, #68153, #74284, #74491. #74674, #74710, #74715, #74825, #77043, #77101, #80613, #81498, and #81599, to the Orchestrator fixed issues for R450-20220215-GA.
The fixed Orchestrators issues impact VMware SASE services as follows:
- VMware SD-WAN: #74491, #77043, #77101, #80613, #81498, and #81599.
- VMware Cloud Web Security: #64410, #64438, #74284, #74674, #74710, #74715, and #74825
- VMware Secure Access: #64410

February 21st, 2022. Fourteenth Edition

Added Fixed Issue #65466 to the Edge/Gateway Resolved Issues section. This fix was included in the original GA version of Edges and Gateways and was omitted by error from the 1st Edition of the 4.5.0 Release Notes.

March 3rd, 2022. Fifteenth Edition

Added Important Note: Mixing Wi-Fi Capable and Non-Wi-Fi Capable Edges in High Availability Is Not Supported.

March 17th, 2022, Sixteenth Edition

Added a new Orchestrator build R450-20220315-GA to the Orchestrator Resolved section. This build is the new Orchestrator GA build for Release 4.5.0.
Orchestrator build R450-20220315-GA includes access to the Data Loss Prevention (DLP) feature for Cloud Web Security customers with an Advanced Package.
Added a description of the DLP feature in the New SASE Features section of the Release Notes.
This Orchestrator build remediates CVE-2021-45046, the Apache Log4j vulnerability, by updating to Log4j version 2.17.0. For more information on the Apache Log4j vulnerability, please consult the VMware Security Advisory VMSA-2021-0028.13.
Added Fixed Issues #69573, #76036, #79324, #83534, #83538, #83822, #83940, #84286, #84297, #84299, and #84300 to the Orchestrator fixed issues for R450-20220315-GA.
The fixed Orchestrators issues impact VMware SASE services as follows:
- VMware SD-WAN: #76036
- VMware Cloud Web Security: #79324, #83534, #83822, #83940, #84286, #84297, #84299, and #84300.
- VMware Secure Access: #69573 and #83538.
Added Fixed Issue #64713 to the Resolved Gateway/Resolved Issues section. The fix for this issue was included with the original Edge GA build R450-20210922-GA but had been omitted in error prior to this edition.
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.
Added a new Important Note regarding the Limitation with BGP over IPsec on Edge and Gateway, and Azure Virtual WAN Automation. The note reads: "The BGP over IPsec on Edge and Gateway feature is not compatible with Azure Virtual WAN Automation from Edge or Gateway. Only static routes are supported when automating connectivity from an Edge or Gateway to an Azure vWAN."

March 23rd, 2022, Seventeenth Edition

Added Issue #84825, to the Edge/Gateway Known Issues section.
Further edited Fixed Issue #58791 to remove the parts that states this ticket fixes HA site configured with a large number of BGP match and set filters. That part of the issue is not fixed with this ticket and is tracked with Issue #84825.

April 9th, 2022. Eighteenth Edition

Added a new Edge rollup build R450-20220404-GA to the Edge Resolved section. This is the third Edge rollup build and is the new Edge GA build for Release 4.5.0.
Edge build R450-20220404-GA includes the fixed issues #67201, #67336, #72245, #72718, #77625, #78003, #80551, #80654, #83432, and #84106, which are each documented in this section.
Added new Open Issue #83212 to Edge/Gateway Known Issues section.
Added Open Issue #62701 to the Edge/Gateway Known Issues section as this issue remains unresolved on all releases at this time.

April 25th, 2022. Nineteenth Edition

Added a new Edge rollup build R450-20220413-GA to the Edge Resolved section. This is the fourth Edge rollup build and is the new Edge GA build for Release 4.5.0.
Edge build R450-20220413-GA includes the fixed issues #78300 and #85375, which are each documented in this section.

May 4th, 2022, Twentieth Edition

Added a new Orchestrator build R450-20220502-GA to the Orchestrator Resolved section. This is the eighth Orchestrator rollup build and is the new Orchestrator GA build for Release 4.5.0.
Orchestrator build R450-20220502-GA includes the fixed issues #78688, #84214, and #84969, which are each documented in this section.
Removed Issues #46254 and #49738 from the Edge/Gateway Known Issues section as they had been resolved with the 4.3.0 Release and are thus also resolved in 4.5.0.

May 27th, 2022, Twenty-First Edition

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

June 8th, 2022, Twenty-Second Edition

Added a new Important Note: "Potential Issue With Sites Using a High-Availability Topology" regarding ongoing issues with customer sites using a High-Availability topology for a pair of Edges. This issue continues to be tracked by Issue #85369 located in Edge/Gateway Known Issues.
Under Compatibility, amended the End of Life dates for Release 4.2.x Edge software. The Edge software is broken out as a separate item and now reads: "Release 4.2.x Edges will reach End of General Support (EOGS) on June 30, 2023, and End of Technical Guidance (EOTG) September 30, 2023." The separate Orchestrator and Gateway entry retains the same End of Life dates as before.
Revised Fixed Issue #53951 in the Edge/Gateway Resolved Issues section to include another scenario that could impact a customer that encounters this issue in the field.

July 13th, 2022. Twenty-Third Edition

Added Open Issues #91365 and #92676 to the Edge/Gateway Known Issues section.

September 14th, 2022. Eighth Edition.

Removed Issue #61797 "Route backtracking is not supported on the VMware SD-WAN Edge which results in false reachability routes" from the Edge/Gateway Resolved Issue section. This issue was included erroneously and because it is an enhancement is being removed entirely from the Release Notes, versus relocating it to Known Issues.

February 2nd, 2023. Ninth Edition.

Added #82188 to the Edge/Gateway Known Issues section. This issue is fixed in Release 4.5.1.

February 17th, 2023. Tenth Edition.

Removed Issue #39659 from the Edge/Gateway Known Issues section as this is a duplicate of another ticket, #39501 which was resolved in Release 4.3.0.

Resolved Issues

The resolved issues are grouped as follows.

Edge Resolved Issues
Gateway Resolved Issues
Edge/Gateway Resolved Issues
Orchestrator Resolved Issues
Cloud Web Security Resolved Issues
Secure Access Resolved Issues

Edge Resolved Issues

Resolved in Edge Version R450-20220413-GA

Edge version R450-20220413-GA was released on 04-25-2022 and is the 4th Edge rollup for Release 4.5.0.

This Edge rollup build addresses the below critical issues since the 3rd Edge rollup, version R450-20220404-GA.

Fixed Issue 78300: If a VMware SD-WAN Edge is using a WAN link configured to be a backup, a user may observe logs or Orchestrator Events which suggest that tunnels are coming up or going down for this link.
By design, tunnels do not get established for backup links. But any tunnel request from a remote end (typically a dynamic Edge-to-Edge tunnel) might change the link status as it goes through the stack. In this fix, care have been taken so that no logs indicate that any tunnel formation or tear down is going on for the back up link.
Fixed Issue 85375: Customers using either USB-based LTE modems on a VMware SD-WAN Edge or VMware SD-WAN Edge LTE models (510-LTE or 610-LTE) may experience disruptions to LTE traffic.
A user would observe on Edge logs RX errors which increment without any traffic passing through the LTE interface. One aspect of the issue is that it occurs only if the MTU for the LTE link is less than 1500.

___________________________________________________________________

Resolved in Edge Version R450-20220404-GA

Edge version R450-20220404-GA was released on 04-05-2022 and is the 3rd Edge rollup for Release 4.5.0.

This Edge rollup build addresses the below critical issues since the 2nd Edge rollup, version R450-20220203-GA.

Fixed Issue 67201: For a site using an High-Availability topology, the customer may observe multiple reboots of the VMware SD-WAN Standby Edge with a potential disruption to customer traffic.
When the Standby Edge is detected, the Active Edge synchronizes all the path information to the Standby Edge. However, where there are a large number of path synchronization messages, the way the Edge processes these path synchronization messages can lead to either a Dataplane Service failure on the Standby Edge or to a thread priority inversion which would causes a delay in heartbeat processing while processing which can lead to an Active/Active state. In either instance on a conventional HA topology the customer impact would be minimal since the Standby Edge is not passing customer traffic. However, on an Enhanced HA deployment, where the Standby Edge is also passing traffic, the reboot(s) would disrupt some customer traffic. An HA Edge which includes this fix has enhanced path information processing code path to prevent the issue from occurring.
Fixed Issue 67336: When a user looks at the Orchestrator's Monitoring page for a VMware SD-WAN Edge, the Transport statistics show much lower values when compared to the Application statistics for that Edge.
The issue prevents a user from getting an accurate picture of throughput for a particular Edge as the user could not know which data set is correct. The issue is the result of Transport statistics not including underlay accounting versus Application statistics which do.
Fixed Issue 72245: If a VMware SD-WAN Hub Edge is used as an internet breakout from an MPLS network, management (VCMP) tunnels from a connected Spoke Edge's private interface to any public Gateways may go down or not come up.
Management (VCMP) packets from a Spoke Edge's private interface to the public Gateway are sent via the Hub Edge. In this scenario, the Hub considers this flow as a direct flow and pushes these packets into the internet via a public interface. However, due to routing issues, these flows can be marked as "Via Gateway" and this would cause the issue described above.
Fixed Issue 72718: On a customer site using a Non SD-WAN Destination (NSD) via Edge, where Internet Backhaul is configured to route traffic through the NSD via Edge, the traffic is failing for destinations using the Backhaul rule.
Backhauling to an NSD via Edge is failing because of an issue stemming from not overwriting the Destination ID. Earlier traffic that was not being backhauled to the NSD matches a default cloud route whose destination is the Gateway. The SD-WAN service fails to overwrite the older cloud route destination with the newer NSD logical ID and thus the traffic fails when matching the backhaul rule.
Fixed Issue 77625: On a site deployed with a High Availability topology, a user may observe the VMware SD-WAN Standby Edge rebooting multiple times.
The site goes into an Active/Active (Split-Brain) state due to the HA thread priority being inverted, a lower priority thread takes priority and prevents a higher priority thread from running that causes a delay in heartbeat processing and leads to the Standby Edge incorrectly being promoted to Active. In an Active-Active state the tie-break goes to the Active Edge and the Standby Edge is rebooted to demote it back to its proper Standby status. In this case though, the Active/Active event is detected multiple times with Standby Edge reboots each time to recover the site. When this issue is encountered on a conventional HA topology the customer impact would be minimal as the Standby Edge does not pass customer traffic. On an Enhanced HA deployment, where the Standby Edge is also passing traffic, the reboot(s) would disrupt some customer traffic.

Field issues have involved Edge 6x0 (610, 620, 640, 680) models but the issue is platform agnostic and could occur on other Edge models.
Fixed Issue 78003: For a customer using a Hub/Spoke topology, static tunnels from the VMware SD-WAN Spoke Edge to a Hub Edge may not form.
Typically if there are a large number of Dynamic Edge-to-Edge tunnels already established on the Spoke Edge, the maximum tunnel number check is hit on the Spoke for the static tunnel, and this check prevents static tunnel formation from the Spoke to the Hub.
Fixed Issue 80551: On VMware SD-WAN Edge models which include an internal LTE modem (Edge 510-LTE and Edge 610-LTE), LTE Tunnels via an IPV6 link become UNSTABLE when the IPv6 address on the CELL interface changes.
Whenever the IPv6 address on a CELL interface changes (for example, due to a DHCP lease expiration), the IPv6 tunnels become UNSTABLE. This is because the tunnels continue to use the old IPv6 address rather than the new one.

Without the fix the only way to remediate the issue is to restart the Edge's service.
Fixed Issue 80654: For a site configured with an Enhanced High Availability topology, a user may observe intermittent traffic drops on the VMware SD-WAN Standby Edge's WAN links.
When there are frequent path flaps (paths being added and deleted frequently), under certain timing scenarios the TCP connection between the Active and Standby Edges is reset, leading to packet drops for traffic traversing a WAN link on the Standby Edge.
Fixed Issue 83432: For a site deployed with a High-Availability topology, when additional tunnels are added to the site the VMware SD-WAN Standby Edge may experience a Dataplane Service crash and generate a core.
A common way tunnels are added is by adding WAN links to the HA Edges. When the number of tunnels the Standby Edge needs to synchronize with the Active Edge exceeds 80, this triggers an exception and a Dataplane Service failure on the Standby. When this issue is encountered on a conventional HA topology the customer impact would be minimal as the Standby Edge does not pass customer traffic. On an Enhanced HA deployment, where the Standby Edge is also passing traffic, the reboot(s) would disrupt some customer traffic.
Fixed Issue 84106: A VMware SD-WAN Edge may export NetFlow statistics at the incorrect time interval which would cause the receiving systems to be out of sync.
NetFlow packets can have an additional 5 second delay from the configured interval. The is because the NetFlow exporter checks for export time once every 5 seconds only, and as a result the NetFlow packets can have a delay of 5 seconds between the configured interval and the actual export interval.

___________________________________________________________________

Resolved in Edge Version R450-20220203-GA

Edge version R450-20220203-GA was released on 02-10-2022 and addresses the below critical issues since Edge version R450-20220120-GA.

Fixed Issue 34234: A WAN link on a VMware SD-WAN Edge may show an incorrect bandwidth capacity value on the Orchestrator UI and the customer may observe the WAN link not being utilized to its actual bandwidth capacity.
With this issue the WAN link is not being remeasured for the most current bandwidth capacity value with the specified frequency. This is caused by the service resetting the date on the bandwidth value cache every time there is a tunnel tear down/bring up (i.e. flap) on the WAN link. Because the cached bandwidth value is reset the SD-WAN service is fooled into thinking this is a new value and no additional bandwidth testing is needed. In a WAN link where there are frequent tunnel flaps, this WAN link bandwidth value could be quite old and not at all representative of the current WAN link bandwidth values and this will cause customer traffic issues because the SD-WAN service will not use the WAN link to its real capacity.
Fixed Issue 53951: A VMware SD-WAN Edge may experience either a failure of traffic sent direct to the internet or a loss of connectivity to the VMware SD-WAN Orchestrator and the Edge is marked as down.
This issue can affect an Edge in one of two scenarios:
1. For an Edge which uses public WAN links, when there is a flap (link goes down and then comes up) on a WAN link, the impact to the customer in this scenario is that traffic that is steered to the affected link and is also classified as Direct is dropped. This issue is especially impactful for a site where Business Policy rules are configured to force certain traffic to use one WAN link only while also being sent Direct.
2. When enabling HA on an Edge using PPPoE WAN links, there is a change in the PPPoE interface IP and the old self route is deleted but with the new PPPoE IP address the new self route is not getting added. As a result the communication between the Orchestrator and the Edge no longer works.
Without the fix, the way to temporarily correct the issue is to either restart the Edge service to ensure Direct traffic is sent, or reboot the Edge (where PPPoE links are used) which recovers the route to the Orchestrator.
Fixed Issue 72423: VMware SD-WAN Edge goes offline on the VMware SD-WAN Orchestrator and is not accessible if the Edge's public DNS server is not Google DNS.
In this scenario, the DNS server configured for an Edge on the Orchestrator is not Google DNS, but DNS packets for specific domains (such as *.nyansa.com & *.velocloud.net) will still be sent to the Google DNS server (8.8.8.8 / 8.8.4.4). (This is an expected behavior.)

When a DNS packet is received from the kernel, it is forwarded only if the destination IP is same as that configured on the Orchestrator. If the destination IP does not match the one configured on the Orchestrator, the Edge ignores that packet. However, the Edge does not free that packet, and this causes a memory buffer leak. It is the memory buffer leak that ultimately causes the Edge to be unresponsive.

Without the fix, as a workaround, customers could ensure that Google DNS is configured as the public DNS server for all of their Edges. For an Edge in an inaccessible state, the Customer needs to reboot the Edge to recover it.

Note: This fix was included in two previous 4.5.0 builds: R450-20211007-GA-72423 and R450-20220120-GA. While the fix in those builds corrects the core issue, there is an extremely rare scenario where if a client sends traffic that is destined for a DNS server that is completely different from what the customer configured (regardless of the DNS service configured and a service other than Google DNS) that the issue could be hit even with the fix found in these builds. The fix in this R450-20220203-GA build also resolves this corner case and is to be regarded as the complete fix for 72423.
Fixed Issue 76196: A WAN link on a VMware SD-WAN Edge may show an incorrect bandwidth capacity value on the Orchestrator UI and the customer may observe the WAN link not being utilized to its actual bandwidth capacity.
WAN link bandwidth measurements have two key default behaviors related to this issue. First, if a WAN link bandwidth test result is less than 90% of the current bandwidth value, the Edge automatically triggers a second test to ensure the measurement is not an anomaly but is indeed the new lower value. Second, when a WAN link bandwidth test fails (the test does not complete due to some kind of link instability) a bandwidth test is rescheduled for a later time when the link instability has cleared.

The issue here is that if the bandwidth test fails and a new test is rescheduled for later and that test returns a result less than 90% of the current value, the Edge does NOT trigger a retest to ensure the validity of this new, lower value. The result is a potentially lower WAN link value that does not represent the real capacity of the link with resulting customer traffic issues because the SD-WAN service will treat the link as having less capacity than it actually does.
Fixed Issue 77525: For a site using a High-Availability topology, when the VMware SD-WAN HA Edges are upgraded to a new software image, the Standby may fail to upgrade and the VMware SD-WAN Orchestrator UI incorrectly lists the Standby Edge's status as 'Active' even though it is not.
When the Active Edge detects the Standby Edge it tries to fetch the Standby Edge's software version and if the version is greater than 3.4.x then the Active Edge copies the network configuration file to the Standby Edge. While fetching the Standby Edge software version, there may be an exception which is not handled by the Edge's HA code and this leads to an HA worker thread getting struck and further communication with the Standby Edge fails. At this point the management process between the Active and Standby Edge is broken and anything have to do with the management plane, including software management, Standby Edge status, and configuration changes, will not be synchronized between the Active and Standby Edge. This results in the Standby Edge being falsely detected as Active and which appears as an Active/Active "split brain" state on the Orchestrator but is not as the Standby Edge is still performing its proper role.

If there is an HA failover and the Standby Edge is promoted to Active, the Edge would be with a mismatched set of configurations and software. The Orchestrator would detect the configuration mismatch and push the updated configuration to this Edge while also completing the software upgrade the Standby Edge previously missed. And since an Edge software upgrade requires a reboot, the customer would observe another failover while the newly Active Edge was rebooted and then demoted back to Standby status.

This issue is not consistently encountered when an HA site upgrades the Edges' software. In addition, this issue can also happen when bringing up a new HA site, or when a standalone site is brought up to High-Availability, anytime the Standby Edge has to upgrade its software. But these secondary scenarios are more rare when compared with HA Edges undergo a software upgrade

Without the fix, a customer observing this issue would need to restart the Edge service or trigger an HA failover to clear the issue.
Fixed Issue 81672: A VMware SD-WAN Edge 510-LTE may experience a Dataplane Service failure after either a reboot, power cycle, or a software upgrade (which requires a reboot to complete).
When the CELL interface on an Edge 510-LTE comes up after a reboot or software upgrade, there can be a timing issue and the Edge Dataplane Service would fail and require a restart to recover. After the restart the service would operate properly.

___________________________________________________________________

Resolved in Edge Version R450-20220120-GA

Edge version R450-20220120-GA was released on 01-27-2022 and addresses the below critical issues since Edge version R450-20211007-GA-72423.

Fixed Issue 72423: VMware SD-WAN Edge goes offline on the VMware SD-WAN Orchestrator and is not accessible if the Edge's public DNS server is not Google DNS.
In this scenario, the DNS server configured for an Edge on the Orchestrator is not Google DNS, but DNS packets for specific domains (such as *.nyansa.com & *.velocloud.net) will still be sent to the Google DNS server (8.8.8.8 / 8.8.4.4). (This is an expected behavior.)

When a DNS packet is received from the kernel, it is forwarded only if the destination IP is same as that configured on the Orchestrator. If the destination IP does not match the one configured on the Orchestrator, the Edge ignores that packet. However, the Edge does not free that packet, and this causes a memory buffer leak. It is the memory buffer leak that ultimately causes the Edge to be unresponsive.

Without the fix, as a workaround, customers could ensure that Google DNS is configured as the public DNS server for all of their Edges. For an Edge in an inaccessible state, the Customer needs to reboot the Edge to recover it.

Note: While the fix in this build corrects the core issue there is an extremely rare scenario where if a client sends traffic that is destined for a DNS server that is completely different from what the customer configured (regardless of the DNS service configured and a service other than Google DNS) that the issue could be hit even with the fix found in this build. Build R450-20220203-GA also resolves this corner case and is to be regarded as the complete fix for 72423.
Fixed Issue 74313: For a customer site using an LTE model of a VMware SD-WAN Edge (in other words, the Edge 510-LTE or Edge 610-LTE), the Edge loses communication to the VMware SD-WAN Orchestrator post-reboot of the Edge if the Edge only has an LTE WAN link.
The connectivity between the Orchestrator and the Edge is lost, as the default route reachability via LTE interface becomes false after an Edge reboot. As a result the Edge will be marked as down by the Orchestrator even though customer traffic is still passing on the LTE WAN link.

Without the fix the only way to recover Edge reachability is to perform an Edge service restart.
Fixed Issue 76173: For a customer using AWS-based VMware SD-WAN Virtual Edges, when the Virtual Edge is rebooted or restarted, connected routes may be missing which will impact customer traffic.
The routes do not show n the FIB and that will significantly impact customer traffic. This is caused by a timing issue: when an AWS based Edge is rebooted or restarted and comes up, the netlink messages are coming before the interfaces are available for all the connected routes and this causes the connected routes to be missing.

Gateway Resolved Issues

Gateway version R450-20211123-GA-74198-70416-74482-30022

Gateway version R450-20211123-GA-74198-70416-74482-30022 was released on 11-29-2021.This Gateway build adds no new fixed issues since Gateway version R450-20211104-GA-74198-70416-74482, but does contain troubleshooting changes required by VMware Engineering.

___________________________________________________________________

Resolved in Gateway Version R450-20211104-GA-74198-70416-74482

Gateway version R450-20211104-GA-74198-70416-74482 was released on 11-08-2021 and addresses the below critical issue since Gateway version R450-20211029-GA-74198-70416.

Fixed Issue 74482: For a customer using a Hub-Spoke network topology, the route from a VMware SD-WAN Spoke Edge is not learned on a Hub Edge if that Hub Edge is also a Spoke for a different Hub Edge.
For this issue to hit, the customer would also have Edge to Edge via Hub configured. When customer deployments have an Edge that is deployed as a Hub for certain Spokes and as a Spoke for certain Hubs, such Edges do not receive the Spoke routes from the VMware SD-WAN Gateway. This issue has a major impact on a network with this topology because of the missing routes.

Without this fix, the only way to prevent this issue is to disable Edge to Edge via Hub on the Spoke Edges.

__________________________________________

Resolved in Gateway Version R450-20211029-GA-74198-70416

Gateway version R450-20211029-GA-74198-70416 was released on 10-30-2021 and addresses the below critical issue since Gateway version R450-20211022-GA-74198.

Fixed Issue 70416: Customers connected to a particular VMware SD-WAN Gateway may observe suddenly high levels of packet loss and latency for all users. An Operator user would observe that the Gateway causing these issues would show a spike in CPU load followed by a spike in handoff queue drops.
When this issue is being observed on a Gateway, Engineering observed an issue with identified fast path threads (IKE, VCMP Data, and similar) spending between 15-20% of their cycles doing inet_ntop operations which caused the spike in CPU load and handoff queue drops. To prevent this issue from recurring, the API calls causing this issue have been replaced with an improved data formatting for log commands.

__________________________________________

Resolved in Gateway Version R450-20211022-GA-74198

Gateway version R450-20211022-GA-74198 was released on 10-23-2021 and addresses the below critical issue since Gateway version R450-20210922-GA.

Fixed Issue 74198: If a customer has deployed a Non SD-WAN Destination (NSD) via Gateway which has multiple tunnels to the same destination IP address on a single segment, the tunnels will all appear as "up" on the VMware SD-WAN Orchestrator, but only one of the tunnels will actually pass traffic.
There is an improper uniqueness check applied to routes being advertised for VMware Non SD-WAN Destinations (NSD) via Gateway. A common example of an error state is a customer who has, for instance, two tunnels from the same VMware SD-WAN Gateway to the same Zscaler IP address for load balancing purposes. With this issue, both tunnels will appear stable in the Orchestrator but only one will pass traffic and the other will simply black hole all traffic (in other words, discard all traffic without informing the source this traffic did not reach its intended recipient). This only affects NSD's using a Gateway with Release 4.4.0 or 4.5.0.

If using Gateways with an earlier build, the workaround for this issue is to use different destination IPs (for example, different Zscaler IP addresses) to facilitate load balancing.

Edge Resolved Issue

Resolved in Edge Version R450-20211007-GA-72423

Edge version R450-20211007-GA-72423 was released on 10-08-2021 and addresses the below critical issues since Edge version R450-20210922-GA

Fixed Issue 72423: VMware SD-WAN Edge goes offline on the VMware SD-WAN Orchestrator and is not accessible if the Edge's public DNS server is not Google DNS.
In this scenario, the DNS server configured for an Edge on the Orchestrator is not Google DNS, but DNS packets for specific domains (such as *.nyansa.com & *.velocloud.net) will still be sent to the Google DNS server (8.8.8.8 / 8.8.4.4). (This is an expected behavior.)

When a DNS packet is received from the kernel, it is forwarded only if the destination IP is same as that configured on the Orchestrator. If the destination IP does not match the one configured on the Orchestrator, the Edge ignores that packet. However, the Edge does not free that packet, and this causes a memory buffer leak. It is the memory buffer leak that ultimately causes the Edge to be unresponsive.

Without the fix, as a workaround, customers could ensure that Google DNS is configured as the public DNS server for all of their Edges. For an Edge in an inaccessible state, the Customer needs to reboot the Edge to recover it.

Note: While the fix in this build corrects the core issue there is an extremely rare scenario where if a client sends traffic that is destined for a DNS server that is completely different from what the customer configured (regardless of the DNS service configured and a service other than Google DNS) that the issue could be hit even with the fix found in this build. Build R450-20220203-GA also resolves this corner case and is to be regarded as the complete fix for 72423.

Edge/Gateway Resolved Issues

Resolved in Edge/Gateway Version R450-20210922-GA

The below issues have been resolved since Edge versions R430-20210702-GA-61583 and R440-20210702-GA-61583, and Gateway version R430-20210727-GA-65293-67191.

Fixed Issue 37813: For a customer site using an Enhanced High-Availability topology, when running the Remote Diagnostic "Interface Status", the interfaces for the Standby Edge do not show speed and auto-negotiation.
The VMware SD-WAN Edge in Active role does not fetch the speed and auto-negotiation details from the Standby Edge where the interface is up, so the details cannot be displayed.
Fixed Issue 43005: A VMware SD-WAN Edge may not transmit Tx and/or receive Rx packets but the interface status will still show the link as up and connected even though traffic is not passing.
On the Edge's NIC chip, the Tx/Rx hardware module may get into a hung state and this causes the Tx/Rx packets to no longer send/receive and causes customer traffic to stop passing. An Edge in this state would, for example have the dispcnt show the sfp2_l2_dropped counter incrementing and the Tx counter unchanged:
```
dpdk_sfp2_l2_dropped = 199042 71 /s
dpdk_sfp2_l2_tx = 36801627105 71 /s
```
The resolution for this issue is the implementation of Tx hang detection and recovery across all Edge models. This feature monitors hardware stalls and attempts a recovery VMware initially introduced TX hang detection and recovery for the Intel 82599 NIC, which is used on some virtual Edge deployments.

On an interface which uses Tx stall monitoring, the following log line would be observed at Initialization:
```
2021-05-24T23:45:14.287 MSG [NET] dpdk_parse_interface:773 DPDK intf sfp2, driver ixgbe,
 mac ac:1f:6b:2d:d2:0a, pci 0000:02:00.0, tx_stall_monitor 1
```
When a Tx stall is detected and the interface is recovered, a user would observe a log line similar to below:
```
2021-05-20T20:09:05.644 ERR [NET] dpdk_tx_stall_check_and_recovery:1545 TX stall count : 1, on dpdk intf:sfp2 ,port: 0
2021-05-20T20:09:06.644 ERR [NET] dpdk_tx_stall_check_and_recovery:1545 TX stall count : 2, on dpdk intf:sfp2 ,port: 0
...
2021-05-20T20:09:23.647 ERR [NET] dpdk_tx_stall_check_and_recovery:1545 TX stall count : 19, on dpdk intf:sfp2 ,port: 0
2021-05-20T20:09:24.647 ERR [NET] dpdk_tx_stall_check_and_recovery:1545 TX stall count : 20, on dpdk intf:sfp2 ,port: 0
2021-05-20T20:09:24.647 ERR [NET] dpdk_tx_stall_recover:1499 Starting TX stall recovery on dpdk intf:sfp2 ,port: 0
2021-05-20T20:09:37.027 ERR [NET] dpdk_tx_stall_recover:1528 Completed TX stall recovery on dpdk intf:sfp2 ,port: 0
```
Fixed Issue 43278: If a user configures an outbound BGP filter to match the default route or prefix, and then sets an AS Path prepend, the default route or prefix is advertised to the BGP neighbor, but no AS Path prepend occurs.
A BGP outbound neighbor filter set to match a prefix and set AS Path prepend does not work on any prefixes originated by using the BGP Advanced configuration "Networks" statement. This also does not work for a default route originated to a neighbor via the neighbor "DR Originate", via the BGP Advanced "Conditional" Default Route Advertise check box.

Also when using a static route configuration configuration on the VMware SD-WAN Edge, neither a default route or a non-DR static route set to "Advertise" would be advertised to a BGP neighbor with the AS Path prepended; the only AS in the prefix is the Edge's own AS.
Fixed Issue 44526: For an enterprise where two different sites deploy their VMware SD-WAN Edges as Hubs while also using a high-availability topology, and each site uses the other Hub site as a Hub in its profile. If one of the Hub sites triggers an HA failover, it may take up to 30 minutes for both Hub Edges to reestablish tunnels with each other.
On an HA failover, both Hub Edges try to initiate a tunnel with each other at the same time and neither replies to the peer, the packet exchange between both Hubs occurs, but IKE never succeeds. This leads to a deadlock that has been observed to take up to 30 minutes to resolve on its own. The issue is intermittent and does not occur after every HA failover.

Without this fix the only way to prevent this issue from occurring is to use a workaround where the customer configures only one of the two HA Hub sites to use the other Hub site as a Hub for itself. For example, where there are two HA Hub sites, Hub1 and Hub2, Hub1 could have Hub2 as a Hub for itself in its profile, but Hub2 must not use Hub1 as a Hub in its profile.
Fixed Issue 46489: If different Partner Gateway enabled profiles are assigned to multiple VMware SD-WAN Edges, the Edges will retain stale routing entries for the VMware SD-WAN Partner Gateways not assigned in their profile.
If different Partner Gateway enabled profiles are assigned to multiple Edges, the Edge keeps the routing entries which are learned from other Gateways, and those routes are considered stale entries. The customer impact is traffic not being routed correctly because the Edge is trying to send traffic to invalid routes for that profile.
Fixed 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.
The bug concerns with indeterministic route order when the same prefix is received as Unsecure PG route, Underlay route and Overlay Route. There is no direct Preference comparison between Dynamic Overlay/Underlay and PG static routes. This results in same route being stored in different order in FIB, depending upon the order in which route add is received in Edge.
Go to /etc/config/edged and /etc/config/gatewayd, enable legacy_sort_pg_static_pref to 1 and then non-secure PG static route will always be preferred over Dynamic Underlay/overlay route. Thus making the fib route order deterministic.
Fixed Issue 48105: A VMware SD-WAN Gateway may get into a hung state and not complete a reboot when encountering certain kernel panics.
The impact is significant because a user must intervene to reboot the Gateway if it is hung. By default a kernel panic should cause an immediate reboot, but some kernel panics were not triggering the reboot by default.
Fixed Issue 48209: A VMware SD-WAN running a 3.x release cannot establish a tunnel with a VMware SD-WAN Gateway or Hub Edge that is using a 4.x release in certificate mode when Certificate Authority (CA) certificate chain is longer than two.
User would observe tunnels from the Edge failing with a ERR_CERT_INVALID_PARENT_CERTIFICATE error. The problem is related to certificate chain handling. The Mocana library assumes when a certificate chain is received each issuer’s certificate should follow to each other but in some cases the VMware SD-WAN Orchestrator pushes a CA certificate chain which does not match to this rule.

Without the fix, the workaround is to limit the CA certificate chain by two certificates, which always will match to rule.
Fixed Issue 48958: A VMware SD-WAN Gateway may lose connectivity on a bonded interface.
When the VeloCloud Management Protocol (VCMP) and the WAN port are set to use the same port, the Partner Gateway VLAN handoff configuration may cause the Gateway to go offline due to ARP resolutions failing. With this fix, when VCMP and the WAN port are the same, the VLAN handoff configuration from the VMware SD-WAN Orchestrator will be rejected in the Gateway. Without the fix, the workaround is to not assign the same port for VCMP and WAN.
Fixed Issue 48593: Packets from a VMware Non SD-WAN Destination (NSD) or a Cloud Security Service (CSS) may be sent without encryption.
During the link selection, if the secured socket is not available, packets are sent by whatever link is available. The fix ensures that if a secure socket is not available, NSD and CSS packets should be dropped.
Fixed Issue 50422: Peer MAC address may be learned incorrectly via ARP when using VLAN tagged routed interfaces.
If you have a VLAN tag assigned to a routed interface and the next hop sends untagged ARP requests, it will cause the untagged MAC to be learned and can cause traffic to black hole depending on which entry is learned first.

Without this fix, the only workaround is to filter out untagged ARP requests from the next hop if you have a VLAN tag on the routed interface.
Fixed Issue 51428: Multicast traffic loss may be observed on a site where the VMware SD-WAN Edge has a sub-interface configured with PIM.
When a sub-interface configured with PIM is moved from a segment to another on the fly, pimd (the process that manages PIM) may restart and the site would experience intermittent multicast traffic loss.

Without the fix, the workaround for this issue is to disable the sub-interface first, and then move the sub-interface to another segment. Once moved, re-enable the sub-interface.
Fixed Issue 52031: DHCPv6 information request message is not sent in stateless DHCPv6 mode when the router advertisement message is received with other configuration flag set.
If the interface on a VMware SD-WAN Edge is configured with stateless DHCPv6 mode, when it is receiving a router advertisement message with other configuration flag set on that interface, it is expected to send a DHCPv6 Information request message to get additional information, such as the DNS server. But the DHCPv6 information request message is not sent to the DHCP server.
Fixed Issue 52419: The IPv6 address valid time is updated when a Router Advertisement (RA) is received with a non-zero timer.
This behavior is not in compliance with RFC 4862 for updating a valid lifetime timer. Per the RFC:
1. If the received Valid Lifetime is greater than 2 hours or greater than RemainingLifetime, set the valid lifetime of the corresponding address to the advertised Valid Lifetime.
2. If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated (e.g., via Secure Neighbor Discovery [RFC3971]). If the Router Advertisement was authenticated, the valid lifetime of the corresponding address should be set to the Valid Lifetime in the received option.
3. Otherwise, reset the valid lifetime of the corresponding address to 2 hours.
The issue stemmed from RA handling being done by the VMware SD-WAN Edge's kernel, and this task is now moved to the Edge's Dataplane process, ensuring full compliance.
Fixed Issue 54022: Firewall related error logs flood in continuously in a VMware SD-WAN Edge's logs when a USB modem is plugged in.
On plugging the USB modem to an Edge, firewall related error logs flood in the edged logs which impairs a user's ability to see genuine firewall incidents.
Fixed Issue 54157: User may observe traffic drop on a VMware SD-WAN Gateway for the traffic from a datacenter server to a legacy client advertised through BGP over IPsec from Gateway.
In Release 4.4.x and earlier, it is not possible to distribute provider edge (PE) bound legacy routes to a Non SD-WAN Destination (NDS) via Gateway and NSD routes to the PE. Release 4.5.0 provides the data pipeline support between PE-bound destinations and a NSD via Gateway. This also includes route redistribution facility between PG-BGP and NSD-BGP.
Fixed Issue 54378: IPv6 static address enabled interface Duplicate Address Detection (DAD) check fails due to (Neighbor Advertisement) NA drops.
Static address DAD check will not happen. If there is a duplicate address in the network for configured static address then that will not be detected.
Fixed Issue 54536: Duplicate Address Detection (DAD) check does not occur after a VMware SD-WAN Edge reboot.
DAD check not triggered after Edge reboot. If there is a duplicate address in the network then that would not be detected.
Fixed Issue 54687: DHCPv6 solicit message is not sent by a VMware SD-WAN Edge after the server provides a configuration with a T1 value greater than T2.
If a DHCPv6 server initially provides a T1 value greater than T2, then the Edge doesn't accept the provided prefix, but even after this configuration has been corrected on the server, the Edge does not send a DHCPv6 solicit message after three attempts until the Edge Dataplane Service is restarted.
Fixed Issue 54731: Renew messages are sent with a high frequency until the rebind time (t2) is reached when a user changes the value of the IPv6 address range in the server.
When an IP address which has been assigned to a VMware SD-WAN Edge is removed from the valid range of addresses provided by a server, the client keeps sending renew messages to the server until T2 time is reached. This may result in a customer user observing a large quantity of DHCPv6 traffic.
Fixed Issue 54846: VMware SD-WAN SNMP MIBs use counters for Jitter, Latency, and Packet Loss.
In VMware SNMP MIBs, Latency, Jitter, and Packet Loss are defined as Counter64 which is not appropriate for these types. Counters should be used for data types that are ever increasing values and which never reset in SNMP like bytes Tx/Rx. In contrast, latency, jitter, and packet loss do not have ever increasing values but dynamically adjusted values and should not use counters.
Fixed Issue 56218: For a customer site deployed with a High-Availability topology or where HA has just been enabled, when the Edges are upgrade from 3.2.x to 3.4.x, the Standby Edge may go down.
When HA is enabled or the HA Edges are upgraded from 3.2.2 to 3.4.x after a WAN setting is configured using the Local UI, the HA interface (e.g. LAN1 or GE1 depending on the Edge model) will be removed from the Standby Edge and HA status will be set to HA_FAILED on the VMware SD-WAN Orchestrator.
Fixed Issue 56454: Configure both IPv4 and IPv6 links as auto-discovered links on an interface and then have tunnels formed through the non-preferred link as well. The link stats do not display consolidated information of a IPv4 and IPv6 link.
When an interface has both IPv4 and IPv6 overlays configured as auto-discovered overlays and tunnels formed over both links, the links stats reflect only the status of the preferred link. The traffic information or the status of the non-preferred link is not correctly reflected. As a result, the statistics seen for the link on the Edge > Monitoring page which include the bandwidth and throughput should be used as a guideline to measure the performance of the tunnels formed over the preferred IP address family only.
Fixed Issue 58259: In some cases a customer may observe a VMware Non SD-WAN Destination tunnel down on the Gateway side with a Zscaler peer.
There are some cases when the Zscaler peer end deletes Phase 2 security association (SA) but the VMware SD-WAN Gateway still retains the SA. In these cases the tunnel will be torn down, and the customer will not be able to pass traffic.

Without the fix, the workaround is a phase2_sa_check.py script which walks over the Phase 2 SA table and checks if there is Phase 2 SA for which Phase1 SA is missing. If it finds one then the Gateway reestablishes the tunnel.
Fixed Issue 58453: Some Office365 packets are misclassified as SSL packets by the VMware SD-WAN Edge.
The VMware SD-WAN Deep Packet Inspection (DPI) engine is sometimes misclassifying packets that should be classified as Office365 as SSL instead. The impact is that these flows will be treated as SSL flows versus Office365 flows and that may mean they are treated with less priority, impacting the user experience.
Fixed Issue 58791: A site deployed with a High-Availability topology where BGP is used may encounter an issue where the VMware SD-WAN Edge repeatedly fails over.
This issue affects HA sites configured within a Hub/Spoke topology where the HA site has greater than 512 BGPv4 filter prefixes configured.

When BGP is used with multiple network commands configured and while the Standby Edge is coming up it parses the all configurations symmetrically and for every network command vtysh is spawned and as a result this is causing the verp thread to not run. The verp thread being delayed results in a delay in heartbeat processing which causes the Standby Edge to believe the Active Edge is down and the Standby Edge then becomes active which leads to a split-brain state (active-active). To recover from the split-brain state, the Standby Edge restarts which merely repeats the cycle.

Without the fix the workaround is to reduce the number of BGP filter prefix configurations by aggregating them and getting the total number below 512 (256 Inbound, and 256 Outbound filters).

Note: A previous version of this ticket description stated this was also a fix for HA sites with BGP match and set operations. That part of the issue is not fixed with this ticket and is tracked with Issue #84825.
Fixed Issue 59236: For sites using an Enhanced High-Availability topology, tunnels are not formed if the WAN link connected to the Standby Edge is a Metanoia SFP and this behavior persists even after an HA failover.
For Enhanced HA, the WAN ports are blocked on the Standby Edge (in other words, the Edge does not allow TX on its WAN interfaces). In order to bring up a Metanoia SFP interface, there is a packet exchange needed between the hardware. As the Edge does not allow TX, the interface initialization does not succeed.
Fixed Issue 59629: On a customer site deployed with a High-Availability topology, the user may observe the VMware SD-WAN Standby Edge restarting multiple times.
Both the Active and Standby Edge miss their HA heartbeat and both Edges become Active/Active (also known as "Split Brain"). To break the tie, the newly promoted Active Edge (the previous Standby Edge) will undergo a restart with a logging event: "Active/Active Panic". The fix for this issue involves promoting the priority of the HA Edge heartbeat thread so as to minimize the delay in processing the heartbeats which can be viewed as missed heartbeats causing the Active/Active state.
Fixed Issue 60010: For a site using VMware SD-WAN Edges with VNF deployed in a High-Availability topology, the VNF on the Standby Edge is not accessible via SSH after a LAN-side port flap.
The LAN side interface on the Standby VNF is in normally in a disabled state. Due to the LAN-side port flap, it moves to a forwarding state which results in a wrong MAC address port mapping on the bridge interface which results in inaccessibility of the VNF.
Fixed Issue 60073: DNS packets via a VMware SD-WAN Edge's PPPoE interface are not processed.
The DNS packets if traversed via Edge's PPPoE interface are not processed and dropped. Due to this the DNS over PPPoE functionality is impacted and customer would observer, for example, issues such as CSS tunnels not coming after an upgrade to Release 4.2.0 or later.
Fixed Issue 60097: A VMware SD-WAN Edge model 510 has lower maximum throughput performance due to not having DPDK support.
The Edge 510's lower performance resulting from kernel-bound interfaces and opened raw sockets for ingress/egress of Edge packets. This is resolved by having the Edge 510 included in the set of DPDK supported platforms. Throughput changes tested and observed as follows:

Before DPDK support: IMIX 400 = 130 Mbps; 1300 byte packets = 360 Mbps.
After DPDK support: IMIX 400 = 250 Mbps; 1300 byte packets = 600 Mbps.
Fixed Issue 60184: A Branch VMware SD-WAN Edge installs routes marked with uplink community from a non-profile Hub Edge (Dynamic Branch-to-Branch) and prefers these routes before everything else.
The non-profile Hub Edge is treated as a Branch Edge when Dynamic Branch-to-Branch is used. So, when there is a dynamic tunnel bring-up, the issue occurs as described. The only workaround is to add Hubs to all profiles but this cannot scale on larger networks where there are 20+ Hub Edges due to the enormous number of routes that would be created.
Fixed Issue 60367: Stateful Firewall rules do not drop the first packet in a flow going to a VMware SD-WAN Edge IP even with a VLAN-specific drop rule in place.
Sending a ping to and Edge's VLAN IP is successful even with VLAN-specific Stateful Firewall drop rules. With VLAN specific Stateful Firewall Drop rules, the behavior is not consistent between ping to a VLAN host and the VLAN IP of the Edge. Ping to a VLAN IP of the Edge is successful. The fix disallows ping to either the Edge VLAN-IP or VLAN host.
Fixed Issue 60570: Path status may display the incorrect status when using the New UI on the VMWare SD-WAN Orchestrator,
This is a display issue only and does not affect actual customer traffic. And example of this issue is the New UI showing a path as dead when an Edge diagnostic bundle log would show the path as stable.
Fixed Issue 61344: When a VMware SD-WAN Edge has >180Mbps traffic flowing through it, there will be slowness experienced in the next new traffic initiated through the Edge.
When >180Mbps traffic is flowing through an Edge, new traffic is buffered at the VMware SD-WAN Gateway and is not processed by the Gateway in the expected time and thus the traffic experiences latency.
Fixed Issue 61361: When applying a software update to upgrade a VMware SD-WAN Edge 3400, 3800 and 3810 to Edge Release 3.4.5, 4.0.2, or 4.2.1, there is a change the Edge models may not boot back up immediately after the update.
Release 3.4.5, 4.0.2, and 4.2.1 include a particular firmware update for the complex programmable logic device (CPLD), and the update triggers a reboot that can sometimes get "stuck", requiring a manual power cycle to restart the system.

Without the fix, a local user needs to manually power cycle the Edge to complete the update.
Fixed Issue 61502: During activation of a VMware SD-WAN Edge, the download of the new software image to be applied is delayed indefinitely.
In an environment with unreliable network connectivity, or certain types of traffic throttling, the HTTPS download of the new software image can get stuck. Without this fix, should this scenario happen, please power cycle the Edge and wait for a couple of minutes. The download should restart automatically, though it will restart all the way from the beginning.
Fixed Issue 61583: If a customer enables High Availability for a site, the VMware SD-WAN Edge will go offline and the site goes down and all customer traffic is disrupted.
When HA is enabled, the Edge will at a minimum go offline for ~5 minutes with customer traffic disrupted during that period. The Edge may be able to roll back to the previous configuration and resume operation after that ~5 minute period, though that Edge would continue to operate as a standalone with HA not possible. However, if the Edge does not successfully roll back to the last configuration, then it will stay down until a local user performs a factory reset followed by an RMA Reactivation (with HA not enabled) to restore connectivity at that site.

For more information please consult the KB article Enabling High Availability on a VMware SD-WAN Edge using Release 4.3.0 GA or 4.4.0 GA may cause the Edge to go offline. (84396)
Fixed Issue 61596: There is a performance degradation when Partner BGP is enabled with secure option and a static route is configured as unsecure, or vice versa.
The performance degradation is caused by a miscalculation of IP address maximum length when an unsecure static route picks up the secure flag from a BGP configuration. Initially the VMware SD-WAN Gateway does a route lookup and if it finds an insecure static route, the Gateway then checks if the BGP is enabled or not. If BGP is enabled, the Gateway checks to see the encryption set and then picks up the encryption set for BGP which is secure, and then fragmentation happens because the secure option is more conservative than insecure.
Fixed Issue 61622: Google Drive traffic is misidentified as "Other TCP/UDP" or as "APP_UNKNOWN".
This traffic should be identified as "Google Documents (aka Google Drive)". The issue is caused by the Deep Packet Inspection (DPI) engine not having the most up-to-date subnets/ports for Google Drive.
Fixed Issue 61625: A VMware SD-WAN Hub Edge does not advertise all routes if there are more than ~250 routes to be advertised on OSPF.
Whatever the number of routes, whether it is 300 or 2000 or more, only ~250 routes will show as advertised and the remainder will have their advertise flag set to FALSE. This is due to a delay in processing routes beyond that ~250 amount and is resolved by processing a much smaller batch of routes per request.
Fixed Issue 61725: For a site using a High-Availability topology where USB WAN links are used, running the Remote Diagnostic "HA Info" will result in errors.
When a USB/LTE modem is present or was previously present only on the VMware SD-WAN Active Edge and not on the Standby Edge, The Active Edge tries to fetch USB/LTE interface details on the Standby Edge and the result is the Edge throws an error since the USB/LTE interface is not present on the Standby Edge.
Fixed Issue 61759: ISP name and Bandwidth are shown as empty on the VMware SD-WAN Edge Local UI (Overview page and Routed Interface Properties page).
If a routed interface has more than one overlay the local UI is expected to show the details of the interface which has the latest "last active" value (since it is designed to show details of only one). When user opens the Local UI Overview/Details page, the bandwidth and ISP values for routed interfaces with multiple overlays is shown as empty instead.
Fixed Issue 62197: A VMware SD-WAN Gateway may restart its Dataplane Service.
The Gateway encounters a memory leak which occurs while syncing routes from itself to the VMware SD-WAN Orchestrator. When memory consumption reaches critical levels, the Gateway's dataplane service restarts to clear the memory, causing a brief disruption in customer traffic using the Gateway.
Fixed Issue 62280: The VMware SD-WAN Edge's LAN subinteface is not showing in a traceroute from a routed host to a client connected through Edge-to-Edge.
When the traceroute is done from a host (not directly connected to the Edge), to a client in an Edge-to-Edge topology, the Edge's interface IP is not displayed in the o/p. This happens only when a VMware SD-WAN Gateway configuration is not done on the Edge interface on the path to the host.

Without the fix, the only workaround is to enable the Gateway configuration on the Edge interface connecting to that traceroute host.
Fixed Issue 62373: When bringing up a High-Availability site configured for a unique MAC address, the vMAC is programmed from a routed interface to a switched interface.
The unique MAC address will not be programmed for the HA Edge when the interface type is changed from a WAN interface to a Switched interface and this leads to traffic loss.

Without the fix, the workaround to resolve this issue is to restart the HA Edges, which will program the proper MAC on the now switched interface.
Fixed Issue 62552: A site may experience intermittent periods of high packet loss and connectivity issues.
This is caused by the API that checks for ARP resolution telling the Edge there is a successful ARP resolution for a device while delivering a MAC address of 00:00:00:00. This address is kept in the ARP cache and any packets intended for the device where the MAC is listed as zero are dropped. In this issue, many such instances of successful ARP's with zero MAC addresses are delivered causing high packet loss and connectivity issues.

Note: There is a previous issue 60130 with the same underlying behavior and cause but which includes a different resolution from 62552. With 60130, the resolution was a defensive workaround, while 62552 includes a complete fix that prevents any recurrence of this issue.
Fixed Issue 62620: On a site deployed with a High Availability topology, direct traffic to some of the destinations might stop working after HA failover.
The flows from the Active VMware SD-WAN Edge are synced to the Standby Edge along with the port allocated for the NAT entry so that when there is a failover, there is no disruption to traffic after failover. The port allocated on the Standby Edge is never freed even after the flow expires. So when there is a failover, there is a possibility of NAT port exhaustion and NAT failure. As a result, packets can get dropped in the Edge.
Fixed Issue 62685: If LAN side NAT is configured with the same outside IP for different LAN subnets with NAT type as source, traffic destined for the Cloud will not work.
For the outside IP used in LAN side NAT rules, we configure a static route and advertise it to the remote branches. For the return traffic to be routed to the correct the LAN subnet, route lookup should be done based on the Inside IP configured in the LAN side NAT rule instead of the next hop in the static route. But for the return traffic from cloud, the route lookup is done based on the next hop in the static route and traffic can get routed to the wrong LAN subnet.
Fixed Issue 62725: A VMware SD-WAN Edge in a network which uses BGP may experience high memory usage under certain rare conditions.
If an Edge learns a BGP route with a next hop IP address which is different from the peer IP address, the next hop will be tracked for reachability by the Edge's Next Hop Tracking (NHT) module. If BGP is then disabled when the tracked IP address is unreachable on the Edge, the tracked NHT entry may not get deleted. In rare cases where there are a lot of stale NHT entries, high Edge memory usage can be seen.

Without the fix, the only way to remediate the issue is to reboot the Edge to delete the memory leaking NHT entries.
Fixed Issue 62736: On a hardware-based VMware SD-WAN Edge, when user is accessing the Local User Interface, on the routed interface properties page of the Local UI, for PPPoE interfaces, the MAC address field is shown as empty and the IP address field shown is wrong.
Starting release 4.3.x, interface details in Local UI are being fetched from NETLINK events instead of constantly polling for updates. Since PPPoE interfaces themselves interfaces do not have MAC addresses (base interfaces do), the MAC address is shown as empty. Also, a wrong parameter of NETLINK was being used to report the IP address (IFA_ADDRESS instead of IFA_LOCAL). DHCP/Static interfaces do not have this issue as the value of both fields are the same for them.
Fixed Issue 62890: Application IDs are different when viewing statistics in Edge Network Intelligence and the VMware SD-WAN Orchestrator.
There are two different ways that applications are learned:
1. On the first packet, via a database of well-known SaaS applications IP addresses and ports (e.g. Office 365), or by learning the IP of an application the Orchestrator had previously learned.
2. After a series of packets are analyzed using deep packet inspection (DPI).

The Edge Network Intelligence Application IDs were not being updated by #2. That means that first-packet applications like Office365 are visible, but applications that require DPI (e.g. AnyDesk) are seen in the Orchestrator but not Edge Network Intelligence.
Fixed Issue 62897: If an Operator User logs into a VMware SD-WAN Gateway and runs the tcpdump command on either eth0 or eth1, the results are not delivered correctly.
tcpdump is a critical Gateway debugging command for Operators and a lack of correct output greatly impairs their efforts. There is a way to get the correct output without the fix, which is to use a command which pipes tcdump output to cat, for example: tcpdump -nnplei eth0 | cat
Fixed Issue 63056: A VMware SD-WAN Edge may encounter a kernel panic with a resulting reboot and core.
The mutex mon process fails with SIGXCPU and a core is triggered. Allowing all threads to use both cores is the fix along with moving the Edge Dataplane Service < > frr communication to Unix Domain sockets which gains all the benefits of TCP sockets without the heavy kernel overhead and better performance.
Fixed Issue 63141: For a site using an Enhanced High-Availability topology where Metonia ADSL2+ SFP modules are being used, on a failover the ADSL2+ SFP modules fail to come up.
When an Enhanced HA Edge fails over or if the network is restarted, an Edge with an ADSL2+ configuration fails to come up.
Fixed Issue 63359: For a site configured with a High-Availability topology and OSPF and where the VMware SD-WAN Edges are using a MGMT IP Edge build, when these Edges are upgraded from a 3.4.x to a 4.2.x MGMT-IP build, OSPF connectivity may be broken post-upgrade.
When the HA Edges are upgraded to a 4.2.x MGMT IP build, the HA systems may define its Router ID as 169.254.2.2. This is not the expected behavior given that the Edge selection of Router ID should not take the HA interface's IP Address into account. This Router ID breaks OSPF connectivity and there is a complete disconnection as route exchange no longer occurs.

Without the fix, the only workaround is to restart the Edge service (triggering an HA failover) as this will force a reselection of the Router ID which should be a correct one after the restart.
Fixed Issue 63362: For a site using an Enhanced High-Availability Topology, a DHCP/PPPoE enabled interface stops sending traffic after the Standby Edge is either rebooted, or power cycled.
In an Enhanced HA topology if DHCP/PPPoE is enabled on a proxy interface (in other words, the HA link state is set to USE_PEER) it fails to get an address from the server after the Standby Edge either reboots or power cycles.

Without the fix, the only workaround is to either change the dynamic address to a static address type or do a forced HA failover to get an IP address from the server.
Fixed Issue 63513: For a customer using Edge Network Intelligence, the software version displayed for the VMware SD-WAN Edge is not updated after an Edge software upgrade.
The Edge has in fact upgraded to the latest Edge Network Intelligence version, but the Edge communicates the older version number to the VMware SD-WAN Orchestrator and this is what the customer observes. The customer encounters the issue after upgrading an Edge. After the Edge is upgraded from an older to a newer release, the customer continues to see the older release version for Edge Network Intelligence.
Fixed Issue 63640: For a customer using IPv4/IPv6 dual stack on a WAN overlay, the WAN link will show an incorrect MTU value.
In the case of dual stack WAN overlay, if the MTU is changed for a IPv4 link and then the preference is changed to IPv6, the same IPv4 MTU is applied to the IPv6 link and this causes the MTU value discrepancy.
Fixed Issue 64184: When a user enables High-Availability on a site using two VMware SD-WAN Hardware Edges, the user may observe that when the point of upgrading the software of the Standby Edge is reached the upgrade for the Edge does not occur and the Standby Edge remains in an inactive state.
This issue happens rarely under the above conditions, but when it does occur the cause of the issue is, after HA is enabled, an HA worker thread is ended on the Active Edge during the action of invoking the Standby Edge image upgrade. Ending this HA worker thread leads to the Standby Edge being in an inactive state.
Fixed Issue 64205: User will observe a high number of handoff queue drops of VCMP Data for a VMware SD-WAN Gateway, leading to a poor user experience.
When there are continuous flow create events, the packet processing on VCMP (VeloCloud Management Protocol) Data thread gets slower. This fix reduces the VCMP Data thread load by redirecting VCMP Control messages to a different thread and by eliminating some of the continuous log messages.
Fixed Issue 64713: For a customer site that uses an Enhanced High-Availability topology, if a user restarts the Edge service or makes a configuration change that results in the Edge service restarting, the customer may observe that the restart takes much longer than expected before the Edge recovers.
When this issue occurs, there is a race condition between the Edge process and other competing processes that results in the delay in starting up. In the diagnostic bundle logs, the user would see a line with the phrase "FATAL: Cannot get hugepage information".
Fixed Issue 64736: DHCPv6 IP addresses may not get flushed from a VMware SD-WAN Edge interface after configuring the interface from routed to switched.
When an interface is converted from routed to switched, the IPv6 IP addresses should be flushed from the interface because IPv6 is not supported on the LAN. But in some instances, the IPv6 IP addresses are not getting flushed post-conversion to switched. These IP addresses even persist if the interface is bounced. The issue does not occur every time an interface is converted.

Without the fix, the only remediation is to reboot the Edge to clear the IPv6 IP addresses from the newly converted switched interface.
Fixed Issue 64961: A VMware SD-WAN Edge may experience a Dataplane Service Failure and restart that service if processing IP packets that include options.
The processing of IP packets with options, could result in a Dataplane Service Failure due to incorrect parsing of the options fields (the parsing continues beyond the end of the options list). The Dataplane Service failure is triggered by mutex mon. Without this fix, the only way to minimize the risk of this issue is to avoid setting options other than Record Route (RR) and No Option (NOP) in the user-traffic IP packets.
Fixed Issue 65037: A HTTPS/SSL connection may fail to establish because of a corrupt certificate if the certificate has special characters or spaces in the SSL common name field.
The VMware SD-WAN Edge inspects all user traffic passing through it so that it may identify the application to which the traffic belongs. It is needed for correctly applying business policies and also for the VMware SD-WAN Orchestrator to display per-application statistics on the Edge's Monitoring page. However an issue in the application identification code caused a byte in the SSL common name to be overwritten in case the SSL common name had special characters or spaces and thereby corrupting it.
Fixed Issue 65219: A KVM SR-IOV type VMware SD-WAN Gateway using a i40evf driver drops customer packets of 1500 bytes or greater.
Anything less than 1496B data size will not be dropped. If a user attempts to SSH into the Gateway host, the user will observe a hang based on the condition described.
Fixed Issue 65293: The throughput performance of a VMware SD-WAN Gateway deployed in AWS and running with Amazon's Elastic Network Adapter (ENA) driver is degraded when using Release 4.x.
This issue will occur if the Gateway is upgraded to a 4.x build (from 3.x) or on a new deployment using a 4.x build. Gateways using Release 4.0.0 or later have DPDK v19.11, and starting from DPDK v19.02, Amazon's ENA driver uses low-latency queuing (LLQ). However, for LLQ to work efficiently the write-combine for memory setting must be enabled per the ENA reference guide. If memory mapping is not write-combined, a Gateway deployed on AWS experiences high CPU usage, significantly impacting throughput. The fix for this issue enables write-combining on the ENA adapter for Gateways deployed on AWS.
Fixed Issue 65432: A traceroute from a client which is LAN-side connected to a VMware SD-WAN Edge to a DC server via a VMware SD-WAN Gateway does not display the Gateway IP in the traceroute output.
On initiating a traceroute from the LAN client to the DC which is reachable through the Gateway, the traceroute displays all the hops except the gateway IP.
Fixed Issue 65466: A VMware SD-WAN Gateway or VMware SD-WAN Edge processing a large BGP route exchange may experience a Dataplane Service Failure and restart when running certain debug commands or generating a diagnostic bundle.
Either an Edge or Gateway processing a large number of routes (for example, an Edge advertising 50K BGP routes, or a Gateway learning +100K BGP routes from Edges), can encounter this issue if the debug command dispcnt (with parameters) is also run. The dispcnt debug command is used to monitor capacity drops and can be run either by a Partner Operator on the respective device's CLI or by a user during a diagnostic bundle creation. When this command is run on an Edge or Gateway with a large number of routes and another event (for example, route delete) occurs such that the original variable points to a memory location that is now stale, the result will be a Dataplane Service failure due to the illegal access to memory.
Fixed Issue 65521: A VMware SD-WAN Edge may encounter a Dataplane Service failure and restart as a result.
An Edge service restart will disrupt customer traffic for ~5-10 seconds. The Edge Dataplane Service fails while processing an unexpected control message during a VeloCloud Management Protocol (VCMP) tunnel creation handshake. This issue not dependent on network topology or number of flows, or throughput. It is both rare and random, but has the potential to occur on any type of customer enterprise.
Fixed Issue 65539: A BGP session established between two devices across two different branches does not come up when the customer has upgraded their VMware SD-WAN Edges to Release 4.2.x.
When a customer upgrades their Edges from a lower version to Release 4.2.x, the BGP sessions between 2 LAN devices of different branches established over VCMP tunnels will not come up.
Fixed Issue 65673: An Operator User logged into a VMware SD-WAN Gateway who runs the dpdk_xtstats_dump debug command will observe a Remote Procedure Call (RPC) error message.
When executing the debug.py --dpdk_xstats_dump command on the Gateway, the Gateway throws an RPC error due to the call back registration unavailability.
Fixed Issue 65839: For flows initiated from the clients behind a VMware SD-WAN Hub Edge to the LAN behind a Spoke Edge, the return traffic from the spoke is routed via the Partner Gateway if the default route is advertised from the Partner Gateway.
The expected behavior is for a flow that originates from a Hub Edge to return by the Hub Edge as well. If there is no default route or Edge-to-Edge route advertised from the Hub Edge to the Spoke Edge, the route lookup on the Spoke Edge for the return traffic matches the Partner Gateway default route and the return traffic is routed to the Partner Gateway instead of the Hub Edge.

Without this fix, the only way to avoid this issue is to advertise a default route or an Edge-to-Edge route from the Hub Edge to the Spoke Edge.
Fixed Issue 65910: Update-source IP address for Multi-Hop BGP not updating on modifying the loopback address, resulting in BGP-MH session going down.
When a loopback interface is used as a source interface for BGP-MH and on modifying the loopback address, the source interface is not updated resulting in BGP-MH session going down.

Without the fix, the only workaround is as follows: after modifying the loopback address, reconfigure the source interface for Multi-Hop BGP.
Fixed Issue 65985: For a customer using Dynamic Edge-to-Edge, a VMware SD-WAN Edge in their network may abruptly drop all tunnels and then be unable to build tunnels to any other sites in the network.
Once the site drops all its tunnels, the Edge's maximum tunnel value becomes corrupted and shows a negative value for the maximum # of tunnels. This corrupted value prevents the Edge from forming any new Dynamic Edge-to-Edge tunnels to other Edges. The impact is severe as the Edge cannot communicate with any other site in the network.

Without the fix the only way to clear this issue is to perform an Edge service restart or an HA failover for HA sites.
Fixed Issue 66086: The old route map based filter configuration shows up on a BGP configuration listing after that filter has been removed.
With a multiple neighbor BGP configuration where a multiple route map filter is also associated, if that filter is later removed, the stale configuration persists on some neighbors, which may cause disruption in the expected customer network routing.
Fixed Issue 66119: When a VMware SD-WAN Virtual Edge is deployed in a remote location, the Edge fails its auto-activation via cloud-init.
Remote locations often have high network latency (greater than one second) between the Edge and the VMware SD-WAN Orchestrator, and this level of latency will cause a Virtual Edge to fail its auto-activation via cloud-init.
Fixed Issue 66139: A VMware SD-WAN Edge may suffer a Dataplane Service Failure and restart when a user enables or disables BGP neighbors.
As part of every connect event received from BGP, VMware SD-WAN reapplies the configuration from the Edge process to BGP and there is one more thread in which the configurations are removed, which results in stale BGP information and which in rare cases, may cause a race condition scenario which results in the Dataplane Service Failure.
Fixed Issue 66355: For a customer where the Stateful Firewall is enabled and at least one LAN side NAT (Many:1) rule is configured, inter-VLAN flows do not work.
With Many:1 LAN side NAT rules, the TCP state is not maintained properly for the inter-VLAN traffic and with Stateful Firewall also enabled, the packets will be dropped.
Fixed Issue 66366: For a customer using multicast with a large number of neighbors, a VMware SD-WAN Edge may experience a Dataplane Service failure and restart, causing a brief disruption in customer traffic.
"Large number of neighbors" is defined as ~1600 PIM neighbors. In the case where this issue happens, while traffic is running for a group from 1600 Spoke Edges to one receiver behind a Hub Edge, the PIM service fails and this in turn causes the Edge service to also fail, causing the restart.
Fixed Issue 66676: When a Business Policy NAT is configured, the return traffic from the VMware SD-WAN Gateway may not NAT back to the original source IP.
During the NAT entry insertion in the code, it is expected to delete the older entries. However, due to not using all keys for hash table look up, older entries were not getting deleted in some instances and this was causing the NAT entry insertion error.
Fixed Issue 66691: On a VMware SD-WAN Edge model 6x0 (610/620/640/680), auto-negotiation status is not shown correctly.
Auto-negotiation is not supported on SFP1 and SFP2 as a result of the Intel x553 NIC used by all Edge 6x0 models. However, auto-negotiation is supported on GE1-GE6 (copper ports). But the Edge's ethtool communicates that auto-negotiation is always on for all ports due to a defect in the ixgbe driver.
Fixed Issue 66801: For a customer site using a High-Availability topology and a VNF, the customer may not be able to connect to a VNF to perform trust establishment from a management server.
The issue is seen at HA sites when routed interfaces are DHCP enabled and there is no default route present in the kernel route table. In that case the kernel responds with "ICMP destination unreachable".

Without the fix, the workaround to prevent this issue is to add a default route on the Standby Edge so the the Edge does not send "ICMP Unreachable" back to the VNF VM, causing the SSH connection to reset.
Fixed Issue 67060: VMware SD-WAN Edge may show a large memory utilization which may potentially cause an Edge service restart if sufficiently high.
The issue is a memory leak which manifests as a slow and continuous increase in memory utilization. The issue is occurs when multiple HTTP request packets are sent for a single flow, the memory leak specifically happens while the Edge is parsing the HTTP request packets.
Fixed Issue 67173: When the same route is learned from multiple IBGP neighbors, the second best route selected from the BGP process is being used by the VMware SD-WAN Edge resulting in a black-holing of certain customer traffic.
Due to an issue in the Free Range Routing suite (FRR), IBGP was sending multiple next-hops to the Edge and it was picking the second best (last in the next hop order) to update the forwarding information base (FIB). The fix includes a command in the BGP process to send only the best next hop to the Edge.
Fixed Issue 67191: For a customer using a Cloud Security Service (CSS), the Layer 7 Health Check returns an erroneous failure and the CSS tunnels are torn down.
When there are a large number of Non SD-WAN Destination (NSD) tunnels on a VMware SD-WAN Gateway, the Virtual Tunnel Interface (VTI) IP can fall out of the given subnet mask /24 range, which is defined for the probes to be processed by the Gateway dataplane service. This is what causes an erroneous L7 Health Check failure. The fix updates the mask to /16 to accept the L7 for processing in the Gateway's dataplane service.

Without the fix, the only remediation is for an operator with access to the Gateway, the file /opt/vc/bin/gwd_ip_setup.sh can be manually changed to reflect the change in the mask(169.254.0.0/24 to 169.254.0.0/16). Followed by a Gateway service restart.
Fixed Issue 67197: A customer network may experience periodic disruption of multicast service in deployments with more than 1500 sources associated with a multicast group.
A software issue in the PIM stack's join-prune message handling logic fails with an exception when handling join-prune updates in deployments with more than 1500 sources associated with a multicast group.

Without the fix, the only way to prevent this issue is to limit the total number of multicast sources to 1000.
Fixed Issue 67259: Multicast traffic flow disrupted when PIM process restarts multiple times and PIM neighbor do not come up.
On a scale setup with 1600 PIM neighbors, when restarting PIM process multiple times while traffic is running from 700 Spoke Edges to a receiver behind a Hub Edge, after one of the restarts, only 570+ PIM neighbors came up out of the 1600 PIM neighbors. The only way to clear this issue is restart the Edge service.
Fixed Issue 67485: VMware SD-WAN Gateway may have interfaces missing during an upgrade.
A very narrow timing window exists to end the Gateway's dataplane process before this process has initialized all DPDK KNI (software based) interfaces. When rebinding back to the kernel, the KNI interface cannot be found. When binding back to DPDK, that same state is maintained with a missing interface.
Fixed Issue 67694: A customer may experience a Cloud Security Service (CSS) tunnel failure because the L7 Health Check probes get conditionally backhauled.
L7 Health Check probes should never be conditionally backhauled, and when they are they will fail and this results in CSS tunnels being erroneously marked as down.
Fixed Issue 67790: For a customer enterprise which uses either BGP or OSPF and has configured an inbound filter(s) to ignore certain routes, when Dynamic Cost Calculation (DCC) is enabled on this enterprise, the inbound filter(s) will no longer be in effect and traffic will attempt to use those routes.
Prior to DCC being enabled, the forwarding information base (FIB) will not include the routes that were set to IGNORE on the BGP/OSPF inbound filter. After DCC is enabled the FIB now includes these routes and traffic will attempt to use these routes with the potential for significant traffic disruption for the customer enterprise.

Without the fix, the only workaround is to restart OSPF/BGP for the inbound filter to be properly applied.
Fixed Issue 67869: When a VMware SD-WAN Hub Edge was previously configured as single stack IPv4 and later changed to dual stack IPv6 preferred, the older IPv4 tunnel does not get disconnected.
When this issue manifests, the customer would observe an incorrect tunnel count because the IPv4 tunnels are not being torn down. In effect, double the number of tunnels as there should be.
Fixed Issue 68994: Customers who deploy a Non SD-WAN Destination (NSD) tunnel from a VMware SD-WAN Edge with a VMware SD-WAN Gateway may observe the tunnel flapping.
This issue is observed at tunnel establishment or at IKE rekey. Either the Edge or the Gateway deletes the security associations (SAs) based on IKESAID=0 which causes tunnel flapping. The tunnel automatically stabilizes, but the time needed to do this is not consistent and that can further the impact to customer traffic to the NSD.
Fixed Issue 69704: Enabling High-Availability on a site using a VMware SD-WAN Edge 6x0 platform (610, 620, 640, 680) may break the Edge's communication with the VMware SD-WAN Orchestrator.
This has been verified in Release 4.3.0 and 4.4.0. After enabling HA, due to certain timing conditions, the Orchestrator communication breaks. This results in HA not coming up and the Edge loses complete connectivity to the Orchestrator, meaning the Orchestrator will mark the Edge as down and no further configuration changes can be made.
Fixed Issue 70310: For a customer using multiple segments, when one or more segments are deleted or disabled, a VMware SD-WAN Edge may suffer a Dataplane Service failure and restart that service, causing a brief interruption of customer traffic.
When a segment is deleted, the Edge does not fully clean up the memory associated with this deleted segment. There are scenarios where the Active Edge synchronizes events to the Standby Edge by referencing such segments which results in a service failure on the Standby Edge as these segments are not present.
Fixed Issue 70416: VMware SD-WAN Gateway may show a high CPU load that results in latency and packet loss for Edges using it as their Primary Gateway.
This issue is caused by the Gateway's fast path threads (IKE, VCMP Data, etc.) spending between 15-20% of their cycles doing InetNtop operations. The fix for this issue removes InetNtop operations and replaces them with a more efficient data formatting process.
Fixed Issue 70590: An attempt to generate a diagnostic bundle on a VMware SD-WAN Gateway using Release 4.3.0 may fail.
Diagnostic bundles generated on a Gateway running Release 4.3.0 fail due to the diagnostic bundle exceeding the size limit configured on the Orchestrator. The excessive size of the diagnostic bundle is caused by audit logs that grow large over time.

Without this fix, the only way to successfully generate a diagnostic bundle on a Gateway is for an Operator User to log into the Gateway and, prior to triggering the diagnostic bundle on the Orchestrator, the Operator User needs to delete the audit log files that are under the Gateway's /var/log/audit directory.
Fixed Issue 70789: Customer may experience random drops in traffic due to IPSec Anti-Replay detection.
If either a VMware SD-WAN Edge or VMware SD-WAN Gateway receives two packets which each update the cache entry sequence number, then it is possible that the first packet will update the replay window incorrectly, which may trigger IPsec Anti-Replay detection which would cause the IPsec packet to drop.
Fixed Issue 71052: When the number of customer enterprises connecting to a VMware SD-WAN Gateway is greater than 285, the Gateway experiences a Dataplane Service failure.
Beginning with Gateway Release 4.3.0, the Gateway's ability to monitor customers was enhanced by adding new counters to track the packet and flow related information at the customer enterprise level. The issue is that the number of counters initialized for the customer enterprises exhausts after 285 customer enterprises, and the counter initialization for any further new customer will fail, causing the Gateway's Dataplane Service to fail and forcing a service restart.
Fixed Issue 71513: A user looking at the Gateways > Monitor tab on a VMware SD-WAN Orchestrator UI would observe that the Handoff Queue Drops always show a value of 0 if looking at a VMware SD-WAN Gateway using Release 4.3.0.
Gateways running Release 4.3.0 or above do not report handoff queue drops to the Orchestrator due to incorrect formatting and this blocks the Operator from getting a clear picture of this particular troubleshooting data point.

Orchestrator Resolved Issues

Resolved in Orchestrator Version R450-20220502-GA

Orchestrator version R450-20220502-GA was released on 05-04-2022 and is the 8th Orchestrator rollup for Release 4.5.0.

This Orchestrator rollup build addresses the below critical issues since the 7th Orchestrator rollup, version R450-20220315-GA.

Issue 78688: A VMware SASE Orchestrator which hosts customers using a Zscaler Cloud Security Service (CSS) may experience a CPU usage spike which leads to high latency in process requests and the Orchestrator not updating Edge health statistics.
The Orchestrator Edge Health Statistics processing has a database lookup that is not optimized and this increases the CPU utilization by the Orchestrator.

Workaround: There is no workaround for this issue.
Issue 84214: When an Operator user is on the Gateways page of a VMware SASE Orchestrator UI, they may be unable to assign a particular Gateway for the role of Super Gateway.
When a Gateway is already assigned the role of both Super and Alternate Super Gateway, and the Operator tries to edit the Super Gateway assignment of an enterprise from the Customer Usage list on the Gateways > Configure Gateways screen, the UI does not correctly find associated data about the Super Gateway and the Assign Super Gateway dialog does not show up while also throwing an error in the console.

Workaround: There is no workaround for this issue.
Issue 84969: When a VMware SD-WAN Edge running a 4.2.x Release which is also configured with an overridden non-default Management IP is upgraded to Release 4.3.x or higher on a VMware SD-WAN Orchestrator running 4.3.x or higher, the Edge may lose the configured overridden Management IP.
An Orchestrator running 4.3.x or higher (including 4.5.0) is not automatically creating the loopback interface while also retaining the overridden non-default Management IP for an Edge when that Edge is upgraded from 4.2.x to a 4.3.x or later build.

Workaround: A user would need to reconfigure the overridden Management IP.

Orchestrator Resolved Issues and Added Feature

Resolved in Orchestrator Version R450-20220315-GA

Orchestrator version R450-20220315-GA was released on 03/16/2022

This Orchestrator build remediates CVE-2021-45046, an Apache Log4j vulnerability, by updating to Log4j version 2.17.0. The build also remediates CVE-2021-44228, which was first addressed in Orchestrator build R450-20211218-GA with Log4j version 2.16.0. For more information on the Apache Log4j vulnerability, please consult the VMware Security Advisory VMSA-2021-0028.13.

In addition, this Orchestrator build addresses several critical issues since Orchestrator version R450-20220215-GA.

This build also adds a new feature to Cloud Web Security: Data Loss Prevention (DLP). This new feature is covered in greater detail earlier in the Release Notes under New SASE Features.

Fixed Issue 69573: For customers using VMware Secure Access, when creating a Remote Access service, if validation fails in Enterprise & Network Settings Screen, the Next button is disabled as expected but the error messages are not displayed.
When creating a Remote Access service if the user enters invalid data in the Customer Subnet or Subnet bits fields, no error message is displayed below these fields to help the user understand why the configuration failed.
Fixed Issue 76036: Attempting to access either 'Partner Overview' page and/or a 'Configure > Customer' page for that Partner on a VMware SASE Orchestrator fails to load with an "An unexpected error has occurred" message.
The Partner Overview page and/or a Configure > Customer page for a customer supported by that partner may fail to load because the `enterpriseProxy /getEnterpriseProxyGatewayPools` API times out. The trigger for these pages not loading is if the they include a large number of Gateway pools and Gateways which may lead to the enterpriseProxy /getEnterpriseProxyGatewayPools API used on the page timing out, and causing the page loading issue for each UI page.
Fixed Issue 79324: On the Cloud Web Security service, for specific Applications, some CASB Application Controls are effectively linked (in other words, setting one Application to block may also block another Application), while the CASB Exception Rule Wizard presents them individually.
The CASB Exception Rule Wizard now alerts users when CASB Application Controls for the selected Application are linked, and changing the affected Control will also change the others. Additionally, only Applications without linked Controls can be grouped together in an Exception Rule, while an application with linked Controls needs its own Exception Rule.
Fixed Issue 83534: For customers using VMware Cloud Web Security, a customer with a Standard license is able to access features reserved for a customer with an Advanced license.
The API which validates the customer's Cloud Web Security license and ensures that customer accesses the correct features for that license did not work properly and allowed all customers to access all Cloud Web Security features (for example CASB Application Control regardless of license type.
Fixed Issue 83538: For customers using the Secure Access service, when creating a Remote Access service, the Enterprise & Network Settings Screen shows internal error message keys.
When creating a Remote Access service, if the user enters invalid data in the customer subnet or subnet bits fields, an untranslated error message is displayed below these fields. This error message is of no use to the user and does not point to resolving the actual issue regarding invalid data in either field.
Fixed Issue 83822: For customers using VMware Cloud Web Security, when looking at Monitor > Logs > Web Logs, the user is only able to see a maximum of 100 logs and cannot load more pages to see additional logs.
With tis issue the user is stuck using the maximum 100 logs for a single page with no additional logs viewable as pagination is broken for Web Logs. This is a major hindrance for users because it means if they want to load a large time period (for example, 30 days) they would be unable to see all the logs for that period. The only workaround is to load up short time periods that return 100 or less logs.
Fixed Issue 83940: For customers using VMware Cloud Web Security, a customer with a Standard License is able to see pages for both Data Loss Prevention (DLP) and CASB Application Control pages on the VMware SASE Orchestrator UI.
A customer with a Standard Cloud Web Security license does not have access to either DLP or CASB Application Control features and the UI should not display pages for those features. This issue is caused by a missing route configurations in the Cloud Web Security UI.
Fixed Issue 84286: For customers using the VMware Cloud Web Security service, a user with read-only privileges does not see logs on the Cloud Web Security > Events page until the user selects a time interval.
The Cloud Web Security > Events page for a read-only user shows as blank, implying there are no logs to display. But if the user selects a new time interval, then the correct logs for that time interval will display.
Fixed Issue 84297: For customer using VMware Cloud Web Security, read-only users are able to edit Cloud Web Security configurations for the Content Inspection Engine and Authentication pages.
The VMware SASE Orchestrator is not properly enforcing the read-only user role for the selected Cloud Web Security configuration pages.
Fixed Issue 84299: For customers using VMware Cloud Web Security, customer administrators with either a Security Admin or Security Read role are unable to open the Cloud Web Security > Monitor page on the VMware SASE Orchestrator UI.
The customer administrators with Security roles (Admin and Read) are not provided with the necessary privileges to view the Cloud Web Security's Monitor page by the Orchestrator.
Fixed Issue 84300: For customers using the VMware Cloud Web Security service, a customer administrator with any read-only role can remove auditor email addresses from the Configure > DLP page.
Customer administrator roles with read-only status for Cloud Web Security are: Customer Support, Security Read, and Network Admin. Any of these administrators can go to Cloud Web Security > Configure > DLP Settings and under the Auditors tab could delete the configured email addresses of the auditors who are supposed to get alert emails for DLP.

___________________________________________________________________

Resolved in Orchestrator Version R450-20220215-GA

Orchestrator version R450-20220215-GA was released on 02/17/2022 and addresses several critical issues since Orchestrator version R450-20211218-GA.

Fixed Issue 64410: For customers using VMware Cloud Web Security, a user can add invalid IP addresses as part of the SSL Inspection Rule on the VMware SD-WAN Orchestrator New UI.
This can be done an an existing security policy or a new security policy for either the source or destination. When the user finishes configuring the rule with an invalid IP, there is no error message. And then when the user attempts to publish the rule there is an error that is useless to the user and reads "error while publishing security policy: Request failed with status code 400".
Fixed Issue 64438: For customers using VMware Cloud Web Security, a user can add invalid characters to a Security Policy name when updating the rule on the VMware SD-WAN Orchestrator New UI.
For example, when creating a Security Policy, if a user enters invalid characters like '<>' as the name, Orchestrator UI shows an error, but if the user edits an existing Security Policy and update its name to '<>' and saves it, the Security Policy name gets updated.
Fixed Issue 68153: For customers using VMware Secure Access, a user may not be able to delete a Secure Access service from the VMware SD-WAN Orchestrator New UI.
When the creation of a Secure Access service fails and the user tries to delete the Secure Access from the Orchestrator UI, it may fail to get deleted. This happens when some resources do not get created when the Secure Access failed and hence the deletion is not able to complete properly as the backend service tries to find these resources to delete but fails. The result would be a failed delete call.
Fixed Issue 74284: For customers using VMware Cloud Web Security, when creating a new Cloud Access Security Broker (CASB) rule and selecting a destination application, the toggle is set to 'All Applications' on the VMware SD-WAN Orchestrator New UI.
When creating a new CASB rule the toggle should be set to 'Custom', which allows the user to pick the applications to which the CASB rule applies. But sometimes the toggle and is set and 'stuck' to 'All Applications' which encompasses the full 1000+ applications that the CASB rule can apply to.
Fixed Issue 74491: On a VMware SD-WAN Orchestrator configured for Disaster Recovery where VMware Cloud Web Security and VMware Secure Access services are also running, replication may fail between the Active and Standby Orchestrators with the user observing errors on the Orchestrator UI.
When the issue occurs, MySQL on the Standby Orchestrator fails to replay the events from the Active Orchestrator. The reason for this is that Cloud Web Security/Secure Access services are running on the Standby Orchestrator which is also modifying the database state.
Fixed Issue 74674: For customers using VMware Cloud Web Security, when the user is on the Cloud Web Security page of the VMware SD-WAN Orchestrator New UI, there is no section that displays Events specific to Cloud Web Security.
With this issue the only issue that shows up is CWS_EVENT that provides no detail for the user. An Orchestrator that includes this fix would now observe an Events link on the left side navigation pane that leads to a dedicated Events page just for Cloud Web Security.
Fixed Issue 74710: For customers using VMware Cloud Web Security, the date format of both Certificate Issue and Certificate Expiration are always U.S. English on the VMware SD-WAN Orchestrator New UI.
When configuring a CASB rule, select any application, on the pop-up dialogue, the date format for both Certificate Issue (Cert. Issue) and Certificate Expiration (Cert. Expiration) will always be in U.S. English regardless of the actual localization of the user's browser (for example, Spanish).
Fixed Issue 74715: For customers using VMware Cloud Web Security, when a user with a non-English language localization browser is configuring a Security Policy > CASB Rule, the pop-up dialogue text strings are truncated on the VMware SD-WAN Orchestrator New UI.
The user is unable to see the complete text for a particular step on configuring a CASB rule when those test strings are not in English. Instead the sentence just cuts off at the text box boundary.
Fixed Issue 74825: For customers using VMware Cloud Web Security, when a user with a non-English language browser attempts to perform a search on the Security Policy > CASB page using non-English text strings, no results are returned on the VMware SD-WAN Orchestrator New UI.
While some text was being displayed as translated in the Cloud Web Security rules grid, the search box was searching non-translated text keys instead. The only workaround for a non-English user is to use the filter for the Risk Score column to filter out different levels such as Low, Medium, and High.
Fixed Issue 77043: For a site using a High-Availability topology, where the VMware SD-WAN Edges use Release 4.3.x or later, on an HA failover the VMware SD-WAN Orchestrator does not register an HA failover event.
The Orchestrator filters out HA_GOING_ACTIVE events on Edges using Release 4.3.x or later to prevent a race condition and as a result the event does not show up in Events.
Fixed Issue 77101: When a VMware SD-WAN Orchestrator is upgraded, customers using BGP may find their routes changed from 'Uplink' to 'Non-Uplink'.
There is a potential impact for route-order for the prefixes received from this neighbor and may lead to non-preferred routing exits.

Without this fix, a user would need to reconfigure the uplink flag for affected BGP neighbors after the upgrade.
Fixed Issue 80613: On a VMware SD-WAN Orchestrator configured for Disaster Recovery (DR), replication may fail between the Active and Standby Orchestrators with the user observing the Copying DB status as 'Failed' on the Orchestrator UI.
Since MySQL version 8.0.26, master-data option has been deprecated in mysqldump command. This has been replaced with source-data option.
This issue is encountered because the Orchestrator DR process uses mysqldump command with master-data option. However, with the upgrade of MySQL to latest version, this option no longer works and hence breaks the DR. To address this problem, the Orchestrator with this fix uses source-data option instead of master-data option for mysqldump command during the DR process.
Fixed Issue 81498: When a VMware SD-WAN Edge running a 4.2.x Release which is also configured with an overridden non-default Management IP is upgraded to Release 4.3.x or higher on a VMware SD-WAN Orchestrator running 4.3.x or higher, the Edge may lose the configured overridden Management IP.
The Orchestrator running 4.3.x or higher is not automatically creating the loopback interface while also retaining the overridden non-default Management IP for an Edge when the Edge is upgraded from 4.2.x to a 4.3.x or later build.
Fixed Issue 81599: For customers using VMware Cloud Web Security, SSL Inspection is embedded within the Web Security tab on the VMware SD-WAN Orchestrator New UI.
The issue here is that SSL Inspection rules are not specific to Web Security policies but equally applicable to CASB and DLP. As a result, with this Orchestrator build and later, the user would observe SSL Inspection as having its own tab on par with Web Security, CASB, and DLP so the user can easily access and configure those rules as needed.

___________________________________________________________________

Resolved in Orchestrator version R450-20211218-GA

Orchestrator version R450-20211218-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 Orchestrator Version R450-20211120-GA

Orchestrator version R450-20211120-GA was released on 11/22/2021 and addresses several critical issues since Orchestrator version R450-20211109-GA.

Fixed Issue 71490: A customer using a VMware SD-WAN Orchestrator which hosts a large number Edges with a large number of learned route events may observe slowness in their outing requests being processed. Orchestrator administrators would observe the Orchestrator's performance impacted with high CPU utilization.
This issue would impact an Orchestrator with ~5000 Edges, where each Edge was pushing ~20 learned route events every 30 seconds. The issue was caused by inefficiencies in how the Orchestrator processes these Edge's learned routing events, and this build includes optimizations to route processing logic to prevent this issue from recurring..
Fixed Issue 75188: When a customer uses GRE Automation in Release 4.5.0, the primary and secondary tunnels cannot be in the same location.
When customers use GRE automation, the customer is shown a list of recommended tunnels and uses the first two of them as primary and secondary. However, the design does not let the primary and backup tunnels be to the same datacenter. For example, if the primary tunnel was set up to the San Francisco DC and the secondary was set up to the Los Angeles one, then both tunnels would come up.
Fixed Issue 75781: When a VMware SD-WAN Orchestrator is upgraded from 3.x to 4.5.0, users will observe long gaps of no-data on the Orchestrator UI for the QoE monitoring tab. These gaps will be observed for time ranges covered prior to the upgrade.
After upgrading to Release 4.5.0 the expectation is for all QoE data to get migrated from MySQL to ClickHouse with the user able to see all of the QoE historic data served off of ClickHouse post-upgrade, however due to an issue with in the migration business logic the data did not successfully transfer over.
Fixed Issue 75859: For a VMware SD-WAN Orchestrator operating in FIPS mode and which is upgraded to Release 4.5.0, an operator may observe a high rate of audit events and disk load.
The issue for an Orchestrator operating in FIPS mode is that duplicate apparmor (a security service) profiles are created for MySQL during the upgrade to 4.5.0 and this prevents the apparmor service from starting.

___________________________________________________________________

Resolved in Orchestrator Version R450-20211109-GA

Orchestrator version R450-20211109-GA was released on 11-10-2021 and addresses several critical issues since Orchestrator version R450-20211101-GA.

Fixed Issue 69196: Where a customer has a site that has configured a WAN link as a Backup and also uses a Cloud Security Service (CSS), a user may observe CSS Tunnel events for the Backup link.
If the user has Backup WAN links where CSS tunnels are configured, they will see events related to those links along with Active and Hot Standby links. Since the backup link is by definition inactive, these events are spurious and annoying to the customer.
Fixed Issue 72018: If a Partner enables SASE services like Cloud Web Security and Secure Access, these services will not work because SASE Gateways will not be assigned.
Prior to this VMware Orchestrator build, there was no support for enabling SASE services for Partners, as a result if a Partner enabled a SASE service the Orchestrator did not react by assigning SASE Gateways to the Partner's customers.
Fixed Issue 72020: A Partner will not be able to take advantage of SASE services on their statically assigned SASE Gateways on VMware's hosted SASE PoPs and the Partner's customer's Edges will not get assigned SASE gateways.
This issue is linked to 72018 and also is caused by an absence of support for enabling SASE services for partners before this Orchestrator release.
Fixed Issue 75311: When a customer uploads a custom application map which includes duplicate subnets from older VMware SD-WAN Edges to a VMware SD-WAN Orchestrator which uses Release 4.5.0, the customer will observe a validation error for having duplicate subnets.
The fix removes the validation for duplicate subnets to enable customers to upload an application map from older Edges containing duplicate values.
Fixed Issue 75433: If a user navigates to Monitor > Network Services and checked the details for a Non SD-WAN Destination on the VMware SD-WAN Orchestrator, they would observe that the Redundant Cloud VPN field is not read only but has a checkbox the user can select.

All Monitor screens are expected to be purely read only and having anything configurable on a Monitor screen is not correct and there should be no update functionality for Network Services or anywhere else.

___________________________________________________________________

Resolved in Orchestrator Version R450-20211101-GA

Orchestrator version R450-20211101-GA was released on 11-01-2021 and addresses several critical issues since Orchestrator version R450-20211012-GA.

Fixed Issue 63110: For a customer using the VMware Cloud Web Security service, when configuring a Cloud Web Security policy, a user cannot delete a previous domain name in a list without truncating the list.
The user cannot see the domains previous to the one being seen and there is no way to show them with the existing UI. The ability to properly edit a Cloud Web Security policy was not properly implemented in previous 4.5.0 Orchestrator builds.

Without this functionality, the user's only option is to delete all items listed after the item and then re-enter them.
Fixed Issue 64762: For a customer using the VMware Cloud Web Security service, when attempting to configure Content Inspection using the Content Inspection Wizard, the user would note a lack of contextual help.
The user runs into this issue when opening the Content inspection Wizard, as the user should expect there to be contextual help to ensure the user can successfully configure this feature.
Fixed Issue 69570: When using the New UI on the VMware SD-WAN Orchestrator, a customer administrator would observe that the application switcher is not visible.
A customer administrator should be able to see an interface tab that allows the user to switch between SD-WAN, Cloud Web Security, and Secure Access, but that tab is not present.
Fixed Issue 69912: An Operator User using the New UI on the VMware SD-WAN Orchestrator if opening the console on their browser may observe errors related to missing privileges.
The console window would show a series of errors reading "ERROR TypeError: Cannot read property 'authType' of undefined". This issue is caused by a header component missing the necessary privilege.
Fixed Issue 72041: For a customer using the VMware Cloud Web Security service, a user is not able to create a URL filtering rule with domains that have paths, like 'google.com/flights'.
A user should be able to enforce a set of URL Filtering rules that both allows a domain like www.facebook.com while blocking this same domain with a path, like www. facebook.com/gaming. When the user tries to create a URL filtering rule on the Cloud Web Security UI for a domain name which has a path, the Orchestrator throws an error.
Fixed Issue 73910: For a customer using the VMware Cloud Web Security service, a user cannot update any of the settings for the Content Inspection Engine.
A user cannot update the settings for any parameter of the Content Inspection Engine because the VMware SD-WAN Orchestrator UI discards any user changes when the Details section is closed.
Fixed Issue 74038: For a customer using the VMware Cloud Web Security service, an attempt to publish a security policy with a content-inspection rule which selects an ISO option in "Archives and Compressed Packages" does not succeed.
When the ISO option is selected, the data passed to the Cloud Web Security service is not compatible with our current API, especially the v1 Type of ISO option that needs to be modified.
Fixed Issue 74106: Customers who have not enabled Dynamic Cost Calculation (DCC) and are located on VMware SD-WAN Orchestrators which hosts a large number of customers may observe delays in the time it takes the routes for their enterprise to synchronize. An Operator user for that Orchestrator would observe a high number of routing event rejections on the Orchestrator.
On production Orchestrators with a high routing scale, this issue will cause a significant delay in synchronizing the routes for a Non-DCC customer and hence will delay dataplane route convergence. The resolution for this issue improves the Orchestrator's rate limiting of routing API calls from VMware SD-WAN Edges and this improves the route convergence time on the dataplane side in customer environments who are not using Distributed Cost Calculation.
Fixed Issues 74187: For a customer using the VMware Cloud Web Security service, a user is not able to correctly configure a Content Filtering rule to download a file for 'Other Documents' file type.
When a user tries to create a Content Filtering rule to download a file for 'Other Documents' file type, the file type options the user is presented with are from the 'Presentation Tools' file type.
Fixed Issue 74460: Partner users are unable to remove per-segment Partner Gateway handoffs.
Partner users do not have permission to modify VMware SD-WAN Cloud Hosted Gateways, but when a Partner invokes the API to modify handoff configuration for a partner Gateway, the Orchestrator backend was treating a Partner Gateway the same as a Cloud Hosted Gateway. The issue arose due to previous fixes around handoff configurations for mixed Gateway pools (Pools that include both Cloud Hosted and Partner Hosted Gateways).
Fixed Issue 74491: For a VMware SD-WAN Orchestrator configured in a Disaster Recovery topology, an Operator User may observe that the Replication has failed between Active and Standby Orchestrators.
MySQL on the Standby Orchestrator is failing to replay the events from the Active Orchestrator. The reason is that VMware Cloud Web Security and Secure Access services are running on the Standby Orchestrator and each service is modifying the database state.

___________________________________________________________________

Resolved in Orchestrator Version R450-20211012-GA

Orchestrator version R450-20211012-GA was released on 10-12-2021 and addresses two critical issues since Orchestrator version R450-20211006-GA.

Fixed Issue 72386: On the Monitor > Edge section of a VMware SD-WAN Orchestrator, when looking at the QoE tab under monitoring, the user will observe samples indicating no-data towards the right tail of the time series.
The issue is observed if a user goes to a Monitor > Edge page for any VMware SD-WAN Edge and selects the QoE tab with a time range of 12 hours or more.

Without the fix, the user will have to query for the desired time range in increments of 1 hour. When done this way, the user would not observe any gaps.
Fixed Issue 72424: Customers using Secure Access are not able to use the "Edit" functionality to edit the DNS Server, Subnet bits or the subnet. Adding or removing Cloud Web Security service also does not work.
The Secure Access deployment will fail when anything except Cloud Web Security from the above list is edited. A Secure Access deployment will complete successfully for a Cloud Web Security change but would not in fact update the Cloud Web Security field with the new value.

Without this fix, as a workaround the user, instead of editing Secure Access, would delete and create a new Secure Access with the desired updates.

Resolved Issue and Added Feature

Resolved in Version R450-20211006-GA

Orchestrator version R450-20211006-GA was released on 10-08-2021 and addresses one new critical issue since Orchestrator version R450-20210924-GA.

This build also adds a new feature to Cloud Web Security: Cloud Access Security Broker (CASB). This new feature is covered in greater detail earlier in the Release Notes under New Cloud Web Security Features.

Fixed Issue 71278: API calls initiated by a Partner Administrator to the linkQualityEvent/getLinkQualityEvents method fail with the error "No enterprise id in query" when the enterpriseId parameter is not specified.
VMware SD-WAN began treating enterpriseId as mandatory for this API call beginning with Release 4.5.0 GA, even though many partners have never used an enterpriseId in their API call. As a result the fix here is to not require enterpriseId for this API call.

Without this fix, both Operator Users and Partner Administrators are advised to ensure that the "enterpriseId" parameter is always specified on calls to this API method, and all other API methods that operate on customer-managed data.

Orchestrator Resolved Issues

Resolved in Version R450-20210924-GA

The below issues have been resolved since Orchestrator version R430-20210810-GA.

Fixed Issue 48706: Users may not be able to save changes on the Configure > Edge > Device tab with the source interface selected under the Syslog configuration.
The error the user would see on the VMware SD-WAN Orchestrator is "Provided source interface is not present in the segment on segment: <Segment Name>." The is caused by the user creating and deleting a number of segments in such a way the segment sequence is no longer sequential.
Fixed Issue 48791: User is unable to switch a VMware SD-WAN Edge between Profiles when the Edge has an interface configured using Edge Override.
For example, if a customer two Configuration Profiles: Profile 1 and Profile 2 and associates an Edge with Profile 1. If the user then uses Edge Override to configure GE2 to routed and adds a static route for GE2, when the user later tries to assign this same Edge to Profile 2, the user will observe an error that GE2 does not exist on Profile 2 as routed. This issue occurs because when a user configures an Edge interface using Edge Override that belongs to a profile, the VMware SD-WAN Orchestrator is unable to switch because the Orchestrator is not validating the Edge Override presence.
Fixed Issue 51210: The VMware SD-WAN Orchestrator UI API token "management" view was inadvertently made available to users that did not have the privileges to modify (in other words, revoke) API tokens.
Standard Administrators were able to view API tokens allocated to other users on tenant "Authentication" pages; this is not regarded as a security issue but is not intended, since these users do not have the capacity to modify API tokens allocated to other users.
Fixed Issue 52315: When using the New UI on the VMWare SD-WAN Orchestrator, a user may observe inconsistencies with regards to the Edge certificate.
If a user navigates to Edges List, and selects an Edge which has several certificates, this opens a pop-up box. The issue is that sometimes the user will see the old UI design versus the new UI.
Fixed Issue 52863: The VMware SD-WAN Orchestrator UI allows non-standard BGP timer configurations and does not throw an error.
While enabling Partner handoff configuration at the customer configuration page, when a user configures the BGP keep/hold timers on the Orchestrator that do not comply with the BGP standard in RFC 4271, the Orchestrator allows the configuration to be saved. However, on the VMware SD-WAN Edge itself, FRR changes the keep/hold values to comply with standards. For instance, if a user configures a keep 2 second/hold 5 second on the Orchestrator, the Edge FRR will change the keep value to 1 sec so that 3 x keep = (less or equal to hold).
Fixed Issue 55819: When a VMware SD-WAN Edge has COS enabled with strict precedence and policing, link bandwidth remains unutilized when the total bandwidth percentage is less than 100.
The bandwidth is made as a direct percent (versus a ratio) which results in unused bandwidth in the link. In Release 4.5.0, the VMware SD-WAN Orchestrator shows a pop-up message alerting users that the link may not be fully utilized when strict precedence & policing are enabled.
Fixed Issue 59106: The length of the user name cannot affect the page display on the VMware SD-WAN Orchestrator UI.
If a user creates a new administrator with an exceptionally long username (for example, [email protected]), the user's page will not adjust for the length of the username and display incorrectly, resulting in any user being unable to see the user's name properly.
Fixed Issue 59606: Users see icons of varying sizes, where they should be uniform when using the New UI of the VMware SD-WAN Orchestrator.
If a user navigates to any page that contains icons, for instance the Edges List, the user will observe icons of the wrong size. The icons remain usable, just the incorrect size.
Fixed Issue 59611: On the New UI of the VMware SD-WAN Orchestrator, the user has difficulty using the Change Profile Segments table if the table contains a lot of rows.
Navigate to Configure > Profiles List , and select any profile that has a lot of segments. Then open the segment dropdown and click on "Change Profile Segments". User will observe the table is difficult to use.
Fixed Issue 60428: On VMware SD-WAN Orchestrator UI, live monitoring shows double the actual values if the Show TCP/UDP Details check box is not selected.
This issue is observed when user opens Monitor Edge > Links tab and turns on Live Mode, but does not elect to Show TCP/UDP. In this case the user will see doubled metric values.
Fixed Issue 61529: When using the New UI on the VMware SD-WAN Orchestrator, deleting VMware SD-WAN Edge models from a profile list does not work properly.
When editing which Edge models apply to a profile, removing an Edge model from the list should remove the same Edge interface block from the device settings. But in the case of deleting all Edges from the profile list, the interface block will stay for the last deleted edge on the list..
Fixed Issue 61852: Monitor > Firewall Logs page in the New UI does not display correct pagination information.
The page row count is incorrect for this section.
Fixed Issue 62145: When a VMware SD-WAN Orchestrator is upgraded to 4.2.1 from lower releases, the migration fails providing a unique constraint break error. This is on `logicalId` field on the client device table.
Release 4.2.1 has a long-running operation that runs on migration which adds `logicalId` to the client device table. This operation is only performed based on a precondition query. This precondition query was incorrect causing logicalId field to be empty. Addition of a constraint on the logicalId field caused duplication error as more than 1 rows consisted of logicalId as empty string.

Without the fix, the only workaround for this is on migration, manually run the pending long running query which will add unique logicalId to all rows of client device table and add then run the unique constraint query.
Fixed Issue 62575: The VMware SD-WAN Edge does not honor expected Cloud Security Service (CSS) or Non-SD-WAN Destination site configuration for non-global segments when those capabilities are enabled via an Edge-specific override.
In some uncommon configuration scenarios (for example, in one case where Cloud Security Service was enabled exclusively on a non-global segment via an Edge-specific override), the Orchestrator incorrectly computed the Edge control plane configuration for non-global segments.
Fixed Issue 63556: User has the option to add more than one TACACS server on the VMware SD-WAN Orchestrator UI.
While the user can add more than one TACACS server, this is not a valid configuration. The reason is that if the first TACACS server fails, the second TACACS server is not going to take over in any case. The fix removes the option for adding more than one TACACS server.
Fixed Issue 64039: In some cases, a customer may observe their DHCP server as inactive.
Issue can be observed in the following scenario: after providing values to addressing type, enable the DHCP server and give values and click on the Update button. If the user opens the subinterface popup, they would observe the DHCP server showing as inactive with all the fields under DHCP server hidden.
Fixed Issue 64930: API error messages are not specific for create/update/delete roles on the VMware SD-WAN Orchestrator.
The error messages in the Orchestrator backend logs are not sufficiently prices for composite role functionality and this hinders an Operator User in identifying issues related to role management. The fix enhances error messages especially for issues related to composite user roles.
Fixed Issue 65069: When using the New UI on the VMware SD-WAN Orchestrator, the user is not able to tell which tab they are on because the active tab is not highlighted.
This is a cosmetic issue with no functionality impact. But the user cannot just look at the top banner and confirm their location within the UI.
Fixed Issue 65199: When scrolling through Monitor > Events page on the VMware SD-WAN Orchestrator's New UI, a "Grid Data has changed" banner is shown on the last page.
The New UI uses pagination for Monitor > Events page. A "Grid Data has changed" banner is shown on the last page because there is a mismatch of events when they are sorted based on a timestamp attribute in some cases.
Fixed Issue 65253: When configuring a Firewall Rule, the drop down list for Object Groups is unusable on the VMware SD-WAN Orchestrator UI when 20+ groups are configured.
Even with 5+ Object Groups (Address Group, Port Group) configured, the Object Group drop down list appears near the bottom of the browser screen. With 20+ rules the Object Groups list is completely out of the screen, and it’s impossible to see it unless the user zooms out a lot on the browser but by then the text is so tiny as to also be unusable.
Fixed Issue 65266: When viewing the Segments page on the VMware Orchestrator's New UI, the layout is not aligned.
This is a cosmetic issue with no functional impact for the user, but the layout is broken and UI items are not aligned as they should be.
Fixed Issue 65526: The VMware SD-WAN Orchestrator generates Alerts and Events for a VMware SD-WAN Edge in a "Degraded" state which never reaches an "Offline/Down" state.
When a VMware SD-WAN Edge initially loses connectivity to the Orchestrator (on a heartbeat check), this state is called "Degraded". Should the Edge loss of connectivity to the Orchestrator continue, the Edge would then be marked as Offline/Down, and this second state is when an "Edge Down" Event should be posted on the Orchestrator's Monitor > Events page and a matching Alert sent out as appropriate to a Customer's Alerts configuration. However, the Orchestrator is generating an Event and sending an Alert for an Edge in a Degraded state, resulting in a possibly large number of spurious Edge Down Events and Alert notifications for the customer.
Fixed Issue 65381: User is able to create custom composite user roles even though RADIUS has been turned on.
Composite Roles at the customer level should only be created for authentication modes other than RADIUS as RADIUS authentication is at the Orchestrator level and there cannot be specific roles at each enterprise. The fix adds a validation to prevent such cases.
Fixed Issue 65558: Attempt to configure and save Syslog settings fails with an error on the VMware SD-WAN Orchestrator.
The issue occurs when the VLAN source interface is configured. The issue is not seen when choosing a routed port as the source interface.
Fixed Issue 65748: BGP is validated at the Profile level even when it is turned off.
Now source interfaces can be linked to BGP. When it is linked but the profile BGP is turned off and if the source interface is changed, currently it throws an error but ideally it should not.
Fixed Issue 65760: When an Operator User is looking at the Orchestrator Diagnostics page of the VMware SD-WAN Orchestrator UI, the user will observe that the Database Storage Info section is missing several data groups.
The following sections are missing from Database Storage: Database Process List; Database Status Variable; Database System Variable; Database Engine Status.
Fixed Issue 65794: For a customer with an exceptionally large number of Edges which also use Non-VMware SD-WAN Destinations, the Monitoring > Services page on the VMware SD-WAN Orchestrator may time out due to the number of records that need to be retrieved.
For example, if a Customer has nearly 200,000+ Edge records with the tag EDGE_NVS_TUNNEL, when loading the /monitor/services page, it returns with more than 200,000 rows. Then the UI retrieves only the latest Edge record for each tunnel, groups them by provider and shows the tunnel state in Cloud Security Service Sites. The response data are also used after clicking the event when customer want to see the history of the tunnel state changes.
Fixed Issue 66011: The VMWare SD-WAN Orchestrator Portal API method linkQualityEvent/getLinkQualityEvents non-deterministically operates in "verbose" mode.
The linkQualityEvent/getLinkQualityEvents Orchestrator API method supports an "individualScores" option that permits clients to optionally request more detailed information on link QoE in the API response. This optional method produces detailed per-timeseries-sample information (which is slow and performance-intensive to produce) in the result. The default value of this parameter is false, to avoid this performance hit. However, the issue here is that the server non-deterministically reports this information even in cases where the client has not specifically requested it with the attendant performance hit.
Fixed Issue 66038: User will see graphs connected between the points where no traffic had happened on the VMware SD-WAN Orchestrator UI.
This is true for either version of the UI, New or Original. While monitoring customer traffic data, the graph would not capture when there is no traffic, instead it connects the null data points. So on seeing a graph, it would gives the user the wrong data about traffic.
Fixed Issue 66203: When a Gateway Pool is assigned to a Customer which contains both Cloud Hosted and Partner Gateways, the Partner is not able to modify the gateway handoff configuration for their managed Gateways.
The issue occurs when a Partner administrator user tries to modify the gateway handoff configuration in the Customer tab present on the customers page.
Fixed Issue 66236: API response for /edge/getEdgeConfigurationModules "WAN module" does not conform with documented JSON schema.
If user compares the API response for "/edge/getEdgeConfigurationModules" with the documented schema, PrivateNetwork property would be missing for WAN data.
Fixed Issue 66276: When High-Availability is configured on a VMware SD-WAN Edge by overriding an interface on the Edge level, the VMware SD-WAN Orchestrator is not allowing a user to make any new changes to the profile device settings by throwing an error "Edge b2-edge1: Interface GE1 is required to be type of switched for the stand by pair HA."
This issue has sever impact on a user who needs to change a profile configuration as it blocks all changes. The fix for this issue allows users to modify the profile device settings when the Edge has overridden the profile configuration for configuring HA.
Fixed Issue 66597: On a VMWare SD-WAN Orchestrator where there is a customer with a very large number of Edges deployed, when adding multiple VMware SD-WAN Gateways to a Gateway Pool that customer is using, a large number of Edges may show as down on the Orchestrator.
This issue was observed in the field with a customer who had ~7000 Edges connected to the Orchestrator. When there is a change in the Gateway Pool for that customer, the Orchestrator needs to push configuration changes to all the Edges and the control plane recalculations for more than 700+ edges in a 30 second window causes heartbeats/statistic pushes to fail with 'POOL_ENQUEUELIMIT' error. Because of heartbeat failures, the Edges show as down on the Orchestrator.
Fixed Issue 66631: The Migration Tool does not work when attempting to migrate large customer enterprises.
Large customer enterprise is defined as one with 100 or more Edges. The migration tool will fail at the step where is is supposed to stringify the whole data blob and write to a file. When doing the configuration export, the migration tool was using JSON.stringify to stringify the output data and write it to the file, which will fail when the configuration is huge.
Fixed Issue 66636: VMware SD-WAN Edge does not honor source interface configuration for RADIUS authentication traffic when the source is a loopback interface.
When a user configures RADIUS on a Profile or Edge and specifies a loopback interface as the desired source interface for outgoing authentication traffic, the Edge fails to create a NAT rule as expected due to a parse error stemming from an inconsistency in the expected versus actual type of the "port" parameter for the authentication service that is dispatched from the VMware SD-WAN Orchestrator. This value should be an integer, and the Orchestrator API validation logic has been modified accordingly.
Fixed Issue 67153: Alert emails are being sent out even if the VMware SD-WAN Edge came up within the configured delay interval.
The VMware SD-WAN Orchestrator sends Edge Down / Up Alerts notifications even if the events happened within the configured delay interval.
Fixed Issue 67701: When configuring a Business Policy Rule, the drop down list for Object Groups cannot be seen on the VMware SD-WAN Orchestrator UI when 20+ groups are configured.
Even with 5+ Object Groups (Address Group, Port Group) configured, the Object Group drop down list appears near the bottom of the browser screen. With 20+ rules the Object Groups list is completely out of the screen, and it’s impossible to see it unless the user zooms out a lot on the browser but by then the text is so tiny as to also be unusable.
Fixed Issue 70018: A VMware SD-WAN Orchestrator running Release 4.3.0 or higher may not be able to form a Disaster Recovery pair.
The root cause prevents the Orchestrator from getting free disk space size necessary to do DR and the DR pairing may fail as a result.
Fixed Issue 71399: Or a VMware SD-WAN Orchestrator deployed in a Disaster Recovery (DR) configuration, the Operator User may observe that the Standby Orchestrator has failed to synchronize with the Active Orchestrator.
On the Orchestrator UI under the Replication page, a user would observe all Sync activities as failed under the Activity Monitor. The DR synchronization failure happens on initial handshake where the Active Orchestrator fails to copy the configuration database to the Standby Orchestrator.

Cloud Web Security Resolved Issues

Resolved in Version R450-20210922-GA

The below issues have been resolved since Edge version R440-20210702-GA-61583.

Fixed Issue 62978: For an enterprise using VMware Cloud Web Security, if a client user opens a Chrome browser in Incognito and attempts to download a file, the download may fail and if it does the user may see an error screen that lacks VMware branding.
In the above scenario where a file download fails (which is covered in Issue #62934) the error screen "Error occurred contact your administrator" should show VMware branding, but instead shows No branding. If a user encounters this, it should be understood this is not an expected outcome.

Without the fix, the workaround is to allow 3rd party cookies in browser.
Fixed Issue 64429: A customer enterprise using VMware Cloud Web Security, where a Cloud Web Security policy is configured and applied using internet backhaul, a UDP transfer to a server in Internet, initiated by a Client Behind Edge, with DF bit set, UDP transfer will fail.
Cloud Web Security will receive MTU sized packets, but will need to send ICMP unreachable message back to sender, as fragmentation is not allowed due to Do Not Fragment (DF) bit set. Cloud Web Security is executing DNAT (destination network address translation) to the wrong source IP address and is sending a "ICMP unreachable fragmentation needed" message to Client instead of sending it back to Server.
Fixed Issue 65115: For a customer using VMware Cloud Web Security, if SAML authentication is configured, a user may not be able access any websites.
With SAML (Security Assertion Markup Language) authentication turned on, if a user accesses any website it results in an authentication loop where access to the IdP (Identify Provider) itself requires authentication and fails.

Without the fix, the workaround is to add an SSL Exception in the security policy to allow access to the IdP login URL without authentication.
Fixed Issue 72485: For a customer using Cloud Web Security, whenever the customer edits the existing CASB Exception Rule, and changes the selected application in the Wizard, all applications controls were set to 'allowed'.
The CASB Exception Rule wizard on the VMware Orchestrator does not keep the existing control values upon the change of a selected application.

Secure Access Resolved Issues

Resolved in Version R450-20210922-GA

The below issues have been resolved since Edge version R440-20210702-GA-61583.

Fixed Issue 62421: When using Secure Access, traffic to resources could fail if a subnet is conflicting with an existing route exchanged by associated with a conflicting subnet.
Secure Access traffic to resources will fail if the subnet chosen for Secure Access is conflicting with an existing internal customer subnet. This is due to a lack of a check for conflicting IP ranges in the Secure Access service.

Known Issues

Open Issues in Release 4.5.0

The known issues are grouped as follows.

Edge/Gateway Known Issues
Orchestrator Known Issues
Cloud Web Security Known Issues
Secure Access Known Issues

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 primary with a non-global CDE segment running on the LAN interface.
Issue 32731:
Conditional default routes advertised via OSPF may not be withdrawn properly when the route is turned off. Re-enabling and disabling the route will retract it successfully.
Issue 32960:
Interface “Autonegotiation” and “Speed” status might be displayed incorrectly on the Local Web UI for activated VMware SD-WAN Edges.
Issue 32981:
Hard-coding speed and duplex on a DPDK-enabled port may require a VMware SD-WAN Edge reboot for the configurations to take effect as it requires disabling DPDK.
Issue 34254:
When a Zscaler CSS is created and the Global Segment has FQDN/PSK settings configured, these settings are copied to Non-Global Segments to form IPsec tunnels to a Zscaler CSS.
Issue 35778:
When there are multiple user-defined WAN links on a single interface, only one of those WAN links can have a GRE tunnel to Zscaler.

Workaround: Use a different interface for each WAN link that needs to build GRE tunnels to Zscaler.
Issue 35807:
A DPDK routed interface will be disabled completely if the interface is disabled and re-enabled from the VMware SD-WAN Orchestrator.
Issue 36923:
Cluster name may not be updated properly in the NetFlow interface description for a VMware SD-WAN Edge which is connected to that Cluster as its Hub.
Issue 38682:
A VMware SD-WAN Edge acting as a DHCP server on a DPDK-enabled interface may not properly generate “New Client Device" events for all connected clients.
Issue 38767:
When a WAN overlay that has GRE tunnels to Zscaler configured is changed from auto-detect to user-defined, stale tunnels may remain until the next restart.

Workaround: Restart the Edge to clear the stale tunnel.
Issue 39134:
The System health statistic “CPU Percentage” may not be reported correctly on Monitor > Edge > System for the VMware SD-WAN Edge, and on Monitor > Gateways for the VMware SD-WAN Gateway.

Workaround: Users should use handoff queue drops for monitoring Edge capacity not CPU percentage.
Issue 39374:
Changing the order of VMware SD-WAN Partner Gateways assigned to a VMware SD-WAN Edge may not properly set Gateway 1 as the local Gateway to be used for bandwidth testing.
Issue 39608:
The output of the Remote Diagnostic “Ping Test” may display invalid content briefly before showing the correct results.
Issue 39624:
Ping through a subinterface may fail when the parent interface is configured with PPPoE.
Issue 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 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 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 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 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 48597: Multihop BGP neighborship does not stay up if one of the two paths to the peer goes down
If there is a Multihop BGP neighborship with a peer to which there are multiple paths and one of them goes down, user will notice that the BGP neighborship goes down and does not come up using the other available path(s). This includes the Local IP-loopback neighborship case too.

Workaround: There is no workaround for this issue.
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 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 51436: For a site using an Enhanced High-Availability topology while deploying a VMware SD-WAN Edge using an LTE modem, if the site gets into a "split-brain" state, the HA failover takes ~5-6 minutes.
As part of the recovery from a split-brain state, the LAN ports are brought down on the Active Edge and this impacts LAN traffic during the time the ports are down and until the site can recover.

Workaround: There is no workaround for this issue
Issue 53219: After a VMware SD-WAN Hub Cluster rebalances, a few Spoke Edges may not have their RPF interface/IIF set properly.
On the affected Spoke Edges, multicast traffic will be impacted. What happens is that after a cluster rebalance, some of the Spoke Edge fail to send a PIM join.

Workaround: This issue will persist until the affected Spoke Edge has an Edge Service restart.
Issue 53337: Packet drops may be observed with an AWS instance of a VMware SD-WAN Gateway when the throughput is above 3200 Mbps.
When traffic exceeds a throughput above 3200 Mbps and a packet size of 1300 bytes, packets drops are observed at RX and at IPv4 BH handoff.

Workaround: There is no workaround for this issue.
Issue 53359: BGP/BFD session may fail during some DDoS attack scenarios.
If traffic is flooded from the client connected to the routed interface to the LAN client, the BGP/BFD session can fail. Also when real-time high priority traffic is flooded to the overlay destination, the BGP/BFD session can fail.

Workaround: There is no workaround for this issue.
Issue 53934: In an enterprise where a VMware SD-WAN Hub Cluster is configured, if the primary Hub has Multihop BGP neighborships on the LAN side, the customer may experience traffic drops on a Spoke Edge when there is a LAN side failure or when BGP is disabled on all segments.
In a Hub cluster, the primary Hub has Multihop BGP neighborship with a peer device to learn routes. If the physical interface on the Hub by which BGP neighborship is established, goes down, then BGP LAN routes may not become zero despite BGP view being empty. This may cause Hub Cluster rebalancing to not happen. The issue may also be observed when BGP is disabled for all segments and when there are one or more Multihop BGP neighborships.

Workaround: Restart the Hub which had the LAN-side failure (or BGP disabled).
Issue 57210: Even when a VMware SD-WAN Edge is working normally and is able to reach the internet, the LED in the Local UI's Overview page shows as "Red".
The Edge's Local UI determines the Edge's connectivity by whether it can resolve a well-known name via Google's DNS resolver (8.8.8.8). If it cannot do so for any reason, then it thinks it is offline and shows the LED as red.

Workaround: There is no workaround for this issue, except to ensure that DNS traffic to 8.8.8.8 can reach the destination and be resolved successfully.
Issue 61543: If more than one 1:1 NAT rule is configured on different interfaces with the same Inside IP, the inbound traffic can be received on one interface and the outbound packets of the same flow can be routed via different interface.
For the NAT flows from Outside to Inside, the 1:1 NAT rules will be matched against the Outside IP and the interface where the packets are received. For the outbound packets of the same flow, the VMWare SD-WAN Edge will try to match the NAT rules again comparing the Inside IP and the outbound traffic can be routed via the interface configured in the first matching rule with "Outbound Traffic" enabled.

Workaround: There is no workaround for this issue outside of ensuring no more than one 1:1 NAT rule is configured with a particular Inside IP address.
Issue 62701: For a VMware SD-WAN Edge deployed as part of an Edge Hub Cluster, If Cloud VPN is not enabled under the Global Segment but is enabled under a Non-Global Segment, a control plane update sent by the Orchestrator may cause all the WAN links to flap on the Hub Edge.
The Hub Edge's WAN links going down, then up in rapid succession (flap) will impact real time traffic like voice calls. This issue was observed on a customer deployment where Cloud VPN was not enabled on the Hub Edge's Global segment, but the Cluster configuration was enabled which means this Hub Edge was part of a Cluster (and a Cluster configuration is applicable to all segments). When a configuration change is pushed to the Hub Edge, the Hub Edge's dataplane will start parsing data and will start with the Global Segment where it will see Cloud VPN not enabled and the Hub Edge erroneously thinks clustering is disabled on this Global Segment. As a result, the Hub Edge will tear down all tunnels from the Hub's WAN link(s) which will cause link flaps on all that Edge's WAN links. For any such incident the WAN links only go down and recover a single time per control pane update.

Workaround: The workaround is to enable Cloud VPN on the Global Segment.
Issue 63629: In a network topology where the VMware SD-WAN Hub Edge and Spoke Edge have different IP family preferences (in other words, IPv4/IPv6 dual stack), the customer can see more bandwidth allocated to the peer than expected.
If both families IPv4 and IPv6 are enabled, the Edge internally creates two different link objects. The bandwidth values are added for both of them when it should be added only for one.

Workaround: The workaround for this issue is to not have different tunnel preferences if Hub/Spoke topology have dual stack enabled.
Issue 64627: A VMware SD-WAN Gateway may experience a Dataplane Service restart, causing 3-5 seconds of traffic disruption.
When there are a large number of sub-paths configured on a VMware SD-WAN Edge's WAN links or there are frequent flaps of of the VeloCloud Management Plane (VCMP) tunnels, it may lead to the exhaustion of the counters and the ultimate Dataplane Service restart of the Gateway.

Workaround: There is no workaround for this issue.
Issue 65560: Traffic from a customer to PE (Provider Edge) device fails.
BGP neighborship between a Partner Gateway and Provider Edge does not get established when tag-type is selected as "none" on the handoff configuration. This is because ctag, stag values get picked from /etc/config/gatewayd instead of the handoff configuration on the Orchestrator when tag-type is "none".

Workaround: Update the ctag, stag values to 0 each under vrf_vlan->tag_info in /etc/config/gatewayd. Do a vc_procmon restart.
Issue 67458: When a VMware SD-WAN Hub Edge with a large number of Spoke Edges is upgraded to Release 4.2.1 or later, some tunnels to other Spoke Edges will not come up for the Hub Edge.
A large number of Spoke Edges is understood at ~1000 or more. This issue is not consistent, but generally ~1/3rd of the VeloCloud Management Protocol (VCMP) tunnels are not established between the Hub Edge and the connected Spoke Edges. This is caused by the Hub Edge ignoring the
MP_INITs as the number of half open TDs exceeds the Hub Edge's upper limit.

Workaround: Restarting the Edge Service will restore full tunnel connectivity.
Issue 67879: A Cloud Security Service (CSS) tunnel is deleted after a user changes a WAN Overlay setting from auto-detect to user-defined on a WAN interface setting.
After saving the changes, the CSS tunnels do not come back up until the customer takes down and then puts back up the tunnel. Changing the WAN configuration will bring down the CSS tunnel and parse the CSS setup again. However, in some corner cases, the nvs_config->num_gre_links is 0 and the CSS tunnel fails to come up.

Workaround: Disable and then enable the CSS setup will bring the CSS tunnel up
Issue 68057: DHCPv6 release packet is not sent from the VMware SD-WAN Edge on the changing of a WAN interface address mode from DHCP stateful to static IPv6 address and the lease remains active till reaching its valid time.
The DHCPv6 client possesses a lease which it does not release when the configuration change is done. The lease remains valid till its lifetime expires in the DHCPv6 server and is deleted.

Without the fix, there is no way of remediating this issue as the lease would remain active till valid lifetime.
Issue 68851: If a VMware SD-WAN Edge and VMware SD-WAN Gateway each have the same TCP syslog server configured, the TCP connection is not established from the Edge to the syslog server.
If the Edge and Gateway each have the same TCP server and if the syslog packets from the Edge are routed via the Gateway, the syslog server sends a TCP reset to the Edge.

Workaround: Send the syslog packets direct from the Edge instead of routing via a Gateway or configure a different syslog server for the Edge and Gateway..
Issue 69284: For a site using a High-Availability topology where the Edges deploy VNF's in an HA configuration and are using Release 4.x, if these HA Edges are downgraded to a 3.4.x Release where HA VNF's are not supported, and then upgraded to 4.5.0, when the HA VNF's are reenabled, the Standby Edge VNF will not come up.
The VNF state on the Standby Edge is communicated as down via SNMP. If the HA VNF pair is downgraded from a version supporting VNF-HA (release 4.0+) to a release which does not support it with VNF enabled on the Orchestrator. This issue will be seen when the Edge is upgraded back to a version supporting VNF-HA and it is enabled on the Orchestrator again.

Workaround: VNF should first be deactivated in the case of an HA if the Edge is being downgraded to a version which does not support it.
Issue 69562: Traffic failure is observed on a VMware SD-WAN Gateway when both Partner Gateway-BGP and Non SD-WAN Destination-BGP have the same local Autonomous System Number (ASN).
When both PG-BGP and NSD-BGP have the same local ASN and an NSD-BGP learned route is redistributed into a PG-BGP, the ASN will get prepended twice on the route before advertisement. This may cause some other BGP route to get preferred over this one due to a shorter AS path, possibly causing traffic matching the wrong route.

Without this fix, the workaround to this issues is to have different ASN's for PG-BGP and NSD-BGP.
Issue 70311: A VMware SD-WAN Edge may suffer a Dataplane Service Failure and restart as a result.
During the Edge service restart, customer traffic would be disrupted for ~15-30 seconds. This issue occurs inconsistently, but when it does occur the Edge is tearing down an IKE security association (SA). This typically only occurs when: the SA timer (as configured on the VMware SD-WAN Orchestrator) expires; or the user modifies the IPSec configuration on the Orchestrator.

Workaround: There is no workaround for this issue.
Issue 71719: PPTP Connection is not Established along Edge to Cloud path.
Connection to the PPTP server behind the VMware SD-WAN Edge does not get established.

Workaround: There is no workaround for this issue, not even an Edge restart or reboot.
Issue 72358: If the IP address of a VMware SD-WAN Orchestrator DNS name changes, the VMware SD-WAN Gateway's management plane process fails to resolve it properly and the Gateway will be unable to connect to the Orchestrator.
The Gateway's management process periodically checks the DNS resolution of the Orchestrator's DNS name, to see if it has changed recently so that the Gateway can connect to the right host. The DNS resolution code has an issue in it so that all of these resolution checks fail, and the Gateway will keep using the old address and thus no longer be able to connect to the Orchestrator.

Workaround: Until this issue is resolved, an Operator User should not change the IP address of the Orchestrator. If the Orchestrator's IP address must be changed, all Gateways connecting to that Orchestrator will have to be reactivated.
Issue 82188: For VMware SD-WAN LTE models (Edge 510-LTE, 610-LTE), when the IPv6 setting is toggled off, the tunnels via CELL interface may fail.
When the IPv6 checkbox in Device Settings is turned off, the internal state of the CELL interface goes to UNKNOWN. This is not updated even when the IPv6 setting is toggled to on for the CELL interface. Due to this the tunnels via the CELL interface would fail. If the LTE Edge is only using CELL interfaces for traffic this result in the Edge going offline and would drop all Edge traffic which would be very disruptive to the customer.

Workaround: Without the fix, a user would need to restart the Edge Service after toggling the IPv6 setting off. If the Edge is offline because it only uses the CELL interface for bandwidth, a local user would need to power cycle the Edge to recover it.
Issue 83212: When looking at the VMware SASE Orchestrator for Monitor > Edge > Transport, there is a discrepancy between the Link and Application statistics table.
The Application and Link statistics should be match but the Application statistics show a higher value than the Link statistics. This issue is most commonly occurs where there is a VMware SD-WAN Edge Hub Cluster topology where the Spoke Edge uses a single WAN link. If this single WAN link experiences some loss, the packets are retransmitted and are accounted twice in Application statistics which results in the observed discrepancy.

Workaround: There is no workaround for this issue but Applications statistics will be correct versus Link statistics when this issue is encountered.
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.
Issue 85369: For a site deployed with a High-Availability topology, the customer may observe customer traffic disruptions and possibly multiple reboots of the VMware SD-WAN Standby Edge.
A condition triggered by load and system events causes the Active Edge to experience delays in the timely delivery of HA heartbeats to the Standby Edge. The delay causes the Standby Edge to miss heartbeats and incorrectly assume the Active role causing an Active-Active state. To recover from the Active-Active state the Standby Edge reboots, possibly multiple times.

If the site does become Active-Active, a conventional HA setup would experience minimal traffic disruption since the Standby Edge does not pass traffic in this topology, but on an Enhanced HA deployment, where the Standby Edge is also passing traffic, the reboot(s) would disrupt some customer traffic.

Workaround: There is no workaround for this issue.
Issue 91365: For a customer using Edge Network Intelligence, an VMware SD-WAN Edge where Analytics is configured experiences a memory leak that will result in the Edge triggering an Edge Service restart to clear the memory.
When the Analytics function is enabled on an Edge, the Edge's Dataplane service begins leaking memory at a steady rate that will result in the Edge needing to trigger an unscheduled Service Restart to clear the memory leak when it reaches a critical level (60% memory utilization for longer than 90 seconds). An Edge Service restart causes a 10-15 second disruption in customer traffic. In the field the time it takes to trigger an Edge Service restart has been ~3 to 4 days, and once the memory is cleared the memory leak will resume with the same general time window for the next Edge Service restart. The period when the Edge would reach a critical memory usage level depends on the Edge model and the amount of information the Analytics feature is recording for that Edge.

Workaround: The customer has two options, a) temporarily turn off Analytics for the Edge until a fixed Edge build is delivered; or b) monitor the Edge's memory. When memory utilization reaches 40% and the Orchestrator records a Memory Warning Event, schedule a manual Edge Service Restart in a maintenance window to clear the memory and ensure minimal customer impact.
Issue 92676: For a customer deployment where a Non VMware SD-WAN Destination (NSD) via Gateway is configured to use redundant tunnels and redundant Gateways and is also using BGP over IPsec, if the Primary and Secondary Gateways advertise a prefix with an equal AS path to the Primary and Secondary NSD tunnels, the Primary NSD tunnel will prefer a redundant Gateway path over the Primary Gateway.
The impact of the Primary NSD over Gateway tunnel preferring the redundant Gateway path over the Primary Gateway is experienced only for return traffic to the Gateway from the NSD.

Workaround: Configure a higher (3 or more) metric on the redundant Gateway for the interested prefix as this will help the NSD's primary tunnel choose the Primary Gateway for return traffic.

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 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 47269:
The VMware SD-WAN 510-LTE interface may appear for Edge models that do not support an LTE interface.
Issue 47713:
If a Business Policy Rule is configured while Cloud VPN is disabled, the NAT configuration must be reconfigured upon enabling Cloud VPN.
Issue 47820:
If a VLAN is configured with DHCP disabled at the Profile level, while also having an Edge Override for this VLAN on that Edge with DHCP enabled, and there is an entry for the DNS server field set to none (no IP configured), the user will be unable to make any changed on the Configure > Edge > Device page and will get an error message of ‘invalid IP address []’ that does not explain or point to the actual problem.
Issue 48085:
The VMware SD-WAN Orchestrator allows a user to delete a VLAN which is associated with an interface.
Issue 48737:
On a VMware SD-WAN Orchestrator which is using the Release 4.0.0 new user interface, If a user is on a Monitor page and changes the Start & End time interval and then navigates between tabs, the Orchestrator does not update Start & End interval time to the new values.
Issue 49225:
VMware SD-WAN Orchestrator does not enforce a limit of 32 total VLANs.
Issue 49790:
When a VMware SD-WAN Edge is activated to Release 4.0.0, the activation is posted twice in Events.

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

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

Workaround: The next operator may refresh that page prior to logging in to prevent seeing the errors, or each Operator may use different browser windows to avoid this display issue.
Issue 51722: On the Release 4.0.0 VMware SD-WAN Orchestrator, the time range selector is no greater than two weeks for any statistic in the Monitor > Edge tabs.
The time range selector does not show options greater than "Past 2 Weeks" in Monitor > Edge tabs even if the retention period for a set of statistics is much longer than 2 weeks. For example, flow and link statistics are retained for 365 days by default (which is configurable), while path statistics are retained only for 2 weeks by default (also configurable). This issue is making all monitor tabs conform to the lowest retained type of statistic versus allowing a user to select a time period that is consistent with the retention period for that statistic.

Workaround: A user may use the "Custom" option in the time range selector to see data for more than 2 weeks.
Issue 60039: RMA Reactivation does not work when the VMware SD-WAN Edge model is changed.
When performing an RMA Reactivation for a site where the Edge model is also being changed, the VMware SD-WAN Orchestrator does not save the model change making the reactivation link ineffective. This only affects RMA Reactivations where the Edge model is changed, an RMA Reactivation where the Edge model remains the same will work as expected.

Workaround: If using a different Edge model for a site, the user would need to create a new Edge and manually apply all Edge-specific settings.
Issue 60522: On the VMware SD-WAN Orchestrator UI, the user observes a large number of error messages when they try to remove a segment.
The issue can be observed when adding a segment to a profile and the associating the segment with multiple VMware SD-WAN Edges. When the user attempts to remove the added segment from the profile, they will see a large number of error messages.

Workaround: There is no workaround for this issue.
Issue 62624: User sees the Customer name when attempting to uncheck the Partner Gateway checkbox while the Partner Gateway is in use.
When a user unchecks the Partner Gateway checkbox for a particular Gateway on the VMware SD-WAN Orchestrator UI while the Gateway is used by one or more customers and a customer profile as well, the Orchestrator shows only the name of the Profile and Edge not the name of the customer names using the Gateway.
Issue 68463: When using the New UI on the VMware SD-WAN Orchestrator and looking at the QoE section, the wrong graph values are shown.
When going on QoE in the old UI "Latency Fair" is displayed on the graph, whereby when visiting the new UI (for the same Edge and time) "Jitter Fair" is displayed. This is caused by QoE being incorrectly mapped on the New UI.

Workaround: There is no work around for this issue beyond using the Old UI to confirm correct QoE values.

Cloud Web Security Known Issues

Issue 62934: For an enterprise using VMware Cloud Web Security, if a client user opens a Chrome browser in Incognito and attempts to download a file, the download may occasionally not be successful.
Incognito requires enabling 3rd party cookies. Turn on 3rd party cookies and retry the operation. On an unsuccessful download the user would observe a screen which reads either "Error occurred contact your administrator" or for files from a custom web server: "This page is not working". Occasionally some web servers or Files may have a variance in File signature, that the Cloud Web Security Service may not be able to recognize, and hence this issue.

Workaround: Turn on allowing 3rd party Cookies and retry. No known workaround for this issue if using an Incognito window.
Issue 63149: When a customer deployment has overlapping subnets in a profile and configures a subnet for a VMware Cloud Web Security policy, and associates the Cloud Web Security policy to the profile and segment, Edge clients on that subnet will not be able to connect to the internet.
If there are overlapping subnets configured for the LAN segments behind VMware SD-WAN Edges within the same segment, then the resources behind the Edges cannot have Cloud Web Security policies applied for the internet-bound traffic. This is because there is no way to uniquely identify the destination Edge for the return traffic from the internet to Cloud Web Security.

Workaround: Turn on LAN side NAT on the Edge and have a unique subnet represent the traffic originated from resources behind the Edge.
Issue 65001: For a customer using VMware Cloud Web Security, a user cannot configure the Inspection Engine to turn on/off File Hash checks when using the VMware Orchestrator to do so.
When a user is using the Orchestrator to configure the Cloud Web Security Inspection engine's File Hash check parameter for either "Action for Unknown File Download" and "Action for unknown document Download", these changes are not sent to the Inspection Engine and are not applied.

Workaround: There is no workaround for this issue.

Secure Access Known Issues

Issue 64541: For a customer using VMware Secure Access, when using the option in Workspace ONE UEM Configuration to configure Tunnel Hostname within the Organization Group, if a user selects 'Yes', the hostname will be created in the UEM console automatically instead of being configured manually.
The user should have the option to configure the hostname manually and not just have it automatically created.

Workaround: The workaround is to manually set it in the UEM console.
Issue 70493: When a customer edit's a VMware Secure Access service configuration and disables/removes association of a Cloud Web Security policy, saving the configuration fails.
Editing a Secure Access service configuration where a Cloud Web Security policy is being removed fails with an "Invalid CWS Policy" error.

Workaround: There is no workaround for this issue.