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.

The theory

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

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:

VM A talks to VM B via port 445

Then, I created some firewall rules:

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:

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.

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

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:

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.

The original article was posted on: significant-bit.com

Related articles

  • Cloud Native
  • Implementation and Adoption
  • Platform Engineering
  • Digital Workspace
  • Hybrid Cloud
  • ITTS (IT Transformation Services)
  • Managed Security Operations
  • Managed Cloud Platform
  • Backup & Disaster Recovery
Visit our knowledge hub
Visit our knowledge hub
Robert Cranendonk Virtualization Consultant

Let's talk!

Knowledge is key for our existence. This knowledge we use for disruptive innovation and changing organizations. Are you ready for change?

"*" indicates required fields

First name*
Last name*
Hidden