You must follow multiple best practices at all times when you operate your NSX-T Data Center environment.

Table 1. NSX-T Data Center

Best Practice and Configuration ID


Harden your VMware vSphere environment.


NSX-T Data Center relies on a secure VMware vSphere environment. VMware vSphere environment that is not hardened appropriately can jeopardize the working of NSX-T Data Center. Assess the VMware vSphere environment and ensure that the an appropriate level of VMware vSphere hardening guide is enforced and maintained.

Install Security Patches and Updates for NSX-T Data Center.


You install all security patches and updates for NSX-T Data Center as soon as the update bundles are available in SDDC Manager.

Do not apply patches to NSX-T Data Center manually in a VMware Cloud Foundation environment unless directed to do-so by support. If you patch the environment without using SDDC Manager you can cause problems with automated upgrades or actions in the future.

Use roles and privileges in NSX-T Manager to limit user privileges.


You integrate NSX-T Manager with your corporate identity source such as Active Directory over LDAP or OpenLDAP. Evaluate the needs for role separation in your business and implement mapping from individual user accounts to Active Directory groups and roles in NSX-T Data Center. Users and Service accounts must only be assigned required privileges.

To create a new role with specific permissions, associate the newly created role to an Active Directory group, and associate that group to an NSX-T Data Center role.

Navigate to System > Users and Roles > Users > ADD > Role Assignment for LDAP Search from the Domain text box and select the correct domain. Enter name of user or group in Search User/User Group, select a correct role to assign and click Save.

Integrate VMware Identity Manager / VMware Workspace ONE Access with NSX-T Data Center.


You integrate NSX-T Data Center with VMware Workspace ONE Access to enforce two-factor authentication and other identity management services. The integration ensures the individuals can be held accountable for the configuration changes they implement (non-repudiation).

Configure NSX-T Manager to use an authentication server for authenticating users prior to granting administrative access.


Centralized management of authentication settings increases the security of remote and non-local access methods. This control is particularly important protection against the insider threat. With centralized management, audit records for administrator account access to the organization's network, devices can be analyzed for trends and anomalies. The alternative method of defining administrator accounts on each device exposes the device configuration to remote access authentication attacks and system administrators with multiple authenticators for each network device.

NSX-T Manager must be configured to use Active Directory over LDAP or Workspace ONE Access for authentication. Workspace ONE Access must be joined to Active Directory.

The BGP NSX-T Tier-0 gateway must be configured to use a unique key for each autonomous system (AS) that it peers with.


If the same keys are used between eBGP neighbors, risks of a hacker compromising any of the BGP sessions increases. It is possible that a malicious user exists in one autonomous system who would know the key used for the eBGP session. This user would then be able to hijack BGP sessions with other trusted neighbors.

For every NSX-T Tier-0 gateway, view timers and password for every external BGP (eBGP) neighbor and configure password with a unique key.

Validate the integrity of the installation media or patch or upgrade in NSX-T Manager.


Verify the authenticity of the software prior to installation to validate the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and has been provided by a trusted vendor.

Always download VMware software from VMware Secure website using a secure connection. Verify the MD5/SHA1 hash output of the downloaded media with the value posted on the VMware secure website. MD5/SHA1 hash must match.

Ensure that NSX-T Data Center sends logs to an internal syslog server.


Use a security information and event management solution or a syslog server solution such as VMware Log Insight and configure it to collect the NSX-T Data Center logs securely.

Configure NTP servers for the NSX-T Manager nodes


Configure the NSX-T Manager nodes to synchronize internal information system clocks using redundant authoritative time sources.

Either use a valid TLS certificate or create a way to specify a self-signed certificate that is used for certificate pinning.


NSX-T Data Center admin implicitly receives Workspace ONE Access admin token due to the fact that the stored client credentials are not scoped to just RO on Workspace ONE Access. This is the risk until modify Workspace ONE Access to offer finer grains access controls.

Do not install or use software not supported by VMware on your NSX-T Data Center appliances.


Do not install or use any software not supported by VMware to minimize the threat to infrastructure. Do not add other software components to the NSX-T Data Center appliances as it is an untested configuration and could potentially interfere with the operation of the security functions they provide.

Configure the BGP NSX-T Tier-0 gateway to reject inbound route advertisements for any Bogon prefixes.


Accepting route advertisements for Bogon prefixes can result in the local autonomous system (AS) becoming a transit for malicious traffic as it in turn advertises these prefixes to neighbor autonomous systems. For every NSX-T Tier-0 gateway, view Route Filter for every BGP neighbor and ensure that the In Filter is configured with a prefix list that rejects Bogon prefixes.

Configure the BGP NSX-T Tier-0 gateway to reject outbound route advertisements for any prefixes belonging to the IP core.


Outbound route advertisements belonging to the core can result in traffic either looping or being black-holed, or at a minimum, using a non-optimized path.

For every NSX-T Tier-0 gateway, view Route Filter for every external BGP (eBGP) neighbor and make sure that the Out Filter is configured with a prefix list that rejects prefixes belonging to the IP core.

Configure BGP NSX-T Tier-0 gateway to reject inbound route advertisements for any prefixes belonging to the local autonomous system (AS).


Accepting route advertisements belonging to the local AS can result in traffic looping or being black-holed, or at a minimum using a non-optimized path. For every NSX-T Tier-0 gateway, view Route Filter for external BGP (eBGP) neighbor and ensure that the In Filter is configured with a prefix list that rejects prefixes belonging to the local AS.

Configure BGP NSX-T Tier-0 gateway to reject inbound route advertisements from a customer edge (CE) NSX-T Tier-0 gateway for prefixes that are not allocated to that customer.


As a best practice, a service provider should only accept customer prefixes that have been assigned to that customer and any peering autonomous systems. For every NSX-T Tier-0 gateway, view Route Filter for every eBGP neighbor and ensure that the In Filter is configured to reject prefixes from the CE Router with prefixes not allocated to that customer.

Configure BGP NSX-T Tier-0 Gateway to reject outbound route advertisements for any prefixes that do not belong to any customers or the local autonomous system (AS).


For every NSX-T Tier-0 gateway, view Route Filter for every eBGP neighbor and configure the Out Filter to reject prefixes that are not allocated to or belong to any customer or the local AS.

The BGP NSX-T Tier-0 Gateway must be configured to use its loopback address as the source address for iBGP peering sessions


When the loopback address is used as the source for eBGP peering, the BGP session is harder to hijack as the source address to be used is not known globally—making it more difficult for a hacker to spoof an eBGP neighbor. By using traceroute, a hacker can easily determine the addresses for an eBGP speaker when the IP address of an external interface is used as the source address. The routers within the iBGP domain must also use loopback addresses as the source address when establishing BGP sessions.

For every NSX-T Tier-0 gateway, view Souce Address for every internal BGP (iBGP) neighbor and configure it with an NSX-T Tier-0 gateway loopback address.

The Provider Edge NSX-T Tier 0 Gateway must be configured to have each Virtual Routing and Forwarding (VRF) instance with the appropriate Route Target (RT)


The primary security model for an MPLS L3 VPN as well as a VRF-lite infrastructure is traffic separation. Each interface can only be associated to one VRF, which is the fundamental framework for traffic separation. Forwarding decisions are made based on the routing table belonging to the VRF. Control of what routes are imported into or exported from a VRF is based on the RT. It is critical that traffic does not leak from one Community Of Interest tenant or L3 VPN to another; hence, it is imperative that the correct RT is configured for each VRF.

The Provider Edge NSX-T Tier-0 gateway must be configured to have each VRF with the appropriate Route Distinguisher (RD).


An RD provides uniqueness to the customer address spaces within the MPLS L3 VPN infrastructure. The concept of the VPN-IPv4 and VPN-IPv6 address families consists of the RD prepended before the IP address. Hence, if the same IP prefix is used in several different L3VPNs, it is possible for BGP to carry several completely different routes for that prefix, one for each VPN.

Since VPN-IPv4 addresses and IPv4 addresses are different address families, BGP never treats them as comparable addresses. The purpose of the RD is to create distinct routes for common IPv4 address prefixes. On any given PE router, a single RD can define a VRF in which the entire address space may be used independently, regardless of the makeup of other VPN address spaces. Hence, it is imperative that a unique RD is assigned to each L3VPN and that the proper RD is configured for each VRF.

The BGP NSX-T Tier-0 gateway must be configured to limit the prefix size on any inbound route advertisement to /24 or the least significant prefixes issued to the customer.


The effects of prefix de-aggregation can degrade router performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured router, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements.

Disable Protocol Independent Multicast (PIM).


The multicast NSX-T Tier-0 gateway must be configured to disable PIM on all interfaces that are not required to support multicast routing. If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel. Limiting where, within the network, a given multicast group data is permitted to flow is an important first step in improving multicast security.

Disable inactive interfaces on an NSX-T Tier-0 gateway.


An NSX-T Tier-0 gateway must be configured to have all inactive interfaces disabled. An inactive interface is rarely monitored or controlled and might expose a network to an undetected attack on that interface. If an interface is no longer used, the configuration must be deleted and the interface disabled. For sub-interfaces, delete sub-interfaces that are on inactive interfaces and delete sub-interfaces that are inactive.

Enforce a Quality-of-Service (QoS) policy.


The NSX-T Tier-0 and Tier-1 gateways must be configured to enforce a Quality-of-Service policy to limit the effects of packet flooding denial-of-service attacks. Ensure that mechanisms for traffic prioritization and bandwidth reservation exists.

Implement measures to protect against Denial-of-Service attacks.


As Bidirectional Forwarding Detection (BFD) might be tied into the stability of the network infrastructure (such as routing protocols), the effects of an attack on a BFD session might be serious. Alink might be falsely declared to be down, or falsely declared to be up. In either case, the effect is denial of service. Implementing appropriate measures against DoS attack is critical. Edge checks for max-allowed-hops or TTL check for ingress BFD packets to mitigate spoofing attacks.

Disable inactive linked segments for NSX-T Tier-1 gateways.


For each segment attached to an NSX-T Tier-1 gateway that is not in use, edit the segment and set the Connectivity to None.

The out-of-band management (OOBM) gateway must be configured to transport management traffic to the Network Operations Center (NOC) through dedicated circuit, MPLS/VPN service, or IPsec tunnel.


Using dedicated paths, the OOBM backbone connects the OOBM gateway routers located at the edge of the managed network and at the NOC. Dedicated links can be deployed using provisioned circuits or MPLS Layer 2 and Layer 3 VPN services or implementing a secured path with gateway-to-gateway IPsec tunnels. The tunnel mode ensures that the management traffic is logically separated from any other traffic traversing the same path.

Use an SFTP Server configuration for backup and restore.


Use an SFTP server for backup and restore and also ensure that the SFTP server is hardened with general best practices and guidelines for FTP hardening.

Dedicate a user for the backups directory on your SFTP Server and restrict the access of all other users to that directory. Configure a single user with read and write permissions for the directory that stores backups on your SFTP server. Configure a strong password for the backup user.

Ensure that IPv4 DNS is authorized and secure


By ensuring that the IPv4 DNS servers are authorized and secure would mitigate the risks against DNS based vulnerabilities. Also, ensure that the DNS server is hardened based on the best practice guidelines.

Ensure that the NSX-T Manager certificate is valid and legitimate.


As a best practice, replace self-signed certificates with certificates that are signed by a third-party or enterprise Certificate Authority (CA). This ensures that the communication between NSX-T Data Center components is encrypted by using a trusted certificate.

When generating a Certificate Signing Request (CSR), select RSA or EC as algorithm. RSA key sizes can be 2048, 3072, or 4096 and EC key size can be 256, 384, or 521.

Access to all NSX-T Manager interfaces must use an Secure Sockets Layer (SSL) connection. By default, NSX-T Manager uses a self-signed SSL certificate. This certificate is not trusted by end-user devices or Web browsers.

Isolate Virtual network tunnel traffic.


Virtual network tunnel traffic (Geneve) must be separated from other traffic to avoid tampering with the tunnel. The Physical NIC for the virtual tunneling end point (TEP) must be on an isolated network with the other TEPs in your data center on trusted ESXi hosts. You can isolate this to a VLAN segment, but for extra safety use physical isolation. Thoroughly review the deployment and ensure that the virtual network is isolated.

Restrict access to the NSX-T Manager nodes and NSX-T Edge nodes in your vSphere environment.


Users that have access to the NSX-T Manager nodes and NSX-T Edge nodes in your vSphere environment could potentially cause harm by intentionally or unintentionally performing power off, suspend, migrate, or other administrative functions. It is important that the access is protected using user access controls or separating and isolating the environment.

Log in to the vSphere Client and inspect users that have access permissions to the NSX-T Manager nodes and NSX-T Edge nodes. No user other than the intended administrator should have access to the nodes or be able to perform any administrative actions on these nodes.