NSX.3 | Distributed Firewalls (UPDATED)

Portable firewall rules, kernel-level network monitoring and API-friendly? That must be VMware NSX Distributed Firewall.

NSX.3 | Distributed Firewalls (UPDATED)
Updated in April 2019 - cleared up some errors, added the "Taming the Beats section"

If you've ever heard of VMware NSX, you've probably heard the term "Distributed Firewall" and "micro-segmentation". These two terms are always popping up on business meetings, sales briefing and basically anything even remotely related to NSX.

The Network Junction

It is not really a surprise considering the fact the Distributed Firewall (DFW) feature of VMware NSX is something that really shows why NSX is the only solution of its kind on the market. This amazing functionality was created with one simple approach in mind: NSX installs kernel modules (VIBs) on ESXi hosts that allows it to have access to every single packet going to or coming from every virtual machine on these hosts. The DFW rules are then being applied on these monitoring "guard posts" or "junctions", which are located directly in between the VMs and the vNICs they're assigned to through a Distributed Switch - pretty cool, right?

On this image, you can see a visual representation of where the distributed firewall resides:

In this scenario, NSX acts as a general, ordering the ESXi to watch over the out- and incoming traffic. Whenever the ESXi spots a packet which does not comply with the NSX's rules - it drops it. As I've said before, the concept here is brilliant, but at the same time very, very simple and straight-forward.

Light & Powerful

A thing to note here is that because this "traffic control" takes place in the kernel space of the ESXi host it uses a negligible amount of CPU resources and power, making it much more CPU-efficient than any other software-defined firewall solution (excluding the fact that there's no other firewall solution monitoring the traffic on this level, i.e. between the VM and a vNIC)

As VMware NSX is a very API and Open Source friendly product, there are already hundreds of third-party (or "partner") solutions out there which are taking an advantage of the inline access to virtual traffic provided by NSX. Here are some examples of such "add-ons":

  • F5 BIG-IP - local traffic management, DNS services, carrier-grade NAT, policy enforcement, diameter traffic management etc.
  • Palo Alto Networks Intrusion Prevention - vulnerability exploit prevention, malware & command-and-control (C2) prevention
  • Rapid7 Nexpose - on-premise vulnerability scanner  

As you can see, VMware NSX Distributed Firewall technology is a really brilliant piece of tech. The only thing to keep in my though is that even with all its superb functions and features, NSX DFW is not meant to be used for North-South traffic! While DFW will be a great addition or a core system to your East-West topology, you will still need something for monitoring and filtering North-South (physical firewall, NSX Edge Services Gateway, software-defined router etc.).

Taming the Beast

That's all nice and shiny, but how do you configure this Distributed Firewall anyway? Well, there are generally three ways to do that:

  1. Manual - just like in the old days, you can configure NSX rules to be based on source and destination IP addresses, ports and times etc. This approach is nearly exactly the same as what would you expect from a regular (be it physical or software-defined) firewall.
  2. Semi-manual - instead of using IP addresses or hostnames, you can base your NSX rules on any object in vSphere. This means you can have a rule which would allow all incoming packets to the "Cluster-01" or block all network traffic between vCenter "VC02" and logical switch "LGS04" - the possibilities are endless. Any, and I really mean "any", object in vCenter can be used as an argument in a DFW rule:  clusters, datacenters, port groups (all types), IP sets, logical switches, resource pools, security groups, vApps, VMs and a VM's vNICs.
  3. Service Composer - this is the really "proper" way of managing a DFW. Service Composer allows you to create Security Groups and Security Policies and then tie these together forming "Security Services". Let's break it down a bit:
  • Security Groups - logical containers that be made up of multiple object types (MAC address sets, directory groups etc.). You can use these not only to setup static (i.e. all VMs with MAC addresses ending with 22), but also dynamic security objects. For example, you could setup a filter which would add all VMs with "ftp" in their name to "FileServer" security group. That way you can cluster together vSphere objects which should be affected by same network filtering policies.
  • Security Policy - this is the "ACL"-like part of a security group. In these policies, you can define security "services" (rules) which will be then applied to the affected group's members. There are three types of services/rules which you can define: Firewall, Guest Introspection (HIPS, AV, Malware Protection etc.) and Network Introspection (traffic monitoring, traffic shaping etc.). By associating security policies to security groups, we are essentially making the firewall rules portable as they "move" whenever the member VM is migrated as long as it stays in the Security Composer scope.

As simple as it gets

Here's a real world example of how Security Composer makes the life easier for both the network administrator and a virtualization architect:

Let's say we have multiple servers in our environment requiring three different ways of external access:

  • ftp (file)
  • http (web)
  • ssh (management).

With NSX Distributed Firewalls and Security Composer in mind, we can agree on a simple naming scheme which would be easily "translatable" to NSX Security Groups (FTP01, WEB02, MGM01 and so on and so on).  

With these names all around our virtual environment, we can then simply create Security Groups which would choose their members based on this naming scheme - for example, a group containing all file servers (FTP*), another one for web servers (WEB*) and similar one  for management servers (MGM*).

Lastly, we can define individual security policies allowing different kind of traffic and associate them with these three "named" security groups.

Software-Defined Networking World

The VMware NSX Distributed Firewall is one of these things we couldn't find possible mere five or six years ago. Yet, here it is - proving to be the future of security and networking for the enterprise.

If you're interested in more VMware NSX articles, be sure to check out the NSX-themed category on SSH.Guru

Have you ever used VMware NSX and rolled-out a Distributed Firewall to production? Let me know @wilk_it_wizard or #sshguru

Related Article