Firewalling & Micro-segmentation with VMware NSX

One very exciting and strong use case for VMware NSX is advanced security. VMware NSX has some inherent security features and also allows for 3rd party security appliance integration. In this blog, I’ll briefly discuss the firewalling and micro-segmentation capabilities of VMware NSX-vSphere.

An example of a traditional firewall network design is shown below. This setup shows the Dell S6000 switches used at the aggregation layer with a redundant one-arm firewall deployment; the firewalls can be deployed as active/standby or active/active. There are other firewall deployment models, such as in-line deployment at the aggregation/collapsed core, but, for this example, I’ll use this setup to demonstrate a traditional firewall deployment.

Traditional One-Arm Firewall Deployment

In this example, network engineers/admins would decide what traffic needs to be directed through the firewall, and Layer 3 termination for this traffic would be configured at the firewall; this is also where the inter-VLAN traffic would be routed for the respective protected traffic.

Several issues can be observed with this traditional centralized firewall setup:

1. Engineers/admins need to configure/maintain complex traffic engineering rules

2. The firewall becomes a chokepoint in the network

3. Additional firewall hardware as the network grows adds to increasing expenses (hardware CAPEX)

4. One centralized location to break/exploit to gain access to all networks

5. Traffic tromboning causes sub-par performance and wasted bandwidth

For issue #5 above, let’s look at an example. Assume VMs in subnet 10.1.0.0/24 (Green VM) and VMs in subnet 10.2.0.8/24 (Purple VM) are not allowed to communicate with each other. If VM 1 attempts to communicate with VM 2, the traffic is sent to the ToR Dell S4810 switches, then to the aggregate S6000s, and then to the firewall only to be denied. This is a classic centralized firewall scenario and illustrated in the figure below.

Traffic Flow from VM 1 to Firewall in Attempt to Communicate with VM 2

Some vendors have started supplying firewall virtual appliances, which does help resolve some of the traditional issues with VM to VM traffic and reduces the amount of traffic that needs to be sent to the external physical firewall. However, issues with low performance (typically 1-4 Gbps) and choke points still persist.

VMware NSX provides Distributed Firewall (DFW) capabilities. This is provided by a kernel-level module which is installed via the VMware NSX Manager vCenter Plugin as shown below. You can see from the below that the NSX firewall kernel-level module is installed at the cluster-level. In this case, I have a separate Management, Edge, and Compute cluster, and the firewall module has only been installed in hosts in the Compute and Edge clusters.

Installing VMware NSX DFW at the Cluster-Level

The VMware DFW is installed at the kernel-level of the ESXi hypervisor and thus VMware states it can get close to line rate performance.

One clear advantage of the VMware NSX DFW is that the firewall is brought down directly to the VM, meaning that each packet that leaves or enters a VM is processed systematically by the DFW before the packets ever leave the host. This is illustrated below. Compare this to the earlier example of the traditional centralized firewall. The advantage here is that the DFW knows that VM 1 should not communicate to VM 2 and blocks the traffic before it ever leaves the host, preventing unnecessary traffic over the network to a physical centralized firewall.

Traffic Flow from VM 1 to NSX DFW in Attempt to Communicate with VM 2

Another benefit is that the firewall/security rules move with the VM. In a physical environment, where the VM is tied-down to the networking hardware, provisioning of network services for a simple VM move could be very tedious and time consuming.

To configure a DFW rule, under Network & Security in vCenter, select Firewall. You should see the below; here you can add the required firewall rules. Note, although the firewall rules are distributed to hosts in the cluster, the DFW itself is centrally managed as shown below.

VMware NSX DFW Rules

Another great feature of the VMware NSX DFW is the diverse options/criteria available for creating rules. Below, you can see a rule is being added; when clicking the + symbol in the Source field, there is a wide array of criteria to base the rule off of. For example, I can create firewall rules to allow/deny based off of Datacenter, Cluster, VM, Logical Switch, vNIC, etc.

VMware NSX DFW Rule Creation Options/Criteria

In this example, I simply click the red IP label under the + symbol and create a firewall rule based on the IP addresses that correspond to my example network diagram. As shown below, I have created two rules and edited the Name, Source, Destination, and Action fields.

Configuring VMware NSX DFW Rules

I’ve also enabled logging as shown below for the DFW rule, so there is a record of every incidence where the firewall rule is utilized.

Configuring VMware NSX DFW Rule to Block and Log

The VMware NSX DFW allows for micro-segmentation or a fine-grained network segmentation approach where security is no longer perimeter-centric but brought down to the respective segment/vNIC level. For example, a complete 3-tier architecture can be replicated in software and have firewall rules pushed down to the respective segments/tiers allowing for an enhanced security model; this is illustrated in the diagram below. The NSX DFW is positioned for internal East-West Software Defined Data Center (SDDC) traffic.

Micro-segmentation with VMware NSX DFW

VMware NSX also provides a NSX Edge Services Gateway which provides a VM-based North-South firewall positioned for protecting the border of the SDDC; an example illustration is provided below.

Protecting the Border of the SDDC with VMware NSX Edge Services Gateway Firewall

Beyond the basics demonstrated here, VMware NSX provides additional firewall features/capabilities such as using NSX Security Groups where specific firewall rules can be applied to VMs based on different attributes like VM Name or Security Tag. Furthermore, VMware NSX supports Role Based Access Control (RBAC) to allow for access/control of firewalls based on job profile.

Follow me on Twitter: @Humair_Ahmed