Direction and Applied To for NSX Firewall Rules

I've had the chance to learn about NSX lately, which has included really diving in to how the firewall behaves.  While it can certainly be used very much like a traditional firewall, you're not doing yourself any favors by doing so.  Remember, this is a policy-based firewall, so our goal is to define as many general behaviors as possible and then have them apply intelligently to the correct VMs based on attributes such as Security Tags.

There's a lot to dig into on this topic, but for now I want to focus on two attributes of a firewall rule: Direction and Applied To.  These two settings can be used to dramatically simplify a firewall configuration and can lead to some unexpected results if not used correctly (also, they took me quite a while to wrap my head around).

The most important thing to remember is that, like all firewalls, NSX eventually boils down to a sequential list of rules.  NSX will do whatever action is specified in the first rule to match a given flow.  Where things get really interesting (and confusing), is that NSX actually considers the list of rules twice for any given network flow, once as it flows out of the source and once as it flows in to the destination.  NSX actually maintains a list of rules per VM NIC, which is a digested version of all of the rules in the distributed firewall so that it only contains the rules that apply to that specific VM NIC.  A rule can apply to a given VM NIC because that VM is port of a Security Group, ESXi Cluster, Port Group, or even just to every VM NIC on the whole Distributed Firewall.

Let's look at a simple example DFW configuration:

Source Destination Action Applied To
VMA VMB Allow DFW
VMA VMC Allow DFW

We have 2 firewall rules involving 3 VMs.  NSX digests these rules to create a separate list for each VM, resulting in 3 lists:

VMA
Source Destination Action Applied To
VMA VMB Allow DFW
VMA VMC Allow DFW

VMB
Source Destination Action Applied To
VMA VMB Allow DFW

VMC
Source Destination Action Applied To
VMA VMC Allow DFW

Ok, so that was a really boring example, given that these simple rules directly involve VMs, but it makes the point painfully clear.  VM NICs don't consider rules that don't apply to them.

Consider instead this example rule set that isolates traffic between different solutions while allowing a set of default 3 tier application network flows.  An arbitrary number of additional solutions can be added to this example very easily, but we'll save the long discussion on Policies and Security Groups for another time.

When you look at this example, remember that every object referenced is actually a Security Group (so a dynamic collection of VMs).  Each VM in the environment will belong to at least two Security Groups: one for the solution that it's involved in, and one for its service tier (either web, app, or DB).  Also, note that the Applied To field gets very specific here - that's important for later.

Source Destination Action Applied To
Any InfraServices Allow DFW
Client Devices Web Allow Web
DB, App Web Deny Web
Web App Allow App
DB App Deny App
App DB Allow DB
Web DB Deny DB
SolutionA SolutionA Allow SolutionA
SolutionA ANY Deny SolutionA
SolutionB SolutionB Allow SolutionB
SolutionB ANY Deny SolutionB

Given these rules, a VM that's a member of the SolutionA and App Security Groups could talk to another VM that's a member of the SolutionA and DB Security Groups, but could not talk to a VM in the SolutionB and DB Security Groups.  If you just read this list of rules from top to bottom, that sounds like magic, as that Source: App, Destination: DB, Allow rule would seem to apply regardless of what Solution's Security Groups are applied, but bear with me.

Let's look at the lists of rules that NSX has calculated for each of the VM NICs that are involved in this network flow.

SolutionA App Server
Source Destination Action Applied To
Any InfraServices Allow DFW
Web App Allow App
DB App Deny App
SolutionA SolutionA Allow SolutionA
SolutionA ANY Deny SolutionA

This list might be a bit shorter than you would have guessed.  After all, the full firewall list has an additional rule that specifies the App Security Group as a Source.  Note though, that rule is Applied To the DB Security Group, meaning that it doesn't belong on this VM NIC.  This list will only contain rules that are applied to it, which means either one of its Security Groups or the DFW as a whole.

When NSX considers our network flow (SolutionA App to SolutionA DB) in light of these rules, the first rule that it finds and then applies is the SolutionA to SolutionA Allow rule (since this flow is between two VMs that are both tagged as being part of SolutionA).  NSX allows that traffic out of the Source VM.  Note, this is only the first NSX rule scan though; in order for this flow to be allowed, it must also be allowed in to the Destination VM.  Now, let's look at the applicable rules on that destination:

SolutionA DB Server
Source Destination Action Applied To
Any InfraServices Allow DFW
App DB Allow DB
Web DB Deny DB
SolutionA SolutionA Allow SolutionA
SolutionA ANY Deny SolutionA

NSX looks at the rules that are on the destination and gets another match: Source: App, Destination: DB, Allow.  Since this rule also allows the network flow, the flow will be allowed in to the DB server and will succeed.

So, why won't the SolutionA App server be allowed to talk to the SolutionB DB server?  Well, take a look at the list of rules that are considered when the SolutionA App server attempts to send traffic out.  The first rule that it finds is the Source: SolutionA, Destination: Any, Deny rule.  That means that, even though the SolutionB DB server rules, taken in isolation, might allow any App server to communicate with it, the DFW will deny that traffic from App servers from all other solutions, because that traffic is being denied as it is leaving those servers.

If you break down the rules for individual servers within each of the 3 tiers within each of the Solutions, you'll find that they all behave this way.  No servers may communicate across Solution boundaries and, within a solution, the only allowed traffic is within each tier or down from the tier immediately above (so, Web to App or App to DB but never Web to DB).

So, what's this have to do with the firewall rule direction?  Well, you probably noticed my use of the emboldened ins and outs throughout this post; those have all been references to implicit directions for those flows.  When we create a firewall rule that is Applied To its own Source, we are effectively saying that this firewall rule only applies in the out direction.  Conversely, if a rule is Applied To its own Destination, we are implicitly saying that it only applies in the in direction (in and out are from the perspective of the VMs here, not from the DFW perspective).

Of course, if we don't want to imply anything we can be explicit and actually set a Direction for the firewall rules.  If we say that a firewall rule only applies to the out direction, we are saying that that firewall rule can only be applied to traffic flows that are leaving a VM NIC (even if that rule is Applied To the whole DFW).  When a firewall rule only applies to the in direction, the opposite holds true - it is only applied to network flows that are going into a VM NIC.

So, this framework creates a very simple way to allow a set of default network behaviors for 3 tier applications, while scaling out very easily through the creation of additional solution groups when new solutions are introduced to the environment.

Comments

Popular posts from this blog

Deleting Orphaned (AKA Zombie) VMDK Files

Clone a Standard vSwitch from one ESXi Host to Another

Orphaned VMDK Files