NSX Components

Starting a series of posts for beginners , who wants to understand what is NSX and What it does , how it can help you and your organisations to enhance networking and security inside the datacenters.

Here is the list of Components which are required to prepare NSX Infrastructure:

  • vSphere ESX Agent Manager (EAM)
  • NSX Manager
  • Controller cluster (if using unicast, hybrid mode or distributed logical routing)
  • VTEP (ESXi hypervisor)
  • User world agents (UWA)
  •  vSphere distributed switch


I will explain each of the Components using series of Posts…..


Finding IDs of vCenter Object

When you use NSX API , there are many places inside the API we need to provide Object Ids. here is the procedure by which we can get vCenter Object IDs.

We can Use the vCenter MOB (Managed Object) viewer to find the object IDs. Browse to https://<vcenter>/mob and log in with an account that has administrative privileges within vSphere.

From there, click on Content > the rootFolder value link > the childEntity value link > any object you need an ID for. below is what mine looks like….


Happy Learning 🙂

Restrict User Access using NSX Load Balancer Application Rules without using Firewall

Use Case: I have a single data center with two departments on different subnets accessing their respective VDI pools sitting behind a NSX Load Balancer. suppose HR users are having a URL – hr.vdi.com and sales users are having sales.vdi.com hitting to a single NSX LB configured with a VIP and connection manager pool.

Think a scenario where HR users comes to Sales block and try to access its VDI using hr.vdi.com from sales subnet , as per security guidelines this should not be allowed.

Now think another scenario where HR user comes to sales block and try to access its VDI using sales.vdi.com from sales subnet, as per the security guidelines this should not be allowed.

Another requirement is that no user from any other subnet should be able to access any of the VDI URLs and customer does not wants to use firewall for internal traffic. So in short we have to do a subnet to URL mapping on NSX Edge Load Balancer.

To achieve this, we will be using NSX edge LB “Application Rules”. Application Rules – we can write an application rule to directly manipulate and manage IP application traffic.

The procedure is as below….

1 Log in to the vSphere Web Client.
2 Click Networking & Security and then click NSX Edges.
3 Double-click an NSX Edge.
4 Click Manage and then click the Load Balancer tab.
5 In the left navigation panel, click Application Rules and click the Add icon.
6 Type the name and script for the rule.

So we have created a NSX edge Load Balancer with Connection Broker VIP and a Pool of Connection servers.

Now to restrict access , the procedure is as below:

Go to NSX edge and click on Load Balancer and go to Virtual Servers and set Deafult Pool – NONE


This will insure that if any user try to access connection broker will get an error because there is no Pool is defined. ( So no User will be able to access any of the services ,default action)

Now we will write Application Rules to allow access.


#ACL for subnet –> acl host_subnet src   – We are allowing to this subnet

#ACL for URL ->  acl host_url hdr(Host) –i abc.xyz.com – We are allowing abc.xyz.com

So if the user is from subnet and using the URL abc.xyz.com than only it should be allowed to access Pool  , which are hosting Horizon view Connection Broker services.

Rule will be like this – Use_backend CB_Pool if host_subnet host_url

If you see after “if “ there are two acl names and there is nothing between them it means these will be treated as “AND” condition (Default HAProxy setting) , so it has to be verify both the acl and if ok then it will allow user access.

I hope this will be  useful in planing security at Load Balancer label where Firewall is not feasible.

Some other examples of Application Rules :

# Block URL

Check if the request starts with “/private” or “/finance” (case insensitive)
acl block_url_list path_beg -i /private /finance
# If the request is part of the list of forbidden url, reply “Forbidden” (HTTP response code 403)
block if block_url_list

# Redirect EVERYTHING to maintenance site
redirect location http://maintenance.xyz.com/maintenance.htm


Automation Leveraging NSX REST API

A new Automation Guide has been published by VMware to help customers to Automate the Virtual Networking using NSX APIs.

VMware NSX provides a RESTful API service via NSX Manager that can be consumed in several ways. The NSX REST API can be consumed directly via a tool/library such as cURL or a REST Client like Postman, via multiple popular programming languages, and via orchestration cloud management tools. Popular programming languages such as Python, PowerShell, Perl, Go, and Java have REST client libraries which can easily be utilized to consume the NSX REST API. This means that elaborate workflows and complete systems/portals can be created to provide custom automation, management, and monitoring capabilities.

For More details and download the guide on API Guide


VMware NSX Firewalling using AD Groups

This particular use-case is to implement network security to allow or block network access to certain applications/servers in the datacenter, depending on the logged-on user in a horizon view environment.

This we will achieve using a feature of VMware NSX that is Identity based firewalling.

Let’s first connect NSX to Active Directory. This step can be completed on the NSX Manager under manage -> domains. Add the domain you want to use to NSX:







Once AD sync is completed. now , we need to chose an AD group inside NSX “Grouping Object”.

  1. Go to Grouping Objects
  2. Click on + sign, a New Window will open, provide a proper Name.
  3. Click on + sign
  4. Choose “Entity” from drop down.
  5. Click on the next box , it will open a list of AD groups.
  6. Choose your AD group



Go to IP Sets and lets create an IP set , these will contain the list of IPs which we don’t want users to access.

  1. Click on + Sign.
  2. Enter descriptive Name.
  3. Enter IP address to block.
  4. Click OK.



Now Lets’ go to Firewall and create a Rule.

  • Click in Firewall
  • Click on + Sign.
  • Give a descriptive Name.
  • Chose Group , that we have created in Grouping Object , in our case it is “Demo”.
  • Choose IP Set , that we have created in IP set , in our case “no_access_server”.
  • Chose “Block” as we would need to block the traffic.


I hope this should be useful and helpful. Please Review and comment.

Add a Static Route to DLR

In my last post i have created a DLR using API , now as per requirement we have to add a default route on DLR.

Request Type : PUT


Request Body:



Deploy Distributed Logical Router using NSX API

I am working on a NSX Design and Deployment engagement, this includes deployment of NSX on many sites and all sites spread across many cities of India and working on web client from the central location was very slow due to bandwidth issues. so we decided to deploy all the NSX components using NSX API.this will also help in keeping this code as a backup handy , so can be executed in case of restore required.

In my first post i have shown how to create Logical Switch , Now lets create a Distributed Logical Router….

Since we are using static Routing and there is no Firewall requirement  , so we have decided to not to deploy DLR edge VM at this point of time.

Request Type :POST   https://<NSX-MGR-IP>/api/4.0/edges

Request Body:



Distributed Logical Router successfully created.

Note – At the time of Writing with NSX 6.2.2,The example given in the API doc in the DLR section is actually for an ESG. the use of “vnic” for DLR does not work. we must use <interface> </interface>.

NSX Edge Backup and Restore


Apart from NSX Manager backup and restore procedure , I was looking for a procedure to backup and restore NSX edge appliances.Here is the API way to do this…. (this may not be supported by VMware)

Backup NSX Edge Configuration-

To get edge configuration of a specified edge using REST API, use the following rest API call.

Request type: GET https://<nsxmgr-ip>/api/4.0/edges/<Edge-id>


Save the response body (output) as backed up configuration in a file.

Note : Backup the edge certificates , passkeys and passphrase outside of NSX as the edge certificates are not exported  as  part of the REST call.

How to Restore Edge Configuration-

To deploy a new edge using backed up configuration in the above step, use the following rest API call with the saved backed up configuration inside the API call body.

Before pasting the backup in the request body make the following changes……

Remove the section <id><edge-id></id>


Add a new section <password>your 12 digit password </password> inside <cliSettings></cliSettings>




you must remove the section <clientSsl></clientSsl> in the Application Profiles inside Load-Balancer if exists.


Now go to your API client and

Request type: POST   and URL – https://<nsxmgr-ip>/api/4.0/edges/
where body is the backed up configuration with the above modifications.


if above goes well , it will deploy edge with existing configuration and response will be like this.


then user will have to go to the NSX UI and self sign the certificate or import the certificate. If the certificate was associated to an application profile, the user will have to do the same via UI.


Assigning User Permissions(RBAC)-NSX

In this post, we will get into the NSX  Permission (Role Based Access control) configuration.

Let’s go to NSX console from vSphere Client and from there Go to “Manage” -> “Users” -> Click on the green Plus button:


Here we can select if we want to map specific A/D user to NSX Role or A/D Group to Role.


Format to use is as – > “group_name”@domain.name. or. “user_name”@domain.name.

Let’s start with a sample user “dave”, which should have been already created in our Active Directory, this user “dave” is required “Enterprise Administrator” permission, as he is going to manage our entire NSX environment. same way we can assign permission to other users with different permission needs.


Select one of the NSX Role, for “dave” user we chose “Enterprise Administrator”


Let’s Try our first login with user “dave”:


 The login successful but there is no “Network & Security” tab , as user got the permission on the NSX but not on the vCenter.


So far we configure all NSX Manager part but we didnt take care of the vCenter Configuration permission for that user.

Let’s configure vCenter permission, so that user can view Network & Security Tab:

vCenter has its own Role for each group. We need to configure roles to etch A/D group/users to whom we want to assign permission. These settings determine what the user can create/access the in vCenter environment.

Configure vCenter Roles:

Let’s start by configure the Role for “dave”. We know this user is for “Enterprise Administrator” in the NSX Manager, so it will make sense to give this user “Network Administrator” to all other vCenter environment, so that he can manage network related components of vSphere also.

Go to vCenter -> Manage -> Permissions and click the green button:


For our case choose “Network Administrator” is the Minimum.

Select “Network Administrator” from the Assigned Role drop down list and click on the “Add” button from “User and Group”:


From the Domain Select your Domain name, in our lab the domain is “CORP”, choose your Active Directory user from the list (dave for this example) and click the “Add” button:


Click Ok and Ok for Next Step:



Now we can try to login with “Dave” user: now Networking & Security is visible.




Create Logical Switch using NSX API

Request Type : POST


Request Body:

<description>For ABC ODC</description>