VMGuru

Micro segmentation is probably the number one reason for companies with vSphere to purchase NSX. This feature inserts a packet filter in between your VMs. A filter you can configure centrally, link to single VMs, groups of VMs, kinds of VMs and specify according to your needs. As your data security on the internet is, involuntarily, tested on a daily basis, it’s not a question of IF but rather WHEN you will face a breach of your security. Micro segmentation can be your saviour at that moment, as it restrains the attacker to the compromised host. Compare it to your house. With a generic firewall, you just lock the front door. If a burglar gets in, he can walk right into your living room and nick your TV. With micro segmentation, every door in your house is closed and properly locked. If your front door is broken down, the unwanted guest is still limited to the hallway.

Recently a lot rumors went around over the interwebs on NSX. It was said that for the deployment of micro segmentation, you need a full NSX deployment. That is, you need to deploy the appliance, including all the planes, maybe even an edge router, the works. And it would take you years to install, let alone configure. Well, that is not correct. To deploy NSX just for micro segmentation, you only need to deploy the NSX Manager appliance and connect it to your vCenter. That’s all! No need for distributed switches, no need for full blown NSX deployment. So, to be clear, for micro segmentation:

You only need to deploy the NSX Manager VM
You need virtual distributed switches (If you are on vSphere 6, you don’t need Enterprise+ to use VDS when you have NSX)
You don’t have to have vSphere 6, it also works with vSphere 5.1 and 5.5
You don’t need expensive core switches or any other physical network gear requirements, its all virtual
You do need to have the vCenter Server Appliance and use the web client (it really got incredibly better in v6!)
You need about 12 gigs of RAM, 4 vCPUs, 60 gigs of storage and 1 vNIC for deployment

But then you’re good to go! I will not be going into configuration of policies in this post. That is food for another post. In this post we just go through the installation motions to get micro segmentation available to you in vSphere 5.x or 6.

So, to be clear on how to do it, I went along and just did it myself in my lab environment. Now, my lab currently consists of 2 hosts, but for demonstration purposes it is enough. Both run vSphere 6, vCenter Server Appliance v6 on iSCSI storage. I do use distributed switches but as mentioned before, this is not a requirement. When you first log into the vCenter Server Appliance, it looks like this.

No mention of firewalls anywhere.

NSX comes as an OVA file. I’m assuming you all know how to to download and deploy an OVA. One remark on this. When you deploy OVAs with the vCenter Appliance, you need to install the vCenter Integration Plugin on your management desktop first. And there is a little trick with that if you do. It took me a while to figure out what went wrong, which is why I am telling you in advance: the CIP modifies your HOSTS file in your Windows directory with an entry pointing to local host, to which it later connects. If your install does not modify the HOSTS file correctly, CIP will not install or will not start properly and you will not be able to deploy OVA files with vCenter Appliance. The easiest way to work around the problem, is to take an account with sufficient rights, browse to the HOSTS file in your Windows folder and remove the READ ONLY flag, before you install CIP. After the installation, you can set the READ ONLY flag back.

The hosts file can be found in your Windows folder, usually on C: C:\Windows\System32\Drivers\etc\hosts. Take care that you do not modify the access rights of the file, otherwise Windows will refuse to read the file and work with the entries. After installing CIP, you can go forward and deploy the NSX OVA file. The version I downloaded is 6.1.4, which is the most recent version at this time of writing.

Mark the checkbox on top for the extra configuration options to proceed. At this time it might be a good idea to talk about the network settings. The NSX Manager VM has just 1 IP address and it connects to your vCenter Server Appliance. Although I did not see it mentioned in the documentation, it’s probably a good idea to create your DNS entries for the appliance before you deploy. As my lab environment has a bit flakey DNS implementation, its less essential, but as you probably are going to move this into production in time, this is a good moment to do so. The next screens zoom in on where you want the appliance to be created in your cluster, where you want it to be stored and last but not least, the network settings.

After the IP information, you are asked (but not required) to enter the NTP server and if you would like to enable SSH. I left the last checkbox blank for now. After this deployment, we are ready to power it up and go and have a cup of coffee, because the NSX appliance, like the vCSA, takes a couple of ages to boot for the first time. When it’s done doing so, you can start your browser and open the secure NSX page on the new VM: https:// or . If all went well, you will get a login page where you need to log in with username “admin” and the password you defined earlier during the OVA deployment. After the obligatory browser-moaning about the self signed certificates (commercial ones are not supported, yet) you are presented with the NSX appliance console, which is pretty compact

To move on, select “Manage vCenter Registration”. Now, I have Single Sign On configured in my lab and it actually works quite well, although I break my lab on a regular basis. You might consider creating and using a specific service account to register the NSX appliance with the vCenter Appliance. If you did so, you will need those credentials in the next screen, otherwise just use the vCenter admin account.

If you have entered the information correctly, you should get a little popup stating the vCenter Appliance certificate fingerprint. If you select OK, the NSX manager will go on and register with vCenter.

If this process was finished correctly, you should see a nice green dot appear in the screen next to the status message that your NSX management appliance is now connected to vCenter. Go back to your vCenter appliance and log off. When you log in again, you should see a new entry in your options list!

When you go into “Networking and Security”, you will be presented with the NSX management screen. From this screen, you can configure NSX completely. Now there is one thing left to do. You need to install the VIBs in every host of your NSX cluster. This sounds like a lot of work and incredibly complicated, but in fact it’s easy as pie. When you click on the install menu entry in the NSX console on the left side, you are presented with a couple of tabs.

Go to host preparation, you should see your datacenter cluster there. Just click “INSTALL” and NSX will automatically go and install the VIBs one host after another. That is all you need to do. No VXLAN install, no data planes, this is it.

For the micro segmentation, you go to distributed firewall to see your ruleset and you can go into SpoofGuard, Service Definitions and Service Composer to create the policies you want and need to keep that door shut to anyone without a proper ticket.

The complete installation took me about an hour, including DNS modification and preparing my client system with CIP. When you are at this point, you might want to go and involve the security guy(s) to help you create the correct policies for your VMs. But as you can see, the NSX installation for micro segmentation is straight forward and does not require full deployment of NSX to make it work for you.