0

Practical NSX: The Distributed Firewall

In my humble opinion the Distributed Firewall is by far the biggest selling point of NSX. Micro-segmentation has become a magical word as It greatly surpasses the capabilities of tradition firewall technology at the perimeter. Simply put, micro-segmentation has completly changed the way security is handled in the datacenter. Let’s take a look at what the DFW can do for us and how you can best take advantage of it.

Let’s get one thing out of way first, The DFW is meant to be used for east-west traffic, while the NSX Edge is meant for North-South traffic. The distributed firewall allows to create both L2 and L3 rules. Note that the L2 rules take precedence over the L3 rules.

The Components

As we everything else in NSX, The DFW has a management plane, a control plane and a data plane let’s have a look at each plane.

  • Management Plane: represented by the vCenter server or by api calls
  • Control Plane: The NSX manager gets the rules from vCenter then pushes them down to your ESXi host.
  • Data Plane: that’s your ESXi hosts. All firewall functions take place via the kernel modules on the hosts.

Note that each vNIC get its own instance of DFW. Wherever the vm move the firewall moves with it!

Where is my firewall?

The Distributed Firewall is a hypervisor kernel-embedded firewall, remember the vibs you installed when you where preparing your hosts? this results in great throughput and the more ESXi hosts you add  the more throughput you will have. Now tell me that’s not great!

Let’s have a look at how this is implemented.

The VM called web01 has a slot 2 dvfilter applied. Web01 is now subject to all of the DFW rules configured.

Let’s check what rules are applied to this VM

How are rules are enforced

  • DFW rules are enforced in top-to-bottom ordering.
  • Each packet is checked against the top rule in the rule table before moving down the subsequent rules in the table.
  • The first rule in the table that matches the parameters are enforced.

Therefore, when creating rules it is recommended to put the most granular rules at the top.

How does it work?

The DFW instance on an ESXi host contains 2 separate tables:

Rule table:  Store all policy rules.

Connection tracker table: cache flow entries for rules with permit action.

  • When VM1 sends traffic to VM2 a lookup is performed in the connection tracker table to check if the flow has already an entry
  • If no entry is found a lookup is performed against the rule table to identify which rule is applicable, the first rule that match the flow will be enforced.  A new entry will be created inside the connection tracker table (Allow).
  • Subsequent packet will be checked against the connection tracker table.

How do I use it?

When working with the distributed firewall, you can specify source and destination IP addresses or ranges as you would do with a traditional firewall, however with the DFW you can apply firewall rules to almost any object in vCenter. You can configure firewall rules for a Cluster,  a Datacenter, Logical Switch etc.  This is already far better than what we had before, but NSX takes it a step further with the Service Composer which I will talk about in a separate post.

Let’s have a look at an Example

In our example, we have three servers a web, app and db. All three servers are on the same segment and attached to the same logical switch. We are going to create some DFW rules to implement the below:

  • SSH connections from outside are permited to the web server
  • the Web server is allowed to connect to the App server via port 8342
  • the App server is allowed to connected to the DB server on port 8344
  • All other connections are denied.

Let’s add the VMs to the collapsed logical switch

Now let’s check that the VMs can communicate with each other

Time to create our DFW firewall rules

I am going to create a section to keep things tidy

Rule to allow SSH outside connections to the web server

Rule to permit connections from the web server to the app server on port 8342. Please note that I have created my own service for port 8342

Our final rule is to allow the app server to connect to the db server on port 8344

Testing

If our rule are working as they should be, the web server should not be able to ping the app server. Let’s check.

We are unable to ping as our firewall is blocking!

I hope this post was helpful. Thank you for reading.

How useful was this post?

Click on a star to rate it!

Average rating / 5. Vote count:

Sharing is caring!

Leave a Reply

Your email address will not be published. Required fields are marked *