Configuring NSX-T 3.2 Switch Agnostic Security

NSX-T 3.2 was released on the 16th of December 2021 with a lot of new features focusing o Gateway security, ease of NSX adoption in brownfields and a lot of new operational and performance enhancement.

On this blog post I am covering how NSX-T 3.2 can be utilised to secure workloads which are not connected to NSX logical segments. This is what is called switch agnostic security because you do not need to connect your workloads (to be protected by NSX DFW) to an NSX-T logical segment, all what you need to do is to point NSX to “protect” those workloads as they are connected to standard DVS port groups.

You need however to prepare the cluster which is running those workloads with a new NSX mode of operation called “security only”. With NSX operating in security mode, hosts which are going to be NSX “prepared” are not going to make use of any NSX networking stack capabilities and only utilises the DFW kernel module to filter E-W traffic for DVS port groups connected workloads.

Lab Inventory

For software versions I used the following:

• VMware ESXi, 7.0.2, 17867351
• vCenter server version 7.0.3
• NSX-T 3.2.0.1
• TrueNAS 12.0-U7 used to provision NFS datastores to ESXi hosts.
• VyOS 1.1.8 used as lab core router.
• Two Ubuntu 20.04.2 LTS VMs as webserver1 and webserver1.
• Ubuntu 20.04.2 LTS as DNS and Internet gateway.
• Ubuntu 20.04.2 LTS as Linux management host.
• Windows Server 2012 R2 Datacenter as management host for UI access.

For virtual hosts and appliances sizing I used the following specs:

• 2 x virtualised ESXi hosts each with 8 vCPUs, 4 x nics and 32 GB RAM.
• vCenter server appliance with 2 vCPU and 24 GB RAM.
• NSX-T Manager medium sized deployment with 6 vCPUs and 24 GB RAM (no reservations).

Configuring NSX Security on Workloads cluster

As mentioned, NSX-T 3.2 offers a new cluster preparation mode called security only. This mode allows hosts to run workloads on standard DVS port groups while utilising NSX DFW for those workloads without the need to migrate workload VMs to NSX-T logical segments.

First you need to add vCenter server which is managing the workloads cluster as compute manager in NSX UI. Ensure that vCenter is successfully registered and UP

After adding a compute manager, navigate to System > Quickstart and then click on “Get started ” under Prepare Clusters for Networking and Security

Choose the cluster that you want to prepare for NSX security and from the Insyall NSX drop down menu choose Security Only

Click on Install to start installing NSX bits on the selected cluster

Wait for a couple of minutes and then your cluster should be successfully prepared for NSX security and you can view the hosts status under System > Fabric > Nodes > Host Transport Nodes

Notice the security tag near the cluster name, this indicates that hosts in that cluster are prepared for NSX security only.

Creating a DFW rule for workloads connected to standard DPG

First, we will create a security group containing all webserver VMs in order to apply a DFW policy on them allowing only http traffic and denying all the rest. Creating a security group is not a must but it is a common practice in production environments to properly group workloads which have similar functionality.

It is also recommendation to apply DFW policies as specific as possible to limit the resource consumption on hosts running workloads which are not part of the DFW policy.

From NSX UI navigate to Inventory > Groups > Add Group and create a group called WebServers

Set group compute members based on the below criteria

Navigate then to Security > Policy Management > Distributed Firewall

Click Add Policy and add a policy called WebSevers

Add a rule called Allow HTTP with source Any, destination WebServers security group and under services select HTTP.

Click on Apply, add then another rule to drop any other traffic to WebServers server group.

Your DFW policy and rules should look like the below

Testing access to WebServer VMs

From my Ubuntu JumpBox I will try to HTTP, Ping and SSH to both webserver VMs. According to the configured DFW policies, only HTTP access should be allowed.

~# curl http://webserver1
<html>
    <head>
        <title>Welcome to Webserver1!</title>
    </head>
    <body>
        <h1>Success!  Your Webserver is working!</h1>
    </body>
</html>

~# curl http://webserver2
<html>
    <head>
        <title>Welcome to Webserver2!</title>
    </head>
    <body>
        <h1>Success!  Your Webserver2 is working!</h1>
    </body>
</html>

~# ping webserver1
PING webserver1.corp.local (20.20.20.1) 56(84) bytes of data.
^C
--- webserver1.corp.local ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2034ms

~# ssh  bassem@webserver1
^C
~#

The above shows that ICMP and SSH do not go through but HTTP does.