NSX-T Distributed Firewall Traffic Direction

Submitted by Robert Cranendonk on Fri, 07/15/2022 - 15:24
 
 
Follow your favourite author

Leave us your email address and be the first to receive a notification when Robert posts a new blog.

NSX-T Distributed Firewall Traffic Direction
Fri 15 Jul, 2022
NSX-T has a (somewhat hidden) setting in the Distributed Firewall configuration: traffic direction. But one thing that has continually stumped me is how to explain this in a concise way. Every time I think I finally got it, during the explanation I get lost in the following: direction is relative. So is it outgoing for the source, or the destination? But for the destination it's the other way around...?

So I did some testing to once and for all figure it out.
Textarea

The theory

The VMware Docs have the following explanation for the direction setting:

Image
1
Textarea

Source: VMware - About Firewall Rules

So the direction is always relative to the destination.

However; what tripped me up is that the Distributed Firewall is enforced on each and every VM (that participates in the fabric). So what is incoming for the destination VM, is outgoing for the source VM, so how does that relate to the way the firewall is enforced?

Often times we also include an 'any-any-any:OUT' rule at the top of our DFW model. That way we only check the incoming traffic, which simplifies the configuration of the rulebase at a very slight reduction in security. So how is this outgoing rule affected by the direction?

The practice

So in order to test, I have created the following, very simple, setup:

Image
2
Textarea

VM A talks to VM B via port 445

Then, I created some firewall rules:

Image
3
Textarea

Using the little cog wheel on the right I have configured the direction as it is written in the name; we allow all the outgoing traffic, and filter on the incoming. Take note of the Rule ID's; 1003 (deny all), 1004 (SMB incoming), 1005 (allow all outgoing).

For example, the outgoing rule:

Image
4
Textarea

Going into the Traffic Analysis portion of NSX-T we'll see how this affects the flow. We'll trace a path from VM A (winvm01 in my case) to VM B (winvm03) using port 445.

Looking at the steps we can see it is allowed at the source VM through rule ID 1005, and at the destination through rule ID 1004, exactly as we have defined it.

Image
5
Textarea

To further test it, we'll have a look at the reverse path, which we haven't explicitly allowed.

Image
6
Textarea

And immediately we can see this traffic is dropped by rule 1003, but only on the destination VM.

This makes total sense; since we're allowing all outgoing traffic it will exit the VM (rule ID 1005), but since only VM B (winvm01) is configured to have incoming traffic allowed, it is dropped by the deny-any rule 1003.

In/Out

If we configure the SMB rule from incoming to in/out we can see that this is the rule that is hit twice for this same traffic stream:

Image
7
Textarea

Conclusion

To wrap up; I don't like the definition as written in the VMware Docs, because there's slightly more to it.

It's much easier to think about it in a common-sense way, i.e. just to think of the traffic flow and what direction it is in when it hits the firewall, and remembering the fact that NSX has a firewall on both the source and destination, so all traffic must traverse the DFW twice.

Tags

Questions, Remarks & Comments

If you have any questions and need more clarification, we are more than happy to dig deeper. Any comments are also appreciated. You can either post it online or send it directly to the author, it’s your choice.
Let us know  

 
 
Questions, Remarks & Comments

Message Robert directly, in order to receive a quick response.

More about RedLogic