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…..

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 🙂

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….

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

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.

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

https://<NSX-MGR-IP>/api/4.0/edges/edge-35/routing/config/static

Request Body:
<staticRouting>
<staticRoutes>
<route>
<description>route2</description>
<vnic>2</vnic>
<network>0.0.0.0/0</network>
<nextHop>192.168.10.2</nextHop>
<mtu>1500</mtu>
<type>user</type>
</route>
</staticRoutes>
</staticRouting>

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:

<edge>
<datacenterMoid>datacenter-21</datacenterMoid>
<name>ODC-A1</name>
<type>distributedRouter</type>
<appliances>
<deployAppliances>false</deployAppliances>
</appliances>
<mgmtInterface>
<connectedToId>dvportgroup-50</connectedToId>
</mgmtInterface>
<interfaces>
<interface>
<name>Towards_Transit</name>
<addressGroups>
<addressGroup>
<primaryAddress>192.168.10.1</primaryAddress>
<subnetMask>255.255.255.0</subnetMask>
<subnetPrefixLength>24</subnetPrefixLength>
</addressGroup>
</addressGroups>
<mtu>1500</mtu>
<type>uplink</type>
<isConnected>true</isConnected>
<isSharedNetwork>false</isSharedNetwork>
<connectedToId>virtualwire-16</connectedToId>
<connectedToName>vxw-dvs-35-virtualwire-16-sid-5011-LS_ODC_A_Transit</connectedToName>
</interface>
<interface>
<name>Towards_ODC_LS</name>
<addressGroups>
<addressGroup>
<primaryAddress>10.112.203.1</primaryAddress>
<subnetMask>255.255.255.0</subnetMask>
<subnetPrefixLength>24</subnetPrefixLength>
</addressGroup>
</addressGroups>
<mtu>1500</mtu>
<type>internal</type>
<isConnected>true</isConnected>
<connectedToId>virtualwire-15</connectedToId>
<connectedToName>vxw-dvs-35-virtualwire-15-sid-5010-LS_ODC_A</connectedToName>
</interface>
</interfaces>
</edge>

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>.

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>

Example:

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.

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.