In this blog article I will first give you some history of the NSX product and how it evolved to the current product that we all know today. Next I will explain the security use case for NSX. And show you step by step how to implement this in your environment.

A bit of history
In 2012, VMware acquired a company called Nicira. One year later VMware launched of the first NSX product from to the public. One year later in 2013 VMware launched NSX for vSphere (NSX-V). NSX-V came with its limitations. To name a few It was tied into vCenter and it was not possible to create multi-tier routing. In 2016 came VMware launched NSX 1.0 which later evolved into NSX Datacenter. Now fast forward to January 22 of 2022, on this day VMware release NSX for Datacenter version 3.2.0.1. This release came with a long list of improvement on his predecessor. The migration and upgrade assistance is very much improved to allow this version to operate in a wide variation of environments. Another big change is the launch of the Kubernetes bases NSX Application Platform.

Security Use case.
Now that we set the tone on NSX, and have everybody on board about the latest release let’s dive in to the subject at hand, security. In today’s online world, news items about data breaches for company’s both big and small are no longer a surprise. News about security issues within software (Log4j) or companies being attacked by hackers from other countries. Cyberattacks have increased by 65% since Russia invaded Ukraine. The common sentiment among companies nowadays is “It is not a question if, but when will you fall victim to an online attack”.

Previous the security of networks was only focused on the threads coming from outside. But what happens when they are already inside without you knowing it? If you use vRealize Network Insight (vRNI) to scan and analyze your network flows you will learn that most of your network traffic occurs within the datacenter (East – West) and not to the outside world (North – South). NSX for Datacenter has a components called Distributed Firewall (DFW). This firewall “lives” within the NSX agent that you install on every NSX managed vSphere ESXi host. Because it “lives” on the vSphere ESXi host it is able to “see” all the network traffic within the virtual infrastructure. This answers one the most asked questions about NSX Microsegmentation, can it also protect physical devices. For all the firewall rules within the DFW, needs to be to or from a VM. So I can protect for instance the traffic from a physical Citrix Netscaler to a virtual application server.

How to setup NSX microsegmentation?
To setup microsegmentation you need to group your type of VMs. Needless to say that this requires deep knowledge of you application infrastructure. NSX has an option called NSX Intelligence, just like the forementioned vRNI NSX Intelligence will analyze your network traffic and make suggestions for DFW rules to protect your environment. From NSX for Datacenter 3.2.x NSX Intelligence is part of NSX Application Platform (NAP). NAP requires an Kubernetes cluster (for instance VMware Tanzu) to function. This Kubernetes cluster will require resources to be available in your environment. I will spend a separate blog on NAP later on.

To explain the implementation of NSX Migrosegmentation let’s assume we have a two three tier application setup. We have a database server, an application server and a webserver to present the application to the end user. So This is a schematic display of the three tier application infrastructure, plus it shows the port required for the application to function correctly.

To allow for a streamlined view of the various rules we are going to create to complete this task we will create Server groups. We need the following groups, VDI, Web Servers, Application Servers, Database servers and AD servers.

First, for your administrators we create a “Management RDS Server” where we install all the necessary consoles to manage the environment, and we allow that server to contact all Windows servers over port 3389 to be to manage these servers via RDP. On a side note, allowing RDP from any device is a big risk because hackers are using RDP for lateral movement towards high risk systems once they have access to your network.

VDI is by far the easiest use case for DFW. For the VDI group we first create a rule that VMs within the VDI group are not allow to talk to each other. This solves the issue where one affected VDI causes trouble by allowing the malware to be replicating to any other VDI machine.

From the Web Server group, we create a rule that states that the VDI machines can only access the webservers over port 8080.

The application server is talking to the database server on the default SQL port 1433 and to the webserver on a application specific port 46500.

By only allowing the specified network flows and blocking any other traffic to these system you have now placed a firewall before each VM.

Configuration in NSX

To configurate East-West Firewall rules within NSX we first need to be able to identify the traffic we are dealing with. By using NSX Intelligence we are able to do just that.

In the above screenshot from NSX Intelligence we can see how the dataflows are identified by NSX Intelligence. The software will also make recommendations to group certain systems together and recommend firewall rules between those grouped devices.

In the above screenshot we see a recommended firewall group. NSX Intelligence allows you to create the recommended firewall rules with just a few clicks.

In the next part of this article I will show you how to create these rules manually.

you choose Security from the top menu and Distributed Firewall from the right side menu bar.

There are different category’s to apply firewall rules from within NSX. For the examples in this article I will focus on the application category.

First I want to show an example of creating a group. I want to create a group to identify all VDI machines. So I’ve created a VDI group in NSX and I also created a rule to add the appropriate members to this group.

In the above screenshot you can see I’ve created a rule to add all machines where the VM name starts with the letters VDI.

In the next step I’ve created a rule with the group I’ve created in the previous step.

In the above screenshot you can see that I’ve used the VDI group in both source and destination and set the rule to drop. Important to point out that I’ve choose to apply this rule on the DFW (Distributed Firewall).

I also want to show a different firewall rule I’ve created. As mentioned earlier in this article intruders are often using our tooling against us. A example of that is the attackers are using RDP for lateral movement towards the “golden nugget” systems. To put a stop to that we’ve created specified management systems. These systems are only used for management, Outlook and Teams are not installed on these systems.

In the above screenshot you can see the rule I’ve created for the management systems. These two rules make sure that I can only RDP to the Web, Application and Database servers from these specified management devices. If I try to RDP from any other device the traffic is dropped by the firewall.