NSX 64 Admin
NSX 64 Admin
NSX 64 Admin
Guide
Update 1
Modified on 25 JAN 2018
VMware NSX for vSphere 6.4
NSX Administration Guide
You can find the most up-to-date technical documentation on the VMware website at:
https://docs.vmware.com/
If you have comments about this documentation, submit your feedback to
docfeedback@vmware.com
VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com
Copyright © 2010 – 2018 VMware, Inc. All rights reserved. Copyright and trademark information.
VMware, Inc. 2
Contents
3 Overview of NSX 15
NSX Components 16
NSX Edge 19
NSX Services 22
5 Transport Zones 35
Add a Transport Zone 37
View and Edit a Transport Zone 39
Expand a Transport Zone 39
Contract a Transport Zone 40
Controller Disconnected Operation (CDO) Mode 40
6 Logical Switches 41
Add a Logical Switch 43
Connect Virtual Machines to a Logical Switch 46
Test Logical Switch Connectivity 47
Prevent Spoofing on a Logical Switch 47
Edit a Logical Switch 47
Logical Switch Scenario 48
VMware, Inc. 3
NSX Administration Guide
8 L2 Bridges 61
Add L2 Bridge 62
Add L2 Bridge to a Logically Routed Environment 63
9 Routing 65
Add a Logical (Distributed) Router 65
Add an Edge Services Gateway 78
Specify Global Configuration 89
NSX Edge Configuration 91
Add a Static Route 111
Configure OSPF on a Logical (Distributed) Router 112
Configure OSPF on an Edge Services Gateway 119
Configure BGP 125
Configure Route Redistribution 129
View the NSX Manager Locale ID 131
Configure Locale ID on a Universal Logical (Distributed) Router 131
Configure Locale ID on a Host or Cluster 131
VMware, Inc. 4
NSX Administration Guide
VMware, Inc. 5
NSX Administration Guide
VMware, Inc. 6
NSX Administration Guide
VMware, Inc. 7
NSX Administration Guide
®
The NSX Administration Guide describes how to configure, monitor, and maintain the VMware NSX for
®
vSphere system by using the NSX Manager user interface and the vSphere Web Client. The information
includes step-by-step configuration instructions, and suggested best practices.
Intended Audience
This manual is intended for anyone who wants to install or use NSX in a VMware vCenter environment.
The information in this manual is written for experienced system administrators who are familiar with
virtual machine technology and virtual datacenter operations. This manual assumes familiarity with
VMware vSphere, including VMware ESXi, vCenter Server, and the vSphere Web Client.
VMware, Inc. 8
System Requirements for NSX 1
Before you install or upgrade NSX, consider your network configuration and resources. You can install
one NSX Manager per vCenter Server, one instance of Guest Introspection per ESXi™ host, and multiple
NSX Edge instances per datacenter.
Hardware
This table lists the hardware requirements for NSX appliances.
NSX Controller 4 GB 4 28 GB
As a general guideline, increase NSX Manager resources to 8 vCPU and 24 GB of RAM if your NSX-
managed environment contains more than 256 hypervisors or more than 2000 VMs.
For information about increasing the memory and vCPU allocation for your virtual appliances, see
Allocate Memory Resources, and Change the Number of Virtual CPUs in vSphere Virtual Machine
Administration.
The provisioned space for a Guest Introspection appliance shows as 6.26 GB for Guest Introspection.
This is because vSphere ESX Agent Manager creates a snapshot of the service VM to create fast clones,
when multiple hosts in a cluster shares a storage. For more information on how to disable this option via
ESX Agent Manager, refer to ESX Agent Manager documentation.
VMware, Inc. 9
NSX Administration Guide
Network Latency
You should ensure that the network latency between components is at or below the maximum latency
described.
Software
For the latest interoperability information, see the Product Interoperability Matrixes at
http://partnerweb.vmware.com/comp_guide/sim/interop_matrix.php.
For recommended versions of NSX, vCenter Server, and ESXi, see the release notes at
https://docs.vmware.com/en/VMware-NSX-for-vSphere/index.html.
For an NSX Manager to participate in a cross-vCenter NSX deployment the following conditions are
required:
Component Version
To manage all NSX Managers in a cross-vCenter NSX deployment from a single vSphere Web Client, you
must connect your vCenter Servers in Enhanced Linked Mode. See Using Enhanced Linked Mode in
vCenter Server and Host Management.
To verify the compatibility of partner solutions with NSX, see the VMware Compatibility Guide for
Networking and Security at
http://www.vmware.com/resources/compatibility/search.php?deviceCategory=security.
VMware, Inc. 10
NSX Administration Guide
n Access to the datastore where you store virtual machine files, and the account permissions to copy
files to that datastore
n Cookies must be enabled on your Web browser to access the NSX Manager user interface.
n Port 443 must be open between the NSX Manager and the ESXi host, the vCenter Server, and the
NSX appliances to be deployed. This port is required to download the OVF file on the ESXi host for
deployment.
n A Web browser that is supported for the version of vSphere Web Client you are using. See Using the
vSphere Web Client in the vCenter Server and Host Management documentation for details.
n For information about using the vSphere Client (HTML5) on vSphere 6.5 with NSX 6.4, see
https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.4/rn/nsx-vsphere-client-65-functionality-
support.html.
VMware, Inc. 11
Ports and Protocols Required by
NSX 2
The following ports must be open for NSX to operate properly.
Client PC NSX Manager 443 TCP NSX Manager No Yes PAM Authentication
Administrative
Interface
ESXi Host NSX Controller 1234 TCP User World Agent No Yes
Connection
NSX Controller NSX Controller 2878, TCP Controller Cluster - No Yes IPsec
2888, State Sync
3888
NSX Controller NSX Controller 30865 TCP Controller Cluster - No Yes IPsec
State Sync
VMware, Inc. 12
NSX Administration Guide
REST Client NSX Manager 443 TCP NSX Manager No Yes User/Password
REST API
ESXi Host ESXi Host 6999 UDP ARP on VLAN LIFs No Yes
VMware, Inc. 13
NSX Administration Guide
Primary NSX NSX Universal 443 TCP NSX Controller No Yes User/Password
Manager Controller REST API
Cluster
Secondary NSX NSX Universal 443 TCP NSX Controller No Yes User/Password
Manager Controller REST API
Cluster
ESXi Host NSX Universal 1234 TCP NSX Control Plane No Yes
Controller Protocol
Cluster
VMware, Inc. 14
Overview of NSX 3
IT organizations have gained significant benefits as a direct result of server virtualization. Server
consolidation reduced physical complexity, increased operational efficiency and the ability to dynamically
re-purpose underlying resources to quickly and optimally meet the needs of increasingly dynamic
business applications.
VMware’s Software Defined Data Center (SDDC) architecture is now extending virtualization technologies
®
across the entire physical data center infrastructure. VMware NSX , the network virtualization platform, is
a key product in the SDDC architecture. With NSX, virtualization delivers for networking what it has
already delivered for compute and storage. In much the same way that server virtualization
programmatically creates, snapshots, deletes and restores software-based virtual machines (VMs), NSX
network virtualization programmatically creates, snapshots, deletes, and restores software-based virtual
networks. The result is a completely transformative approach to networking that not only enables data
center managers to achieve orders of magnitude better agility and economics, but also allows for a vastly
simplified operational model for the underlying physical network. With the ability to be deployed on any IP
network, including both existing traditional networking models and next-generation fabric architectures
from any vendor, NSX is a completely non-disruptive solution. In fact, with NSX, the physical network
infrastructure you already have is all you need to deploy a software-defined data center.
VMware, Inc. 15
NSX Administration Guide
The figure above draws an analogy between compute and network virtualization. With server
virtualization, a software abstraction layer (server hypervisor) reproduces the familiar attributes of an x86
physical server (for example, CPU, RAM, Disk, NIC) in software, allowing them to be programmatically
assembled in any arbitrary combination to produce a unique VM in a matter of seconds.
With network virtualization, the functional equivalent of a network hypervisor reproduces the complete set
of Layer 2 through Layer 7 networking services (for example, switching, routing, access control,
firewalling, QoS, and load balancing) in software. As a result, these services can be programmatically
assembled in any arbitrary combination, to produce unique, isolated virtual networks in a matter of
seconds.
With network virtualization, benefits similar to server virtualization are derived. For example, just as VMs
are independent of the underlying x86 platform and allow IT to treat physical hosts as a pool of compute
capacity, virtual networks are independent of the underlying IP network hardware and allow IT to treat the
physical network as a pool of transport capacity that can be consumed and repurposed on demand.
Unlike legacy architectures, virtual networks can be provisioned, changed, stored, deleted, and restored
programmatically without reconfiguring the underlying physical hardware or topology. By matching the
capabilities and benefits derived from familiar server and storage virtualization solutions, this
transformative approach to networking unleashes the full potential of the software-defined data center.
NSX can be configured through the vSphere Web Client, a command-line interface (CLI), and a REST
API.
n NSX Components
n NSX Edge
n NSX Services
NSX Components
This section describes the components of the NSX solution.
VMware, Inc. 16
NSX Administration Guide
NSX
Manager
Management Plane
NSX
Controller
Control Plane
Run-time state
NSX
Edge
Data Plane
Note that a cloud management platform (CMP) is not a component of NSX, but NSX provides integration
into virtually any CMP via the REST API and out-of-the-box integration with VMware CMPs.
Data Plane
The NSX data plane consists of the NSX vSwitch, which is based on the vSphere Distributed Switch
(VDS) with additional components to enable services. NSX kernel modules, userspace agents,
configuration files, and install scripts are packaged in VIBs and run within the hypervisor kernel to provide
services such as distributed routing and logical firewall and to enable VXLAN bridging capabilities.
The NSX vSwitch (vDS-based) abstracts the physical network and provides access-level switching in the
hypervisor. It is central to network virtualization because it enables logical networks that are independent
of physical constructs, such as VLANs. Some of the benefits of the vSwitch are:
n Support for overlay networking with protocols (such as VXLAN) and centralized network
configuration. Overlay networking enables the following capabilities:
n Creation of a flexible logical Layer 2 (L2) overlay over existing IP networks on existing physical
infrastructure without the need to re-architect any of the data center networks
n Application workloads and virtual machines that are agnostic of the overlay network and operate
as if they were connected to a physical L2 network
VMware, Inc. 17
NSX Administration Guide
The logical routers can provide L2 bridging from the logical networking space (VXLAN) to the physical
network (VLAN).
The gateway device is typically an NSX Edge virtual appliance. NSX Edge offers L2, L3, perimeter
firewall, load balancing, and other services such as SSL VPN and DHCP.
Control Plane
The NSX control plane runs in the NSX Controller cluster. NSX Controller is an advanced distributed state
management system that provides control plane functions for NSX logical switching and routing functions.
It is the central control point for all logical switches within a network and maintains information about all
hosts, logical switches (VXLANs), and distributed logical routers.
The controller cluster is responsible for managing the distributed switching and routing modules in the
hypervisors. The controller does not have any dataplane traffic passing through it. Controller nodes are
deployed in a cluster of three members to enable high-availability and scale. Any failure of the controller
nodes does not impact any data-plane traffic.
NSX Controllers work by distributing network information to hosts. To achieve a high level of resiliency the
NSX Controller is clustered for scale out and HA. NSX Controllers must be deployed in a three-node
cluster. The three virtual appliances provide, maintain, and update the state of all network functioning
within the NSX domain. NSX Manager is used to deploy NSX Controller nodes.
The three NSX Controller nodes form a control cluster. The controller cluster requires a quorum (also
called a majority) in order to avoid a "split-brain scenario." In a split-brain scenario, data inconsistencies
originate from the maintenance of two separate data sets that overlap. The inconsistencies can be
caused by failure conditions and data synchronization issues. Having three controller nodes ensures data
redundancy in case of failure of one NSX Controller node.
n API provider
n Persistence server
n Switch manager
n Logical manager
n Directory server
Each role has a master controller node. If a master controller node for a role fails, the cluster elects a new
master for that role from the available NSX Controller nodes. The new master NSX Controller node for
that role reallocates the lost portions of work among the remaining NSX Controller nodes.
VMware, Inc. 18
NSX Administration Guide
NSX supports three logical switch control plane modes: multicast, unicast and hybrid. Using a controller
cluster to manage VXLAN-based logical switches eliminates the need for multicast support from the
physical network infrastructure. You don’t have to provision multicast group IP addresses, and you also
don’t need to enable PIM routing or IGMP snooping features on physical switches or routers. Thus, the
unicast and hybrid modes decouple NSX from the physical network. VXLANs in unicast control-plane
mode do not require the physical network to support multicast in order to handle the broadcast, unknown
unicast, and multicast (BUM) traffic within a logical switch. The unicast mode replicates all the BUM traffic
locally on the host and requires no physical network configuration. In the hybrid mode, some of the BUM
traffic replication is offloaded to the first hop physical switch to achieve better performance. Hybrid mode
requires IGMP snooping on the first-hop switch and access to an IGMP querier in each VTEP subnet.
Management Plane
The NSX management plane is built by the NSX Manager, the centralized network management
component of NSX. It provides the single point of configuration and REST API entry-points.
The NSX Manager is installed as a virtual appliance on any ESX™ host in your vCenter Server
environment. NSX Manager and vCenter have a one-to-one relationship. For every instance of NSX
Manager, there is one vCenter Server. This is true even in a cross-vCenter NSX environment.
In a cross-vCenter NSX environment, there is both a primary NSX Manager and one or more secondary
NSX Managers. The primary NSX Manager allows you to create and manage universal logical switches,
universal logical (distributed) routers and universal firewall rules. Secondary NSX Managers are used to
manage networking services that are local to that specific NSX Manager. There can be up to seven
secondary NSX Managers associated with the primary NSX Manager in a cross-vCenter NSX
environment.
Consumption Platform
The consumption of NSX can be driven directly through the NSX Manager user interface, which is
available in the vSphere Web Client. Typically end users tie network virtualization to their cloud
management platform for deploying applications. NSX provides rich integration into virtually any CMP
through REST APIs. Out-of-the-box integration is also available through VMware vCloud Automation
Center, vCloud Director, and OpenStack with the Neutron plug-in for NSX.
NSX Edge
You can install NSX Edge as an edge services gateway (ESG) or as a distributed logical router (DLR).
The number of edge appliances including ESGs and DLRs is limited to 250 on a host.
VMware, Inc. 19
NSX Administration Guide
Uplink interfaces of ESGs connect to uplink port groups that have access to a shared corporate network
or a service that provides access layer networking. Multiple external IP addresses can be configured for
load balancer, site-to-site VPN, and NAT services.
A logical router can have eight uplink interfaces and up to a thousand internal interfaces. An uplink
interface on a DLR generally peers with an ESG, with an intervening Layer 2 logical transit switch
between the DLR and the ESG. An internal interface on a DLR peers with a virtual machine hosted on an
ESX hypervisor with an intervening logical switch between the virtual machine and the DLR.
n The DLR control plane is provided by the DLR virtual appliance (also called a control VM). This VM
supports dynamic routing protocols (BGP and OSPF), exchanges routing updates with the next Layer
3 hop device (usually the edge services gateway) and communicates with the NSX Manager and the
NSX Controller cluster. High-availability for the DLR virtual appliance is supported through active-
standby configuration: a pair of virtual machines functioning in active/standby modes are provided
when you create the DLR with HA enabled.
n At the data-plane level, there are DLR kernel modules (VIBs) that are installed on the ESXi hosts that
are part of the NSX domain. The kernel modules are similar to the line cards in a modular chassis
supporting Layer 3 routing. The kernel modules have a routing information base (RIB) (also known as
a routing table) that is pushed from the controller cluster. The data plane functions of route lookup
and ARP entry lookup are performed by the kernel modules. The kernel modules are equipped with
logical interfaces (called LIFs) connecting to the different logical switches and to any VLAN-backed
port-groups. Each LIF has assigned an IP address representing the default IP gateway for the logical
L2 segment it connects to and a vMAC address. The IP address is unique for each LIF, whereas the
same vMAC is assigned to all the defined LIFs.
VMware, Inc. 20
NSX Administration Guide
External
Network
192.168.100.0/24
NSX Edge
(Acting as next
hop router)
P
VPN V
OSPF, BGP
Peering
192.168.10.1
Control
Logical NSX
router 1 Manager
3 appliance
Data Path
6 192.168.10.3
192.168.10.2
4
vSphere Distributed Switch
Control
Controller
Cluster
5 2
Logical
Router
172.16.10.1 172.16.20.1
Web VM App VM
172.16.10.11 172.16.20.11
1 A DLR instance is created from the NSX Manager UI (or with API calls), and routing is enabled,
leveraging either OSPF or BGP.
2 The NSX Controller leverages the control plane with the ESXi hosts to push the new DLR
configuration including LIFs and their associated IP and vMAC addresses.
3 Assuming a routing protocol is also enabled on the next-hop device (an NSX Edge [ESG] in this
example), OSPF or BGP peering is established between the ESG and the DLR control VM. The ESG
and the DLR can then exchange routing information:
n The DLR control VM can be configured to redistribute into OSPF the IP prefixes for all the
connected logical networks (172.16.10.0/24 and 172.16.20.0/24 in this example). As a
consequence, it then pushes those route advertisements to the NSX Edge. Notice that the next
hop for those prefixes is not the IP address assigned to the control VM (192.168.10.3) but the IP
address identifying the data-plane component of the DLR (192.168.10.2). The former is called the
DLR "protocol address," whereas the latter is the "forwarding address."
n The NSX Edge pushes to the control VM the prefixes to reach IP networks in the external
network. In most scenarios, a single default route is likely to be sent by the NSX Edge, because it
represents the single point of exit toward the physical network infrastructure.
VMware, Inc. 21
NSX Administration Guide
4 The DLR control VM pushes the IP routes learned from the NSX Edge to the controller cluster.
5 The controller cluster is responsible for distributing routes learned from the DLR control VM to the
hypervisors. Each controller node in the cluster takes responsibility of distributing the information for a
particular logical router instance. In a deployment where there are multiple logical router instances
deployed, the load is distributed across the controller nodes. A separate logical router instance is
usually associated with each deployed tenant.
6 The DLR routing kernel modules on the hosts handle the data-path traffic for communication to the
external network by way of the NSX Edge.
NSX Services
The NSX components work together to provide the following functional services.
Logical Switches
A cloud deployment or a virtual data center has a variety of applications across multiple tenants. These
applications and tenants require isolation from each other for security, fault isolation, and non-overlapping
IP addresses. NSX allows the creation of multiple logical switches, each of which is a single logical
broadcast domain. An application or tenant virtual machine can be logically wired to a logical switch. This
allows for flexibility and speed of deployment while still providing all the characteristics of a physical
network's broadcast domains (VLANs) without physical Layer 2 sprawl or spanning tree issues.
A logical switch is distributed and can span across all hosts in vCenter (or across all hosts in a cross-
vCenter NSX environment). This allows for virtual machine mobility (vMotion) within the data center
without limitations of the physical Layer 2 (VLAN) boundary. The physical infrastructure is not constrained
by MAC/FIB table limits, because the logical switch contains the broadcast domain in software.
Logical Routers
Routing provides the necessary forwarding information between Layer 2 broadcast domains, thereby
allowing you to decrease the size of Layer 2 broadcast domains and improve network efficiency and
scale. NSX extends this intelligence to where the workloads reside for East-West routing. This allows
more direct VM-to-VM communication without the costly or timely need to extend hops. At the same time,
NSX logical routers provide North-South connectivity, thereby enabling tenants to access public networks.
Logical Firewall
Logical Firewall provides security mechanisms for dynamic virtual data centers. The Distributed Firewall
component of Logical Firewall allows you to segment virtual datacenter entities like virtual machines
based on VM names and attributes, user identity, vCenter objects like datacenters, and hosts, as well as
traditional networking attributes like IP addresses, VLANs, and so on. The Edge Firewall component
helps you meet key perimeter security requirements, such as building DMZs based on IP/VLAN
constructs, and tenant-to-tenant isolation in multi-tenant virtual data centers.
VMware, Inc. 22
NSX Administration Guide
The Flow Monitoring feature displays network activity between virtual machines at the application protocol
level. You can use this information to audit network traffic, define and refine firewall policies, and identify
threats to your network.
Service Composer
Service Composer helps you provision and assign network and security services to applications in a
virtual infrastructure. You map these services to a security group, and the services are applied to the
virtual machines in the security group using a Security Policy.
NSX Extensibility
3rd-party solution providers can integrate their solutions with the NSX platform, thus enabling customers
to have an integrated experience across VMware products and partner solutions. Data center operators
can provision complex, multi-tier virtual networks in seconds, independent of the underlying network
topology or components.
VMware, Inc. 23
Overview of Cross-vCenter
Networking and Security 4
NSX 6.2 and later allows you to manage multiple vCenter NSX environments from a single primary NSX
Manager.
There are many reasons multiple vCenter Server systems may be required, for example:
n To overcome scale limits of vCenter Server
n To accommodate products that require dedicated or multiple vCenter Server systems, such as
Horizon View or Site Recovery Manager
n To separate environments, for example by business unit, tenant, organization, or environment type
In NSX 6.1 and earlier, if multiple vCenter NSX environments are deployed, they must be managed
separately. In NSX 6.2 and later you can create universal objects on the primary NSX Manager, which are
synchronized across all vCenter Servers systems in the environment.
VMware, Inc. 24
NSX Administration Guide
n Increased span of NSX logical networks. The same logical networks are available across the vCenter
NSX environment, so it's possible for VMs on any cluster on any vCenter Server system to be
connected to the same logical network.
n Centralized security policy management. Firewall rules are managed from one centralized location,
and apply to the VM regardless of location or vCenter Server system.
n Support of new mobility boundaries in vSphere 6, including cross vCenter and long distance vMotion
across logical switches.
n Enhanced support for multi-site environments, from metro distance to 150ms RTT. This includes both
active-active and active-passive datacenters.
n Increased mobility of workloads - VMs can be vMotioned across vCenter Servers without having to
reconfigure the VM or change firewall rules.
Note Cross-vCenter NSX functionality is supported with vSphere 6.0 and later.
The primary NSX Manager is used to deploy a universal controller cluster that provides the control plane
for the cross-vCenter NSX environment. The secondary NSX Managers do not have their own controller
clusters.
The primary NSX Manager can create universal objects, such as universal logical switches. These
objects are synchronized to the secondary NSX Managers by the NSX Universal Synchronization
Service. You can view these objects from the secondary NSX Managers, but you cannot edit them there.
You must use the primary NSX Manager to manage universal objects. The primary NSX Manager can be
used to configure any of the secondary NSX Managers in the environment.
On both primary and secondary NSX Managers, you can create objects that are local to that specific
vCenter NSX environment, such as logical switches, and logical (distributed) routers. They will exist only
within the vCenter NSX environment in which they were created. They will not be visible on the other NSX
Managers in the cross-vCenter NSX environment.
VMware, Inc. 25
NSX Administration Guide
NSX Managers can be assigned the standalone role. This is equivalent to pre-NSX 6.2 environments with
a single NSX Manager and single vCenter. A standalone NSX Manager cannot create universal objects.
Note If you change the role of a primary NSX Manager to standalone and any universal objects exist in
the NSX environment, the NSX Manager will be assigned the transit role. The universal objects remain,
but they cannot be changed, and no other universal objects can be created. You can delete universal
objects from the transit role. The transit role should only be used temporarily, for example, when changing
which NSX Manager is the primary.
Universal
Distributed
Firewall
L2 bridges No
VMware, Inc. 26
NSX Administration Guide
Table 4‑1. Support matrix for NSX Services in cross-vCenter NSX (Continued)
Supports cross-vCenter NSX
NSX Service Details synchronization?
Exclude list No
SpoofGuard No
Edge firewall No
VPN No
Service composer No
Network extensibility No
IP pools No
Services Yes
VMware, Inc. 27
NSX Administration Guide
As the universal controller cluster is the only controller cluster for the cross-vCenter NSX environment, it
maintains information about universal logical switches and universal logical routers as well as logical
switches and logical routers that are local to a vCenter NSX pair.
In order to avoid any overlap in object IDs, separate ID pools are maintained for universal objects and
local objects.
The universal transport zone is created on the primary NSX Manager, and is synchronized to the
secondary NSX Managers. Clusters that need to participate in universal logical networks must be added
to the universal transport zone from their NSX Managers.
When you create a logical switch in a universal transport zone, you create a universal logical switch. This
switch is available on all clusters in the universal transport zone. The universal transport zone can include
clusters in any vCenter in the cross-vCenter NSX environment.
The segment ID pool is used to assign VNIs to logical switches, and the universal segment ID pool is
used to assign VNIs to universal logical switches. These pools must not overlap.
You must use a universal logical router to route between universal logical switches. If you need to route
between a universal logical switch and a logical switch, you must use an Edge Services Gateway.
When you create a universal logical router you must choose whether to enable local egress, as this
cannot be changed after creation. Local egress allows you to control what routes are provided to ESXi
hosts based on an identifier, the locale ID.
Each NSX Manager is assigned a locale ID, which is set to the NSX Manager UUID by default. You can
override the locale ID at the following levels:
n Cluster
n ESXi host
VMware, Inc. 28
NSX Administration Guide
If you do not enable local egress the locale ID is ignored and all ESXi hosts connected to the universal
logical router will receive the same routes. Whether or not to enable local egress in a cross-vCenter NSX
environment is a design consideration, but it is not required for all cross-vCenter NSX configurations.
As your datacenter needs scale out, the existing vCenter Server may not scale to the same level. This
may require you to move a set of applications to newer hosts that are managed by a different vCenter
Server. Or you may need to move applications from staging to production in an environment where
staging servers are managed by one vCenter Server and production servers are managed by a different
vCenter Server. Distributed Firewall supports these cross-vCenter vMotion scenarios by replicating
firewall policies that you define for the primary NSX Manager on up to seven secondary NSX Managers.
From the primary NSX Manager you can create distributed firewall rule sections that are marked for
universal synchronization. You can create more than one universal L2 rule section and more than one
universal L3 rule section. Universal sections are always listed at the top of primary and secondary NSX
Managers. These sections and their rules are synchronized to all secondary NSX Managers in your
environment. Rules in other sections remain local to the appropriate NSX Manager.
The following Distributed Firewall features are not supported in a cross-vCenter NSX environment:
n Exclude list
n SpoofGuard
n Edge Firewall
Service Composer does not support universal synchronization, so you cannot use it to create distributed
firewall rules in the universal section.
n Universal IP Sets
VMware, Inc. 29
NSX Administration Guide
n Dynamic criteria
Universal network and security objects are created, deleted, and updated only on the primary NSX
Manager, but are readable on the secondary NSX Manager. Universal Synchronization Service
synchronizes universal objects across vCenters immediately, as well as on demand using force
synchronization.
Universal security groups are used in two types of deployments: multiple live cross-vCenter NSX
environments, and cross-vCenter NSX active standby deployments, where one site is live at a given time
and the rest are on standby. Only active standby deployments can have universal security groups with
dynamic membership based on VM name static membership based on universal security tag. Once a
universal security group is created it cannot be edited to be enabled or disabled for the active standby
scenario functionality. Membership is defined by included objects only, you cannot use excluded objects.
Universal security groups cannot be created from Service Composer. Security groups created from
Service Composer will be local to that NSX Manager.
Whether the cross-vCenter NSX environment is contained within a single site or crosses multiple sites, a
similar configuration can be used. These two example topologies consist of the following:
n A universal transport zone that includes all clusters in the site or sites.
n Universal logical switches attached to the universal transport zone. Two universal logical switches are
used to connect VMs and one is used as a transit network for the router uplink.
n A universal logical router with an NSX Edge appliance to enable dynamic routing. The universal
logical router appliance has internal interfaces on the VM universal logical switches and an uplink
interface on the transit network universal logical switch.
n Edge Services Gateways (ESGs) connected to the transit network and the physical egress router
network.
VMware, Inc. 30
NSX Administration Guide
Universal Site A
Controller
vCenter with NSX vCenter with NSX
Cluster
Manager (Primary) Manager (Secondary)
Physical Routers
P P
VPN V VPN V
OSPF, BGP
NSX Edge Universal
Peering x8 Services Logical Switch
Gateway Transit Network
E1 E8
Universal
Logical Router
Appliance
VMware, Inc. 31
NSX Administration Guide
Physical Routers
P P
VPN V VPN V
OSPF, BGP
NSX Edge Universal
Peering Services Logical Switch
Gateway Transit Network
E1 E8
Universal
Logical Router
Appliance
Local Egress
All sites in a multi-site cross-vCenter NSX environment can use the same physical routers for egress
traffic. However, if egress routes need to be customized, the local egress feature must be enabled when
the universal logical router is created.
Local egress allows you to customize routes at the universal logical router, cluster, or host level. This
example of a cross-vCenter NSX environment in multiple sites has local egress enabled. The edge
services gateways (ESGs) in each site have a default route that sends traffic out through that site's
physical routers. The universal logical router is configured with two appliances, one in each site. The
appliances learn routes from their site's ESGs. The learned routes are sent to the universal controller
VMware, Inc. 32
NSX Administration Guide
cluster. Because local egress is enabled, the locale ID for that site is associated with those routes. The
universal controller cluster sends routes with matching locale IDs to the hosts. Routes learned on the site
A appliance are sent to the hosts in site A, and routes learned on the site B appliance are sent to the
hosts in site B.
P P P P
VPN V VPN V VPN V VPN V
OSPF, BGP OSPF, BGP
NSX Edge NSX Edge
Peering Services Services Peering
Gateway Gateway
E1 E8 E1 E8
Universal Universal
Universal Logical Switch Logical Switch
Logical Router Universal
Transit Network A Transit Network B
Primary Logical Router
Appliance Secondary
Appliance
Universal Distributed Logical Router
VMware, Inc. 33
NSX Administration Guide
It is important to understand what happens when you change an NSX Manager's role.
Set as primary This operation sets the role of an NSX Manager to primary and starts the
synchronization software. This operation fails if the NSX Manager is
already the primary or already a secondary.
Set as standalone (from This operation sets the role of NSX Manager to standalone or transit mode.
secondary) This operation might fail if the NSX Manager already has the standalone
role.
Set as standalone (from This operation resets the primary NSX Manager to standalone or transit
primary) mode, stops the synchronization software, and unregisters all secondary
NSX Managers. This operation might fail if the NSX Manager is already
standalone or if any of the secondary NSX Managers are unreachable.
Disconnect from When you run this operation on a secondary NSX Manager, the secondary
primary NSX Manager is unilaterally disconnected from the primary NSX Manager.
This operation should be used when the primary NSX Manager has
experienced an unrecoverable failure, and you want to register the
secondary NSX Manager to a new primary. If the original primary NSX
Manager does come up again, its database continues to list the secondary
NSX Manager as registered. To resolve this issue, include the force option
when you disconnect or unregister the secondary from the original primary.
The force option removes the secondary NSX Manager from the original
primary NSX Manager's database.
VMware, Inc. 34
Transport Zones 5
A transport zone controls to which hosts a logical switch can reach. It can span one or more vSphere
clusters. Transport zones dictate which clusters and, therefore, which VMs can participate in the use of a
particular network. In a cross-vCenter NSX environment you can create a universal transport zone, which
can include clusters from any vCenter in the environment. You can create only one universal transport
zone.
An NSX environment can contain one or more transport zones based on your requirements. A host
cluster can belong to multiple transport zones. A logical switch can belong to only one transport zone.
NSX does not allow connection of VMs that are in different transport zones. The span of a logical switch
is limited to a transport zone, so virtual machines in different transport zones cannot be on the same
Layer 2 network. A distributed logical router cannot connect to logical switches that are in different
transport zones. After you connect the first logical switch, the selection of further logical switches is limited
to those that are in the same transport zone. Similarly, an edge services gateway (ESG) has access to
logical switches from only one transport zone.
The following guidelines are meant to help you design your transport zones:
n If a cluster requires Layer 3 connectivity, the cluster must be in a transport zone that also contains an
edge cluster, meaning a cluster that has Layer 3 edge devices (distributed logical routers and edge
services gateways).
n Suppose you have two clusters, one for web services and another for application services. To have
VXLAN connectivity between the VMs in these two clusters, both of the clusters must be included in
the transport zone.
n Keep in mind that all logical switches included in the transport zone will be available and visible to all
VMs within the clusters that are included in the transport zone. If a cluster includes secured
environments, you might not want to make it available to VMs in other clusters. Instead, you can
place your secure cluster in a more isolated transport zone.
n The span of the vSphere distributed switch (VDS or DVS) should match the transport zone span.
When creating transport zones in multi-cluster VDS configurations, make sure all clusters in the
selected VDS are included in the transport zone. This is to ensure that the DLR is available on all
clusters where VDS dvPortgroups are available.
The following diagram shows a transport zone correctly aligned to the VDS boundary.
VMware, Inc. 35
NSX Administration Guide
5001
5002
5003
db1
If you do not follow this best practice, keep in mind that if a VDS spans more than one host cluster and
the transport zone includes only one (or a subset) of these clusters, any logical switch included within this
transport zone can access VMs within all clusters spanned by the VDS. In other words, the transport zone
will not be able to constrain the logical switch span to a subset of the clusters. If this logical switch is later
connected to a DLR, you must ensure that the router instances are created only in the cluster included in
the transport zone to avoid any Layer 3 issues.
VMware, Inc. 36
NSX Administration Guide
For example, when a transport zone is not aligned to the VDS boundary, the scope of the logical switches
(5001, 5002 and 5003) and the DLR instances that these logical switches are connected to becomes
disjointed, causing VMs in cluster Comp A to have no access to the DLR logical interfaces (LIFs).
5001
DLR DLR
Missing! Missing!
5002
5003
db1
You can have only one universal transport zone in a cross-vCenter NSX environment.
VMware, Inc. 37
NSX Administration Guide
Prerequisites
n In a standalone or single vCenter NSX environment there is only one NSX Manager so you do not
need to select one.
n Objects local to an NSX Manager must be managed from that NSX Manager.
n In a cross-vCenter NSX environment that does not have Enhanced Linked Mode enabled, you must
make configuration changes from the vCenter linked to the NSX Manager that you want to modify.
n In a cross-vCenter NSX environment in Enhanced Linked Mode, you can make configuration changes
to any NSX Manager from any linked vCenter. Select the appropriate NSX Manager from the NSX
Manager drop-down menu.
Procedure
1 Navigate to Home > Networking & Security > Installation and Upgrade and select the Logical
Network Preparation tab.
2 Click Transport Zones and click the New Transport Zone ( ) icon.
3 (Optional) To add a universal transport zone, select Mark this object for universal
synchronization.
n Multicast: Multicast IP addresses in the physical network are used for the control plane. This
mode is recommended only when you are upgrading from older VXLAN deployments. Requires
PIM/IGMP in the physical network.
n Unicast: The control plane is handled by an NSX controller. All unicast traffic leverages optimized
headend replication. No multicast IP addresses or special network configuration is required.
n Hybrid: Offloads local traffic replication to the physical network (L2 multicast). This requires
IGMP snooping on the first-hop switch and access to an IGMP querier in each VTEP subnet, but
does not require PIM. The first-hop switch handles traffic replication for the subnet.
Important If you create a universal transport zone and select hybrid as the replication mode, you
must ensure that the multicast address used does not conflict with any other multicast addresses
assigned on any NSX Manager in the environment.
Transport-Zone is a transport zone local to the NSX Manager on which it was created.
VMware, Inc. 38
NSX Administration Guide
What to do next
If you added a universal transport zone, you can add universal logical switches.
If you added a universal transport zone, you can select the secondary NSX Managers and add their
clusters to the universal transport zone.
Procedure
The Summary tab displays the name and description of the transport zone as well as the number of
logical switches associated with it. Transport Zone Details displays the clusters in the transport zone.
2 Click the Edit Settings icon in the Transport Zone Details section to edit the name, description, or
control plane mode of the transport zone.
If you change the transport zone control plane mode, select Migrate existing Logical Switches to
the new control plane mode to change the control plane more for existing logical switches linked to
this transport zone. If you do not select this check box, only the logical switches linked to this
transport zone after the edit is done will have the new control plane mode.
3 Click OK.
Prerequisites
The clusters you add to a transport zone have the network infrastructure installed and are configured for
VXLAN. See the NSX Installation Guide.
Procedure
2
Click the Add Cluster ( ) icon.
VMware, Inc. 39
NSX Administration Guide
3 Select the clusters you want to add to the transport zone and click OK.
Procedure
2
In Transport Zones Details, click the Remove Clusters ( ) icon.
4 Click OK.
VMware, Inc. 40
Logical Switches 6
A cloud deployment or a virtual data center has a variety of applications across multiple tenants. These
applications and tenants require isolation from each other for security, fault isolation, and avoiding
overlapping IP addressing issues. The NSX logical switch creates logical broadcast domains or segments
to which an application or tenant virtual machine can be logically wired. This allows for flexibility and
speed of deployment while still providing all the characteristics of a physical network's broadcast domains
(VLANs) without physical Layer 2 sprawl or spanning tree issues.
A logical switch is distributed and can span arbitrarily large compute clusters. This allows for virtual
machine mobility (vMotion) within the datacenter without limitations of the physical Layer 2 (VLAN)
boundary. The physical infrastructure does not have to deal with MAC/FIB table limits since the logical
switch contains the broadcast domain in software.
A logical switch is mapped to a unique VXLAN, which encapsulates the virtual machine traffic and carries
it over the physical IP network.
VMware, Inc. 41
NSX Administration Guide
Controller NSX
cluster Manager
The NSX controller is the central control point for all logical switches within a network and maintains
information of all virtual machines, hosts, logical switches, and VXLANs. The controller supports two new
logical switch control plane modes, Unicast and Hybrid, These modes decouple NSX from the physical
network. VXLANs no longer require the physical network to support multicast in order to handle the
Broadcast, Unknown unicast, and Multicast (BUM) traffic within a logical switch. The unicast mode
replicates all the BUM traffic locally on the host and requires no physical network configuration. In the
hybrid mode, some of the BUM traffic replication is offloaded to the first hop physical switch to achieve
better performance. This mode requires IGMP snooping to be turned on the first hop physical switch.
Virtual machines within a logical switch can use and send any type of traffic including IPv6 and multicast.
You can extend a logical switch to a physical device by adding an L2 bridge. See Chapter 8 L2 Bridges.
You must have the Super Administrator or Enterprise Administrator role permissions to manage logical
switches.
VMware, Inc. 42
NSX Administration Guide
n You have the Super Administrator or Enterprise Administrator role permission to configure and
manage logical switches.
n VXLAN UDP port is opened on firewall rules (if applicable). The VXLAN UDP port can be configured
through the API.
n Physical infrastructure MTU is at least 50 bytes more than the MTU of the virtual machine vNIC.
n Managed IP address is set for each vCenter Server in the vCenter Server Runtime Settings. See
vCenter Server and Host Management.
n DHCP is available on VXLAN transport VLANs if you are using DHCP for IP assignment for VMKNics.
n A consistent distributed virtual switch type (vendor, and so on) and version is being used across a
given transport zone. Inconsistent switch types can lead to undefined behavior in your logical switch.
n You have configured an appropriate LACP teaming policy and connected physical NICs to the ports.
For more information on teaming modes, refer to the VMware vSphere documentation.
n 5-tuple hash distribution is enabled for Link Aggregation Control Protocol (LACP).
n Verify that for every host where you want to use LACP, a separate LACP port channel exists on the
distributed virtual switch.
n For multicast mode, multicast routing is enabled if VXLAN traffic is traversing routers. You have
acquired a multicast address range from your network administrator.
n Port 1234 (the default controller listening port) is opened on firewall for the ESX host to communicate
with controllers.
n (Recommended) For multicast and hybrid modes, you have enabled IGMP snooping on the L2
switches to which VXLAN participating hosts are attached. If IGMP snooping is enabled on L2, IGMP
querier must be enabled on the router or L3 switch with connectivity to multicast enabled networks.
VMware, Inc. 43
NSX Administration Guide
When you create a logical switch, in addition to selecting a transport zone and replication mode, you
configure two options: IP discovery, and MAC learning.
IP discovery minimizes ARP traffic flooding within individual VXLAN segments---in other words, between
VMs connected to the same logical switch. IP discovery is enabled by default.
Note You cannot disable IP discovery when you create a universal logical switch. You can disable IP
discovery via the API after the universal logical switch is created. This setting is managed separately on
each NSX Manager. See the NSX API Guide.
MAC learning builds a VLAN/MAC pair learning table on each vNIC. This table is stored as part of the
dvfilter data. During vMotion, dvfilter saves and restores the table at the new location. The switch then
issues RARPs for all the VLAN/MAC entries in the table. You might want to enable MAC learning if your
VMs have multiple MAC addresses or are using virtual NICs that are trunking VLANs.
Prerequisites
Table 6‑1. Prerequisites for creating a logical switch or universal logical switch
Logical Switch Universal Logical Switch
n vSphere distributed switches must be configured. n vSphere distributed switches must be configured.
n NSX Manager must be installed. n NSX Manager must be installed.
n Controllers must be deployed. n Controllers must be deployed.
n Host clusters must be prepared for NSX. n Host clusters must be prepared for NSX.
n VXLAN must be configured. n VXLAN must be configured.
n A segment ID pool must be configured. n A primary NSX Manager must be assigned.
n A transport zone must be created. n A universal segment ID pool must be configured.
n A universal transport zone must be created.
n In a standalone or single vCenter NSX environment there is only one NSX Manager so you do not
need to select one.
n Objects local to an NSX Manager must be managed from that NSX Manager.
n In a cross-vCenter NSX environment that does not have Enhanced Linked Mode enabled, you must
make configuration changes from the vCenter linked to the NSX Manager that you want to modify.
n In a cross-vCenter NSX environment in Enhanced Linked Mode, you can make configuration changes
to any NSX Manager from any linked vCenter. Select the appropriate NSX Manager from the NSX
Manager drop-down menu.
Procedure
2 Select the NSX Manager on which you want to create a logical switch. To create a universal logical
switch, you must select the primary NSX Manager.
VMware, Inc. 44
NSX Administration Guide
5 Select the transport zone in which you want to create the logical switch. Selecting a universal
transport zone will create a universal logical switch.
By default, the logical switch inherits the control plane replication mode from the transport zone. You
can change it to one of the other available modes. The available modes are unicast, hybrid, and
multicast.
If you create a universal logical switch and select hybrid as the replication mode, you must ensure
that the multicast address used does not conflict with other multicast addresses assigned on any NSX
Manager in the cross-vCenter NSX environment.
The logical switch and the universal logical switch have segment IDs from different segment ID pools.
What to do next
Create a logical router and attach it to your logical switches to enable connectivity between VMs that are
connected to different logical switches.
Create a universal logical router and attach it to your universal logical switches to enable connectivity
between VMs that are connected to different universal logical switches.
VMware, Inc. 45
NSX Administration Guide
Procedure
1 In Logical Switches, select the logical switch to which you want to connect an NSX Edge.
3 Select the NSX Edge to which you want to connect the logical switch and click Next.
4 Select the interface that you want to connect to the logical switch and click Next.
5 On the Edit NSX Edge interface page, type a name for the NSX Edge interface.
8 If the NSX Edge to which you are connecting the logical switch has Manual HA Configuration
selected, specify two management IP addresses in CIDR format.
10 Click Next.
Prerequisites
One or more third party virtual appliances must have been installed in your infrastructure.
Procedure
1 In Logical Switches, select the logical switch on which you want to deploy services.
2
Click the Add Service Profile ( ) icon.
3 Select the service and service profile that you want to apply.
4 Click OK.
Procedure
1 In Logical Switches, select the logical switch to which you want to add virtual machines.
2
Click the Add Virtual Machine ( ) icon.
3 Select the virtual machines you want to add to the logical switch.
VMware, Inc. 46
NSX Administration Guide
5 Click Next.
7 Click Finish.
1 In Logical Switches, double click the logical switch that you want to test in the Name column.
4 Click Browse in the Source Host section. In the Select Host dialog box, select the destination host.
VXLAN standard size is 1550 bytes (should match the physical infrastructure MTU) without
fragmentation. This allows NSX to check connectivity and verify that the infrastructure is prepared for
VXLAN traffic.
Minimum packet size allows fragmentation. Hence, with packet size minimized, NSX can check
connectivity but not whether the infrastructure is ready for the larger frame size.
6 Click Browse in the Destination Host section. In the Select Host dialog box, select the destination
host.
SpoofGuard allows you to authorize the IP addresses reported by VMware Tools or IP discovery, and alter
them if necessary to prevent spoofing. SpoofGuard inherently trusts the MAC addresses of virtual
machines collected from the VMX files and vSphere SDK. Operating separately from the Firewall rules,
you can use SpoofGuard to block traffic identified as spoofed.
VMware, Inc. 47
NSX Administration Guide
Procedure
1 In Logical Switches, select the logical switch that you want to edit.
4 Click OK.
Cluster 1 Cluster 2
vDS1 vDS2
Physical Physical
Switch Switch
Engineering: VLAN10:10.10.1.0/24
Finance: VLAN20:10.20.1.0/24
Marketing: VLAN30:10.30.1.0/24
ACME is running out of compute space on Cluster1 while Cluster2 is under-utilized. The ACME network
supervisor asks John Admin (ACME's virtualization administrator) to figure out a way to extend the
Engineering department to Cluster2 in a way that virtual machines belonging to Engineering on both
clusters can communicate with each other. This would enable ACME to utilize the compute capacity of
both clusters by stretching ACME's L2 layer.
If John Admin were to do this the traditional way, he would need to connect the separate VLANs in a
special way so that the two clusters can be in the same L2 domain. This might require ACME to buy a
new physical device to separate traffic, and lead to issues such as VLAN sprawl, network loops, and
administration and management overhead.
VMware, Inc. 48
NSX Administration Guide
John Admin remembers seeing a logical network demo at VMworld, and decides to evaluate NSX. He
concludes that building a logical switch across dvSwitch1 and dvSwitch2 will allow him to stretch ACME's
L2 layer. Since John can leverage the NSX controller, he will not have to touch ACME's physical
infrastructure as NSX works on top of existing IP networks.
Cluster 1 Cluster 2
Logical Switch stretches across multiple VLANs/subnets
vDS1 vDS2
Physical Physical
Switch Switch
Engineering: VXLAN5000:10.10.1.0/24
Finance: VLAN 20:10.20.1.0/24
Marketing: VLAN 30:10.30.1.0/24
Once John Admin builds a logical switch across the two clusters, he can vMotion virtual machines from
one cluster to another while keeping them attached to the same logical switch.
VMware, Inc. 49
NSX Administration Guide
vDS1 vDS2
Physical Physical
Switch Switch
Engineering: VXLAN5000:10.10.1.0/24
Finance: VLAN 20:10.20.1.0/24
Marketing: VLAN 30:10.30.1.0/24
Let us walk through the steps that John Admin follows to build a logical network at ACME Enterprise.
Prerequisites
1 John Admin verifies that dvSwitch1 and dvSwitch2 are vSphere Distributed Switches.
2 John Admin sets the Managed IP address for the vCenter Server.
c Click OK.
3 John Admin installs the network virtualization components on Cluster1 and Cluster 2. See NSX
Installation Guide.
4 John Admin gets a segment ID pool (5000 - 5250) from ACME's NSX Manager administrator. Since
he is leveraging the NSX controller, he does not require multicast in his physical network.
5 John Admin creates an IP pool so that he can assign a static IP address to the VXLAN VTEPs from
this IP pool. See Add an IP Pool.
VMware, Inc. 50
NSX Administration Guide
Procedure
1 In the vSphere Web Client, click Networking & Security > Installation and Upgrade.
2 Click the Logical Network Preparation tab and then click Segment ID.
3 Click Edit.
6 Click OK.
Procedure
3 In the Configuring VXLAN networking dialog box, select dvSwitch1 as the vSphere Distributed Switch
for the cluster.
5 In Specify Transport Attributes, leave 1600 as the Maximum Transmission Units (MTU) for dvSwitch1.
MTU is the maximum amount of data that can be transmitted in one packet before it is divided into
smaller packets. John Admin knows that VXLAN logical switch traffic frames are slightly larger in size
because of the encapsulation, so the MTU for each switch must be set to 1550 or higher.
John Admin wants to maintain the quality of service in his network by keeping the performance of
logical switches the same in normal and fault conditions. Hence, he chooses Failover as the teaming
policy.
8 Click Add.
After John admin maps Cluster1 and Cluster2 to the appropriate switch, the hosts on those clusters are
prepared for logical switches:
1 A VXLAN kernel module and vmknic is added to each host in Cluster 1 and Cluster 2.
2 A special dvPortGroup is created on the vSwitch associated with the logical switch and the VMKNic is
connected to it.
VMware, Inc. 51
NSX Administration Guide
Procedure
7 Click OK.
Procedure
1 Click Logical Switches and then click the New Logical Network icon.
3 In Description, type
Logical Network for extending ACME Engineering network to Cluster2.
5 Click OK.
NSX creates a logical switch providing L2 connectivity between dvSwitch1 and dvSwitch2.
What to do next
John Admin can now connect ACME's production virtual machines to the logical switch, and connect the
logical switch to an NSX Edge services gateway or Logical Router.
VMware, Inc. 52
Configuring Hardware Gateway 7
Hardware gateway configuration maps physical networks to virtual networks. The mapping configuration
allows NSX to leverage the Open vSwitch Database (OVSDB).
The OVSDB database contains information about the physical hardware and the virtual network. The
vendor hardware hosts the database server.
The hardware gateway switches in the NSX logical networks terminate VXLAN tunnels. To the virtual
network, the hardware gateway switches are known as hardware VTEP. For more information about
VTEPs, see the NSX Installation guide and NSX Network Virtualization Design guide.
n Physical server
n IP network
The sample topology with a hardware gateway shows HV1 and HV2 as the two hypervisors. The VM1
virtual machine is on HV1. VTEP1 is on HV1, VTEP2 is on HV2, and VTEP3 is on the hardware gateway.
The hardware gateway is located in a different subnet 211 compared to the two hypervisors that are
located in the same subnet 221.
NSX Controllers
10.114.221.132-134 VLAN-Server
VTEP3
Ethernet18
WebService LS
VLAN 160
VM1 VNI 5000
10.114.221.199
VMware, Inc. 53
NSX Administration Guide
The hardware gateway underlying configuration can have any one of the following components:
n Single switch
The NSX Controller communicates with the hardware gateway using its IP address on port 6640. This
connection is used to send and receive OVSDB transactions from hardware gateways.
The sample topology shows that virtual machine VM1 and VLAN-Server are configured with an IP
address in the subnet 10. VM1 is attached to WebService logical switch. The VLAN-Server is attached to
VLAN 160 on the physical server.
VM1 VLAN-Server
VM
10.0.0.1/8 10.0.0.2/8
Important In a cross-vCenter NSX environment, hardware gateway switch configurations are only
supported on the primary NSX Manager. Hardware gateway switches must be bound to non-universal
logical switches. Hardware gateway configurations are not supported on secondary NSX Managers.
Prerequisites
n Verify that you meet the NSX system and hardware requirements for hardware gateway configuration.
See Chapter 1 System Requirements for NSX.
n Verify that the logical networks are set up properly. See the NSX Installation guide.
n Verify that the transport parameter mappings in the VXLAN are accurate. See the NSX Installation
guide.
n Verify that the VXLAN port value is set to 4789. See Change VXLAN Port.
VMware, Inc. 54
NSX Administration Guide
Procedure
Note The replication nodes and the hardware gateway switches cannot be on the same IP subnet.
Prerequisites
Procedure
4 Click Edit in the Replication Cluster section to select hypervisors to serve as replication nodes in this
replication cluster.
VMware, Inc. 55
NSX Administration Guide
6 Click OK.
The replication nodes are added to the replication cluster. At least one host must exist in the replication
cluster.
The Controller passively listens to the connection attempt from the physical switch. Therefore, the
hardware gateway must use the OVSDB manager table to initiate connection.
Prerequisites
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.
VMware, Inc. 56
NSX Administration Guide
Procedure
1 Use the commands that apply to your environment to connect the hardware gateway to the NSX
Controller.
prmh-nsx-tor-7050sx-3#enable
prmh-nsx-tor-7050sx-3#configure terminal
prmh-nsx-tor-7050sx-3(config)#cvx
prmh-nsx-tor-7050sx-3(config-cvx)#service hsc
prmh-nsx-tor-7050sx-3(config-cvx-hsc)#manager 172.16.2.95 6640
prmh-nsx-tor-7050sx-3(config-cvx-hsc)#no shutdown
prmh-nsx-tor-7050sx-3(config-cvx-hsc)#end
4 (Optional) Verify that the hardware gateway is connected to the NSX Controller through the OVSDB
channel.
n Ping the VM1 and VLAN 160 to verify that the connection succeeds.
5 (Optional) Verify that the hardware gateway is connected to correct NSX Controller.
b Select Networking & Security > Installation and Upgrade > Management > NSX Controller
nodes.
Prerequisites
Verify that the hardware gateway certificate from your environment is available.
Procedure
VMware, Inc. 57
NSX Administration Guide
4 Click the Add ( ) icon to create the hardware gateway profile details.
Option Description
Certificate Paste the certificate that you extracted from your environment.
5 Click OK.
6 Refresh the screen to verify that the hardware gateway is available and running.
7 (Optional) Click the hardware gateway profile and right-click to select View the BFD Tunnel Status
from the drop-down menu.
The dialog box shows diagnostic tunnel status details for troubleshooting.
VMware, Inc. 58
NSX Administration Guide
Note If you bind multiple logical switches to hardware ports, you must apply these steps for each logical
switch.
Prerequisites
n Verify that the WebService logical switch is available. See Add a Logical Switch.
Procedure
3 Locate the WebService logical switch and right-click to select Manage Harware Bindings from the
drop-down menu.
5 Click the Add ( ) icon and select the physical switch from the drop-down menu.
6 Click Select to choose a physical port from the Available Objects list.
7 Click OK.
9 Click OK.
VMware, Inc. 59
NSX Administration Guide
The NSX Controller synchronizes the physical and logical configuration information with the hardware
gateway.
VMware, Inc. 60
L2 Bridges 8
You can create an L2 bridge between a logical switch and a VLAN, which enables you to migrate virtual
workloads to physical devices with no impact on IP addresses.
A Layer 2 bridge enables connectivity between the virtual and physical network by enabling virtual
machines (VMs) to be connected to a physical server or network. Use cases include:
n Physical to virtual, or virtual to virtual migration. L2 bridging allows you to maintain connectivity
between workloads inside NSX and outside NSX, without requiring IP re-addressing.
n Insertion into NSX of an appliance that cannot be virtualized, and that require L2 connectivity with its
clients. This is common for some physical database servers.
n Service insertion. An L2 Bridge allows integrating transparently into NSX any physical appliance such
as a router, load balancer or firewall
A logical network can leverage a physical L3 gateway and access existing physical networks and security
resources by bridging the logical switch broadcast domain to the VLAN broadcast domain. The L2 bridge
runs on the host that has the NSX Edge logical router virtual machine. An L2 bridge instance maps to a
single VLAN, but there can be multiple bridge instances. The logical router cannot be used as a gateway
for devices connected to a bridge.The VLAN port group and VXLAN logical switch that is bridged must be
on the same vSphere distributed switch (VDS) and both must share same physical NICs.
VXLAN (VNI) network and VLAN-backed port groups must be on the same distributed virtual switch
(VDS).
VMware, Inc. 61
NSX Administration Guide
NSX Edge
logical router
virtual machine
Compute rack
Physical
workload
Physical
gateway
Note that you should not use an L2 bridge to connect a logical switch to another logical switch, a VLAN
network to another VLAN network, or to interconnect datacenters. Also, you cannot use a universal
logical router to configure bridging and you cannot add a bridge to a universal logical switch.
n Add L2 Bridge
Add L2 Bridge
You can add a bridge from a logical switch to a distributed virtual port group.
Prerequisites
VMware, Inc. 62
NSX Administration Guide
The logical switch and the VLAN-backed distributed virtual port group that are to be bridged together
must exist on the same Virtual Distributed Switch (VDS).
A DLR Control VM on a hypervisor where the VDS with the logical switch and VLAN-backed distributed
virtual port group are instantiated must be deployed in your environment.
You cannot use a universal logical router to configure bridging, and you cannot add a bridge to a universal
logical switch.
Procedure
7 Select the logical switch that you want to create a bridge for.
8 Select the distributed virtual port group to which you want to bridge the logical switch.
9 Click OK.
Prerequisites
n You cannot use a universal logical router to configure bridging, and you cannot add a bridge to a
universal logical switch.
Procedure
3 Double click the logical router that will be used for bridging.
Note The bridge instance has to be created in the same routing instance to which the vxlan is
connected. One bridge instance can have one vxlan and one vlan, the vxlan and vlan cannot overlap.
The same vxlan and vlan cannot connect to more than one bridge instances.
VMware, Inc. 63
NSX Administration Guide
The logical switch that is being used as a router will state Routing Enabled.
7 Select the logical switch that you want to create a bridge for.
8 Select the distributed virtual port group to which you want to bridge the logical switch.
9 Click OK.
The logical switch that is used for bridging will now appear with Routing Enabled specified. For more
information, see Add a Logical Switch and Connect Virtual Machines to a Logical Switch.
VMware, Inc. 64
Routing 9
You can specify static and dynamic routing for each NSX Edge.
Dynamic routing provides the necessary forwarding information between Layer 2 broadcast domains,
thereby allowing you to decrease Layer 2 broadcast domains and improve network efficiency and scale.
NSX extends this intelligence to where the workloads reside for doing East-West routing. This allows
more direct virtual machine to virtual machine communication without the added cost or time needed to
extend hops. At the same time, NSX also provides North-South connectivity, thereby enabling tenants to
access public networks.
n Configure BGP
VMware, Inc. 65
NSX Administration Guide
n NSX version 6.2 and later allows logical router-routed logical interfaces (LIFs) to be connected to a
VXLAN that is bridged to a VLAN.
n Logical router interfaces and bridging interfaces cannot be connected to a dvPortgroup with the VLAN
ID set to 0.
n A given logical router instance cannot be connected to logical switches that exist in different transport
zones. This is to ensure that all logical switches and logical router instances are aligned.
n A logical router cannot be connected to VLAN-backed portgroups if that logical router is connected to
logical switches spanning more than one vSphere distributed switch (VDS).This is to ensure correct
alignment of logical router instances with logical switch dvPortgroups across hosts.
n Logical router interfaces should not be created on two different distributed portgroups (dvPortgroups)
with the same VLAN ID if the two networks are in the same vSphere distributed switch.
n Logical router interfaces should not be created on two different dvPortgroups with the same VLAN ID
if two networks are in different vSphere distributed switches, but the two vSphere distributed switches
share the same hosts. In other words, logical router interfaces can be created on two different
networks with the same VLAN ID if the two dvPortgroups are in two different vSphere distributed
switches, as long as the vSphere distributed switches do not share a host.
The following list describes feature support by interface type (uplink and internal) on the logical router:
n Dynamic routing protocols (BGP and OSPF) are supported only on uplink interfaces.
n Firewall rules are applicable only on uplink interfaces and are limited to control and management
traffic that is destined to the edge virtual appliance.
n For more information about the DLR Management Interface see the Knowledge Base Article,
Considerations for Management Interface of Distributed Logical Router Control VM,
http://kb.vmware.com/kb/2122060.
Important If you enable high availability on an NSX Edge in a cross-vCenter NSX environment, both the
active and standby NSX Edge appliances must reside within the same vCenter Server. If you migrate one
of the members of an NSX Edge HA pair to a different vCenter Server system, the two HA appliances will
no longer operate as an HA pair, and you might experience traffic disruption.
Prerequisites
n You must have been assigned the Enterprise Administrator or NSX Administrator role.
n You must create a local segment ID pool, even if you have no plans to create NSX logical switches.
n Make sure the controller cluster is up and available before creating or changing a logical router
configuration. A logical router cannot distribute routing information to hosts without the help of NSX
controllers. A logical router relies on NSX controllers to function, while edge services gateways
(ESGs) do not.
VMware, Inc. 66
NSX Administration Guide
n If a logical router is to be connected to VLAN dvPortgroups, ensure that all hypervisor hosts with a
logical router appliance installed can reach each other on UDP port 6999 for logical router VLAN-
based ARP proxy to work.
n The destination host must be part of the same transport zone as the logical switches connected
to the new logical router's interfaces.
n Avoid placing it on the same host as one or more of its upstream ESGs if you use ESGs in an
ECMP setup. You can use DRS anti-affinity rules to enforce this, thus reducing the impact of host
failure on logical router forwarding. This guideline does not apply if you have one upstream ESG
by itself or in HA mode. For more information, see the VMware NSX for vSphere Network
Virtualization Design Guide at https://communities.vmware.com/docs/DOC-27683.
n Verify that the host cluster on which the logical router appliance will be installed is prepared for NSX.
See Prepare Host Clusters for NSX in the NSX Installation Guide.
n In a standalone or single vCenter NSX environment there is only one NSX Manager so you do
not need to select one.
n Objects local to an NSX Manager must be managed from that NSX Manager.
n In a cross-vCenter NSX environment that does not have Enhanced Linked Mode enabled, you
must make configuration changes from the vCenter linked to the NSX Manager that you want to
modify.
n In a cross-vCenter NSX environment in Enhanced Linked Mode, you can make configuration
changes to any NSX Manager from any linked vCenter. Select the appropriate NSX Manager
from the NSX Manager drop-down menu.
n If you need to connect a logical switch, you must add a logical router
n If you need to connect a universal logical switch, you must add a universal logical router
n If you are adding a universal logical router, determine if you need to enable local egress. Local egress
allows you to selectively send routes to hosts. You may want this ability if your NSX deployment
spans multiple sites. See Cross-vCenter NSX Topologies for more information. You cannot enable
local egress after the universal logical router has been created.
Procedure
1 In the vSphere Web Client, navigate to Home > Networking & Security > NSX Edges.
2 Select the appropriate NSX Manager on which to make your changes. If you are creating a universal
logical router, you must select the primary NSX Manager.
VMware, Inc. 67
NSX Administration Guide
n Select Logical (Distributed) Router to add a logical router local to the selected NSX Manager.
n Select Universal Logical (Distributed) Router to add a logical router that can span the cross-
vCenter NSX environment. This option will be available only if you have assigned a primary NSX
Manager, and are making changes from the primary NSX Manager.
a If you select Universal Logical (Distributed) Router, you must also select whether to enable
local egress.
This name appears in your vCenter inventory. The name should be unique across all logical routers
within a single tenant.
Optionally, you can also enter a hostname. This name appears in the CLI. If you do not specify the
host name, the Edge ID, which gets created automatically, is displayed in the CLI.
Deploy Edge Appliance is selected by default. An edge appliance (also called a logical router virtual
appliance) is required for dynamic routing and the logical router appliance's firewall, which applies to
logical router pings, SSH access, and dynamic routing traffic.
You can deselect the edge appliance option if you require only static routes, and do not want to
deploy an Edge appliance. You cannot add an Edge appliance to the logical router after the logical
router has been created.
Enable High Availability is not selected by default. Select the Enable High Availability check box to
enable and configure high availability. High availability is required if you are planning to do dynamic
routing.
The password must be 12-255 characters and must contain the following:
By default, SSH is disabled. If you do not enable SSH, you can still access the logical router by
opening the virtual appliance console. Enabling SSH here causes the SSH process to run on the
logical router virtual appliance, but you will also need to adjust the logical router firewall configuration
manually to allow SSH access to the logical router's protocol address. The protocol address is
configured when you configure dynamic routing on the logical router.
VMware, Inc. 68
NSX Administration Guide
By default, FIPS mode is disabled. Select the Enable FIPS mode check box to enable the FIPS
mode. When you enable the FIPS mode, any secure communication to or from the NSX Edge uses
cryptographic algorithms or protocols that are allowed by FIPS.
For example:
11 Configure deployment.
u If you did not select Deploy Edge Appliance, the Add ( ) icon is grayed out. Click Next to
continue with configuration.
u If you selected Deploy Edge Appliance, enter the settings for the logical router virtual appliance
that will be added to your vCenter inventory.
For example:
VMware, Inc. 69
NSX Administration Guide
If you selected Deploy Edge Appliance you must connect the HA interface to a distributed port
group or logical switch. If you are using this interface as an HA interface only, VMware
recommends using a logical switch. A /30 subnet is allocated from the link local range
169.254.0.0/16 and is used to provide an IP address for each of the two NSX Edge appliances.
Optionally, if you want to use this interface to connect to the NSX Edge, you can specify an
additional IP address and prefix for the HA interface.
Note Before NSX 6.2, the HA interface was called the management interface. You cannot SSH
into the HA interface from anywhere that isn’t on the same IP subnet as the HA interface. You
cannot configure static routes that point out of the HA interface, which means that RPF will drop
incoming traffic. You could, in theory, disable RPF, but this would be counterproductive to high
availability. For SSH access, you can also use the logical router's protocol address, which is
configured later when you configure dynamic routing.
In NSX 6.2 and later, the HA interface of a logical router is automatically excluded from route
redistribution.
In Configure interfaces of this NSX Edge the internal interfaces are for connections to switches
that allow VM-to-VM (sometimes called East-West) communication. Internal interfaces are
created as pseudo vNICs on the logical router virtual appliance. Uplink interfaces are for North-
South communication. A logical router uplink interface might connect to an NSX edge services
VMware, Inc. 70
NSX Administration Guide
gateway, a third-party router VM for that, or a VLAN-backed dvPortgroup to make the logical
router connect to a physical router directly. You must have at least one uplink interface for
dynamic routing to work. Uplink interfaces are created as vNICs on the logical router virtual
appliance.
The interface configuration that you enter here is modifiable later. You can add, remove, and
modify interfaces after a logical router is deployed.
The following example shows an HA interface connected to the management distributed port group.
The example also shows two internal interfaces (app and web) and an uplink interface (to-ESG).
VMware, Inc. 71
NSX Administration Guide
For example:
14 Make sure any VMs attached to the logical switches have their default gateways set properly to the
logical router interface IP addresses.
In the following example topology, the default gateway of app VM should be 172.16.20.1. The default
gateway of web VM should be 172.16.10.1. Make sure the VMs can ping their default gateways and each
other.
VMware, Inc. 72
NSX Administration Guide
Logical
router
172.16.20.1 172.16.10.1
App Web
logical logical
switch switch
172.16.20.10 172.16.10.10
App Web
VM VM
Log in via SSH to the NSX Manager, and run the following commands:
n List the hosts that have received routing information for the logical router from the controller cluster.
The output includes all hosts from all host clusters that are configured as members of the transport
zone that owns the logical switch that is connected to the specified logical router (edge-1 in this
example).
n List the routing table information that is communicated to the hosts by the logical router. Routing table
entries should be consistent across all of the hosts.
VMware, Inc. 73
NSX Administration Guide
n List additional information about the router from the point of view of one of the hosts. This is helpful to
learn which controller is communicating with the host.
Check the Controller IP field in the output of the show logical-router host host-25 dlr edge-1
verbose command.
SSH to a controller, and run the following commands to display the controller's learned VNI, VTEP, MAC,
and ARP table state information.
n
192.168.110.202 # show control-cluster logical-switches vni 5000
VNI Controller BUM-Replication ARP-Proxy Connections
5000 192.168.110.201 Enabled Enabled 0
The output for VNI 5000 shows zero connections and lists controller 192.168.110.201 as the owner
for VNI 5000. Log in to that controller to gather further information for VNI 5000.
VMware, Inc. 74
NSX Administration Guide
Because 192.168.110.201 owns all three VNI connections, we would expect to see zero connections
on the other controller, 192.168.110.203.
n Before checking the MAC and ARP tables, start pinging from one VM to the other VM.
Check the logical router information. Each logical router Instance is served by one of the controller nodes.
The interface-summary sub-command displays the LIFs that the controller learned from the NSX
Manager. This information is sent to the hosts that are in the host clusters managed under the transport
zone.
VMware, Inc. 75
NSX Administration Guide
The routes sub-command shows the routing table that is sent to this controller by the logical router's
virtual appliance (also known as the control VM). Note that unlike on the ESXi hosts, this routing table
does not include directly connected subnets because this information is provided by the LIF configuration.
Route information on the ESXi hosts includes directly connected subnets because in that case it is a
forwarding table used by ESXi host’s datapath.
n
controller # show control-cluster logical-routers interface-summary 0x1388
Interface Type Id IP[]
13880000000b vxlan 0x1389 172.16.10.1/24
13880000000a vxlan 0x1388 172.16.20.1/24
138800000002 vxlan 0x138a 192.168.10.2/29
n
controller # show control-cluster logical-routers routes 0x1388
Destination Next-Hop[] Preference Locale-Id Source
192.168.100.0/24 192.168.10.1 110 00000000-0000-0000-0000-000000000000 CONTROL_VM
0.0.0.0/0 192.168.10.1 0 00000000-0000-0000-0000-000000000000 CONTROL_VM
[root@comp02a:~] esxcfg-route -l
VMkernel Routes:
Network Netmask Gateway Interface
10.20.20.0 255.255.255.0 Local Subnet vmk1
192.168.210.0 255.255.255.0 Local Subnet vmk0
default 0.0.0.0 192.168.210.1 vmk0
VMware, Inc. 76
NSX Administration Guide
These Host-IP addresses are vmk0 interfaces, not VTEPs. Connections between ESXi hosts and
controllers are created on the management network. The port numbers here are ephemeral TCP
ports that are allocated by the ESXi host IP stack when the host establishes a connection with the
controller.
n On the host, you can view the controller network connection matched to the port number.
n Display active VNIs on the host. Observe how the output is different across hosts. Not all VNIs are
active on all hosts. A VNI is active on a host if the host has a VM that is connected to the logical
switch.
[root@192.168.210.52:~] # esxcli network vswitch dvs vmware vxlan network list --vds-name
Compute_VDS
VXLAN ID Multicast IP Control Plane Controller Connection
Port Count MAC Entry Count ARP Entry Count VTEP Count
-------- ------------------------- ----------------------------------- ---------------------
---------- --------------- --------------- ----------
5000 N/A (headend replication) Enabled (multicast proxy,ARP proxy) 192.168.110.203
(up) 1 0 0 0
5001 N/A (headend replication) Enabled (multicast proxy,ARP proxy) 192.168.110.202
(up) 1 0 0 0
Note To enable the vxlan namespace in vSphere 6 and later, run the /etc/init.d/hostd restart
command.
For logical switches in hybrid or unicast mode, the esxcli network vswitch dvs vmware vxlan
network list --vds-name <vds-name> command should contain the following output:
n Multicast proxy and ARP proxy are listed. AARP proxy is listed even if you disabled IP discovery.
n If a logical router is connected to the ESXi host, the port Count is at least 1, even if there are no
VMs on the host connected to the logical switch. This one port is the vdrPort, which is a special
dvPort connected to the logical router kernel module on the ESXi host.
VMware, Inc. 77
NSX Administration Guide
n First ping from VM to another VM on a different subnet and then display the MAC table. Note the
Inner MAC is the VM entry while the Outer MAC and Outer IP refer to the VTEP.
~ # esxcli network vswitch dvs vmware vxlan network mac list --vds-name=Compute_VDS --vxlan-id=5000
Inner MAC Outer MAC Outer IP Flags
----------------- ----------------- -------------- --------
00:50:56:a6:23:ae 00:50:56:6a:65:c2 192.168.250.52 00000111
~ # esxcli network vswitch dvs vmware vxlan network mac list --vds-name=Compute_VDS --vxlan-id=5001
Inner MAC Outer MAC Outer IP Flags
----------------- ----------------- -------------- --------
02:50:56:56:44:52 00:50:56:6a:65:c2 192.168.250.52 00000101
00:50:56:f0:d7:e4 00:50:56:6a:65:c2 192.168.250.52 00000111
What to do next
When you install an NSX Edge appliance, NSX enables automatic VM startup/shutdown on the host if
vSphere HA is disabled on the cluster. If the appliance VMs are later migrated to other hosts in the
cluster, the new hosts might not have automatic VM startup/shutdown enabled. For this reason, VMware
recommends that when you install NSX Edge appliances on clusters that have vSphere HA disabled, you
should check all hosts in the cluster to make sure that automatic VM startup/shutdown is enabled. See
"Edit Virtual Machine Startup and Shutdown Settings" in vSphere Virtual Machine Administration.
After the logical router is deployed, double-click the logical router ID to configure additional settings, such
as interfaces, routing, firewall, bridging, and DHCP relay.
Uplink interfaces of an ESG connect to uplink port groups that have access to a shared corporate network
or a service that provides access layer networking.
The following list describes feature support by interface type (internal and uplink) on an ESG.
n HA: Not supported on uplink interface, requires at least one internal interface.
VMware, Inc. 78
NSX Administration Guide
The following figure shows a sample topology with an ESG's uplink interface connected to physical
infrastructure through the vSphere distributed switch and the ESG's internal interface connect to an NSX
logical router through an NSX logical transit switch.
Edge vSphere
Services Distributed Physical
192.168.100.3 Architecture
Gateway Link type: uplink Switch 192.168.100.1
192.168.10.1
Link type: internal
Transit
logical
switch
192.168.10.2
Link type: uplink
Protocol address:
192.168.10.3
Logical
Router
172.16.20.1 172.16.10.1
Link type: internal Link type: internal
App Web
logical logical
switch switch
172.16.20.10 172.16.10.10
App Web
VM VM
Multiple external IP addresses can be configured for load balancing, site-to-site VPN, and NAT services.
Important If you enable high availability on an NSX Edge in a cross-vCenter NSX environment, both the
active and standby NSX Edge appliances must reside within the same vCenter Server. If you migrate one
of the members of an NSX Edge HA pair to a different vCenter Server system, the two HA appliances will
no longer operate as an HA pair, and you might experience traffic disruption.
Prerequisites
n You must have been assigned the Enterprise Administrator or NSX Administrator role.
VMware, Inc. 79
NSX Administration Guide
n Verify that the resource pool has enough capacity for the edge services gateway (ESG) virtual
appliance to be deployed. See Chapter 1 System Requirements for NSX.
n Verify that the host clusters on which the NSX Edge appliance will be installed are prepared for NSX.
See Prepare Host Clusters for NSX in the NSX Installation Guide.
Procedure
1 In vCenter, navigate to Home > Networking & Security > NSX Edges and click the Add ( ) icon.
2 Select Edge Services Gateway and type a name for the device.
This name appears in your vCenter inventory. The name should be unique across all ESGs within a
single tenant.
Optionally, you can also enter a hostname. This name appears in the CLI. If you do not specify the
host name, the Edge ID, which gets created automatically, is displayed in the CLI.
Optionally, you can enter a description and tenant and enable high availability.
For example:
VMware, Inc. 80
NSX Administration Guide
The password must be at least 12 characters and must follow 3 of the following 4 rules:
4 (Optional) Enable SSH, high availability, automatic rule generation, and FIPS mode, and set the log
level.
If you do not enable automatic rule generation, you must manually add firewall, NAT, and routing
configuration to allow control traffic for certain, NSX Edge services, including as load balancing and
VPN. Auto rule generation does not create rules for data-channel traffic.
By default, SSH and high availability are disabled, and automatic rule generation is enabled.
For example:
VMware, Inc. 81
NSX Administration Guide
5 Select the size of the NSX Edge instance based on your system resources.
The Large NSX Edge has more CPU, memory, and disk space than the Compact NSX Edge, and
supports a larger number of concurrent SSL VPN-Plus users. The X-Large NSX Edge is suited for
environments that have a load balancer with millions of concurrent sessions. The Quad Large NSX
Edge is recommended for high throughput and requires a high connection rate.
Enter the settings for the ESG virtual appliance that will be added to your vCenter inventory. If you do
not add an appliance when you install NSX Edge, NSX Edge remains in an offline mode until you add
an appliance.
If you enabled HA you can add two appliances. If you add a single appliance, NSX Edge replicates its
configuration for the standby appliance and ensures that the two HA NSX Edge virtual machines are
not on the same ESX host even after you use DRS and vMotion (unless you manually vMotion them
to the same host). For HA to work correctly, you must deploy both appliances on a shared datastore.
For example:
7 Select Deploy NSX Edge to add the Edge in a deployed mode. You must configure appliances and
interfaces for the Edge before it can be deployed.
8 Configure interfaces.
If you enter more than one IP address for an interface, you can select the primary IP address. An
interface can have one primary and multiple secondary IP addresses. NSX Edge considers the
primary IP address as the source address for locally generated traffic, for example remote syslog and
operator-initiated pings.
You must add an IP address to an interface before using it on any feature configuration.
Optionally, you can enter the MAC address for the interface.
VMware, Inc. 82
NSX Administration Guide
If you change the MAC address using API call later, you must redeploy the edge after changing the
MAC address.
If HA is enabled, you can optionally enter two management IP addresses in CIDR format. Heartbeats
of the two NSX Edge HA virtual machines are communicated through these management IP
addresses. The management IP addresses must be in the same L2/subnet and be able to
communicate with each other.
Enable proxy ARP if you want to allow the ESG to answer ARP requests intended for other machines.
This is useful, for example, when you have the same subnet on both sides of a WAN connection.
Enable reverse path filtering to verify the reachability of the source address in packets being
forwarded. In enabled mode, the packet must be received on the interface that the router would use
to forward the return packet. In loose mode, the source address must appear in the routing table.
Configure fence parameters if you want to reuse IP and MAC addresses across different fenced
environments. For example, in a cloud management platform (CMP), fencing allow you to run several
cloud instances simultaneous with the same IP and MAC addresses completely isolated or “fenced.”
For example:
VMware, Inc. 83
NSX Administration Guide
VMware, Inc. 84
NSX Administration Guide
The following example shows two interfaces, one attaching the ESG to the outside world through an
uplink portgroup on a vSphere distributed switch and the other attaching the ESG to a logical transit
switch to which a distributed logical router is also attached.
VMware, Inc. 85
NSX Administration Guide
You can edit the MTU value, but it cannot be more than the configured MTU on the interface.
For example:
Caution If you do not configure the firewall policy, the default policy is set to deny all traffic.
By default, logs are enabled on all new NSX Edge appliances. The default logging level is NOTICE. If
logs are stored locally on the ESG, logging may generate too many logs and affect the performance
of your NSX Edge. For this reason, it is recommended that you configure remote syslog servers, and
forward all logs to a centralized collector for analysis and monitoring.
If you enabled high availability, complete the HA section. By default, HA automatically chooses an
internal interface and automatically assigns link-local IP addresses. NSX Edge supports two virtual
machines for high availability, both of which are kept up to date with user configurations. If a
heartbeat failure occurs on the primary virtual machine, the secondary virtual machine state is
VMware, Inc. 86
NSX Administration Guide
changed to active. Thus, one NSX Edge virtual machine is always active on the network. NSX Edge
replicates the configuration of the primary appliance for the standby appliance and ensures that the
two HA NSX Edge virtual machines are not on the same ESX host even after you use DRS and
vMotion. Two virtual machines are deployed on vCenter in the same resource pool and datastore as
the appliance you configured. Local link IP addresses are assigned to HA virtual machines in the NSX
Edge HA so that they can communicate with each other. Select the internal interface for which to
configure HA parameters. If you select ANY for interface but there are no internal interfaces
configured, the UI displays an error. Two Edge appliances are created but since there is no internal
interface configured, the new Edge remains in standby and HA is disabled. Once an internal interface
is configured, HA will get enabled on the Edge appliance. Type the period in seconds within which, if
the backup appliance does not receive a heartbeat signal from the primary appliance, the primary
appliance is considered inactive and the backup appliance takes over. The default interval is 15
seconds. Optionally, you can enter two management IP addresses in CIDR format to override the
VMware, Inc. 87
NSX Administration Guide
local link IP addresses assigned to the HA virtual machines. Ensure that the management IP
addresses do not overlap with the IP addresses used for any other interface and do not interfere with
traffic routing. You should not use an IP address that exists somewhere else on your network, even if
that network is not directly attached to the NSX Edge.
For example:
After the ESG is deployed, go to the Hosts and Clusters view and open the console of the edge virtual
appliance. From the console, make sure you can ping the connected interfaces.
VMware, Inc. 88
NSX Administration Guide
What to do next
When you install an NSX Edge appliance, NSX enables automatic VM startup/shutdown on the host if
vSphere HA is disabled on the cluster. If the appliance VMs are later migrated to other hosts in the
cluster, the new hosts might not have automatic VM startup/shutdown enabled. For this reason, VMware
recommends that when you install NSX Edge appliances on clusters that have vSphere HA disabled, you
should check all hosts in the cluster to make sure that automatic VM startup/shutdown is enabled. See
"Edit Virtual Machine Startup and Shutdown Settings" in vSphere Virtual Machine Administration.
Now you can configure routing to allow connectivity from external devices to your VMs.
You must have a working NSX Edge instance before you can configure routing on it. For information on
setting up NSX Edge, see NSX Edge Configuration.
Procedure
5 To change Equal-cost multi-path routing (ECMP) configuration click Edit next to Routing
Configuration, then do the following .
Option Description
For an Edge Services Gateway To edit ECMP, click Enable or Disable next to ECMP.
ECMP is a routing strategy that allows next-hop packet forwarding to a single destination can occur
over multiple best paths. These best paths can be added statically or as a result of metric calculations
by dynamic routing protocols like OSPF or BGP. Multiple paths for static routes can be added by
providing multiple next hops separated by commas in the Static Routes dialog box. For more
information, see Add a Static Route.
The Edge Services Gateway utilizes Linux network stack implementation, a round-robin algorithm
with a randomness component. After a next hop is selected for a particular source and destination IP
address pair, the route cache stores the selected next hop. All packets for that flow go to the selected
next hop. The default IPv4 route cache timeout is 300 seconds (gc_timeout). If an entry is inactive for
this time, it is eligible to be removed from the route cache. The actual removal happens when
garbage collection timer activates (gc_interval = 60 seconds).
VMware, Inc. 89
NSX Administration Guide
The Logical Router uses an XOR algorithm to determine the next hop from a list of possible ECMP
next hops. This algorithm uses the source and destination IP address on the outgoing packet as
sources of entropy.
Until version 6.1.2, enabling ECMP disabled Distributed Firewall on the Edge Services Gateway
virtual machine. Stateful services such as NAT did not work with ECMP. From NSX vSphere version
6.1.3 onwards, ECMP and Distributed Firewall can work together.
6 To change the Locale ID on a logical router, click Edit next to Routing Configuration. Enter a locale
ID and click OK.
By default, the locale ID is set to the NSX Manager UUID, but you can override it if local egress was
enabled when the universal logical router was created. Locale ID is used to selectively configure
routes in a cross-vCenter NSX or multi-site environment. See Cross-vCenter NSX Topologies for
more information.
a Select an interface from which the next hop towards the destination network can be reached.
c (Optional) Type the locale ID. Locale ID is an option only on universal logical routers.
Choose a value between 1 and 255. The admin distance is used to choose which route to use
when there are multiple routes for a given network. The lower the admin distance, the higher the
preference for the route.
Connected 0
Static 1
External BGP 20
OSPF Intra-Area 30
g Click Save.
VMware, Inc. 90
NSX Administration Guide
a Router ID displays the first uplink IP address of the NSX Edge that pushes routes to the kernel
for dynamic routing.
c Select Enable Logging to save logging information and select the log level.
Note If you have IPSec VPN configured in your environment, you should not use dynamic routing.
What to do next
To delete routing configuration, click Reset. This deletes all routing configurations (default, static, OSPF,
and BGP configurations, as well as route redistribution).
Procedure
Option Description
VMware, Inc. 91
NSX Administration Guide
7 Click OK.
n To import a signed certificate at the global level, click Import in the NSX Manager Virtual
Appliance.
n To import a signed certificate for an NSX Edge, click Actions and select Import Certificate
in the Certificates tab.
c In the Import CSR dialog box, paste the contents of the signed certificate.
d Click OK.
Add a CA Certificate
By adding a CA certificate, you can become an interim CA for your company. You then have the authority
for signing your own certificates.
Procedure
4 Click the Manage tab and then ensure that you are in the Settings tab.
5 Click Certificates.
7 Copy and paste the certificate contents in the Certificate contents text box.
9 Click OK.
VMware, Inc. 92
NSX Administration Guide
To import the server certificate as a certificate that is chained with the intermediary certificate on the NSX
Edge:
Prerequisites
For a certificate chain you need a server certificate and an intermediate certificate.
Procedure
4 Click the Manage tab and then ensure that you are in the Settings tab.
5 Click Certificates.
7 In the Certificates Contents field paste the contents of the server cert.pem file and then append the
content of the .pem file of the intermediary certificate. Both the NSX Server Certificate and the CA
Certificates must be included in the contents. Click OK.
-----BEGIN CERTIFICATE-----
Server cert
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate cert
-----END CERTIFICATE-----
After the certificates are imported the server certificate chained with its intermediary certificates should be
displayed under Certificate Details.
Prerequisites
Verify that you have a CA certificate so that you can sign your own certificates.
Procedure
VMware, Inc. 93
NSX Administration Guide
4 Click the Manage tab and then ensure that you are in the Settings tab.
5 Click Certificates.
b In Common name, type the IP address or fully qualified domain name (FQDN) of the NSX
Manager.
Note that SSL VPN-Plus only supports RSA certificates. VMware recommends RSA for backward
compatibility.
h Click OK.
9 Type the number of days the self sign certificate is valid for.
10 Click OK.
The main benefit of implementing client certificates is that the NSX Edge Load Balancer can ask the client
for its client certificate, and validate it before forwarding its web requests to the backend servers. If a
client certificate is revocated because it has been lost, or the client doesn't work in the company anymore,
NSX Edge will validate the client certificate doesn't belong to the Certification Revocation List.
For more information on generating client certificates, refer to Scenario: SSL Client and Server
Authentication.
VMware, Inc. 94
NSX Administration Guide
When a potential user attempts to access a server, the server allows or denies access based on the CRL
entry for that particular user.
Procedure
4 Click the Manage tab and then ensure that you are in the Settings tab.
5 Click Certificates.
9 Click OK.
FIPS Mode
When you enable the FIPS mode, any secure communication to or from the NSX Edge uses
cryptographic algorithms or protocols that are allowed by United States Federal Information Processing
Standards (FIPS). FIPS mode turns on the cipher suites that comply with FIPS.
If you configure components those are not FIPS compliant on a FIPS enabled edge, or if you enable FIPS
on a edge which has ciphers or authentication mechanism that is not FIPS compliant, NSX Manager will
fail the operation and provide a valid error message.
VMware, Inc. 95
NSX Administration Guide
Caution Changing FIPS mode reboots the NSX Edge appliance causing temporary traffic disruption.
This applies whether or not high availability is enabled.
Depending on your requirements, you can enable FIPS on some or all of your NSX Edge appliances.
FIPS-enabled NSX Edge appliances can communicate with NSX Edge appliances that do not have FIPS
enabled.
If a logical (distributed) router is deployed without an NSX Edge appliance, you cannot modify the FIPS
mode. The logical router automatically gets the same FIPS mode as the NSX Controller cluster. If the
NSX Controller cluster is NSX 6.3.0 or later, FIPS is enabled.
To change FIPS mode on a universal logical (distributed) router in a cross-vCenter NSX environment that
has multiple NSX Edge appliances deployed in the primary and secondary NSX Managers, you must
change FIPS mode on all the NSX Edge appliances associated with the universal logical (distributed)
router on the primary NSX Manager.
If you change FIPS mode on an NSX Edge appliances with high availability enabled, FIPS will be enabled
on both appliances, and the appliances will be rebooted one after the other.
If you want to change FIPS mode for a standalone edge, use the fips enable or fips disable
command. For more information, refer to NSX Command Line Interface Reference.
Prerequisites
n Verify any partner solutions are FIPS mode certified. See the VMware Compatibility Guide at
http://www.vmware.com/resources/compatibility/search.php?deviceCategory=security.
n If you have upgraded from an earlier version of NSX, do not enable FIPS mode until the upgrade to
NSX 6.3.0 is complete. See Understand FIPS Mode and NSX Upgrade in the NSX Upgrade Guide.
n Verify that all host clusters running NSX workloads are prepared with NSX 6.3.0 or later.
n Verify that all NSX Edge appliances are version 6.3.0 or later.
VMware, Inc. 96
NSX Administration Guide
n Verify that the messaging infrastructure has status GREEN. Use the API method
GET /api/2.0/nwfabric/status?resource={resourceId}, where resourceId is the vCenter
Managed Object ID of a host or cluster. Look for the status corresponding to the featureId of
com.vmware.vshield.vsm.messagingInfra in the response body:
<nwFabricFeatureStatus>
<featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
<updateAvailable>false</updateAvailable>
<status>GREEN</status>
<installed>true</installed>
<enabled>true</enabled>
<allowConfiguration>false</allowConfiguration>
</nwFabricFeatureStatus>
Procedure
3 Select the required edge or router, click Actions ( ) and select Change FIPS mode.
What to do next
Managing Appliances
You can add, edit, or delete appliances. An NSX Edge instance remains offline till at least one appliance
has been added to it.
Add an Appliance
You must add at least one appliance to NSX Edge before deploying it.
VMware, Inc. 97
NSX Administration Guide
Procedure
4 Click the Manage tab and then click the Settings tab.
6 Select the cluster or resource pool and datastore for the appliance.
8 (Optional) Select the vCenter folder within which the appliance is to be added.
9 Click Add.
Edit an Appliance
You can edit a NSX Edge appliance.
Procedure
4 Click the Manage tab and then click the Settings tab.
6
Click the Edit ( ) icon.
7 In the Edit Edge Appliance dialog box, make the appropriate changes.
8 Click Save.
Delete an Appliance
You can delete an NSX Edge appliance.
Procedure
4 Click the Manage tab and then click the Settings tab.
VMware, Inc. 98
NSX Administration Guide
An NSX Edge must have at least one internal interface before it can be deployed.
Configure an Interface
Internal interfaces are generally for East-West traffic, while uplink interfaces are for North-South traffic.
An NSX edge services gateway (ESG) can have up to ten internal, uplink, or trunk interfaces. These limits
are enforced by the NSX Manager. When a logical router (DLR) is connected to an edge services
gateway (ESG), the interface on the router is an uplink interface, while the interface on the ESG is an
internal interface. An NSX trunk interface is for internal networks, not external networks. The trunk
interface allows multiple internal networks (either VLAN or VXLAN) to be trunked.
An NSX deployment can have up to 1,000 distributed logical router (DLR) instances on a single ESXi
host. On a single logical router, you can configure up to 8 uplink interfaces, and up to 991 internal
interfaces. These limits are enforced by the NSX Manager. For more information about interface scaling
®
in an NSX deployment, see the VMware NSX for vSphere Network Virtualization Design Guide at
https://communities.vmware.com/docs/DOC-27683.
Note IPv6 multicast addresses are not supported on NSX ESG interfaces in NSX for vSphere 6.2.x and
6.3.x.
Procedure
4 Click the Manage tab and then click the Interfaces tab.
5
Select an interface and click the Edit ( ) icon.
6 In the Edit Edge Interface dialog box, type a name for the interface.
Select Trunk when creating a sub interface. For more information, see Add a Sub Interface.
8 Select the port group or logical switch to which this interface should be connected.
b Depending on what you want to connect to the interface, click the Logical Switch, Standard
Portgroup, or Distributed Portgroup tab.
d Click Select.
VMware, Inc. 99
NSX Administration Guide
10 In Configure Subnets, click the Add ( ) icon to add a subnet for the interface.
If you enter more than one IP address, you can select the Primary IP address. An interface can have
one primary and multiple secondary IP addresses. NSX Edge considers the Primary IP address as
the source address for locally generated traffic.
You must add an IP address to an interface before using it on any feature configuration.
12 Type the subnet mask for the interface and click Save.
Option Description
Enable Proxy ARP Supports overlapping network forwarding between different interfaces.
Reverse Path Filter Verifies the reachability of the source address in packets being forwarded. In
enabled mode, the packet must be received on the interface that the router would
use to forward the return packet. In loose mode, the source address must appear
in the routing table.
16 Click OK.
Delete an Interface
You can delete an NSX Edge interface.
Procedure
4 Click the Manage tab and then click the Interfaces tab.
Enable an Interface
An interface must be enabled for NSX Edge to isolate the virtual machines within that interface (port
group or logical switch).
Procedure
4 Click the Manage tab and then click the Interfaces tab.
Disable an Interface
You can disable an interface on an NSX Edge.
Procedure
4 Click the Manage tab and then click the Interfaces tab.
Procedure
1 Double-click an NSX Edge and navigate to Manage > Settings > Interfaces.
2 Select an interface.
5 Click OK.
Edge
vNic 0 vNic 10
n VLAN trunk is standard and works with any version of ESXi. This is used to bring tagged VLAN traffic
into Edge.
n VXLAN trunk works with NSX version 6.1, and later. This is used to bring VXLAN traffic into Edge.
n DHCP
n Load Balancer
n IPSEC VPN
n L2 VPN
n NAT
. A sub interface cannot be used for HA or Logical Firewall. You can, however, use the IP address of the
sub interface in a firewall rule.
Procedure
1 In the Manage > Settings tab for an NSX Edge, click Interfaces.
2
Select an interface and click the Edit ( ) icon.
3 In the Edit Edge Interface dialog box, type a name for the interface.
5 Select the standard portgroup or distributed portgroup to which this interface should be connected.
b Depending on what you want to connect to the interface, click the Standard Portgroup or
Distributed Portgroup tab.
d Click Select.
7 Click Enable Sub interface and type a name for the sub interface.
The tunnel Id is used to connect the networks that are being stretched. This value must be the same
on both the client and server sites.
9 In Backing Type, select one of the following to indicate the network backing for the sub interface.
Type the VLAN ID of the virtual LAN that your sub interface should use. VLAN IDs can range from
0 to 4094.
Click Select and select the distributed portgroup or logical switch. NSX Manager extracts the
VLAN ID and uses it in trunk configuration.
n None to create a sub interface without specifying a network or VLAN ID. This sub interface is
internal to NSX Edge, and is used to route packets between a stretched network and an
unstretched (untagged) network
10 To add subnets to the sub interface, click the Add icon in the Configure Subnets area.
11 In Add Subnets, click the Add icon to add an IP address. Type the IP address and click OK.
If you enter more than one IP address, you can select the Primary IP address. An interface can have
one primary and multiple secondary IP addresses. NSX Edge considers the Primary IP address as
the source address for locally generated traffic.
13 Edit the default MTU value for the sub interface if required.
The default MTU for a trunk interface is 1600 and the default MTU for a sub interface is 1500. The
MTU for the sub interface should be equal to or less than the lowest MTU among all the trunk
interfaces for the NSX Edge.
Reverse Path Filter verifies the reachability of the source address in packets being forwarded. In
enabled mode, the packet must be received on the interface that the router would use to forward the
return packet. In loose mode, the source address must appear in the routing table.
17 Enter the MAC address for the interface if needed. Enter two MAC addresses if using ESG HA.
The default MTU for a trunk interface is 1600, and the default MTU for a sub interface is 1500. The
MTU for the trunk interface should be equal to or more than the MTU of the sub interface.
19 Click OK.
What to do next
Configure VLAN trunk if the sub interface added to a trunk vNic is backed by standard portgroup. See
Configure VLAN Trunk.
Prerequisites
Verify that a sub interface with a trunk vNic backed by standard portgroup is available. See Add a Sub
Interface.
Procedure
2 Click Networking.
5 In VLAN Type, select VLAN Trunking and type the VLAN IDs to be trunked.
6 Click OK.
Procedure
4 Click the Manage tab and then click the Settings tab. Click Configuration.
5 In the Details panel, click Action ( ) and select Change Auto Rule configuration.
Procedure
4 Click the Manage tab and then click the Settings tab. Click Configuration.
5 In the Details panel, click Action ( ) and select Change CLI Credentials.
For example, NSX Edge HA synchronizes the connection tracker of the statefull firewall, or the statefull
information held by the load balancer. The time required to bring all services backup is not null. Examples
of known service restart impacts include a non-zero downtime with dynamic routing when an NSX Edge is
operating as a router.
Sometimes, the two NSX Edge HA appliances are unable to communicate and unilaterally decide to
become active. This behavior is expected to maintain availability of the active NSX Edge services if the
standby NSX Edge is unavailable. If the other appliance still exists, when the communication is re-
established, the two NSX Edge HA appliances renegotiate active and standby status. If this negotiation
does not finish and if both appliances declare they are active when the connectivity is re-established, an
unexpected behavior is observed. This condition, known as split brain, is observed due to the following
environmental conditions:
n Transient storage problems that might cause at least one NSX Edge HA VM to become unavailable.
For example, an improvement in NSX Edge HA stability and performance is observed when the VMs
are moved off overprovisioned storage. In particular, during large overnight backups, large spikes in
storage latency can impact NSX Edge HA stability.
n Congestion on the physical or virtual network adapter involved with the exchange of packets.
In addition to environmental issues, a split-brain condition is observed when the HA configuration engine
falls into a bad state or when the HA daemon fails.
All NSX Edge services run on the active appliance. The primary appliance maintains a heartbeat with the
standby appliance and sends service updates through an internal interface.
If a heartbeat is not received from the primary appliance within the specified time (default value is 15
seconds), the primary appliance is declared dead. The standby appliance moves to the active state, takes
over the interface configuration of the primary appliance, and starts the NSX Edge services that were
running on the primary appliance. When the switch over takes place, a system event is displayed in the
System Events tab of Settings & Reports. Load Balancer and VPN services need to re-establish TCP
connection with NSX Edge, so service is disrupted for a short while. Logical switch connections and
firewall sessions are synched between the primary and standby appliances however, service is disrupted
during the switch over while waiting for the standby appliance to become active and take over.
If the NSX Edge appliance fails and a bad state is reported, HA force syncs the failed appliance to revive
it. When revived, it takes on the configuration of the now-active appliance and stays in a standby state. If
the NSX Edge appliance is dead, you must delete the appliance and add a new one.
NSX Edge ensures that the two HA NSX Edge virtual machines are not on the same ESX host even after
you use DRS and vMotion (unless you manually vMotion them to the same host). Two virtual machines
are deployed on vCenter in the same resource pool and datastore as the appliance you configured. Local
link IPs are assigned to HA virtual machines in the NSX Edge HA so that they can communicate. You can
specify management IP addresses to override the local links.
If syslog servers are configured, logs in the active appliance are sent to the syslog servers.
If vSphere HA is not leveraged, the active-standby NSX Edge HA pair will survive one fail-over. However,
if another fail-over happens before the second HA pair was restored, NSX Edge availability can be
compromised.
Note In NSX 6.2.3 and later, enabling high availability (HA) 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.
Procedure
4 Click the Manage tab and then click the Settings tab.
6 In the Change HA Configuration dialog box, make changes as explained in the NSX Installation
Guide section, Add an Edge Services Gateway.
Note If L2 VPN is configured on this Edge appliance before HA is enabled, there must be at least
two internal interfaces set up. If there is a single interface configured on this Edge which is already
being used by L2 VPN, HA is disabled on the Edge appliance.
7 Click OK.
Force sync is used when you need to synchronize the edge configuration as known to the NSX Manager
to all of the components.
Note For 6.2 and later, force sync avoids data loss for east-west routing traffic, however, north-south
routing and bridging may experience an interruption.
n If the NSX Manager is primary or stand alone, and the edge is a logical distributed router, then the
controller cluster is synced
n A message is sent to all relevant hosts to sync the distributed router instance
Important In a cross-vCenter NSX environment, it is required that the NSX Edge instance be force
synced first on the primary NSX Manager. When that is complete, force sync theNSX Edge instance on
secondary NSX Managers.
Procedure
Procedure
4 Click the Manage tab, and then click the Settings tab.
6 Type the IP address of both remote syslog servers and select the protocol.
Procedure
5 Select the period for which you want to view the statistics.
What to do next
To view more details about NSX Edge, click Manage and then click Settings.
Note Redeploying is a disruptive action. It is recommended that you first apply a force sync and if the
issue is not fixed, then redeploy.
n Edge appliances are deleted and freshly deployed with the latest configuration applied
n Logical routers are deleted from the controller and then recreated with the latest configuration applied
n Distributed logical router instances on hosts are deleted and then recreated with the latest
configuration applied
OSPF adjacencies are withdrawn during redeploy if graceful restart is not enabled.
Important In a cross-vCenter environment it is required that theNSX Edge instance be redeployed first
on the primary NSX manager and after that is complete, then redeploy the NSX Edge instance on
secondary NSX managers. It is required that both the primary and the secondary NSX managers are
redeployed.
Prerequisites
n Verify the hosts have enough resources to deploy additional NSX Edge Services Gateway appliances
during the redeploy. See the Chapter 1 System Requirements for NSX for the resources required for
each NSX Edge size.
n For a single NSX Edge instance, there are two NSX Edge appliances of the appropriate size in
the poweredOn state during redeploy.
n For an NSX Edge instance with high availability, both replacement appliances are deployed
before replacing the old appliances. This means there are four NSX Edge appliances of the
appropriate size in the poweredOn state during upgrade of a given NSX Edge. Once the NSX
Edge instance is redeployed, either of the HA appliances could become active.
n Verify that the host clusters listed in the configured location and live location for the NSX Edge
appliance are prepared for NSX and that their messaging infrastructure status is GREEN. If the
configured location is not available, for example, because the cluster has been removed since the
NSX Edge appliance was created, then verify the live location only.
n Find the ID of the original configured location (configuredResourcePool > id) and the current live
location (resourcePoolId) with the GET https://NSX-Manager-IP-
Address/api/4.0/edges/{edgeId}/appliances API request.
n Find the host preparation status and the messaging infrastructure status for those clusters with
the GET https://NSX-Manager-IP-Address/api/2.0/nwfabric/status?
resource={resourceId} API request, where resourceId is the ID of the configured and live
location of the NSX Edge appliances found previously.
<nwFabricFeatureStatus>
<featureId>com.vmware.vshield.vsm.nwfabric.hostPrep</featureId>
<featureVersion>6.3.1.5124716</featureVersion>
<updateAvailable>false</updateAvailable>
<status>GREEN</status>
<installed>true</installed>
<enabled>true</enabled>
<allowConfiguration>false</allowConfiguration>
</nwFabricFeatureStatus>
<nwFabricFeatureStatus>
<featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
<updateAvailable>false</updateAvailable
<status>GREEN</status>
<installed>true</installed>
<enabled>true</enabled>
<allowConfiguration>false</allowConfiguration>
</nwFabricFeatureStatus>
Procedure
4
Click the Actions ( ) icon and select Redeploy Edge.
The NSX Edge virtual machine is replaced with a new virtual machine and all services are restored. If
redeploy does not work, power off the NSX Edge virtual machine and redeploy NSX Edge again.
n Resource pool on which the NSX Edge was installed is no longer in the vCenter inventory or its
Managed Object ID (MoId) has changed.
n dvportGroups on which the NSX Edge interfaces were connected are no longer in the vCenter
inventory or their MoId (identifier in vCenter server) has changed.
If any of the above is true, you must update the MoId of the resource pool, datastore, or dvPortGroup
using a REST API call. See NSX API Programming Guide.
If FIPS mode is enabled on NSX Edge and something goes wrong, NSX Manager will not allow to
redeploy the edge. You should try to resolve infrastructure issues for communication failures instead of
redeploying the edge.
Procedure
Procedure
4 Click the Manage tab and then click the Routing tab.
10 For MTU, edit the maximum transmission value for the data packets if required.
The MTU cannot be higher than the MTU set on the NSX Edge interface.
Choose a value between 1 and 255. The admin distance is used to choose which route to use when
there are multiple routes for a given network. The lower the admin distance, the higher the preference
for the route.
Connected 0
Static 1
External BGP 20
OSPF Intra-Area 30
An administrative distance of 255 causes the static route to be excluded from the routing table (RIB)
and the data plane, so the route is not used.
By default, routes have the same locale ID as the NSX Manager. Specifying a locale ID here will
associate the route with this locale ID. These routes will be sent only to hosts that have a matching
locale ID. See Cross-vCenter NSX Topologies for more information.
14 Click OK.
OSPF routing policies provide a dynamic process of traffic load balancing between routes of equal cost.
An OSPF network is divided into routing areas to optimize traffic flow and limit the size of routing tables.
An area is a logical collection of OSPF networks, routers, and links that have the same area identification.
Prerequisites
A Router ID must be configured, as shown in Example: OSPF Configured on the Logical (Distributed)
Router.
When you enable a router ID, the field is populated by default with the logical router's uplink interface.
Procedure
5 Enable OSPF.
a Click Edit at the top right corner of the window and click Enable OSPF
b In Forwarding Address, type an IP address that is to be used by the router datapath module in
the hosts to forward datapath packets.
c In Protocol Address, type a unique IP address within the same subnet as the Forwarding
Address. The protocol address is used by the protocol to form adjacencies with the peers.
c Type an Area ID. NSX Edge supports an area ID in the form of an IP address or decimal number.
NSSAs prevent the flooding of AS-external link-state advertisements (LSAs) into NSSAs. They
rely on default routing to external destinations. Hence, NSSAs must be placed at the edge of an
OSPF routing domain. NSSA can import external routes into the OSPF routing domain, thereby
providing transit service to small routing domains that are not part of the OSPF routing domain.
7 (Optional) Select the type of Authentication. OSPF performs authentication at the area level.
All routers within the area must have the same authentication and corresponding password
configured. For MD5 authentication to work, both the receiving and transmitting routers must have the
same MD5 key.
c MD5: This authentication method uses MD5 (Message Digest type 5 ) encryption. An MD5
checksum is included in the transmitted packet.
d For Password or MD5 type authentication, type the password or MD5 key.
Note
n You cannot configure MD5 authentication when FIPS mode is enabled.
n NSX always uses a key ID value of 1. Any non-NSX device peering with an NSX Edge or
Logical Distributed Router must be configured to use a key ID of value 1 when MD5
authentication is used, or an OSPF session will not be established.
a In Area to Interface Mapping, click the Add icon to map the interface that belongs to the OSPF
area.
b Select the interface that you want to map and the OSPF area that you want to map it to.
In most cases, it is recommended to retain the default OSPF settings. If you do change the settings,
make sure that the OSPF peers use the same settings.
a Hello Interval displays the default interval between hello packets that are sent on the interface.
b Dead Interval displays the default interval during which at least one hello packet must be
received from a neighbor before the router declares that neighbor down.
c Priority displays the default priority of the interface. The interface with the highest priority is the
designated router.
d Cost of an interface displays the default overhead required to send packets across that interface.
The cost of an interface is inversely proportional to the bandwidth of that interface. The larger the
bandwidth, the smaller the cost.
Edge
Services
Gateway
192.168.10.1
Link type: internal
Transit
logical
switch
192.168.10.2
Link type: uplink
Protocol address:
192.168.10.3
Logical
Router
172.16.20.1 172.16.10.1
Link type: internal Link type: internal
App Web
logical logical
switch switch
172.16.20.10 172.16.10.10
App Web
VM VM
In the following screen, the logical router's default gateway is the ESG's internal interface IP address
(192.168.10.1).
The router ID is the logical router's uplink interface---in other words, the IP address that faces the ESG
(192.168.10.2).
The logical router configuration uses 192.168.10.2 as its forwarding address. The protocol address can
be any IP address that is in the same subnet and is not used anywhere else. In this case, 192.168.10.3 is
configured. The area ID configured is 0, and the uplink interface (the interface facing the ESG) is mapped
to the area.
What to do next
Make sure the route redistribution and firewall configuration allow the correct routes to be advertised.
In this example, the logical router's connected routes (172.16.10.0/24 and 172.16.20.0/24) are advertised
into OSPF.
If you enabled SSH when you created the logical router, you must also configure a firewall filter that
allows SSH to the logical router's protocol address. For example:
OSPF routing policies provide a dynamic process of traffic load balancing between routes of equal cost.
An OSPF network is divided into routing areas to optimize traffic flow and limit the size of routing tables.
An area is a logical collection of OSPF networks, routers, and links that have the same area identification.
Prerequisites
A Router ID must be configured, as shown in Example: OSPF Configured on the Edge Services Gateway.
When you enable a router ID, the field is populated by default with the ESG's uplink interface IP address.
Procedure
3 Double-click an ESG.
5 Enable OSPF.
a Click Edit at the top right corner of the window and click Enable OSPF
b (Optional) Click Enable Graceful Restart for packet forwarding to be un-interrupted during
restart of OSPF services.
c (Optional) Click Enable Default Originate to allow the ESG to advertise itself as a default
gateway to its peers.
c Type an Area ID. NSX Edge supports an area ID in the form of an IP address or decimal number.
NSSAs prevent the flooding of AS-external link-state advertisements (LSAs) into NSSAs. They
rely on default routing to external destinations. Hence, NSSAs must be placed at the edge of an
OSPF routing domain. NSSA can import external routes into the OSPF routing domain, thereby
providing transit service to small routing domains that are not part of the OSPF routing domain.
7 (Optional) If you select type as NSSA, the NSSA Translator Role field appears. Select the Always
check box to translate Type-7 LSAs to Type-5 LSAs. All Type-7 LSAs are translated into Type-5 LSAs
by the NSSA.
8 (Optional) Select the type of Authentication. OSPF performs authentication at the area level.
All routers within the area must have the same authentication and corresponding password
configured. For MD5 authentication to work, both the receiving and transmitting routers must have the
same MD5 key.
c MD5: This authentication method uses MD5 (Message Digest type 5 ) encryption. An MD5
checksum is included in the transmitted packet.
d For Password or MD5 type authentication, type the password or MD5 key.
Note
n You cannot configure MD5 authentication when FIPS mode is enabled.
n NSX always uses a key ID value of 1. Any non-NSX device peering with an NSX Edge or Logical
Distributed Router must be configured to use a key ID of value 1 when MD5 authentication is
used, or an OSPF session will not be established.
a In Area to Interface Mapping, click the Add icon to map the interface that belongs to the OSPF
area.
b Select the interface that you want to map and the OSPF area that you want to map it to.
In most cases, it is recommended to retain the default OSPF settings. If you do change the settings,
make sure that the OSPF peers use the same settings.
a Hello Interval displays the default interval between hello packets that are sent on the interface.
b Dead Interval displays the default interval during which at least one hello packet must be
received from a neighbor before the router declares that neighbor down.
c Priority displays the default priority of the interface. The interface with the highest priority is the
designated router.
d Cost of an interface displays the default overhead required to send packets across that interface.
The cost of an interface is inversely proportional to the bandwidth of that interface. The larger the
bandwidth, the smaller the cost.
12 Make sure that the route redistribution and firewall configuration allow the correct routes to be
advertised.
The ESG can be connected to the outside world through a bridge, a physical router (or as shown here)
through an uplink portgroup on a vSphere distributed switch.
Edge vSphere
Services Distributed Physical
192.168.100.3 Architecture
Gateway Link type: uplink Switch 192.168.100.1
192.168.10.1
Link type: internal
Transit
logical
switch
192.168.10.2
Link type: uplink
Protocol address:
192.168.10.3
Logical
Router
172.16.20.1 172.16.10.1
Link type: internal Link type: internal
App Web
logical logical
switch switch
172.16.20.10 172.16.10.10
App Web
VM VM
In the following screen, the ESG's default gateway is the ESG's uplink interface to its external peer.
The router ID is the ESG's uplink interface IP address---in other words, the IP address that faces its
external peer.
The area ID configured is 0, and the internal interface (the interface facing the logical router) is mapped to
the area.
The connected routes are redistributed into OSPF so that the OSPF neighbor (the logical router) can
learn about the ESG's uplink network.
Note Additionally, OSPF can be configured between the ESG and its external peer router, but more
typically this link uses BGP for route advertisement.
Make sure that the ESG is learning OSPF external routes from the logical router.
To verify connectivity, make sure that an external device in the physical architecture can ping the VMs.
For example:
Configure BGP
Border Gateway Protocol (BGP) makes core routing decisions. It includes a table of IP networks or
prefixes, which designate network reachability among multiple autonomous systems.
An underlying connection between two BGP speakers is established before any routing information is
exchanged. Keepalive messages are sent by the BGP speakers in order to keep this relationship alive.
After the connection is established, the BGP speakers exchange routes and synchronize their tables.
Procedure
5 Click Edit.
7 Click Enable Graceful Restart for packet forwarding to be un-interrupted during restart of BGP
services.
8 Click Enable Default Originate to allow NSX Edge to advertise itself as a default gateway to its
peers.
9 Type the router ID in Local AS. Type the Local AS. This is advertised when BGP peers with routers in
other autonomous systems (AS). The path of ASs that a route traverses is used as one metric when
selecting the best path to a destination.
10 Click OK.
When you configure BGP peering between an edge services gateway (ESG) and a logical router, use
the logical router's protocol IP address as the ESG's BGP neighbor address.
The forwarding address is the IP address that you assigned to the distributed logical router's interface
facing its BGP neighbor (its uplink interface).
The protocol address is the IP address that the logical router uses to form a BGP neighbor
relationship. It can be any IP address in the same subnet as the forwarding address (as long as it is
not used anywhere else). When you configure BGP peering between an edge services gateway
(ESG) and a logical router, use the logical router's protocol IP address as the ESG neighbor's IP
address.
17 Hold Down Timer displays interval (180 seconds) after not receiving a keep alive message that the
software declares a peer dead. Edit if required.
18 Keep Alive Timer displays the default frequency (60 seconds) with which the software sends
keepalive messages to its peer. Edit if required.
19 If authentication is required, type the authentication password. Each segment sent on the connection
between the neighbors is verified. MD5 authentication must be configured with the same password on
both BGP neighbors, otherwise, the connection between them will not be made.
20 To specify route filtering from a neighbor, click the Add icon in the BGP Filters area.
21 Select the direction to indicate whether you are filtering traffic to or from the neighbor.
22 Select the action to indicate whether you are allowing or denying traffic.
23 Type the network in CIDR format that you want to filter to or from the neighbor.
AS 64511
ESG
DLR
192.168.10.3
(protocol address)
AS 64512
In this topology, the ESG is in AS 64511. The logical router (DLR) is in AS 64512.
The logical router's forwarding address is 192.168.10.2. This is the address configured on the logical
router's uplink interface. The logical router's protocol address is 192.168.10.3. This is the address that the
ESG will use to form its BGP peering relationship with the logical router.
The ESG's neighbor address is 192.168.10.3, which is the logical router's protocol address.
Run the show ip bgp neighbors command on the logical router, and make sure the BGP state is
Established.
Run the show ip bgp neighbors command on the ESG, and make sure the BGP state is Established.
You can exclude an interface from route redistribution by adding a deny criterion for its network. From
NSX 6.2, the HA (management) interface of a logical (distributed) router is automatically excluded from
route redistribution.
Procedure
6 Select the protocols for which you enable route redistribution and click OK.
7 Add an IP prefix.
The IP prefix entered is exactly matched, except if you include less-than-or-equal-to (LE) or
greater-than-or-equal-to (GE) modifiers.
c LE and GE together specify a range of prefix lengths that the rule must match. You can add IP
prefix GE as minimum prefix length to be matched and IP prefix LE as maximum prefix length to
be matched.
You can use these two options individually or in conjunction. Value for LE and GE cannot be zero
or greater than 32. GE value cannot be greater than LE value. For example,
n If you provide a prefix as 10.0.0.0/16 and LE = 28, then the redistribution rule matches all
prefixes ranging from 10.0.0.0/16 to 10.0.0.0/28. It means that the rule matches all prefix
lengths from 16 to 28. Prefix 10.0.2.0/24 is matched.
n If you provide a prefix as 10.0.0.0/16 and GE = 24, then the redistribution rule matches all
prefixes ranging from 10.0.0.0/24 to 10.0.0.0/32. Prefix 10.0.0.16/28 is matched.
n If you provide GE = 24 and LE = 28, then the redistribution rule matches all prefixes ranging
from 10.0.0.0/24 to 10.0.0.0/28. Prefix 10.0.0.32/27 is matched.
d Click OK.
c In Learner Protocol, select the protocol that is to learn routes from other protocols.
d In Allow Learning from, select the protocols from which routes should be learned.
f Click OK.
Procedure
1 In the vSphere Web Client, click Networking & Security > NSX Home.
3 From the NSX Manager drop-down menu, select the IP address of the NSX Manager. The ID field
contains the UUID of the NSX Manager.
See Cross-vCenter NSX Topologies for information on routing configurations for cross-vCenter NSX
environments.
Prerequisites
The universal logical (distributed) router must have been created with local egress enabled.
Procedure
Prerequisites
The universal logical (distributed) router that performs routing for the hosts or clusters must have been
created with local egress enabled.
Procedure
2 Click Networking & Security and then click Installation and Upgrade.
4 Select the NSX Manager that manages the hosts or clusters you need to configure.
5 Select the host or cluster you want to modify, expanding clusters to display hosts if needed.
6
Click the Settings icon ( ) and click Change Locale ID.
The universal controller cluster will send only routes matching this new locale ID to the hosts.
What to do next
n Edge Firewall
n Firewall Logs
Distributed Firewall
Distributed firewall is a hypervisor kernel-embedded firewall that provides visibility and control for
virtualized workloads and networks.
You can create access control policies based on VMware vCenter objects like datacenters and clusters
and virtual machine names; network constructs like IP or IPSet addresses, VLAN (DVS port-groups),
VXLAN (logical switches), security groups, as well as user group identity from Active Directory. Firewall
rules are enforced at the vNIC level of each virtual machine to provide consistent access control even
when the virtual machine gets vMotioned.
The NSX Distributed firewall is a stateful firewall, meaning it monitors the state of active connections and
uses this information to determine which network packets to allow through the firewall. A flow is identified
by the following:
n Source address
n Source port
n Destination address
n Destination port
n Protocol
A distributed firewall instance on an ESXi host (one instance per virtual machine vNIC) contains two
tables: a rule table to store all policy rules and a connection tracker table to cache flow entries for rules
with permit action. DFW rules are enforced in top-to-bottom ordering. Traffic that needs to go through a
firewall is first matched against a firewall rules list. Each packet is checked against the top rule in the rule
table before moving down the subsequent rules in the table. The first rule in the table that matches the
traffic parameters is enforced. The last rule in the table is the DFW default policy rule: packets not
matching any rule above the default rule will be enforced by the default rule.
By default, the NSX Distributed Firewall operates in strict TCP mode and when using a default block rule,
it drops packets that do not satisfy connection requirements. A connection begins with a three way
handshake (SYN, SYN-ACK, ACK) and typically end with a two way exchange (FIN, ACK)
For example, if an IP packet(first packet, pkt1) flow 3, that matches rule number 2 is sent by the VM the
following policy lookup and packet flow take place:
1 Lookup is performed in the connection tracker table to check if an entry for the flow already exists
2 Because flow 3 is not present in the connection tracker table (i.e miss result), a lookup is performed in
the rule table to identify which rule is applicable to flow 3. The first rule that matches the flow will be
enforced.
4 Because the Action is set to ‘Allow’ for flow 3, a new entry will be created inside the connection
tracker table. The packet is then transmitted out of the distributed firewall.
For L2 packets, distributed firewall creates a cache for performance boost. L3 packets are processed in
the following sequence:
1 All packets are checked for an existing state. This is done for SYNs too so that bogus or retransmitted
SYNs for existing sessions can be detected.
3 If a state match is not found, the packet is processed through the rules until a match is found.
n For TCP packets, a state is set only for packets with a SYN flag. However, rules that do not
specify a protocol (service ANY), can match TCP packets with any combination of flags.
n For UDP packets, 5-tuple details are extracted from the packet. If a state does not exist in the
state table, a new state is created using the extracted 5-tuple details. Subsequently received
packets are matched against the state that was just created.
n For ICMP packets, ICMP type, code, and packet direction are used to create a state.
Distributed firewall can help in creating identity-based rules as well. Administrators can enforce access
control based on the user's group membership as defined in the enterprise Active Directory. Here are
some scenarios where identity-based firewall rules can be used:
n User accessing virtual applications using a laptop or mobile device where AD is used for user
authentication
n User accessing virtual applications using VDI infrastructure where the virtual machines are Microsoft
Windows based
If you have a third-party vendor firewall solution deployed in your environment, see Redirecting Traffic to
a Vendor Solution through Logical Firewall.
Context-Aware Firewall
Context- aware firewall enhances the visibility at the application level and helps to override the problem of
application permeability. Visibility at the application layer helps you to monitor the workloads better from a
resource, compliance, and security point of view.
Firewall rules cannot consume application IDs. Context-aware firewall identifies applications and enforces
a micro-segmentation for EAST-WEST traffic, independent of the port that the application uses. Context-
aware or application-based firewall rules can be defined by defining Layer 7 service objects. After defining
Layer 7 service objects in rules, you can define rules with specific protocol, ports, and their application
definition. Rule definition can be based on more than 5-tuples. You can also use Application Rule
Manager to create context-aware firewall rules.
Context-aware firewall is only supported for NSX for vSphere 6.4 and above.
All clusters in existing NSX managed infrastructure must be upgraded to NSX 6.4, or above.
Types of Firewall
Firewall can take action based on one or a combination of different L2, L3, L4, and L7 packet headers
that are added to the data as it moves through each layer of the TCP/IP model.
Application Layer
Distributed Firewall
+ Presentation Layer Application L7
Third Party Layer
Session Layer
In layer 3 or layer 4 firewall, the action is taken solely based on source/destination IP, port, and protocol.
The activity of network connections is also tracked. This type of firewall is known as a stateful firewall.
Layer 7 firewall is also called as a context-aware firewall. Layer 7 or context-aware firewall can do
everything that the layer 3 and layer 4 firewall do. Also, it can intelligently inspect the content of the
packets. For example, a layer 7 firewall rule can be written to deny all HTTP requests from a specific IP
address.
Rule processing
and revalidation Flow Rule
Index 2 Index 1
Entry ID
Flow not
Packet 1 Rule 1
1 Flow 1 found
2 Flow 2 2 Rule 2
5 tuple
3 Flow 3 3 Rule 3
When a context-aware firewall is configured for the virtual machine, the Distributed Deep Packet
Inspection (DPI) attributes must also be matched with the 5-tuples. This is where rules are processed and
validated again and the correct rule is found. Depending on the action, a flow is created or dropped.
n All the rules are processed normally until a matching context or non-context rule is found. At this
stage, only 5-tuples are matched. If the matching rule is a non-context one, the state is attached to it
and rule processing is marked as complete.
n If an L4 part of the context rule is hit, packets are punted to the vDPI process to determine the
protocol of the application ID where the flow is already created by the DFW filter. A state is also
attached here depending on the movement of the previous packet, which is now marked as DPI
under progress.
n Once the protocol of application ID is determined, the punt is moved to copy mode, where vDPI only
observes and sets other attributes only if necessary. Rule revalidation starts here.
n Because new attributes are discovered though the application ID, the rules must be revalidated
beginning from the rule that was attached. This must be done until a similar rule is found, which
matches all application ID attributes. Here, the new rule is anchored and an action is taken to accept
or drop the packet depending on the action defined in the rule.
It is possible to have a context-aware firewall rule exactly like an L3 or L4 rule, without really defining the
context. If that is the case, the validation step might be performed to apply the context, which might have
more attributes.
Management
Plane
User Control
World Agent Plane (vsfwd)
User Space
Kernel Space
Datapath VSIP
Module
Session Timers
Session Timers can be configured for TCP, UDP, and ICMP sessions.
Session Timers define how long a session is maintained on the firewall after inactivity. When the session
timeout for the protocol expires, the session closes.
On the firewall, a number of timeouts for TCP, UDP, and ICMP sessions can be specified to apply to a
user-defined subset of virtual machines or vNICs. By default, any virtual machines or vNICs not included
in the user-defined timer are included in the global session timer. All of these timeouts are global,
meaning they apply to all of the sessions of that type on the host.
Default session values can be modified depending on your network needs. Note that setting a value too
low could cause frequent timeouts, and setting a value too high could delay failure detection.
On the firewall, you can define timeouts for TCP, UDP, and ICMP sessions for a set of user defined VMs
or vNICS. The default timer is global, meaning that it applies to all virtual machines protected by firewall .
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
2 Ensure that you are in the Settings tab. If there is more than one NSX Manager available, select one
from the drop-down list.
The Add a Timeout Configuration dialogue box appears, populated with the default values.
4 Enter a name (required) and a description (optional) for the session timer.
5 Select the protocol. Accept the default values or enter your own values.
First Packet The timeout value for the connection after the first packet has been sent. The default is 120 seconds.
Open The timeout value for the connection after a second packet has been transferred. The default is 30 seconds.
Established The timeout value for the connection once the connection has become fully established.
Closing The timeout value for the connection after the first FIN has been sent. The default is 120 seconds.
Fin Wait The timeout value for the connection after both FINs have been exchanged and the connection is closed.
The default is 45 seconds.
Closed The timeout value for the connection after one endpoint sends an RST. The default is 20 seconds.
First Packet The timeout value for the connection after the first packet is sent. This will be the initial timeout for the new
UDP flow. The default is 60 seconds.
Single The timeout value for the connection if the source host sends more than one packet and the destination host
has not sent one back. The default is 30 seconds.
Multiple The timeout value for the connection if both hosts have sent packets. The default is 60 seconds.
First Packet The timeout value for the connection after the first packet is sent. This is the initial timeout for the new ICMP
flow. The default is 20 seconds.
Error reply The timeout value for the connection after an ICMP error is returned in response to an ICMP packet. The
default is 10 seconds.
7 Select one or more objects and click the arrow to move them to the Selected Objects column.
8 Click OK.
After a session timer has been created it can be changed as needed. The default session timer can also
be edited.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
2 Ensure that you are in the Settings tab. If there is more than one NSX Manager available, select one
from the drop-down list.
3 Select the timer you want to edit. Note that the default timer values can also be edited. Click the
pencil icon.
The Edit a Timeout Configuration dialogue box appears, populated with the default values.
4 Enter a name (required) and a description (optional) for the session timer.
5 Select the protocol. Edit any default values that you want to change.
First Packet The timeout value for the connection after the first packet has been sent. The default is 120 seconds.
Open The timeout value for the connection after a second packet has been transferred. The default is 30 seconds.
Established The timeout value for the connection once the connection has become fully established.
Closing The timeout value for the connection after the first FIN has been sent. The default is 120 seconds.
Fin Wait The timeout value for the connection after both FINs have been exchanged and the connection is closed.
The default is 45 seconds.
Closed The timeout value for the connection after one endpoint sends an RST. The default is 20 seconds.
First Packet The timeout value for the connection after the first packet is sent. This will be the initial timeout for the new
UDP flow. The default is 60 seconds.
Single The timeout value for the connection if the source host sends more than one packet and the destination host
has not sent one back. The default is 30 seconds.
Multiple The timeout value for the connection if both hosts have sent packets. The default is 60 seconds.
First Packet The timeout value for the connection after the first packet is sent. This is the initial timeout for the new ICMP
flow. The default is 20 seconds.
Error reply The timeout value for the connection after an ICMP error is returned in response to an ICMP packet. The
default is 10 seconds.
7 Select one or more objects and click the arrow to move them to the Selected Objects column.
8 Click OK.
VMware recommends that you install VMware Tools on each virtual machine in your environment. In
addition to providing vCenter with the IP address of VMs, it provides many other functions:
n collecting network, disk, and memory usage from the VM and sending it to the host
Note that having two vNICs for a VM on the same network is not supported and can lead to unpredictable
results around which traffic is blocked or allowed.
For those VMs that do not have VMware Tools installed, NSX will learn the IP address through ARP or
DHCP snooping, if ARP and DHCP snooping is enabled on the VM's cluster.
Procedure
1 In the vSphere Web client, navigate to Networking & Security > Installation and Upgrade > Host
Preparation.
2
Click the cluster you want to change, then click Actions ( ) > Change IP Detection Type.
What to do next
Configure SpoofGuard.
NSX Manager, NSX Controllers, and NSX Edge virtual machines are automatically excluded from NSX
distributed firewall protection. In addition, VMware recommends that you place the following service
virtual machines in the Exclusion List to allow traffic to flow freely.
n vCenter Server. It can be moved into a cluster that is protected by Firewall, but it must already exist in
the exclusion list to avoid connectivity issues.
Note It is important to add the vCenter Server to the exclusion list before changing the "any any"
default rule from allow to block. Failure to do so will result in access to the vCenter Server being
blocked after creating a Deny All rule (or modifying default rule to block action). If this occurs, roll
back the DFW to the default firewall rule set by running the following API command:
https://NSX_Manager_IP/api/4.0/firewall/globalroot-0/config. The request must return a
status of 204. This restores the default policy (with a default rule of allow) for DFW and re-enables
access to vCenter Server and the vSphere Web Client.
n Virtual machines that require promiscuous mode. If these virtual machines are protected by NSX
distributed firewall, their performance may be adversely affected.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
5 Select the virtual machines that you want to exclude and click Add.
6 Click OK.
If a virtual machine has multiple vNICs, all of them are excluded from protection. If you add vNICs to a
virtual machine after it has been added to the Exclusion List, Firewall is automatically deployed on the
newly added vNICs. In order to exclude these vNICs from firewall protection, you must remove the virtual
machine from the Exclusion List and then add it back to the Exclusion List. An alternative workaround is
to power cycle (power off and then power on) the virtual machine, but the first option is less disruptive.
Knowing the host resource utilization at any given time can help you in better organizing your server
utilization and network designs.
The default CPU threshold is 100, and the memory threshold is 100. You can modify the default threshold
values through REST API calls. The Firewall module generates system events when the memory and
CPU usage crosses the thresholds. For information on configuring default threshold values, see Working
with Memory and CPU Thresholds in the NSX API Guide.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Events.
Each ESXi host is configured with three threshold parameters for DFW resource utilization: CPU, RAM,
and connections per second (CPS). An alarm is raised if the respective threshold is crossed 20
consecutive times during a 200-second period. A sample is taken every 10 seconds.
100 percent of CPU corresponds to the total CPU available on the host.
100 percent of RAM corresponds to the memory allocated for distributed firewall ("total max size"), which
is dependent on the total amount of RAM installed in the host.
0 - 8GB 160
128GB 4222
The memory is used by distributed firewall internal data structures, which include filters, rules, containers,
connection states, discovered IPs, and drop flows. These parameters can be manipulated using the
following API call:
https://NSX-MGR-IP/api/4.0/firewall/stats/eventthresholds
Request body:
<eventThresholds>
<cpu>
<percentValue>100</percentValue>
</cpu>
<memory>
<percentValue>100</percentValue>
</memory>
<connectionsPerSecond>
<value>100000</value>
</connectionsPerSecond>
</eventThresholds>
Edge Firewall
Edge Firewall monitors North-South traffic to provide perimeter security functionality including firewall,
Network Address Translation (NAT) as well as site-to-site IPSec and SSL VPN functionality. This solution
is available in the virtual machine form factor and can be deployed in a High Availability mode.
Firewall support is limited on the Logical Router. Only the rules on management and/or uplink interfaces
work, however, the rules on internal interfaces do not work.
Note NSX-V Edge is vulnerable to Syn-Flood attacks, where an attacker fills the firewall state tracking
table by flooding SYN packets. This DOS/DDOS attack creates a service disruption to genuine users.
Edge must defend from Syn-Flood attacks by implementing logic to detect bogus TCP connections and
terminate them without consuming Firewall state tracking resources. This feature is disabled by default.
To enable this feature in a high risk environment, set the REST API enableSynFloodProtection value
to 'true' as part of the Firewall Global Configuration.
Firewall rules applied to a Logical Router only protect control plane traffic to and from the Logical Router
control virtual machine. They do not enforce any data plane protection. To protect data plane traffic,
create Logical Firewall rules for East-West protection or rules at the NSX Edge Services Gateway level
for North-South protection.
Rules created on the Firewall user interface applicable to this NSX Edge are displayed in a read-only
mode. Rules are displayed and enforced in the following order:
2 Auto-plumbed rules (rules that enable control traffic to flow for Edge services).
a SSL VPN auto-plumb rule: The Edge Firewall tab displays the sslvpn auto-plumb rule when
server settings are configured and SSL VPN service is enabled.
b DNAT auto-plumb rule: The Edge NAT tab displays the DNAT auto-plumb rule as part of default
SSL VPN configuration.
4 Default rule.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > NSX Edges.
4 Select the Default Rule, which is the last rule in the firewall table.
5
Point to the Action cell of the new rule and click .
a Click Accept to allow traffic from or to the specified source and destination.
d Click OK.
You can add multiple NSX Edge interfaces and/or IP address groups as the source and destination for
firewall rules.
Figure 10‑2. Firewall rule for traffic to flow from an NSX Edge interface to an HTTP server
Figure 10‑3. Firewall rule for traffic to flow from all internal interfaces (subnets on
portgroups connected to internal interfaces) of a NSX Edge to an HTTP Server
Note If you select internal as the source, the rule is automatically updated when you configure
additional internal interfaces.
Figure 10‑4. Firewall rule for traffic to allow SSH into a m/c in internal network
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > NSX Edges.
3 Click the Manage tab and then click the Firewall tab.
Option Description
a Select an object from the drop-down and then make the appropriate selections.
If you select vNIC Group and then select vse, the rule applies to traffic generated by the NSX
Edge. If you select internal or external, the rule applies to traffic coming from any internal or
uplink interface of the selected NSX Edge instance. The rule is automatically updated when you
configure additional interfaces. Note that firewall rules on internal interfaces do not work for a
Logical Router.
If you select IP Sets, you can create a new IP address group. After you create the new group, it is
automatically added to the source column. For information on creating an IP Set, see Create an
IP Address Group.
b Click OK.
a Select an object from the drop-down and then make the appropriate selections.
If you select vNIC Group and then select vse, the rule applies to traffic generated by the NSX
Edge. If you select internal or external, the rule applies to traffic going to any internal or uplink
interface of the selected NSX Edge instance. The rule is automatically updated when you
configure additional interfaces. Note that firewall rules on internal interfaces do not work for a
Logical Router.
If you select IP Sets, you can create a new IP address group. After you create the new group, it is
automatically added to the source column. For information on creating an IP Set, see Create an
IP Address Group.
b Click OK.
n If you clicked , select a service. To create a new service or service group, click New. After you
create the new service, it is automatically added to the Service column. For more information on
creating a new service, see Create a Service.
n
If you clicked , select a protocol. You can specify the source port by clicking the arrow next to
Advanced options. VMware recommends that you avoid specifying the source port from release
5.1 and later. Instead, you can create a service for a protocol-port combination.
10 Point to the Action cell of the new rule and click . Make appropriate selections as described in the
table below and click OK.
Log Logs all sessions matching this rule. Enabling logging can affect performance.
Advanced options > Match on Applies the rule to the translated IP address and services for a NAT rule
Translated
11 Click Publish Changes to push the new rule to the NSX Edge instance.
What to do next
n
Disable a rule by clicking next to the rule number in the No. column.
n Hide generated rules or pre rules (rules added on the centralized Firewall tab) by clicking Hide
Generated rules or Hide Pre rules.
n
Display additional columns in the rule table by clicking and selecting the appropriate columns.
Stats
Clicking shows the traffic affected by this rule (number of sessions, traffic packets, and size)
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > NSX Edges.
3 Click the Manage tab and then click the Firewall tab.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > NSX Edges.
3 Click the Manage tab and then click the Firewall tab.
4 Select the rule for which you want to change the priority.
Note You cannot change the priority of auto-generated rules or the default rule.
6 Click OK.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > NSX Edges.
3 Click the Manage tab and then click the Firewall tab.
The NAT service configuration is separated into source NAT (SNAT) and destination NAT (DNAT) rules.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > NSX Edges.
3 Click the Manage tab, and then click the NAT tab.
7 Type the original source (public) IP address in one of the following formats.
Format Example
IP address 192.0.2.0
IP address/subnet 192.0.2.0/24
any
Format Example
Port number 80
any
Format Example
IP address 192.0.2.0
any
Format Example
Port number 80
any
Format Example
IP address 192.0.2.0
IP address/subnet 192.0.2.0/24
any
Format Example
Port number 80
any
Procedure
4 Click the Manage tab, and then click the NAT tab.
Format Example
IP address 192.0.2.0
any
Format Example
Port number 80
any
Format Example
IP address 192.0.2.0
any
Format Example
Port number 80
any
Format Example
IP address 192.0.2.0
any
Format Example
Port number 80
any
NAT64 supports communications initiated by the IPv6-only node towards an IPv4-only node only.
n TCP
n UDP
n ICMP
The translation of IPv4options, IPv6 routing headers, hop-by-hop extension headers, destination option
headers, and source routing headers is not supported. FTP is not supported. Fragmented packets are not
supported.
NSX Edge high availability is not supported with NAT64. NAT64 sessions are not synced between active
and standby appliances, so if a failover occurs, connectivity is interrupted.
If you have dynamic routing protocols configured, IPv4 prefixes are redistributed.
TCP-ESTABLISHED 2 hours
TCP-Trans 4 minutes
UDP 5 minutes
ICMP 1 minute
Prerequisites
n Configure an uplink interface of the Edge Services Gateway with an address on the IPv6 network.
n Configure an internal interface of the Edge Services Gateway with an address on the IPv4 network.
n Ensure that these addresses are not duplicated anywhere else in your environment
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > NSX Edges.
3 Click the Manage tab, and then click the NAT tab.
Option Description
Match IPv6 Destination Prefix IPv6 address used to map IPv6 destinations to IPv4 destinations.
Specify an IPv6 CIDR. Prefix length must be 32, 40, 48, 56, 64, or 96.
The IPv4 destination address is appended to this network. For example, if the
prefix is 64:ff9b::/96, and the destination IPv4 IP is 120.1.1.3, the IPv6 destination
is 64:ff9b::7801:0103 (7801:0103 is 120.1.1.3 in hex).
You can use the well-known prefix defined in RFC 6052: 64:ff9b::/96, or use any
other IPv6 CIDR that is not already in use in your environment. You can use a
network or an IP address.
Translated IPv4 Source Prefix IPv4 address used to translate an IPv6 source address into an IPv4 source
address.
Specify an IPv4 CIDR.
The translated IPv4 source address is assigned from this network. For example, if
the prefix is 10.10.10.0/24, the source address might be 10.10.10.5.
You can use any IPv4 CIDR that is not already in use in your environment, or
optionally use the shared address defined in RFC 6598: 100.64.0.0/10. You can
use a network or an IP address.
You can create multiple firewall rule sections for L2 and L3 rules.
Cross-vCenter NSX environments can have multiple universal rule sections. Multiple universal sections
allow rules to be easily organized per tenant and application. If rules are modified or edited within a
universal section, only the universal distributed firewall rules for that section are synced to the secondary
NSX Managers. You must manage universal rules on the primary NSX Manager, and you must create the
universal section there before you can add universal rules. Universal sections are always listed above
local sections on both primary and secondary NSX Managers.
Rules outside the universal sections remain local to the primary or secondary NSX Managers on which
they are added.
Prerequisites
n In a standalone or single vCenter NSX environment there is only one NSX Manager so you do not
need to select one.
n Objects local to an NSX Manager must be managed from that NSX Manager.
n In a cross-vCenter NSX environment that does not have Enhanced Linked Mode enabled, you must
make configuration changes from the vCenter linked to the NSX Manager that you want to modify.
n In a cross-vCenter NSX environment in Enhanced Linked Mode, you can make configuration changes
to any NSX Manager from any linked vCenter. Select the appropriate NSX Manager from the NSX
Manager drop-down menu.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
2 If there is more than one NSX Manager available, select one. You must select the Primary NSX
Manager to add a universal section.
3 Ensure that you are in the Configuration > General tab to add a section for L3, L4, or L7 rules. Click
the Ethernet tab to add a section for L2 rules.
4
Click the Add Section ( ) icon.
5 Type a name for the section and specify the position for the new section. Section names must be
unique within NSX Manager.
Option Description
Enable User Identity at Source When using Identity Firewall for RDSH, Enable User Identity
at Source must be checked. Note that this disables the
enable stateless firewall option because the TCP connection
state is tracked for identifying the context.
Enable TCP Strict Enables you to set TCP strict for each firewall section.
Enable Stateless Firewall Enables stateless firewall for each firewall section.
7 (Optional) To create a universal section, select Mark this section for Universal Synchronization.
What to do next
Add rules to the section. You can edit the name of a section by clicking the Edit section ( ) icon for that
section.
Merging and consolidating a complex firewall configuration can help with maintenance and readability.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
2
For the section you want to merge, click the Merge ( ) icon and specify whether you want to merge
this section with the section above or below.
Rules from both sections are merged. The new section keeps the name of the section with which the
other section is merged.
You cannot delete a section and add it again at a different place in the firewall table. To do so, you must
delete the section and publish the configuration. Then add the deleted section to the firewall table and re-
publish the configuration.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
2 Ensure that you are in the Configuration > General tab to delete a section for L3 rules. Click the
Ethernet tab to delete a section for L2 rules.
3 Click the Delete section ( ) icon for the section you want to delete.
Each traffic session is checked against the top rule in the Firewall table before moving down the
subsequent rules in the table. The first rule in the table that matches the traffic parameters is enforced.
Rules are displayed in the following order:
1 Rules defined in the Firewall user interface by users have the highest priority, and are enforced in top-
to-bottom ordering with a per-virtual NIC level precedence.
2 Auto-plumbed rules (rules that enable control traffic to flow for Edge services).
4 Service Composer rules - a separate section for each policy. You cannot edit these rules in the
Firewall table, but you can add rules at the top of a security policy firewall rules section. If you do so,
you must re-synchronize the rules in Service Composer. For more information, see Chapter 18
Service Composer.
Note that firewall rules are enforced only on clusters on which you have enabled firewall. For information
on preparing clusters, see the NSX Installation Guide.
The following vCenter objects can be specified as the source or destination for a firewall rule:
Prerequisites
Make sure the state of NSX distributed firewall is not in backward compatibility mode. To check the
current state, use the REST API call GET https://<nsxmgr-ip>/api/4.0/firewall/globalroot-0/state. If the
current state is backward compatibility mode, you can change the state to forward by using the REST API
call PUT https://<nsxmgr-ip>/api/4.0/firewall/globalroot-0/state. Do not try to publish a distributed firewall
rule while the distributed firewall is in backward compatibility mode.
If you are adding universal firewall rules, see Add a Universal Firewall Rule
n One or more domains have been registered with NSX Manager. NSX Manager gets group and user
information as well as the relationship between them from each domain that it is registered with. See
Register a Windows Domain with NSX Manager.
n A security group based on Active Directory objects has been created which can be used as the
source or destination of the rule. See Create a Security Group.
If you are adding a rule for remote desktop access ensure that:
n The Applied to field is not supported for rules for remote desktop access.
If you are adding a rule based on a VMware vCenter object, ensure that VMware Tools is installed on the
virtual machines. See NSX Installation Guide.
VMs that are migrated from 6.1.5 to 6.2.3 do not have support for TFTP ALG. To enable TFTP ALG
support after migrating, add and remove the VM from the exclusion list or restart the VM. A new 6.2.3
filter is created, with support for TFTP ALG.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
2 Ensure that you are in the Configuration > General tab to add an L3, L4, or L7 rule. Click the
Ethernet tab to add an L2 rule.
3 In the section in which you add a rule, click Add rule ( ) icon.
A new any allow rule is added at the top of the section. If the system-defined rule is the only rule in
the section, the new rule is added above the default rule.
If you want to add a rule at a specific place in a section, select a rule. In the No. column, click and
select Add Above or Add Below.
7 Point to the Source cell of the new rule. Additional icons are displayed as described in the table
below.
Option Description
To specify source as an IP address.
Click
a Select the IP address format.
You can enter multiple IP addresses in a comma-separated list. The list can
contain up to 255 characters.
You can create a new security group or IPSet. Once you create the new
object, it is added to the source column by default. For information on
creating a new security group or IPSet, see Chapter 22 Network and Security
Objects.
c To exclude a source from the rule, click Advanced options.
d Select Negate Source to exclude this source from the rule.
If Negate Source is selected, the rule is applied to traffic coming from all
sources except for the source you specified in the previous step.
If Negate Source is not selected, the rule applies to traffic coming from the
source you specified in the previous step.
e Click OK.
8 Point to the Destination cell of the new rule. Additional icons are displayed as described in the table
below.
Option Description
To specify destination as an IP address.
Click
a Select the IP address format.
You can enter multiple IP addresses in a comma-separated list. The list can
contain up to 255 characters.
You can create a new security group or IPSet. Once you create the new
object, it is added to the Destination column by default. For information on
creating a new security group or IPSet, see Chapter 22 Network and Security
Objects.
c To exclude a destination port, click Advanced options.
d Select Negate Destination to exclude this destination from the rule.
If Negate Destination is not selected, the rule applies to traffic going to the
destination you specified in the previous step.
e Click OK.
9 Point to the Service cell of the new rule. Additional icons are displayed as described in the table
below.
Option Description
Note: VMs that are migrated from 6.1.5 to 6.2.3 do not have support for TFTP
ALG. To enable TFTP ALG support after migrating, add and remove the VM
from the exclusion list or restart the VM. A new 6.2.3 filter is created, with
support for TFTP ALG.
b Type the port number and click OK.
You can create a new service or service group. Once you create the new
object, it is added to the Selected Objects column by default.
b Click OK.
In order to protect your network from ACK or SYN floods, you can set Service to TCP-all_ports or
UDP-all_ports and set Action to Block for the default rule. For information on modifying the default
rule, see Edit the Default Distributed Firewall Rule.
10 Point to the Action cell of the new rule and click . Make appropriate selections as described in the
table below and click OK.
Action Results in
Allow Allows traffic from or to the specified source(s), destination(s), and service(s).
Block Blocks traffic from or to the specified source(s), destination(s), and service(s).
Log Logs all sessions matching this rule. Enabling logging can affect performance.
11 In Applied To, define the scope at which this rule is applicable. Make appropriate selections as
described in the table below and click OK. Note that if you adding a rule for remote desktop access,
the Applied To field is not supported.
All prepared clusters in your environment Select Apply this rule on all clusters on which Distributed
Firewall is enabled. After you click OK, the Applied To
column for this rule displays Distributed Firewall.
All NSX Edge gateways in your environment Select Apply this rule on all Edge gateways. After you click
OK, the Applied To column for this rule displays All Edges.
If both the above options are selected, the Applied To column
displays Any.
One or more cluster, datacenter, distributed virtual port group, 1 In Container type, select the appropriate object..
NSX Edge, network, virtual machine, vNIC, or logical switch 2 In the Available list, select one or more objects and click
If the rule contains virtual machines/vNICS in the source and destination fields, you must add both the
source and destination virtual machines/vNICS to Applied To for the rule to work correctly.
After a few moments, a message indicating whether the publish operation was successful is
displayed. In case of any failures, the hosts on which the rule was not applied are listed. For
additional details on a failed publish, navigate to NSX Managers > NSX_Manager_IP_Address >
Monitor > System Events.
When you click Publish Changes, the firewall configuration is automatically saved. For information
on reverting to an earlier configuration, see Load a Saved Firewall Configuration.
What to do next
n
Disable a rule by clicking , or enable a rule by clicking .
n
Display additional columns in the rule table by clicking and selecting the appropriate columns.
Stats
Clicking shows the traffic related to this rule (traffic packets and size)
n Merge sections by clicking the Merge section icon and selecting Merge with above section or
Merge with below section.
The default Distributed Firewall rule allows all L3 and L2 traffic to pass through all prepared clusters in
your infrastructure. The default rule is always at the bottom of the rules table and cannot be deleted or
added to. However, you can change the Action element of the rule from Allow to Block or Reject, add
comments for the rule, and indicate whether traffic for that rule should be logged.
In a cross-vCenter NSX environment the default rule is not a universal rule. Any changes to the default
rule must be made on each NSX Manager.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
You can only edit Action and Log, or add comments to the default rule.
Force sync is used when you need to synchronize the firewall rules on an individual host with the NSX
Manager.
Procedure
1 In the vSphere Web client, navigate to Networking & Security > Installation and Upgrade > Host
Preparation.
2
Select the cluster you want to force sync, then click Actions ( ) > Force Sync Services.
The primary NSX Manager can contain multiple universal sections for universal L2 rules and multiple
universal sections for universal L3 rules. Universal sections are on top of all local and service composer
sections. Universal sections and universal rules can be viewed but not edited on the secondary NSX
Managers. The placement of the universal section with respect to the local section does not interfere with
rule precedence.
n universal MAC set n universal security group, which can n pre-created universal services and
n universal IP set contain a universal security tag, IP service groups
set, MAC set, or universal security n user created universal services and
n universal security group, which can
group services groups
contain a universal security tag, an IP
set, MAC set, or universal security n universal logical switch
group n Distributed Firewall - applies rules on
all clusters on which Distributed
Firewall is installed
Note that other vCenter objects are not supported for universal rules.
Prerequisites
You must create a universal rule section before you can create universal rules. See Add a Firewall Rule
Section.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
3 Ensure that you are in the Configuration > General tab to add an L3 universal rule. Click the
Ethernet tab to add an L2 universal rule.
4 In the universal section click the Add rule ( ) icon and then click Publish Changes.
A new any any allow rule is added at the top of the universal section.
5
Point to the Name cell of the new rule and click . Type a name for the rule.
6 Point to the Source cell of the new rule. Additional icons are displayed as described in the table
below.
Option Description
To specify source as an IP address.
Click
a Select the IP address format.
You can create a new security group or IPSet. Once you create the new
object, it is added to the source column by default. For information on
creating a new security group or IPSet, see Chapter 22 Network and Security
Objects.
c To exclude a source from the rule, click Advanced options.
d Select Negate Source to exclude this source from the rule.
If Negate Source is selected, the rule is applied to traffic coming from all
sources except for the source you specified in the previous step.
If Negate Source is not selected, the rule applies to traffic coming from the
source you specified in the previous step.
e Click OK.
7 Point to the Destination cell of the new rule. Additional icons are displayed as described in the table
below.
Option Description
To specify destination as an IP address.
Click
a Select the IP address format.
You can create a new security group or IPSet. Once you create the new
object, it is added to the Destination column by default. For information on
creating a new security group or IPSet, see Chapter 22 Network and Security
Objects.
c To exclude a destination from the rule, click Advanced options.
d Select Negate Destination to exclude this destination from the rule.
If Negate Destination is not selected, the rule applies to traffic going to the
destination you specified in the previous step.
e Click OK.
8 Point to the Service cell of the new rule. Additional icons are displayed as described in the table
below.
Option Description
You can create a new service or service group. Once you create the new
object, it is added to the Selected Objects column by default.
b Click OK.
In order to protect your network from ACK or SYN floods, you can set Service to TCP-all_ports or
UDP-all_ports and set Action to Block for the default rule. For information on modifying the default
rule, see Edit the Default Distributed Firewall Rule.
9
Point to the Action cell of the new rule and click . Make appropriate selections as described in the
table below and click OK.
Action Results in
Allow Allows traffic from or to the specified source(s), destination(s), and service(s).
Block Blocks traffic from or to the specified source(s), destination(s), and service(s).
Log Logs all sessions matching this rule. Enabling logging can affect performance.
10 In Applied To cell, either accept the default setting, Distributed Firewall, to apply the rule on all
clusters with Distributed Firewall enabled, or click the edit icon to select the universal logical
switches on which the rule is to be applied to.
The universal rule is replicated on all secondary NSX Managers. The Rule ID stays the same across all
NSX instances. To display the Rule ID, click and then click Rule ID.
Universal rules can be edited on the primary NSX Manager and are read only on secondary NSX
Managers.
Firewall rules with Universal Section Layer3 and Default Section Layer3:
What to do next
n
Disable a rule by clicking in the No. column, or enable a rule by clicking .
n
Display additional columns in the rule table by clicking and selecting the appropriate columns.
Stats
Clicking shows the traffic related to this rule (traffic packets and size)
A firewall rule with a custom protocol number can be created on the distributed firewall or the NSX Edge
firewall.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
2 Ensure that you are in the Configuration > General tab to add an L3 rule. Click the Add rule ( )
icon.
A new any allow rule is added at the top of the section. If the system-defined rule is the only rule in
the section, the new rule is added above the default rule.
If you want to add a rule at a specific place in a section, select a rule. In the No. column, click and
select Add Above or Add Below.
6 Specify theSource of the new rule. See Add a Distributed Firewall Rule for icon details.
7 Specify the Destination of the new rule. See Add a Distributed Firewall Rule for details.
8 Point to the Service cell of the new rule. Click the Add Service ( ) icon
9 Click New Service on the bottom left of the Specify Service window.
13 Click OK.
Procedure
3 Type a name and description for the configuration and click OK.
NSX can save up to 100 configurations. After this limit is exceeded, saved configurations marked with
Preserve Configuration are preserved, while older non-preserved configurations are deleted to
make room for preserved configurations.
n Click Revert Changes to go back to the configuration that existed before you added the rule.
When you want to publish the rule you just added, click the Load Configuration icon, select the
rule that you saved in step 3 and click OK.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Firewall.
2 Ensure that you are in the Configuration > General tab to load an L3 firewall configuration. Click the
Ethernet tab to load an L2 firewall configuration.
3
Click the Load configuration ( ) icon.
What to do next
If Service Composer rules in your configuration were overridden by the loaded configuration, click
Actions > Synchronize Firewall Rules in the Security Policies tab within Service Composer.
Rules can be filtered by source or destination virtual machines or IP address, rule action, logging, rule
name, comments, and rule ID. You can also filter rules based on a specific service, application, or a
protocol.
Procedure
1
In the Firewall tab, click the Apply Filter ( ) icon.
3 Click Apply.
What to do next
To display all rules again, click the Remove applied filter ( ) icon.
1 User-defined pre rules have the highest priority and are enforced in top-to-bottom ordering with a per-
virtual NIC level precedence.
2 Auto-plumbed rules.
4 Service Composer rules - a separate section for each policy. You cannot edit these rules in the
Firewall table, but you can add rules at the top of a security policy firewall rules section. If you do so,
you must re-synchronize the rules in Service Composer. For more information, see Chapter 18
Service Composer.
You can move a custom rule up or down in the table. The default rule is always at the bottom of the table
and cannot be moved.
Procedure
1 In the Firewall tab, select the rule that you want to move.
Procedure
Table 10‑5. Firewall Rule Behavior with RDSH and Non-RDSH Sections
Enable User Identity Security Group Identity Security Group (RDSH Any Security Group (Non-RDSH
(RDSH Section) Section) Section)
Source - SID based rules are preemptively Source - IP based rules Source - IP based rules
pushed to hypervisor. Rule enforcement is
on the first packet.
Applied To with Identity based Security Group - Applied to all hosts User based Applied To
Applied To with Non-Identity based Security Group - User based Applied to User based Applied to
Firewall Logs
Firewall generates and stores log files, such as audit log, rules message log, and system event log. You
must configure a syslog server for each cluster that has enabled the firewall . The syslog server is
specified in the Syslog.global.logHost attribute.
Rules message logs Include all access decisions such as permitted or /var/log/dfwpktlogs.log
denied traffic for each rule if logging was enabled for
that rule. Contains DFW packet logs for the rules
where logging has been enabled.
Data Plane/VMKernel logs Capture activities related to a firewall kernel module /var/log/vmkernel.log
(VSIP). It include log entries for messages
generated by the system.
Note The vsm.log file can be accessed by running the show log manager command from the
NSX Manager Command Line Interface (CLI) and performing grep for the keyword vsm.log. This file is
accessible only to the user or user group having the root privilege.
# more /var/log/dfwpktlogs.log
2015-03-10T03:22:22.671Z INET match DROP domain-c7/1002 IN 242 UDP 192.168.110.10/138-
>192.168.110.255/138
# more /var/log/dfwpktlogs.log
2017-04-11T21:09:59.877Z ESXi_FQDN dfwpktlogs: 50047 INET TERM domain-c1/1001 IN TCP RST
10.1.2.3/33491->10.4.5.6/10001 22/14 7684/1070
More examples:
n RULE_TAG is an example of the text that you add in the Tag text box while adding or editing the
firewall rule.
The following tables explain the text boxes in the firewall log message.
Timestamp 2017-04-11T21:09:59
Firewall-specific portion 877Z ESXi_FQDN dfwpktlogs: 50047 INET TERM domain-c1/1001 IN TCP RST
10.1.2.3/33491->10.4.5.6/10001 22/14 7684/1070
Filter hash A number that can be used to get the filter name and other information.
1 Ensure that you are in the General tab. Enable the Log column on the Networking & Security >
Security > Firewall page.
2 Enable logging for a rule by hovering over the Log table cell and clicking the pencil icon.
Note If you want customized text to be displayed in the firewall log message, you can enable the Tag
column and add the required text by clicking the pencil icon.
System event logs include Distributed Firewall configuration applied, filter created, deleted, or failed, and
virtual machines added to security groups, and so on. These logs are stored
in /home/secureall/secureall/logs/vsm.log.
To view the audit and system event logs in the vSphere Web Client, navigate to Networking & Security
> System > Events. In the Monitor tab, select the IP address of the NSX Manager.
n Use Case 1: Don, the IT director of a team instructs his NSX administrator to restrict ALL HTTP traffic
for a particular VM. Don wants to restrict this traffic irrespective of the port it comes from.
n Use Case 2: Robert, the IT lead of a team wants to restrict the HTTP traffic to a particular VM on the
condition that the traffic does not come from TCP port 8080.
n Use Case 3: Now that there is a context-aware firewall, it can be extended to identity-based logins as
well, such that an Active Directory user when logged into his virtual desktop, will only be able to
access HTTP requests from port 8080. A manager wants his employee John to be able to access
HTTP only from port 8080, and only when John is logged in to the Active Directory.
Parameter Option
Layer Layer7
App ID HTTP
Parameter Option
Protocol TCP
Destination port 80
With the context-aware firewall rule, only traffic that is allowed is Web traffic on port 80.
Parameter Option
Layer Layer7
App ID SSH
Protocol TCP
With the context-aware firewall rule, only traffic that is allowed is SSH traffic on any port.
A high level overview of the IDFW configuration workflow begins with preparing the infrastructure. This
includes the administrator installing the host preparation components on each protected cluster, and
setting up Active Directory synchronization so that NSX can consume AD users and groups. Next, IDFW
must know which desktop an Active Directory (AD) user logs onto in order to apply DFW rules. There are
two methods IDFW uses for logon detection: Guest Introspection (GI) and/or the Active Directory Event
Log Scraper. Guest Introspection is deployed on ESXi clusters where IDFW virtual machines are running.
When network events are generated by a user, a guest agent installed on the VM forwards the
information through the Guest Introspection framework to the NSX Manager. The second option is the
Active Directory event log scraper. Configure the Active Directory event log scraper in the NSX Manager
to point at an instance of your Active Directory domain controller. NSX Manager will then pull events from
the AD security event log. You can use both in your environment, or one or the other. When both the AD
log scraper and Guest Introspection are used, Guest Introspection will take precedence. Note that if both
the AD event log scraper and Guest Introspection are used, the two are mutually exclusive: if one of
these stops working, the other does not begin to work as a back up.
Once the infrastructure is prepared, the administrator creates NSX Security Groups and adds the newly
available AD Groups (referred to as Directory Groups). The administrator can then create Security
Policies with associated firewall rules and apply those policies to the newly created Security Groups.
Now, when a user logs into a desktop, the system will detect that event along with the IP address which is
being used, look up the firewall policy that is associated with that user, and push those rules down. This
works for both physical and virtual desktops. For physical desktops, AD event log scraper is also required
to detect that a user is logged into a physical desktop.
Identity firewall can be used for micro-segmentation with remote desktop sessions (RDSH), enabling
simultaneous logins by multiple users, user application access based on requirements, and the ability to
maintain independent user environments. Identity Firewall with remote desktop sessions requires Active
Directory.
For supported Windows operating systems see Identity Firewall Tested and Supported Configurations.
Note that Linux based operating systems are not supported for Identity Firewall.
User-based distributed firewall rules are determined by membership in an Active Directory (AD) group
membership. IDFW monitors where AD users are logged in, and maps the login to an IP Address, which
is used by DFW to apply firewall rules. Identity Firewall requires either guest introspection framework or
active directory event log scraping. You can use both in your environment, or one or the other. When both
the AD log scraper and Guest Introspection are used, Guest Introspection will take precedence. Note that
if both the AD event log scraper and Guest Introspection are used, the two are mutually exclusive: if one
of these stops working, the other does not begin to work as a back up.
AD group membership changes do not immediately take effect for logged in users using RDSH Identity
Firewall rules, this includes enabling and disenabling users, and deleting users. For changes to take
effect, users must log off and then log back on. We recommend AD administrators force a log off when
group membership is modified. This behavior is a limitation of Active Directory.
Note Identity Firewall for RDSH is only supported with Windows Server 2016.
Procedure
1 Configure Active Directory Sync in NSX, see Synchronize a Windows Domain with Active Directory.
This is required to use Active Directory groups in Service Composer.
2 Prepare the ESXi cluster for DFW. See Prepare the Host Cluster for NSX in the NSX Installation
Guide.
3 Configure Identity Firewall logon detection options. One or both of these options must be configured.
Note If you have a multi-domain AD architecture, and the log scrapper isn't accessible due to
security constraints, use Guest Introspection to generate login and logout events.
n Configure Active Directory event log access. See Register a Windows Domain with NSX
Manager.
n Windows Guest OS with guest agent installed. This comes with a complete installation of
VMware Tools ™. Deploy Guest Introspection service to protected clusters. See Install Guest
Introspection on Host Clusters. For troubleshooting Guest Introspection, see Collecting Guest
Introspection Troubleshooting Data.
Windows Server 2016 Yes. Note that for IDFW with RDSH only Windows Server 2016
is supported
Domain sync with single subtree of OUs with level hierarchy 6.4.0 and later
Delete and re-add same domain with selective OU 6.4.0 and later
n VM IP address change
n The event log queue for incoming login events is limited, and login events are not received if the log is
full.
For more information about domain synchronization see Synchronize a Windows Domain with Active
Directory.
Linux Support No
n GI framework must be deployed to every cluster where IDFW VMs are running.
n UDP sessions are not supported. Networking events are not generated for UDP sessions on Guest
VMs.
Table 12‑5. Single forest, single domain and nesting of Active Directory groups and user
configurations
Scenarios Supported?
n A user login event is processed only when a tcp session is initiated from guest VM.
n No user logout event is sent/processed, system enforce rules for new user when tcp session by that
new user login (after the logout).
n Multi-user support is available with NSX 6.4.0 and later. The system does not distinguish between
users for enforcing the identity firewall rules in case multi-user logs in to a Guest VM.
Once NSX Manager retrieves AD credentials, you can create security groups based on user identity,
create identity-based firewall rules, and run Activity Monitoring reports.
Important Any changes made in Active Directory will NOT be seen on NSX Manager until a delta or full
sync has been performed.
The domain account must have AD read permission for all objects in the domain tree. The event log
reader account must have read permissions for security event logs.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Users and Domains.
2 Click the Domains tab, and then click the Add domain ( ) icon.
3 In the Add Domain dialog box, enter the fully qualified domain name (for example, eng.vmware.com)
and netBIOS name for the domain.
To retrieve the netBIOS name for your domain, type nbtstat -n in a command window on a
Windows workstation that is part of a domain or on a domain controller. In the NetBIOS Local Name
Table, the entry with a <00> prefix and type Group is the netBIOS name.
5 During sync, to filter out users that no longer have active accounts click Ignore disabled users .
6 Click Next.
7 In the LDAP Options page, specify the domain controller that the domain is to be synchronized with
and select the protocol. See Identity Firewall Tested and Supported Configurationsfor more
information about supported domain synchronization options.
9 Enter the user credentials for the domain account. This user must be able to access the directory tree
structure.
10 Click Next.
11 (Optional) In the Security Event Log Access page, select either CIFS or WMI for the connection
method to access security event logs on the specified AD server. Change the port number if required.
This step is used by Active Directory Event Log Scraper. See Identity Firewall Workflow.
Note The event log reader looks for events with the following IDs from the AD Security event log:
Windows 2008/2012: 4624, Windows 2003: 540. The event log server has a limit of 128 MB. When
this limit is reached you may see Event ID 1104 in the Security Log Reader. See
https://technet.microsoft.com/en-us/library/dd315518 for more information.
12 Select Use Domain Credentials to use the LDAP server user credentials. To specify an alternate
domain account for log access, un-select Use Domain Credentials and specify the user name and
password.
The specified account must be able to read the security event logs on the Domain Controller specified
in step 10.
13 Click Next.
15 Click Finish.
Attention
n If an error message appears stating that the Adding Domain operation failed for the entity
because of a domain conflict, select Auto Merge. The domains will be created and the settings
displayed below the domain list.
The domain is created and its settings are displayed below the domain list.
What to do next
Verify that login events on the event log server are enabled.
You can add, edit, delete, enable, or disable LDAP servers by selecting the LDAP Servers tab in the
panel below the domain list. You can perform the same tasks for event log servers by selecting the Event
Log Servers tab in the panel below the domain list. Adding more than one Windows server (Domain
Controllers, Exchange servers, or File Servers) as an event log server improves the user identity
association.
Through the vSphere Web Client UI, you can perform a force sync for Active Directory domains. A
periodic sync is automatically performed once a week, and a delta sync every 3 hours. It is not possible to
selectively sync sub-trees through the UI.
With NSX 6.4 and later it is possible to selectively sync active directory sub trees using API calls. The root
domain cannot have any parent-child relationships and must have a valid directory distinguished name.
n /api/1.0/directory/updateDomain has an options to specify the folder under root domain. And
there is an option to perform a force update private boolean forceUpdate .
n /api/directory/verifyRootDN. Verify that the list of rootDN doesn't have any parent-child
relationships. Verify each rootDN is a valid active directory distinguished name.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Users and Domains.
2 Click the Domains tab, and then select the domain to be synchronized.
Important Any changes made in Active Directory will NOT be seen on NSX Manager until a delta or
full sync has been performed.
Click To
Perform a delta synchronization, where local AD objects that changed since the
last synchronization event are updated
Perform a full synchronization, where the local state of all AD objects is updated
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Users and Domains.
After creating a new user account, you must enable read-only security log access on a Windows 2008
server-based domain section to grant the user read-only access.
Note You must perform these steps on one Domain Controller of the domain, tree, or forest.
Procedure
1 Navigate to Start > Administrative Tools > Active Directory Users and Computers.
2 In the navigation tree, expand the node that corresponds to the domain for which you want to enable
security log access.
3 Under the node that you just expanded, select the Builtin node.
5 Select the Members tab in the Event Log Readers Properties dialog box.
7 If you previously created a group for the “AD Reader” user, select that group in the Select Users,
Contacts, Computers, or Groups dialog. If you created only the user and you did not create a group,
select that user in the Select Users, Contacts, Computers, or Groups dialog.
What to do next
After you have enabled security log access, verify directory privileges by following the steps in Verifying
Directory Privileges.
After you have created a new account and enabled security log access, you must verify the ability to read
the security logs.
Prerequisites
Enable security log access. See Enable Security Read-Only Log Access on Windows 2008.
Procedure
1 From any workstation that is part of the domain, log on to the domain as an administrator.
3 Select Connect to Another Computer... from the Action menu. The Select Computer dialog box
appears. (Note that you must do this even if you are already logged on to the machine for which you
plan to view the event log.)
5 In the text field adjacent to the Another computer radio button, enter the name of the Domain
Controller. Alternatively, click the Browse... button and then select the Domain Controller.
7 Click the Set User... button. The Event Viewer dialog box appears.
8 In the User name field, enter the user name for the user that you created.
9 In the Password field, enter the password for the user that you created
10 Click OK
11 Click OK again.
13 Under the Windows Logs node, select the Security node. If you can see log events then the account
has the required privileges.
You create a SpoofGuard policy for specific networks that allows you to authorize the IP addresses
reported by VMware Tools and alter them if necessary to prevent spoofing. SpoofGuard inherently trusts
the MAC addresses of virtual machines collected from the VMX files and vSphere SDK. Operating
separately from Firewall rules, you can use SpoofGuard to block traffic determined to be spoofed.
SpoofGuard supports both IPv4 and IPv6 addresses. The SpoofGuard policy supports multiple IP
addresses assigned to a vNIC when using VMwareTools and DHCP snooping. If ARP snooping is
enabled, multiple IP addresses are not supported. The SpoofGuard policy monitors and manages the IP
addresses reported by your virtual machines in one of the following modes.
Automatically Trust IP This mode allows all traffic from your virtual machines to pass while building
Assignments On Their a table of vNIC-to-IP address assignments. You can review this table at
First Use your convenience and make IP address changes. This mode automatically
approves all IPv4 and IPv6 addresses that are first seen on a vNIC.
Manually Inspect and This mode blocks all traffic until you approve each vNIC-to-IP address
Approve All IP assignment. In this mode, multiple IPv4 address can be approved.
Assignments Before
Use
Note SpoofGuard inherently allows DHCP requests regardless of enabled mode. However, if in manual
inspection mode, traffic does not pass until the DHCP-assigned IP address has been approved.
SpoofGuard includes a system-generated default policy that applies to port groups and logical networks
not covered by the other SpoofGuard policies. A newly added network is automatically added to the
default policy until you add the network to an existing policy or create a new policy for it.
SpoofGuard is one of the ways that an NSX distributed firewall policy can determine the IP address of a
virtual machine. For information, see IP Discovery for Virtual Machines.
n Approve IP Addresses
n Edit an IP Address
n Clear an IP Address
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > SpoofGuard.
Option Description
Automatically Trust IP Assignments on Select this option to trust all IP assignments upon initial registration with the NSX
Their First Use Manager.
Manually Inspect and Approve All IP Select this option to require manual approval of all IP addresses. All traffic to and
Assignments Before Use from unapproved IP addresses is blocked.
6 Click Allow local address as valid address in this namespace to allow local IP addresses in your
setup.
When you power on a virtual machine and it is unable to connect to the DHCP server, a local IP
address is assigned to it. This local IP address is considered valid only if the SpoofGuard mode is set
to Allow local address as valid address in this namespace. Otherwise, the local IP address is
ignored.
7 Click Next.
8 To specify the scope for the policy, click Add and select the networks, distributed port groups, or
logical switches that this policy should apply to.
A port group or logical switch can belong to only one SpoofGuard policy.
What to do next
You can edit a policy by clicking the Edit icon and delete a policy by clicking the Delete icon.
Approve IP Addresses
If you set SpoofGuard to require manual approval of all IP address assignments, you must approve IP
address assignments to allow traffic from those virtual machines to pass.
Procedure
Option Description
Active Virtual NICs Since Last List of IP addresses that have been validated since the policy was last updated
Published
Virtual NICs IP Required Approval IP address changes that require approval before traffic can flow to or from these
virtual machines
Virtual NICs with Duplicate IP IP addresses that are duplicates of an existing assigned IP address within the
selected datacenter
Inactive Virtual NICs List of IP addresses where the current IP address does not match the published
IP address
Unpublished Virtual NICs IP List of virtual machines for which you have edited the IP address assignment but
have not yet published
n To approve multiple IP addresses, select the appropriate vNICs and then click Approve Detected
IP(s).
Edit an IP Address
You can edit the IP address assigned to a MAC address to correct the assigned IP address.
Note SpoofGuard accepts a unique IP address from virtual machines. However, you can assign an IP
address only once. An approved IP address is unique across NSX. Duplicate approved IP addresses are
not allowed.
Procedure
Option Description
Active Virtual NICs Since Last List of IP addresses that have been validated since the policy was last updated
Published
Virtual NICs IP Required Approval IP address changes that require approval before traffic can flow to or from these
virtual machines
Virtual NICs with Duplicate IP IP addresses that are duplicates of an existing assigned IP address within the
selected datacenter
Inactive Virtual NICs List of IP addresses where the current IP address does not match the published
IP address
Unpublished Virtual NICs IP List of virtual machines for which you have edited the IP address assignment but
have not yet published
3 For the appropriate vNIC, click the Edit icon and make appropriate changes.
4 Click OK.
Clear an IP Address
You clear an approved IP address assignment from a SpoofGuard policy.
Procedure
Option Description
Active Virtual NICs Since Last List of IP addresses that have been validated since the policy was last updated
Published
Virtual NICs IP Required Approval IP address changes that require approval before traffic can flow to or from these
virtual machines
Virtual NICs with Duplicate IP IP addresses that are duplicates of an existing assigned IP address within the
selected datacenter
Inactive Virtual NICs List of IP addresses where the current IP address does not match the published
IP address
Unpublished Virtual NICs IP List of virtual machines for which you have edited the IP address assignment but
have not yet published
n To clear multiple IP addresses, select the appropriate vNICs and then click Clear Approved
IP(s).
You must have a working NSX Edge instance before you can use VPN. For information on setting up
NSX Edge, see NSX Edge Configuration.
n L2 VPN Overview
Admin NSX
Manager
Corporate LAN
Remote users
connecting through
web access mode
P Windows
Internet VPN V Server
NSX Edge
SSL VPN
external
n Mac OS X Tiger, Leopard, Snow Leopard, Lion, Mountain Lion, Maverick, and Yosemite. These can
be installed either manually or using the Java installer.
n Linux - TCL-TK is required for UI to work. If not present, Linux client can be used using CLI.
For information about troubleshooting SSL VPNs, see NSX Troubleshooting Guide.
Prerequisites
The SSL VPN gateway requires port 443 to be accessible from external networks and the SSL VPN client
requires the NSX Edge gateway IP and port 443 to be reachable from client system.
Procedure
1 In the SSL VPN-Plus tab, Server Settings from the left panel.
2 Click Change.
4 Edit the port number if required. This port number is required to configure the installation package.
Note Backward compatibility issue may occur with some browsers if any of the following GCM
cipher is configured at SSL VPN server:
n AES128-GCM-SHA256
n ECDHE-RSA-AES128-GCM-SHA256
n ECDHE-RSA-AES256-GCM-SHA38
6 (Optional) From the Server Certificates table, select the server certificate that you want to add.
7 Click OK.
Add an IP Pool
The remote user is assigned a virtual IP address from the IP pool that you add.
Procedure
1 In the SSL Vpn-Plus tab, select IP Pools from the left panel.
5 Type the IP address which is to add the routing interface in the NSX Edge gateway.
10 Type the connection-specific DNS suffix for domain based host name resolution.
12 Click OK.
Procedure
1 In the SSL VPN-Plus tab, select Private Networks from the left panel.
6 Specify whether you want to send private network and internet traffic over the SSL VPN-Plus enabled
NSX Edge or directly to the private server by bypassing the NSX Edge.
7 If you selected Send traffic over the tunnel, select Enable TCP Optimization to optimize the
internet speed.
Conventional full-access SSL VPNs tunnel sends TCP/IP data in a second TCP/IP stack for
encryption over the internet. This results in application layer data being encapsulated twice in two
separate TCP streams. When packet loss occurs (which happens even under optimal internet
conditions), a performance degradation effect called TCP-over-TCP meltdown occurs. In essence,
two TCP instruments are correcting a single packet of IP data, undermining network throughput and
causing connection timeouts. TCP Optimization eliminates this TCP-over-TCP problem, ensuring
optimal performance.
8 When optimization is enabled, specify the port numbers for which traffic should be optimized.
Traffic for remaining ports for that specific network will not be optimized.
Note Traffic for all ports are optimized, if port numbers are not specified.
When TCP traffic is optimized, the TCP connection is opened by the SSL VPN server on behalf of the
client. Because the TCP connection is opened by the SSLVPN server, the first automatically
generated rule is applied, which allows all connections opened from the Edge to get passed. Traffic
that is not optimized will be evaluated by the regular Edge firewall rules. The default rule is allow any
any.
10 Click OK.
What to do next
Add Authentication
Instead of a local user, you can add an external authentication server (AD, LDAP, Radius, or RSA) which
is bound to the SSL gateway. All users with accounts on the bound authentication server will be
authenticated.
The maximum time to authenticate over SSL VPN is 3 minutes. This is because non-authentication
timeout is 3 minutes and is not a configurable property. So in scenarios where AD authentication timeout
is set to more than 3 minutes or there are multiple authentication servers in chain authorization and the
time taken for user authentication is more than 3 minutes, you will not be authenticated.
Procedure
1 In the SSL VPN-Plus tab, select Authentication from the left panel.
4 Depending on the type of authentication server you selected, complete the following fields.
u AD authentication server
Enable SSL Enabling SSL establishes an encrypted link between a web server and a browser.
Note There might be issues if you do not enable SSL and try to change password using SSL VPN-
Plus tab or from client machine later.
Search base Part of the external directory tree to search. The search base may be something equivalent to the
organizational unit (OU), domain controller (DC), or domain name (AD) of external directory.
Examples:
n OU=Users,DC=aslan,DC=local
n OU=VPN,DC=aslan,DC=local
Bind DN User on the external AD server permitted to search the AD directory within the defined search base.
Most of the time, the bind DN is permitted to search the entire directory. The role of the bind DN is to
query the directory using the query filter and search base for the DN (distinguished name) for
authenticating AD users. When the DN is returned, the DN and password are used to authenticate
the AD user.
Example: CN=ldap.edge,OU=users,OU=Datacenter Users,DC=aslan,DC=local
Login Attribute Name against which the user ID entered by the remote user is matched with. For Active Directory, the
Name login attribute name is sAMAccountName.
Search Filter Filter values by which the search is to be limited. The search filter format is attribute operator value.
If you need to limit the search base to a specific group in the AD and not allow searching across the
entire OU, then
n Do not put group name inside the search base, only put OU and DC.
n Do not put both objectClass and memberOf inside the same search filter string. Example of
correct format for the search filter: memberOf=CN=VPN_Users,OU=Users,DC=aslan,DC=local
Use this server If selected, this AD server is used as the second level of authentication.
for secondary
authentication
Enable SSL Enabling SSL establishes an encrypted link between a web server and a browser.
Search base Part of the external directory tree to search. The search base may be something equivalent to
the organization, group, or domain name (AD) of external directory.
Bind DN User on the external server permitted to search the AD directory within the defined search
base. Most of the time, the bind DN is permitted to search the entire directory. The role of the
bind DN is to query the directory using the query filter and search base for the DN
(distinguished name) for authenticating AD users. When the DN is returned, the DN and
password are used to authenticate the AD user.
Login Attribute Name Name against which the user ID entered by the remote user is matched with. For Active
Directory, the login attribute name is sAMAccountName.
Search Filter Filter values by which the search is to be limited. The search filter format is attribute operator
value.
Use this server for If selected, this server is used as the second level of authentication.
secondary
authentication
Secret Shared secret specified while adding the authentication agent in the RSA security console.
NAS IP Address IP address to be configured and used as RADIUS attribute 4, NAS-IP-Address, without changing the
source IP address in the IP header of the RADIUS packets.
Retry Count Number of times the RADIUS server is to be contacted if it does not respond before the
authentication fails.
Use this server If selected, this server is used as the second level of authentication.
for secondary
authentication
Configuration Click Browse to select the sdconf.rec file that you downloaded from the RSA Authentication
File Manager.
Source IP IP address of the NSX Edge interface through which the RSA server is accessible.
Address
Use this server If selected, this server is used as the second level of authentication.
for secondary
authentication
Enable password If selected, defines a password policy. Specify the required values.
policy
Enable password If selected, defines an account lockout policy. Specify the required values.
policy 1 In Retry Count, type the number of times a remote user can try to access his or her account
after entering an incorrect password.
2 In Retry Duration, type the time period in which the remote user's account gets locked on
unsuccessful login attempts.
For example, if you specify Retry Count as 5 and Retry Duration as 1 minute, the remote user's
account will be locked if he makes 5 unsuccessful login attempts within 1 minute.
3 In Lockout Duration, type the time period for which the user account remains locked. After this
time, the account is automatically unlocked.
Use this server If selected, this server is used as the second level of authentication.
for secondary
authentication
Procedure
1 In the SSL VPN-Plus tab, select Installation Package from the left panel.
4 In Gateway, type the IP address or FQDN of the public interface of NSX Edge.
This IP address or FQDN is binded to the SSL client. When the client is installed, this IP address or
FQDN is displayed on the SSL client.
5 Type the port number that you specified in the server settings for SSL VPN-Plus. See Add SSL VPN-
Plus Server Settings.
6 (Optional) To bind additional NSX Edge uplink interfaces to the SSL client,
c Click OK.
7 The installation package is created for Windows operating system by default. Select Linux or Mac to
create an installation package for Linux or Mac operating systems as well.
9 Select Enable to display the installation package on the Installation Package page.
Option Description
Start client on logon The SSL VPN client is started when the remote user logs on to his system.
Enable silent mode installation Hides installation commands from remote user.
Hide SSL client network adapter Hides the VMware SSL VPN-Plus Adapter, which is installed on the remote user's
computer along with the SSL VPN installation package.
Hide client system tray icon Hides the SSL VPN tray icon which indicates whether the VPN connection is
active or not.
Create desktop icon Creates an icon to invoke the SSL client on the user's desktop.
Enable silent mode operation Hides the pop-up that indicates that installation is complete.
Server security certificate validation The SSL VPN client validates the SSL VPN server certificate before establishing
the secure connection.
Block user on certificate validation If the certificate validation fails, then block the SSL VPN user.
failure
11 Click OK.
Add a User
Add a remote user to the local database.
Procedure
1 In the SSL Vpn-Plus tab, select Users from the left panel.
8 In Password Details, select Password never expires to always keep the same password for the
user.
9 Select Allow change password to let the user change the password.
10 Select Change password on next login if you want the user to change the password the next time
he logs in.
12 Click OK.
Procedure
1 In the SSL Vpn-Plus tab, select Dashboard from the left panel.
2
Click the icon.
The dashboard displays the status of the service, number of active SSL VPN sessions, and session
statistics and data flow details. Click Details next to Number of Active Sessions to view information
about the concurrent connections to private networks behind the NSX Edge gateway.
What to do next
1 Add an SNAT rule to translate the IP address of the NSX Edge appliance to the VPN Edge IP
address.
2 Using a web browser, navigate to the IP address of the NSX Edge interface by typing
https//NSXEdgeIPAddress.
3 Login using the user name and password that you created in the Add a User section and download
the installation package.
4 Enable port forwarding on your router for the port number used in Add SSL VPN-Plus Server
Settings.
5 Launch the VPN client, select your VPN server, and login. You can now navigate to the services on
your network. SSL VPN-Plus gateway logs are sent to the syslog server configured on the NSX Edge
appliance. SSL VPN-Plus client logs are stored in the following directory on the remote user's
computer: %PROGRAMFILES%/VMWARE/SSLVPN Client/.
Add a Script
You can add multiple login or logoff scripts. For example, you can bind a login script for starting Internet
Explorer with gmail.com. When the remote user logs in to the SSL client, Internet Explorer opens up
gmail.com.
Procedure
1 In the SSL Vpn-Plus tab, select Login/Logoff Scripts from the left panel.
3 In Script, click Browse and select the script you want to bind to the NSX Edge gateway.
Option Description
Login Performs the script action when remote user logs in to SSL VPN.
Logoff Performs the script action when remote user logs out of SSL VPN.
Both Performs the script action both when remote user logs in and logs out of SSL
VPN.
7 Click OK.
Procedure
7 Login to the SSL client with the credentials specified in the Users section.
The SSL VPN server certificate is validated depending on the client operating system.
n Windows client
Windows client is authenticated as the Server security certificate validation option is selected
by default, when the installation package was created.
For Internet Explorer (IE) browser, add a trusted CA to the trust certificate store. If server
certificate validation fails, you are prompted to contact your system administrator. If server
certificate validation succeeds, a log in prompt is displayed.
Adding a trusted CA to the trust store is independent of SSL VPN work flow.
n Linux client
The SSL VPN Linux client validates the server certificate against Firefox's certificate store by
default. If server certificate validation fails, you are prompted to contact your system
administrator. If server certificate validation succeeds, a log in prompt is displayed.
Adding a trusted CA to the trust store i.e Firefox's certificate store is independent of SSL VPN
work flow.
n OS X client
The SSL VPN OS X client validates the server certificate against Keychain, a database used to
store certificates on OS X, by default. If server certificate validation fails, you are prompted to
contact your system administrator. If server certificate validation succeeds, a log in prompt is
displayed.
Adding a trusted CA to the trust store i.e Keychain is independent of SSL VPN work flow.
2 Go to the Logging Policy section and expand the section to view the current settings.
3 Click Change.
OR
Note SSL VPN-Plus client logs are enabled by default and log level is set to NOTICE.
6 Click OK.
Procedure
1 In the SSL VPN-Plus tab, select Client Configuration from the left panel.
In split tunnel mode, only the VPN flows through the NSX Edge gateway. In full tunnel, the NSX Edge
gateway becomes the remote user's default gateway and all traffic (VPN, local, and internet) flows
through this gateway.
a Select Exclude local subnets to exclude local traffic from flowing through the VPN tunnel.
b Type the IP address for the default gateway of the remote user's system.
4 Select Enable auto reconnect if you would like the remote user to automatically reconnect to the
SSL VPN client after getting disconnected.
5 Select Client upgrade notification for the remote user to get a notification when an upgrade for the
client is available. The remote user can then choose to install the upgrade.
6 Click OK.
Procedure
1 In the SSL VPN-Plus tab, select General Settings from the left panel.
Select To
Prevent multiple logon using same Allow a remote user to login only once with a username.
username
Enable compression Enable TCP based intelligent data compression and improve data transfer speed.
Enable logging Maintain a log of the traffic passing through the SSL VPN gateway.
Force virtual keyboard Allow remote users to enter web or client login information only via the virtual
keyboard.
Randomize keys of virtual keyboard Make the virtual keyboard keys random.
Select To
Enable forced timeout Disconnect the remote user after the specified timeout period is over. Type the
timeout period in minutes.
Session idle timeout If there is no activity on the user session for the specified period, end the user
session after that period is over.
SSLVPN idle timeout considers all packets, including control packets sent by any
Application and user data, towards timeout detection. As a result, even if there is
no user data, the session won't timeout if there is an application which transmits a
periodic control packet (such as MDNS).
User notification Type a message to be displayed to the remote user after he logs in.
3 Click OK.
Procedure
2 Click the Manage tab and then click the SSL VPN-Plus tab.
6 In Logo, click Change and select the image file for the remote user's logo.
7 In Colors, click the color box next to numbered item for which you want to change the color, and
select the desired color.
9 Click OK.
For information on adding an IP pool, see Configure Network Access SSL VPN-Plus.
Edit an IP Pool
You can edit an IP pool.
Procedure
3
Click the Edit ( ) icon.
5 Click OK.
Delete an IP Pool
You can delete an IP pool.
Procedure
Enable an IP Pool
You can enable an IP pool if you want an IP address from that pool to be assigned to the remote user.
Procedure
Disable an IP Pool
You can disable an IP pool if you do not want the remote user to be assigned an IP address from that
pool.
Procedure
1 In the SSL VPN-Plus tab, select IP Pool from the left panel.
3
Click the Disable ( ) icon.
Procedure
2 Select the IP pool that you want to change the order for.
For information on adding a private network, see Configure Network Access SSL VPN-Plus.
Procedure
1 In the SSL VPN-Plus tab, click Private Networks in the left panel.
2 Select the network that you want to delete and click the Delete ( ) icon.
Procedure
1 In the SSL VPN-Plus tab, click Private Networks in the left panel.
Procedure
1 In the SSL VPN-Plus tab, click Private Networks in the left panel.
3
Click the Disable ( ) icon.
If you select Enable TCP Optimization for a private network, some applications such as FTP in Active
mode may not work within that subnet. To add an FTP server configured in Active mode, you must add
another private network for that FTP server with TCP Optimization disabled. Also, the active TCP private
network must be enabled, and must be placed above the subnet private network.
Procedure
1 In the SSL VPN-Plus tab, click Private Networks in the left panel.
3 Select the network that you want to change the order of.
5 Click OK.
What to do next
To add an FTP server configured in Active mode, refer to Configure Private Network for Active FTP
Server.
Prerequisites
Procedure
1 In the SSL VPN-Plus tab, click Private Networks in the left panel.
2 Add the private network that you want to configure for active FTP. For more information, refer to Add
a Private Network.
4 In the Ports field, add port number for the private network.
6 Place the private network that you want to configure for active FTP above other private networks that
are configured. For more information, refer to Change the Sequence of a Private Network.
What to do next
For information on creating an installation package, see Configure Network Access SSL VPN-Plus.
Procedure
1 In the SSL VPN-Plus tab, click Installation Package in the left panel.
3
Click the Edit ( ) icon.
5 Click OK.
Procedure
1 In the SSL VPN-Plus tab, click Installation Package in the left panel.
For information on adding a user, see Configure Network Access SSL VPN-Plus.
Edit a User
You can edit the details for a user except for the user ID.
Procedure
2
Click the Edit ( ) icon.
4 Click OK.
Delete a User
You can delete a user.
Procedure
3 Select the user that you want to delete and click the Delete ( ) icon.
Procedure
4 Click Change password on next login to change the password when the user logs in to his system
next time.
5 Click OK.
Edit a Script
You can edit the type, description, and status of a login or logoff script that is bound to the NSX Edge
gateway.
Procedure
1 In the SSL VPN-Plus tab, click Login/Logoff Scripts in the left panel.
2
Select a script and click the Edit ( ) icon.
4 Click OK.
Delete a Script
You can delete a login or logoff script.
Procedure
1 In the SSL VPN-Plus tab, click Login/Logoff Scripts in the left panel.
Enable a Script
You must enable a script for it to work.
Procedure
1 In the SSL VPN-Plus tab, click Login/Logoff Scripts in the left panel.
Disable a Script
You can disable a login/logoff script.
Procedure
1 In the SSL VPN-Plus tab, click Login/Logoff Scripts in the left panel.
2
Select a script and click the Disable ( ) icon.
Procedure
1 In the SSL VPN-Plus tab, click Login/Logoff Scripts in the left panel.
2 Select the script that you want to change the order of and click the Move Up ( )or Move Down ( )
icon.
3 Click OK.
Behind each remote VPN router, you can configure multiple subnets to connect to the internal network
behind an NSX Edge through IPSec tunnels.
Note Subnets and the internal network behind a NSX Edge must have address ranges that do not
overlap.
If the local and remote peer across an IPsec VPN have overlapping IP addresses, traffic forwarding
across the tunnel might be not consistent depending on whether local connected routes and auto-
plumbed routes exist.
You can deploy an NSX Edge agent behind a NAT device. In this deployment, the NAT device translates
the VPN address of an NSX Edge instance to a publicly accessible address facing the Internet. Remote
VPN routers use this public address to access the NSX Edge instance.
You can place remote VPN routers behind a NAT device as well. You must provide the VPN native
address and the VPN Gateway ID to set up the tunnel. On both ends, static one-to-one NAT is required
for the VPN address.
The number of tunnels needed is defined by the number of local subnets multiplied by the number of peer
subnets. For example, if there are 10 local subnets and 10 peer subnets you need 100 tunnels. The
maximum number of tunnels supported is determined by the ESG size, as shown below.
Compac 512
t
Large 1600
Quad- 4096
Large
X-Large 6000
n AES (AES128-CBC)
n AES256 (AES256-CBC)
n AES-GCM (AES128-GCM)
For IPSec VPN configuration examples, see IPSec VPN Configuration Examples.
Note If you connect to a remote site via IPSec VPN, the IP address of that site cannot be learnt by
Dynamic Routing on the Edge uplink.
Procedure
4 Click the Manage tab and then click the VPN tab.
6 Click Enable.
7 (Optional) To operate IPSec VPN in a responder-only mode, select the Responder only check box.
Prerequisites
Procedure
mkdir newcerts
mkdir certs
mkdir req
mkdir private
echo "01" > serial
touch index.txt
openssl req -new -x509 -newkey rsa:2048 -keyout private/cakey.pem -out cacert.pem -days 3650
5 On NSX Edge1, generate a CSR, copy the privacy-enhanced mail (PEM) file content, and save it in a
file in req/edge1.req.
7 On NSX Edge2, generate a CSR, copy the PEM file content, and save it in a file in req/edge2.req.
9 Upload the PEM certificate at the end of the file certs/edge1.pem to Edge1.
10 Upload the PEM certificate at the end of the file certs/edge2.pem to Edge2.
11 Upload the CA certificate in the file cacert.pem to Edge1 and Edge2 as CA-signed certificates.
12 In the IPSec global configuration for Edge1 and Edge2, select the uploaded PEM certificate and the
uploaded CA certificate and save the configuration.
13 On the Certifcate tab, click the uploaded certificate and record the DN string.
15 Create IPsec VPN sites on Edge1 and Edge2 with Local ID and Peer ID as the distinguished name
(DN) string in the specified format.
Check the status by clicking Show IPsec Statistics. Click the channel to see the tunnel status. Both the
channel and tunnel status should be green.
Prerequisites
To enable certificate authentication, server certificates and corresponding CA-signed certificates must be
imported. Optionally, you can use an open-source command-line tool such as OpenSSL to generate CA-
signed certificates.
Self-signed certificates cannot be used for IPSec VPNs. They can only be used in load balancing and
SSL VPNs.
Procedure
4 Click the Manage tab and then click the VPN tab.
7 Type a global pre-shared key for those sites whose peer endpoint is set to any and select Display
shared key to display the key.
The add_spd extension allows two options on and off. The default option is on, even when you don't
configure this extension. The following table describes the global extensions.
Extension Description
add_spd=off n Security policies are installed only when the tunnel is up.
n If the tunnel is up, packets are sent encrypted through the tunnel.
n If the tunnel is down, packets are sent unencrypted, if a route is available.
add_spd=on n Security policies are installed regardless of whether the tunnel is established.
n If the tunnel is up, packets are sent encrypted through the tunnel.
n If the tunnel is down, packets are dropped.
ike_fragment_size If the maximum transmission unit (MTU) is small, you can set the IKE fragment
size by using this extension to avoid failure in the IKE negotiation. For example,
ike_fragment_size=900
10 Click OK.
Procedure
4 Click the Manage tab and then click the VPN tab.
6 Click next to Logging Policy and click Enable logging to log the traffic flow between the local
subnet and peer subnet and select the logging level.
Procedure
4 Click the Manage tab and then click the VPN tab.
8 Type the IP address of the NSX Edge instance in Local Id. This will be the peer Id on the remote site.
If you are adding an IP to IP tunnel using a pre-shared key, the local Id and local endpoint IP can be
the same.
10 Type the subnets to share between the sites in CIDR format. Use a comma separator to type multiple
subnets.
11 Type the Peer Id to uniquely identify the peer site. For peers using certificate authentication, this ID
must be the common name in the peer's certificate. For PSK peers, this ID can be any string. VMware
recommends that you use the public IP address of the VPN or a FQDN for the VPN service as the
peer ID.
12 Type the IP address of the peer site in Peer Endpoint. If you leave this blank, NSX Edge waits for the
peer device to request a connection.
13 Type the internal IP address of the peer subnet in CIDR format. Use a comma separator to type
multiple subnets.
14 Select one of the following Internet Key Exchange (IKE) protocols to set up a security association
(SA) in the IPSec protocol suite.
Option Description
IKEv1 When you select this option, IPSec VPN initiates and responds to IKEv1 protocol
only.
IKEv2 When you select this option, IPSec VPN initiates and responds to IKEv2 protocol
only.
IKE-Flex When you select this option, and if the tunnel establishment fails with IKEv2
protocol, the source site does not fall back and initiate a connection with IKEv1
protocol. Instead, if the remote site initiates a connection with IKEv1 protocol,
then the connection is accepted.
Important If you configure multiple sites with similar local and remote endpoints, make sure that you
select the same IKE version across all the sites.
15 In Digest Algorithm, select the secure hashing algorithm that is used by SSL certificate authorities to
sign certificates.
Option Description
PSK (Pre Shared Key) Indicates that the secret key shared between NSX Edge and the peer site is to be
used for authentication. The secret key can be a string with a maximum length of
128 bytes.
PSK authentication is disabled in FIPS mode.
Certificate Indicates that the certificate defined at the global level is to be used for
authentication.
18 Type the shared key in if anonymous sites are to connect to the VPN service.
19 Click Display Shared Key to display the key on the peer site.
20 In Diffie-Hellman (DH) Group, select the cryptography scheme that will allow the peer site and the
NSX Edge to establish a shared secret over an insecure communications channel.
DH14 is default selection for both FIPS and non-FIPS mode. DH2 and DH5 are not available when
FIPS mode is enabled.
n securelocaltrafficbyip=IPAddress to re-direct Edge's local traffic over the IPSec VPN tunnel. This
is the default value. For more information see http://kb.vmware.com/kb/20080007 .
22 Click OK.
NSX Edge creates a tunnel from the local subnet to the peer subnet.
What to do next
Procedure
7
Click the Edit ( ) icon.
9 Click OK.
Procedure
7
Click the Disable ( ) icon.
Procedure
For this scenario, NSX Edge connects the internal network 192.168.5.0/24 to the internet. NSX Edge
interfaces are configured as follows:
The remote gateway connects the 172.15.0.0/16 internal network to the internet. The remote gateway
interfaces are configured as follows:
192.168.5.0/24 172.15.0.0/16
192.168.5.1 172.16.0.1
V
Internet
Note For NSX Edge to NSX Edge IPSEC tunnels, you can use the same scenario by setting up the
second NSX Edge as the remote gateway.
Terminology
IPSec is a framework of open standards. There are many technical terms in the logs of the NSX Edge
and other VPN appliances that you can use to troubleshoot the IPSEC VPN.
n ISAKMP (Internet Security Association and Key Management Protocol) is a protocol defined by RFC
2408 for establishing Security Associations (SA) and cryptographic keys in an Internet environment.
ISAKMP only provides a framework for authentication and key exchange and is designed to be key
exchange independent.
n Oakley is a key-agreement protocol that allows authenticated parties to exchange keying material
across an insecure connection using the Diffie-Hellman key exchange algorithm.
n IKE (Internet Key Exchange) is a combination of ISAKMP framework and Oakley. NSX Edge provides
IKEv1.
n Diffie-Hellman (DH) key exchange is a cryptographic protocol that allows two parties that have no
prior knowledge of each other to jointly establish a shared secret key over an insecure
communications channel. VSE supports DH group 2 (1024 bits) and group 5 (1536 bits).
Phase 1 Parameters
Phase 1 sets up mutual authentication of the peers, negotiates cryptographic parameters, and creates
session keys. The Phase 1 parameters used by NSX Edge are:
n Main mode
n SHA-1
Phase 2 Parameters
IKE Phase 2 negotiates an IPSec tunnel by creating keying material for the IPSec tunnel to use (either by
using the IKE phase one keys as a base or by performing a new key exchange). The IKE Phase 2
parameters supported by NSX Edge are:
n SHA-1
n Selectors for all IP protocols, all ports, between the two networks, using IPv4 subnets
NSX Edge supports Main Mode for Phase 1 and Quick Mode for Phase 2.
NSX Edge proposes a policy that requires PSK, 3DES/AES128, sha1, and DH Group 2/5. The peer must
accept this policy; otherwise, the negotiation phase fails.
This example shows an exchange of Phase 1 negotiation initiated from a NSX Edge to a Cisco device.
The following transactions occur in sequence between the NSX Edge and a Cisco VPN device in Main
Mode.
n DPD enabled
n If the Cisco device does not accept any of the parameters the NSX Edge sent in step one, the
Cisco device sends the message with flag NO_PROPOSAL_CHOSEN and terminates the
negotiation.
n include ID (PSK)
n include ID (PSK)
n If the Cisco device finds that the PSK doesn't match, the Cisco device sends a message with flag
INVALID_ID_INFORMATION; Phase 1 fails.
The following transactions occur in sequence between the NSX Edge and a Cisco VPN device in Quick
Mode.
Cisco device sends back NO_PROPOSAL_CHOSEN if it does not find any matching policy for the
proposal. Otherwise, the Cisco device sends the set of parameters chosen.
To facilitate debugging, you can enable IPSec logging on the NSX Edge and enable crypto debug on
Cisco (debug crypto isakmp <level>).
Procedure
Procedure
4 Click the Manage tab and then click the VPN tab.
8 Type the IP address of the NSX Edge instance in Local Id. This will be the peer Id on the remote site.
If you are adding an IP to IP tunnel using a pre-shared key, the local Id and local endpoint IP can be
the same.
10 Type the subnets to share between the sites in CIDR format. Use a comma separator to type multiple
subnets.
11 Type the Peer Id to uniquely identify the peer site. For peers using certificate authentication, this ID
must be the common name in the peer's certificate. For PSK peers, this ID can be any string. VMware
recommends that you use the public IP address of the VPN or a FQDN for the VPN service as the
peer ID
12 Type the IP address of the peer site in Peer Endpoint. If you leave this blank, NSX Edge waits for the
peer device to request a connection.
13 Type the internal IP address of the peer subnet in CIDR format. Use a comma separator to type
multiple subnets.
Option Description
PSK (Pre Shared Key) Indicates that the secret key shared between NSX Edge and the peer site is to be
used for authentication. The secret key can be a string with a maximum length of
128 bytes.
Certificate Indicates that the certificate defined at the global level is to be used for
authentication.
16 Type the shared key in if anonymous sites are to connect to the VPN service.
17 Click Display Shared Key to display the key on the peer site.
18 In Diffie-Hellman (DH) Group, select the cryptography scheme that will allow the peer site and the
NSX Edge to establish a shared secret over an insecure communications channel.
20 Select whether to enable or disable the Perfect Forward Secrecy (PFS) threshold. In IPsec
negotiations, Perfect Forward Secrecy (PFS) ensures that each new cryptographic key is unrelated to
any previous key.
21 Click OK.
NSX Edge creates a tunnel from the local subnet to the peer subnet.
What to do next
Procedure
4 Click the Manage tab and then click the VPN tab.
6 Click Enable.
What to do next
Click Enable Logging to log the traffic flow between the local subnet and peer subnet.
Procedure
interface GigabitEthernet0/0
ip address 10.24.120.90 255.255.252.0
duplex auto
speed auto
crypto map MYVPN
!
interface GigabitEthernet0/1
ip address 172.16.0.1 255.255.0.0
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 10.24.123.253
Example: Configuration
!
hostname router2821
!
boot-start-marker
boot-end-marker
!
! card type command needed for slot 0
! card type command needed for slot 1
enable password cisco
!
no aaa new-model
!
resource policy
!
ip subnet-zero
!
ip cef
!no ip dhcp use vrf connected
!
!
no ip ips deny-action ips-interface
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key vshield address 10.115.199.103
!
crypto ipsec transform-set myset esp-3des
esp-sha-hmac
!
crypto map MYVPN 1 ipsec-isakmp
set peer 10.115.199.103
set transform-set myset
set pfs group1
match address 101
!
interface GigabitEthernet0/0
ip address 10.24.120.90 255.255.252.0
duplex auto
speed auto
crypto map MYVPN
!
interface GigabitEthernet0/1
ip address 172.16.0.1 255.255.0.0
duplex auto
speed auto
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.24.123.253
!
ip http server
no ip http secure-server
!
access-list 101 permit ip 172.16.0.0
shutdown
no nameif
no security-level
no ip address
!
boot system disk0:/asa821-18-k8.bin
ftp mode passive
access-list ACL1 extended permit ip 172.16.0.0 255.255.0.0
192.168.5.0 255.255.255.0
access-list ACL1 extended permit ip 192.168.5.0 255.255.255.0
172.16.0.0 255.255.0.0
access-list 101 extended permit icmp any any
pager lines 24
mtu untrusted 1500
mtu trusted 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
icmp permit any untrusted
icmp permit any trusted
no asdm history enable
arp timeout 14400
access-group 101 in interface untrusted
access-group 101 out interface untrusted
access-group 101 in interface trusted
access-group 101 out interface trusted
route untrusted 10.115.0.0 255.255.0.0 10.24.123.253 1
route untrusted 192.168.5.0 255.255.255.0 10.115.199.103 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00
udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00
sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
no snmp-server location
no snmp-server contact
crypto ipsec transform-set MYSET esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map MYVPN 1 match address ACL1
crypto map MYVPN 1 set pfs
crypto map MYVPN 1 set peer 10.115.199.103
crypto map MYVPN 1 set transform-set MYSET
crypto map MYVPN interface untrusted
crypto isakmp enable untrusted
crypto isakmp policy 1
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
telnet 10.0.0.0 255.0.0.0 untrusted
telnet timeout 5
ssh timeout 5
console timeout 0
no threat-detection basic-threat
no threat-detection statistics access-list
no threat-detection statistics tcp-intercept
username admin password f3UhLvUj1QsXsuK7 encrypted
tunnel-group 10.115.199.103 type ipsec-l2l
tunnel-group 10.115.199.103 ipsec-attributes
pre-shared-key *
!
!
prompt hostname context
Cryptochecksum:29c3cc49460831ff6c070671098085a9
: end
Procedure
5 Select Network > Branch Office VPN > Manual IPSec to configure the remote gateway.
6 In the IPSec Configuration dialog box, click Gateways to configure the IPSEC Remote Gateway.
8 In the IPSec Configuration dialog box, click Add to add a routing policy.
9 Click Close.
L2 VPN Overview
With L2 VPN, you can stretch multiple logical networks (both VLAN and VXLAN) across geographical
sites. In addition, you can configure multiple sites on an L2 VPN server. Virtual machines remain on the
same subnet when they are moved between sites and their IP addresses do not change. Egress
optimization enables Edge to route any packets sent towards the Egress Optimization IP address locally,
and bridge everything else.
L2 VPN thus allows enterprises to seamlessly migrate workloads backed by VXLAN or VLAN between
physically separated locations. For cloud providers, L2 VPN provides a mechanism to on-board tenants
without modifying existing IP addresses for workloads and applications.
Layer 3
Network
VPN VPN
vNic vNic
VXLAN VXLAN Trunk VXLAN Trunk VXLAN
5010 5010
VM 3 VM 4 VM 7 VM 8
VXLAN VXLAN
5011 5011
The L2 VPN client and server learn the MAC addresses on both local and remote sites based on the
traffic flowing through them. Egress optimization maintains local routing since the default gateway for all
virtual machines are always resolved to the local gateway using firewall rules. Virtual machines that have
been moved to Site B can also access L2 segments that are not stretched on Site A.
If one of the sites is not backed by NSX, a standalone NSX Edge can be deployed on that site.
In the following graphic, L2 VPN stretches network VLAN 10 to VXLAN 5010 and VLAN 11 to VXLAN
5011. So VM 1 bridged with VLAN 10 can access VMs 2, 5, and 6.
Figure 15‑3. Extending Non-NSX Site with VLAN Based Network to NSX-Site with VXLAN
Based Network
Layer 3
Network
Uplink Network
Uplink Network
NSX
Standalone NSX Edge
Edge VM 5 VM 6
vNic
Trunk VLAN 10-11 vNic
VXLAN Trunk VXLAN
5010
VLAN 10 VLAN 11
VM 7 VM 8
VXLAN
VM 1 VM 2 VM 3 VM 4
5011
Site A: Non-NSX VLAN Backed Network Site B: NSX with VXLAN Backed Network
Configuring L2 VPN
To stretch your network using L2 VPN, you configure an L2 VPN server (destination Edge) and an L2
VPN client (source Edge). You must then enable the L2 VPN service on both the server and the client.
Prerequisites
A sub interface must have been added on a trunk interface of the NSX Edge. See Add a Sub Interface.
Option 1: Separate ESXi hosts for the L2VPN Edges and the VMs
Teaming Active/Active:
Not Supported Standby Active
dvPortGroup dvPortGroup
SINK
Trunk
vDS
interface
2 Configure the Teaming and Failover Policy for the Distributed Port Group associated with the Edge’s
Trunk vNic as follows:
b Configure only one uplink as Active and the other uplink as Standby.
3 Configure the teaming and failover policy for the distributed port group associated with the VMs as
follows:
4 Configure Edges to use sink port mode and disable promiscuous mode on the trunk vNic.
Note
n Disable promiscuous mode: If you are using vSphere Distributed Switch.
n Enable promiscuous mode: If you are using virtual switch to configure trunk interface.
If a virtual switch has promiscuous mode enabled, some of the packets that come in from the uplinks that
are not currently used by the promiscuous port, are not discarded. You should enable and then disable
ReversePathFwdCheckPromisc that will explicitly discard all the packets coming in from the currently
unused uplinks, for the promiscuous port.
To block the duplicate packets, activate RPF check for the promiscuous mode from the ESXi CLI where
NSX Edge is present:
In PortGroup security policy, set PromiscousMode from Accept to Reject and back to Accept to
activate the configured change.
Standby Standby
a Configure the teaming and failover policy for the distributed port group associated with Edge’s
trunk vNic as follows:
b Configure the teaming and failover policy for the distributed port group associated with the VMs
as follows:
3 The order of the active/standby uplinks must be the same for the VMs' distributed port group
and the Edge’s trunk vNic distributed port group.
c Configure the client-side standalone edge to use sink port mode and disable promiscuous mode
on the trunk vNic.
If one of you VPN sites does not have NSX deployed, you can configure an L2 VPN by deploying a
standalone NSX Edge at that site. A standalone Edge is deployed using an OVF file that represents an
Edge gateway with the purpose of acting as an L2 VPN client to be deployed on a host that is not
managed by NSX.
If a standalone edge trunk vNIC is connected to a vSphere Distributed Switch, either promiscuous mode
or a sink port is required for L2 VPN function. Using promiscuous mode can cause duplicate pings and
duplicate responses. For this reason, we recommend using sink port mode in the L2 VPN standalone
NSX Edge configuration.
Prerequisites
You need the port number of the trunk vNIC of the standalone edge.
Procedure
b Click content.
c Click the link associated with the rootFolder (for example: group-d1 (Datacenters)).
d Click the link associated with the childEntity (for example: datacenter-1).
e Click the link associated with the networkFolder (for example: group-n6).
f Click the DVS name link for the vSphere distributed switch associated with the NSX Edges (for
example: dvs-1 (Mgmt_VDS)).
b Click content.
c Click DVSManager.
d Click updateOpaqueDataEx.
<selectionSet xsi:type="DVPortSelection">
<dvsUuid>c2 1d 11 50 6a 7c 77 68-e6 ba ce 6a 1d 96 2a 15</dvsUuid> <!--example only-->
<portKey>393</portKey> <!--port number of the DVPG where SINK to be set-->
</selectionSet>
Use the dvsUuid value that you retrieved from the vCenter MOB.
f On the opaqueDataSpec value box paste one of the following XML blocks:
<opaqueDataSpec>
<operation>edit</operation>
<opaqueData>
<key>com.vmware.etherswitch.port.extraEthFRP</key>
<opaqueData
xsi:type="vmodl.Binary">AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAA=</opaqueData>
</opaqueData>
</opaqueDataSpec>
<opaqueDataSpec>
<operation>edit</operation>
<opaqueData>
<key>com.vmware.etherswitch.port.extraEthFRP</key>
<opaqueData
xsi:type="vmodl.Binary">AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAA=</opaqueData>
</opaqueData>
</opaqueDataSpec>
Procedure
2 In Listener IP, type the primary or secondary IP address of an external interface of the NSX Edge.
3 The default port for the L2 VPN service is 443. Edit this if required.
4 Select the encryption algorithm for communication between the server and the client.
6 Click OK.
Note Changing site configuration settings causes the NSX Edge to disconnect and reconnect all existing
connections.
Procedure
4 Type the user name and password with which the peer site is to be authenticated. User credentials on
the peer site should be the same as those on the client side.
5 In Stretched Interfaces, click Select Sub Interfaces to select the sub interfaces to be stretched with
the client.
c Click OK.
6 If the default gateway for virtual machines is same across the two sites, type the gateway IP
addresses for which the traffic should be locally routed or for which traffic is to be blocked over the
tunnel in Egress Optimization Gateway Address.
Procedure
1 For the destination NSX Edge, navigate to Manage > VPN > L2 VPN.
What to do next
Create NAT or firewall rule on the internet facing firewall side to enable the client and server to connect to
each other.
You can also configure a standalone Edge as the L2 VPN client. See Configure Standalone Edge as L2
VPN Client.
Procedure
1 In the L2 VPN tab, set the L2 VPN Mode to Client and click Change.
2 Type the address of the L2 VPN server to which this client is to be connected. The address can be
the host name or IP address.
3 If required, edit the default port to which the L2 VPN client should connect to.
5 In Stretched Interfaces, click Select Sub Interfaces to select the sub interfaces to be stretched to
the server.
c Click OK.
6 Type a description.
7 In Egress Optimization Gateway Address, type the gateway IP address of the sub interfaces or the
IP addresses to which traffic should not flow over the tunnel.
8 In User Details, type the user credentials to get authenticated at the server..
If the client NSX Edge does not have direct access to the internet and needs to reach the source
(server) NSX Edge via a proxy server, specify Proxy Settings.
11 Type the proxy server address, port, user name, and password.
12 To enable server certificate validation, select Validate Server Certificate and select the appropriate
CA certificate.
What to do next
Ensure that the internet facing firewall allows traffic to flow from L2 VPN Edge to the internet. The
destination port is 443.
Procedure
1 For the source NSX Edge, navigate to Manage > VPN > L2 VPN.
What to do next
n Create NAT or firewall rule on the internet facing firewall side to enable the client and server to
connect to each other.
n If a trunk vNic backed by standard portgroup is being stretched, enable L2 VPN traffic manually by
the following steps:
For more information about promiscuous mode operation and forged transmits, see Securing
®
vSphere Standard Switches in the VMware vSphere Documentation.
If you want to change FIPS mode for a standalone edge, use the fips enable or fips disable
command. For more information, refer to NSX Command Line Interface Reference.
Prerequisites
You have created a trunk port group for the trunk interface of the standalone edge to connect to. This port
group requires some manual configuration:
n If the trunk port group is on a vSphere Standard Switch you must do the following:
n If the trunk port group is on a vSphere Distributed Switch you must do the following:
n Enable sink port for the trunk vNic, or enable promiscuous mode. Enabling a sink port is the
recommended best practice.
Sink port configuration must be done after the standalone edge has been deployed, because you
need to change the configuration of the port connected to the edge trunk vNIC.
Procedure
1 Using vSphere Web Client, log in to the vCenter Server that manages the non-NSX environment.
2 Select Hosts and Clusters and expand clusters to show the available hosts.
3 Right-click the host where you want to install the standalone Edge and select Deploy OVF Template.
4 Enter the URL to download and install the OVF file from the internet or click Browse to locate the
folder on your computer that contains the standalone Edge OVF file and click Next.
5 On the OVF Template Details page, verify the template details and click Next.
6 On the Select name and folder page, type a name for the standalone Edge and select the folder or
datacenter where you want to deploy. Then click Next.
7 On the Select storage page, select the location to store the files for the deployed template.
8 On the Select networks page, configure the networks the deployed template should use. Click Next.
n The Trunk interface is used to create sub-interfaces for the networks that will be stretched.
Connect this interface to the trunk port group you created.
d Type the uplink IP address and prefix length, and optionally default gateway and DNS IP address.
e Select the cipher to be used for authentication. This should match the cipher used on the L2VPN
server.
f To enable Egress Optimization, type the gateway IP addresses for which traffic should be locally
routed or for which traffic is to be blocked over the tunnel.
h Type the user name and password with which the peer site is to be authenticated.
i In Sub Interfaces VLAN (Tunnel ID), type VLAN ID(s) of the network(s) you want to stretch. You
can list the VLAN IDs as a comma separated list or range. For example, 2,3,10-20.
If you want to change the VLAN ID of the network before stretching it to the standalone Edge site,
you can type the VLAN ID of the network and then type the tunnel ID in brackets. For example,
2(100),3(200). The Tunnel ID is used to map the networks that are being stretched. However, you
cannot specify the tunnel ID with a range. So this would not be allowed: 10(100)-14(104). You
would need to rewrite this as 10(100),11(101),12(102),13(103),14(104).
j If the standalone NSX Edge does not have direct access to the internet and needs to reach the
source (server) NSX Edge via a proxy server, type the proxy address, port, user name, and
password.
l Click Next.
10 On the Ready to complete page, review the standalone Edge settings and click Finish.
What to do next
Note the trunk vNIC port number and configure a sink port. See Configure a Sink Port .
Make any further configuration changes with the standalone edge command line interface. See the NSX
Command Line Interface Reference.
Procedure
If the L2 VPN server has multiple peer sites, statistics are displayed for all the peer sites.
What to do next
To see the networks configured on a trunk interface, navigate to Manage > Settings > Interfaces for the
Edge and click Trunk in the Type column.
You map an external, or public, IP address to a set of internal servers for load balancing. The load
balancer accepts TCP, UDP, HTTP, or HTTPS requests on the external IP address and decides which
internal server to use. Port 80 is the default port for HTTP and port 443 is the default port for HTTPs.
You must have a working NSX Edge instance before you can configure load balancing. For information on
setting up NSX Edge, see NSX Edge Configuration.
For information on configuring an NSX Edge certificate, see Working with Certificates.
n Connection throttling
n One-arm mode
n Inline mode
n IPv6 support
n Available on all flavors of an NSX edge services gateway, with a recommendatory of X-Large or Quad
Large for production traffic
Topologies
There are two types of load balancing services to configure in NSX, a one-armed mode, also known as a
proxy mode, or the Inline mode, otherwise known as the transparent mode.
n The external client sends traffic to the virtual IP address (VIP) exposed by the load balancer.
n The load balancer – a centralized NSX edge – performs only destination NAT (DNAT) to replace the
VIP with the IP address of one of the servers deployed in the server farm.
n The server in the server farm replies to the original client IP address. The traffic is received again by
the load balancer since it is deployed inline, usually as the default gateway for the server farm.
n The load balancer performs source NAT to send traffic to the external client, leveraging its VIP as
source IP address.
Phase 4 Phase 3
IP DST 172.30.40.7 IP DST 172.30.40.7
SRC 192.168.20.20 SRC 192.168.1.3
TCP DST 1025 TCP DST 1025
SRC 80 SRC 80
192.168.1.3
(Selected)
n The external client sends traffic to the Virtual IP address (VIP) exposed by the load balancer.
n The load balancer performs two address translations on the original packets received from the client:
destination NAT (DNAT) to replace the VIP with the IP address of one of the servers deployed in the
server farm, and source NAT (SNAT) to replace the client IP address with the IP address identifying
the load balancer itself. SNAT is required to force through the load balancer the return traffic from the
server farm to the client.
n The server in the server farm replies by sending the traffic to the load balancer per SNAT functionality.
n The load balancer again performs a source and destination NAT service to send traffic to the external
client, leveraging its VIP as source IP address.
Phase 4 Phase 3
IP DST 172.30.40.7 IP DST 192.168.1.20
SRC 192.168.1.20 SRC 192.168.1.3
TCP DST 1025 TCP DST 4099
SRC 80 SRC 80
SLB
192.168.1.3
(Selected)
192.168.1.20
TCP 80
VLAN Logical
V Switch
(VXLAN) 192.168.1.1
NSX load balancer supports layer 4 and layer 7 load balancing engines. The layer 4 load balancer is
packet-based, providing fast path processing and the layer 7 load balancer is socket-based, allowing for
advanced traffic manipulations and DDOS mitigation for back-end services.
Packet-based load balancing is implemented on the TCP and UDP layer. Packet-based load balancing
does not stop the connection or buffer the whole request, it sends the packet directly to the selected
server after manipulating the packet. TCP and UDP sessions are maintained in the load balancer so that
packets for a single session are directed to the same server. You can select Acceleration Enable in both
the global configuration and relevant virtual server configuration to enable packet-based load balancing.
Socket-based load balancing is implemented on top of the socket interface. Two connections are
established for a single request, a client-facing connection and a server-facing connection. The server-
facing connection is established after server selection. For HTTP socket-based implementation, the whole
request is received before sending to the selected server with optional L7 manipulation. For HTTPS
socket-based implementation, authentication information is exchanged either on the client-facing
connection or on the server-facing connection. Socket-based load balancing is the default mode for TCP,
HTTP, and HTTPS virtual servers.
Service Monitor Defines how to probe the health status of a backend server.
Application Profile Represents the TCP, UDP, persistence, and certificate configuration for a
given application.
You begin by setting global options for the load balancer, then create a server pool of backend server
members, and associate a service monitor with the pool to manage and share the backend servers
efficiently.
Next, you create an application profile to define the common application behavior in a load balancer such
as client SSL, server SSL, x-forwarded-for, or persistence. Persistence sends subsequent requests with
similar characteristic such as source IP or cookie are required to be dispatched to the same pool member,
without running the load balancing algorithm. Application profiles can be reused across virtual servers.
You then create an optional application rule to configure application-specific settings for traffic
manipulation such as matching a certain URL or hostname so that different requests can be handled by
different pools. Next, you create a service monitor that is specific to your application, or use a previously
created service monitor.
Optionally, you can create an application rule to support advanced functionality of L7 virtual servers.
Some use cases for application rules include content switching, header manipulation, security rules, and
DOS protection.
Finally, you create a virtual server that connects your server pool, application profile, and any potential
application rules together.
When the virtual server receives a request, the load balancing algorithm considers pool member
configuration and runtime status. The algorithm then calculates the appropriate pool to distribute the
traffic comprising one or more members. The pool member configuration includes settings such as,
weight, maximum connection, and condition status. The runtime status includes current connections,
response time, and health check status information. The calculation methods can be round-robin,
weighted round-robin, least connection, source IP hash, weighted least connections, URL, URI, or HTTP
header.
Each pool is monitored by the associated service monitor. When the load balancer detects a problem with
a pool member, it is marked as DOWN. Only UP server is selected when choosing a pool member from
the server pool. If the server pool is not configured with a service monitor, all the pool members are
considered as UP.
Note For load balancer troubleshooting information, refer to NSX Troubleshooting Guide.
Procedure
5 Click Edit.
6 Select the check boxes next to the options to enable. Global load balancer configuration parameters
can be specified.
Option Description
Enable Load Balancer Allows the NSX Edge load balancer to distribute traffic to internal servers for load
balancing.
Enable Acceleration When disabled, all virtual IP addresses (VIPs) use the L7 LB engine.
When enabled, the virtual IP uses the faster L4 LB engine or L7 LB engine (based
on the VIP configuration).
The L4 VIP ("acceleration enabled" in the VIP configuration and no L7 setting
such as AppProfile with cookie persistence or SSL-Offload) is processed before
the edge firewall, and no edge firewall rule is required to reach the VIP. However,
if the VIP is using a pool in non-transparent mode, the edge firewall must be
enabled (to allow the auto-created SNAT rule).
The L7 HTTP/HTTPS VIPs ("acceleration disabled" or L7 setting such as
AppProfile with cookie persistence or SSL-Offload) are processed after the edge
firewall, and require an edge firewall allow rule to reach the VIP.
Note: To validate which LB engine is used for each VIP by the NSX Load
Balancer, on the NSX Edge CLI (ssh or console) run the following command:
"show service loadbalancer virtual" and look for the field "LB PROTOCOL [L4|L7]"
Option Description
Enable Service Insertion Allows the load balancer to work with third party vendor services.
If you have a third party vendor load balancer service deployed in your
environment, see Using a Partner Load Balancer.
7 Click OK.
Following types of monitors are supported: ICMP, TCP, UDP, HTTP, HTTPS, DNS, MSSQL, and LDAP.
Procedure
Interval, Timeout, and Max Retries are common parameters for all types of health checks.
The interval is the period of time in seconds that the monitor sends requests to the back-end server.
9 Enter the Timeout. In each health check, the timeout value is the maximum time in seconds within
which a response from the server must be received.
10 Enter the Max Retries. This value is the number of times the server is tested before it is declared
DOWN.
For example, if Interval is set as 5 seconds, Timeout as 15 seconds, and Max Retries as 3, it
means NSX load balancer will probe backend server every 5 seconds. In each probe, if the expected
response is received from server within 15 seconds, then the health check result is OK. If not, then
the result is CRITICAL. If the recent three health check results are all DOWN, the server is marked as
DOWN.
11 Select the way in which to send the health check request to the server from the drop-down menu.
Monitor types that are supported are ICMP, TCP, UDP, HTTP, HTTPS, DNS, MSSQL, and LDAP.
Three predefined monitors are embedded in the system: default_tcp_monitor, default_http_monitor,
and default_https_monitor.
12 If you select ICMP as the monitor type, then no other parameters are applicable. Leave other
parameters empty.
13 If you select TCP as the monitor type, three more parameters are available: Send, Receive, and
Extension.
a Send (optional) - The string sent to the backend server after a connection is established.
b Receive (optional) Enter the string to be matched. This string can be a header or in the body of
the response. Only when the received string matches this definition is the server considered UP.
c Extension: Enter advanced monitor parameters as key=value pairs in the Extension section.
A sample extension, warning=10, indicates that if a server does not respond within 10 seconds,
the status is set as warning.
escape Can use \n, \r, \t, or \ in send or quit string. Must come
before send or quit option. Default: nothing added to
send, \r\n added to end of quit.
refuse=ok|warn|crit Accept TCP refusals with states ok, warn, or criti Default is
crit.
14 If you select HTTP or HTTPS as the monitor type, perform the steps below.
a Expected (optional) - Enter the string that the monitor expects to match in the status line of HTTP
response in the Expected section. This is a comma separated list.
b Method (optional) - Select the method to detect server status from the drop-down menu: GET,
OPTIONS, or POST.
d If you select the POST method, enter the data to be sent in the Bold section.
e Enter the string to be matched in the response content in the Receive section. This string can be
a header or in the body of the response.
If the string in the Expected section is not matched, the monitor does not try to match the Receive
content.
f Extension: Enter advanced monitor parameters as key=value pairs in the Extension section.
A sample extension, warning=10, indicates that if a server does not respond within 10 seconds,
the status is set as warning.
no-body Do not wait for document body: stop reading after headers.
Note that this still does an HTTP GET or POST, not a
HEAD.
15 If you select UDP as the monitor type, perform the steps below:
a Send (required): Enter the string to be sent to back-end server after a connection is established.
b Receive (required): Enter the string expected to receive from back-end server. Only when the
received string matches this definition, is the server is considered as UP.
16 If you select DNS as the monitor type, perform the following steps:
a Send (required): Enter the string to be sent to back-end server after a connection is established.
b Receive (required): Enter the string expected to receive from back-end server. Only when the
received string matches this definition, the server is considered as UP.
c Extension: Enter advanced monitor parameters as key=value pairs in the Extension section.
A sample extension, warning=10, indicates that if a server does not respond within 10 seconds,
the status is set as warning.
querytype=TYPE Optional: DNS record query type where TYPE =A, AAAA,
SRV, TXT, MX, CNAME, ANY.
n A=IPv4 host address
n AAAA=Ipv6 host address
n SRV= Service locator
n TXT=Text record
n MX=Mail Exchange for the domain record
n CNAME=The Canonical name of an alias record
The default query type is A.
17 If you select MSSQL as the monitor type, perform the following steps:
a Send: Enter the string to be executed on the back-end server after a connection is established.
b Receive: Enter the string expected to receive from the back-end server. Only when the received
string matches this definition, the server is considered as UP.
c User Name, Password and Confirm password (required): Enter the required user name,
password and confirm the entered password. As monitor is associated with a pool, you must set
MSSQL servers in the pool with the same user name and password that is specified here.
d Extension: Enter advanced monitor parameters as key=value pairs in the Extension section.
A sample extension, warning=10, indicates that if a server does not respond within 10 seconds,
the status is set as warning.
18 If you select LDAP as the monitor type, perform the following steps:
a Password and Confirm password (optional): Enter the required password and confirm the
entered password.
b Extension: Enter advanced monitor parameters as key=value pairs in the Extension section.
A sample extension, warning=10, indicates that if a server does not respond within 10 seconds,
the status is set as warning.
base=’cn=admin,dc=example,dc=com’ Required: LDAP base (For example, ou=my unit, o=my org,
c=at.
19 Click OK.
What to do next
Procedure
Option Description
IP-HASH Selects a server based on a hash of the source IP address and the total weight of
all the running servers.
Algorithm parameters are disabled for this option.
ROUND_ROBIN Each server is used in turn according to the weight assigned to it.
This is the smoothest and fairest algorithm when the server's processing time
remains equally distributed.
Algorithm parameters are disabled for this option.
URI The left part of the URI (before the question mark) is hashed and divided by the
total weight of the running servers.
The result designates which server receives the request. This ensures that a URI
is always directed to the same server as long as no server goes up or down.
The URI algorithm parameter has two options uriLength=<len> and
uriDepth=<dep>. The length parameter range should be 1<=len<256. The depth
parameter range should be 1<=dep<10.
Length and depth parameters are followed by a positive integer number. These
options can balance servers based on the beginning of the URI only. The length
parameter indicates that the algorithm should only consider the defined
characters at the beginning of the URI to compute the hash.
The depth parameter indicates the maximum directory depth to be used to
compute the hash. One level is counted for each slash in the request. If both
parameters are specified, the evaluation stops when either is reached.
Option Description
URL URL parameter specified in the argument is looked up in the query string of each
HTTP GET request.
If the parameter is followed by an equal sign = and a value, then the value is
hashed and divided by the total weight of the running servers. The result
designates which server receives the request. This process is used to track user
identifiers in requests and ensure that a same user ID is always sent to the same
server as long as no server goes up or down.
If no value or parameter is found, then a round robin algorithm is applied.
The URL algorithm parameter has one option urlParam=<url>.
9 (Optional) Select an existing default or custom monitor from the Monitors drop-down menu.
b Enter the name and IP address of the server member or click Select to assign grouping objects.
Note VMware Tools must be installed on each VM, or an enabled IP discovery method (DHCP
snooping or ARP snooping, or both) must be in place to when using grouping objects instead of
IP addresses. For more details, refer to the IP Discovery for Virtual Machines.
n Drain - Forces the server to shut down gracefully for maintenance. Setting the pool member
as "drain" removes the back end server from load balancing, while allowing it to be used for
exiting connections and new connections from clients with persistence to that server. The
persistence methods that work with drain state are source IP persistence, cookie insert, and
cookie prefix.
Note Enabling and disabling High Availability configuration on the NSX Edge can break the
persistence and drain state with source IP persistence method.
n Enable - Removes the server from maintenance mode and brings it back into operation. The
pool member state should be either Drain or Disabled.
Note You cannot change the pool member state from Disabled to Drain.
d Enter the port where the member is to receive traffic, and the monitor port where the member is
to receive health monitor pings.
Port value should be null if the related virtual server is configured with a port range.
e Enter the proportion of traffic this member is to handle in the Weight section.
f Enter the maximum number of concurrent connections the member can handle.
If the incoming requests goes higher than the maximum, they are queued and wait for a
connection be released.
g Enter the minimum number of concurrent connections a member must always accept.
h Click OK.
11 Check Transparent to make client IP addresses visible to the backend servers. For more details,
refer to Chapter 16 Logical Load Balancer.
If Transparent is not selected (default value), backend servers see the traffic source IP address as a
load balancer internal IP address. If Transparent is selected, the source IP address is the real client
IP address and the NSX Edge must be set as the default gateway to ensure that return packets go
through the NSX Edge device.
12 Click OK.
You create an application profile to define the behavior of a particular type of network traffic. After
configuring a profile, you associate the profile with a virtual server. The virtual server then processes
traffic according to the values specified in the profile.
Procedure
7 Type a name for the profile and select the traffic type for which you are creating the profile from the
drop-down menu.
UDP Source IP
9 Specify persistence type for the profile from the drop-down menu.
Persistence tracks and stores session data, such as the specific pool member that serviced a client
request. With persistence, client requests are directed to the same pool member throughout the life of
a session or during subsequent sessions.
n Select Cookie persistence to insert a unique cookie to identify the session the first time a client
accesses the site.
The cookie is referred in subsequent requests to persist the connection to the appropriate server.
When a client requests a connection to a virtual server that supports source address affinity
persistence, the load balancer checks to see if that client previously connected, and if so, returns
the client to the same pool member.
n Select Microsoft Remote Desktop Protocol MSRDP persistence to maintain persistent sessions
between Windows clients and servers that are running the Microsoft Remote Desktop Protocol
(RDP) service.
The recommended scenario for enabling MSRDP persistence is to create a load balancing pool
that consists of members running Windows Server 2003 or Windows Server 2008, where all
members belong to a Windows cluster and participate in a Windows session directory.
10 Enter a cookie name and select the mode by which the cookie should be inserted.
Option Description
Prefix This option is selected if your client does not support more than one cookie.
Note All browsers accept multiple cookies. If you have a proprietary application
using a proprietary client that supports only one cookie. The Web server sends its
cookie as usual. NSX Edge injects (as a prefix) its cookie information in the server
cookie value. This cookie added information is removed when NSX Edge sends it
to the server.
App Session The server does not send a cookie. Instead, it sends the user session information
as a URL.
For example,
http://mysite.com/admin/UpdateUserServlet;jsessionid=OI24B9ASD7BSSD,
where jsessionid is the user session information and is used for the
persistence. It is not possible to see the App Session persistence table for
troubleshooting.
11 Enter the persistence expiration time in seconds. The default value of persistence is 300 seconds
(five minutes). Note that the persistence table is of limited size. A large timeout value may lead to the
persistence table quickly filling up if the traffic is heavy. When the persistence table fills up, the oldest
entry is deleted to accept the newest entry.
The load balancer persistence table maintains entries to record that client requests are directed to the
same pool member.
n If no new connection requests are received from the same client within the timeout period, the
persistence entry expires and is deleted.
n If a new connection request from same client is received within the timeout period, the timer is
reset, and the client request is sent to a sticky pool member.
n After the timeout period has expired, new connection requests will be sent to a pool member
allocated by the load balancing algorithm.
For the L7 load balancing TCP source IP persistence scenario, the persistence entry times out if no
new TCP connections are made for a period of time, even if the existing connections are still alive.
n SSL Offloading - Client -> HTTPS -> LB (terminate SSL) -> HTTP -> server
n SSL Proxy - Client -> HTTPS -> LB (terminate SSL) -> HTTPS -> server
n SSL Passthrough - Client -> HTTPS-> LB (SSL passthrough) -> HTTPS -> server
a (Optional) Check Insert X-Forwarded-For HTTP header to identify the originating IP address of
a client connecting to a Web server through the load balancer.
b Check Configure Service Certificate to select the applicable service certificate, CA certificates,
and CRLs used to terminate the HTTPS traffic from the client on the load balancer in the Virtual
Server Certificates tab.
c (Optional) Check Enable Pool Side SSL to enable the HTTPS communication between the load
balancer and the backend servers.
You can use the pool side SSL to configure End-to-End SSL.
d (Optional) Check Configure Service Certificate to select the applicable service certificate, CA
certificates, and CRLs used to authenticate the load balancer from the server side in the Pool
Certificates tab.
This is only required for the pattern Client -> HTTPS -> LB -> HTTPS -> servers.
You can configure service certificate if the NSX Edge load balancer has CA certificate and CRL
already configured and needs to verify service certificate from backend servers. This option can
also be used to provide load balancer certificate to backend server if the backend server needs to
verify the load balancer side service certificate.
13 Enter the cipher algorithms or cipher suite negotiated during the SSL/TLS handshake. Multiple
ciphers can be added, separated with a colon (:).
DEFAULT DEFAULT
ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
ECDHE-RSA-AES256-SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
ECDHE-ECDSA-AES256-SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
ECDH-ECDSA-AES256-SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
ECDH-RSA-AES256-SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
AES256-SHA TLS_RSA_WITH_AES_256_CBC_SHA
AES128-SHA TLS_RSA_WITH_AES_128_CBC_SHA
DES-CBC3-SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
ECDHE-RSA-AES128-SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
ECDHE-RSA-AES128-SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
AES128-SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256
AES128-GCM-SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256
AES256-SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256
AES256-GCM-SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384
14 Specify whether client authentication is to be ignored or required from the drop-down menu.
If you select required, the client must provide a certificate after the request or the handshake is
aborted.
15 Click OK.
Procedure
8 Click OK.
An application profile allows you to specify HTTP/HTTPS redirection, which always redirects traffic
regardless of the request URLs. You also have the flexibility to specify the conditions in which
HTTP/HTTPS traffic should be redirected.
You can create an application rule to direct requests to a specific load balancer pool according to domain
name. The following rule direct requests to foo.com to pool_1, and requests to bar.com to pool_2.
In the following sample scenario, the load balancer balances a new user to the less loaded server and
resumes a broken session. The NSX Edge internal interface IP address for this scenario is 10.0.0.18,
internal interface IP address is 192.168.1.1, and the virtual servers are 192.168.1.100, 192.168.1.101,
and 192.168.1.102.
# Each user is supposed to get a single active connection at a time, block the second one
tcp-request content reject if { sc1_conn_cur ge 2 }
# if a user tried to get connected at least 10 times over the last minute,
# it could be a brute force
tcp-request content reject if { sc1_conn_rate ge 10 }
7 Associate the application profile to this virtual server and add the application rule created in step 4.
The newly applied application rule on the virtual server protects the RDP servers.
Advanced Logging
By default, NSX load balancer supports basic logging. You can create an application rule as follows to
view more detailed logging messages for troubleshooting.
After you associate the application rule to the virtual server, logs include detailed messages such as the
following example.
To troubleshoot the HTTPS traffic, you may need to add more rules. Most web application use 301/302
responses with a location header to redirect the client to a page (most of the time after a login or a POST
call) and also require an application cookie. So your application server may have difficulty in getting to
know client connection information and may not be able to provide the correct responses: it may even
stop the application from working.
To allow the web application to support SSL offloading, add the following rule.
# See clearly in the log if the application is setting up response for HTTP or HTTPS
capture response header Location len 32
capture response header Set-Cookie len 32
# Provide client side connection info to application server over HTTP header
http-request set-header X-Forwarded-Proto https if { ssl_fc }
http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
The load balancer inserts the following header when the connection is made over SSL.
X-Forwarded-Proto: https
The load balancer inserts the following header when the connection is made over HTTP.
X-Forwarded-Proto: http
You can block requests that contain specific keywords in the URL. The following sample rule checks if the
request starts with /private or /finance and blocks the requests that have those terms.
# If the request is part of the list forbidden urls,reply "Forbidden"(HTTP response code
403)
block if block_url_list
You can redirect a client request that does not have a cookie to get an authentication. The following
sample rule checks if the HTTP request is authentic and has cookies in the header. If the request does
not have cookies then the rule redirects the request to / authent.php for authentication.
You can redirect the client request / to a default page. The following sample rule checks if the HTTP
request is / and redirects the request to a default login page.
When the primary pool is down, you can use a maintenance server pool and redirect the URL to the
maintenance Web site.
By default on the server side NSX closes the TCP connection after each request. When you do not want
to close the server session after each request, you can keep the server session alive and secure with the
NTLM protocol.
no option http-server-close
By default on the client side NSX keeps the TCP connection established between requests. However with
option "X-Forwarded-For", the session is closed after each request. The following option keeps the client
connection open between requests even if XFF is configured.
no option httpclose
You can delete the existing response server header and replace it with another server. The following
sample rule deletes the server header and replaces it with the NGINX Web server that can act as a
reverse proxy server for HTTP, HTTPS, SMTP, POP3, and IMAP protocols, HTTP cache, and a load
balancer.
rspidel Server
rspadd Server:\ nginx
Rewrite Redirect
You can rewrite the Location header from HTTP to HTTPS. The following sample rule identifies the
Location header and replaces the HTTP with HTTP.
You can redirect requests with a specific host to defined pools. The following sample rule checks for the
request for specific hosts app1.xyz.com, app2.xyz.com, and host_any_app3 and redirects these requests
respectively to defined pools, pool_app1, or pool_app2, and pool_app3. All other requests are redirected
to existing pools defined in the Virtual Server.
You can redirect requests with URL keywords to specific pools. The following sample rule checks if the
request starts with /private or /finance and redirects these requests to defined pools, pool_private or
pool_finance. All other requests are redirected to existing pools defined in the Virtual Server.
If your servers in the primary pool are down, you can redirect users to use the servers in the secondary
pool. The following sample rule checks in the pool_production is down and transfers users to
pool_sorry_server.
You can block client IP addresses from accessing your server. The following sample rule blocks the
defined IP address and resets the connection if the client IP address is not in the whitelist.
By default, sslv3 and tlsv1 are disabled service monitor extensions. You can enable them using the
following application rule.
sslv3 enable
tlsv1 enable
Session timeout is the maximum connection inactivity time on the client side. The inactivity timeout
applies when the client is expected to acknowledge or send data. In the HTTP mode, this timeout is
particularly important to consider during the first phase, when the client sends the request, and during the
response while the client is reading the data sent by the server. The default timeout value is five minutes.
The following sample rule sets the timeout period to 100 seconds.
Time can be set as an integer with milliseconds, seconds, minutes, hour, or days.
You can redirects the clients coming on HTTP to the same page on HTTPS.
# Redirect all HTTP requests to same URI but HTTPS redirect scheme
https if !{ ssl_fc }
Replace the response server header "Server" with the value "nginx".
Sorry Server
In case of servers in the primary pool are all dead, use servers in the secondary pool.
Prerequisites
n If you are associating an application rule with the virtual server, see Create an Application Profile.
n If you are enabling acceleration to use the faster load balancer, the acceleration should be enabled
when configuring the load balancer. See Configure Load Balancer Service.
Procedure
7 Check Enable Virtual Server to make this virtual server available for use.
8 (Optional) Check Enable Acceleration for the NSX Edge load balancer to use the faster L4 load
balancer engine rather than L7 load balancer engine.
If a virtual server configuration such as application rules, HTTP type, or cookie persistence, is using
the L7 load balancer engine, then the L7 load balancer engine is used even if you enabled
acceleration or not. The Acceleration Enabled option must be selected under Global Configuration.
You can use the show service loadbalancer virtual CLI command to confirm the load balancer
engine in use.
You can associate only an application profile with the same protocol as the virtual server that you are
adding. The services supported by the selected pool appear.
11 Click Select IP Address to set the IP address that the load balancer is listening on and type the
protocol that the virtual server will handle.
The Select IP Address dialog box shows only the primary IP address. If you are creating a VIP using
a secondary IP address, enter it manually.
12 Select the protocol that the virtual server handles from the drop-down menu.
13 Enter the port number that the load balancer listens on.
You can also set a range of ports for example, 80,8001-8004,443, to share the virtual server
configuration such as, server pool, application profile, and application rule.
To use FTP, the TCP protocol must have port 21 assigned to it.
15 Enter the maximum concurrent connections that the virtual server can process in the Connection
Limit section.
16 Enter the maximum incoming new connection requests per second in the Connection Rate Limit
section.
17 (Optional) Click the Advanced tab and add the application rule to associate it with the virtual server.
18 Click OK.
Procedure
4 Click the Manage tab and then click the Load Balancer tab.
6
Select a profile and click the Edit ( ) icon.
7 Make the appropriate changes to traffic, persistence, certificate, or cipher configuration and click
Finish.
Prerequisites
Go to Manage > Settings > Certificates to ensure that a valid certificate is present. You can upload a
certificate for load balancer as follows:
n In PEM format, or
n Generate a CSR, or
Procedure
1 In the application profile at Manage > Load Balancer > Application Profiles.
Procedure
If using the load balancer service monitor with high availability (HA), HA must be enabled on a dedicated
interface.
After you create a service monitor and associate it with a pool, you can update the existing service
monitor or delete it to save system resources.
For more information about service monitors, refer to Create a Service Monitor.
Procedure
Procedure
Procedure
4 Click the Manage tab and then click the Load Balancer tab.
7
Click the Edit ( ) icon.
Procedure
u In the server pool configuration at Manage > Load Balancer > Pools, enable transparent mode.
Procedure
4 Click the Manage tab and then click the Load Balancer tab.
Procedure
6 Select the required pool, and then click the Show Pool Statistics link.
Pool status can be UP or DOWN. Pool is marked as DOWN when all the members in the pool are
DOWN; otherwise the pool is UP.
n UP: Member is enabled, and the health status of the member is UP. Or monitor is not defined on
the pool.
n DOWN: Member is enabled, and the health status of the member is DOWN.
Procedure
4 Click the Manage tab and then click the Load Balancer tab.
7
Click the Edit ( ) icon.
Procedure
4 Click the Manage tab and then click the Load Balancer tab.
Procedure
Procedure
By default, NSX Load Balancer closes the server TCP connection after each client request, however,
Windows NT LAN Manager (NTLM) authentication requires the same connection for the lifetime of the
authenticated request, connections are kept alive for the duration of the requests.
To keep the server connection open between requests, add the following application rule on the Virtual IP
load balancing the Web servers using NTLM authentication:
add # NTLM authentication and keep the server connection open between requests
no option http-server-close
HTTP Server Close (default) - The server-facing connection is closed once the end of the response is
received, and the client-facing connection remains open. HTTP Server Close provides latency on the
client side (slow network) and the fastest session reuse on the server side to save server resources. It
also permits non-keepalive capable servers to be served in keep-alive from a client perspective. This
mode is suitable for most common use cases, especially for slow client-facing networks and fast server-
facing networks.
HTTP Keep Alive - All requests and responses are processed and connections remain open but idle
between responses and new requests. The advantages are reduced latency between transactions, and
less processing power required on the server side. Note that memory requirements will increase to
accommodate the number of active sessions, which will be higher because connections are no longer
closed after each request. The client-facing idle timeout can be configured via application rule “timeout
http-keep-alive [time]”. By default the idle timeout is 1 second. This mode is mandatory when an
application requires NTLM authentication.
HTTP Tunnel - Only the first request and response are processed and a tunnel is established between
the client and the server, allowing them to talk without further analysis of HTTP protocol. Once
established, the connection is persistent on both the client and server sides. To enable this mode, none of
the following options should be set: passive-close mode, server-close mode, force-close mode.
HTTP tunnel mode impacts the following features, and applies to only the first request and response in a
session:
n cookie processing
n content switching
HTTP Passive Close - The same as tunnel mode, but with a "Connection: close" header added in both
the client and server directions. Both ends close after the first request and response exchange. If "option
httpclose" is set, the NSX Load Balancer works in HTTP tunnel mode and checks if a "Connection: close"
header is present in each direction. If the header is not present, a "Connection: close" header is added.
Each end then actively closes the TCP connection after each transfer, resulting in a switch to the HTTP
close mode. Any connection header other than "close" is removed. Applications that cannot process the
second and subsequent requests properly, such as an inserted cookie by the NSX Load Balancer then
carried back by the following requests from client, can use tunnel mode or passive close mode.
Some HTTP servers do not necessarily close the connections when they receive the "Connection: close"
set by "option httpclose". If the client also does not close, the connection remains open until l the timeout
expires. This causes a high number of simultaneous connections on the servers, and shows high global
session times in the logs. For this reason, they are not compatible with older HTTP 1.0 browsers. If this
occurs, use the "option forceclose" which actively closes the request connection once the server
responds. Option "forceclose" also releases the server connection earlier because it does not have to wait
for the client to acknowledge it.
HTTP Force Close - Both the client and the server connections are actively closed by the NSX Load
Balancer after the end of a response. Some HTTP servers do not necessarily close the connections when
they receive the "Connection: close" set by "option httpclose". If the client also does not close, the
connection remains open until the timeout expires. This causes a high number of simultaneous
connections on the servers and shows high global session times in the logs. When this happens, "option
forceclose" will actively close the outgoing server channel as soon as the server has finished to respond
and release some resources earlier than with "option httpclose".
Default
Connection Connection Mode when X-Forwarded- Available Application Rules
NSX Mode For enabled to switch connection mode
6.1.2 - 6.1.4 HTTP Server HTTP Passive Close (“option httpclose” is “no option http-server-close”
Close added automatically to virtual server) “option httpclose”
“no option httpclose”
6.1.5 - 6.1.x 6.2.0 - 6.2.2 HTTP Server HTTP Server Close xff header is added “no option http-server-close”
Close onto each request from the client when “option httpclose”
dispatching to backend server. “no option httpclose”
6.2.3-6.2.5 HTTP Server HTTP Server Close xff header is added “no option http-server-close”
Close onto each request from the client when “option httpclose”
dispatching to backend server. “no option httpclose”
6.2.3-6.2.5 HTTP Server HTTP Server Close xff header is added “no option http-server-close”
Close onto each request from the client when “no option httpclose”
dispatching to backend server. “option httpclose”
6.2.5 - 6.2.x HTTP Server HTTP Server Close xff header is added “no option http-server-close”
Close onto each request from the client when “option http-keep-alive”
dispatching to backend server. “option http-tunnel”
“option httpclose”
“option forceclose”
Phase 4 Phase 3
IP DST 172.30.40.7 IP DST 192.168.1.20
SRC 192.168.1.20 SRC 192.168.1.3
TCP DST 1025 TCP DST 4099
SRC 80 SRC 80
SLB
192.168.1.3
(Selected)
192.168.1.20
TCP 80
VLAN Logical
V Switch
(VXLAN) 192.168.1.1
In proxy mode, the load balancer uses its own IP address as the source address to send requests to a
backend server. The backend server views all traffic as being sent from the load balancer and responds
to the load balancer directly. This mode is also called SNAT mode or non-transparent mode. For more
information, refer to NSX Administration Guide.
A typical NSX one-armed load balancer is deployed on the same subnet with its backend servers, apart
from the logical router. The NSX load balancer virtual server listens on a virtual IP for incoming requests
from client and dispatches the requests to backend servers. For the return traffic, reverse NAT is required
to change the source IP address from the backend server to a virtual IP (VIP) address and then send the
virtual IP address to the client. Without this operation, the connection to the client would break.
After the ESG receives the traffic, it performs two operations: Destination Network Address Translation
(DNAT) to change the VIP address to the IP address of one of the load balanced machines, and Source
Network Address Translation (SNAT) to exchange the client IP address with the ESG IP address.
Then the ESG server sends the traffic to the load balanced server and the load balanced server sends
the response back to the ESG then back to the client. This option is much easier to configure than the
Inline mode, but has two potentials caveats. The first is that this mode requires a dedicated ESG server,
and the second is that the load balancer servers are not aware of the original client IP address. One
workaround for HTTP/HTTPS applications is to enable Insert X-Forwarded-For in the HTTP application
profile so that the client IP address will be carried in the X-Forwarded-For HTTP header in the request
sent to the backend server.
If client IP address visibility is required on the backend server for applications other than HTTP/HTTPS,
you can configure the IP pool to be transparent. In case clients are not on the same subnet as the
backend server, inline mode is recommended. Otherwise, you must use the load balancer IP address as
the default gateway of the backend server.
n Inline/transparent mode
In DSR mode, the backend server responds directly to the client. Currently, NSX load balancer does not
support DSR.
Procedure
1 As an example, lets configure a one-armed virtual server with SSL offload. Create a certificate by
double-clicking the Edge and then selecting Manage > Settings > Certificate.
2 Enable the load balancer service by selecting Manage > Load Balancer > Global Configuration >
Edit.
3 Create an HTTPS application profile by selecting Manage > Load Balancer > Application Profiles.
Note The screenshot above uses self-signed certificates for documentation-purposes only.
4 Optionally, click Manage > Load Balancer > Service Monitoring and edit the default service
monitoring to change it from basic HTTP/HTTPS to specific URL/URIs, as required.
5 Create server pools by selecting Manage > Load Balancer > Pools.
To use SNAT mode, leave the Transparent check box unchecked in the pool configuration.
6 Optionally, click Manage > Load Balancer > Pools > Show Pool Statistics to check the status.
7 Create a virtual server by selecting Manage > Load Balancer > Virtual Servers.
If you would like to use the L4 load balancer for UDP or higher-performance TCP, check Enable
Acceleration. If you check Enable Acceleration, make sure that the firewall status is Enabled on
the load balancer NSX Edge, because a firewall is required for L4 SNAT.
8 Optionally, if using an application rule, check the configuration in Manage > Load Balancer >
Application Rules.
9 If using an application rule, ensure that the application rule is associated with the virtual server in
Manage > Load Balancer > Virtual Servers > Advanced.
In non-transparent mode, the backend server cannot see the client IP, but can see the load balancer
internal IP address. As a workaround for HTTP/HTTPS traffic, check Insert X-Forwarded-For HTTP
header. With this option checked, the Edge load balancer adds the header "X-Forwarded-For" with
the value of the client source IP address.
After you configure the NSX load balancer, you can provide the NSX Edge device uplink interface IP
address for vCenter Single Sign-On.
Prerequisites
n Perform the PSC High Availability preparation tasks listed in the knowledge. See
http://kb.vmware.com/kb/2113315.
n Save the /ha/lb.crt and /ha/lb_rsa.key from first PSC node to configure certificates.
n Verify that you have at least one uplink for configuring VIP and one interface attached to internal
logical switch.
Procedure
a Save the PSC root.cer and certificate, RSA and passphrase generated from the OpenSSL
command.
b Double-click the Edge and select Manage > Settings > Certificate .
Procedure
f Click the Add ( ) icon, and select Certificate. For more details, refer to Working with
Certificates.
g Copy and paste the certificate contents in the Certificate Contents text box. Text should include
"-----BEGIN xxx-----" and "-----END xxx-----".
For chain certificate (certificate with the intermediate or root CA), select the CA Certificate
option. Following is example of the chain certificate content:
-----BEGIN CERTIFICATE-----
Server cert
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate cert
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Root cert
-----END CERTIFICATE-----
h Copy and paste the private key contents in the Private Key text box.
The certificate content (PEM for certificate or private key) should be prefixed with one of the
following strings:
For complete examples of certificate and private key, refer to the Example: Certificate and Private
Key topic.
a Navigate to Edge.
c In the left navigation panel, click Application Profile. For more details, refer to Managing
Application Profiles.
a Navigate to Edge.
c In the left navigation panel, click Virtual Servers. For more details, refer to Managing Application
ProfilesManaging Virtual Servers.
n Select the Enable Virtual Server check box to make the virtual server available for use.
n Select the default pool that is composed of HTTP servers (not HTTPS servers).
-----BEGIN CERTIFICATE-----
MIID0DCCArigAwIBAgIBATANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJGUjET
MBEGA1UECAwKU29tZS1TdGF0ZTEOMAwGA1UEBwwFUGFyaXMxDTALBgNVBAoMBERp
bWkxDTALBgNVBAsMBE5TQlUxEDAOBgNVBAMMB0RpbWkgQ0ExGzAZBgkqhkiG9w0B
CQEWDGRpbWlAZGltaS5mcjAeFw0xNDAxMjgyMDM2NTVaFw0yNDAxMjYyMDM2NTVa
MFsxCzAJBgNVBAYTAkZSMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJ
bnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxFDASBgNVBAMMC3d3dy5kaW1pLmZyMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvpnaPKLIKdvx98KW68lz8pGa
RRcYersNGqPjpifMVjjE8LuCoXgPU0HePnNTUjpShBnynKCvrtWhN+haKbSp+QWX
SxiTrW99HBfAl1MDQyWcukoEb9Cw6INctVUN4iRvkn9T8E6q174RbcnwA/7yTc7p
1NCvw+6B/aAN9l1G2pQXgRdYC/+G6o1IZEHtWhqzE97nY5QKNuUVD0V09dc5CDYB
aKjqetwwv6DFk/GRdOSEd/6bW+20z0qSHpa3YNW6qSp+x5pyYmDrzRIR03os6Dau
ZkChSRyc/Whvurx6o85D6qpzywo8xwNaLZHxTQPgcIA5su9ZIytv9LH2E+lSwwID
AQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVy
YXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU+tugFtyN+cXe1wxUqeA7X+yS3bgw
HwYDVR0jBBgwFoAUhMwqkbBrGp87HxfvwgPnlGgVR64wDQYJKoZIhvcNAQEFBQAD
ggEBAIEEmqqhEzeXZ4CKhE5UM9vCKzkj5Iv9TFs/a9CcQuepzplt7YVmevBFNOc0
+1ZyR4tXgi4+5MHGzhYCIVvHo4hKqYm+J+o5mwQInf1qoAHuO7CLD3WNa1sKcVUV
vepIxc/1aHZrG+dPeEHt0MdFfOw13YdUc2FH6AqEdcEL4aV5PXq2eYR8hR4zKbc1
fBtuqUsvA8NWSIyzQ16fyGve+ANf6vXvUizyvwDrPRv/kfvLNa3ZPnLMMxU98Mvh
PXy3PkB8++6U4Y3vdk2Ni2WYYlIls8yqbM4327IKmkDc2TimS8u60CT47mKU7aDY
cbTV5RDkrlaYwm5yqlTIglvCv7o=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIID0DCCArigAwIBAgIBATANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJGUjET
MBEGA1UECAwKU29tZS1TdGF0ZTEOMAwGA1UEBwwFUGFyaXMxDTALBgNVBAoMBERp
bWkxDTALBgNVBAsMBE5TQlUxEDAOBgNVBAMMB0RpbWkgQ0ExGzAZBgkqhkiG9w0B
CQEWDGRpbWlAZGltaS5mcjAeFw0xNDAxMjgyMDM2NTVaFw0yNDAxMjYyMDM2NTVa
MFsxCzAJBgNVBAYTAkZSMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJ
bnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxFDASBgNVBAMMC3d3dy5kaW1pLmZyMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvpnaPKLIKdvx98KW68lz8pGa
RRcYersNGqPjpifMVjjE8LuCoXgPU0HePnNTUjpShBnynKCvrtWhN+haKbSp+QWX
SxiTrW99HBfAl1MDQyWcukoEb9Cw6INctVUN4iRvkn9T8E6q174RbcnwA/7yTc7p
1NCvw+6B/aAN9l1G2pQXgRdYC/+G6o1IZEHtWhqzE97nY5QKNuUVD0V09dc5CDYB
aKjqetwwv6DFk/GRdOSEd/6bW+20z0qSHpa3YNW6qSp+x5pyYmDrzRIR03os6Dau
ZkChSRyc/Whvurx6o85D6qpzywo8xwNaLZHxTQPgcIA5su9ZIytv9LH2E+lSwwID
AQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVy
YXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU+tugFtyN+cXe1wxUqeA7X+yS3bgw
HwYDVR0jBBgwFoAUhMwqkbBrGp87HxfvwgPnlGgVR64wDQYJKoZIhvcNAQEFBQAD
ggEBAIEEmqqhEzeXZ4CKhE5UM9vCKzkj5Iv9TFs/a9CcQuepzplt7YVmevBFNOc0
+1ZyR4tXgi4+5MHGzhYCIVvHo4hKqYm+J+o5mwQInf1qoAHuO7CLD3WNa1sKcVUV
vepIxc/1aHZrG+dPeEHt0MdFfOw13YdUc2FH6AqEdcEL4aV5PXq2eYR8hR4zKbc1
fBtuqUsvA8NWSIyzQ16fyGve+ANf6vXvUizyvwDrPRv/kfvLNa3ZPnLMMxU98Mvh
PXy3PkB8++6U4Y3vdk2Ni2WYYlIls8yqbM4327IKmkDc2TimS8u60CT47mKU7aDY
cbTV5RDkrlaYwm5yqlTIglvCv7o=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDyTCCArGgAwIBAgIBADANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJGUjET
MBEGA1UECAwKU29tZS1TdGF0ZTEOMAwGA1UEBwwFUGFyaXMxDTALBgNVBAoMBERp
bWkxDTALBgNVBAsMBE5TQlUxEDAOBgNVBAMMB0RpbWkgQ0ExGzAZBgkqhkiG9w0B
CQEWDGRpbWlAZGltaS5mcjAeFw0xNDAxMjgyMDI2NDRaFw0yNDAxMjYyMDI2NDRa
MH8xCzAJBgNVBAYTAkZSMRMwEQYDVQQIDApTb21lLVN0YXRlMQ4wDAYDVQQHDAVQ
YXJpczENMAsGA1UECgwERGltaTENMAsGA1UECwwETlNCVTEQMA4GA1UEAwwHRGlt
aSBDQTEbMBkGCSqGSIb3DQEJARYMZGltaUBkaW1pLmZyMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAuxuG4QeBIGXj/AB/YRLLtpgpTpGnDntVlgsycZrL
3qqyOdBNlwnvcB9etfY5iWzjeq7YZRr6i0dIV4sFNBR2NoK+YvdD9j1TRi7njZg0
d6zth0xlsOhCsDlV/YCL1CTcYDlKA/QiKeIQa7GU3Rhf0t/KnAkr6mwoDbdKBQX1
D5HgQuXJiFdh5XRebxF1ZB3gH+0kCEaEZPrjFDApkOXNxEARZdpBLpbvQljtVXtj
HMsvrIOc7QqUSOU3GcbBMSHjT8cgg8ssf492Go3bDQkIzTROz9QgDHaqDqTC9Hoe
vlIpTS+q/3BCY5AGWKl3CCR6dDyK6honnOR/8srezaN4PwIDAQABo1AwTjAdBgNV
HQ4EFgQUhMwqkbBrGp87HxfvwgPnlGgVR64wHwYDVR0jBBgwFoAUhMwqkbBrGp87
HxfvwgPnlGgVR64wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEAVqYq
vhm5wAEKmvrKXRjeb5kiEIp7oZAFkYp6sKODuZ1VdkjMDD4wv46iqAe1QIIsfGwd
Dmv0oqSl+iPPy24ATMSZQbPLO5K64Hw7Q8KPos0yD8gHSg2d4SOukj+FD2IjAH17
a8auMw7TTHu6976JprQQKtPADRcfodGd5UFiz/6ZgLzUE23cktJMc2Bt18B9OZII
J9ef2PZxZirJg1OqF2KssDlJP5ECo9K3EmovC5M5Aly++s8ayjBnNivtklYL1VOT
ZrpPgcndTHUA5KS/Duf40dXm0snCxLAKNP28pMowDLSYc6IjVrD4+qqw3f1b7yGb
bJcFgxKDeg5YecQOSg==
-----END CERTIFICATE-----
Procedure
f Click the Add ( ) icon, and select Certificate. For more details, refer to Working with
Certificates.
g Copy and paste the certificate contents in the Certificate Contents text box. Text should include
"-----BEGIN xxx-----" and "-----END xxx-----".
For chain certificate (certificate with the intermediate or root CA), select the CA Certificate
option. Following is example of the chain certificate content:
-----BEGIN CERTIFICATE-----
Server cert
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate cert
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Root cert
-----END CERTIFICATE-----
h Copy and paste the private key contents in the Private Key text box.
The certificate content (PEM for certificate or private key) should be prefixed with one of the
following strings:
For complete examples of certificate and private key, refer to the Example: Certificate and Private
Key topic.
e In the left navigation panel, click Application Profile. For more details, refer to Managing
Application Profiles.
e In the left navigation panel, click Virtual Servers. For more details, refer to Managing Virtual
Servers.
n Select the Enable Virtual Server check box to make the virtual server available for use.
Prerequisites
Note Certificates are not required for the HTTPS passthrough scenario.
Procedure
e In the left navigation panel, click Application Profile. For more details, refer to Managing
Application Profiles.
Note Certificates are not required for the HTTPS passthrough scenario.
e In the left navigation panel, click Virtual Servers. For more details, refer to Managing Virtual
Servers.
n Select the Enable Virtual Server check box to make the virtual server available for use.
Note If Enable Acceleration check box is selected and there are no L7 related configurations,
the session would NOT be terminated by the edge.
If Enable Acceleration check box is not selected, the session would be treated as L7 TCP mode,
and edge will terminate it into two sessions.
Client Authentication
Clients access the Web application through HTTPS. HTTPS is terminated on the edge VIP and requests
for client certificate.
1 Import the Web server certificate along with root CA. For details, refer to Scenario: Import SSL
Certificate.
b Select the Virtual Server Certificates tab, and then select CA Certificates tab. CA is used to
verify client certificate.
Note If the Client Authentication option is set to Ignore, load balancer ignores the client
certificate authentication.
3 Create a virtual server. For details, refer to Scenario: Import SSL Certificate.
Note If the Enable Pool Side SSL option is disabled in the application profile, the pool selected is
composed of HTTP servers. If the Enable Pool Side SSL option is enabled in the application profile,
the pool selected is composed of HTTPS servers.
b Convert certificate and private key to the pfx file. For complete examples of certificate and private
key, refer to the Example: Certificate and Private Key topic.
Server Authentication
Clients access the Web application through HTTPS. HTTPS is terminated on the edge VIP. The edge
establish new HTTPS connections to the servers, it requests and verifies server certificate.
1 Import the Web server certificate and root CA certificate for server certificate authentication. For
details, refer to Scenario: Import SSL Certificate.
c Select the Pool Certificates tab, and then select CA Certificates tab. CA is used to verify client
certificate from backend HTTPS server.
After upgrading from old version, if cipher is null/empty or not in approved ciphers suite in the old
version, it resets to Default.
3 Create a virtual server. For details, refer to Scenario: Import SSL Certificate.
Note If the Enable Pool Side SSL option is disabled in the application profile, the pool selected is
composed of HTTP servers. If the Enable Pool Side SSL option is enabled in the application profile,
the pool selected is composed of HTTPS servers.
You must have a working NSX Edge instance before you can use any of the above services. For
information on setting up NSX Edge, see NSX Edge Configuration.
n Uses the IP address of the internal interface on NSX Edge as the default gateway address for all
clients (except for non-directly connected pools), and the broadcast and subnet mask values of the
internal interface for the container network.
You must restart the DHCP service on client virtual machines in the following situations:
n You changed or deleted a DHCP pool, default gateway, or DNS server.
An IP pool is a sequential range of IP addresses within the network. Virtual machines protected by NSX
Edge that do not have an address binding are allocated an IP address from this pool. An IP pool's range
cannot intersect one another, thus one IP address can belong to only one IP pool.
Procedure
Option Action
Auto Configure DNS Select to use the DNS service configuration for the DHCP binding.
Lease never expires Select to bind the address to the MAC address of the virtual machine forever. If
you select this, Lease Time is disabled.
Domain Name Enter the domain name of the DNS server. This is optional.
Primary Name Server If you did not select Auto Configure DNS, type the Primary Nameserver for the
DNS service. You must enter the IP address of a DNS server for hostname-to-IP
address resolution. This is optional.
Secondary Name Server If you did not select Auto Configure DNS, type the Secondary Nameserver for
the DNS service. You must enter the IP address of a DNS server for hostname-to-
IP address resolution. This is optional.
Default Gateway Enter the default gateway address. If you do not specify the default gateway IP
address, the internal interface of the NSX Edge instance is taken as the default
gateway. This is optional.
Subnet Mask Specify the subnet mask. The subnet mask must be same as the subnet mask of
the Edge interface or the DHCP Relay, in case of distributed router.
Lease Time Select whether to lease the address to the client for the default time (1 day), or
enter a value in seconds. You cannot specify the lease time if you selected Lease
never expires. This is optional.
In NSX 6.2.5 and later, if a DHCP pool is configured on an Edge Services Gateway with both
classless static routes and a default gateway, the default gateway is added as a classless static route.
Option Action
Next Server Next boot TFTP server, used by the PXE boot or bootp.
TFTP server name (option 66) Enter a unicast IPv4 address or a host name that the device should use to
download the file specified in bootfile name (option 67).
TFTP server address (option 150) Enter one or more TFTP server IPv4 addresses.
Bootfile name (option 67) Enter the bootfile file name that is to be downloaded from the server specified in
TFTP server name (option 66).
Option Action
Interface MTU (option 26) The Maximum Transmission Unit (MTU) is the maximum frame size that can be
sent between two hosts without fragmentation. This option specifies the MTU size
to be used on the interface. One MTU size (in bytes) can be set for each pool and
static binding. The MTU minimum value is 68 bytes and the maximum value is
65535 bytes. If the interface MTU is not set on the DHCP server, DHCP clients
will keep the OS default setting of the interface MTU.
Classless static route (option 121) Each classless static route option may have multiple routes with the same
destination. Each route includes a destination subnet, subnet mask, next hop
router . Note that 0.0.0.0/0 is an invalid subnet for a static route. For information
about classless static routes and option 121, refer to RFC 3442.
a
Click the Add ( ) icon.
b Enter the destination and the next hop router IP address.
8 Click OK.
Prerequisites
Procedure
4 Click the Manage tab and then click the DHCP tab.
5 Click Enable.
Note VMware strongly recommends creating a firewall rule to prevent malicious users from introducing
rogue DHCP servers. To do this, add a firewall rule that allows UDP traffic only on ports 67 and 68 when
the traffic is going to or from a valid DHCP server IP address. For details, refer to Working with Firewall
Rules.
What to do next
Procedure
4 Click the Manage tab and then click the DHCP tab.
Procedure
4 Click the Manage tab and then click the DHCP tab.
Option Action
Auto Configure DNS Select to use the DNS service configuration for the DHCP binding.
Lease never expires Select to bind the address to the MAC address of the virtual machine forever.
VM vNIC Index Select the virtual machine NIC to bind to the IP address.
Host Name Type the host name of the DHCP client virtual machine.
IP Address Type the address to which to bind the MAC address of the selected virtual
machine.
Subnet Mask Specify the subnet mask. The subnet mask should be same as the subnet mask
of the Edge interface or the DHCP Relay, in case of distributed router.
Option Action
Primary Name Server If you did not select Auto Configure DNS, type the Primary Nameserver for the
DNS service. You must enter the IP address of a DNS server for hostname-to-IP
address resolution.
Secondary Name Server If you did not select Auto Configure DNS, type the Secondary Nameserver for
the DNS service. You must enter the IP address of a DNS server for hostname-to-
IP address resolution.
Default Gateway Type the default gateway address. If you do not specify the default gateway IP
address, the internal interface of the NSX Edge instance is taken as the default
gateway.
Lease Time If you did not select Lease never expires, select whether to lease the address to
the client for the default time (1 day), or type a value in seconds.
8 Click Add.
Procedure
4 Click the Manage tab and then click the DHCP tab.
5 Select Bindings from the left panel and click the binding to edit.
DHCP configuration is applied on the logical router port and can list several DHCP servers. Requests are
sent to all listed servers. While relaying the DHCP request from the client, the relay adds a Gateway IP
Address to the request. The external DHCP server uses this gateway address to match a pool and
allocate an IP address for the request. The gateway address must belong to a subnet of the NSX port on
which the relay is running.
You can specify a different DHCP server for each logical switch and can configure multiple DHCP servers
on each logical router to provide support for multiple IP domains.
When configuring pool and binding at DHCP server, ensure that the subnet mask of the pool/binding for
the relayed queries is same as the interface of the DHCP relay. Subnet mask information must be
provided in API while DLR is acting as DHCP relay between VMs and Edge providing DHCP service. This
subnet mask should match the one configured on gateway interface for VMs on DLR.
NSX DHCP
server X
DHCP
server Y
Relay Server Y
Distributed
router
Logical Logical
Switch Switch
Note
n DHCP relay does not support overlapping IP address space (option 82).
n DHCP Relay and DHCP service cannot run on a port/vNic at the same time. If a relay agent is
configured on a port, a DHCP pool cannot be configured on the subnet(s) of this port.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > NSX Edges.
2 Double-click the appropriate Edge and ensure that that you are in the Manage > DHCP tab.
b
Move the selected IP set to the Selected Objects list by clicking the icon.
c Click OK.
5 To add IP addresses or domain names, type the address or name in the appropriate area.
6 Click OK.
Procedure
The Gateway IP Address displays the primary IP address of the selected vNic.
3 Click OK.
Procedure
4 Click the Manage tab and then click the Settings tab.
9 Click Enable Logging to log DNS traffic and select the log level.
10 Click Ok.
Security Group
You begin by creating a security group to define assets that you want to protect. Security groups may be
static (including specific virtual machines) or dynamic where membership may be defined in one or more
of the following ways:
n Security tags, IPset, MACset, or even other security groups. For example, you may include a criteria
to add all members tagged with the specified security tag (such as AntiVirus.virusFound) to the
security group.
Note that security group membership changes constantly. For example, a virtual machine tagged with the
AntiVirus.virusFound tag is moved into the Quarantine security group. When the virus is cleaned and this
tag is removed from the virtual machine, it again moves out of the Quarantine security group.
Security Policy
Firewall rules Rules that define the traffic to be allowed to, from, or within the security group. vNIC
Endpoint service Third party solution provider services such as anti-virus or vulnerability virtual machines
management services.
Network Services that monitor your network such as IPS. virtual machines
introspection
services
During service deployment in NSX, the third party vendor selects the service category for the service
being deployed. A default service profile is created for each vendor template.
When third party vendor services are upgraded to NSX 6.1, default service profiles are created for the
vendor templates being upgraded. Existing service policies that include Guest Introspection rules are
updated to refer to the service profiles created during the upgrade.
You map a security policy (say SP1) to a security group (say SG1). The services configured for SP1 are
applied to all virtual machines that are members of SG1.
Note When you have many security groups to which you need to attach the same security policy, create
an umbrella security group that includes all these child security groups, and apply the common security
policy to the umbrella security group. This will ensure that the NSX distributed firewall utilises ESXi host
memory efficiently.
Security group
If a virtual machine belongs to more than one security group, the services that are applied to the virtual
machine depends on the precedence of the security policy mapped to the security groups.
Service Composer profiles can be exported and imported as backups or for use in other environments.
This approach to managing network and security services helps you with actionable and repeatable
security policy management.
Let us walk through an example to show how Service Composer helps you protect your network end-to-
end. Let us say you have the followings security policies defined in your environment:
n An initial state security policy that includes a vulnerability scanning service (InitStatePolicy)
n A remediation security policy that includes a network IPS service in addition to firewall rules and an
anti-virus service (RemPolicy)
Ensure that the RemPolicy has higher weight (precedence) than InitStatePolicy.
n An applications assets group that includes the business critical applications in your environment
(AssetGroup)
n A remediation security group defined by a tag that indicates the virtual machine is vulnerable
(VULNERABILITY_MGMT.VulnerabilityFound.threat=medium) named RemGroup
You now map the InitStatePolicy to AssetGroup to protect all business critical applications in your
environment. You also map RemPolicy to RemGroup to protect vulnerable virtual machines.
When you initiate a vulnerability scan, all virtual machines in AssetGroup are scanned. If the scan
identifies a virtual machine with a vulnerability, it applies the
VULNERABILITY_MGMT.VulnerabilityFound.threat=medium tag to the virtual machine.
Service Composer instantly adds this tagged virtual machine to RemGroup, where a network IPS solution
is already in place to protect this vulnerable virtual machine.
VULNERABILITY_MGMT,
VulnerabilityFound.threat
=medium
Business Critical
Application
Security Group
VULNERABILITY_MGMT, VULNERABILITY_MGMT,
VulnerabilityFound.threat VulnerabilityFound.threat
=medium =medium
This topic will now take you through the steps required to consume the security services offered by
Service Composer.
Prerequisites
If you are creating a security policy for use with remote desktop access, ensure that:
n The Applied to field is not supported for rules for remote desktop access.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
Security groups for use with Identity Firewall for RDSH, must use security policies that are marked
"Enable User Identity at Source" when created. Security groups for use with Identity Firewall for
RDSH can only contain Active Directory (AD) groups, and all nested security groups must also be AD
groups.
4 Type a name and description for the security group and click Next.
5 On the Dynamic Membership page, define the criteria that an object must meet for it to be added to
the security group you are creating.
For example, you may include a criteria to add all members tagged with the specified security tag
(such as AntiVirus.virusFound) to the security group.
Or you can add all virtual machines containing the name W2008 AND virtual machines that are in the
logical switch global_wire to the security group.
Note If you define a security group by virtual machines that have a certain security tag applied to
them, you can create a dynamic or conditional workflow. The moment the tag is applied to a virtual
machine, the virtual machine is automatically added to that security group.
6 Click Next.
7 On the Select objects to include page, select the object type from the drop-down.
Note that security groups for use in remote desktop sessions can only contain Directory groups.
8 Double-click the object you want to add to the include list. You can include the following objects in a
security group.
n Other security groups to nest within the security group you are creating.
n Cluster
n Logical switch
n Network
n Virtual App
n Datacenter
n IP sets
n AD groups
Note The AD configuration for NSX security groups is different from the AD configuration for
vSphere SSO. NSX AD group configuration is for end users accessing guest virtual machines
while vSphere SSO is for administrators using vSphere and NSX.
n MAC Sets
Note Service Composer allows use of Security Groups that contain MAC Sets in Policy
configurations, however, Service Composer fails to enforce rules for that specific MAC Set.
Service Composer works on Layer 3 and does not support Layer 2 constructs.
n Security tag
n vNIC
n Virtual Machine
n Resource Pool
When you add a resource to a security group, all associated resources are automatically added. For
example, when you select a virtual machine, the associated vNIC is automatically added to the
security group.
9 Click Next and double-click the objects that you want to exclude from the security group.
The objects selected here are always excluded from the security group even if they match the
dynamic criteria or are selected in the include list .
10 Click Finish.
{Expression result (derived from Step 5) + Inclusions (specified inStep 8} - Exclusion (specified in Step 9)
which means that inclusion items are first added to the expression result. Exclusion items are then
subtracted from the combined result.
Prerequisites
Ensure that:
n the required VMware built in services (such as Distributed Firewall, and Guest Introspection) are
installed.
n the required partner services have been registered with NSX Manager.
n the desired default applied to value is set for Service Composer firewall rules. See Edit Service
Composer Firewall Applied To Setting.
If you are creating a security policy framework for Identity Firewall for RDSH:
n The Applied to field is not supported for rules for remote desktop access.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
3
Click the Create Security Policy ( ) icon.
4 In the New Security Policy dialog box, type a name for the security policy.
NSX assigns a default weight (highest weight +1000) to the policy. For example, if the highest weight
amongst the existing policy is 1200, the new policy is assigned a weight of 2200.
Security policies are applied according to their weight - a policy with the higher weight has
precedence over a policy with a lower weight.
6 Select Inherit security policy from specified policy if you want the policy that you are creating to
receive services from another security policy. Select the parent policy.
All services from the parent policy are inherited by the new policy.
7 Click Next.
8 In the Guest Introspection Services page, click the Add Guest Introspection Service ( ) icon.
a In the Add Guest Introspection Service dialog box, type a name and description for the service.
When you inherit a security policy, you may choose to block a service from the parent policy.
If you apply a service, you must select a service and service profile. If you block a service, you
must select the type of service to block.
d If you chose to apply the Guest Introspection service, select the service name.
The default service profile for the selected service is displayed, which includes information about
the service functionality types supported by the associated vendor template.
e In State, specify whether you want to enable the selected Guest Introspection service or disable
it.
You can add Guest Introspection services as placeholders for services to be enabled at a later
time. This is especially useful for cases where services need to be applied on-demand (for
example, new applications).
f Select whether the Guest Introspection service is to be enforced (i.e. it cannot be overridden). If
the selected service profile supports multiple service functionality types, then this is set to
Enforce by default and cannot be changed.
If you enforce a Guest Introspection service in a security policy, other policies that inherit this
security policy would require that this policy be applied before the other child policies. If this
service is not enforced, an inheritance selection would add the parent policy after the child
policies are applied.
g Click OK.
You can add additional Guest Introspection services by following the above steps. You can manage
the Guest Introspection services through the icons above the service table.
You can export or copy the services on this page by clicking the icon on the bottom right side of
the Guest Introspection Services page.
9 Click Next.
Here, you are defining firewall rules for the security groups(s) that this security policy will be applied
to.
When creating a security policy for Identity Firewall for RDSH, Enable User Identity at Source must
be checked. Note that this disables the enable stateless firewall option because the TCP connection
state is tracked for identifying the context. This flag cannot be changed while the policy is being
updated. Once a security policy is created with Enable User Identity at Source inheritance is not
supported.
a Type a name and description for the firewall rule you are adding.
b Select Allow or Block to indicate whether the rule needs to allow or block traffic to the selected
destination.
c Select the source for the rule. By default, the rule applies to traffic coming from the security
groups to which this policy gets applied to. To change the default source, click Change and select
the appropriate security groups.
Note Either the Source or Destination (or both) must be security groups to which this policy gets
applied to.
Say you create a rule with the default Source, specify the Destination as Payroll, and select
Negate Destination. You then apply this security policy to security group Engineering . This
would result in Engineering being able to access everything except for the Payroll server.
e Select the services and/or service groups to which the rule applies to.
h Click OK.
You can add additional firewall rules by following the above steps. You can manage the firewall rules
through the icons above the firewall table.
You can export or copy the rules on this page by clicking the icon on the bottom right side of the
Firewall page.
The firewall rules you add here are displayed on the Firewall table. VMware recommends that you do
not edit Service Composer rules in the firewall table. If you must do so for an emergency
troubleshooting, you must re-synchronize Service Composer rules with firewall rules by selecting
Synchronize Firewall Rules from the Actions menu in the Security Policies tab.
11 Click Next.
The Network Introspection Services page displays NetX services that you have integrated with your
VMware virtual environment.
a Enter a name and description for the service you are adding.
You can make additional selections based on the service you selected.
h Click OK.
You can add additional network introspection services by following the above steps. You can manage
the network introspection services through the icons above the service table.
You can export or copy the services on this page by clicking the icon on the bottom right side of
the Network Introspection Service page.
Note Bindings created manually for the Service Profiles used in Service Composer policies will be
overwritten.
13 Click Finish.
The security policy is added to the policies table. You can click the policy name and select the
appropriate tab to view a summary of the services associated with the policy, view service errors, or
edit a service.
What to do next
When Service Composer firewall rules have an applied to setting of distributed firewall, the rules are
applied to all clusters on which distributed firewall is installed. If the firewall rules are set to apply to the
policy's security groups, you have more granular control over the firewall rules, but may need multiple
security policies or firewall rules to get the desired result.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
3 Click Actions > Edit Firewall Policy Settings. Select a default setting for Applied To and click OK.
Option Description
Distributed Firewall Firewall rules are applied to all clusters on which Distributed Firewall is installed.
Policy's Security Groups Firewall rules are applied to security groups on which the security policy is
applied.
The default Applied To setting can also be viewed and changed via the API. See the NSX API Guide.
In this example scenario, your default firewall rule action is set to block. You have two security groups:
web-servers and app-servers, which contain VMs. You create a security policy, allow-ssh-from-web, which
contains the following firewall rule, and apply it to the security group app-servers.
n Name: allow-ssh-from-web
n Source: web-servers
n Service: ssh
n Action: allow
If the firewall rule applies to Distributed Firewall, you will be able to ssh from a VM in the security group
web-servers to a VM in the security group app-servers.
If the firewall rule applies to Policy's Security Group, you will not be able to ssh, as the traffic will be
blocked from reaching the app servers. You will need to create an additional security policy to allow ssh to
the app servers, and apply this policy to the security group web-servers.
n Name: allow-ssh-to-app
n Destination: app-servers
n Service: ssh
n Action: allow
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
3
Select a security policy and click the Apply Security Policy ( ) icon.
4 Select the security group that you want to apply the policy to.
Security groups for use with Identity Firewall for RDSH, must use security policies that are marked
"Enable User Identity at Source" when created. Security groups for use with Identity Firewall for
RDSH can only contain Active Directory (AD) groups, and all nested security groups must also be AD
groups.
If you select a security group defined by virtual machines that have a certain security tag applied to
them, you can create a dynamic or conditional workflow. The moment the tag is applied to a virtual
machine, the virtual machine is automatically added to that security group.
Network Introspection rules and Endpoint rules associated with the policy will not take effect for
security groups containing IPSet and/or MacSet members.
5 Click the Preview Service Status icon to see the services that cannot be applied to the selected
security group and the reason for the failure.
For example, the security group may include a virtual machine that belongs to a cluster on which one
of the policy services has not been installed. You must install that service on the appropriate cluster
for the security policy to work as intended.
6 Click OK.
This topic introduces Service Composer by walking you through a partially configured system so that you
can visualize the mappings between security groups and security policy objects at a high level from the
canvas view.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
All security groups within the selected NSX Manager (that are not contained within another security
group) are displayed along with the policies applied on them. The NSX Manager drop-down lists all
NSX Managers on which the currently logged in user has a role assigned.
Each rectangular box in the canvas represents a security group and the icons within the box represents
security group members and details about the security policy mapped to the security group.
A number next to each icon indicates the number of instances - for example, indicates that 1
security policy is mapped to that security group.
Virtual machines that are currently part of the main security group as well as nested security groups. Click the Errors tab
to see virtual machines with service errors.
Effective Endpoint services associated with the security policy mapped to the security group. Suppose you have two
policies applied to a security group and both have the same category Endpoint service configured. The effective service
count in this case will be 1 (since the second lower priority service is overridden).
Endpoint service failures, if any, are indicated by the alert icon. Clicking the icon displays the error.
Effective firewall rules associated with the security policy mapped to the security group.
Service failures, if any, are indicated by the alert icon. Clicking the icon displays the error.
Effective network introspection services associated with the security policy mapped to the security group.
Service failures, if any, are indicated by the alert icon. Clicking the icon displays the error.
Figure 18‑5. Details displayed when you click an icon in the security group
You can search for security groups by name. For example, if you type PCI in the search field in the top
right corner of the canvas view, only the security groups with PCI in their names are displayed.
To see the security group hierarchy, click the Top Level ( ) icon at the top left of the window and select
the security group you want to display. If a security group contains nested security groups, click to
display the nested groups. The top bar displays the name of the parent security group and the icons in
the bar display the total number of security policies, endpoint services, firewall services, and network
introspection services applicable to the parent group. You can navigate back up to the top level by clicking
the Go up one level ( ) icon in the top left part of the window.
You can zoom in and out of the canvas view smoothly by moving the zoom slider on the top right corner
of the window. The Navigator box shows a zoomed out view of the entire canvas. If the canvas is much
bigger than what fits on your screen, it will show a box around the area that is actually visible and you can
move it to change the section of the canvas that is being displayed.
What to do next
Now that we have seen how the mapping between security groups and security policies work, you can
begin creating security policies to define the security services you want to apply to your security groups.
Procedure
1 Select the security policy that you want to apply to the security group.
3 Click Save.
Security tags are labels which can be associated with a Virtual Machine (VM). Numerous security tags
can be created to identify a specific workload. The matching criteria of a Security Group can be a security
tag, and a workload that is tagged can be automatically placed into a Security Group.
Adding or removing security tags to a VM can be done dynamically in response to various criteria such as
antivirus or vulnerability scans, and intrusion prevention systems. Tags can also be added and removed
manually by an administrator.
In a cross-vCenter NSX environment, universal security tags are created on the primary NSX manager
and are marked for universal synchronization with secondary NSX managers. Universal security tags can
be assigned to VMs statically, based on unique ID selection.
Unique ID Selection
The unique ID selection criteria is used when assigning tags to Virtual Machines on active standby
deployments.
Unique ID is used by the NSX Manager when a Virtual Machine (VM) goes from standby to active
deployment. The unique ID can be based on VM instance UUID, VM BIOS UUID, or VM name or a
combination of these options. Note that if the criteria changes (such as a VM name changes) after
universal security tags have been created and attached to VMs, the security tag must be detached and
reattached to the VMs.
Procedure
1 In the vSphere Web Client, navigate to Home > Networking & Security > Installation and
Upgrade, click the Management tab.
2 Click the primary NSX Manager. Then select Actions > Unique ID Selection Criteria.
n Use Virtual Machine instance UUID (recommended) - The VM instance UUID is generally unique
within a VC domain, however there are exceptions such as when deployments are made through
snapshots. If the VM instance UUID is not unique we recommend you use the VM BIOS UUID in
combination with the VM name.
n Use Virtual Machine BIOS UUID - The BIOS UUID is not guaranteed to be unique within a VC
domain, but it is always preserved in case of disaster. We recommend you use BIOS UUID in
combination with VM name.
n Use Virtual Machine Name - If all of the VM names in an environment are unique, then VM name
can be used to identify a VM across vCenters. We recommend you use VM name in combination
with VM BIOS UUID.
4 Click OK.
What to do next
Prerequisites
An antivirus scan must have been run, and a tag applied to the appropriate virtual machine.
Note Refer to the third party solution documentation for details of the tags applied by those solutions.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
A list of tags applied in your environment is displayed along with details about the virtual machines to
which those tags have been applied. Note down the exact tag name if you plan on adding a security
group to include virtual machines with a specific tag.
3 Click the number in the VM Count column to view the virtual machines to which that tag in that row
has been applied.
Prerequisites
If creating a universal security tag in an active standby deployment scenario, first set the unique ID
selection criteria on the primary NSX Manager.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
4 (Optional) To create a universal security tag for use in cross-vCenter NSX environments, select Mark
this object for universal synchronization.
5 Type a name and description for the tag and click OK.
What to do next
Security tags can be used as the matching criteria in security groups. In a cross-vCenter environment,
security tags are synchronized between primary and secondary NSX managers.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
The Assign Security Tag to Virtual Machine window appears, populated with available VMs.
4 Double-click one or more virtual machines to move them to the Selected Objects column. Click OK.
The Security Tags tab appears with an updated VM count for the security tag.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 Select a security tag and click the Delete Security Tag ( ) icon.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
4 Ensure that you are in the Manage > Information Security tab.
Each of the three tabs (Endpoint Services, Firewall, Network Introspection Services) displays the
corresponding services for the security policy.
Services that are not effective are greyed out. The Overridden column displays the services that are
actually applied on the security policy and the Inherited from column displays the security policy from
which services are inherited.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
4 Ensure that you are in the Monitor > Service Errors tab.
Clicking the link in the Status column takes you to the Service Deployment page where you can
correct service errors.
Procedure
4 Ensure that you are in the Monitor > Service Composer tab.
The following network and security services can be grouped into a security policy:
Multiple security policies may be applied to a virtual machine either because the security group that
contains the virtual machine is associated with multiple policies or because the virtual machine is part of
multiple security groups associated with different policies. If there is a conflict between services grouped
with each policy, the weight of the policy determines the services that will be applied to the virtual
machine. For example, say policy 1 blocks internet access and has a weight value of 1000 while policy 2
allows internet access and has a weight value of 2000. In this particular case, policy 2 has a higher
weight and hence the virtual machine will be allowed internet access.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
3
Click the Manage Priority ( ) icon.
4 In the Manage Priority dialog box, select the security policy that you want to change the priority for
and click the Move Up ( ) or Move Down ( )icon.
5 Click OK.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
3
Select the security policy that you want to edit and click the Edit Security Policy ( ) icon.
4 In the Edit Security Policy dialog box, make the appropriate changes and click Finish.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
3 Select the security policy that you want to delete and click the Delete Security Policy ( ) icon.
Our sample scenario shows how you can protect your desktops end to end.
Create security
policy for desktops
(DesktopPolicy)
Create security
policy for infected VMs
(QuarantinePolicy)
Create security
policy to scan desktops
(DesktopPolicy)
Map DesktopPolicy to
DesktopSecurityGroup
Map Quarantine to
QuarantineSecurityGroup
Run partner
solution scan
Vulnerability
Management
scan
Vulnerable VM
tagged
Tagged VM
instantly added to
QuarantineSecurityGroup
Administrator tasks
VM in
QuarantineSecurityGroup
Automatic action by protected with IPS
Service Composer
Prerequisites
We are aware that Symantec tags infected virtual machine with the AntiVirus.virusFound tag.
Procedure
a Click the Security Policies tab and click the Add Security Policy icon.
d Change the weight to 51000. The policy precedence is set very high so as to ensure that it is
enforced above all other policies.
e Click Next.
f On the Add Endpoint Service page, click and fill in the following values.
Option Value
Name Desktop AV
g Click OK.
h Do not add any firewall or network introspection services and click Finish.
a Click the Security Policies tab and click the Add Security Policy icon.
e Click Next.
f On the Add Endpoint Service page, do not do anything and click Next.
g In Firewall, add three rules - one rule to block all outgoing traffic, the next rule to block all traffic
with groups, and the last rule to allow incoming traffic only from remediation tools.
4 Move QuarantinePolicy to the top of the security policy table to ensure that it is enforced before all
other policies.
c Click the Security Groups tab and click the Add Security Group icon.
g Review your selections on the Ready to Complete page and click Finish.
6 Create a Quarantine security group where the infected virtual machines are to be placed.
a Click the Security Groups tab and click the Add Security Group icon.
c In Description, type
Dynamic group membership based on infected VMs identified by the antivirus
scan.
d On the Define membership Criteria page click and add the following criteria.
e Do not do anything on the Select objects to include or Select objects to exclude pages and click
Next.
f Review your selections on the Ready to Complete page and click Finish.
a On the Security Policies tab, ensure that the DesktopPolicy policy is selected.
b
Click the Apply Security Policy ( ) icon and select the SG_Desktops group.
c Click OK.
This mapping ensures that all desktops (part of the DesktopSecurityGroup) are scanned when
an antivirus scan is triggered.
8 Navigate to the canvas view to confirm that QuarantineSecurityGroup does not include any virtual
machines yet.
The scan discovers infected virtual machine and tags them with the security tag
AntiVirus.virusFound. The tagged virtual machines are instantly added to
QuarantineSecurityGroup. The QuarantinePolicy allows no traffic to and from the infected
systems.
Procedure
2 Create a security group for the first tier of the Share Point application - web servers.
c Click the Security Groups tab and click the Add Security Group icon.
f Do not do anything on the Define membership Criteria page and click Next.
g On the Select objects to include page, select the web server virtual machines.
h Do not do anything on the Select objects to exclude page and click Next.
i Review your selections on the Ready to Complete page and click Finish.
3 Now create a security group for your database and share point servers and name them
SG_Database, and SG_Server_SharePoint respectively. Include the appropriate objects in each
group.
4 Create a top level security group for your application tiers and name it SG_App_Group. Add SG_Web,
SG_Database, and SG_Server_SharePoint to this group.
a Click the Security Policies tab and click the Add Security Policy icon.
d Change the weight to 50000. The policy precedence is set very high so as to ensure that it is
enforced above most other policies (with the exception of quarantine).
e Click Next.
f On the Endpoint Services page, click and fill in the following values.
Option Value
g Do not add any firewall or network introspection services and click Finish.
7 Navigate to the canvas view to confirm that the SP_App has been mapped to SG_App_Group.
b
Click the number next to the icon to see that the SP_App is mapped.
a
Click the Security Policies tab and then click the Export Blueprint ( ) icon.
c Click Next.
f Select the directory on your computer where you want to download the exported file and click
Save.
The security policy as well as all the security groups to which this policy has been applied (in our
case, the Application security group as well as the three security groups nested within it) are
exported.
9 In order to demonstrate how the exported policy works, delete the SP_App policy.
10 Now we will restore the Template_ App_ DevTest policy that we exported in step 7.
a Click Actions and then click the Import Service Configuration icon.
b Select the FromAppArtchitect_Template_App file from your desktop (you saved it in step 7).
c Click Next.
d The Ready to complete page displays the security policies along with associated objects (security
groups on which these have been applied, as well as Endpoint services, firewall rules, and
network introspection services) to be imported.
e Click Finish.
The configuration and associated objects are imported to the vCenter inventory and are visible in
the canvas view.
Security policy contents such as guest introspection and firewall rules, along with the binding of the policy
to security groups are exported. While exporting, prefixes can be added to the policy which will be applied
to policy name, policy actions name, and security group name.
When importing the configuration onto a different NSX manager, users can provide a suffix which will be
applied to policy name, policy actions name and security group name. Importing a security configuration
will will fail if the security group or security policy with the same name is present on the NSX Manager on
which the import is happening.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
5 Type a name and description for the configuration that you are exporting.
6 If desired, type a prefix to be added to the security policies and security groups that are being
exported.
If you specify a prefix, it is added to the target security policy names thus ensuring that they have
unique names.
7 Click Next.
8 In the Select security policies page, select the security policy that you want to export and click Next.
9 The Ready to complete page displays the security policies along with associated objects (security
groups on which these have been applied, as well as Endpoint services, firewall rules, and network
introspection services) to be exported.
10 Click Finish.
11 Select the directory on your computer where you want to download the exported blueprint and click
Save.
When importing the configuration, an empty security group is created. All of the services, service profiles,
applications, and application groups need to be present in the destination environment or the import will
fail.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Security > Service Composer.
3 Click Actions and then click the Import Service Configuration icon.
5 If desired, type a suffix to be added to the security policies and security groups that are being
imported.
If you specify a suffix, it is added to the security policy names being imported thus ensuring that they
have unique names.
6 Click Next.
Service Composer verifies that all services referred to in the configuration are available in the
destination environment. If not, the Manage Missing Services page is displayed, where you can map
missing services to available target services.
The Ready to complete page displays the security policies along with associated objects (security
groups on which these have been applied, as well as Endpoint services, firewall rules, and network
introspection services) to be imported.
7 Click Finish.
The imported security policies are added to the top of the security policy table (above the existing
policies) in the target NSX Manager. The original order of the imported policies is preserved.
Guest Introspection health status is conveyed by using alarms that show in red on the vCenter Server
console. In addition, more status information can be gathered by looking at the event logs.
Important Your environment must be correctly configured for Guest Introspection security:
n All hosts in a resource pool containing protected virtual machines must be prepared for Guest
Introspection so that virtual machines continue to be protected as they are vMotioned from one ESXi
host to another within the resource pool.
n Virtual machines must have the Guest Introspection thin agent installed to be protected by Guest
Introspection security solution. Not all guest operating systems are supported. Virtual machines with
non-supported operating systems are not protected by the security solution.
Note You cannot migrate a Service VM (SVM) using vMotion/SvMotion. SVMs must remain on the host
on which they were deployed for correct operation.
Prerequisites
The installation instructions that follow assume that you have the following system:
n A datacenter with supported versions of vCenter Server and ESXi installed on each host in the
cluster.
n Hosts in the cluster where you want to install Guest Introspection have been prepared for NSX. See
Prepare Host Clusters for NSX in the NSX Installation Guide. Guest Introspection cannot be installed
on standalone hosts. If you are using NSX for deploying and managing Guest Introspection for anti-
virus offload capability only, you do not need to prepare the hosts for NSX, and the NSX for vShield
Endpoint license does not allow it.
n Ensure the NSX Manager and the prepared hosts that will run Guest Introspection services are linked
to the same NTP server and that time is synchronized. Failure to do so may cause VMs to be
unprotected by anti-virus services, although the status of the cluster will be shown as green for Guest
Introspection and any third-party services.
If an NTP server is added, VMware recommends that you then redeploy Guest Introspection and any
third-party services.
If you want to assign an IP address to the NSX Guest Introspection service virtual machine from an IP
pool, create the IP pool before installing NSX Guest Introspection. See Working with IP Pools in the NSX
Administration Guide.
Procedure
3 In the Deploy Network and Security Services dialog box, select Guest Introspection.
4 In Specify schedule (at the bottom of the dialog box), select Deploy now to deploy Guest
Introspection as soon as it is installed or select a deployment date and time.
5 Click Next.
6 Select the datacenter and cluster(s) where you want to install Guest Introspection, and click Next.
7 On the Select storage and Management Network Page, select the datastore on which to add the
service virtual machines storage or select Specified on host. It is recommended that you use shared
datastores and networks instead of "specified on host" so that deployment workflows are automated.
The selected datastore must be available on all hosts in the selected cluster.
If you selected Specified on host, follow the steps below for each host in the cluster.
a On the vSphere Web Client home page, click vCenter and then click Hosts.
b Click a host in the Name column and then click the Manage tab.
8 Select the distributed virtual port group to host the management interface. If the datastore is set to
Specified on host, the network must also be Specified on host.
The selected port group must be able to reach the NSX Manager’s port group and must be available
on all hosts in the selected cluster.
If you selected Specified on host, follow the substeps in Step 7 to select a network on the host.
When you add a host (or multiple hosts) to the cluster, the datastore and network must be set before
each host is added to the cluster.
Select To
DHCP Assign an IP address to the NSX Guest Introspection service virtual machine
through Dynamic Host Configuration Protocol (DHCP). Select this option if your
hosts are on different subnets.
An IP pool Assign an IP address to the NSX Guest Introspection service virtual machine from
the selected IP pool.
10 Click Next and then click Finish on the Ready to complete page.
11 Monitor the deployment until the Installation Status column displays Succeeded.
In NSX 6.4.0 and later, the name of the GI SVM in vCenter server displays the IP address of the host
that it has been deployed on.
12 If the Installation Status column displays Failed, click the icon next to Failed. All deployment errors
are displayed. Click Resolve to fix the errors. In some cases, resolving the errors displays additional
errors. Take the required action and click Resolve again.
n If you are using vSphere 6.0, see these instructions for installing VMware Tools:
http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.vm_admin.doc
%2FGUID-391BE4BF-89A9-4DC3-85E7-3D45F5124BC7.html.
n If you are using vSphere 6.5, see these instructions for installing VMware
Tools:https://www.vmware.com/support/pubs/vmware-tools-pubs.html.
Windows virtual machines with the Guest Introspection drivers installed are automatically protected
whenever they are started up on an ESXi host that has the security solution installed. Protected virtual
machines retain the security protection through shut downs and restarts, and even after a vMotion move
to another ESXi host with the security solution installed.
For Linux instructions, see Install the Guest Introspection Thin Agent on Linux Virtual Machines.
Prerequisites
Ensure that the guest virtual machine has a supported version of Windows installed. The following
Windows operating systems are supported for NSX Guest Introspection:
n Windows 10
n Win2012 (64)
Procedure
1 Start the VMware Tools installation, following the instructions for your version of vSphere. Select
Custom install.
The options available will vary depending on the version of VMware Tools.
Driver Description
vShield Endpoint Drivers Installs File Introspection (vsepflt) and Network Introspection
(vnetflt) drivers.
Guest Introspection Drivers Installs File Introspection (vsepflt) and Network Introspection
(vnetflt) drivers.
NSX File Introspection Driver and NSX Network Introspection Select NSX File Introspection Driver to install vsepflt.
Driver Optionally select NSX Network Introspection Driver to install
vnetflt (vnetWFP on Windows 10 or later).
3 In the drop-down menu next to the drivers you want to add, select This feature will be installed on
the local hard drive.
What to do next
Check if the thin agent is running using the fltmc command with the administrative privileges. The Filter
Name column in the output lists the thin agent with an entry vsepflt.
The Linux thin agent is available as part of the VMware Tools operating system specific packages
(OSPs). Installing VMware Tools is not required. Linux thin agent installation and upgrade is not
connected to NSX installation and upgrade. Also, Enterprise or Security Administrator (non-NSX
Administrator) can install the agent on guest VMs outside of NSX.
To install Linux thin agent on RHEL or SLES systems, use the RPM package. To install Linux thin agent
on Ubuntu systems, use the DEB package.
For Windows instructions, see Install the Guest Introspection Thin Agent on Windows Virtual Machines.
Prerequisites
n Ensure that the guest virtual machine has a supported version of Linux installed:
Procedure
u Based on your Linux operating system, perform the following steps with root privilege:
a Obtain and import the VMware packaging public keys using the following commands:
curl -O https://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub
vi /etc/apt/sources.list.d/vm.list
deb https://packages.vmware.com/packages/ubuntu/ trusty main
apt-get update
apt-get install vmware-nsx-gi-file
a Obtain and import the VMware packaging public keys using the following commands:
curl -O https://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub
vi /etc/yum.repos.d/vm.repo
[vm]
name = VMware
baseurl = https://packages.vmware.com/packages/rhel7/x86_64
enabled = 1
gpgcheck = 1
metadata_expire = 86400
ui_repoid_vars = basearch
a Obtain and import the VMware packaging public keys using the following commands:
curl -O https://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub
What to do next
Check if the thin agent is running using the service vsepd status command with the administrative
privileges. The status should be running.
Procedure
1 In the vSphere Web Client, click vCenter Inventory Lists, and then click Datacenters.
The Guest Introspection Health and Alarms page displays the health of the objects under the
datacenter you selected, and the active alarms. Health status changes are reflected within a minute
of the actual occurrence of the event that triggered the change.
n Failure to establish communication with SVM (when first such failure occurs).
Generated log messages have the following substrings near the beginning of each log message: vf-
AUDIT, vf-ERROR, vf-WARN, vf-INFO, vf-DEBUG.
Caution Before you uninstall a Guest Introspection module from a cluster, you must uninstall all third-
party products that are using Guest Introspection from the hosts on that cluster. Use the instructions from
the solution provider.
There is a loss of protection for VMs in the NSX cluster. You must vMotion the VMs out of the cluster
before you uninstall.
1 In vCenter, navigate to Home > Networking & Security > Installation and Upgrade and select the
Service Deployments tab.
Prerequisites
Guest Introspection for Linux is installed. You have root privileges on the Linux system.
Procedure
n For uninstalling package from Ubuntu system, run the apt-get remove vmware-nsx-gi-file
command.
n For uninstalling package from RHEL7 system, run the yum remove vmware-nsx-gi-file
command.
n For uninstalling package from SLES system, run the zypper remove vmware-nsx-gi-file
command.
Any Application
Physical or Virtual
Workloads
SW partner
extensions
Virtual Networks
NSX API
Guest and network
introspection
NSX
vSphere
Overlay transport
HW partner
extensions
Edge service
insertion
There are various deployment methods for inserting third party services into NSX.
Vendor solutions that make use of this type of service insertion include Intrusion Prevention Service
(IPS)/Intrusion Detection Service (IDS), Firewall, Anti Virus, File Identity Monitoring (FIM), and
Vulnerability Management.
Vendor solutions that make use of this type of service insertion include ADC/Load Balancer devices.
Procedure
1 Register the third-party service with NSX Manager on the vendor's console.
You need NSX login credentials to register the service. For more information, refer to the vendor
documentation.
Once deployed, the third-party service is displayed in the NSX Service Definitions window and is
ready to be used. The procedure for using the service in NSX depends on the type of service
inserted.
For example, you can enable a host-based firewall service by creating a security policy in Service
Composer or creating a firewall rule to redirect traffic to the service. See Consuming Vendor Services
through Service Composer or Redirecting Traffic to a Vendor Solution through Logical Firewall. For
information on using an Edge based service, see Using a Partner Load Balancer.
Prerequisites
Ensure that:
Procedure
1 Click Networking & Security and then click Installation and Upgrade.
2 Click the Service Deployments tab and click the New Service Deployment ( ) icon.
3 In the Deploy Network and Security Services dialog box, select the appropriate solution(s).
4 In Specify schedule (at the bottom of the dialog box), select Deploy now to deploy the solution
immediately or select a deployment date and time.
5 Click Next.
6 Select the datacenter and cluster(s) where you want to deploy the solution and click Next.
7 Select the datastore on which to add the solution service virtual machines storage or select Specified
on host.
The selected datastore must be available on all hosts in the selected cluster.
If you selected Specified on host, the datastore for the ESX host must be specified in the AgentVM
Settings of the host before it is added to the cluster. See vSphere API/SDK Documentation.
8 Select the distributed virtual port group to host the management interface. This port group must be
able to reach the NSX Manager’s port group.
If the network is set to Specified on host, the network to be used must be specified in the Agent VM
Settings > Network property of each host in the cluster. See vSphere API/SDK Documentation.
You must set the agent VM network property on a host before you add it to a cluster. Navigate to
Manage > Settings > Agent VM Settings > Network and click Edit to set the agent VM network.
The selected port group must be available on all hosts in the selected cluster.
Select To
DHCP Assign an IP address to the service virtual machine through Dynamic Host
Configuration Protocol (DHCP).
An IP pool Assign an IP address to the service virtual machine from the selected IP pool.
10 Click Next and then click Finish on the Ready to complete page.
11 Monitor the deployment until the Installation Status displays Successful. If the status displays
Failed, click the icon next to Failed and take action to resolve the error.
What to do next
You can now consume the partner service through NSX UI or NSX API.
A security group is a set of vCenter objects such as clusters, virtual machines, vNICs, and logical
switches. A security policy is a set of Guest Introspection services, firewall rules, and network
introspection services.
When you map a security policy to a security group, redirection rules are created on the appropriate third-
party vendor service profile. As traffic flows from virtual machines belonging to that security group, it is
redirected to registered third-party vendor services that determine how to process that traffic. For more
information on Service Composer, see Using Service Composer.
Prerequisites
n The third party service must be registered with NSX Manager, and the service must be deployed in
NSX.
n If the default firewall rule action is set to Block, you must add a rule to allow the traffic to be
redirected.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Firewall.
3 In the section to which you want to add a rule, click the Add rule ( ) icon.
A new any any allow rule is added at the top of the section.
4 Point to the Name cell of the new rule, click , and type a name for the rule.
5 Specify the Source, Destination, and Service for the rule. For more information, see Add a
Distributed Firewall Rule
b In Redirect To, select the service profile and the logical switch or security group to which you
want to bind the service profile.
The service profile is applied to virtual machines connected to or contained in the selected logical
switch or security group.
c Indicate whether the redirected traffic is to be logged and type comments, if any.
d Click OK.
The selected service profile is displayed as a link in the Action column. Clicking the service
profile link displays the service profile bindings.
Prerequisites
The third-party load balancer must be registered with NSX Manager, and it must be deployed in NSX.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > NSX Edges.
8 Complete the remaining fields and set up the load balancer by adding a service monitor, server pool,
application profile, application rules, and a virtual server. When adding a virtual server, select the
template provided by the vendor. For more information, see Setting Up Load Balancing.
Traffic for the specified Edge is load balanced by the third party vendor's management console.
There is a correct order of software when removing any third-party software solution. If this sequence is
not followed and specifically if the third-party solution is uninstalled or deleted before it is unregistered
with NSX Manager, the removal operation will fail. See https://kb.vmware.com/kb/2126678 for instructions
on how to resolve this.
Procedure
1 In the Sphere Web Client, navigate to Networking & Security > Service Composer, and delete the
rules (or security polices) that are redirecting traffic to the 3rd-party solution.
2 Navigate to Service Definitions and double-click the name of the third-party solution.
4 Navigate to Installation and Upgrade > Service Deployments and delete the third-party
deployment.
What to do next
Make notes of the configuration settings, and then remove NSX from the third-party solution. For
example, you may need to delete rules that reference other objects and then delete the objects.
NSX also supports Single Sign On (SSO), which enables NSX to authenticate users from other identity
services such as Active Directory, NIS, and LDAP.
User management in the vSphere Web Client is separate from user management in the CLI of any NSX
component.
Security Enterprise
Auditor Admin NSX Admin Admin
Administrator
Edge
High availability R R R, W R, W
DNS R R, W R R, W
Auto plumbing R R, W R R, W
Statistics R R R R, W
DHCP R R, W R R, W
Load balance R R, W R R, W
VPN R R, W R R, W
Support No Access R, W R, W R, W
Bridging R R, W R R, W
Security Enterprise
Auditor Admin NSX Admin Admin
Certificate R R, W R R, W
Distributed Firewall
Application Rule Flows are collected for selected set R R,W No Access R, W
Manager of applications. Firewall rules are
then created based on the
collected flows.
NameSpace
Config R R R, W R, W
SpoofGuard
Security Enterprise
Auditor Admin NSX Admin Admin
Reports R R R, W R, W
Library
Install
App No Access R R, W R, W
EPSEC No Access R R, W R, W
DLP No Access R R, W R, W
VDN
Provision R R R, W R, W
Service Insertion
Service R R, W R, W R, W
Service profile R R R, W R, W
Trust Store
Security Enterprise
Auditor Admin NSX Admin Admin
Security Fabric
Messaging
Security Policy
You can configure lookup service on the NSX Manager and provide the SSO administrator credentials to
register NSX Management Service as an SSO user. Integrating the single sign on (SSO) service with
NSX improves the security of user authentication for vCenter users and enables NSX to authenticate
users from other identity services such as AD, NIS, and LDAP. With SSO, NSX supports authentication
using authenticated Security Assertion Markup Language (SAML) tokens from a trusted source via REST
API calls. NSX Manager can also acquire authentication SAML tokens for use with other VMware
solutions.
NSX caches group information for SSO users. Changes to group memberships will take up to 60 minutes
to propagate from the identity provider (for example, active directory) to NSX.
Prerequisites
n To use SSO on NSX Manager, you must have vCenter Server 6.0 or later, and single sign on (SSO)
authentication service must be installed on the vCenter Server. Note that this is for embedded SSO.
Instead, your deployment might use an external centralized SSO server.
For information about SSO services provided by vSphere, see http://kb.vmware.com/kb/2072435 and
http://kb.vmware.com/kb/2113115.
n NTP server must be specified so that the SSO server time and NSX Manager time is in sync.
For example:
Procedure
3 From the home page, click Manage Appliance Settings > NSX Management Service.
5 Enter the name or IP address of the host that has the lookup service.
The Lookup Service URL is displayed based on the specified host and port.
7 Enter the SSO Administrator user name and password, and click OK.
8 Check that the certificate thumbprint matches the certificate of the SSO server.
If you installed a CA-signed certificate on the CA server, you are presented with the thumbprint of the
CA-signed certificate. Otherwise, you are presented with a self-signed certificate.
For example:
What to do next
A user can have only one role. The following table lists the permissions of each user role.
NSX Administrator NSX operations only: for example, install virtual appliances, configure port groups.
Security Administrator NSX security only: for example, define distributed firewall rules, configure NAT and load
balancer services.
When you assign a role to an SSO user, access is granted in the following interfaces:
n The Networking and Security plug-in in the vSphere Web Client.
n The NSX Manager appliance, including the API. This access is available only in NSX 6.4 or later.
The Enterprise Administrator role gets the same access to the NSX Manager appliance and the API as
the NSX Manager admin user. The other NSX roles get read-only access to the NSX Manager appliance
and the API.
For example:
SSO users with any role other than the Enterprise Administrator role can access the NSX Manager UI
and run API requests in read-only mode. Users can access NSX APIs with the GET API request, but
they cannot run the PUT, POST, and DELETE API requests. In addition, these SSO users cannot perform
actions such as stop, configure, edit, and so on, in the NSX Manager UI.
You can manage NSX Manager appliance admin user only through CLI commands.
When you assign a role to an SSO user, access is granted in the following interfaces:
n The NSX Manager appliance, including the API. This access is available only in NSX 6.4 or later.
The Enterprise Administrator role gets the same access to the NSX Manager appliance and the API as
the NSX Manager admin user. The other NSX roles get read-only access to the NSX Manager appliance
and the API.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Users and Domains.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
For example:
Alias corp
Note When a group is assigned a role on the NSX Manager, any user from that group can log in to
the NSX Manager UI.
7 Click Next.
8 Select the role for the user and click Next. For more information about available roles, see Managing
User Rights.
9 Click Finish.
n AD domain: corp.local
Prerequisites: vCenter Server must be registered with NSX Manager, and SSO must be configured. Note
that SSO is required only for Groups.
b Navigate to Networking & Security > System > Users and Domains.
f Click Next.
a Click the Home icon and then click vCenter Home > Datacenters.
b Select a datacenter and click Actions > All vCenter Actions > Add Permission.
f In Assigned Role, select Read-only and un-select Propagate to children and click OK.
Sally can perform NSX operations only. For example, install virtual appliances, create logical
switches, and so on.
Name G1
Name John
Belongs to group G1
Name G1
Name G2
Resources Datacenter1
Name Joseph
n Read, write (security administrator role) for Datacenter1 and its child resources
Name G1
Name Bob
Belongs to group G1
Resources Datacenter1
Procedure
1 Create a CLI user account. You can create a CLI user account for each NSX virtual appliance. To
create a CLI user account, perform the following steps:
a Log in to the vSphere Web Client, and select an NSX Manager virtual appliance.
c Log in to the CLI session using the Administrator account and password that you specified while
installingNSX Manager. For example,
nsx-mgr> enable
Password:
nsx-mgr>
d Switch to Privileged mode from Basic mode using the enable command as follows:
nsx-mgr> enable
Password:
nsx-mgr#
e Switch to Configuration mode from Privileged mode using the configure terminal command
as follows:
f Add a CLI user account using the user username password (hash | plaintext) password
command. For example,
2 Now provide web interface privilege which will enable the user to login to NSX Manager virtual
appliance and allows the execution of appliance management REST APIs as follows:
b Allow the created CLI user to run the REST API calls using the user username privilege
web-interface command. For example:
Current configuration:
!
user cliuser
!
ntp server 192.168.110.1
!
ip name server 192.168.110.10
!
hostname nsxmgr-01a
!
interface mgmt
ip address 192.168.110.15/24
!
ip route 0.0.0.0/0 192.168.110.1
!
web-manager
nsx-mgr#(config)# exit
nsx-mgr# exit
The created user is not listed in the Networking & Security > System > Users and Domains >
Users tab. Also, no role is assigned to the user.
5 Assign the required role to the user using the REST API. You can assign auditor (Auditor),
security_admin (Security Administrator), or super_user (System Administrator) role as follows:
POST - https://<NSX-IP>/api/2.0/services/usermgmt/role/<username>?isCli=true
<accessControlEntry>
<role>auditor</role> # Enter the required role #
<resource>
<resourceId>globalroot-0</resourceId>
</resource>
</accessControlEntry>
What to do next
You can log in to vSphere Web Client using the credentials provided while creating the user.
For more information on CLI, refer to NSX Command Line Interface Reference.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Users and Domains.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Users and Domains.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Users and Domains.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Users and Domains.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
If you delete a vCenter user account, only the role assignment for NSX Manager is deleted. The user
account on the vCenter Server is not deleted.
Note Duplicate names are allowed when you create a group with universal scope. You can provide
duplicate names when you select Mark this object for Universal Synchronization option while creating
the following groups:
n IP Address Group
n Security Group
Prerequisites
VMware Tools must be installed on each VM, or an enabled IP discovery method (DHCP snooping or
ARP snooping, or both) must be in place to when using grouping objects instead of IP addresses. For
more details, refer to IP Discovery for Virtual Machines.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal IP address groups.
10 (Optional) Select Mark this object for Universal Synchronization to create a universal IP address
group.
11 Click OK.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal IP address groups.
5
Select the group that you want to edit and click the Edit ( ) icon.
7 Click OK.
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal IP address groups.
5 Select the group that you want to delete and click the Delete ( ) icon.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal MAC address groups.
10 (Optional) Select Mark this object for Universal Synchronization to create a universal MAC
address group.
11 Click OK.
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal MAC address groups.
5
Select the group that you want to edit and click the Edit ( ) icon.
6 In the Edit MAC Set dialog box, make the appropriate changes.
7 Click OK.
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal MAC address groups.
5 Select the group that you want to delete and click the Delete ( ) icon.
Create an IP Pool
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
6 Type a name for the IP pool and type the default gateway and prefix length.
7 (Optional) Type the primary and secondary DNS and the DNS suffix.
8 Type the IP address ranges to be included in the pool and click OK.
Edit an IP Pool
You can edit an IP pool - you cannot edit the CIDR and gateway.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
Delete IP Pool
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
5 Select the IP pool that you want to delete and click the Delete icon.
Security Groups are containers that can contain multiple object types including logical switch, vNIC, IPset,
and Virtual Machine (VM). Security groups can have dynamic membership criteria based on security tags,
VM name or logical switch name. For example, all VM's that have the security tag "web" will be
automatically added to a specific security group destined for Web servers. After creating a security group,
a security policy is applied to that group.
Security groups for use with Identity Firewall for RDSH, must use security policies that are marked
"Enable User Identity at Source" when created. Security groups for use with Identity Firewall for RDSH
can only contain Active Directory (AD) groups, and all nested security groups must also be AD groups.
Security groups used in Identity Firewall can contain only AD directory groups. Nested groups can be
non-AD groups or other logical entities such as virtual machines.
In a cross-vCenter NSX environment, universal security groups are defined on the primary NSX manager
and are marked for universal synchronization with secondary NSX managers. Universal security groups
cannot have dynamic membership criteria defined unless they are marked for use in an active standby
deployment scenario.
In a cross-vCenter NSX environment with an active standby deployment scenario, the SRM creates a
placeholder VM on the recovery site for every protected VM on the active site. The placeholder VMs are
not active, and stay in the standby mode. When the protected VM goes down, the placeholder VMs on
the recovery site are powered on and take over the tasks of the protected VM. Users create distributed
firewall rules with universal security groups containing universal security tags on the active site. The NSX
manager replicates the distributed firewall rule with the universal security groups containing universal
security tags on the placeholder VMs and when the placeholder VMs are powered on the replicated
firewall rules with the universal security groups and universal security tags are enforced correctly.
Note
n Universal security groups created prior to 6.3 cannot be edited for use in active standby deployments.
Table 22‑1. Firewall Rule Behavior with RDSH and Non-RDSH Sections
Enable User Identity Security Group Identity Security Group (RDSH Any Security Group (Non-RDSH
(RDSH Section) Section) Section)
Source - SID based rules are preemptively Source - IP based rules Source - IP based rules
pushed to hypervisor. Rule enforcement is
on the first packet.
Applied To with Identity based Security Group - Applied to all hosts User based Applied To
Applied To with Non-Identity based Security Group - User based Applied to User based Applied to
Universal security groups are used in two types of deployments: active cross-vCenter NSX environments,
and active standby cross-vCenter NSX environments, where one site is live at a given time and the rest
are on standby.
n Universal security groups in an active environment can contain the following included objects only:
security groups, IP sets, MAC sets. You cannot configure dynamic membership or excluded objects.
n Universal security groups in an active standby environment can contain the following included
objects: security groups, IP sets, MAC sets, universal security tags. You can also configure dynamic
membership using VM Name only. You cannot configure excluded objects.
Note Universal security groups created prior to 6.3 cannot be edited for use in active standby
deployments.
Prerequisites
If you are creating a security group based on Active Directory group objects, ensure that one or more
domains have been registered with NSX Manager. NSX Manager gets group and user information as well
as the relationship between them from each domain that it is registered with. See Register a Windows
Domain with NSX Manager.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal security groups.
4 Click the Security Group tab, and then click the Add New Security Group icon.
6 (Optional) If you are creating a universal security group, select Mark this object for universal
synchronization.
7 (Optional) If you are creating a universal security group for use in an active standby deployment,
select both Mark this object for universal synchronization and Use for active standby
deployments. Dynamic membership for universal security groups with active standby deployment is
based on virtual machine name
8 Click Next.
9 On the Dynamic Membership page, define the criteria that an object must meet for it to be added to
the security group you are creating. This gives you the ability to include virtual machines by defining a
filter criteria with a number of parameters supported to match the search criteria.
Note If you are creating a universal security group, the Define dynamic membership step is not
available in active active deployments. It is available in active standby deployments, based on virtual
machine name only.
For example, you may include a criterion to add all virtual machines tagged with the specified security
tag (such as AntiVirus.virusFound) to the security group. Security tags are case sensitive.
Or you can add all virtual machines containing the name W2008 and virtual machines that are in the
logical switch global_wire to the security group.
10 Click Next.
11 On the Select objects to include page, select the tab for the resource you want to add and select one
or more resources to add to the security group. You can include the following objects in a security
group.
Table 22‑2. Objects that can be included in security groups and universal security
groups.
Security Group Universal Security Group
n Other security groups to nest within the security group n Other universal security groups to nest within the
you are creating. universal security group you are creating.
n Cluster n Universal IP sets
n Logical Switch n Universal MAC sets
n Network n Universal Security Tag (active standby deployments only)
n Virtual App
n Datacenter
n IP sets
n Directory Groups
The objects selected here are always included in the security group regardless of whether or not they
match the criteria that you defined earlier on the Dynamic Membership page.
When you add a resource to a security group, all associated resources are automatically added. For
example, when you select a virtual machine, the associated vNIC is automatically added to the
security group.
12 Click Next and select the objects that you want to exclude from the security group.
Note If you are creating a universal security group, the Select objects to exclude step is not
available.
The objects selected here are always excluded from the security group regardless of whether or not
they match the dynamic criteria.
13 Click Next.
The Ready to Complete window appears with a summary of the security group.
14 Click Finish.
{Expression result (derived from Define dynamic membership) + Inclusions (specified in Select objects
to include} - Exclusion (specified in Select objects to exclude)
This means that inclusion items are first added to the expression result. Exclusion items are then
subtracted from the combined result.
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal security groups.
Note that universal security groups created prior to 6.3 cannot be edited for use in active standby
deployments.
5
Select the group that you want to edit and click the Edit ( ) icon.
6 In the Edit Security Group dialog box, make the appropriate changes.
7 Click OK.
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal security groups.
5 Select the group that you want to delete and click the Delete ( ) icon.
Create a Service
You can create a service and then define rules for that service.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal services.
8 Select a Layer.
Depending on the layer selected, you may be prompted to enter further information, such as App ID
or source ports.
9 Select a Protocol.
a Depending on the protocol selected, you may be prompted to enter further information, such as
destination port.
11 (Optional) Select Mark this object for Universal Synchronization to create a universal service.
12 Click OK.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
u You must select the primary NSX Manager if you want to manage universal security groups.
8 (Optional) Select Mark this object for Universal Synchronization to create a universal service
group.
9 In Members, select the services or service groups that you want to add to the group.
11 Click OK.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
4
Select a custom service or service group and click the Edit ( ) icon.
6 Click OK.
Procedure
1 In the vSphere Web Client, click Networking & Security > Groups and Tags.
4 Select a custom service or service group and click the Delete ( ) icon.
5 Click Yes.
n NSX Controller
n Audit Logs
n System Events
2 Click Networking & Security. The Dashboard > Overview page appears as your default homepage.
You can view existing system-defined widgets and the custom widgets.
Widget Component
Controller Nodes:
n Controller node status
n Controller peer connectivity status
n Controller VM status (powered off/deleted)
n Controller disk latency alerts
External Components:
n vSphere ESX Agent Manager (EAM) service status
Firewall Publish Status Number of hosts with Firewall Publish status as failed. Status is Red when
any host does not successfully apply the published distributed firewall
configuration
Logical Switch Status Number of logical switches with status Error or Warning. Flags when the
backed distributed virtual port group is deleted from vCenter Server
Host Notification Security alerts for hosts. You can see this alert when the hardware address
of the DHCP client is spoofed. A possible DHCP denial-of-service (DoS)
attack is happening.
Edge Notifications Highlights active alarms for certain services. It monitors the list of critical
events that are listed and tracks them until the problem is not resolved.
Alarms are auto resolved when the recovery event is reported, or edge is
force synced, redeployed, or upgraded
Widget Component
System Scale Dashboard Shows a summary of warnings and alerts for scale. For detail listing of the
parameters and scale numbers, click Details to go to the System Scale
Dashboard
Custom Widget You can view the custom widget created through API
Custom Widget
You can add custom widgets to the dashboard using the REST API. You can create five custom widgets
for your personal viewing in the dashboard.
You can also share the custom widgets with other users by setting the shared parameter as true in the
widget configuration. Maximum limit on shared widgets is 10. It means that the total number of widgets
shared by all the users is limited to 10.
n To delete the custom widget created earlier: Use the DELETE /api/2.0/services/dashboard/ui-
views/dashboard/widgetconfigurations/<widgetconfiguration-id> API.
If the current value exceeds a specified threshold percentage, a warning indicator is displayed to alert that
the maximum supported scale is approaching. A red indicator shows that configuration maximum is
reached. The listing is sorted in descending order of the current scale percent value which ensures that
the warning indicators are always displayed at the top.
The data is collected every hour to verify if the threshold values are exceeding the limits, and creates an
indicator when the thresholds are exceeded. The information is logged twice a day to the NSX Manager
technical support logs.
n A critical event when a parameter crosses the supported system scale configuration.
For more information on system scales, refer to NSX Recommended Configuration Maximums.
You can also view Communication Channel Health on the dashboard at Networking & Security >
Dashboard in the Fabric Status section.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Installation and Upgrade > Host
Preparation.
2
Select a cluster or expand clusters and select a host. Click Actions ( ) then Communication
Channel Health.
NSX Controller
You can manage NSX Controller instances.
For information about troubleshooting controller cluster issues, including deleting controllers safely, refer
to the NSX Controller section in the NSX Troubleshooting Guide.
Procedure
2 Click Networking & Security and then click Installation and Upgrade.
3 Under Management, select the controller for which you want to change the password.
Procedure
2 Click Networking & Security, and then click Installation and Upgrade.
3 Under Management, select the controller that you want to download logs from.
5 Click Download.
The NSX Manager starts downloading the NSX Controller log and acquires the lock.
Note Download one NSX Controller log at a time. Once the first one completes, start downloading
the other. An error might occur if you download logs from multiple controllers simultaneously.
6 After the log is ready, click Save to download the log to your desktop.
What to do next
If you want to upload diagnostic information for VMware technical support, refer to the Knowledge Base
article 2070100.
Procedure
1 To enable syslog on NSX Controller, use the following NSX API. It adds controller syslog exporter and
configures a syslog exporter on the specified controller node.
Request
POST https://<nsxmgr-ip>/api/2.0/vdn/controller/{controller-id}/syslog
Request Body:
<controllerSyslogServer>
<syslogServer>10.135.14.236</syslogServer>
<port>514</port>
<protocol>UDP</protocol>
<level>INFO</level>
</controllerSyslogServer>
2 You can query the controller syslog exporter and retrieve details about the configured syslog exporter
on the specified controller node using the following NSX API.
Request
GET https://<nsxmgr-ip>/api/2.0/vdn/controller/{controller-id}/syslog
Response Body:
<?xml version="1.0" encoding="UTF-8"?>
<controllerSyslogServer>
<syslogServer>10.135.14.236</syslogServer>
<port>514</port>
<protocol>UDP</protocol>
<level>INFO</level>
</controllerSyslogServer>
3 If not required, you can delete controller syslog exporter on the specified controller node using the
following NSX API.
Request
DELETE https://<nsxmgr-ip>/api/2.0/vdn/controller/{controller-id}/syslog
What to do next
CDO mode avoids the connectivity issues during the following failure scenarios:
n WAN is down.
When the CDO mode is enabled and host detects a control plane failure, the host waits for the configured
time period and then enters the CDO mode. You can configure the time period for which you want the
host to wait before entering the CDO mode. By default, the wait time is five minutes.
NSX Manager creates a special CDO logical switch (4999) on the controller. The VXLAN Network
Identifier (VNI) of the special CDO logical switch is unique from all other logical switches. When the CDO
mode is enabled, one controller in the cluster is responsible for collecting all the VTEP information
reported from all transport nodes, and replicating the updated VTEP information to all other transport
nodes. After detecting the CDO mode, broadcast packets like ARP/GARP and RARP is sent to the global
VTEP list. This allows to vMotion the VMs across the vCenter Servers without any data plane connectivity
issues.
When you disable the CDO mode, NSX Manager removes the CDO logical switch from the controller.
Prerequisites
n After upgrading to NSX 6.4, NSX Manager disables CDO mode for the existing transport nodes. Use
a pre-defined global VNI to configure vSphere Distributed Switch (VDS), if NSX Manager had one or
more CDO enabled transport nodes before upgrade.
Procedure
2 Click Networking & Security and then click Installation and Upgrade.
4 Click the Actions icon, and then click Enable CDO mode.
5 Click Yes.
The CDO Mode column displays State as Enabled and Status as Successful.
Procedure
2 Click Networking & Security and then click Installation and Upgrade.
4 Click the Actions icon, and then click Disable CDO mode.
5 Click Yes.
The CDO Mode column displays State as Disabled and Status as Successful.
NSX Manager removes the CDO logical switch from the controller.
For example: A vSphere Distributed Switch (VDS) gets deleted from the NSX Manager database, when
the last cluster associated with that VDS gets unconfigured from the VXLAN. Then, NSX Manager
removes the CDO-related opaque property from VDS. If the removal of opaque property fails due to some
reason, the opaque property remains in VDS. Now if you disable the CDO mode and configure VXLAN on
a host associated with that VDS, the CDO gets enabled on that host as the opaque property is present
and VNI is also present in the controller. In this case, use the resync feature to apply the CDO disabled
mode again. Now, NSX Manager tries to remove the opaque property from VDS.
Prerequisites
Procedure
2 Click Networking & Security and then click Installation and Upgrade.
3 On the Management tab, select the required NSX Manager. Enable CDO mode on the secondary
NSX Manager.
4 Click the Actions icon, and then click Resync CDO configuration.
5 Click Yes.
In NSX 6.2.3 and later, the default VXLAN port is 4789, the standard port assigned by IANA. Before NSX
6.2.3, the default VXLAN UDP port number was 8472.
Any new NSX installations will use UDP port 4789 for VXLAN.
If you upgrade from NSX 6.2.2 or earlier to NSX 6.2.3 or later, and your installation used the old default
(8472), or a custom port number (for example, 8888) before the upgrade, that port will continue to be
used after the upgrade unless you take steps to change it.
If your upgraded installation uses or will use hardware VTEP gateways (ToR gateways), you must switch
to VXLAN port 4789.
Cross-vCenter NSX does not require that you use 4789 for the VXLAN port, however, all hosts in a cross-
vCenter NSX environment must be configured to use the same VXLAN port. If you switch to port 4789,
this will ensure that any new NSX installations added to the cross-vCenter NSX environment are using
the same port as the existing NSX deployments.
Changing the VXLAN port is done in a three phase process, and will not interrupt VXLAN traffic.
1 NSX Manager configures all hosts to listen for VXLAN traffic on both the old and new ports. Hosts
continue to send VXLAN traffic on the old port.
2 NSX Manager configures all hosts to send traffic on the new port.
3 NSX Manager configures all hosts to stop listening on the old port, all traffic is sent and received on
the new port.
In a cross-vCenter NSX environment you must initiate the port change on the primary NSX Manager. For
each stage, the configuration changes are made on all hosts in the cross-vCenter NSX environment
before proceeding to the next stage.
Prerequisites
n Verify that the port you want to use for VXLAN is not blocked by a firewall.
n Verify that host preparation is not running at the same time as the VXLAN port change.
Procedure
1 Click the Logical Network Preparation tab, then click VXLAN Transport.
2 Click the Change button in the VXLAN Port panel. Enter the port you want to switch to. 4789 is the
port assigned by IANA for VXLAN.
It will take a short time for the port change to propagate to all hosts.
GET https://nsxmgr-01a/api/2.0/vdn/config/vxlan/udp/port/taskStatus
...
Details regarding the data collected through CEIP and the purposes for which it is used by VMware are
set forth at the Trust & Assurance Center at http://www.vmware.com/trustvmware/ceip.html.
To join or leave the CEIP for NSX, or edit program settings, see Edit the Customer Experience
Improvement Program Option.
Prerequisites
n Verify that the NSX manager is connected and can sync with vCenter Server.
Procedure
1 In the vSphere Web Client, click Networking & Security > NSX Home.
4 Select or deselect the Join the VMware Customer Experience Improvement Program option.
6 Click OK.
For information on configuring a syslog server for hosts managed by a vCenter Server, see the
appropriate version of vSphere documentation at https://docs.vmware.com.
Note Syslog or jump servers used to collect logs and access an NSX Distributed Logical Router (DLR)
Control VM can't be on the logical switch that is directly attached to that DLR's logical interfaces.
ESXi Logs These logs are collected as part of the VM support bundle generated from
vCenter Server.
For more information on ESXi log files, refer to vSphere documentation.
NSX Edge Logs Use the show log [follow | reverse] command in the NSX Edge CLI.
Download Technical Support Log bundle via NSX Edge UI.
NSX Manager Logs Use the show log CLI command in the NSX Manager CLI.
Download Technical Support Log bundle via the NSX Manager Virtual Appliance UI.
Routing Logs See the NSX Logging and System Events Guide.
Guest Introspection Logs See NSX Logging and System Events Guide.
NSX Manager
To specify a syslog server, see Configure a Syslog Server for NSX Manager.
To download technical support logs, see Download Technical Support Logs for NSX.
NSX Edge
To specify a syslog server, see Configure Syslog Servers for NSX Edge.
To download technical support logs, see Download Tech Support Logs for NSX Edge.
NSX Controller
To specify a syslog server, see Configuring a Syslog Server for NSX Controller.
To download technical support logs, see Download Technical Support Logs for NSX Controller.
Firewall
For more details, refer to Firewall Logs.
Audit Logs
Audit logs for operations tracked by a ticket includes the ticket ID. With the NSX ticket logger feature, you
can track the changes you make with a ticket ID.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Events.
2 Click the Manage tab, and then click NSX Ticket Logger.
The NSX Ticket Logging pane is displayed at the right side of the vSphere Web Client window. Audit
logs for the operations that you perform in the current UI session include the ticket ID in the
Operation Tags column.
If multiple vCenter Servers are being managed by the vSphere Web Client, the ticket ID is used for
logging on all applicable NSX Managers.
What to do next
Ticket logging is session based. If ticket logging is on and you log out or if the session is lost, ticket
logging will be turned off by default when you re-login to the UI. When you complete the operations for a
ticket, you turn logging off by repeating steps 2 and 3 and clicking Turn Off.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Events.
3 If multiple IP addresses are available in the NSX Manager drop-down menu, select an IP address, or
keep the default selection.
The audit log details are displayed in the Audit Logs tab.
4 When details are available for an audit log, the text in the Operation column for that log is clickable.
To view details of an audit log, click the text in the Operation column.
5 In the Audit Log Change Details, select Changed Rows to display only those properties whose
values have changed for this audit log operation.
System Events
System events are events that are related to NSX operations. They are raised to detail every operational
event. Events might relate to basic operation (Informational) or to a critical error (Critical).
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Events.
You can click the arrows in the column headers to sort events, or use the Filter text box to filter
events.
Alarms
Alarms are notifications that are activated in response to an event, a set of conditions, or the state of an
object. Alarms, along with other alerts, are displayed on the NSX Dashboard and other screens on the
vSphere Web Client UI.
You can use the GET api/2.0/services/systemalarms API to view alarms on NSX objects.
n Alarm corresponds to a system event and has an associated resolver that will attempt to resolve the
issue that triggers the alarm. This approach is designed for network and security fabric deployment
(for example, EAM, Message Bus, Deployment Plug-In), and is also supported by Service Composer.
These alarms use the event code as the alarm code. For more details, refer to NSX Logging and
System Events document.
n Edge notifications alarms are structured as a triggering and resolving alarm pair. This method is
supported by several Edge functions, including IPSec VPN, load balancer, high availability, health
check, edge file system, and resource reservation. These alarms use a unique alarm code which is
not the same as the event code. For more details, refer to NSX Logging and System Events
document.
Generally, an alarm gets automatically deleted by the system when the error condition is rectified. Some
alarms are not auto cleared on a configuration update. Once the issue is resolved, you have to clear the
alarms manually.
Here is an example of the API that you can use to clear the alarms.
You can get alarms for a specific source, for example, cluster, host, resource pool, security group, or NSX
Edge. View alarms for a source by sourceId:
GET https://<<NSX-IP>>/api/2.0/services/alarms/{sourceId}
POST https://<<NSX-IP>>/api/2.0/services/alarms/{sourceId}?action=resolve
You can view NSX alarms, including Message Bus, Deployment Plug-In, Service Composer, and Edge
alarms:
GET https://<<NSX-IP>>/api/2.0/services/systemalarms
GET https://<<NSX-IP>>/api/2.0/services/systemalarms/<alarmId>
POST https://<<NSX-IP>>/api/2.0/services/systemalarms/<alarmId>?action=resolve
Format of an Alarm
You can view format of an alarm through API.
SNMP traps must have the SNMPv2c version. The traps must be associated with a management
information base (MIB) so that the SNMP receiver can process the traps with object identifiers (OID).
By default, the SNMP trap mechanism is disabled. Enabling the SNMP trap only activates the critical and
high severity notifications so that the SNMP manager does not get inundated by a high volume of
notifications. An IP address or a host name defines the trap destination. For the host name to work for the
trap destination, the device must be set up to query a Domain Name System (DNS) server.
When you enable the SNMP service, a coldStart trap with OID 1.3.6.1.6.3.1.1.5.1 is sent out the first time.
A warmStart trap with OID 1.3.6.1.6.3.1.1.5.2 is sent out later on each stop-start to the configured SNMP
receivers.
If the SNMP service remains enabled, a heartbeat trap vmwHbHeartbeat with OID
1.3.6.1.4.1.6876.4.190.0.401 is sent out every five minutes. When you disable the service, a
vmwNsxMSnmpDisabled trap with OID 1.3.6.1.4.1.6876.90.1.2.1.0.1 is sent out. This process stops the
vmwHbHeartbeat trap from running and disables the service.
When you add, modify, or delete a SNMP receiver value, a warmStart trap with OID 1.3.6.1.6.3.1.1.5.2
and vmwNsxMSnmpManagerConfigUpdated trap with OID 1.3.6.1.4.1.6876.90.1.2.1.0.2 is sent to the
new or updated set of SNMP receivers.
Prerequisites
n Familiarize yourself with the SNM trap mechanism. See Working with SNMP Traps.
n Download and install the MIB module for the NSX Manager so that the SNMP receiver can process
the traps with OID. See http://kb.vmware.com/kb/1013445.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Events.
2 Click the Manage tab. If multiple NSX Managers are available, select an IP address of an
NSX Manager from the NSX Manager drop-down menu.
Option Description
Service Sends out SNMP trap.
By default, this option is disabled.
Group Notification Predefined set of groups for some system events that are used to aggregate the
events that are raised. By default, this option is enabled.
For example, if a system event belongs to a group, the trap for these grouped
events are withheld. Every five minutes a trap is sent out detailing the number of
system events that have been received from the NSX Manager. The fewer traps
being sent out save the SNMP receiver resources.
5 Click OK.
The SNMP service is enabled and traps are sent out to the receivers.
What to do next
Check whether the SNMP configuration works. See Verify SNMP Trap Configuration.
Prerequisites
Verify that you have SNMP configured. See Configure SNMP Settings.
Procedure
c Click OK.
A warmStart trap with OID 1.3.6.1.6.3.1.1.5.2 is sent out to all the SNMP receivers.
a If the SNMP receiver does not receive the traps, verify that the SNMP receiver is running on a
configured port.
b Check the accuracy of the receiver details under the SNMP settings section.
d If the Heartbeat trap stops, check whether the SNMP service is disabled or test whether the
network connectivity between the NSX Manager and the SNMP receiver is working.
When the Module, SNMP OID, or SNMP trap enabled column value appears as --, it means that those
events have not been allocated a trap OID. Therefore, a trap for these events is not going to be sent out.
A system trap has several columns that list different aspects of a system event.
Option Description
Severity Level of an event can be informational, low, medium, major, critical, or high.
By default when the SNMP service is enabled, traps are sent out for only critical and high severity events to
highlight the traps that require immediate attention.
SNMP OID Represents the individual OID and this OID is sent out when a system event is raised.
Group notification is enabled by default. When group notifications is enabled, the events or traps under this
group show the OID of the group the event or trap belongs to.
For example, group notification OID categorized under configuration group has the OID
1.3.6.1.4.1.6876.90.1.2.0.1.0.1.
SNMP trap Shows whether sending out of the trap for this event is enabled or disabled.
enabled You can toggle the icon to individually an event or trap enablement. When group notification is enabled, you
cannot toggle the trap enablement.
Prerequisites
Verify that the SNMP settings are available. See Configure SNMP Settings.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > System > Events.
2 Click the Manage tab, and then select an NSX Manager IP address.
4
Click the Edit ( ) icon.
Editing a trap enablement is not allowed when group notification is enabled. You can change the
enablement of traps that do not belong to a group.
5 Change the severity of the system event from the drop-down menu.
6 If you change the severity from Informational to critical, check the Enable as SNMP Trap checkbox.
7 Click OK.
8
(Optional) Click the Enable ( ) icon or Disable ( ) icon in the header to enable or disable sending
a system trap.
9 (Optional) Click the Copy ( ) icon to copy one or more event rows to your clipboard.
Procedure
1 Open a Web browser window and type the IP address assigned to the NSX Manager. For example,
https://192.168.110.42.
The NSX Manager user interface opens in a web browser window using SSL.
3 Log in to the NSX Manager virtual appliance by using the user name admin and the password you set
during installation.
The following events are specific to the NSX Manager virtual appliance.
Local CLI Run show log follow Run show log follow Run show log follow Run show log follow
command. command. command. command.
GUI NA NA NA NA
Local CLI Run show process monitor Run show system memory Run show filesystem command.
command. command.
GUI NA NA NA
Procedure
5 Click OK.
Syslog data is useful for troubleshooting and reviewing data logged during installation and configuration.
Procedure
2 From the home page, click Manage Appliance Settings > General.
4 Type the IP address or hostname, port, and protocol of the syslog server.
For example:
5 Click OK.
NSX Manager remote logging is enabled, and logs are stored in your syslog server. If you have
configured multiple syslog servers, logs are stored in all the configured syslog servers.
What to do next
n In a Cross-vCenter NSX environment, you should enable the FIPS mode on each NSX Manager
separately.
n If one of the NSX Managers is not configured for FIPS, you must still ensure that it uses a secure
communication method which complies with the FIPS standards.
n Both primary and secondary NSX Managers must be on the same TLS version for universal
synchronization to work correctly.
Important Changing FIPS mode reboots the NSX Manager virtual appliance.
Prerequisites
n Verify any partner solutions are FIPS mode certified. See the VMware Compatibility Guide at
http://www.vmware.com/resources/compatibility/search.php?deviceCategory=security.
n If you have upgraded from an earlier version of NSX, do not enable FIPS mode until the upgrade to
NSX 6.3.0 is complete. See Understand FIPS Mode and NSX Upgrade in the NSX Upgrade Guide.
n Verify that all host clusters running NSX workloads are prepared with NSX 6.3.0 or later.
n Verify that all NSX Edge appliances are version 6.3.0 or later, and that FIPS mode has been enabled
on the required NSX Edge appliances. See Change FIPS Mode on NSX Edge.
Procedure
5 To enable FIPS mode, select the Enable FIPS Mode check box.
6 For Server and Client, select the check boxes for the required TLS protocol version.
Note When FIPS mode is enabled, NSX Manager disables the TLS protocols that are not complaint
to the FIPS standards.
7 Click OK.
Procedure
6 Click OK.
Procedure
6 Click OK.
Procedure
7 Click OK.
Procedure
3
Click and then click Download Tech Support Log.
4 Click Download.
5 After the log is ready, click the Save to download the log to your desktop.
What to do next
You can open the log using a decompression utility by browsing for All Files in the directory where you
saved the file.
To obtain the NSX Manager certificate, you can use NSX Manager's built-in CSR generator or you can
use another tool such as OpenSSL.
A CSR generated using NSX Manager's built-in CSR generator cannot contain extended attributes such
as subject alternate name (SAN). If you wish to include extended attributes, you must use another CSR
generation tool. If you are using another tool such as OpenSSL to generate the CSR, the process is 1)
generate the CSR, 2) have it signed, and 3) proceed to the section Convert the NSX Manager Certificate
File to PKCS#12 Format.
This method is limited in that the CSR cannot contain extended attributes such as subject alternate name
(SAN). If you wish to include extended attributes, you must you another CSR generation tool. If you are
using another CSR generation tool, skip this procedure.
Procedure
Option Action
Key Size Select the key length used in the selected algorithm.
Common Name Type the IP address or fully qualified domain name (FQDN) of the NSX Manager.
VMware recommends that you enter the FQDN.
Organization Unit Enter the department in your company that is ordering the certificate.
City Name Enter the full name of the city in which your company resides.
State Name Enter the full name of the state in which your company resides.
Country Code Enter the two-digit code that represents your country. For example, the United
States is US.
6 Click OK.
Using this method, the private key never leaves the NSX Manager.
c Get the Signed Certificate and Root CA and any intermediary CA certificates in PEM format.
d To convert CER/DER formatted certificates to PEM, use the following OpenSSL command:
e Concatenate all the certificates (server, intermediary and root certificates) in a text file.
f In the NSX Manager UI, click Import and browse to the text file with all of the certificates.
g Once the import is successful, the server certificate and all the CA certificates will be shown on
the SSL Certificates page.
What to do next
Prerequisites
Verify that OpenSSL is installed on the system. You can download openssl from http://www.openssl.org.
Procedure
u After receiving the signed certificate from the authorized signer, use OpenSSL to generate a
PKCS#12 (.pfx or .p12) keystore file from the certificate file and your private key.
For example:
openssl pkcs12 -export -out server.p12 -inkey server.key -in server.crt -certfile CACert.crt
In this example, CACert.crt is the name of the root certificate that was returned by the certificate
authority.
What to do next
Prerequisites
When installing a certificate on NSX Manager, only the PKCS#12 keystore format is supported, and it
must contain a single private key and its corresponding signed certificate or certificate chain.
Procedure
6 Click Import.
The NSX Manager backup contains all of the NSX configuration, including controllers, logical switching
and routing entities, security, firewall rules, and everything else that you configure within the NSX
Manager UI or API. The vCenter database and related elements like the virtual switches need to be
backed up separately.
At a minimum, we recommend taking regular backups of NSX Manager and vCenter. Your backup
frequency and schedule might vary based on your business needs and operational procedures. We
recommend taking NSX backups frequently during times of frequent configuration changes.
NSX Manager backups can be taken on demand or on an hourly, daily, or weekly basis.
n After Day Zero deployment and initial configuration of NSX components, such as after the creation of
NSX Controllers, logical switches, logical routers, edge services gateways, security, and firewall
policies.
To provide an entire system state at a given time to roll back to, we recommend synchronizing NSX
component backups (such as NSX Manager) with your backup schedule for other interacting
components, such as vCenter, cloud management systems, operational tools, and so on.
The backup file is saved to a remote FTP or SFTP location that NSX Manager can access. NSX Manager
data includes configuration, events, and audit log tables. Configuration tables are included in every
backup.
Restore is only supported on the same NSX Manager version as the backup version. For this reason, it is
important to create a new backup file before and after performing an NSX upgrade, one backup for the
old version and another backup for the new version.
Procedure
3 To specify the backup location, click Change next to FTP Server Settings.
b From the Transfer Protocol drop-down menu, select either SFTP or FTP, based on what the
destination supports.
d Type the user name and password required to login to the backup system.
e In the Backup Directory field, type the absolute path where backups will be stored.
To determine the absolute path, you can log in to the FTP server, navigate to the directory that
you want to use, and run the present working directory command (pwd). For example:
This text is prepended to each backup filename for easy recognition on the backup system. For
example, if you type ppdb, the resulting backup is named as ppdbHH_MM_SS_YYYY_Mon_Day.
Note Files in the Backup Directory must be limited to 100. If number of files in the directory
exceeds the limit, you will receive a warning message.
h Click OK.
For example:
a From the Backup Frequency drop-down menu, select Hourly, Daily, or Weekly. The Day of
Week, Hour of Day, and Minute drop-down menus are disabled based on the selected frequency.
For example, if you select Daily, the Day of Week drop-down menu is disabled as this field is not
applicable to a daily frequency.
b For a weekly backup, select the day of the week the data should be backed up.
c For a weekly or daily backup, select the hour at which the backup should begin.
6 To exclude logs and flow data from being backed up, click Change next to Exclude.
b Click OK.
7 Save your FTP server IP/hostname, credentials, directory details, and pass phrase. This information
is needed to restore the backup.
Prerequisites
Before restoring NSX Manager data, we recommend reinstalling the NSX Manager appliance. Running
the restore operation on an existing NSX Manager appliance might work, too, but is not supported. The
assumption is that the existing NSX Manager has failed, and therefore a new NSX Manager appliance is
deployed.
The best practice is to take note of the current settings for the old NSX Manager appliance so that they
can be used to specify IP information and backup location information for the newly deployed NSX
Manager appliance.
Procedure
1 Take note of all settings on the existing NSX Manager appliance. Also, note down FTP server
settings.
The version must be the same as the backed up NSX Manager appliance.
5 In FTP Server Settings, click Change and add the FTP server settings.
The Host IP Address, User Name, Password, Backup Directory, Filename Prefix, and Pass
Phrase fields in the Backup Location screen must identify the location of the backup to be restored.
Note If the backup folder does not appear in the Backup History section, verify the FTP server
settings. Check if you can connect to FTP server and view the backup folder.
6 In the Backup History section, select the required backup folder to restore, and click Restore.
Caution After restoring an NSX Manager backup, you might need to take additional action to ensure
correct operation of NSX Edge appliances and logical switches. See Restore NSX Edges and Resolve
Out of Sync Errors on Logical Switches.
If you have an intact NSX Manager configuration, you can recreate an inaccessible or failed Edge
appliance VM by redeploying the NSX Edge (click Redeploy NSX Edge ( ) in the vSphere Web Client).
See "Redeploy NSX Edge" in the NSX Administration Guide.
Caution After restoring an NSX Manager backup, you might need to take additional action to ensure
correct operation of NSX Edge appliances.
n Edge appliances created after last backup are not removed during restore. You must delete the VM
manually.
n Edge appliances deleted after the last backup are not restored unless redeployed.
n If both the configured and current locations of an NSX Edge appliance saved in the backup no longer
exist when the backup is restored, operations such as redeploy, migrate, enable or disable HA will
fail. You must edit the appliance configuration and provide valid location information. Use
PUT /api/4.0/edges/{edgeId}/appliances to edit the appliance location configuration
(resourcePoolId, datastoreId, hostId and vmFolderId as necessary). See "Working With NSX Edge
Appliance Configuration" in the NSX API Guide.
If any of the following changes have occurred since the last NSX Manager backup, the restored NSX
Manager configuration and the configuration present on the NSX Edge appliance will differ. You must
Force Sync the NSX Edge to revert these changes on the appliance and ensure correct operation of the
NSX Edge. See "Force Sync NSX Edge with NSX Manager" in the NSX Administration Guide.
n Changes made via Distributed Firewall for preRules for NSX Edge firewall.
If any of the following changes have occurred since the last NSX Manager backup, the restored NSX
Manager configuration and the configuration present on the NSX Edge appliance will differ. You must
Redeploy the NSX Edge to revert these changes on the appliance and ensure correct operation of the
NSX Edge. See "Redeploy NSX Edge" in the NSX Administration Guide.
n HA enabled or disabled
n port groups
n trunk ports
n fence parameters
n shaping policy
Procedure
3 If present, click the Out of sync link in the Status column to display error details.
4 Click Resolve to recreate missing backing port groups for the logical switch.
The file preserves valid network configurations, enabling distribution of these configurations to other
deployments.
vSphere Distributed Switch settings and port-group settings are imported as part of the import.
As a best practice, export the vSphere Distributed Switch configuration before preparing the cluster for
VXLAN. For detailed instructions, see http://kb.vmware.com/kb/2034602.
Back Up vCenter
To secure your NSX deployment, it is important to back up the vCenter database and take snapshots of
the VMs.
Refer to the vCenter documentation for your vCenter version for vCenter backup and restore procedures
and best practices.
n The vSphere Installation and Setup documentation for your version of vSphere
n http://kb.vmware.com/kb/2110294
Flow Monitoring
Flow monitoring is a traffic analysis tool that provides a detailed view of the traffic to and from protected
virtual machines. When flow monitoring is enabled, its output defines which machines are exchanging
data and over which application. This data includes the number of sessions and packets transmitted per
session. Session details include sources, destinations, applications, and ports being used. Session
details can be used to create firewall to allow or block rules.
You can view flow data for many different protocol types, including TCP, UDP, ARP, ICMP, and so on. You
can live monitor TCP and UDP connections to and from a selected vNIC. You can also exclude flows by
specifying filters.
Flow monitoring can thus be used as a forensic tool to detect rogue services and examine outbound
sessions.
Prerequisites
Flow monitoring data is only available for virtual machines in clusters that have the network virtualization
components installed and firewall enabled. See the NSX Installation Guide.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Tools > Flow Monitoring.
The page might take several seconds to load. The top of the page displays the percentage of allowed
traffic, traffic blocked by firewall rules, and traffic blocked by SpoofGuard. The multiple line graph
displays data flow for each service in your environment. When you point to a service in the legend
area, the plot for that service is highlighted.
n Top Flows displays the total incoming and outgoing traffic per service over the specified time
period based on the total bytes value (not based on sessions/packets). The top five services are
displayed. Blocked flows are not considered when calculating top flows.
n Top Destinations displays incoming traffic per destination over the specified time period. The top
five destinations are displayed.
n Top Sources displays outgoing traffic per source over the specified time period. The top five
sources are displayed.
Details about all traffic for the selected service is displayed. The Allowed Flows tab displays the
allowed traffic sessions and the Blocked Flows tab displays the blocked traffic.
5 Click an item in the table to display the rules that allowed or blocked that traffic flow.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Tools > Flow Monitoring.
3 Select the time period or type a new start and end date.
The maximum time span for which you can view traffic flow data is the previous two weeks.
4 Click OK.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Tools > Flow Monitoring.
Depending on the selected tab, rules that allowed or denied traffic for this service are displayed.
n To edit a rule:
3 Click OK.
n To add a rule:
2 Complete the form to add a rule. For information on completing the firewall rule form, see Add
a Distributed Firewall Rule.
3 Click OK.
Viewing live flows can affect the performance of NSX Manager and the corresponding virtual machine.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Tools > Flow Monitoring.
The page refreshes every 5 seconds. You can select a different frequency from the Refresh Rate
drop-down.
5 Click Stop when your debugging or troubleshooting is done to avoid affecting the performance of
NSX Manager or the selected virtual machine.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Tools > Flow Monitoring.
All firewall related flows are collected across your inventory except for the objects specified in
Exclusion Settings.
4 To specify filtering criteria, click Flow Exclusion and follow the steps below.
Service Excludes flows for the specified services and service groups.
1 Click the Add icon.
2 Select the appropriate services and/or service groups.
c Click Save.
5 To configure flow collection, click IPFix and follow the steps as described in IPFIX for Distributed
Firewall.
Configure IPFIX
IPFIX (Internet Protocol Flow Information Export) is an IETF protocol that defines the standard of
exporting flow information from an end device to a monitoring system. NSX supports IPFIX to export IP
flow information to a collector.
In the vSphere environment, vSphere Distributed Switch is the exporter and the collector is any
monitoring tool available from any networking vendor.
The IPFIX standard specifies how IP flow information is presented and transferred from an exporter to a
collector.
After you enable IPFIX on the vSphere Distributed Switch, it periodically sends messages to the collector
tool. The contents of these messages are defined using the templates. For more information on
templates, refer to IPFIX Templates.
Logical Switch
HV1/vSwitch HV2/vSwitch
Flow Collector
Virtual (Overlay)
Physical (Underlay)
TOR2 TOR3
TOR1 TOR4
Network
IPFIX (DFW)
Overlay Tunnel
You can enable a flow export for IPFIX on a distributed firewall are as follows:
2 Click Networking & Security, and then under Tools, click Flow Monitoring.
5 To configure flow collection, click IPFix and follow the preceding steps.
a Click Edit next to IPFix Configuration and click Enable IPFix Configuration.
b In Observation DomainID, enter a 32-bit identifier that identifies the firewall exporter to the flow
collector. Valid range is 0–65535.
c In Active Flow Export Timeout, type the time (in minutes) after which active flows are to be
exported to the flow collector. The default value is five. For example, if the flow is active for 30
minutes and the export timeout is five minutes, then the flow is exported seven times during its
lifetime. One for each creation and deletion, and five times during the active period.
d In Collector IPs, click the Add (Add) icon and enter the IP address and UDP port of the flow
collector. Refer to your NetFlow collector documentation to determine the port number.
e Click OK.
Logical Switch
HV1/vSwitch HV2/vSwitch
Flow Collector
Virtual (Overlay)
Physical (Underlay)
TOR2 TOR3
TOR1 TOR4
Network
IPFIX (vNic)
IPFIX (pNic)
Overlay Tunnel
1 Configure the NetFlow collector on the vSphere Distributed Switch backing the NSX transport zone
(Logical Switch). For more information on how to configure NetFlow collector, see "Configure the
NetFlow Settings of a vSphere Distributed Switch" topic in the vSphere Networking Guide.
2 You can enable NetFlow monitoring on the distributed port group corresponding to the Logical
Switch. If the NSX transport zone spans multiple vSphere Distributed Switches (VDS), then repeat
these steps for each VDS/distributed port group. For more information on how to enable NetFlow
monitoring, see "Enable or Disable NetFlow Monitoring on a Distributed Port Group or Distributed
Port in the vSphere documentation.
In an NSX environment, the virtual machine data traffic on a logical switch traversing the NSX uplink of
ESXi is VXLAN encapsulated. When NetFlow is enabled on the host uplink, the IP flow records are
exported using a custom IPFIX flow-record template. The template includes the outer VXLAN UDP/IP
header information and the information of the inner encapsulated IP packet. Such flow record, as a result
provides visibility on the VTEP that is encapsulating the packet (outer header) and the details of the
virtual machine that generated inter-host traffic (inner header) on a NSX logical switch (VXLAN).
For more details on the IPFIX templates for vSphere Distributed Switch, refer to IPFIX Templates.
IPFIX Templates
IPFIX templates provides the visibility into the VXLAN and non- VXLAN flows. The templates have
additional parameters that provide more information regarding the encapsulated traffic.
The templates are supported in vSphere Distributed Switch (exporter). IPFIX support on vSphere
Distributed Switch provides the required visibility into the virtual machine flows and VXLAN flows. If you
are using any third party collector tool , you can use additional information available in the templates to
provide correlation between the internal and external flows and the port connections.
IPv4 Template
IPFIX_TEMPLATE_START(IPFIX_FLOW_TYPE_IPv4)
IPFIX_TEMPLATE_FIELD(sourceIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(destinationIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(octetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(packetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(flowStartSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(flowEndSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(sourceTransportPort, 2)
IPFIX_TEMPLATE_FIELD(destinationTransportPort, 2)
IPFIX_TEMPLATE_FIELD(ingressInterface, 4)
IPFIX_TEMPLATE_FIELD(egressInterface, 4)
IPFIX_TEMPLATE_FIELD(vxlanId, 8)
IPFIX_TEMPLATE_FIELD(protocolIdentifier, 1)
IPFIX_TEMPLATE_FIELD(flowEndReason, 1)
IPFIX_TEMPLATE_FIELD(tcpFlags, 1)
IPFIX_TEMPLATE_FIELD(IPv4TOS, 1)
IPFIX_TEMPLATE_FIELD(maxTTL, 1)
IPFIX_TEMPLATE_FIELD(flowDir, 1)
// Specify the Interface port- Uplink Port, Access port,N.A
IPFIX_VMW_TEMPLATE_FIELD(ingressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(egressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(vxlanExportRole, 1)
IPFIX_TEMPLATE_PADDING(paddingOctets, 1)
IPFIX_TEMPLATE_END()
IPFIX_TEMPLATE_START(IPFIX_FLOW_TYPE_IPv4_VXLAN)
IPFIX_TEMPLATE_FIELD(sourceIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(destinationIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(octetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(packetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(flowStartSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(flowEndSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(sourceTransportPort, 2)
IPFIX_TEMPLATE_FIELD(destinationTransportPort, 2)
IPFIX_TEMPLATE_FIELD(ingressInterface, 4)
IPFIX_TEMPLATE_FIELD(egressInterface, 4)
IPFIX_TEMPLATE_FIELD(protocolIdentifier, 1)
IPFIX_TEMPLATE_FIELD(flowEndReason, 1)
IPFIX_TEMPLATE_FIELD(tcpFlags, 1)
IPFIX_TEMPLATE_FIELD(IPv4TOS, 1)
IPFIX_TEMPLATE_FIELD(maxTTL, 1)
IPFIX_TEMPLATE_FIELD(flowDir, 1)
IPFIX_TEMPLATE_FIELD(vxlanId, 8)
IPFIX_VMW_TEMPLATE_FIELD(tenantSourceIPv4, 4)
IPFIX_VMW_TEMPLATE_FIELD(tenantDestIPv4, 4)
IPFIX_VMW_TEMPLATE_FIELD(tenantSourcePort, 2)
IPFIX_VMW_TEMPLATE_FIELD(tenantDestPort, 2)
IPFIX_VMW_TEMPLATE_FIELD(tenantProtocol, 1)
// Specify the Interface port- Uplink Port, Access port,N.A
IPFIX_VMW_TEMPLATE_FIELD(ingressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(egressInterfaceAttr, 2)
// TUNNEL-GW or no.
IPFIX_VMW_TEMPLATE_FIELD(vxlanExportRole, 1)
IPFIX_TEMPLATE_END()
IPFIX_TEMPLATE_START(IPFIX_FLOW_TYPE_IPv4_ICMP_VXLAN)
IPFIX_TEMPLATE_FIELD(sourceIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(destinationIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(octetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(packetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(flowStartSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(flowEndSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(sourceTransportPort, 2)
IPFIX_TEMPLATE_FIELD(destinationTransportPort, 2)
IPFIX_TEMPLATE_FIELD(ingressInterface, 4)
IPFIX_TEMPLATE_FIELD(egressInterface, 4)
IPFIX_TEMPLATE_FIELD(protocolIdentifier, 1)
IPFIX_TEMPLATE_FIELD(flowEndReason, 1)
IPFIX_TEMPLATE_FIELD(IPv4TOS, 1)
IPFIX_TEMPLATE_FIELD(maxTTL, 1)
IPFIX_TEMPLATE_FIELD(flowDir, 1)
IPFIX_TEMPLATE_FIELD(vxlanId, 8)
IPFIX_VMW_TEMPLATE_FIELD(tenantSourceIPv4, 4)
IPFIX_VMW_TEMPLATE_FIELD(tenantDestIPv4, 4)
IPFIX_VMW_TEMPLATE_FIELD(tenantProtocol, 1)
// Specify the Interface port- Uplink Port, Access port,N.A
IPFIX_VMW_TEMPLATE_FIELD(ingressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(egressInterfaceAttr, 2)
// TUNNEL-GW or no.
IPFIX_VMW_TEMPLATE_FIELD(vxlanExportRole, 1)
IPFIX_TEMPLATE_PADDING(paddingOctets, 1)
IPFIX_TEMPLATE_END()
IPFIX_TEMPLATE_START(IPFIX_FLOW_TYPE_IPv4_ICMP)
IPFIX_TEMPLATE_FIELD(sourceIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(destinationIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(octetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(packetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(flowStartSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(flowEndSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(ingressInterface, 4)
IPFIX_TEMPLATE_FIELD(egressInterface, 4)
IPFIX_TEMPLATE_FIELD(protocolIdentifier, 1)
IPFIX_TEMPLATE_FIELD(flowEndReason, 1)
IPFIX_TEMPLATE_FIELD(IPv4TOS, 1)
IPFIX_TEMPLATE_FIELD(maxTTL, 1)
IPFIX_TEMPLATE_FIELD(flowDir, 1)
IPFIX_TEMPLATE_FIELD(vxlanId, 8)
// Specify the Interface port- Uplink Port, Access Port,or NA.
IPFIX_VMW_TEMPLATE_FIELD(ingressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(egressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(vxlanExportRole, 1)
IPFIX_TEMPLATE_PADDING(paddingOctets, 2)
IPFIX_TEMPLATE_END()
IPFIX_TEMPLATE_START(IPFIX_FLOW_TYPE_IPv6_ICMP_VXLAN)
IPFIX_TEMPLATE_FIELD(sourceIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(destinationIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(octetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(packetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(flowStartSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(flowEndSysUpTime, 8)
IPFIX_VMW_TEMPLATE_FIELD(sourceTransportPort, 2)
IPFIX_VMW_TEMPLATE_FIELD(destinationTransportPort, 2)
IPFIX_TEMPLATE_FIELD(ingressInterface, 4)
IPFIX_TEMPLATE_FIELD(egressInterface, 4)
IPFIX_TEMPLATE_FIELD(protocolIdentifier, 1)
IPFIX_TEMPLATE_FIELD(IPv6TOS, 1)
IPFIX_TEMPLATE_FIELD(maxTTL, 1)
IPFIX_TEMPLATE_FIELD(flowDir, 1)
IPFIX_TEMPLATE_FIELD(flowEndReason, 1)
//VXLAN Specific
IPFIX_TEMPLATE_FIELD(vxlanId, 8)
IPFIX_VMW_TEMPLATE_FIELD(tenantSourceIPv6, 16)
IPFIX_VMW_TEMPLATE_FIELD(tenantDestIPv6, 16)
IPFIX_VMW_TEMPLATE_FIELD(tenantProtocol, 1)
// Specify the Interface port- Uplink Port, Access Port, or NA.
IPFIX_VMW_TEMPLATE_FIELD(ingressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(egressInterfaceAttr, 2)
// TUNNEL-GW or no.
IPFIX_VMW_TEMPLATE_FIELD(vxlanExportRole, 1)
IPFIX_TEMPLATE_PADDING(paddingOctets, 1)
IPFIX_TEMPLATE_END()
IPFIX_TEMPLATE_START(IPFIX_FLOW_TYPE_IPv6_ICMP)
IPFIX_TEMPLATE_FIELD(sourceIPv6Address, 16)
IPFIX_TEMPLATE_FIELD(destinationIPv6Address, 16)
IPFIX_TEMPLATE_FIELD(octetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(packetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(flowStartSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(flowEndSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(ingressInterface, 4)
IPFIX_TEMPLATE_FIELD(egressInterface, 4)
IPFIX_TEMPLATE_FIELD(protocolIdentifier, 1)
IPFIX_TEMPLATE_FIELD(flowEndReason, 1)
IPFIX_TEMPLATE_FIELD(IPv6TOS, 1)
IPFIX_TEMPLATE_FIELD(maxTTL, 1)
IPFIX_TEMPLATE_FIELD(flowDir, 1)
IPFIX_TEMPLATE_FIELD(vxlanId, 8)
// Specify the Interface port- Uplink Port, Access Port,or NA.
IPFIX_VMW_TEMPLATE_FIELD(ingressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(egressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(vxlanExportRole, 1)
IPFIX_TEMPLATE_PADDING(paddingOctets, 2)
IPFIX_TEMPLATE_END()
IPv6 Template
IPFIX_TEMPLATE_START(IPFIX_FLOW_TYPE_IPv6)
IPFIX_TEMPLATE_FIELD(sourceIPv6Address, 16)
IPFIX_TEMPLATE_FIELD(destinationIPv6Address, 16)
IPFIX_TEMPLATE_FIELD(octetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(packetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(flowStartSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(flowEndSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(sourceTransportPort, 2)
IPFIX_TEMPLATE_FIELD(destinationTransportPort, 2)
IPFIX_TEMPLATE_FIELD(ingressInterface, 4)
IPFIX_TEMPLATE_FIELD(egressInterface, 4)
IPFIX_TEMPLATE_FIELD(vxlanId, 8)
IPFIX_TEMPLATE_FIELD(protocolIdentifier, 1)
IPFIX_TEMPLATE_FIELD(flowEndReason, 1)
IPFIX_TEMPLATE_FIELD(tcpFlags, 1)
IPFIX_TEMPLATE_FIELD(IPv6TOS,1)
IPFIX_TEMPLATE_FIELD(maxTTL, 1)
IPFIX_TEMPLATE_FIELD(flowDir, 1)
// Specify the Interface port- Uplink Port, Access Port, or NA.
IPFIX_VMW_TEMPLATE_FIELD(ingressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(egressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(vxlanExportRole, 1)
IPFIX_TEMPLATE_PADDING(paddingOctets, 1)
IPFIX_TEMPLATE_END()
IPFIX_TEMPLATE_FIELD(sourceIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(destinationIPv4Address, 4)
IPFIX_TEMPLATE_FIELD(octetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(packetDeltaCount, 8)
IPFIX_TEMPLATE_FIELD(flowStartSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(flowEndSysUpTime, 8)
IPFIX_TEMPLATE_FIELD(sourceTransportPort, 2)
IPFIX_TEMPLATE_FIELD(destinationTransportPort, 2)
IPFIX_TEMPLATE_FIELD(ingressInterface, 4)
IPFIX_TEMPLATE_FIELD(egressInterface, 4)
IPFIX_TEMPLATE_FIELD(protocolIdentifier, 1)
IPFIX_TEMPLATE_FIELD(flowEndReason, 1)
IPFIX_TEMPLATE_FIELD(tcpFlags, 1)
IPFIX_TEMPLATE_FIELD(IPv6TOS, 1)
IPFIX_TEMPLATE_FIELD(maxTTL, 1)
IPFIX_TEMPLATE_FIELD(flowDir, 1)
//VXLAN specific
IPFIX_TEMPLATE_FIELD(vxlanId, 8)
IPFIX_VMW_TEMPLATE_FIELD(tenantSourceIPv6, 16)
IPFIX_VMW_TEMPLATE_FIELD(tenantDestIPv6, 16)
IPFIX_VMW_TEMPLATE_FIELD(tenantSourcePort, 2)
IPFIX_VMW_TEMPLATE_FIELD(tenantDestPort, 2)
IPFIX_VMW_TEMPLATE_FIELD(tenantProtocol, 1)
// Specify the Interface port- Uplink Port, Access Port,or NA.
IPFIX_VMW_TEMPLATE_FIELD(ingressInterfaceAttr, 2)
IPFIX_VMW_TEMPLATE_FIELD(egressInterfaceAttr, 2)
// TUNNEL-GW or no.
IPFIX_VMW_TEMPLATE_FIELD(vxlanExportRole, 1)
IPFIX_TEMPLATE_END()
Additional Parameters
1 VXLAN Specific Parameters: The tenant specific fields are the inner flow IPs, ports and protocol
information.
n tenantSourceIPv4
n tenantSourceIPv6
n tenantDestIPv4
n tenantDestIPv6
n tenantSourcePort
n tenantDestPort
n tenantProtocol
2 Interface Port Parameters: These parameters can be used for both VXLAN and non-VXLAN
templates.
n ingressInterfaceAttr
n egressInterfaceAttr
n vxlanExportRole
The ingress and egress interface attributes can take the following values based on type of the port:
n IPFIX_UPLINK_PORT 0X01
n IPFIX_ACCESS_PORT 0X02
n IPFIX_VXLAN_TUNNEL_PORT 0X03
The vxlanExportRole defines if the exporter is an ESXi host or any other network device.
IPFIX_END_POINT 0X01 means host is exporting the data. If other devices export the IPFIX
templates, this field might have different value (not defined yet).
Standard Elements...
Host 1 Host 2
IngressInterfaceAttr:
0x02 - port1
IP1 IP2
EgressIngerfaceAttr:
0x03 - Management port
vxlanExportRole:
01 VDS VDS
1 2
Flow 2: IPv4 VXLAN Template
10 11 12 13
Standard Elements...
tenantSourceIPv4:
IP1
tenantDestIPv4:
IP2
Physical Switch
tenantSourcePort:
10000
tenantDestPort:
80
IngressInterfaceAttr:
0x03 - Management port
EgressIngerfaceAttr:
0x01 - dvuplink
vxlanExportRole:
01
The Figure 23‑2 shows the flows are collected from Host 1. The IPv4 template has additional information
about the ingress and egress port and the standard elements.
The ingressInterfaceAttr text box 0x02 indicates it is an access port where the virtual machine is
connected. The access port number is assigned to the ingressInterface parameter in the template.
The egressInterfaceAttr value of 0x03 shows that it is a VXLAN tunnel port and the port number
associated with it is a management VMKNic port. This port number is assigned to the egressInterface
parameter in the template.
The IPv4 VXLAN template on the other hand has additional information about the VXLAN ID, inner
source, and destination IP/Port and protocol. The ingress and egress interfaces are VXLAN tunnel port
and dvuplink port respectively.
Standard Elements...
Host 1 Host 2
IngressInterfaceAttr:
0x03 - Management port
IP1 IP2
EgressIngerfaceAttr:
0x02 – port3
vxlanExportRole:
VDS VDS 01
1 3
Flow 3: IPv4 VXLAN Template
10 11 12 13
Standard Elements...
tenantSourceIPv4:
IP1
tenantDestIPv4:
IP2
Physical Switch
tenantSourcePort:
10000
tenantDestPort:
80
IngressInterfaceAttr:
0x01 - dvuplink
EgressIngerfaceAttr:
0x03 - Management port
vxlanExportRole:
01
The templates in the Figure 23‑2 differs from the Figure 23‑2 only in the Ingress and egress attributes and
port numbers.
The additional information provided through this template helps the collector tool vendors to correlate the
external VXLAN flows and the internal virtual machine flows.
IPFIX support on vSphere Distributed Switch provides the required visibility into the virtual machine flows
and VXLAN flows. If you are using any collector tool vendor, you can use additional information available
in the templates to provide a correlation between the internal and external flows and the port connections.
The following section provides the details regarding how to decode the new parameters that are added in
the VXLAN templates. IANA defines IPFIX information elements and their element IDs. You can find the
list of standard element IDs at http://www.iana.org/assignments/ipfix/ipfix.xml.
All the new elements defined as part of VXLAN template have their new element IDs.
These custom parameters or elements provide additional information about the VXLAN and internal
flows. The following are the new elements and their IDs:
Note The Enterprise ID is appended to all the custom elements defined above. The enterprise ID for
VMware is 6876.
The following table shows an example of complete list of element IDs. You can find data type and unit for
standard element IDs at http://www.iana.org/assignments/ipfix/ipfix.xml.
1 octetDeltaCount
2 packetDeltaCount
4 protocolIdentifier
5 IPv4TOS
5 IPv6TOS
6 tcpFlags
7 sourceTransportPort
8 sourceIPv4Address
10 ingressInterface
11 destinationTransportPort
12 destinationIPv4Address
14 egressInterface
15 nextHopIPv4
27 sourceIPv6Address
28 destinationIPv6Address
53 maxTTL
61 flowDir
136 flowEndReason
152 flowStartSysUpTime
153 flowEndSysUpTime
210 paddingOctets
351 vxlanId
880 tenantProtocol
881 tenantSourceIPv4
882 tenantDestIPv4
883 tenantSourceIPv6
884 tenantDestIPv6
886 tenantSourcePort
887 tenantDestPort
888 egressInterfaceAttr
889 vxlanExportRole
890 ingressInterfaceAttr
Flow monitoring is used for long term data collection across the system, while the application rule
manager is used for a targeted modeling of an application.
1 Select virtual machines (VM) that form the application and need to be monitored. Once configured, all
incoming and outgoing flows for a defined set of VNICs (Virtualized Network Interface Cards) on the
VMs are monitored. There can be up to five sessions collecting flows at a time.
2 Stop the monitoring to generate the flow tables. The flows are analyzed to reveal the interaction
between VMs. The flows can be filtered to bring the flow records to a limited working set.
3 Use flow tables to create grouping objects such as security groups, IP sets, services and service
groups and firewall rules.
Prerequisites
Before starting a monitoring session, you need to define the VMs and vNICs that need to be monitored.
VMware Tools must be running and current on your Windows desktop VMs.
Selected VMs need to be in a cluster that has firewall enabled (they cannot be on the exclude list).
A default firewall rule of "any allow" that applies to the selected vNICs must be created for the duration of
the monitoring session, so that flows to and from the vNICs are not dropped by any other firewall rule.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Tools > Flow Monitoring.
4 In the Start New Session dialogue box, enter a name for the session.
6 Double-click the vNICs or VMs you want monitored. The selected vNICs or VMs move to the
Selected Objects column.
The status is now Collecting Data. The latest set of flows collected is shown in the flow table.
A flow monitoring session has been created for the selected vNICs and VMs.
What to do next
Analyze Flows
After a flow monitoring session has been collected, the results are analyzed and can be filtered for use in
grouping objects and firewall rules.
Analyzed flows can be filtered to limit the number of flows in a working set. The filter option icon is next to
the Processed View drop-down menu on the right.
Prerequisites
Before analysis, a flow monitoring session must have been collected from selected vNICs or VMs.
Procedure
Defined services are resolved, the IP address to VM translation begins, and duplicates are removed.
Field Options
Direction IN - flow is coming into one of the VM and VNIC selected as part of the input seed.
OUT - flow is generated from one of the VM and VNIC selected as part of the input seed.
INTRA- flow is between VM- and VNIC selected as part of the input seed.
Source VM Name, if the Source IP address of the flow record is resolved to one VM in the NSX inventory. Note that IP
address can be resolved to VM, only if VM Tools has been enabled on those VMs.
Raw IP, if there is no VM found for this source IP address in NSX Inventory. Note that multicast and broadcast
IP addresses will not be resolved to VMs.
Number of VMs (Ex:2 Virtual Machines) if the IP address is an overlapping IP address mapped to multiple
VMs in different networks, the user needs to resolve Virtual machines to the correct Virtual Machine related to
this flow record.
What to do next
Analyzed flows can be modified for further customization. Next, use the analyzed flows to create firewall
rules.
After system analysis is complete, the analyzed flow table is available in the Processed View. Users can
further consolidate the flows by changing the source, destination, and service fields. See Customizing
Services in Flow Records and Customizing Source and Destination in Flow Records.
Processed View
Field Options
Direction IN - flow is coming into one of the VMs or vNICs selected as part of the input seed.
OUT - flow is generated from one of the VMs or vNICs selected as part of the input seed.
INTRA- flow is between the VM or vNIC selected as part of the input seed.
Source VM Name, if the Source IP address of the flow record is resolved to one VM in the NSX inventory.
Raw IP if there is no VM found for this source IP address in the NSX Inventory. Note than multicast and broadcast
IPs will not be resolved to VMs.
Number of VMs if IP address is an overlapping IP address mapped to multiple VMs in different networks. The user
needs to resolve multiple VMs to one VM related to this flow record.
Flow tables can be edited and the flows consolidated for easier rule creation. For example, the source
field can be replaced with ANY. Multiple VMs receiving flows with HTTP and HTTPs can be replaced with
“WEB-Service” service group, which includes both HTTP and HTTPs service. By doing so, Multiple flows
may look similar and flow patterns may emerge that can be easily translated to a firewall rule.
Note that while each cell of the flow table can be modified, the cells are not auto-populated. For instance,
if the IP address196.1.1.1 is added to the DHCP-Server IPSet, the subsequent occurrences of that IP are
not auto-populated to show the DHCP-Server group. There is a prompt asking if you want to replace all
instances of the IP address with the IPSet. This allows the flexibility to make that IP part of multiple IPSet
groups.
Consolidated View
The consolidated view is accessed from the drop-down list in the right-hand corner. The consolidated
view eliminates duplicate flows and displays the minimal number of flows. This view can be used to create
firewall rules.
Clicking the arrow in the left hand corner of the Direction column shows the corresponding related raw
flow information:
n for intra flows the corresponding IN and OUT flows with raw data are shown
n the original source IP, destination IP, port, and protocol information in all of the raw flows that were
consolidated into the record
n for ALG flows, the corresponding data flow for the control flow is shown
After flow analysis, users can associate any undefined protocol/port combinations and create a service.
Service groups can be created for any of the services listed in the flows collected. For more information
on modifying flow records see Flow Consolidation and Customization.
Prerequisites
Flow data must have been collected from a set of vNICs and VMs. See Create a Monitoring Session.
Procedure
u After the flow state is Analysis Completed, the flow table is populated with data, in the Processed
View. To customize cell data, hover the cursor over a cell. A gear icon appears in the right-hand
corner of the cell. Click the gear icon in theService column and select one of the following options:
Option Description
Resolve Services If the port and protocol has been translated to multiple services, use this option to
select the correct service.
Create Services Group and Replace You can create a new service group with the service from the flow included in it.
Then, the new service group will replace the service. To add a service group:
a Enter a name for the service group.
b Optional - enter a description of the Service Group.
c Select the Object type.
d Select the available objects you want to be added to the Service Group and
click the arrow to move the object to the Selected Objects column.
e A new services group is created and populated in the Service column.
Replace Service with Any Replaces the specific service with any service.
Replace Service with Service Group If the selected service is a member of multiple service groups, you select the
specific service group you want to apply.
a Click the desired Service Group from the list of available objects.
b Click OK .
Revert Protocol and Port Reverts any cell modifications back to the original data.
The changed flow record has a pink bar on the side. When the curser is hovered over any cell which has
been modified there is a green checkmark. Clicking the checkmark displays a pop-up window with the
previous and new values for that cell. The modified flow record is easier to translate into firewall rules.
What to do next
After flows have been modified, they can be further grouped together to get the smallest distinct working
set. The Processed View is used to create Service Groups and IPSets and modify the flows. The
Consolidated view further compresses these modified flows to make it easier to create firewall rules.
After flow analysis is complete, flow cells can be customized by the user.
Prerequisites
Flow data must have been collected from a set of vNICs and VMs. See Create a Monitoring Session
Procedure
u After the flow state shows Analysis Completed, the flow table is populated with data. To customize
cell data, hover the cursor over a cell. A gear icon appears in the right-hand corner of the cell. Click
the gear icon in the Source or Destination column and select one of the following options:
Option Description
Resolve VMs This option is available if multiple VMs have the same IP address. This option is
used to chose the applicable VM name for the flow record.
Replace with any If the source should be accessible to everyone then any source IP address is the
correct option. In all other cases, you should specify the source address.
Configuring a destination value of any for the destination IP address is
discouraged.
Replace with Membership If the VM is part of Security Groups they will be displayed here and can replace
the VM name.
Option Description
Create Security Group a Enter a Name and (optional) description of the security group.
b Click Next.
c Define the criteria that an object must meet for it to be added to the security
group you are creating. This gives you the ability to include virtual machines
by defining a filter criteria with a number of parameters supported to match
the search criteria.
d Select one or more resources to add to the security group. Note that when
you add a resource to a security group, all associated resources are
automatically added. For example, when you select a virtual machine, the
associated vNIC is automatically added to the security group. You can include
the following objects in a security group:
Cluster
Logical Switch
vApp
Datacenter
e Click Next.
f Select the objects to exclude from the security group. The objects selected
here are always excluded from the security group, regardless of whether or
not they match the dynamic criteria.
g Click Next.
h Review the Security Group details on the Ready to complete window. Click
Finish.
Add to existing Security Group and For VMs, if the selected VM is a member of multiple security groups, select the
Replace specific security group you want to apply. This option is not available if the IP
address is present in the source or destination field. For raw IP addresses, use
Add to existing IPset and Replace option.
a Click the desired Service Group from the list of available objects.
b Click OK.
Create IPSet and Replace An IPset allows you to apply a firewall rule to an entire set of IP addresses at
once.
a Enter a name for the IPSet.
b Optional - enter a description.
c Enter IP addresses or range of address in the new IP set.
d Click OK.
Add to existing IPset and Replace An IP address may be part of several IPsets. Use this option to replace the shown
IP address and replace it with another.
a Select the desire IPset from the Available Objects.
b Click OK.
Revert to initial data Reverts any cell modifications back to the original data.
What to do next
Prerequisites
After the flow record has been analyzed you can create firewall rules.
Procedure
1 Open a flow session. If you are in the Processed View. Right-click on a single flow cell or shift + first
cell > last cell to select several cells, and then right-click. If you are in the Consolidated View select
a flow cell and click the Action icon. Select Create Firewall rule.
The New Firewall Rule pop-up window appears with all of the cells populated based on the selected
row data. If several cells were selected, all the source, destination, service objects are added to the
corresponding fields of the rule.
3 (Optional) To select a different source or destination click Select next to the Source or Destination
box. Specify a new source or destination from the available objects and click OK.
4 (Optional) To select a different service click Select the Service box. Distributed Firewall supports ALG
(Application Level Gateway) for the following protocols: FTP, CIFS, ORACLE TNS, MS-RPC, and
SUN-RPC. Edge supports ALG for FTP only. Specify a new service from the available objects and
click OK.
5 (Optional) To apply the rule to a different scope click Select next to the Applied To box. Make
appropriate selections as described in the table below and click OK. By default, the rule is applied to
the VNICs you originally right-clicked on.
All prepared clusters in your environment Select Apply this rule on all clusters on which Distributed
Firewall is enabled. After you click OK, the Applied To
column for this rule displays Distributed Firewall.
One or more cluster, datacenter, distributed virtual port group, 1 In Container type, select the appropriate object..
NSX Edge, network, virtual machine, vNIC, or logical switch 2 In the Available list, select one or more objects and click
If the rule contains virtual machines and vNICS in the source and destination fields, you must add
both the source and destination virtual machines and vNICS to Applied To for the rule to work
correctly.
Action Results in
Allow Allows traffic from or to the specified source(s), destination(s), and service(s).
Block Blocks traffic from or to the specified source(s), destination(s), and service(s).
7 Specify the rule Direction of the rule by clicking the drop-down arrow.
8 Click OK
What to do next
Publish the firewall rules. See Publishing and Managing Firewall Rules From Application Rule Manager.
After firewall rules have been created they can be managed in the Firewall Rules tab of the Application
Rule Manager.
Prerequisites
Procedure
u After you have created firewall rules from a flow monitoring session, they appear in the Firewall
Rules tab. Select one of the following options:
Option Description
Publish a Click Publish to publish the created firewall rules. The rules are published as
a new section.
b Enter a Section Name for the firewall rule
c Select where the new firewall section will be inserted in the existing firewall
configuration.
d Click OK.
Option Description
Down Arrow Select the down arrow icon to move the rule down
Note When firewall rules are published from Application Rule Manager, the section name is added
to the Publish button. Any subsequent publishing from the Application Rule Manager overrides the
existing section in the Firewall Configuration with the rules which are currently available in the
Application Rule Manager.
Note After data is gathered, it is purged daily at 2:00 a.m. During the data purge the number of flow
records across all sessions combined is checked, and any records above 20 million (or ~4GB) are
deleted. Deletion begins with the oldest session, and continues until the number of flow records in the
database is below 15 million records. If a session is in progress during the data purge, some records
could be lost.
Prerequisites
Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 2012, Windows 10, and Windows
2016. It is not supported on Linux.
n VMware Tools must be running and current on your Windows desktop VMs.
n Security Groups with 20 or fewer VMs are needed for data collection before Endpoint Monitoring can
begin. See Create a Security Group for more information.
n Data collection must be enabled for one or more virtual machines on a vCenter Server before running
an Endpoint Monitoring report. Before running a report, verify that the enabled virtual machines are
active, and are generating network traffic.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Tools > Endpoint Monitoring.
3 On the Start Data Collection for Security Groups pop-up window, select the security groups for which
you want to collect data. Click OK.
5 Click OK.
The main Endpoint Monitoring Screen appears. In the left hand corner the status is Collecting Data.
The EndPoint Monitoring screen appears with the Summary tab populated with data.
Endpoint Monitoring
Endpoint Monitoring enables visibility into specific application processes and their associated network
connections.
Summary Tab
After data collection is completed, the summary screen displays the details of the NSX manager, the
security group and the time slot of the collected data. The number of running virtual machines (VMs) and
the total number of processes generating traffic is shown in the first box. Clicking the number of virtual
machines running takes you to the VM Flows tab, described below. Clicking the number of processes
generating traffic takes you to the Process Flows tab, described below.
The second box displays a donut with the total number of flows. A flow is any unique stream of network
traffic as identified by its packet type, source and destination IP, and port. Hover the cursor over each
section and the number of flows within the security group or outside the security group is shown.
VM Flows Tab
This screen displays the details of the flows within the VMs including:
n Flows within security group - Traffic flowing between the VMs where the source or destination is
inside the monitored security group
n Flows outside security group - Traffic flowing between the VMs where the source or destination is
outside the monitored security group
n Shared service flows outside group - Shared service flows such as DHCP, LDAP, DNS, or NTP,
outside the monitored security group
n Shared service flows inside security group - Shared service such as DHCP, LDAP, DNS, or NTP,
inside the monitored security group
Clicking on a specific VM name in the table displays a bubble graph that shows the following:
Click on a bubble to view the details of the VM. The detailed flow view includes the process name,
version and number of flows being generated by each process. If it contains shared services there is a
special icon that is visible. Clicking on a line between two VM bubbles displays the process flow details of
the flows between those two VMs including:
n Source process - Name of application/exe generating traffic and initiating the flow
n Protocol - TCP
n Destination process - Name of the server application/exe of the process that is the destination of the
flow
This screen displays a list of all the applications that are generating flows. The table displays the
following:
n Process Name - The name of application generating traffic
n VM name
n Flows within security group - Traffic flowing between the VMs where the source or destination is
inside the monitored security group
n Flows outside security group - Traffic flowing between the VMs where the source or destination is
outside the monitored security group
n Shared flows within security group - Shared flows, within the monitored security group
n Shared flows outside security group - Shared flows, outside the monitored security group
The bubble graph depicts the flows that are occurring with the process or application on the selected VM
as the anchor. Click on any of the bubbles for the process name and version. Click on any line to display
the following:
n Source VM - The name of client VM that is hosting the client process
n Protocol - TCP
n Destination VM - The name of the server VM that is hosting the server process
Traceflow
Traceflow is a troubleshooting tool that provides the ability to inject a packet and observe where that
packet is seen as it passes through the physical and logical network. The observations allow you to
determine information about the network, such as identifying a node that is down or a firewall rule that is
preventing a packet from being received by its destination.
About Traceflow
Traceflow injects packets into a vSphere distributed switch (VDS) port and provides various observation
points along the packet’s path as it traverses physical and logical entities (such as ESXi hosts, logical
switches, and logical routers) in the overlay and underlay networks. This allows you to identify the path
(or paths) a packet takes to reach its destination or, conversely, where a packet is dropped along the way.
Each entity reports the packet handling on input and output, so you can determine whether issues occur
when receiving a packet or when forwarding the packet.
Keep in mind that traceflow is not the same as a ping request/response that goes from guest-VM stack to
guest-VM stack. What traceflow does is observe a marked packet as it traverses the overlay network.
Each packet is monitored as it crosses the overlay network until it reaches and is deliverable to the
destination guest VM. However, the injected traceflow packet is never actually delivered to the destination
guest VM. This means that a traceflow can be successful even when the guest VM is powered down.
n Layer 2 unicast
n Layer 3 unicast
n Layer 2 broadcast
n Layer 2 multicast
You can construct packets with custom header fields and packet sizes. The source for the traceflow is
always a virtual machine virtual NIC (vNIC). The destination endpoint can be any device in the NSX
overlay or in the underlay. However, you cannot select a destination that is north of an NSX edge services
gateway (ESG). The destination must be on the same subnet or must be reachable through NSX
distributed logical routers.
The traceflow operation is considered Layer 2 if the source and destination vNICs are in the same Layer
2 domain. In NSX, this means that they are on the same VXLAN network identifier (VNI or segment ID).
This happens, for example, when two VMs are attached to the same logical switch.
If NSX bridging is configured, unknown Layer 2 packets are always be sent to the bridge. Typically, the
bridge forwards these packets to a VLAN and reports the traceflow packet as delivered. A packet
reported as delivered does not necessarily mean that the trace packet was delivered to the specified
destination.
For Layer 3 traceflow unicast traffic, the two end points are on different logical switches and have different
VNIs, connected to a distributed logical router (DLR).
For multicast traffic, the source is a VM vNIC, and the destination is a multicast group address.
Traceflow observations may include observations of broadcasted traceflow packets. The ESXi host
broadcasts a traceflow packet if it does not know the destination host's MAC address. For broadcast
traffic, the source is a VM vNIC. The Layer 2 destination MAC address for broadcast traffic is
FF:FF:FF:FF:FF:FF. To create a valid packet for firewall inspection, the broadcast traceflow operation
requires a subnet prefix length. The subnet mask enables NSX to calculate an IP network address for the
packet.
Caution Depending on the number of logical ports in your deployment, multicast and broadcast
traceflow operations might generate high traffic volume.
There are two ways to use traceflow: through the API and through the GUI. The API is the same API that
the GUI uses, except the API allows you to specify the exact settings within the packet, while the GUI has
more limited settings.
n TCP and UDP source and destination port numbers. The default values are 0.
n TCP flags.
n An expiry timeout, in milliseconds (ms), for the traceflow operation. The default is 10,000 ms.
n Ethernet frame size. The default is 128 bytes per frame. The maximum frame size is 1000 bytes per
frame.
n Payload value.
n Troubleshooting network failures to see the exact path that traffic takes
Prerequisites
n Traceflow operations require communication among vCenter, NSX Manager, the NSX Controller
cluster and the netcpa user world agents on the hosts.
n For Traceflow to work as expected, make sure that the controller cluster is connected and in healthy
state.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Tools > Traceflow.
If the VM is managed in the same vCenter Server where you are running the traceflow, you can select
the VM and vNIC from a list.
The destination can be a vNIC of any device in the NSX overlay or underlay, such as a host, a VM, a
logical router, or an edge services gateway. If the destination is a VM that is running VMware Tools
and is managed in the same vCenter Server from which you are running the traceflow, you can select
the VM and vNIC from a list.
Otherwise, you must enter the destination IP address (and the MAC address for a unicast Layer 2
traceflow). You can gather this information from the device itself in the device console or in an SSH
session. For example, if it is a Linux VM, you can get its IP and MAC address by running the
ifconfig command in the Linux terminal. For a logical router or edge services gateway, you can
gather the information from the show interface CLI command.
The packet is switched based on MAC address only. The destination MAC address is
FF:FF:FF:FF:FF:FF.
Both the source and destination IP addresses are required to make the IP packet valid for firewall
inspection.
Both the source and destination IP addresses are required to make the IP packet valid. In the case of
multicast, the MAC address is deduced from the IP address.
8 Click Trace.
Example: Scenarios
The following example shows a Layer 2 traceflow involving two VMs that are running on a single ESXi
host. The two VMs are connected to a single logical switch.
The following example shows a Layer 2 traceflow involving two VMs that are running on two different
ESXi hosts. The two VMs are connected to a single logical switch.
The following example shows a Layer 3 traceflow. The two VMs are connected to two different logical
switches that are separated by a logical router.
The following example shows a broadcast traceflow in a deployment that has three VMs connected to a
single logical switch. Two of the VMs are on one host (esx-01a), and the third is on another host
(esx-02a). The broadcast is sent from one of the VMs on host 192.168.210.53.
The following example shows what happens when multicast traffic is sent in a deployment that has
multicast configured.
The following example shows what happens when a traceflow is dropped because of a distributed firewall
rule that blocks ICMP traffic sent to the destination address. Notice that the traffic never leaves the
original host, even though the destination VM is on another host.
The following example shows what happens when a traceflow destination is on the other side of an edge
services gateway, such as an IP address on the Internet or any internal destination that must be routed
through the edge services gateway. The traceflow is not allowed, by design, because traceflow is
supported for destinations that are either on the same subnet or are reachable through distributed logical
routers (DLRs).
The following example shows what happens when the traceflow destination is a VM that is on another
subnet and is powered off.
Packet Capture
You can create a packet capture session for required hosts on the NSX Manager using the Packet
Capture tool. After the packets are captured, the file is available to download. If your dashboard is
indicating that a host is not in a healthy state, you can capture packets for that particular host for further
troubleshooting.
Maximum of 16 sessions and total of 400 MB files are available to download. Sessions remain active for
10 minutes or until the capture file reaches either 20 MB or 20,000 packets, whichever limit is reached
first. When the limit is reached, the new capture session cannot be created, but you can download the
previously captured files. If you want to start a new session after reaching maximum session, you must
clean the older sessions. Your session remains active for 10 minutes, and the existing session is removed
one hour after the session was created. If you restart NSX, all the existing sessions are cleared.
Options Description
NSX Manager Select the NSX Manager for which you want to create a packet
capture session.
CREATE SESSION To start a new packet capture session, click CREATE SESSION.
For details, see Create a Packet Capture Session.
CLEAR ALL If you want to clear all sessions, then click CLEAR ALL. A
confirmation dialog box appears. Click YES to clear all the listed
sessions.
DOWNLOAD Select the required session, and click DOWNLOAD. You can
also click the download icon. A confirmation dialog box appears.
Click YES to download the captured session.
You can view the number of active sessions and total file size. The session status can be as follows:
n Finished: After the session is finished, you can download the session. You can also restart, and clear
the session.
n Stopped: The session that was forced stopped. You can restart, or clear the session.
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Tools > Packet Capture.
The Create Session window appears. Enter the required details as explained further.
Parameter Description
General Tab The General tab is the default tab. Enter the required details
as explained further.
Filter Type Select the filter type from the list that is based on the selected
host. The list depends on the configured firewall rules.
Advanced Tab To provide additional options to filter the capture packet, click
the Advanced tab, and type the required details.
What to do next
n You can download the captured session after it is finished, and can view the file using tools such as
Wireshark.
n You can clear the session after you download the file.
You can also use API to generate, download, delete, or cancel the bundle collection.
If the size limit in NSX is reached before all the requested logs are generated, the operation skips
generation of remaining logs. The bundle gets generated with partial logs and is made available for the
local download or FTP upload. The status of logs that are skipped is displayed.
When you request new log collection request, the old bundle gets deleted. The bundle also gets deleted
after it has been uploaded to a remote server or the generate logs operation is canceled.
n VM Guest logs
Prerequisites
Procedure
1 In the vSphere Web Client, navigate to Networking & Security > Tools > Support Bundle.
a To include NSX Manager logs, select the Include NSX Manager logs check box.
b Select the required object type from the list. You can select Hosts, Edges, and Controllers.
c Based on the selected object type, the available components are listed under the Available
Objects column.
n Select the check box next to the component that you want to include in the logs, and then
click the arrow key ( ) to move the component to the Selected Objects list.
n To remove the selected objects, select the check box next to the component that you want to
remove, and then click the arrow key ( ) to move the component to the Available Objects
list.
d For Hosts, you can select additional log options as Guest Introspection and Firewall.
4 Set the default timeout (in minutes) for the bundle collection process per selected object from the list.
Note You can either download the support bundle, or upload it to a remote server. If you do not want
to upload the bundle to a remote server, the bundle will be available for download after it is
generated.
a Select the Upload support bundle to remote file server check box.
n Username and Password: Enter the user name and password of the remote server.
n Port: Port number is added by default. You can change the port number, if necessary. To
increase or decrease the number, click the arrow key.
To view the bundle details, click the View Bundle Details link.
You can view overall completion status (in percent) and status for each component. You can view the
completion status of bundle (in percent) being uploaded to a remote server. The status can be as follows:
n Skipped: This status can appear due to limited disk space. The bundle gets generated with partial
logs and is made available for a local download, or is uploaded to a remote server. The status of the
logs that are skipped is displayed.
n Failed: Log collection is failed due to various reasons like connectivity issues or timeout error. Click
START NEW to start the data collection again.
n Completed: You can now download the bundle or view at the remote server.
What to do next
n You can Download a Support Bundle after it is generated, or you can view the filename that is
uploaded to the configured remote server.
n Click START NEW to start the data collection again. A confirmation box appears. Click Yes to start
new data generation request.
Prerequisites
Procedure
2 Click DOWNLOAD.
3 The support bundle filename ending with tar.gz is downloaded to your default Downloads folder.
Some browsers might alter the file extension.
For example, the name of the support bundle file has a format similar to VMware-NSX-TechSupport-
Bundle-YYYY-MM-DD_HH-MM-SS.tar.gz.
5 Click Yes. The log files generated in this particular request get deleted.
What to do next
You can provide the downloaded support bundle to VMware technical support.
Prerequisites
Procedure
2 If the log generation is in-progress, you can cancel the process. Click ABORT GENERATION.
5 Click Yes. The log files generated in this particular request get deleted.
What to do next
Click START NEW to start data collection again. A confirmation box appears. Click Yes to start a new
data generation request.