Monthly Archives: June 2016

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

NSX

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

Advertisements

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

contentroot

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

VIP

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.

rule

#ACL for subnet –> acl host_subnet src 10.52.16.0/24   – 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 10.52.16.0/24 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:

1

2

3

4

5

6

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

7

8

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.

10

9

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.

11

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

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>

route

 

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:

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

dlr

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

%d bloggers like this: