The NSX Distributed Firewall is one of the truly big innovative features that VMware has brought to its customers in the past few years. It is also one of the big selling points of VMware NSX. Anytime you hear something about "micro-segmentation", that's basically VMware marketing lingo referring to the Distributed Firewall feature. So let's take a look at what the DFW can do for you and how you can best take advantage of it for your organization's needs.
Dude, where's my Distributed Firewall?
The NSX Distributed Firewall is like Santa Claus, it is everywhere and it is nowhere. It sees you when you're sleeping, it knows when… you get the point.
This amazing new functionality is born from a very simple principle: NSX installs kernel modules (VIBs) on ESXi hosts that allows it to have access to ALL the network traffic that goes in or out of ALL VMs that reside on those hosts. The Distributed Firewall would never be possible without that type of inline functionality. What the DFW does is basically applying firewall rules on these "junction points" where traffic is monitored, which are located right in between a VM's vNIC and it's connectivity to the Distributed vSwitch. On this image, you can see a visual representation of where the distributed firewall resides, right under each VM's vNIC :
In this case, NSX is the brain and ESXi is the workhorse. NSX contains the firewall rules, ESXi watches the network traffic and if it matches a blocked firewall rule, ESXi drops the packets. Very simple, yet very efficient. Since it runs in the kernel space it is very CPU-efficient and should use a negligeable amount of CPU horsepower. From a network design perspective, the DFW eliminates any convergence points where all of the network traffic is concentrated and distributes that functionnality to every NSX-participating ESXi host.
Allowing NSX to have inline access to any VM's network traffic opens up a lot of possibilities. Distributed firewalling is one prime example, but VMware also enables its partners to utilize this functionality for other interesting use cases. One such partner is Palo Alto Networks, that uses this inline access to add-on an Intrusion Prevention solution on top of NSX. NSX and Palo Alto Network's Panorama console work in tandem to accomplish things that NSX alone cannot. There are other examples like this one (F5, Rapid7, etc.), and NSX having the traction it does, I'm sure we'll see more partners using this hook in the near future.
Finally, one thing you need to understand about all this NSX goodness is that the DFW is meant to be used for East-West network traffic only, you will most probably still need to have a physical firewall sitting on your perimeter network for North-South network traffic! The NSX Edge Services Gateway is meant for North-South firewalling among other things, but chance are those are also INSIDE your datacenter, not in your network's perimeter. Be mindful of that when designing your network.
What's in it for me?
Configuring the Distributed Firewall is a breeze and consuming it in an "operational" manner is even easier. Let's take a look at why that is.
When configuring the distributed firewall, you can chose to do things the old school way, by specifying source and destination IP addresses or ranges, but that just sounds plain boring, not to mention inefficient. If you want take things a step further, you can apply firewall rules to almost any object in vCenter. For example, you can configure firewall rules for a specific Cluster, Datacenter, Port group (all types), IP Set, Logical Switch, Resource Pool, Security Group, vApp, VM and a VM's vNIC. Nearly any existing object in vCenter can be configured as a Source or Destination for a firewall rule. This already gives you great flexibility when applying rules. But NSX can do even more, using what's called the Service Composer. To understand how to do it, you'll first need to grasp a few key concepts:
Security Group : Security Groups are basically containers that can contain multiple object types (see earlier list and these two : MAC Sets and Directory Groups). NSX also allows you to specify Dynamic Membership, which you can use for example to add all VM's that have "web" in them to a specific Security Group destined for Web servers. Being part of a Security Group actually does nothing, until a Security Policy is applied to that group.
Security Policy : A Security Policy can be applied to a Security Group and is the definition of what Security "services" you will apply to that SG. There are 3 types of services : Firewall Rules, Guest Introspection (things like antivirus, HIPS) and Network Introspection (traffic monitoring, IPS/IDS, etc.). For the purposes of the DFW, this is where we'll configure our rules.
Since adding objects dynamically to Security Groups and applying Security Policies to those Groups is so easy, that makes for a tremendous amount of power for the NSX Administrator. What this method also allows you to do is to make firewall rules portable. Move VMs around and the Security Policy follows! Awesome… right?
Let's end with an example. Let's say I have a typical 3 tier application, Web server, App server and DB server.
Step 1.
I would make sure that all of the application's VMs would contain a specific string in their hostname that designates its function, something stupidly simple like "web", "app" and "db".
Pretty easy so far right?
Step 2.
Create 3 Security Groups, one for each server type and configure each with a dynamic membership rule that will include any VM that has a specific string in its VM name. For example the "SG-Web" security group will include any VM that contains the string "web" in its name.
Step 3.
Create 3 Security Policies that contain 3 different sets of firewall rules for each of the application's tiers. Apply these Security Policies to their corresponding Security Group.
Step 4.
Sit back relax and have a nice cup of tea, you've earned it.
The Bottom Line
The NSX Distributed Firewall is a huge step forward for anyone coming from traditional firewalls and micro-segmentation is the best thing since sliced bread. Finally, if you want to learn more about the NSX Distributed Firewall, you can find a ton of info on it in VMware's official NSX documentation. Have fun!
For small scale deployments, using descriptors in the VM name might suffice, but I would think that Tags would be a better approach? Is matching based on Tags available? It lends itself to a policy-driven data center.
For step 1, why not use tags instead? Much more flexible, you don't have to give away your servers' functions in the name, and you don't have to rename anything that already exists.
Great post! i would request more posts for different nsx components as well.
Nice post, very informative, thanks for sharing