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.