Learning NSX Step by Step : Configuring SSL VPN-Plus on VMware NSX Edge Gateway

VMware NSX SSL VPN-Plus allows remote users to access private networks behind a NSX Edge Gateway. You can access applications and servers running in the private network. Below is a diagram is taken from the NSX Admin Guide of the clients connect to the private network and also the support operating systems for the SSL VPN client:


To configure network access SSL VPN-Plus. Login to vCenter Web Client and go to “Network and Security”

Click on NSX Edge. Double click on Edge Gateway Services account

Click on SSL VPN-Plus Tab.

Create an IP Pool for the client connecting via VPN.

Add the Private Network you want to allow user connecting over VPN.

Select the Authentication Server Type.

Start the SSL VPN Service

Open the browser and browse external IP address over https. https://<External_IP_Address_of_ESG>


Verify the communication from VPN Client to internal network.


This concludes the configuration of SSL VPN-Plus on a VMware NSX Edge Gateway Services router. Hope this will be informative for you. Please share if you find worth sharing it. Thanks for Reading!!!

Learning NSX Step by Step – Configuring NSX SpoofGuard Policy


Spoofing also referred to as ARP Spoofing is a practice attacker use to penetrate networks. They spoof legitimate traffic on a network so that it appears to be coming from the trusted source on the network.

VMware NSX SpoofGuard keeps track of the ARP addresses to IP addresses and if there is any change in them.  Leveraging VMware NSX SpoofGuard, VMware NSX can block the system automatically if there is an unexpected change of IP address to ARP address.

You can configure SpoofGuard either  in Automatic or Manual mode:

  • Automatically trust IP assignments on their first use  – Configuring this mode will automatically trust the first IP address reported to the NSX Manager. This mode is not recommended to be configured in a DHCP environment as IP addresses are dynamic and will change dynamically.
  • Manually inspect and approve all IP assignment before use – Configuring this mode will prevent all traffic by default will present the set of IP addresses discovered for approval by users.

Configuring SpoofGuard Policy

Login to vSphere Web Client and click on “Network and Security”

Click on SpoofGuard

Choose the appropriate mode, Automatically or Manual

Select the appropriate “Object Type”

As we configured mode as Manual select the VM and approve the IP Address

Click on App IP to add the additional IP Address.

Click on “Clear Approved IP” if you want to clear the approved IP Addresses.


This concludes the configuration of SpoofGuard policy in VMware NSX environment. SpoofGuard policy provides an automated way to get virtual machine blocked in case of any spoof. Hope this would be informative for you. Do share if you find this worth sharing it. Thanks for Reading!!!


Learning NSX Step by Step – Configuring DNS Server on Edge Router


You can configure a VMware NSX edge to relay name resolution requests from clients to external DNS servers. Once configured VMware NSX Edge Services Gateway (ESG)  will forward name resolution request from clients to an external DNS Server. An ESG will relay client application requests to the DNS servers to fully resolve a network name and cache the response from the servers

In this blog, I will show you how to configure the DNS servers on the NSX edge.

Log in to the vSphere Web Client. Click Networking & Security 

Click NSX EdgesDouble-click on NSX Edge.

Click on Configuration –> DNS Configuration

Click Enable DNS Service to enable the DNS service. Type the IP Address of External DNS Server. Configure “Cache Size” and “Enable Logging” in case required

Post configuration NSX edge will relay the name resolution requests for any VM’s traffic that flow through it, to the configured external DNS servers.


This concludes the configuration of an external DNS server on Vmware NSX Edge Gateway Servies Router. Hope this will be informative for you. Please share if you find worth sharing it. Thanks for Reading!!!.



Learning NSX Step by Step – Configuring DHCP Services in VMware NSX


One of the services that the NSX Edge provides is IP address pooling and one-to-one static IP address allocation and external DNS services. NSX Edge listens to the internal interface for DHCP requests and uses the internal interface IP as the default gateway for clients.

In VMware NSX Edge DHCP service comply to the following guidelines:

  • Listens on the NSX Edge internal interface for DHCP discovery.
  • Uses the IP address of the internal interface on NSX Edge as the default gateway address for all clients and the broadcast and subnet mask values of the internal interface for the container network.

Lab Environment


In this post, I’ll show you how to configure

    • DHCP on the NSX Edge to provide IP addresses to clients on a logical switch.
    • DHCP on the NSX EDGE to provide IP Address to the clients connected to Distributed Logical Router(DLR) and DLR configured as DHCP Relay Server.


This concludes the demonstration of configuring DHCP Services on VMware NSX Edge Router. Hope this will be informative for you. Please do share if you find worth sharing it. Thanks for Reading!!!



Learning NSX Step by Step – Configuring Dynamic Routing using OSPF in VMware NSX


Dynamic Routing provides the necessary forwarding information between Layer 2 broadcast domains.  There are 3 types of Dynamic Routing supported by VMware NSX OSPF, BGP, and IS-IS. NSX Edge supports OSPF, an interior gateway protocol that routes IP packets only within a single routing domain. It gathers link state information from available routers and constructs a topology map of the network. 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. An area is a logical collection of OSPF networks, routers, and links that have the same area identification. Areas are identified by an Area ID.



VMware NSX Step by Step – Creating Logical Switch


Logical Switches are no more different than the physical switches in the network. Similar to physical switches, It allows you to create a broadcast domain and isolate the Virtual Machines in the network. Once you create a logical switch is new distributed port group gets added on a distributed switch. The reason why we say it logical because a unique VNI (VXLAN Network Identifier) get associated to it to overlays the L2 network. Logical switching enables the extension of an L2 segment / IP subnet anywhere in the fabric independent of the physical network design. Endpoints, either virtual and physical, can connect to logical segments and establish connectivity independently from their physical location in the data center network.

The NSX Controller cluster controls logical switches and maintains information about virtual machines, ESXi hosts, logical switches, and VXLANs. All logical switches created within the transport zone inherit VMware NSX transport zone settings.

Logical Switch – Key Points

  • Logical Switch in an NSX Environment is a virtual network segment which is a distributed port group tagged with a unique VNI on a distributed switch.
  • Logical Switch can span distributed switch by associating with a port group in each distributed switch.
  • All hosts that are part of the same vDS supports VMotion.
  • A distributed port group is automatically created on all the VTEPs (ESXi hosts) that are part of the same underlying Transport Zone once you add a Logical Switch
  • A Virtual Machine vNIC then connects to each Logic Switch as appropriate.



This concludes the demonstration of creating a logical switch and connecting virtual machines vNIC’s to it. Hope this will be informative for you. Please do share if you find worth sharing it. Thanks for Reading !!!.

VMware NSX Step by Step – Creating Segment ID & Transport Zone

In the Previous post, We have discussed configuring VXLAN on ESXi hosts. In this post, We will discuss creating Segment Id and transport Zones. You must create a pool of segment ID in an NSX Environment to isolate your network traffic.

Introduction to Segment ID

Segment ID in an NSX environment determines the maximum number of logical switches that can be created in your infrastructure. Segments ID’s will be used by logical segments for VXLAN Network Identifiers (VNI). A segment ID is like a VLAN ID but for a VXLAN. A VLAN ID can only range from 1 to 4094 but Segment ID can range between 1 to 16,777,215. VMware has decided to use Segment ID starting from 5000 to avoid confusion between VLAN ID & Segment ID.

Starting with the NSX 6.2, segment ID range planning is required in order to enable cross-VC connectivity. It is recommended to keep the segment ID unique for each NSX domain to leverage cross-VC capabilities in NSX 6.2 release; this will help avoid the requirement of the renumbering of segment IDs.


Transport Zone

A VMware NSX Transport Zone defines the boundary of which VMware NSX  Logical switch (VXLAN’s) can be extended across. The ESXi hosts part of a Transport Zone communicate with each other over a VXLAN Tunnel Endpoint (VTEP) connection. In an NSX Environment, we can have one or more transport zone depending on our requirements. A single host cluster can belong to multiple transport zone and a Single Transport zone can span multiple vSphere Clusters. Basically, Transport Zone dictates which cluster and therefore which VM’s can participate in a particular network.



This video demonstrates the steps to create a New Transport Zone & Defining pool of Segment ID’s in an NSX environment. Hope this will be informative for you. Please share if you find worth sharing it. Thanks for Reading !!!

What’s New in NSX for vSphere 6.2.3

VMware NSX delivers an operational model for networking that forms the foundation of the Software-Defined Data Center. VMware NSX provides a complete set of logical networking elements and services—including logical switching, routing, firewalling, load balancing, VPN, quality of service (QoS), and monitoring. RecentlyVMware released a new version of VMware NSX (6.2.3)  Build 3979471.

New in 6.2.3

Changes introduced in NSX vSphere 6.2.3:

  • Logical Switching and Routing
    • NSX Hardware Layer 2 Gateway Integration: expands physical connectivity options by integrating 3rd-party hardware gateway switches into the NSX logical network
    • New VXLAN Port 4789 in NSX 6.2.3 and later: Before version 6.2.3, the default VXLAN UDP port number was 8472. See the NSX Upgrade Guide for details.
  • Networking and Edge Services
    • New Edge DHCP Options: DHCP Option 121 supports static route option, which is used for DHCP server to publish static routes to DHCP client; DHCP Options 66, 67, 150 supports DHCP options for PXE Boot; and DHCP Option 26 supports configuration of DHCP client network interface MTU by DHCP server.
    • Increase in DHCP Pool, static binding limits: The following are the new limit numbers for various form factors: Compact: 2048; Large: 4096; Quad large: 4096; and X-large: 8192.
    • Edge Firewall adds SYN flood protection: Avoid service disruptions by enabling SYN flood protection for transit traffic. Feature is disabled by default, use the NSX REST API to enable it.
    • NSX Edge — On Demand Failover: Enables users to initiate on-demand failover when needed.
    • NSX Edge — Resource Reservation: Reserves CPU/Memory for NSX Edge during creation. Admin user can modify the CPU/Memory settings after NSX Edge deployment using REST API to configure VM appliances.
    • Change in NSX Edge Upgrade Behavior: Replacement NSX Edge VMs are deployed before upgrade or redeploy. The host must have sufficient resources for four NSX Edge VMs during the upgrade or redeploy of an Edge HA pair. Default value for TCP connection timeout is changed to 21600 seconds from the previous value of 3600 seconds.
    • Cross VC NSX — Universal Distributed Logical Router (DLR) Upgrade: Auto upgrade of Universal DLR on secondary NSX Manager, once upgraded on primary NSX Manager
    • Flexible SNAT / DNAT rule creation: vnicId no longer needed as an input parameter; removed requirement that the DNAT address must be the address of an NSX Edge VNIC.
    • NSX Edge VM (ESG, DLR) now shows both Live Location and Desired Location. NSX Manager and NSX APIs including GET api/4.0/edges//appliances now return configuredResourcePool and configuredDataStore in addition to current location.
  • Security Services
    • Distributed Firewall — TFTP ALG: enables use cases such as network boot for VMs.
    • Firewall — Granular Rule Filtering: simplifies troubleshooting by providing granular rule filters in UI, based on Source, Destination, Action, Enabled/Disabled, Logging, Name, Comments, Rule ID, Tag, Service, Protocol.
    • Guest Introspection — Windows 10 support
    • SSL VPN Client — Mac OS El Capitan support
    • Service Composer — Performance Improvements: enables faster startup/reboot of NSX Manager by optimizing synchronization between security policy and firewall service, and disabling auto-save of firewall drafts by default.
    • Service Composer — Status Alarms: raises system alarm if security policy is out-of-sync, and takes specific actions based on alarm code to resolve issue.
  • Operations and Troubleshooting
    • NSX Dashboard: Simplifies troubleshooting by providing visibility into the overall health of NSX components in one central view.
    • Traceflow Enhancement — Network Introspection Services: Enhances ability to trace a packet from source to destination, by identifying whether packets were forwarded to 3rd-party network introspection services, and whether the packet comes back from the 3rd-party service VM or not.
    • SNMP Support: Configure SNMP traps for events from NSX Manager, NSX Controller, and Edge.
    • Logging is now enabled by default for SSL VPN and L2 VPN. The default log level is notice.
    • Firewall rules UI now displays configured IP protocols and TCP/UDP port numbers associated with services.
    • NSX Edge technical support logs have been enhanced to report memory consumption per process.
    • Central CLI Enhancements
      • Central CLI for Host Health: Shows host health status, with 30+ checks in one command (including network config, VXLAN config, resource utilization, etc.)
      • Central CLI for Packet Capture: Provides ability to capture packet on the host and transfer the capture file to user’s remote server. This eliminates the need to open up hypervisor access to network administrators, when troubleshooting logical network issues.
    • Technical support bundle per host: Gathers per-host logs and creates a bundle that can be saved and submitted to VMware technical support for assistance.
  • Licensing Enhancements
    • Change in default license & evaluation key distribution: default license upon install is “NSX for vShield Endpoint”, which enables use of NSX for deploying and managing vShield Endpoint for anti-virus offload capability only. Evaluation license keys can be requested through VMware sales.
    • License usage reporting: NSX license usage counts are displayed on NSX Manager’s Summary UI and also retrievable via API. NSX license usage counts will no longer be reported through vCenter licensing service.
  • Solution Interoperability
    • Customer Experience Improvement Program: NSX supports reporting system statistics via the VMware Customer Experience Improvement Program (CEIP). Participation is optional and is configured in the vSphere Web Client.
    • VMware vRealize Log Insight 3.3.2 for NSX provides intelligent log analytics for NSX, with monitoring and troubleshooting capabilities and customizable dashboards for network virtualization, flow analysis and alerts. This version accepts NSX Standard/Advanced/Enterprise edition license keys issued for NSX 6.2.2+.

Reference : NSX for vSphere 6.2.3 Release Notes

Creating SpoofGuard Policy in VMware NSX

NSX Manager collects the IP addresses of all vCenter guest virtual machines from VMware Tools on each virtual machine after Initial Synchronization with vCenter Server. In case  virtual machine gets compromised, the IP address can be spoofed and malicious transmissions can bypass firewall policies.

VMware NSX includes Spoofguard which allows administrator to authorize IP addresses reported by VMware tools running inside a virtual machine. Administrator can create SpoofGuard policies for specific networks that allows you to authorize the IP addresses to prevent spoofing.You can use SpoofGuard to block traffic determined to be spoofed. SpoofGuard supports both IPv4 and IPv6 addresses. The SpoofGuard policy supports a single IP address assigned to a vNIC when IPv4 and support multiple IP Address when using IPv6.

By default Spoofguard is disabled, you can configure Spoofguard using NSX plugin in the vSphere Web Client.


The SpoofGuard policy monitors and manages the IP addresses reported by your virtual machines in one of the following modes.

  • Automatically Trust IP Assignments On Their First Use : This mode allows all traffic from your virtual machines to pass while building a table of vNIC-to-IP address assignments. All the assignments are initially marked as trusted and can be reviewed in case needed at later stage.
  • Manually Inspect and Approve All IP Assignments Before Use : If you select this mode, this mode blocks all traffic until you approve each vNIC-to-IP address assignment.

Click on Green ” + ” Sign to create an new SpoofGuard Policy.


Choose the Network to apply SpoofGuard Policy.



Click OK


Once you choose the network. You will see the list of virtual machines with detected IP Addresses. Click on Approve to approve the IP Address.


Publish the changes.



Perform Ping test to verify the communication.


This concludes the process of creating SpoofGurad Policy to prevent spoofing. I hope this is informative for you. Thanks for reading !!!. Be social and share it in social media, if you feel worth sharing it.



VMware NSX 6.2 – Communication Channel Health Check

In NSX 6.2.0 VMware adds the ability to create communication channel health. The channel health status between

  • NSX Manager and the firewall agent: A heartbeat is sent every 3 minutes, if two iterations are lost a sync will occur.
  • NSX Manager and the control plane agent: A heartbeat is sent every 2 minutes, if two iterations are lost a sync will occur.
  • Host and the NSX Controller: Heartbeats are sent every 30 seconds, if three iterations are lost a sync will occur.

The channel health status can be seen from the NSX Manager UI. In addition, this feature detects when configuration messages from the NSX Manager have been lost before being applied to a host, and it instructs the host to reload its NSX configuration when such message failures occur.

The following diagram shows the communication channels involved in the communication:


All the host / cluster that have been prepared for NSX runs VSFWD (Firewall Agent) & NETCPA (Network Control Plane agent). To verify the Communication Channel Health log into the vSphere Web Client and navigate to Networking & Security plugin -> Installation –> Host Preparation. Select the Cluster/Individual host and click on  Actions and then Communications Channel Health.




In case hosts looses the connectivity with NSX controllers then you will see the Control Plane Agent to Controller being down.


ESXi Host uses the NETCPA agent to communicate with the controllers, If there are issues with the NETCPA or VSFWD (firewall) agent then you will see an unknown error.



You can change the default interval that the host will send heartbeats by editing netcpa.xml located at following location on ESX Host.


This concludes how we can leverage channel health to verify if communication is working properly between different components. I hope this is informative for you. Thanks for reading !!!. Be social and share it in social media, if you feel worth sharing it.