NSXT 3.2 DFW on the VDS

Now that the distributed firewall (DFW) can be applied to a distributed virtual port group (DVPG), a lot of new options for where the DFW can be used have opened up. Before this feature an NVDS or a VDS version 7 were required to be able to use the NSX-T DFW. With this release it is also possible to use the DFW with a VDS version 6.6 and later. Opening the NSX-T DFW up to vSphere versions 6.7 and later, where this was only vSphere 7.0, if you are working with the VDS version 7.

Upgrading to NSX-T 3.2

To demonstrate the DFW on the VDS I upgraded a lab environment from NSX-T 3.1.3.3 to version 3.2. During the upgrade I paid special attention to one of the VM’s that was on the DVPG. Because I wanted to know, what would happen with this VM during the upgrade of the hosts. Would it start blocking traffic, since I had a block all rule at the end of my DFW configuration?

Apparently, nothing happened… When I moved the VM to an NSX-T Segment with the same VLAN-ID the DFW config was applied. When I moved the VM back to a DVPG the DFW config was removed again. This is because on clusters where NSX-T is already installed the functionality remains the same. So, during an upgrade from NSX-T 3.1.x to NSX-T 3.2 you don’t have to worry that workloads on DVPGs get blocked during the upgrade. But then how does this new feature work?

NOTE: be aware of KB87231, NSX-T 3.2 is officially only supported for Greenfield implementations, since they found some serious upgrade issues. Fortunately I was lucky in the lab environment, because I upgraded before this KB was released.

Distributed firewall on VDS

Okay, let’s start at the beginning. To be able to use NSX-T the ESXi hosts need to be prepared for NSX-T. In version 3.2 there are two options to prepare the hosts. Using the normal System > Fabric > Nodes > Host Transport Nodes method. The hosts can be prepared for Networking & Security.

New in version 3.2 is the option to only prepare the hosts for Security. This can only be done from the Quick Start menu. If you go to System > Quick Start you’ll see the following screen.

If you click the Get Started button, you’ll get an overview of the clusters where NSX-T Security can be installed. NSX-T Security is a Cluster wide option, it cannot be used on standalone hosts. To demonstrate this feature, I’ve created an additional vSphere cluster Compute-T-Security.

NSX-T can be installed by selecting the cluster and clicking Install NSX. Here you can select to install Security Only. With this option the DFW works on the VDS, with the Networking and Security option it works on the segment created in NSX-T.

Once the installation is complete the difference in NSX installation can be viewed using the normal System > Fabric > Nodes > Host Transport Nodes method.

As you can see, I have added 2 additional ESXi hosts to the cluster. NSX-T Security is automatically installed when the hosts are added to the vSphere cluster. For the blog I added 3 different versions of ESXi hosts. Even though the documentation says vSphere version 6.7 or later can be used. This is not entirely true. The vSphere version still needs to be compatible with NSX-T. When looking at the Interoperability matrix we can see that vSphere 6.7 is supported from U2 and later.

After upgrading the ESXi host to version 6.7 U2 and clicking the Resolve button, NSX-T Security is also installed here.

Although the installation is done automatically when a host is added to a cluster, the removal is not. So, be aware of that when moving hosts in and out of vSphere clusters. To remove the NSX-T Security, move the host outside the vSphere cluster. Select the host and click Remove NSX. 

If there is an error removing NSX, this is probably because the host is still a member of a group called 'NSGroup with TransportNode for CPU Mem Threshold'. Remove the host from the group by editing the dynamic criteria. This is the best option I found so far.

During the installation of NSX-T Security on the ESXi host, a Transport Zone and Transport Node profile are created automatically. These cannot be configured or edited.

In my case there are two transport zones, one for each VDS I used on the hosts and one transport node profile.

Now that we have NSX-T Security installed on a few difference ESXi versions, let start testing some firewall rules. In this Lab environment I have 3 different ESXi hosts each with 1 VM. But to keep it simple I’ll demonstrate the DFW on the host and VDS with the lowest version.

As you can see, I have an ESXi server with version 6.7 U2 or EP08 and a VDS version 6.6.0. On this host I have placed a Linux VM to show that DFW rules are applied to a VM that is connected to a DVPG. On the screenshots above you can see that the host roblabesx10 has been configured with NSX-T security. On the screenshot below you can see that firewall rules are applied to the VM.

Networking & Security

On the hosts prepared with Networking & Security the DFW works in the same way as it was in version 3.1. A VM needs to be connected to an NSX-T segment for the DFW configuration to be applied. As shown in the collection of screenshots below. The network roblan_vlan-106 is a DVPG, and roblan_vlan-106_ls is a NSX-T logical segment.

On the left the VM is connected to a DVPG and on the right the same VM on the same ESXi host is connected to a Segment created in NSX-T. Both are created on a VDS v7. At the bottom of the screenshots, you can see that No rules are applied on the bottom left, while there are rules present of the same filter (nic-18546059-eth0-vmware-sfw.2) on the bottom right.

Distributed virtual port groups in NSX-T

If the distributed firewall can be applied to distributed port groups, then these port groups should also be visible in NSX-T. The distributed port groups can be found under Networking > Segments > Distributed Port Groups.

In NSX-T the VLAN of a distributed port group can be viewed, but not edited. That needs to be done from vCenter. The description and the segment profiles can be edited for a distributed port group.

The distributed port groups can also be used to create dynamic groups, the same as with other objects in NSX-T.
A final note on this topic: If a VM is vMotioned from an ESXi host/cluster with NSX-T Security installed to a host without, it will lose the applied security configuration. And vice versa.

This blog shows how the distributed firewall can be applied to distributed virtual port groups, but the distributed virtual port groups can also be used to apply other security capabilities like Distributed IDS/IPS, NSX Intelligence, NSX Guest introspection and NSX Malware Prevention.

That’s all for this blog. Please contact me or leave some comments if you have any questions.