NSX for vSphere 6.2.3 Release Notes

Document updated 22 August 2016
NSX for vSphere 6.2.3   |   Released 09 June 2016   |   Build 3979471

What's in the Release Notes

The release notes cover the following topics:

What's New

See important information about NSX 6.2.3.

See what's new and changed in NSX 6.2.3, 6.2.2, 6.2.1 and 6.2.0.

Important Information about NSX for vSphere 6.2.3

Note: VMware identified an issue in VMware NSX for vSphere 6.2.3 that can affect both new NSX customers as well as customers upgrading from previous versions of NSX. As a result, VMware made the decision to remove NSX 6.2.3 from distribution. The current version available is NSX for vSphere is version 6.2.2. VMware is actively working towards releasing the next version to replace NSX for vSphere 6.2.3.

Customers who have already upgraded to 6.2.3 are advised to review the following:

The 6.2.3 release delivers a security patch CVE-2016-2079 which is a critical input validation vulnerability for sites that uses NSX SSL VPN. Customers who use SSL VPN are strongly advised to review CVE-2016-2079 and contact VMware support to request immediate assistance. For questions or concerns, contact VMware Support. See How to file a Support Request in My VMware  or How to Submit a Support Request.

For customers in the process of installing or upgrading to NSX 6.2.3, VMware recommends waiting until the replacement for NSX 6.2.3 is released. This replacement version will contain fixes for bugs that have been found in NSX 6.2.3.

New in 6.2.3

The 6.2.3 release delivers a security patch CVE-2016-2079 which is a critical input validation vulnerability for sites that uses NSX SSL VPN. It also includes a number of bug fixes documented in the Resolved Issues section.

Changes introduced in NSX vSphere 6.2.3:

  • Logical Switching and Routing

    • NSX Hardware Layer 2 Gateway Integration: expands physical connectivity options by integrating 3rd-party hardware gateway switches into the NSX logical network

    • New VXLAN Port 4789 in NSX 6.2.3 and later: Before version 6.2.3, the default VXLAN UDP port number was 8472. See the NSX Upgrade Guide for details.

  • Networking and Edge Services

    • New Edge DHCP Options: DHCP Option 121 supports static route option, which is used for DHCP server to publish static routes to DHCP client; DHCP Options 66, 67, 150 supports DHCP options for PXE Boot; and DHCP Option 26 supports configuration of DHCP client network interface MTU by DHCP server.

    • Increase in DHCP Pool, static binding limits: The following are the new limit numbers for various form factors: Compact: 2048; Large: 4096; Quad large: 4096; and X-large: 8192.

    • Edge Firewall adds SYN flood protection: Avoid service disruptions by enabling SYN flood protection for transit traffic. Feature is disabled by default, use the NSX REST API to enable it.

    • NSX Edge — On Demand Failover: Enables users to initiate on-demand failover when needed.

    • NSX Edge — Resource Reservation: Reserves CPU/Memory for NSX Edge during creation. You can change the default CPU and memory resource reservation percentages using this API. The CPU/Memory percentage can be set to 0 percent each to disable resource reservation.

      PUT https://<NSXManager>/api/4.0/edgePublish/tuningConfiguration

                  <tuningConfiguration>
                     <lockUpdatesOnEdge>false</lockUpdatesOnEdge>
                     <aggregatePublishing>true</aggregatePublishing>
                     <edgeVMHealthCheckIntervalInMin>0</edgeVMHealthCheckIntervalInMin>
                     <healthCheckCommandTimeoutInMs>120000</healthCheckCommandTimeoutInMs>
                     <maxParallelVixCallsForHealthCheck>25</maxParallelVixCallsForHealthCheck>
                     <publishingTimeoutInMs>1200000</publishingTimeoutInMs>
                     <edgeVCpuReservationPercentage>0</edgeVCpuReservationPercentage>
                     <edgeMemoryReservationPercentage>0</edgeMemoryReservationPercentage>
                     <megaHertzPerVCpu>1000</megaHertzPerVCpu>
                  </tuningConfiguration>
                

    • Change in NSX Edge Upgrade Behavior: Replacement NSX Edge VMs are deployed before upgrade or redeploy. The host must have sufficient resources for four NSX Edge VMs during the upgrade or redeploy of an Edge HA pair. Default value for TCP connection timeout is changed to 21600 seconds from the previous value of 3600 seconds.

    • Cross VC NSX — Universal Distributed Logical Router (DLR) Upgrade: Auto upgrade of Universal DLR on secondary NSX Manager, once upgraded on primary NSX Manager.

    • Flexible SNAT / DNAT rule creation: vnicId no longer needed as an input parameter; removed requirement that the DNAT address must be the address of an NSX Edge VNIC.

    • NSX Edge VM (ESG, DLR) now shows both Live Location and Desired Location. NSX Manager and NSX APIs including GET api/4.0/edges//appliances now return configuredResourcePool and configuredDataStore in addition to current location.

    • Edge Firewall adds SYN flood protection: Avoid service disruptions by enabling SYN flood protection for transit traffic. Feature is disabled by default, use the NSX REST API to enable it.

    • NSX Manager exposes the ESXi hostname on which the 3rd-party VM Series firewall SVM is running to improve operational manageability in large-scale environments.

    • NAT rule now can be applied to a VNIC interface and not only an IP address.

    • New configuration option to set the load balancer session aging time: This release delivers a new application rule command to set the session aging timeout value for both the server and client. If the pool is shared among multiple virtual servers, the maximum value will be set for it.

    • New NSX API to change the autodraft setting for NSX distributed firewall: Starting with NSX 6.2.3, the following PUT API can be used to change the autodraft setting for the NSX distributed firewall:

      • Get the existing GlobalConfiguration:
        GET https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
      • Note: GET will not show the autoDraftDisabled field.

      • Add autoDraftDisabled config property to the global configuration and execute a PUT API call:
        PUT https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
      • Request body:
          <globalConfiguration>
            <layer3RuleOptimize>...</layer3RuleOptimize>
            <layer2RuleOptimize>...</layer2RuleOptimize>
            <tcpStrictOption>...</tcpStrictOption>
            <autoDraftDisabled>true</autoDraftDisabled>
        </globalConfiguration>
          

  • Security Services

    • Distributed Firewall — TFTP ALG: Enables use cases such as network boot for VMs.

    • Firewall — Granular Rule Filtering: Simplifies troubleshooting by providing granular rule filters in UI, based on Source, Destination, Action, Enabled/Disabled, Logging, Name, Comments, Rule ID, Tag, Service, Protocol.

    • Guest Introspection — Windows 10 support

    • SSL VPN Client — Mac OS El Capitan support

    • Service Composer — Performance Improvements: Enables faster startup/reboot of NSX Manager by optimizing synchronization between security policy and firewall service, and disabling auto-save of firewall drafts by default.

    • Service Composer — Status Alarms: Raises system alarm if security policy is out-of-sync, and takes specific actions based on alarm code to resolve issue.

    • Reduction in firewall heap memory usage: Firewall usage of IP address sets has been optimized to reduce heap memory usage.

  • Operations and Troubleshooting

    • NSX Dashboard: Simplifies troubleshooting by providing visibility into the overall health of NSX components in one central view.

    • Traceflow Enhancement — Network Introspection Services: Enhances ability to trace a packet from source to destination, by identifying whether packets were forwarded to 3rd-party network introspection services, and whether the packet comes back from the 3rd-party service VM or not.

    • SNMP Support: Configure SNMP traps for events from NSX Manager, NSX Controller, and Edge.

    • Logging is now enabled by default for SSL VPN and L2 VPN. The default log level is notice.

    • Logging for IPsec VPN is now enabled by default Default log level is set to warning. If you wish to disable logging or change the log level, see the section, "Enable Logging for IPSec VPN" in the NSX Administration Guide.

    • Firewall rules UI now displays configured IP protocols and TCP/UDP port numbers associated with services.

    • NSX Edge technical support logs have been enhanced to report memory consumption per process.

    • Enhanced communication channel health status monitoring with new event log messages reported when the channel health status changes for a server or a cluster.
    • Central CLI Enhancements

      • Central CLI for Host Health: Shows host health status, with 30+ checks in one command (including network config, VXLAN config, resource utilization, etc.)

      • Central CLI for Packet Capture: Provides ability to capture packet on the host and transfer the capture file to user’s remote server. This eliminates the need to open up hypervisor access to network administrators, when troubleshooting logical network issues.

    • Technical support bundle per host: Gathers per-host logs and creates a bundle that can be saved and submitted to VMware technical support for assistance.

  • Licensing Enhancements

    • Change in default license & evaluation key distribution: default license upon install is "NSX for vShield Endpoint", which enables use of NSX for deploying and managing vShield Endpoint for anti-virus offload capability only. Evaluation license keys can be requested through VMware sales.

    • License usage reporting: NSX license usage counts are displayed on NSX Manager's Summary UI and also retrievable via API. NSX license usage counts will no longer be reported through vCenter licensing service.

  • Load Balancer (LB) Enhancements

    • Configurable session timeout for VIP configured without acceleration: Ability to configure Load Balancing L7 engine (no acceleration) VIP timeout above 5 minutes using the Application Rule "timeout client 3600s".

    • Statistics enhancement on CLI: Global statistics are now available through CLI. Specific VIP and pool statistics are also available.

    • LB with acceleration enhancement : Load Balancing L4 engine (acceleration enabled) will now always honor the health checks UDP, TCP source IP hash, and invalidate persistent entry.

    • Log refinements: Load Balancer log improvements.

    • Configurable SSL authentication: Ability to configure SSL server authentication in case of VIP with end-to-end SSL.

    • Source IP Persistent table enhancement: Even after a configuration change, the Source IP Persistence table remains available.

    • NSX Edge load balancer system control (sysctl) sysctl.net.ipv4.vs.expire_nodest_conn parameter added to NSX Manager whitelist: The sysctl.net.ipv4.vs.expire_nodest_conn to change the persistent connection status.

  • Solution Interoperability

    • Customer Experience Improvement Program: NSX supports reporting system statistics via the VMware Customer Experience Improvement Program (CEIP). Participation is optional and is configured in the vSphere Web Client.

    • VMware vRealize Log Insight 3.3.2 for NSX provides intelligent log analytics for NSX, with monitoring and troubleshooting capabilities and customizable dashboards for network virtualization, flow analysis and alerts. This version accepts NSX Standard/Advanced/Enterprise edition license keys issued for NSX 6.2.2+.​

    • vShield Endpoint Management Support: NSX supports management of vShield Endpoint anti-virus offload capabilitie. Customers who purchased vSphere with vShield Endpoint (Essentials Plus and above) can download NSX from the vSphere download site. For more information, refer to VMware knowledge base article 2110078 and VMware knowledge base article 2105558.

    New in 6.2.2

    The 6.2.2 release delivers a security patch to address the glibc vulnerability and includes a number of bug fixes documented in the Resolved Issues section. This release includes the same critical bug fixes that were provided in all the 6.1.4-based and 6.1.5-based patches. For NSX 6.1.x users, this same set of patch fixes is available in the NSX 6.1.6 release.

    The main features of this release are:

    • CVE-2015-7547 (glibc) security patch: This patch addresses CVE-2015-7547, also known as the glibc vulnerability.

    • Issue 1600484: Removal of constraint validations on DHCP domain name configurations NSX 6.2.2 re-enables support for DHCP pools with ".local" domains. See VMware knowledge base article 2144097.

    • Issue 1586149: DFW UI Enhancements for better user experience. In the previous implementation, the table used to scroll the grid to the very first item of grid when a user made a change. In the fixed implementation, whenever a rule is added, the grid scrolls to the newly added rule. Now, when refreshing the grid data for any reason (e.g. after publishing or reverting changes), the vertical scroll position of the grid is maintained.

    • Issue 1592562: Behavior change when a new Edge Service is configured. Prior to 6.2.2, when a new Edge Service is configured, it is enabled by default. In 6.2.2, this behavior has changed. Now, if the current license supports the feature, then by default the feature is enabled. Otherwise, the feature is disabled.

    New in 6.2.1

    The 6.2.1 release delivers a number of bug fixes that have been documented in the Resolved Issues section.

    • 6.1.5 fixes: Release includes the same critical fixes as NSX-vSphere 6.1.5 content.

    • Introduced new 'show control-cluster network ipsec status' command that allows uses to inspect the Internet Protocol Security (IPsec) state.

    • Connectivity status: NSX Manager user interface now shows the connectivity status of the NSX Controller cluster.

    • Support for vRealize Orchestrator Plug-in for NSX 1.0.3: With NSX 6.2.1 release, NSX-vRO plugin version 1.0.3 is introduced for use with vRealize Automation 7.0.0. This plugin includes fixes that improve performance when vRealize Automation 7.0 uses NSX for vSphere 6.2.1 as a networking and security end point.

    • Starting in 6.2.1, NSX Manager queries each Controller node in the cluster to get the connection information between that controller and the other controllers in the cluster.
      This is provided in the output of the NSX REST API ("GET https://[NSX-MANAGER-IP-ADDRESS]/api/2.0/vdn/controller" command), which now shows the peer connection status among the controller nodes. If NSX Manager finds the connection between any two controller nodes is broken, a system event is generated to alert the user.

    • Service Composer now exposes an API that enables users to configure auto creation of Firewall drafts for Service Composer workflows.
      This setting can be turned on/off using REST API and the changes can be saved across reboot. When disabled, no draft is created in the Distributed Firewall (DFW) for policy workflows. This limits the number of drafts that are auto-created in the system and provides better performance.

    New in 6.2.0

    NSX vSphere 6.2.0 included the following new and changed features:

    • Cross vCenter Networking and Security

      • NSX 6.2 with vSphere 6.0 supports Cross vCenter NSX where logical switches (LS), distributed logical routers (DLR) and distributed firewalls (DFW) can be deployed across multiple vCenters, thereby enabling logical networking and security for applications with workloads (VMs) that span multiple vCenters or multiple physical locations.

      • Consistent firewall policy across multiple vCenters: Firewall Rule Sections in NSX can now be marked as "Universal" whereby the rules defined in these sections get replicated across multiple NSX managers. This simplifies the workflows involving defining consistent firewall policy spanning multiple NSX installations

      • Cross vCenter vMotion with DFW: Virtual Machines that have policies defined in the "Universal" sections can be moved across hosts that belong to different vCenters with consistent security policy enforcement.

      • Universal Security Groups: Security Groups in NSX 6.2 that are based on IP Address, IP Set, MAC Address and MAC Set can now be used in Universal rules, whereby the groups and group memberships are synced up across multiple NSX managers. This improves the consistency in object group definitions across multiple NSX managers, and enables consistent policy enforcement

      • Universal Logical Switch (ULS): This new functionality introduced in NSX 6.2 as a part of Cross vCenter NSX allows creation of logical switches that can span multiple vCenters, allowing the network administrator to create a contiguous L2 domain for an application or tenant.

      • Universal Distributed Logical Router (UDLR): This new functionality introduced in NSX 6.2 as a part of Cross vCenter NSX allows creation of distributed logical routers that can span multiple vCenters. The universal distributed logical routers enable routing across the universal logical switches described earlier. In addition, NSX UDLR is capable of localized north-south routing based on the physical location of the workloads.

    • Operations and Troubleshooting Enhancements

      • New traceflow troubleshooting tool: Traceflow is a troubleshooting tool that helps identify if the problem is in the virtual or physical network. It provides the ability to trace a packet from source to destination and helps observe how that packet passes through the various network functions in the virtual network.

      • Flow monitoring and IPFIX separation: In NSX 6.1.x, NSX supported IPFIX reporting, but IPFIX reporting could be enabled only if flow reporting to NSX Manager was also enabled. Starting in NSX 6.2.0, these features are decoupled. In NSX 6.2.0 and later, you can enable IPFIX independent of flow monitoring on NSX Manager.

      • New CLI monitoring and troubleshooting commands in 6.2: See knowledge base article 2129062 for more information.

      • Central CLI: Central CLI reduces troubleshooting time for distributed network functions. Commands are run from the command line on NSX Manager and retrieve information from controllers, hosts, and the NSX Manager. This allows you to quickly access and compare information from multiple sources. The central CLI provides information about logical switches, logical routers, distributed firewall and edges.

      • CLI ping command adds configurable packet size and do-not-fragment flag: Starting in NSX 6.2.0, the NSX CLI 'ping' command offers options to specify the data packet size (not including the ICMP header) and to set the do-not-fragment flag. See the NSX CLI Reference for details.

      • Show health of the communication channels: NSX 6.2.0 adds the ability to monitor communication channel health. The channel health status between NSX Manager and the firewall agent, between NSX Manager and the control plane agent, and between host and the NSX Controller can be seen from the NSX Manager UI. In addition, the host command channel offers greater fault tolerance.

      • Standalone Edge L2 VPN client CLI: Prior to NSX 6.2, a standalone NSX Edge L2 VPN client could be configured only by 'deploy OVF' settings provided to the virtual center. Commands specific to standalone NSX Edge have been added to allow configuration using the command line interface.

    • Logical Networking and Routing

      • L2 Bridging Interoperability with Distributed Logical Router: With VMware NSX for vSphere 6.2, L2 bridging can now participate in distributed logical routing. The VXLAN network to which the bridge instance is connected, will be used to connect the routing instance and the bridge instance together.

      • Support of /31 prefixes on ESG and DLR interfaces per RFC 3021.

      • Enhanced support of relayed DHCP request on the ESG DHCP server.

      • Ability to preserve VLAN IDs/headers inside NSX virtual networks.

      • Exact Match for redistribution filters: The redistribution filter has same matching algorithm as ACL, so exact prefix match by default (except if le or ge options are used).

      • Support of administrative distance for static route.

      • Ability to enable, relax, or disable check per interface on Edge.

      • Display AS path in CLI command show ip bgp

      • HA interface exclusion from redistribution into routing protocols on the DLR control VM.

      • Distributed logical router (DLR) force-sync avoids data loss for east-west routing traffic across the DLR. North-south routing and bridging may continue experience an interruption.

      • View active Edge in HA pair: In the NSX 6.2 web client, you can find out if an NSX Edge appliance is the active or backup in an HA pair.

      • REST API supports reverse path filter (rp_filter) on Edge: Using the system control REST API, rp_filter sysctl can be configured through UI, and is also exposed through REST API for vNIC interfaces and sub-interfaces. See the NSX API documentation for more information.

      • Behavior of the IP prefix GE and IP prefix LE BGP route filters: In NSX 6.2, the following enhancements have been made to BGP route filters:

        • LE / GE keywords not allowed: For the null route network address (defined as ANY or in CIDR format 0.0.0.0/0), less-than-or-equal-to (LE) and greater-than-or-equal-to (GE) keywords are no longer allowed. In previous releases, these keywords were allowed.

        • LE and GE values in the range 0-7 are now treated as valid. In previous releases, this range was not valid.

        • For a given route prefix, you can no longer specify a GE value that is greater than the specified LE value.

    • Networking and Edge Services

      • The management interface of the DLR has been renamed to HA interface. This has been done to highlight the fact that the HA keepalives travel through this interface and that interruptions in traffic on this interface can result in a split-brain condition.

      • Load balancer health monitoring improvements: Delivers granular health monitoring that reports information on failures, keeps track of last health check and status change, and reports failure reasons.

      • Support VIP and pool port range: Enables load balancer support for applications that require a range of ports.

      • Increased maximum number of virtual IP addresses (VIPs): VIP support rises to 1024.

    • Security Service Enhancements

      • New IP address discovery mechanisms for VMs: Authoritative enforcement of security policies based on VM names or other vCenter-based attributes requires that NSX know the IP address of the VM. In NSX 6.1 and earlier, IP address discovery for each VM relied on the presence of VMware Tools (vmtools) on that VM or the manual authorization of the IP address for that VM. NSX 6.2 introduces the option to discover the VM's IP address by doing discovery from the hypervisor. These new discovery mechanisms enable NSX to enforce object based distributed firewall rules on VMs that do not have VMware Tools installed.

    • Solution Interoperability

      • Support for vSphere 6.0 Platform Services Controller topologies: NSX now supports external Platform Services Controllers (PSC), in addition to the already supported embedded PSC configurations.

      • Support for vRealize Orchestrator Plug-in for NSX: NSX 6.2 supports the NSX-vRO plug-in for integration of NSX with vRealize Orchestrator.

    Recommended Versions, System Requirements and Installation

    Recommended Versions and System Requirements

    The table below lists recommended and required versions of VMware software. This information is current as of the publication date of this document. For the latest recommendations, please refer to VMware knowledge base article 2144295

    Product or component Minimum recommended version
    NSX for vSphere 6.2.2

    Note: There is a known issue with SSL VPN. For more information, see CVE-2016-2079. Customers running 6.2.2 or earlier are strongly advised to contact VMware Support to request immediate assistance.

    To contact VMware support, see  How to file a Support Request in My VMware  or How to Submit a Support Request.

    vSphere 5.5U3, or 6.0U2

    Note: There is a known issue with vSphere 6.0 and NSX objects. For more information, see VMware Knowledge base article 2144605, "Duplicate VTEPs in ESXi hosts after rebooting vCenter Server".

    Guest Introspection Guest Introspection-based features in NSX are compatible with specific VMware Tools (VMTools) versions. To enable the optional Thin Agent Network Introspection Driver component packaged with VMware Tools, you must upgrade to one of:
    • VMware Tools 10.0.8 and later to resolve Slow VMs after upgrading VMware Tools in NSX / vCloud Networking and Security (VMware knowledge base article 2144236)

    • VMware Tools 10.0.9 and later for Windows 10 support

    vRealize Orchestrator NSX-vRO plugin 1.0.3

    Installation

    For installation instructions, see the NSX Installation Guide or the NSX Cross-vCenter Installation Guide. For the complete list of NSX installation prerequisites, see the System Requirements for NSX section in the NSX Installation Guide.

    Deprecated and Discontinued Functionality

    End of Life and End of Support Warnings

    For information about NSX and other VMware products that must be upgraded soon, please consult the VMware Lifecycle Product Matrix. Upcoming end-of-support dates include:

    • vCloud Networking and Security will reach End of Availability (EOA) and End of General Support (EOGS) on September 19, 2016. (See also VMware knowledge base article 2144733.) (See also VMware knowledge base article 2144620.)
    • NSX for vSphere 6.1.x will reach End of Availability (EOA) and End of General Support (EOGS) on January 15, 2017. (See also VMware knowledge base article 2144769.)
    • As of NSX 6.2.3, the NSX Data Security feature has been deprecated. In NSX 6.2.3, you can continue to use this feature at your discretion, but be aware that this feature will be removed from NSX in a future release.

    • Web Access Terminal (WAT) is being deprecated and will not be included in a future maintenance release. VMware recommends using the full access client with SSL VPN deployments for improved security.

    Unsupported controller commands are no longer shown

    Please review the CLI guide for the complete list of supported commands. You should only use commands which are documented in this guide. The join control-cluster command is not a supported command on NSX for vSphere. See also VMware knowledge base article 2135280.

    TLS 1.0 support has been deprecated as of NSX 6.2.3

    In the NSX VPN and IPsec cipher suite, TLS 1.0 support has been deprecated as of NSX 6.2.3. There have been some changes in Cipher support as compared to the previous release. These changes are captured in the tables below.

    SSLVPN Cipher suite support: Changes in 6.2.3

    6.2.2 6.2.3
    TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA
    TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA
    TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256
      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

    L2VPN Cipher suite support: Changes in 6.2.3

    6.2.2 6.2.3
    AES128-SHA AES128-GCM-SHA256
    AES256-SHA ECDHE-RSA-AES128-GCM-SHA256
    AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384
    DES-CBC3-SHA NULL-SHA256
    NULL-MD5 NULL-MD5

    IP-Sec Cipher suite: Changes in 6.2.3

    6.2.2 6.2.3
    AES_128-HMAC_SHA1 AES_128-HMAC_SHA1
    AES(12)_256-SHA1(2)_000 AES(12)_256-SHA1(2)_000
    3DES(3)_000-SHA1(2)_000 3DES(3)_000-SHA1(2)_000
    AES_GCM_C_160-NONE AES_GCM_C_160-NONE

    Upgrade Notes

    • Downgrades are not supported:

      • Always capture a backup of NSX Manager before proceeding with an upgrade.

      • Once NSX has been upgraded successfully, NSX cannot be downgraded.

    • To upgrade to NSX 6.2.3, you must perform a full NSX upgrade including host cluster upgrade (which upgrades the host VIBs to 6.2.3). For instructions, see the NSX Upgrade Guide including the Upgrade Host Clusters to NSX 6.2 section.

    • Controller disk layout: New installations of NSX 6.2.3 will deploy NSX Controller appliances with updated disk partitions to provide extra cluster resiliency. In previous releases, log overflow on the controller disk might impact controller stability. In addition to adding log management enhancements to prevent overflows, the NSX Controller appliance has separate disk partitions for data and logs to safeguard against these events. If you upgrade to NSX 6.2.3, the NSX Controller appliances will retain their original disk layout.
    • Upgrade paths:

      • Upgrade path from NSX 6.x: The VMware Product Interoperability Matrix provides details about the upgrade paths from VMware NSX. Cross-vCenter NSX upgrade is covered in the NSX Upgrade Guide.

      • Upgrade path from vCNS 5.5.x: Using the NSX upgrade bundle posted on or after 09 June, 2016, you may upgrade directly from VMware vCloud Network and Security (vCNS) 5.5.x to NSX 6.2.3. For instructions, see the NSX Upgrade Guide, in the section, vCloud Networking and Security to NSX Upgrade. This section also includes instructions for upgrading vCNS 5.5.x to NSX in a vCloud Director environment. A separate guide, the NSX Upgrade Guide for vShield Endpoint, includes instructions for upgrading vCNS 5.5.x to NSX 6.2.3 if you are using vShield Endpoint for anti-virus protection only.

      • There is no support for upgrades from NSX 6.1.6 to NSX 6.2.0, 6.2.1, or 6.2.2.

      • There is no support for upgrades from NSX 6.1.5 to NSX 6.2.0. VMware recommends upgrading from 6.1.5 to 6.2.3 or later to get the latest security updates.

    • To validate that your upgrade to NSX 6.2.x was successful see knowledge base article 2134525.

    • Upgrading as part of a wider VMware product upgrade: When you are upgrading NSX in context with other VMware product upgrades, such as vCenter and ESXi, it is important to follow the supported upgrade sequence documented in knowledge base article 2109760.

    • Partner services compatibility: If your site uses VMware partner services for guest introspection or network introspection, you must review the  VMware Compatibility Guide before you upgrade, to verify that your vendor's service is compatible with this release of NSX.
    • Known issues affecting upgrades: See the section, Installation and Upgrade Known Issues, later in this document, for a list of known upgrade-related issues.

    • New system requirements: For the memory and CPU requirements while installing and upgrading NSX Manager, see the System Requirements for NSX section in the NSX 6.2 documentation.

    • Maximum number of NAT rules: For NSX Edge versions prior to 6.2, a user could configure 2048 SNAT and 2048 DNAT rules separately, giving a total limit of 4096 rules. Since NSX Edge version 6.2 onwards, a limit is enforced for the maximum allowed NAT rules, based on the NSX Edge appliance size:

        1024 SNAT and 1024 DNAT rules for a total limit of 2048 rules for COMPACT edge.

        2048 SNAT and 2048 DNAT for a total limit of 4096 rules for LARGE edge and QUADLARGE edge.

        4096 SNAT and 4096 DNAT rules for a total limit of 8192 rules for XLARGE edge.

      During an NSX Edge upgrade to version 6.2, any existing COMPACT edge whose total NAT rules (sum of SNAT and DNAT) exceeds the limit 2048 will fail validation, resulting in an upgrade failure. In this scenario, the user will need to change the appliance size to LARGE, QUADLARGE and retry the upgrade.

    • Behavior change in redistribution filters on distributed logical router and Edge Services Gateway: Starting in the 6.2 release, redistribution rules in the DLR and ESG work as ACLs only. That is, if a rule is an exact match, the respective action is taken.

    • VXLAN tunnel ID: Before upgrading to NSX 6.2.x, you must make sure your installation is not using a VXLAN tunnel ID of 4094 on any tunnels. VXLAN tunnel ID 4094 no longer available for use. To assess and address this follow these steps:

      1. In vCenter, navigate to Home > Networking and Security > Installation and select the Host Preparation tab.
      2. Click Configure in the VXLAN column.

      3. In the Configure VXLAN Networking window, set the VLAN ID to a value between 1 and 4093.

    • Reset vSphere web client: After upgrading NSX Manager, you must reset the vSphere web client server as explained in the NSX Upgrade documentation. Until you do this, the Networking and Security tab may fail to appear in the vSphere web client. You also may need to clear your browser cache or history.

    • Stateless environments: NSX upgrades in a stateless host environment use new VIB URLs: In NSX upgrades in a stateless host environment, the new VIBs are pre-added to the Host Image profile during the NSX upgrade process. As a result, NSX on stateless hosts upgrade process follows this sequence:

      1. Manually download the latest NSX VIBs from NSX Manager from a fixed URL.

      2. Add the VIBs to the host image profile.

      Prior to NSX 6.2.0, there was a single URL on NSX Manager from which VIBs for a certain version of the ESX Host could be found. (Meaning the administrator only needed to know a single URL, regardless of NSX version.) In NSX 6.2.0 and later, the new NSX VIBs are available at different URLs. To find the correct VIBs, you must perform the following steps:

      • Find the new VIB URL from https://<NSX-Manager-IP>/bin/vdn/nwfabric.properties.
      • Fetch VIBs of required ESX host version from corresponding URL.
      • Add them to host image profile.
    • Autosaved drafts and Service Composer: NSX 6.2.3 changes the default for autosaved drafts to OFF, including with an upgrade. Manually configured settings will be maintained with an upgrade to 6.2.3. To avoid performance issues, VMware recommends disabling autosaved drafts

    • Host may become stuck in the installing state: During large NSX upgrades, a host may become stuck in the installing state for a long time. This can occur due to issues uninstalling old NSX VIBs. In this case the EAM thread associated with this host will be reported in the VI Client Tasks list as stuck.
      Workaround : Log into vCenter using the VI Client. Right click on the stuck EAM task and cancel it. From the vSphere Web Client, issue a Resolve on the cluster. The stuck host may now show as in progress. Log into the host and issue a reboot to force completion of the upgrade on that host.

    Known Issues

    Known issues are grouped as follows:

    General Known Issues

    Issue 1659043: Service Status for Guest Introspection reported as "Not Ready" when NSX Manager to USVM communication times out

    An error message similar to "PLAIN login refused: user 'usvm-admin-host-14' - invalid credentials" may be reported for the Guest Introspection Universal SVM when the expected password change process with NSX Manager on the internal message bus (rabbit MQ) does not succeed.

    Workaround: To re-establish connectivity between the USVM and NSX Manager, restart the USVM or manually delete it and then select the Resolve button on the Service Composer UI to prompt a redeploy of the USVM for the affected host only.

    Issue 1662842: Guest Introspection: Connectivity lost between MUX and USVM when trying to resolve unresolvable Windows SIDs
    Guest Introspection service will go into a warning state, with each Guest Introspection going in and out of a warning state. Until the Guest Introspection VM reconnects, network events will not be delivered to the NSX Manager. This will affect both Activity Monitoring and ID Firewall in the case that logon events are detected through the Guest Introspection path.

    Workaround: To return Guest Introspection to a stable state, Guest Introspection VMs must be configured to ignore lookups for these well-known SIDs. This is achieved by updating a configuration file on each Guest Introspection VM and then restarting the service. In addition, Active Directory log scraping can be used as a workaround for detecting logon events for ID Firewall.

    Steps to ignore SID lookups for unresolvable SIDs:
    1. Login to Guest Introspection VM.
    2. Edit the file at /usr/local/usvmmgmt/config/ignore-sids.lst.
    3. Append the following 2 lines:
      S-1-18-1
      S-1-18-2
    4. Save and close the file.
    5. Restart the Guest Introspection service with command:
      rcusvm restart.

    Issue 1558285: Deleting cluster with Guest Introspection from Virtual Center results in null pointer exception
    Services such as Guest Introspection must be removed first before a cluster is removed from VC

    Workaround: Delete the EAM Agency for the service deployment with no associated cluster.

    Issue 1629030: The packet capture central CLI (debug packet capture and show packet capture) requires vSphere 5.5U3 or higher
    These commands are not supported on earlier vSphere 5.5 releases.

    Workaround: VMware advises all NSX customers to run vSphere 5.5U3 or higher.

    Issue 1568180: Feature list incorrect for NSX when using vCenter Server Appliance (vCSA) 5.5
    You can view the features of a license in the vSphere Web Client by selecting the license and clicking Actions > View Features. If you upgrade to NSX 6.2.3, your license is upgraded to an Enterprise license, which enables all features. However, if NSX Manager is registered with vCenter Server Appliance (vCSA) 5.5, selecting View Features will display the list of features for the license used before the upgrade, not the new Enterprise license.

    Workaround: All Enterprise licenses have the same features, even if they are not displayed correctly in the vSphere Web Client. See the NSX Licensing Page for more information.

    Issue 1477280: Cannot create hardware gateway instances when no controller is deployed
    Controllers must be deployed before any hardware gateway instances are configured. If controllers are not deployed first, the error message "Failed to do the Operation on the Controller" is shown.

    Workaround: None.

    Issue 1491275: NSX API returns JSON instead of XML in certain circumstances
    On occasion, an API request will result in JSON, not XML, being returned to the user.

    Workaround: Add Accept: application/xml to the request header.

    Installation and Upgrade Known Issues

    Before upgrading, please read the section Upgrade Notes, earlier in this document.

    Issue 1685894: VMs migrated (with DRS) from hosts with installed NSX 6.2.3 VIBs to hosts with older release VIBs lose network connectivity.
    This scenario is not supported as NSX does not support downgrades. Refer to VMware knowledge base article 2146171.

    • With a DRS-enabled cluster, change DRS mode to Manual during the upgrade until all hosts in the cluster are upgraded to NSX 6.2.3.

    • On a non-DRS-enabled cluster, do not migrate VMs from NSX 6.2.3-based hosts to older-release hosts.

    Issue 1683879: Upgrade to NSX 6.2.3 may fail on hosts with less than 8 GB of memory​

    NSX 6.2.3 requires a minimum of 8 GB of memory on prepared hosts running networking and security services. The minimum ESXi 6.0 memory requirement of 4 GB is not sufficient to run NSX.

    Workaround: None.

    Issue 1673626: ​Using a database server alias name to create a DSN may cause the installation of vCenter Server to fail

    After upgrading from vCloud Networking and Security to NSX, you will see an error if you try to modify the tcpLoose setting in this API request: /api/3.0/edges.

    Workaround: Use tcpPickOngoingConnections setting in the globalConfig section in the API request /api/4.0/firewall/config instead.

    Issue 1658720: Enabling DFW for a given cluster would fail for a VCNS to NSX upgrade scenario where the cluster has VXLAN installed and vShield App not installed (or removed before upgrade) in VCNS deployment

    This issue occurs because the cluster sync status is not invoked when the hosts are upgraded.

    Workaround: Restart NSX Manager.​

    Issue 1600281: USVM Installation Status for Guest Introspection shows as Failed in the Service Deployments tab

    If the backing datastore for the Guest Introspection Universal SVM goes offline or becomes inaccessible, the USVM may need to be rebooted or re-deployed to recover.

    Workaround:Reboot or re-deploy USVM to recover.

    Issue 1660373: vCenter enforces expired NSX license

    As of vSphere 5.5 update 3 or vSphere 6.0.x vSphere Distributed Switch is included in the NSX license. However, vCenter does not allow ESX hosts to be added to a vSphere Distributed Switch if the NSX license is expired.

    Workaround: Your NSX license must be active in order to add a host to a vSphere Distributed Switch.​

    Issue 1569010/1645525: When upgrading from 6.1.x to NSX for vSphere 6.2.3 on a system connected to Virtual Center 5.5, the Product field in the "Assign License Key" window displays the NSX license as a generic value of "NSX for vSphere" and not a more specific version such as "NSX for vSphere - Enterprise."

    Workaround: None.

    Issue 1465249: Installation status for Guest Introspection shows Succeeded even though the host is offline
    After installing Guest Introspection on the cluster that has one host offline, the host that is offline shows Installation Status as Succeeded and Status Unknown.

    Workaround: None.

    Issue 1636916: In a vCloud Air environment, when the NSX Edge version is upgraded from vCNS 5.5.x to NSX 6.x, Edge firewall rules with a source protocol value of "any" are changed to "tcp:any, udp:any"
    As a result, ICMP traffic is blocked, and packet drops may be seen.

    Workaround: Before upgrading your NSX Edge version, create more specific Edge firewall rules and replace "any" with specific source port values.

    Issue 1660355: VMs which are migrated from 6.1.5 to 6.2.3 will not have support for TFTP ALG
    Even though the host is enabled, VMs which are migrated from 6.1.5 to 6.2.3 will not have support for TFTP ALG.

    Workaround: Add and remove the VM from the exclusion list or restart the VM, so that new 6.2.3 filter gets created which will have support for TFTP ALG.

    Issue 1394287: Adding or removing VMs from a virtual wire does not update IP address set in vShieldApp rules
    If an existing vCNS vShield App firewall installation is not upgraded to the NSX distributed firewall in enhanced mode, new VMs with firewall rules based on virtual wires will not have an updated IP address. As a result, these VMs are not protected by the NSX firewall This issue is only seen in the following scenarios:

    • After upgrading the Manager from vCNS to NSX and not switching to DFW Enhanced mode.
    • If you add new VMs to a virtualWire with vshield App rules consuming those virtualwires, these rules will not have the new IP Address set for the new VMs.
    • This will cause the new VMs not protected by vShieldApp.

    Workaround: Publish the rule again which will set the new address.

    Issue 1474238: After vCenter upgrade, vCenter might lose connectivity with NSX
    If you are using vCenter embedded SSO and you are upgrading vCenter 5.5 to vCenter 6.0, vCenter might lose connectivity with NSX. This happens if vCenter 5.5 was registered with NSX using the root user name. In NSX 6.2, vCenter registration with root is deprecated. NOTE: If you are using external SSO, no change is necessary. You can retain the same user name, for example admin@mybusiness.mydomain, and vCenter connectivity will not be lost.

    Workaround: Reregister vCenter with NSX using the admininstrator@vsphere.local user name instead of root.

    Issue 1332563: Shutdown Guest OS for agent VMs (SVA) before powering OFF
    When a host is put into maintenance mode, all service appliances are powered-off, instead of shutting down gracefully. This may lead to errors within third-party appliances.

    Workaround: None.

    Issue 1473537: Unable to power on the Service appliance that was deployed using the Service Deployments view

    Workaround: Before you proceed, verify the following:

    • The deployment of the virtual machine is complete.

    • No tasks such as cloning, reconfiguring, and so on are in progress for the virtual machine displayed in VC task pane.

    • In the VC events pane of the virtual machine, the following events are displayed after the deployment is initiated:
       
      Agent VM <vm name> has been provisioned.
      Mark agent as available to proceed agent workflow.
       

      In such a case, delete the service virtual machine. In service deployment UI, the deployment is seen as Failed. Upon clicking the Red icon, an alarm for an unavailable Agent VM is displayed for the host. When you resolve the alarm, the virtual machine is redeployed and powered on.

    If not all clusters in your environment are prepared, the Upgrade message for Distributed Firewall does not appear on the Host Preparation tab of Installation page
    When you prepare clusters for network virtualization, distributed firewall is enabled on those clusters. If not all clusters in your environment are prepared, the upgrade message for Distributed Firewall does not appear on the Host Preparation tab.

    Workaround: Use the following REST call to upgrade Distributed Firewall:

    PUT https://<nsxmgr-ip>/api/4.0/firewall/globalroot-0/state/<nsxmgr-ip>

    Issue 1215460: If a service group is modified after the upgrade to add or remove services, these changes are not reflected in the firewall table
    User created service groups are expanded in the Edge Firewall table during upgrade - i.e., the Service column in the firewall table displays all services within the service group. If the service group is modified after the upgrade to add or remove services, these changes are not reflected in the firewall table.

    Workaround: Create a new service group with a different name and then consume this service group in the firewall rule.

    Issue 1088913: vSphere Distributed Switch MTU does not get updated
    If you specify an MTU value lower than the MTU of the vSphere distributed switch when preparing a cluster, the vSphere Distributed Switch does not get updated to this value. This is to ensure that existing traffic with the higher frame size isn't unintentionally dropped.

    Workaround: Ensure that the MTU you specify when preparing the cluster is higher than or matches the current MTU of the vSphere distributed switch. The minimum required MTU for VXLAN is 1550.

    Issue 1413125: SSO cannot be reconfigured after upgrade
    When the SSO server configured on NSX Manager is the one native on vCenter server, you cannot reconfigure SSO settings on NSX Manager after vCenter Server is upgraded to version 6.0 and NSX Manager is upgraded to version 6.x.

    Workaround: None.

    Issue 1288506: After upgrading from vCloud Networking and Security 5.5.3 to NSX vSphere 6.0.5 or later, NSX Manager does not start up if you are using an SSL certificate with DSA-1024 keysize
    SSL certificates with DSA-1024 keysize are not supported in NSX vSphere 6.0.5 onwards, so the upgrade is not successful.

    Workaround: Import a new SSL certificate with a supported keysize before starting the upgrade.

    Issue 1266433: SSL VPN does not send upgrade notification to remote client
    SSL VPN gateway does not send an upgrade notification to users. The administrator has to manually communicate that the SSL VPN gateway (server) is updated to remote users and they must update their clients.

    Workaround: Users need to uninstall the older version of client and install the latest version manually.

    Issue 1402307: If vCenter is rebooted during NSX vSphere upgrade process, incorrect Cluster Status is displayed
    When you do host prep in an environment with multiple NSX prepared clusters during an upgrade and the vCenter Server gets rebooted after at least one cluster has been prepared, the other clusters may show Cluster Status as Not Ready instead of showing an Update link. The hosts in vCenter may also show Reboot Required.

    Workaround: Do not reboot vCenter during host preparation.

    Issue 1487752: Momentary loss of third-party anti-virus protection during upgrade
    When upgrading from NSX 6.0.x to NSX 6.1.x or 6.2.x, you might experience momentary loss of third-party anti-virus protection for VMs. This issue does not affect upgrades from NSX 6.1.x to NSX 6.2.

    Workaround: None.

    Issue 1498376: Host error message appears while configuring distributed firewall
    While configuring distributed firewall, if you encounter an error message related to the host, check the status of fabric feature . If the status is Red, perform the following workaround.

    Workaround: Use the following REST API call to reset communication between NSX Manager and a single host or all hosts in a cluster.

    POST https://<nsxmgr-ip>/api/2.0/nwfabric/configure? action=synchronize

    <nwFabricFeatureConfig>
    <featureId>com.vmware.vshield.nsxmgr.messagingInfra</featureId>
      <resourceConfig>
        <resourceId>HOST/CLUSTER MOID</resourceId>
    </resourceConfig>
    </nwFabricFeatureConfig>
    

    Issue 1491820: NSX Manager log collects WARN messagingTaskExecutor-7 messages after upgrade to NSX 6.2
    After upgrading from NSX 6.1.x to NSX 6.2, the NSX Manager log becomes flooded with messages similar to: WARN messagingTaskExecutor-7 ControllerInfoHandler:48 - host is unknown: host-15 return empty list. There is no operational impact.

    Workaround: None.

    Issue 1284735: After upgrade from vCNS, cannot place new grouping objects into some upgraded grouping objects
    vCNS 5.x supported creation of grouping objects at scopes below GlobalRoot (below the NSX-wide scope). For example, in vCNS 5.x you could create a grouping object as the DC or PG level. By contrast, the NSX 6.x user interface creates such objects under the GlobalRoot, and these newly created grouping objects cannot be added to existing grouping objects that were created at a lower scope (DC or PG) in your pre-upgrade vCNS installation.

    Workaround: See VMware knowledge base article 2117821.

    Issue 1495969: After upgrading from vCNS 5.5.4 to NSX 6.2.x, the firewall on the Host Preparation tab remains disabled
    After upgrading from vCNS 5.5.x to NSX 6.2.x and upgrading all the clusters, the firewall on the Host Preparation tab remains disabled. In addition, the option to upgrade the firewall does not appear in the UI. This happens only when there are hosts that are not part of any prepared clusters in the datacenter, because the VIBs will not be installed on those hosts.

    Workaround: To resolve the issue, move the hosts into an NSX 6.2 prepared cluster.

    Issue 1495307: During an upgrade, L2 and L3 firewall rules do not get published to hosts
    After publishing a change to the distributed firewall configuration, the status remains in progress both in the UI and the API indefinitely, and no log for L2 or L3 rules is written to the file vsfwd.log.

    Workaround: During an NSX upgrade, do not publish changes to the distributed firewall configuration. To exit from the in progress state and resolve the issue, reboot the NSX Manager virtual appliance.

    Issue 1474066: The NSX REST API call to enable or disable IP detection seems to have no effect
    If host cluster preparation is not yet complete, the NSX REST API call to enable or disable IP detection (https://<nsxmgr-ip>/api/2.0/xvs/networks/universalwire-5/features) has no effect.

    Workaround: Before issuing this API call, make sure the host cluster preparation is complete.

    Issue 1479314: NSX 6.0.7 SSL VPN clients cannot connect to NSX 6.2 SSL VPN gateways
    In NSX 6.2 SSL VPN gateways, the SSLv2 and SSLv3 protocols are disabled. This means the SSL VPN gateway only accepts the TLS protocol. The SSL VPN 6.2 clients have been upgraded to use the TLS protocol by default during connection establishment. In NSX 6.0.7, the SSL VPN client uses an older version of OpenSSL library and the SSLv3 protocol to establish a connection. When an NSX 6.0.x client tries to connect to an NSX 6.2 gateway, the connection establishment fails at the SSL handshake level.

    Workaround: Upgrade your SSL VPN client to NSX 6.2 after you have upgraded to NSX 6.2. For upgrade instructions, see the NSX Upgrade documentation.

    Issue 1434909: Must create a segment ID pool for new or upgraded logical routers
    In NSX 6.2, a segment ID pool with available segment IDs must be present before you can upgrade a logical router to 6.2 or create a new 6.2 logical router. This is true even if you have no plans to use NSX logical switches in your deployment.

    Workaround: If your NSX deployment does not have a local segment ID pool, create one as a prerequisite to NSX logical router upgrade or installation.

    Issue 1459032: Error configuring VXLAN gateway
    When configuring VXLAN using a static IP pool (at Networking& Security>Installation> Host Preparation>Configure VXLAN) and the configuration fails to set an IP pool gateway IP on the VTEP(because the gateway is not properly configured or is not reachable), the VXLAN configuration status enters the Error (RED) state at for the host cluster.

    The error message is VXLAN Gateway cannot be set on host and the error status is VXLAN_GATEWAY_SETUP_FAILURE. In the REST API call, GET https://<nsxmgr-ip>/api/2.0/nwfabric/status?resource=<cluster-moid>, the status of VXLAN is as follows:

    <nwFabricFeatureStatus>
      <featureId>com.vmware.vshield.nsxmgr.vxlan</featureId>
      <featureVersion>5.5</featureVersion>
      <updateAvailable>false</updateAvailable>
      <status>RED</status>
      <message>VXLAN Gateway cannot be set on host</message>
      <installed>true</installed>
      <enabled>true</enabled>
      <errorStatus>VXLAN_GATEWAY_SETUP_FAILURE</errorStatus>
    </nwFabricFeatureStatus>
    

    Workaround: To fix the error, there are two options.

    • Option 1: Remove VXLAN configuration for the host cluster, fix the underlying gateway setup in the IP pool by making sure the gateway is properly configured and reachable, and then reconfigure VXLAN for the host cluster.

    • Option 2: Perform the following steps.

      1. Fix the underlying gateway setup in the IP pool by making sure the gateway is properly configured and reachable.

      2. Put the host (or hosts) into maintenance mode to ensure no VM traffic is active on the host.

      3. Delete the VXLAN VTEPs from the host.

      4. Take the host out of maintenance mode. Taking hosts out of maintenance mode triggers the VXLAN VTEP creation process on NSX Manager. NSX Manager will try to re-create the required VTEPs on the host.

    Issue 1463767: In a cross vCenter deployment, a universal firewall configuration section might be under (subordinate to) a local configuration section
    If you move a secondary NSX Manager to the standalone (transit) state and then change it back to the secondary state, any local configuration changes that you made while it was temporarily in the standalone state might be listed above the replicated universal configuration sections inherited from the primary NSX Manager. This produces the error condition universal section has to be on top of all other sections on secondary NSX Managers.

    Workaround: Use the UI option to move sections up or down so that the local section is below the universal section.

    Issue 1289348: After an upgrade, firewall rules and network introspection services might be out of sync with NSX Manager
    After upgrading from NSX 6.0 to NSX 6.1 or 6.2, the NSX firewall configuration displays the error message: synchronization failed / out of sync. Using the Force Sync Services: Firewall action does not resolve the issue.

    Workaround: In NSX 6.1 and NSX 6.2, either security groups or dvPortgroups can be bound to a service profile, but not both. To resolve the issue, modify your service profiles.

    Issue 1462319: The esx-dvfilter-switch-security VIB is no longer present in the output of the "esxcli software vib list | grep esx" command.
    Starting in NSX 6.2, the esx-dvfilter-switch-security modules are included within the esx-vxlan VIB. The only NSX VIBs installed for 6.2 are esx-vsip and esx-vxlan. During an NSX upgrade to 6.2, the old esx-dvfilter-switch-security VIB gets removed from the ESXi hosts.

    Workaround: None.

    Issue 1481083: After the upgrade, logical routers with explicit failover teaming configured might fail to forward packets properly
    When the hosts are running ESXi 5.5, the explicit failover NSX 6.2 teaming policy does not support multiple active uplinks on distributed logical routers.

    Workaround: Alter the explicit failover teaming policy so that there is only one active uplink and the other uplinks are in standby mode.

    Issue 1485862: Uninstalling NSX from a host cluster sometimes results in an error condition
    When using the Uninstall action on the Installation: Host Preparation tab, an error might occur with the eam.issue.OrphanedAgency message appearing in the EAM logs for the hosts. After using the Resolve action and rebooting the hosts, the error state continues even though the NSX VIBs are successfully uninstalled.

    Workaround: Delete the orphaned agency from the vSphere ESX Agent Manager (Administration: vCenter Server Extensions: vSphere ESX Agent Manager).

    Issue 1479314: SSLv2 and SSLv3 deprecated in NSX 6.2
    Starting in NSX 6.2, the SSL VPN gateway only accepts the TLS protocol. After the NSX upgrade, any new NSX 6.2 clients that you create automatically use the TLS protocol during connection establishment. When an NSX 6.0.x client tries to connect to an NSX 6.2 gateway, the connection establishment fails at the SSL handshake step.

    Workaround: After the upgrade to NSX 6.2, uninstall your old SSL VPN clients and install the NSX 6.2 version of the SSL VPN clients.

    Issue 1411275: vSphere Web Client does not display Networking and Security tab after backup and restore in NSX vSphere 6.2
    When you perform a backup and restore operation after upgrading to NSX vSphere 6.2, the vSphere Web Client does not display the Networking and Security tab.

    Workaround: When an NSX Manager backup is restored, you are logged out of the Appliance Manager. Wait a few minutes before logging in to the vSphere Web Client.

    Issue 1493777: After upgrade to NSX 6.2, NSX Manager has more than 100 percentage of physical memory allocated
    Starting in NSX 6.2, NSX Manager requires 16 GB of reserved memory. The former requirement was 12 GB.

    Workaround: Increase the NSX Manager virtual appliance's reserved memory to 16 GB.

    Issue 1393889: Data Security service status is shown as UP even when IP connectivity is not established
    Data Security appliance may have not received the IP address from DHCP or is connected to an incorrect port group.

    Workaround: Ensure that the Data Security appliance gets the IP from DHCP/IP Pool and is reachable from the management network. Check if the ping to the Data Security appliance is successful from NSX/ESX.

    Service virtual machine deployed using the Service Deployments tab on the Installation page does not get powered on

    Workaround: Follow the steps below.

    1. Manually remove the service virtual machine from the ESX Agents resource pool in the cluster.
    2. Click Networking and Security and then click Installation.
    3. Click the Service Deployments tab.
    4. Select the appropriate service and click the Resolve icon.
      The service virtual machine is redeployed.

    NSX Manager Known Issues

    Issue 1668519: High CPU utilization on NSX Manager
    NSX Manager may experience sustained high CPU, especially after a reboot, when the purgetask process must process or clean up a very large volume of job entries on the NSX Manager database.

    Workaround: Contact VMware technical support.

    Issue 1671067: NSX Plugin does not appear in vCenter Web Client while ESXTOP plugin is also installed
    After deployment of NSX and successful registration with vCenter, NSX plugin does not appear in the vCenter Web Client. This issue is caused by conflict between NSX plugin and ESXTOP plugin.

    Workaround: Remove ESXTOP plugin with the following procedure:

    1. Make sure there is a recent backup of vCenter Snapshot vCenter VM (without quiesce)
    2. Delete /usr/lib/vmware-vsphere-client/plugin-packages/esxtop-plugin
      rm -R /usr/lib/vmware-vsphere-client/plugin-packages/esxtop-plugin
    3. Delete /usr/lib/vmware-vsphere-client/server/work
      rm -R /usr/lib/vmware-vsphere-client/server/work
    4. Restart the web client
      service vsphere-client restart
    5. (Optional) Ensure that there is no output from the following command: "tail -f /var/log/vmware/vsphere-client/logs/eventlog.log | grep esx"
    6. Make sure to consolidate vCenter snapshot if that is the preferred method of roll back option

    Issue 1466790: NSX Manager does not accept DNS search strings with a space delimiter
    NSX Manager does not accept DNS search strings with a space delimiter. You may only use a comma as a delimiter. For example, if the DHCP server advertises eng.sample.com and sample.com for the DNS search list, NSX Manager is configured with eng.sample.com sample.com.

    Workaround: Use comma separators. NSX Manager only accepts comma separator as DNS search strings.

    Issue 1529178: Uploading a server certificate which does not include a common name returns an "internal server error" message

    If you upload a server certificate that does not have any common name, an "internal server error" message appears.

    Workaround: Use a server certificate which has both a SubAltName and a common name, or at least a common name.

    Issue 1655388: NSX Manager 6.2.3 UI displays English language instead of local language when using IE11/Edge browser on Windows 10 OS for JA, CN, and DE languages

    When you launch NSX Manager 6.2.3 with IE11/Edge browser on Windows 10 OS for JA, CN, and DE languages, English language is displayed.

    Workaround:

    Perform the following steps:

    1. Launch the Microsoft Registry Editor (regedit.exe), and go to Computer > HKEY_CURRENT_USER > SOFTWARE > Microsoft > Internet Explorer > International.
    2. Modify the value of AcceptLanguage file to native language. For example, If you want to change language to DE, change value and make the DE show the first position.
    3. Restart the browser, and log in to the NSX Manager again. Appropriate language is displayed.

    Issue 1446649/1445281: Change in Secondary NSX Manager IP / Thumbprint results into Replication errors of Universal objects in a Cross-vCenter setup

    If there is any change in the Secondary NSX Manager IP / Thumbprint, it would result into Replication errors of Universal objects in a Cross-vCenter setup as the Primary NSX Manager would not be aware of the latest IP/Thumbprint of the Secondary NSX Manager.

    Workaround: If you click the Universal sync status of an Universal object and see exception like "Peer not authenticated;nested exception is javax.net.ssl.SSLPeerUniverifiedException", you can realize that the IP/Thumbprint has been changed.

    Issue 1660718: Service Composer policy status is shown as "In Progress" at the UI and "Pending" in the API output

    Workaround: None.

    Issue 1620491: Policy-level Sync status in Service Composer does not show publishing status of the rules within a policy

    When a policy is created or modified, Service Composer will display a success status which indicates only the persistence state. It does not reflect whether the rules were published to the host successfully.

    Workaround: Use the firewall UI to view publish status.

    Issue 1435996: Log files exported as CSV from NSX Manager are timestamped with epoch not datetime
    Log files exported as CSV from NSX Manager using the vSphere Web Client are timestamped with the epoch time in milliseconds, instead of with the appropriate time based on the time zone.

    Workaround: None.

    Issue 1466790: Unable to choose VMs on bridged network using the NSX traceflow tool
    Using the NSX traceflow tool, you cannot select VMs that are not attached to a logical switch. This means that VMs on an L2 bridged network cannot be chosen by VM name as the source or destination address for traceflow inspection.

    Workaround: For VMs attached to L2 bridged networks, use the IP address or MAC address of the interface you wish to specify as destination in a traceflow inspection. You cannot choose VMs attached to L2 bridged networks as source. See the knowledge base article 2129191 for more information.

    Issue 1644297: Add/delete operation for any DFW section on the primary NSX creates two DFW saved configurations on the secondary NSX
    In a cross-vCenter setup, when an additional universal or local DFW section is added to the primary NSX Manager, two DFW configurations are saved on the secondary NSX Manager. While it does not affect any functionality, this issue will cause the saved configurations limit to be reached more quickly, possibly overwriting critical configurations.

    Workaround: None.

    Issue 1534877: NSX management service doesn't come up when the hostname's length is more than 64 characters
    Certificate creation via OpenSSL library requires a hostname less than or equal to 64 characters.

    Issue 1537258: NSX Manager list slow to display in Web Client
    In vSphere 6.0 environments with multiple NSX Managers, the vSphere web client may take up to two minutes to display the list of NSX Managers when the logged-in user is being validated with a large AD Group set. You may see a data service timeout error when attempting to display the NSX Manager list. There is no workaround. You must wait for the list to load/relogin to see the NSX Manager list.

    Issue 1534622: NSX controller shows as disconnected
    NSX Manager logs report disconnection to controllers via a message similar to ERROR http-nio-127.0.0.1-7441-exec-16908 BaseRestController:339 - Exception: 'I/O error: Read timed out; nested exception is java.net.SocketTimeoutException: Read timed out'. This condition occurs when an intermediate firewall on the network blocks the TCP/IP FIN message after the idle timeout value is reached. When this condition is occurring, the number of connections to the NSX Manager will increase.

    Issue 1534606: Host Preparation Page fails to load
    When running Virtual Center in linked mode, each VC must be connected to an NSX Manager on the same NSX version. If the NSX versions differ, the vSphere Web Client will only be able to communicate with the NSX Manager running the higher version of NSX. An error similar to "Could not establish communication with NSX Manager. Please contact administrator," will be displayed on the Host Preparation tab.

    Workaround: All NSX managers should be upgraded to the same NSX software version.

    Issue 1317814: Service Composer goes out of sync when policy changes are made while one of the Service Managers is down
    When a policy changes is made when one of multiple Service Managers is down, the changes will fail, and Service Composer will fall out of sync.

    Workaround: Ensure the Service Manager is responding and then issue a force sync from Service Composer.

    Issue 1386874: Networking and Security Tab not displayed in vSphere Web Client
    After vSphere is upgraded to 6.0, you cannot see the Networking and Security Tab when you log in to the vSphere Web Client with the root user name.

    Workaround: Log in as administrator@vsphere.local or as any other vCenter user which existed on vCenter Server before the upgrade and whose role was defined in NSX Manager.

    Issue 1415480: After NSX Manager backup is restored, REST call shows status of fabric feature com.vmware.vshield.nsxmgr.messagingInfra as Red
    When you restore the backup of an NSX Manager and check the status of fabric feature com.vmware.vshield.nsxmgr.messagingInfra using a REST API call, it is displayed as Red instead of Green.

    Workaround: Use the following REST API call to reset communication between NSX Manager and a single host or all hosts in a cluster.
    POST https://<nsxmgr-ip>/api/2.0/nwfabric/configure? action=synchronize
    <nwFabricFeatureConfig>
    <featureId>com.vmware.vshield.nsxmgr.messagingInfra</featureId>
    <resourceConfig>
        <resourceId>HOST/CLUSTER MOID</resourceId>
    </resourceConfig>
    </nwFabricFeatureConfig>

    Issue 1070905: Cannot remove and re-add a host to a cluster protected by Guest Introspection and third-party security solutions
    If you remove a host from a cluster protected by Guest Introspection and third-party security solutions by disconnecting it and then removing it from vCenter Server, you may experience problems if you try to re-add the same host to the same cluster.

    Workaround: To remove a host from a protected cluster, first put the host in maintenance mode. Next, move the host into an unprotected cluster or outside all clusters and then disconnect and remove the host.

    Issue 1027066: vMotion of NSX Manager may display the error message, "Virtual ethernet card Network adapter 1 is not supported"
    You can ignore this error. Networking will work correctly after vMotion.

    Issue 1406471: Syslog shows host name of backed up NSX Manager on the restored NSX Manager
    If a second NSX Manager is installed with the same IP address and a unique hostname as the first NSX Manager, restoring the configuration will show the first NSX Manager’s hostname after a restore and the second NSX Manager’s hostname after reboot.

    Workaround: Host name of second NSX Manager should be configured to be same as the backed up NSX Manager.

    Issue 1477041: NSX Manager virtual appliance summary page shows no DNS name
    When you log in to the NSX Manager virtual appliance, the Summary page has a field for the DNS name. This field remains blank even though a DNS name has been defined for the NSX Manager appliance.

    Workaround: You can view the NSX Manager's hostname and the search domains on the Manage: Network page.

    Issue 1492880: NSX Manager UI do not automatically log out after changing password using NSX Command Line Interface
    If you are logged in to NSX Manager and recently changed your password using CLI, you might continue to stay logged in to the NSX Manager UI using your old password. Typically, NSX Manager client should automatically log you out if the session times out for being inactive.

    Workaround: Log out from the NSX Manager UI and log back in with your new password.

    Issue 1467866: Standalone NSX Manager incorrectly allows import of universal firewall configuration
    On an NSX Manager running in stand-alone mode, universal firewall rules can be imported even though they do not apply. Once imported, these rules cannot be deleted via API or the Web Client. Instead, they are retained and treated as a local section.

    Workaround: If you are running NSX Manager in standalone role, do not import a firewall configuration that contains universal rules. If you have already imported a universal firewall rule into a standalone NSX Manager, fix the issue by importing a saved firewall configuration file that does not contain universal rules, and publish that configuration file by loading it in the Firewall table.
    Perform the following steps:

    1. Log in to the vSphere Web Client.

    2. Click Networking & Security and then click Firewall.

    3. Click the Firewall tab.

    4. Click the Saved Configurations tab.

    5. Click the Import configuration (import) icon.

    6. Click Browse and select the file containing the configuration that you want to import.

      Rules are imported based on the rule names. During the import, Firewall ensures that each object referenced in the rule exists in your environment. If an object is not found, the rule is marked as invalid. If a rule referenced a dynamic security group, the dynamic security group is created in NSX Manager during the import.

    7. Add the node back as a secondary node. The synchronizing across NSX Managers automatically syncs up the universal section correctly performing any required cleanup.

      Once you have successfully published the configuration file, the rules are pushed down to the host and impact the datapath. The system functions as expected.

    Issue 1468613: Unable to edit a network host name
    After you login to NSX Manager virtual appliance and navigate to the Appliance Management, click Manage Appliance Settings, and click Network under Settings to edit the network host name, you might receive an invalid domain name list error. This happens when the domain names specified in the Search Domains field are separated with whitespace characters, instead of commas. NSX Manager only accepts domain names that are comma separated.
    Workaround: Perform the following steps:

    1. Log in to the NSX Manager virtual appliance.

    2. Under Appliance Management, click Manage Appliance Settings.

    3. From the Settings panel, click Network.

    4. Click Edit next to DNS Servers.

    5. In the Search Domains field, replace all whitespace characters with commas.

    6. Click OK to save the changes.

    Issue 1436953: False system event is generated even after successfully restoring NSX Manager from a backup
    After successfully restoring NSX Manager from a backup, the following system events appear in the vSphere Web Client when you navigate to Networking & Security: NSX Managers: Monitor: System Events.

    • Restore of NSX Manager from backup failed (with Severity=Critical).

    • Restore of NSX Manager successfully completed (with Severity=Informational).

    Workaround: If the final system event message shows as successful, you can ignore the system generated event messages.

    Issue 1489768: Change in behavior of NSX REST API call to add a namespace in a datacenter
    In NSX 6.2, the POST https://<nsxmgr-ip>/api/2.0/namespace/datacenter/ REST API call returns a URL with an absolute path, for example http://198.51.100.3/api/2.0/namespace/api/2.0/namespace/datacenter/datacenter-1628/2. In previous releases of NSX, this API call returned a URL with a relative path, for example: /api/2.0/namespace/datacenter/datacenter-1628/2.

    Workaround: None.

    Logical Networking Known Issues and NSX Edge Known Issues

    Issue 1703913: NSX DLR HA nodes remain in a split-brain state

    In an NSX 6.2.3 environment using dynamic routing with High Availability (HA) configured on a DLR Control VM, both the primary and secondary DLR HA nodes can enter and remain in Active state concurrently. This split-brain operating condition can result in routing errors. When this occurs, the NSX Manager System Events log displays an entry similar to: Critical, Code:'30205', 'Split Brain detected for NSX Edge edge-X with HighAvailability.

    Workaround: Refer to VMware knowledge base article 2146506.

    Issue 1703247: VMs lose network connectivity in NSX with DLR HA

    In an NSX 6.2.3 environment using dynamic routing with High Availability (HA) configured on a DLR Control VM, virtual machines lose network connectivity when the DLR control VMs recover from a split-brain condition.

    Workaround: Refer to VMware knowledge base article 2146413.

    Issue 1674721: NSX Edge is unmanageable after upgrading to NSX 6.2.3

    This issue occurs when serverSsl or clientSsl is configured in load balancer, but the cipher's value was set to NULL in the previous version.

    Workaround: Refer to VMware knowledge base article 2145887.

    Issue 1461421:"show ip bgp neighbor" command output for NSX Edge retains the historical count of previously established connections

    The “show ip bgp neighbor” command displays the number of times that the BGP state machine transitioned into the Established state for a given peer. Changing the password used with MD5 authentication causes the peer connection to be destroyed and re-created, which in turn will clear the counters. This issue does not occur with an Edge DLR.

    Workaround: To clear the counters, execute the clear ip bgp neighbor command.

    Issue 1676085: Enabling Edge HA will fail if resource reservation fails

    Starting with NSX for vSphere 6.2.3, enabling high availability on an existing Edge will fail when sufficient resources cannot be reserved for the second Edge VM appliance. The configuration will roll back to the last known good configuration. In previous releases, if HA is enabled after Edge deployment and resource reservation fails, the Edge VM still is created.

    Workaround: This is an expected change in behavior.

    Issue 1656713: IPsec Security Policies (SPs) missing on the NSX Edge after HA failover, traffic cannot flow over tunnel

    The standby-to-active resumption (failback) does not work for traffic flowing on IPsec tunnels.

    Workaround: Disable/Enable IPsec after the NSX Edge failover and recovery.

    Issue 1633694: Storage failure may induce loss of VXLAN configuration in the NSX Manager database

    After a storage failure, Virtual Center may report that the DVS is deleted, and NSX Manager responds by removing the VXLAN configuration associated with the DVS. When this condition occurs, a message similar to "INFO DCNPool-9 VcDriver:1077 - Deleting vmknic info from host tables [host-21843 : 319]" will be printed in the NSX Manager logs.

    Workaround: None.

    Issue 1588450: NSX Edge virtual machine do not failover during a vSphere HA event

    The issue occurs when the NSX edge virtual machine is configured after vSphere High Availability (HA) has been configured. When the NSX Edge virtual machine is configured, it is added to the ESXi Auto Shutdown/Start up configuration. The NSX Edge virtual machine is then removed from the vSphere HA protected list when a power off event is received from the ESXi host.

    Workaround: Refer to the VMware knowledge base article 2143998.

    Issue 1624663: After clicking "Configure Advanced Debugging" refreshes the VC UI and the change does not persist

    After clicking the specific edge ID > Configuration > Action > Configure Advanced Debugging causes the VC UI to refresh and the change does not persist

    Workaround: Go directly to the Edge list menu , highlight the edge, and click Action > Configure Advanced Debugging to continue with the changes.

    Issue 1354824: When an Edge VM becomes corrupted or becomes otherwise unreachable due to such reasons as a power failure, system events are raised when the health check from NSX Manager fails

    The system events tab will report "Edge Unreachability" events. The NSX Edges list may continue to report a Status of Deployed.

    Workaround: Use the https://NSX-Manager-IP-Address/api/4.0/edges/edgeId/status API with detailedStatus=true.

    Issue 1556924: L3 connectivity loss with VXLAN would block error

    When DLR LIF's are configured on the host but underlying VXLAN layer is not fully prepared, connectivity through some of DLR LIF's may be affected. Some of the VMs belonging to DLR are not reachable. There might be "Failed to Create VXLAN trunk status: Would block" logs in /var/log/vmkernel.log file.

    Workaround: You may delete the LIF's and recreate them. Another option is rebooting the affected ESX hosts.

    Issue 1647657: Show commands on an ESXi host with VDR display no more than 2000 routes per VDR instance

    Show commands on an ESXi host with VDR enabled will not show more than 2000 routes per VDR instance, although more than this maximum may be running. This issue is a display issue, and the data path will work as expected for all routes.

    Workaround: No workaround.

    Issue 1634215: OSPF CLI commands output does not indicate whether routing is disabled

    When OSPF is disabled, routing CLI commands output does not show any message saying "OSPF is disabled". The output is empty.

    Workaround: The show ip ospf command will display the correct status.

    Issue 1663902: Renaming an NSX Edge VM disrupts traffic flowing through the Edge

    Issue 1647739: Redeploying an Edge VM after a vMotion operation will cause the Edge or DLR VM to be placed back on the original cluster.  

    Workaround: To place the Edge VM in a different resource pool or cluster, use the NSX Manager UI to configure the desired location.

    Issue 1463856: When NSX Edge Firewall is enabled, existing TCP connections are blocked

    TCP connections are blocked through the Edge statefull firewall because the initial three-way handshake cannot be seen.

    Workaround: To handle such existing flows, do the following.

    1. Use the NSX REST API to enable the flag tcpPickOngoingConnections in the firewall global configuration. This switches the firewall from strict mode to lenient mode. To do this, use the NSX REST API method, api/4.0/edges/{edgeId}/firewall/config/global, passing as input:
      <globalConfig>
      <tcpPickOngoingConnections>true</tcpPickOngoingConnections>
      </globalConfig>
    2. Enable the firewall.
    3. Once existing connections have been picked up (this may take a few minutes after you enable the firewall), set the flag tcpPickOngoingConnections back to false to return the firewall to strict mode. (This setting is persistent.) Use the API method api/4.0/edges/{edgeId}/firewall/config/global again, passing as input:
      <globalConfig>
      <tcpPickOngoingConnections>false</tcpPickOngoingConnections>
      </globalConfig>

    Issue 1374523: Reboot ESXi, or run [services.sh restart] after installation of VXLAN VIB to make the VXLAN commands available using esxcli

    After installation of VXLAN VIB, you must reboot ESXi or run the [services.sh restart] command, so that the VXLAN commands becomes available using esxcli.

    Workaround: Instead of using esxcli, use localcli.

    Issue 1604514: Editing/Configuring default gateway on an unmanaged DLR fails after clicking Publish

    When a default gateway is added to an unmanaged DLR, the publish will fail with error "Routing Distance is support only on NSX Edge version 6.2.0 and later with NSX Edge VMs deployed". This is due to the default admin distance "1" populated on the UI.

    Workaround: Remove the admin distance "1" which is populated by default.

    Issue 1642087: After modifying the securelocaltrafficbyip parameter value in the IPsec VPN Extension, forwarding to destination networks fails

    When using an NSX Edge Services Gateway, you experience this symptom:

    • After changing the securelocaltrafficbyip value to 0 in the NSX UI (Edit IPsec VPN screen), forwarding to a remote subnet of the IPsec VPN tunnel no longer works
    • After changing this parameter, you no longer see the correct information for a remote subnet in the IP routing table

    Workaround: Disable and re-enable the IPSec VPN service. Then validate that the expected routing information is shown in the CLI and the UI.

    Issue 1606785: NSX Edge load balancer may fill the /var/log/partition with the nagios.log file messages
    The nagio.log file for the NSX Edge load balancer may fill the /var/log/partition if the daily log rotation rate is not sufficient to reset the logs in time.

    Workaround: Write the Nagios.log messages to syslog.

    Issue 1525003: Restoring an NSX Manager backup with an incorrect passphrase will silently fail as critical root folders cannot be accessed

    Workaround: None.

    Issue 1637639: When using the Windows 8 SSL VPN PHAT client, the virtual IP is not assigned from the IP pool
    On Windows 8, the virtual IP address is not assigned as expected from the IP pool when a new IP address is assigned by the Edge Services Gateway or when the IP pool changes to use a different IP range.

    Workaround: This issue occurs only on Windows 8. Use a different Windows OS to avoid experiencing this issue.

    Issue 1628220: DFW or NetX observations are not seen on receiver side
    Traceflow may not show DFW and NetX observations on receiver side if switch port associated with the destination VNIC changed. It will not be fixed for vSphere 5.5 releases. For vSphere 6.0 and up, there is no such issue.

    Workaround: Do not disable VNIC. Reboot VM.

    Issue 1534603: IPsec and L2 VPN service status shows as down even when the service is not enabled
    Under the Settings tab in the UI, the L2 service status is displayed as down, however the API shows the L2 status as up. L2 VPN and IPsec service always shows as down in the Settings tab unless the UI page is refreshed.

    Workaround: Refresh the page.

    Issue 1562767: Delays in connecting to NSX load balancer do not provide consistent connections over multiple VIPs
    When the load balancer is configured to use Source IP Hash load balancing, a connected client session receives a consistent connection to a backend server. The load balancer should also be able to provide, for a given connected client, consistent connections over multiple VIPs if those VIPs are backed by the same server pool. That is, when one backend server serves multiple VIPs, a given client's connection to one of that backend server's VIPs should guarantee that that client will use the same backend server when connecting to other VIPs served by that backend server. A known issue prevents the NSX load balancer from providing such consistent connections over multiple VIPs.

    Issue 1553600: Delays in connecting to RIB and FIB after assigning IP address to interface
    When you attempt to assign an IP address to an interface, typically, the interface information is updated immediately. However, when waiting for a polling event, you may observe a delay in seeing the assigned IP address. (The NSX logical router polls periodically to get changes in the interfaces.)

    Issue 1534799: Slow convergence when OSPF area border router with highest IP address is shut down
    Convergence takes a long time when the NSX-based, OSPF area border router (ABR) with highest IP address is shut down or rebooted. If an ABR that does not have the numerically highest IP address is shut down or rebooted, traffic converges quickly to another path. However, if the ABR with the highest IP address is shut down or rebooted, a multi-minute re-convergence time is seen. The OSPF process can be cleared manually to reduce the convergence time.

    Issue 1446327: Some TCP-based applications may time out when connecting through NSX Edge
    The default TCP established connection inactivity timeout is 3600 seconds. The NSX Edge deletes any connections idle for more than the inactivity timeout and drops those connections.

    Workaround:
    1. If the application has a relatively long inactivity time, enable TCP keepalives on the hosts with keep_alive_interval set to less than 3600 seconds.
    2. Increase the Edge TCP inactivity timeout to greater than 2 hours using the following NSX REST API. For example, to increase the inactivity timeout to 9000 seconds. NSX API URL:
      /api/4.0/edges/{edgeId}/systemcontrol/config PUT Method <systemControl> <property>sysctl.net.netfilter.nf_conntrack_tcp_timeout_established=9000</property> </systemControl>

    Issue 1534602: UI does not display Edge management plane mode (VIX/MSGBUS), and does not provide the option to change from VIX to MSGBUS
    When an Edge appliance is in VIX mode, it is not eligible to be selected for inclusion in DFW, and centralized CLI commands take much longer to run compared to MSGBUS mode
    Workaround: Make sure that the cluster where the Edge is deployed is prepared for NSX and its "NSX Manager to Firewall Agent" is in "Up" state, and redeploy the Edge.

    Issue 1498243: Distributed logical router advertises incorrect next hop for default route when BGP neighbor filter is set to "DENY, ANY, OUT"
    With 'default originate' enabled on an NSX distributed logical router (DLR), setting a BGP neighbor filter of "DENY, ANY, OUT" on the DLR causes the DLR to advertise an incorrect next hop address for the default route. This error occurs only when a BGP neighbor filter is added with the following attributes:

    • Action: DENY
    • Network: ANY
    • Direction: OUT

    Workaround: None.

    Issue 1471561: BGP/OSPF neighbor relationship is not established with directly connected routers 
    Dynamic routing does not work as expected with directly connected routers when ECMP routes exist for that directly connected network.

    Workaround: Reboot Edge OR delete and re-create the associated vNIC interface.

    Issue 1089745: Logical router LIF routes are advertised by upstream Edge Services Gateway even if logical router OSPF is disabled
    Upstream Edge Services Gateway will continue to advertise OSPF external LSAs learned from logical router connected interfaces even when logical router OSPF is disabled.

    Workaround: Disable redistribution of connected routes into OSPF manually and publish before disabling OSPF protocol. This ensures that routes are properly withdrawn.

    Issue 1498965: Edge syslog messages do not reach remote syslog server
    Immediately after deployment, the Edge syslog server cannot resolve the hostnames for any configured remote syslog servers.

    Workaround: Configure remote syslog servers using their IP address, or use the UI to Force Sync the Edge.

    Issue 1494025: Logical router DNS Client configuration settings are not fully applied after updating REST Edge API

    Workaround: When you use REST API to configure DNS forwarder (resolver), perform the following steps:

    1. Specify the DNS Client XML server's settings so that they match the DNS forwarder setting.

    2. Enable DNS forwarder, and make sure that the forwarder settings are same as the DNS Client server's settings specified in the XML configuration.

    Issue 1243112: Validation and error message not present for invalid next hop in static route, ECMP enabled
    When trying to add a static route, with ECMP enabled, if the routing table does not contain a default route and there is an unreachable next hop in the static route configuration, no error message is displayed and the static route is not installed.

    Workaround: None.

    Issue 1288487: If an NSX Edge virtual machine with one sub interface backed by a logical switch is deleted through the vCenter Web Client user interface, data path may not work for a new virtual machine that connects to the same port
    When the Edge virtual machine is deleted through the vCenter Web Client user interface (and not from NSX Manager), the VXLAN trunk configured on dvPort over opaque channel does not get reset. This is because trunk configuration is managed by NSX Manager.

    Workaround: Manually delete the VXLAN trunk configuration by following the steps below:

    1. Navigate to the vCenter Managed Object Browser by typing the following in a browser window:
      https://<vc-ip>/mob?vmodl=1
    2. Click Content.
    3. Retrieve the dvsUuid value by following the steps below.
      1. Click the rootFolder link (for example, group-d1(Datacenters)).
      2. Click the data center name link (for example, datacenter-1).
      3. Click the networkFolder link (for example, group-n6).
      4. Click the DVS name link (for example, dvs-1)
      5. Copy the value of uuid.
    4. Click DVSManager and then click updateOpaqueDataEx.
    5. In selectionSet, add the following XML.
      <selectionSet xsi:type="DVPortSelection">
          <dvsUuid>value</dvsUuid>
          <portKey>value</portKey> <!--port number of the DVPG where trunk vnic got connected-->
      </selectionSet>
    6. In opaqueDataSpec, add the following XML
      <opaqueDataSpec>
          <operation>remove</operation>
          <opaqueData>
            <key>com.vmware.net.vxlan.trunkcfg</key>
            <opaqueData></opaqueData>
          </opaqueData>
      </opaqueDataSpec>
    7. Set isRuntime to false.
    8. Click Invoke Method.
    9. Repeat steps 5 through 8 for each trunk port configured on the deleted Edge virtual machine.

    Security Services Known Issues

    Issue 1694483: After installing or upgrading to NSX for vSphere 6.2.3 with Distributed Firewall (DFW) and Security Groups (SG) configured, you may encounter traffic disruption upon a vMotion operation on compute virtual machines.
    See VMware knowledge base article 2146227.

    Issue 1632235: During Guest Introspection installation, network drop down list displays "Specified on Host" only
    When installing Guest Introspection with the NSX anti-virus-only license and vSphere Essential or Standard license, the network drop down list will display only the existing list of DV port groups. This license does not support DVS creation.

    Workaround: Before installing Guest Introspection on a vSphere host with one of these licenses, first specify the network in the "Agent VM Settings" window.

    Issue 1652155: Creating or migrating firewall rules using REST APIs may fail under certain conditions and report HTTP 404 error

    Adding or migrating firewall rules using REST APIs is not supported under these conditions:

    • Creating firewall rules as a bulk operation when the autosavedraft=true is set.
    • Adding firewall rules in sections concurrently.

    Workaround: Set the autoSaveDraft parameter to false in the API call when performing bulk firewall rule creation or migration.

    Issue 1509687: URL length supports up to 16000 characters when assigning a single security tag to many VMs at a time in one API call
    A single security tag cannot be assigned to a large number of VMs simultaneously with a single API if the URL length is more than 16,000 characters.

    Workaround:To optimize performance, tag up to 500 VMs in a single call.

    Issue 1662020: Publish operation may fail resulting in an error message "Last publish failed on host host number" on DFW UI in General and Partner Security Services sections

    After changing any rule, the UI displays "Last publish failed on host host number". The hosts listed on the UI may not have correct version of firewall rules, resulting in lack of security and/or network disruption.

    The problem is usually seen in the following scenarios:

    • After upgrade from older to latest NSXv version.
    • Move a host out of cluster and move it back in.
    • Move a host from one cluster to another.

    Workaround: To recover, you must force sync the affected clusters (firewall only).

    Issue 1481522: Migrating firewall rule drafts from 6.1.x to 6.2.3 is not supported as the drafts are not compatible between the releases

    Workaround: None.

    Issue 1491046: IPv4 IP address does not get auto approved when SpoofGuard policy is set to Trust On First Use (TOFU) in VMware NSX for vSphere 6.2.x

    Workaround: See VMware knowledge base article 2144649.

    Issue 1628679: With identity-based firewall, the VM for removed users continues to be part of the security group

    When a user is removed from a group on the AD server, the VM where the user is logged-in continues to be a part of the security-group. This retains firewall policies at the VM vnic on the hypervisor, thereby granting the user full access to services.

    Workaround: None. This behavior is expected by design.

    Issue 1662020: In a cross vCenter setup, an error message "Last publish failed on host 10.156.221.88" appears on DFW UI in General and Partner Security Services tabs

    The error message appears when the associated NIC for the rules is not present.

    Workaround: None.

    Issue 1637939: MD5 certificates are not supported while deploying hardware gateways

    While deploying hardware gateway switches as VTEPs for logical L2 VLAN to VXLAN bridging, the physical switches support at minimum SHA1 SSL certificates for OVSDB connection between the NSX controller and OVSDB switch.

    Workaround: None.

    Issue 1637943: No support for hybrid or multicast replication modes for VNIs that have a hardware gateway binding

    Hardware gateway switches when used as VTEPs for L2 VXLAN-to-VLAN bridging support Unicast replication mode only.

    Workaround: Use Unicast replication mode only.

    Issue 1620109: Deployment of third-party service VMs may not complete as expected, and Installation Status will be reported as "Failed"

    For example, the SVM may not receive the expected IP address. An error message of "Value provided for parameter property.info.key was not correct" is seen in the NSX Manager logs.

    Workaround: None.

    Issue 1462027: In cross vCenter NSX deployments, multiple versions of saved firewall configurations get replicated to secondary NSX Managers
    Universal Sync saves multiple copies of universal configurations on secondary NSX Managers. The list of saved configurations contains multiple drafts created by the synchronizing across NSX Managers with the same name and at the same time or with a time difference of 1 second.

    Workaround: Run the API call to delete duplicate drafts.

    DELETE: https://<nsxmgr-ip>/api/4.0/firewall/config/drafts/

    Find the drafts to be deleted by viewing all drafts:

    GET: https://<nsxmgr-ip>/api/4.0/firewall/config/drafts

    In the following sample output, drafts 143 and 144 have the same name and were created at the same time and are therefore duplicates. Likewise, drafts 127 and 128 have the same name are off by 1 second and are also duplicates.

    <firewallDrafts>
        <firewallDraft id="144" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120917">
            <description>Auto saved configuration</description>
            <preserve>false</preserve>
            <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
            <mode>autosaved</mode>
        </firewallDraft>
        <firewallDraft id="143" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120713">
            <description>Auto saved configuration</description>
            <preserve>false</preserve>
            <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
            <mode>autosaved</mode>
        </firewallDraft>
       <firewallDraft id="128" name="AutoSaved_Wednesday, August 5, 2015 9:08:02 PM GMT" timestamp="1438808882608">
            <description>Auto saved configuration</description>
            <preserve>false</preserve>
            <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
            <mode>autosaved</mode>
        </firewallDraft>
        <firewallDraft id="127" name="AutoSaved_Wednesday, August 5, 2015 9:08:01 PM GMT" timestamp="1438808881750">
            <description>Auto saved configuration</description>
            <preserve>false</preserve>
            <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
            <mode>autosaved</mode>
        </firewallDraft>
    </firewallDrafts>
    

    Issue 1449611: When a firewall policy in the Service Composer is out of sync due to a deleted security group, the firewall rule cannot be fixed in the UI

    Workaround: In the UI, you can delete the invalid firewall rule and then add it again. Or, in the API, you can fix the firewall rule by deleting the invalid security group. Then synchronize the firewall configuration: Select Service Composer: Security Policies, and for each security policy that has associated firewall rules, click Actions and select Synchronize Firewall Config. To prevent this issue, modify firewall rules so that they do not refer to security groups before deleting the security groups.

    Issue 1557880: Layer 2 (L2) rules may be missing if the MAC address of a VM used in the rules is modified
    Because L2 rule optimization is ON by default, L2 rules with both source and destination fields specified (other than "any") will be applied to vNICs(or filters) only if the vNIC MAC address matches the source or destination MAC address list. Hosts with VMs not matching the source or destination MAC addresses will not have those L2 rules applied.

    Workaround: To have L2 rules applied to all vNICs(or filters), set one of the source or destination fields to "any".

    Issue 1505316: NSX NetX rule not published to host when selected service is a Service Group
    When creating an L3 Redirection rule in the Partner Services tab in DFW, selecting a Service Group doesn't create the rule correctly.

    Workaround: Use individual services when creating the rule instead of using a Service Group.

    Issue 1496273: UI allows creation of in/out NSX firewall rules that cannot be applied to Edges
    The web client incorrectly allows creation of an NSX firewall rule applied to one or more NSX Edges when the rule has traffic traveling in the 'in' or 'out' direction and when PacketType is IPV4 or IPV6. The UI should not allow creation of such rules, as NSX cannot apply them to NSX Edges.

    Workaround: None.

    Issue 1493611: No connectivity on VLAN ID 0 in L2 VPN
    NSX L2 VPN configuration incorrectly allows the user to configure an L2 VPN with VLAN ID 0. Once configured, no traffic can flow on this VPN.

    Workaround: Workaround: Use a valid VLAN ID in the range from 1 to 4094.

    Issue 1534574: There is no support for Cipher 3C (SHA-256) encryption algorithms for SSLVPN-Plus

    Issue 1557924: Universal logical switch is allowed to be consumed in the appliedTo field of a local DFW rule
    When a universal logical switch is used as a security group member, the DFW rule can use that security group in AppliedTo field. This indirectly applies the rule on the universal logical switch, which should not be allowed because it may cause unknown behavior of those rules.

    Workaround: None.

    Issue 1559971: Cross-vCenter NSX firewall exclude list not published if firewall is disabled on one cluster
    In cross-vCenter NSX, firewall exclude list is not published to any cluster when the firewall is disabled on one of the clusters.

    Workaround: Force sync the affected NSX Edges.

    Issue 1407920: Firewall rule republish fails after DELETE API is used
    If you delete the entire firewall configuration through the DELETE API method and then try to republish all the rules from a previously saved firewall rules draft, then the rule publish will fail.

    Issue 1534585: Publishing Distributed Firewall (DFW) rules fails after referenced object is deleted in VMware NSX for vSphere 6.1.x and 6.2.x

    Workaround: If this occurs, see knowledge base article 2126275.

    Issue 1494718: New universal rules cannot be created, and existing universal rules cannot be edited from the flow monitoring UI

    Workaround: Universal rules cannot be added or edited from the flow monitoring UI. EditRule will be automatically disabled.

    Issue 1442379: Service composer firewall configuration out of sync
    In the NSX service composer, if any firewall policy is invalid (for example of you deleted a security group that was currently in use in a firewall rule), deleting or modifying another firewall policy causes the service composer to become out of sync with the error message Firewall configuration is not in sync.

    Workaround: Delete any invalid firewall rules and then synchronize the firewall configuration. Select Service Composer: Security Policies, and for each security policy that has associated firewall rules, click Actions and select Synchronize Firewall Config. To prevent this issue, always fix or delete invalid firewall configurations before making further firewall configuration changes.

    Issue 1301627: Security policy name does not allow more than 229 characters
    The security policy name field in the Security Policy tab of Service Composer can accept up to 229 characters. This is because policy names are prepended internally with a prefix.

    Workaround: None.

    Issue 1443344: Some versions of 3rd-party Networks VM-Series do not work with NSX Manager default settings
    Some NSX 6.1.4 components disable SSLv3 by default. Before you upgrade, please check that all third-party solutions integrated with your NSX deployment do not rely on SSLv3 communication. For example, some versions of the Palo Alto Networks VM-series solution require support for SSLv3, so please check with your vendors for their version requirements.

    Issue 1438859: In upgraded NSX installations, publishing a firewall rule may result in Null Pointer exception in Web Client
    In upgraded NSX installations, publishing a firewall rule may result in a Null Pointer exception in the UI. The rule changes are saved. This is a display issue only.

    Monitoring Services Known Issues

    Issue 1655593: Missing status on NSX Dashboard when logging in as Auditor or Security Admin roles

    When viewing NSX Dashboard as Auditor or Security Admin, a error message "User is not authorized to access object ... and feature ... Please check object access scope and feature permissions for the user" appears. For example, Auditor may not be able to see "Logical Switch Status" from the Dashboard.

    Workaround: None.

    Solution Interoperability Issues

    Issue 1568861: The NSX Edge deployment fails during any edge deployment from a VCD cell that does not own the VC listener

    The NSX Edge deployment fails during any Edge deployment from a VCD cell that does not own the VC listener. Also, NSX Edge actions, including a redeploy, fail from VCD.

    Workaround:

    Deploy an NSX Edge from the VCD cell which owns the VC listener.

    Issue 1530360: After an NSX Manager VM has failed over, Site Recovery Manager (SRM) incorrectly reports a timeout error

    When a NSX Manager VM is failed over, SRM incorrectly reports a timeout error waiting for VMware Tools. In this case, VMware Tools actually is up and running within the 300 second timeout.

    Workaround: None.

    NSX Controller Known Issues

    Issue 1516207: Controller(s) may become isolated after IPsec communication is re-enabled on in NSX controller cluster

    If an NSX controller cluster is set to allow controller-to-controller communications in the clear (IPsec is disabled), and IPsec-based communication is later re-enabled, one or more controllers may become isolated from the cluster majority due to a mismatched pre-shared key ("PSK"). When this occurs, the NSX API may become unable to change the IPsec settings of the controllers.

    Workaround:

    Follow these steps to address this issue:

    1. Disable IPSec using the NSX API.

      PUT: /2.0/vdn/controller/node <controllerNodeConfig>
      <ipSecEnabled>false</ipSecEnabled>
      </controllerNodeConfig>

    2. Re-enable IPsec using the NSX API.

      PUT: /2.0/vdn/controller/node <controllerNodeConfig>
      <ipSecEnabled>true</ipSecEnabled>
      <controllerNodeConfig>

    Follow these best practices to avoid this issue:

    • Always use the NSX API to disable IPsec. Using the NSX Controller CLI to disable IPsec is not supported.
    • Always verify that all controllers are active before you use the API to change the IPsec setting.

    Issue 1306408: NSX Controller logs must be downloaded sequentially
    NSX Controller logs cannot be downloaded simultaneously. Even when downloading from multiple controllers, you must wait for the download from the current controller to finish before you start the download from the next controller. Note also that you cannot cancel a log download once it has started.

    Workaround: Wait for the current controller log download to finish before starting another log download.

    Resolved Issues

    See what's resolved in 6.2.3, or in 6.2.2 and earlier.

    Issues Resolved in NSX 6.2.3

    6.2.3 resolved issues are grouped as follows:

    General Resolved Issues in 6.2.3

    • Fixed issue 1644529: Security patch to address the security vulnerability, CVE-2016-2079
      The 6.2.3 release delivers a security patch to address CVE-2016-2079.

    • Fixed issue 1571156: vCenter 6.0 restart/reboot may result in duplicate VTEPs on VXLAN prepared ESX hosts
      See VMware knowledge base article 2144605. This has been fixed in NSX 6.2.3.

    Install and Upgrade Resolved Issues in 6.2.3

    • Fixed issue 1578509: After EAM restart, Guest Introspection(GI) Service status is in warning state
      This has been fixed in NSX 6.2.3.

    • Fixed issue 1539203: After NSX upgrade, NSX plugin gets disconnected from Primary VC during a Cross-vCenter Upgrade
      This has been fixed in NSX 6.2.3.

    • Fixed issue 1558017: After upgrading the NSX Edge from 6.1.x to 6.2.x, the NSX Manager vsm.log shows "INVALID DHCP CONFIG"
      If you have an interface with an IPv6 subnet, DHCP generates an empty shared subnet and treats it as an invalid operation.

    NSX Manager Resolved Issues in 6.2.3

    • Fixed issue 1534588: Previous backups are not displayed in the NSX Manager UI
      Running a backup operation never shows a successful completion at the NSX Manager UI. Either one of these issues may manifest if a large number of backup files are stored in the destination folder. Each backup file has to be checked for compatibility before displaying the list on the same page. The current file list process can cause the page to timeout.
      This has been fixed in NSX 6.2.3.

    • Fixed Issue 1593910: Duplicate NSX Manager IP address is not detected or prevented
      If the NSX Manager IP address is assigned to another device on the network, an explicit error or event log is not generated. As a result, NSX controllers and hosts may respond to NSX Manager using an incorrect MAC address, causing a data path outage. Workaround: Attempt to determine and then remove the other network device from the network or assign it a different IP address. Due to presence of duplicate NSX manager IP in the network, hosts and Controllers are responding to NSX Manager/VM using the wrong MAC address. This affects communications between NSX Manager and ESX and between NSX Manager and NSX Controllers. This can result in a datapath outage. In this case applications are impacted until the duplicate IP is removed from the network and communication channels are restored.
      This has been fixed in NSX 6.2.3 by adding a system event when a duplicate IP address is detected.

    • Fixed issue 1489648: NSX is unavailable from the vSphere Web Client Plug-in after taking a backup of NSX Manager with quiesced snapshot
      See VMware knowledge base article 2142263. This has been fixed in NSX 6.2.3.

    • Fixed issue 1440451: NSX Manager certificate replacement requires restart of NSX Manager and may require restart of vSphere Web Client
      After you replace the NSX Manager appliance certificate, you must always restart the NSX Manager appliance. In certain cases after a certificate replacement, the vSphere Web Client will not display the "Networking and Security" tab.

    • Fixed issue 1568861: Unable to add Secondary NSX Manager if GUI is Japanese language on Firefox browser
      When adding a secondary NSX Manager with German, Japanese, Korean, or French locale and a Firefox browser, the thumbprint dialog is not shown, blocking the configuration.

    Logical Networking Resolved Issues in 6.2.3

    • Fixed issue 1591582: In some corner conditions ARP requests sent by VDR instance might get dropped
      VDR ARP requests for remote VMs located on other hosts may get dropped at VDR uplink output processing, causing slow connection establishment.

    • Fixed Issue 1604506: Cannot deploy DLR without NSX Edge VM if using default gateway for static routing use case
      When deploying a new Distributed Logical Router (DLR) through the Web Client, by selecting the "Configure Default Gateway" option during configuration, the DLR fails to create and an error appears. See the VMware knowledge base article 2144551 for more information. This has been fixed in NSX 6.2.3.

    • Fixed Issue 1501900: Edge OSPF router remains stuck in ExchangeStart date after changing OSPF interface IP address
      Due to a race condition, changing the IP address on an OSPF interface was causing the OSPF neighbors to remain stuck in ExchangeStart state on both sides.​ Under normal conditions, it is a supported operation to change the OSPF interface IP address.
      This has been fixed in NSX 6.2.3.

    • Fixed issue 1498251: IS-IS is not a supported routing protocol for the Edge Services Gateway router
      The references to IS-IS are removed from the UI and APIs in NSX 6.2.3.

    • Fixed issue 1492738: Unable to add more than eight uplink interfaces during Distributed Logical Router (DLR) deployment using vSphere Web Client
      This has been fixed in NSX 6.2.3.

    • Fixed issue 1552038: Intermittent loss of connectivity from NSX Edge to DLR uplink interface
      This issue was caused by the NSX Edge having the DLR control VM’s MAC address in its ARP table rather than the local instance MAC address of the DLR. This release adds an outbound ARP filter to prevent the DLR control VM from generating ARPs related to the DLR IP address.

    • Fixed issue 1454161: Static routes with a next hop as a /31 IP address cannot be configured
      This has been fixed in NSX 6.2.3.

    • Fixed issue 1528443: VXLAN ARP cache on the hosts not being updated when an Edge VM sends a GARP during failover
      In certain deployments where the VM's and Edge are on the same VXLAN segment, VXLAN ARP cache on the host won't get updated after the Edge failover. This has been fixed in NSX 6.2.3.

    • Fixed issue 1600874: Stranded VMs are not removed when new Edge VM is being deployed
      When upgrading an Edge, if the publish operation and roll back operations both fail, the original Edge VM remains in the NSX Manager database, while VC retains the new Edge VM's ID number. Due to this mismatch, redeploying an Edge VM will fail. A force sync also will fail with a "VM not found" error.

    • Fixed issue 1467774: Incorrect value shown for admin distance field in "show ip bgp neighbor" command
      A route learned from a EBGP peer and advertised to an IBGP peer in the same AS incorrectly retains the previous admin distance. This issue has been fixed in 6.2.3.

    • Fixed issue 1613383: For an NSX Edge Load Balancer running in L4 mode, the current connections value incorrectly used the total connections number
      This release fixes the issue by calculating the current connections using a sum of the active connections. This issue has been fixed in 6.2.3.

    • Fixed issue 1584664: If load balancer pool VM members are removed manually from the vCenter inventory without first being unconfigured in NSX, orphan database entries are left behind in the NSX Manager database. An ObjectNotFoundException will be reported in the NSX Manager logs.
      This issue has been fixed in 6.2.3.

    • Fixed issue 1446809: NSX Edge can no longer be managed by vCloud Director if no health check recovery event is sent after an Edge reboot
      NSX Manager saves Edge connectivity status in memory. When an Edge VM fails to respond to a health check, a miss event is raised, and on recovery, a recovered event is raised. If NSX Manager is restarted, the recovery event may not be sent if no health checks were missed after the reboot. As vCloud Director depends on these events, a missed recovery event can lead to an unmanageable Edge VM from VCD.

    NSX Edge Services Resolved Issues in 6.2.3

    • Fixed issue 1456172: NAT does not translate IP addresses when NSX Edge firewall is disabled
      When the Edge gateway firewall is disabled, all stateful services also are disabled if the Edge device is a 6.0 Extra Large or 6.1 and 6.2 Edge device. NSX 6.2.3 release adds a warning at the UI that other stateful services also are disabled.

    • Fixed issue 1499601: Extended HA failover times for Edge Services Gateway (ESG) or DLR with Edge VM when using only static routes
      This has been fixed in NSX 6.2.3.

    • Fixed issue 1618289: Unexpected TCP interruption on TCP sessions during Edge High Availability (HA) failover in VMware NSX for vSphere 6.2.x
      This issue occurred due to outdated internal libraries that are used in VMware NSX for vSphere 6.2.x. This has been fixed in NSX 6.2.3.

    • Fixed Issue 1653484: NSX Edge core dumps did not display function names
      NSX 6.2.3 enhances debugability by displaying memory address information in the core file. However, you must enable core dumps only when requested by VMware technical support.
      This has been fixed in NSX 6.2.3.

    Security Services Resolved Issues in 6.2.3

    • Fixed issue 1619570: In a large-scale DFW configuration with millions of rules and Service Composer, rule publishing may require several seconds to complete after a reboot. During this time, new rules cannot be published
      NSX 6.2.3 reduces the time to sync the firewall rules on reboot by re-syncing only those firewall policies for which the latest revision has not been processed due to reboot.

    • Fixed issue 1526781: Querying the getFirewallConfigLayer3SectionByName API does not return the responseHeaders field on NSX 6.2.x
      This issue has been fixed in 6.2.3 and the ETag header information reinstated in the API output.

    • Fixed issue 1599576: An edited rule in a universal firewall section may fail to be published because a null value was being set for the Global Section ID field.
      No error message is reported.This has been fixed in NSX 6.2.3.

    • Fixed Issue 1558501: Guest Introspection installation may fail when the Universal SVM to NSX Manager connection fails
      When NSX Manager is configured with a FQDN only, the messaging channel between NSX Manager and the Guest Introspection Service VM may fail. When this issue occurs, the Guest Introspection Service Status remains in "Warning" status. An "UnknownHostException" message is displayed in the eventmanager.log file on the USVM. This has been fixed in NSX 6.2.3 by adding automatic DNS support.

    • Fixed Issue 1673068: Editing firewall rules within Service Composer Policy section causes out-of-sync configuration
      Service Composer goes out-of-sync when firewall rules are added or edited from within the Service Composer policy section of the firewall configuration screen. This has been fixed in NSX 6.2.3, by changing the Service Composer section of the firewall configuration to read-only. Rules created through Service Composer must be managed through Service Composer. This has been fixed in NSX 6.2.3.

    • Fixed issue 1639612: MSRPC connectivity issues with Windows 2008 and later in NSX for vSphere 6.2.x
      In later versions of Windows which support 64-bit addressing, the DCE/EPM protocol negotiates NDR64 as the transfer encoding format, leading the firewall to not parse the EPM response packet, hence failing to detect the dynamic port to open. See VMware knowledge base article 2145135. This has been fixed in NSX 6.2.3.

    • Fixed issue 1567693: Using IPset as source/destination in NetX rule displays the error Invalid container type: IPSet
      This has been fixed in NSX 6.2.3.

    • Fixed issue 1407920: If you delete the firewall configuration using a REST API call, you cannot load and publish saved configurations
      When you delete the firewall configuration, a new default section is created with a new section ID. When you load a saved draft (that has the same section name but an older section ID), section names conflict and display the following error: Duplicate key value violates unique constraint firewall_section_name_key. This has been fixed in NSX 6.2.3.

    • Fixed issue 1498504: VM loses firewall protection when removed from one of two overlapping service groups
      NetX filters (created by firewall workflow) on the host are removed when another service created by Service Composer workflow is applied to the same VM. This could happen, for example, when one service profile was applied to two overlapping service groups. In this case if a VM is in both service groups and then is removed from one of the service groups, it loses protection. This has been fixed in 6.2.3 by introducing the priority field in the service profile. If there are overlapping service groups for a VNIC on a host, the service profile with the highest priority is applied.

    • Fixed issue 1550370: Linux virtual machines with NFSv3 mounts experience an operating system hang after more than 15 minutes outage on the upstream datapath
      See VMware knowledge base article 2133815. This has been fixed in NSX 6.2.3.

    • Fixed issue 1494366: Copy and paste of a firewall rule with negate source/destination enabled will list a new rule with Negate option disabled
      When copying a firewall rule with the negate source/destination option enabled, a new firewall is created with this option disabled. This has been fixed in NSX 6.2.3.

    • Fixed issue 1473767: Flow Monitoring drops flows that exceed a 2 million flows / 5 minutes limit
      NSX Flow Monitoring retains up to 2 million flow records. If hosts generate more than 2 million records in 5 minutes, new flows are dropped. This has been fixed in NSX 6.2.3.
      See VMware knowledge base article 2091376.

    • Fixed issue 1611238: In 6.2.x Edge Firewall only the Security Groups created at Edge Scope (SGs at Edge Scope can be created only through REST) used to appear
      In 6.2.3, SGs created at Global Scope (these can be created in UI) and SGs created at Edge scope for the corresponding Edge (these can be created only through REST) appear in the Edge Firewall in the Security Group listing under the Source/Destination columns. This has been fixed in NSX 6.2.3.

    • Fixed issue 1516460: Firewall rules continued to be marked as valid even after the applied-to logical switch in the rule was deleted
      This has been fixed in 6.2.3.

    • Fixed issue 1542157: Loss of distributed firewall functionality after vMotion of protected VMs to destination host
      Removing an NSX-prepared host from the VC inventory removes the host entry in the internal firewall tables. Later adding that host back to the VC inventory was not re-creating the firewall table entries. This has been fixed in 6.2.3.

    • Fixed issue 1592439: Service Composer fails to translate virtual machines into security-groups
      This issue occurred due to a deadlock in EpSecLib on the Universal Service Virtual Machine (USVM). This has been fixed in 6.2.3.

    Monitoring Services Resolved Issues in 6.2.3

    • Fixed issue 1617561: vmkernel log files floods with "ALERT: vdrb: VdrArpInput:1015: CP:Malformed pkt"
      This happens when networking device such as server is sending ARP request in IEEE 802 Networks ARP format. This has been fixed in 6.2.3.

    • Fixed issue 1525620: The icmpCode value in a distributed firewall rule was not being sent to the host. The protocolName and subProtocolName values work as expected
      This has been fixed in 6.2.3.

    • Fixed issue 1563830: Applying firewall rule on a DLR appliance with the source or destination as'mgmtInterface' fails
      A message similar to "vShield Edge:10014:Configuration failed on NSX Edge vm" is reported in the NSX Manager logs. This has been fixed in 6.2.3.

    • Fixed issue 1474498: Importing draft firewall rules fails after existing firewall configuration is removed by a REST API request
      This issue occurs when drafts are created in VMware NSX for vSphere 6.1.x and 6.2.x containing section id = null. This has been fixed in 6.2.3.

    Solution Interoperability Resolved Issues in 6.2.3

    • Fixed issue 1571170: Some Log Insight reports are not supported in NSX 6.2 with some vRealize Content Pack versions
      This has been fixed in the latest version of the Log Insight Content Pack. Download and install the content pack from VMware Solution Exchange. This has been fixed in NSX 6.2.3.

    • Fixed Issue 1484506: PSOD during ESXi upgrade
      When you are upgrading an NSX-enabled vSphere 5.5U2 host to vSphere 6.0, some of the ESXi host upgrades might halt with a purple diagnostic screen (also known as a PSOD). See VMware knowledge base article 2137826. This has been fixed in 6.2.3.

    The following issues were resolved in the 6.2.2, 6.2.1, and 6.2.0 releases:

    6.2.2, 6.2.1, and 6.2.0 resolved issues are grouped as follows:

    General Resolved Issues in 6.2.2 and earlier

    • Fixed issue 1529665: The DaaS service is not working as the service using 2 different VIPs (one VIP for HTTP and another for PCoIP) that must have exactly the same persistency
      This issue has been fixed in 6.2.1.
    • Fixed issue 1631261: IDFW is configured to work with Log Scraper and GI is also installed, after un-installing the GI, IDFW stops working
      This has been fixed in NSX 6.2.2.

    • Fixed issue 1551773: Edge Security Gateway (ESG) HA vNIC dropdown selection is always empty in VMware NSX for vSphere 6.2.0
      This has been fixed in NSX 6.2.2. See VMware knowledge base article 2138158.

    • Fixed issue 1608608: Security patch to address the glibc vulnerability, CVE-2015-7547
      The 6.2.2 release delivers a security patch to address CVE-2015-7547.

    • Fixed issue 1480581: netcpa sockets are CLOSED and VM fails to communicate across VNIs, subnets
      This issue was fixed by fixing thread unsafe use of boost::asio in vmacore. This has been fixed in NSX 6.2.2. See VMware knowledge base article 2137011.

    • Fixed issue 1583566: Rules not pushed to host
      DFW rule/ip list updates failed to be scheduled due to task framework resource limitations in NSX Manager. Error message showed a failure to queue tasks for Change Notification threads. This has been fixed in NSX 6.2.2.

    • Fixed issue 1573818: Traffic interrupted for 50 seconds after HA failover on ESG
      This issue was caused when NSX failed to synchronize the static routes among the HA NSX Edge nodes. This has been fixed in NSX 6.2.2.

    • Fixed issue 1570808: NSX load balancer IP_HASH health check issue
      In IPVS, when using the source-ip hash algorithm, if the selected backend server's weight equals 0, a "service unavailable" reply is sent even if there are healthy backend servers. This has been fixed in NSX 6.2.2.

    • Fixed issue 1564005: In NSX NetX, cannot add rules to redirect traffic to partner devices
      Customers were unable to add traffic redirection rules to their NetX rule sets. As a result, customers were unable to redirect traffic to partner devices. This affected rules that used IP address sets. This issue was caused by incorrect handling of IP ranges in the NetX rules. This has been fixed in NSX 6.2.2.

    • Fixed issue 1587660: NSX NetX error in DVFilterProcessSlowPathPackets
      Using NSX NetX without DFW resulted in an error in DVFilter. The full error message indicated NetX error PF (err=11,cr2=0x10) in DVFilterProcessSlowPathPackets: VSIPDVFProcessSlowPathPackets: PFFilterPacket. This has been fixed in NSX 6.2.2. See VMware knowledge base article 2144018.

    • Fixed issue 1591673: Adding ESXi host to vSphere Distributed Switch fails with license error
      In NSX 6.2.1 only, adding an ESXi host to a vSphere Distributed Switch failed with license error: "Host IP address is not licensed for the VDS feature. Cannot add this host to dvSwitch." For details, see VMware knowledge base article 2143397. This has been fixed in NSX 6.2.2.

    • Fixed issue 1590563: Enterprise license error after upgrade
      The NSX 6.2.1 upgrade routine allowed you to upgrade to 6.2.1 without a VMware Enterprise License, but after upgrade, the Enterprise License was required in orer to use NSX. This has been fixed in NSX 6.2.2. See VMware knowledge base article 2135310.

    • Fixed issue 1589046: Packet sent to LIF without DHCP relay results in PSOD
      The ESXi host suffers a PSOD if a DHCP unicast packet is addressed to the IP of a LIF that is expected to have DHCP relay enabled but the actual receiving LIF does not have DHCP relay enabled. This has been fixed in NSX 6.2.2. See VMware knowledge base article 2144314.

    • Fixed issue 1593436: In VXLAN hybrid mode, controller disconnection incorrectly triggers fallback to multicast mode
      This has been fixed in NSX 6.2.2. See VMware knowledge base article 2144457.

    • Fixed issue 1574995: DFW Publishing error
      Modifying and saving DFW rules in filtered mode may result in rules not being saved and published. This has been fixed in NSX 6.2.2. See VMware knowledge base article 2141155.

    • Fixed issue 1422110: One of the NSX Controllers does not hand over master role to other controllers when it is shut down
      This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1483728: Control plane connectivity fails for NSX Controller
      Control plane connectivity was seen to fail for a Controller, showing an error in netcpa related to txInProgress. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1487910: Upgrading Edge Services Gateway fails with "Timed out waiting for Edge vm" message
      Applying an IPv6 address to the NSX management interface causes NSX Manager to use the host name. The vsfwd proxy which connects the Edge VM to NSX Manager does not correctly handle a FQDN, resulting in a error similar to "ERROR TaskFrameworkExecutor-6 AbstractEdgeApplianceManager:185 - Timed out waiting for Edge vm {}. Vm took too long to boot and respond com.vmware.vshield.edge.exception.VshieldEdgeException". This has been fixed in NSX 6.2.0.

    • Fixed issue 1571548: In NSX for vSphere release 6.2.0 and later, if a VTEP IP address is changed directly on a host or in VC, the old IP address of the VTEP is released automatically.
      This has been fixed in NSX 6.2.0.

    • Fixed issue 1551164: NSX User Interface (UI) is grayed out for several seconds and exhibits slow performance on NSX for vSphere 6.2.0
      See VMware knowledge base article 2141919. This has been fixed in NSX 6.2.1.

    • Fixed issue 1545840: Cannot disable the NSX distributed firewall (DFW) on a host in VMware NSX for vSphere 6.x
      See also VMware knowledge base article 2141915. This has been fixed in NSX 6.2.1.

    • Fixed issue 1528680: VMware ESXi 5.x and 6.x experiences a purple diagnostic screen when using IP discovery in VMware NSX for vSphere 6.2.0 (KB 2134329)
      When using IP discovery on logical switches in VMware NSX for vSphere 6.2.0, the ESXi 5.x and 6.x host fails with a purple diagnostic screen as explained in knowledge base article 2134329. This has been fixed in NSX 6.2.1.

    • Fixed issue 1545885: Manage option on Security Tag portlet is grayed out by default
      On a Virtual Machine's summary page, the "Manage" hyperlink on the security tag portlet remains grayed out till the user creates a new security tag. This has been fixed in NSX 6.2.1.

    • Fixed issue 1476087: Some Controller logs not available for syslog export.
      Controller logs, including Zookeeper clustering logs, are not part of syslog export. This has been fixed in NSX 6.2.1.

    • Fixed issue 1545830: ESXi 6.0 PSOD on vdl2 when pinging with data size higher than available data size for the MTU
      Starting ping from NSX host switch attached vmknic will lead to host PSOD if data size if greater than MTU.This has been fixed in NSX 6.2.1.

    • Fixed issue 1545873: Users needed to configure same IP address and port number for both TCP and UDP protocol
      This release resolves the following issues as well:

      • UDP virtual server without pool configuration leads to configuration failure.
      • Statistics shows incorrect data when UDP virtual server is not associated with any pool.

      This has been fixed in NSX 6.2.1. With 6.2.1 release, users can use the same IP address and port number for both TCP and UDP with/without a pool associated.

    Install and Upgrade Resolved Issues in 6.2.2 and earlier

    • Fixed issue 1490496: After NSX upgrade, Guest Introspection fails to communicate with NSX Manager
      After upgrading from NSX 6.0.x to NSX 6.1.x or from NSX 6.0.x to NSX 6.2 and before the Guest Introspection service is upgraded, the NSX Manager cannot communicate with the Guest Introspection Universal Service Virtual Machine (USVM). This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1536179: SSL VPN-Plus client cannot be installed on Mac OS X Yosemite and higher
      Earlier versions of Mac OS X are supported. This has been fixed in NSX 6.2.1.

    • Fixed issue 1393503: After upgrading NSX vSphere from 6.0.7 to 6.1.3, vSphere Web Client crashes on login screen
      After upgrading NSX Manager from 6.0.7 to 6.1.3, you will see exceptions displayed on the vSphere Web Client UI login screen. You will not be able to login and perform operations on either vCenter or NSX Manager. This has been fixed in NSX 6.2.0.

    • Fixed issue 1088497: Guest Introspection installation fails with error
      When installing Guest Introspection on a cluster, the install fails with the following error:
      Invalid format for VIB Module. This has been fixed in NSX 6.2.0.

    • Fixed issue 1328589: DVPort fails to enable with "Would block" due to host prep issue
      On an NSX-enabled ESXi host, the DVPort fails to enable with "Would block" due to a host preparation issue. When this occurs, the error message first noticed varies (for example, this may be seen as a VTEP creation failure in VC/hostd.log, a DVPort connect failure in vmkernel.log, or a 'SIOCSIFFLAGS' error in the guest). This happens when VIBs are loaded after the vSphere Distributed Switch (vDS) properties are pushed by vCenter. This may happen during upgrade. See knowledge base article 2107951. This has been fixed in NSX 6.2.0.

    • Fixed issue 1446544: Attempts to delete existing NSX Edge Gateway fail in an environment upgraded to NSX 6.1.4
      In NSX installations upgraded from 6.1.3 to 6.1.4, the existing NSX Edge Gateways cannot be deleted after the upgrade to 6.1.4. This issue does not affect new Edge Gateways created after the upgrade. Installations that upgraded directly from 6.1.2 or earlier are not affected by this issue. This has been fixed in NSX 6.2.0.

    • Fixed issue 1418836: The AES encryption unavailable when performing an NSX backup using third-party secured FTP backup. This has been fixed in NSX 6.2.0.

    • Fixed issue 1410153: NSX Manager UI does not display user-friendly error messages during host reboot
      In this 6.2 release, NSX Manager UI is updated to display detail error messages that describe the problems you might encounter during host reboot and provide possible solution. This has been fixed in NSX 6.2.0.

    • Fixed issue 1412133: Unable to install NSX VIB installation
      The installation of NSX VIB might not complete, as expected if the ixgbe driver fails to load from third-party module because it has been locked and prevents it from being used for installation. This has been fixed in NSX 6.2.0.

    • Fixed issue 1467438: Unable to start NSX Manager service after upgrading from vCloud Networking and Security (vCNS) 5.5.3
      After upgrading vCloud Networking and Security (vCNS) 5.5.3 to NSX 6.1.3, the NSX Manager service hangs and is unable to start successfully. This has been fixed in NSX 6.2.0.

    • Fixed issue 1440867: The message bus randomly does not start after NSX Edge reboot
      After restarting an Edge VM, the message bus often does not start after powering on, and an additional reboot is required. This has been fixed in NSX 6.2.0.

    NSX Manager Resolved Issues in 6.2.2 and earlier

    • Fixed issue 1482989 / 1522092: NSX Networking and Security shows all hosts as GREEN but Cluster status incorrectly shown as RED
      In NSX 6.1.4 and earlier, under rare conditions the NSX Networking and Security tab showed all hosts as GREEN but incorrectly showed the Cluster status as RED (incorrectly indicating an error condition).This has been fixed in NSX 6.1.5.

    • Fixed issue 1515656: NSX Manager CPU utilization is high after adding it to Active Directory domain
      NSX Manager CPU utilization is high after adding it to Active Directory domain. In the system logs of the NSX Manager, multiple Postgres threads are seen as running. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1484939: Unable to register NSX Manager 6.1.4 with vCenter, gives error: NSX Management Service operation failed
      This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1521710: NSX Manager web client displays error: Code 301002
      Description: When you navigate to NSX manager > Monitor > System Events, the web client displays the following message: Filter config not applied to vnic. Code 301002. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1479665: Starting in 6.2.1, NSX Manager queries each controller node in the cluster to get the connection information between that controller and the other controllers in the cluster
      This is provided in the output of the NSX REST API ("GET https://[NSX-MANAGER-IP-ADDRESS]/api/2.0/vdn/controller" command), which now shows the peer connection status between among the controller nodes. If NSX Manager finds the connection between any two controller nodes is broken, a system event is generated to alert the user. This has been fixed in NSX 6.2.1.

    • Fixed issue 1525516: Force-sync of controller is broken if backup-restore of manager is done on another appliance
      If an NSX Manager appliance is cloned and/or restored from a backup, a force-sync operation to an NSX controller cluster will fail. This issue does not occur for an NSX Manager deployed from scratch. This has been fixed in NSX 6.2.1.

    • Fixed issue 1509454: NSX logging heartbeat failures for hosts that are not part of the NSX installation
      When an NSX-prepared host is directly removed from the vCenter inventory (without first unpreparing it in NSX), NSX receives an unexpected 'Host Connected' DCN which causes partial removal of messaging infrastructure components from the host. As a result, the messaging link between NSX and the host may remain active when it should have been removed, and NSX may raise false 'Alert' SystemEvents for the host. This has been fixed in NSX 6.2.1. This has been fixed in NSX 6.2.1.

    • Fixed issue 1418655: NSX Manager is non-functional after running the write erase command
      When you restart the NSX Manager after running the write erase command, you might notice that the NSX Manager is not working as expected, such as the password to access the Linux shell has been reset, the setup command is missing, and so on. This has been fixed in NSX 6.2.0.

    • Fixed issue 1366669: Add Domain shows error at LDAP option with Use Domain Credentials
      In NSX 6.1.x, the user when trying to add an LDAP domain, the web client gave a User Name was not specified error, even when Username was provided in UI. This has been fixed in NSX 6.2.0. This has been fixed in NSX 6.2.0.

    • Fixed issue 1352169: CA signed certificate import needs an NSX Manager reboot before becoming effective
      When you import an NSX Manager certificate signed by CA, the newly imported certificate does not become effective until NSX Manager is rebooted. This has been fixed in NSX 6.2.0.

    • Fixed issue 1497113: Unable to import NSX Manager to LDAPS domain
      When you attempt to add NSX manager to LDAPS domain, the following error message appears.
      Cannot connect to host <Server FQDN>
      error message: simple bind failed: <Server FQDN:Number>
      . This has been fixed in NSX 6.2.0.

    Logical Networking Resolved Issues and NSX Edge Resolved Issues in 6.2.2 and earlier

    • Fixed issue 1441319: Connectivity loss after removing a logical interface (LIF) in installations with dynamic routing
      A problem was identified in the NSX Logical Router (Edge/DLR) when using dynamic routing (OSPF & BGP) that will cause network connectivity loss after removing a LIF. This affects NSX versions 6.0.x through 6.1.4. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1445291: RADIUS authentication server configuration fails on NSX Edge
      In NSX 6.1.5 and earlier, the RADIUS server secret key string had a 32-character limit; if the string exceeded this character limit, the RADIUS server failed to connect with the NSX Edge. The limit is now 64 characters. This was fixed in NSX 6.2.0.

    • Fixed issue 1534811: VIO Heat stack deployment fails intermittently for the VMware NSX for vSphere 6.x Edge with the error: Cannot allocate memory
      Health monitoring memory usage increases over time, eventually causing edge failure. This has been fixed in NSX 6.2.1.

    • Fixed issue 1500624: BGP filters are taking approximately 40 seconds to be effectively applied
      During this period all the redistribution policies are applied without filters. This delay applies only to NSX Distributed Logical Router (DLR) for OUT directions. This has been fixed in NSX 6.2.0.

    • Fixed issue 1484758: On NSX Edge subinterfaces, ICMP redirects are sent out, even when the Send ICMP redirect option is disabled
      By default, NSX Edge subinterfaces have Send ICMP redirect disabled. Although this option is disabled, ICMP redirects are sent out on edge subinterfaces. This has been fixed in NSX 6.2.0.

    • Fixed issue 1265605: Cannot add non-ASCII characters in bridge or tenant name for logical router
      NSX controller APIs do not support non-ASCII characters. This has been fixed in NSX 6.2.0.

    • Fixed issue 1341784: When a BGP neighbor filter rule is modified, the existing filters may not be applied for up to 40 seconds
      When BGP filters are applied to an NSX Edge running IBGP, it may take up to 40 seconds for the filters to be applied on the IBGP session. During this time, NSX Edge may advertise routes which are denied in the BGP filter for the IBGP peer. This has been fixed in NSX 6.2.0.

    • Fixed issue 1422110: One of the NSX Controllers does not hand over master role to other controllers when it is shut down
      Typically, when a controller assumes operations master role and is preparing to shut down, it automatically hands over the master role to other controllers. In this case, the controller fails to hand over the role to other controllers and the status becomes interrupted and then goes into disconnected mode. This has been fixed in NSX 6.2.0.

    • Fixed issue 1440790: Unable to pass VXLAN traffic between hosts with unicast or multicast
      When VMs are on the same host they can communicate across VXLAN with unicast or multicast, but cannot communicate when VMs are on different hosts. This has been fixed in NSX 6.2.0.

    • Fixed issue 1432420: Removing multiple BGP rules on NSX Edge/DLR at the same time causes web client to crash. This has been fixed in NSX 6.2.0. You can now delete multiple BGP rules at a time.

    • Fixed issue 1431716: Protocol address is briefly displayed after adding Border Gateway Protocol (BGP) deny rule
      You might notice that the protocol address is briefly displayed after adding Border Gateway Protocol (BGP) deny rule in NSX Edge services gateway. This has been fixed in NSX 6.2.0.

    • Fixed issue 1441773: VMs disconnect during vMotion
      You might notice that VMs disconnect during vMotion or you might receive alerts for VMs with disconnected NICs. This has been fixed in NSX 6.2.0.

    • Fixed issue 1463579: Unable to download controller snapshot
      When downloading controller snapshots, you might notice that you are unable to download snapshot for the last controller. For example, if you have three controllers, one can successfully download snapshots of the first two but you might fail to download snapshot of the third controller. This has been fixed in NSX 6.2.0.

    Networking and Edge Services Resolved Issues in 6.2.2 and earlier

    • Fixed issue 1445057: OSPF routes configured on NSX Edge Services Gateway (ESG) not honored in the logical router (DLR), and affected packets are dropped
      The problem occurs in cases when OSPF uses IP_HDRINCL option. On certain Linux kernels, when this option is present, it prevents the IP stack from fragmenting the packets. Hence, any packets greater than the interface MTU are dropped. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1406471: Syslog shows host name of backed up NSX Manager on the restored NSX Manager
      Suppose the host name of the first NSX Manager is A and a backup is created for that NSX Manager. Now a second NSX Manager is installed and configured to the same IP address as the old Manager according to backup-restore docs, but host name is B. Restore is run on this NSX Manager. The restored NSX Manager shows host name A just after restore and host name B again after reboot. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1444581: ESXi host might lose network connectivity
      An ESXi host might lose network connectivity and experience stability issues when multiple error messages similar to the following are logged in:
      WARNING: Heartbeat: 785: PCPU 63 didn't have a heartbeat for 7 seconds; *may* be locked up. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1444784: VMs disconnect during vMotion
      VMs disconnect during vMotion on 6.0.8 with message, VISP heap depleted. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1462506: Cannot redeploy NSX Edge with L2VPN Service configured with CA-signed certificate
      Cannot redeploy or change size of NSX Edge with L2VPN Service configured with CA-signed or self-signed certificate. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1440867: The message bus randomly does not start after NSX Edge reboot
      After restarting an Edge VM, the message bus often does not start after powering on, and an additional reboot is required. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1548939: When configuring a virtual server, the previously selected IP address is applied
      When creating a new virtual server, you might notice that the IP address is automatically applied from the list of previously selected IP pool. This happens when you have previously selected an IP pool to derive the Virtual Server IP. When you attempt to edit the virtual server IP Pool information, the information is not automatically sent to the backend from the UI and previous IP address derived from the IP Pool is automatically applied. This has been fixed in NSX 6.2.1.

    • Fixed issue 1599706: SYN/ACK packet lost in communication over LDR between two VNIs
      This has been fixed in NSX 6.2.2.

    • Fixed issue 1082549: When HA is enabled on Edge Services Gateway, OSPF hello and dead interval configured to values other than 30 seconds and 120 seconds respectively can cause some traffic loss during failover
      When the primary NSX Edge fails with OSPF running and HA enabled, the time required for standby to take over exceeds the graceful restart timeout and results in OSPF neighbors removing learned routes from their Forwarding Information Base (FIB) table. This results in dataplane outage until OSPF re-initiates converges. This has been fixed in NSX 6.2.0.

    • Fixed issue 1403594: VMs are unable to receive ping from Edge DHCP server
      VM's can ping the Edge gateway but unable to receive DHCP ping from an Edge gateway trunk over an overlay network. The Edge DHCP server is setup as a trunk port and fails to pass or receive any traffic. However, when the Edge Gateway and the DHCP Edge are on the same host they are able to ping each other. When the DHCP Edge is moved to another host, the DHCP Edge is unable to receive ping from the Edge Gateway. This has been fixed in NSX 6.2.0.

    • Fixed issue 1477176: Edge Load Balancer stats not correctly displayed in the vSphere Web Client
      The Load Balancer does not display the number of concurrent connection statistics in the chart in vSphere Web Client UI. This has been fixed in NSX 6.2.0.

    • Fixed issue 1399863: When the direct aggregate network in local and remote subnet of an IPsec VPN channel is removed, the aggregate route to the indirect subnets of the peer Edge also disappears
      When there is no default gateway on Edge and you remove all of the direct connect subnets in local subnets and part of the remote subnets at the same time when configuring IPsec, the remaining peer subnets become unreachable by IPsec VPN. This has been fixed in NSX 6.2.0.

    • Fixed issue 1484743: Unable to pass traffic through load balancer after upgrading to NSX 6.1.2 or later
      When using option Insert X-Forwarded-For on NSX Edge Load Balancer, traffic may not pass through the load balancer. This has been fixed in NSX 6.2.0.

    • Fixed issue 1449461: Running the clear ip ospf neighbor command returns a segmentation fault error
      This has been fixed in NSX 6.2.0.

    • Fixed issue 1418264: Unable to process Kerberos requests
      Certain Kerberos requests are failing when being balanced with an NSX Edge. This has been fixed in NSX 6.2.0.

    Security Services Resolved Issues in 6.2.2 and earlier

    • Fixed issue 1534597: NSX for vSphere 6.x Controllers disconnect intermittently
      Due to an IPSEC bug in the StrongSWAN package that was shipping in 6.1.4 and earlier releases, the tunnels between controllers weren’t established after IPSEC rekeying. This caused partial connectivity failures between controllers resulting in multiple different issues. For more information see knowledge base article 2127655. This has been fixed in NSX 6.1.5 and 6.2.1

    • Fixed issue 1491042: LDAP Domain Objects take too long to return or fail to return in Security Group Object Selection screen. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1468169: Delayed mouse movement when viewing FW rules
      In NSX Networking and Security section of vSphere Web Client, moving the mouse over rows in the Firewall Rules display results in a 3 second delay each time the mouse is moved. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1476642: Some IP Spoofguard rules in NSX-v are not applied correctly
      Some IP Spoofguard rules in NSX-v are not applied correctly. Instance is not present in the Security Group in NSX-v and needs to be manually added to the security group. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1510350: Bulk deletion in Service Composer user interface generates "between 0 to 0" message
      Bulk deletion of policies (~100) from the NSX Service Composer user interface generates a message, "It should be between 0 to 0". You may safely ignore this message. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1515656: Background operation for Policy deletion may take long time with high CPU utilization
      Deletion of a policy reevaluates all the remaining policies in background. This may take more than an hour on setups having large number of policies, large number of security groups, and/or large number of rules per policy. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1515630: All queued publishable tasks are marked as failed after the default timeout of 20 minutes
      Queues are maintained per NSX Edge and can publish in parallel for different Edges. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1545879: If you rename an existing firewall draft, the operation will fail with the UI displaying "Internal Server Error"
      This has been fixed in NSX 6.2.1.

    • Fixed issue 1545893: Some DFW central CLIs show "ERROR output 100" output
      In some situations, where a Virtual Network Adapter (vNIC) is disconnected, a discrepancy can arise between the vNIC state information in NSX Manager and the Host leading to an "ERROR output 100" in the centralized CLI. This has been fixed in NSX 6.2.1.

    • Fixed issue 1545853: Application Profile list is not sorted.
      The list of Application Profile names in NSX Edge when Service Insertion is enabled, is presented in an unordered fashion. This release incorporates the fix to present the Application Profile list in a sorted manner. This has been fixed in NSX 6.2.1.

    • Fixed issue 1545895: Central CLI commands that are run for a specific ESXi host time out on some setups
      This has been fixed in NSX 6.2.1.

    • Fixed issue 1491365: The vsfwd.log gets overwritten quickly with a large number of container updates
      After the SpoofGuard policy is changed the NSX Manager promptly sends the change to host but host takes longer to process the change and update the state of the virtual machine's SpoofGuard state. This has been fixed in NSX 6.2.0.

    • Fixed issue 1113755: Cannot configure NSX firewall using security groups or other grouping objects defined at global scope
      Administrator users defined at the NSX Edge scope cannot access objects defined at the global scope. For example, if user abc is defined at Edge scope and security group sg-1 is defined at global scope, then abc will not be able to use sg-1 in firewall configuration on the NSX Edge. This has been fixed in NSX 6.2.0.

    • Fixed issue 1425691: Delayed mouse movement when viewing FW rules
      In the NSX Networking and Security section of vSphere Web Client, moving the mouse over rows in the Firewall Rules display results in a 3 second delay. This has been fixed in NSX 6.2.0.

    • Fixed issue 1352926: UI shows error Firewall Publish Failed despite successful publish
      If Distributed Firewall is enabled on a subset of clusters in your environment and you update an application group that is used in one or more active firewall rules, any publish action on the UI will display an error message containing IDs of the hosts belonging to the clusters where NSX firewall is not enabled. This has been fixed in NSX 6.2.0.

    • Fixed issue 1295384: Deleting security rules via REST displays error
      If a REST API call is used to delete security rules created by Service Composer, the corresponding rule set is not actually deleted in the service profile cache resulting in an ObjectNotFoundException error. This has been fixed in NSX 6.2.0.

    • Fixed issue 1412713: Firewall rules do not reflect newly added virtual machine
      When new VMs were added to the logical switch, firewall rules are not updated correctly to include the newly added VMs. If you make a change to the firewall and publish changes the new objects are added to the policy. This has been fixed in NSX 6.2.0.

    • Fixed issue 1448022: Cannot select Active Directory objects when configuring security groups
      In NSX 6.1.x, AD/LDAP Domain Objects took a long time to return in the Security Group Object selection screen. This has been fixed in NSX 6.2.0.

    • Fixed issue 1473585: Cannot add firewall rule with source/destination as multiple comma-separated IP addresses. This has been fixed in NSX 6.2.0.

    • Fixed issue 1460351: Unable to move NSX Distributed Firewall (DFW) section at the top of the list
      When using Service Composer to create a security group policy, the section created in the DFW table cannot be added to the top of the list. There is no way to move DFW section up or down. This has been fixed in NSX 6.2.0.

    • Fixed issue 1501451: Security policy configured as a port range causes firewall to go out of sync
      Configuring security policies as a port range (for example, "5900-5964") will cause the firewall to go out of sync with a NumberFormatException error. This has been fixed in NSX 6.2.0.

    Monitoring Services Resolved Issues in 6.2.2 and earlier

    • Fixed issue 1545888: When reporting flow statistics, index 0 (bytes-in) and index 1 (bytes out) counts are sometimes reversed.
      Index 0 holds the counts for traffic for the origination direction and, and index 1 holds the counts for traffic in the reverse direction. This has been fixed in NSX 6.2.1.

    • Fixed issue 1460085: The #show interface command does not display the bandwidth/speed of vNic_0 interface
      After running the "#show interface" command, a full duplex, "0 M/s" speed is displayed but not the bandwidth/speed of NSX Edge vNic_0 interface. This has been fixed in NSX 6.2.0.

    • Fixed issue 1288395: When IPFIX configuration is enabled for Distributed Firewall, firewall ports in the ESXi management interface for NetFlow for vDS or SNMP may be removed
      When a collector IP and port is defined for IPFIX, the firewall for ESXi management interface is opened up in the outbound direction for the specified UDP collector ports. This operation may remove the dynamic ruleset configuration on ESXi management interface firewall for the following services if they were previously configured on the ESXi host:
      • Netflow collector port configuration on vDS
      • SNMP target port configuration

      This has been fixed in NSX 6.2.0.
    • Fixed issue 1354728: Unable to process Denied/Block events through IPFIX protocol
      Typically, vsfwd user process handles the collection of flows, including dropped/denied ones and processes them for IPFIX. This happens when the IPFIX Collector fails to see the Denied/Block events because the vSIP drop packet queue is either too narrow or is wrapped around by inactive flow events. In this release, the ability to send Denied/Block events using the IPFIX protocol is implemented. This has been fixed in NSX 6.2.0.

    Solution Interoperability Resolved Issues in 6.2.2 and earlier

    • Fixed issue 1453802: Copy of VM via vCloud Connector fails when route traverses NSX Load Balancer. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1462006: In VIO Deployment, some newly deployed VMs appear to have valid port and IPs assigned but do not have access to the network. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1482665: Slow login to NSX tab of vSphere web client with AD-backed SSO
      In NSX for vSphere installations that use SSO for AD authentication, the user's initial login to the NSX Networking and Security section of the vSphere Web Client takes a long time. This has been fixed in NSX 6.1.5 and NSX 6.2.1.

    • Fixed issue 1326669: Unable to set up organizational network
      When attempting to set up an organization-wide network, vCloud Director fails with an error message. This has been fixed in NSX 6.2.0.

    • Fixed issue 1497044: Unable to launch multiple VMs using VIO setup
      Users using VMware Integrated OpenStack were unable to launch large numbers of VMs or publish large numbers of firewall rules in a short period of time. This resulted in Error publishing ip for vnic messages in the log. This has been fixed in NSX 6.2.0.

    Document Revision History

    20 August 2015: First edition for NSX 6.2.0.
    4 September 2015: Second edition for NSX 6.2.0. Removed unneeded upgrade warning.
    17 December 2015: First edition for NSX 6.2.1.
    1 March 2016: Second edition for NSX 6.2.1. Clarified NSX-Log Insight compatibility.
    4 March 2016: First edition for NSX 6.2.2. Security patch to address glibc vulnerability.
    14 March 2016: Second edition for NSX 6.2.2. Clarified components to be upgraded to 6.2.2. Added Log Insight download URL. Added issue numbers.
    31 March 2016: Third edition for NSX 6.2.2. Noted new support for single-hop upgrades from vCNS.
    18 May 2016: Fourth edition for NSX 6.2.2. Noted 6.1.6 upgrade limitations.
    9 June 2016: First edition for NSX 6.2.3.
    17 June 2016: Second edition for NSX 6.2.3. Added upgrade advisories.
    30 June 2016: Third edition for NSX 6.2.3. Added LB enhancements, security patch update. Noted few fixed and known issues.
    7 July 2016: Fourth edition for NSX 6.2.3. Added Resource Reservation REST API.
    21 July 2016: Fifth edition for NSX 6.2.3. Added install/upgrade caution and known issue, downgrade not supported, autodraft API. Moved resolved issue to correct section.
    12 August 2016: Sixth edition for NSX 6.2.3. State that this release is no longer available, other edits.
    22 August 2016: Seventh edition for NSX 6.2.3. Added known DLR HA issues 1703913 and 1703247.