NSX-T DFW Jump to Application

Submitted by Robin van Altena on Tue, 05/04/2021 - 08:53
 
 
Follow your favourite author

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

NSX-T DFW Jump to Application
Every time a new version of a product becomes available there are features that are presented on main stage and there are features that are ‘quietly’ introduced. One of those features is the ‘Jump to application’ option in the Distributed Firewall rules base of NSX-T 3.1. About a month ago during a technical discussion this option was mentioned to me and due to lack of time I didn’t look any further into it.... Until last week. We had just upgraded NSX-T to version 3.1 and we where checking the environment I was asked what this option was for. So, in this category of ‘Oooh! what does this button do’ the NSX-T 3.1 feature ‘Jump to Application’
Textarea

When I got the question about this feature I fortunately remembered a conversation I had regarding this. Because there isn’t much information to be found on the Internet. During my search I could only find one Youtube reference to it. Even in the NSX-T 3.1 release notes the is only a mention of something not working with the jumpto rule action. The NSX-T Administration Guide only shows ‘jumphost’ when looking for the word jump.

What does the ‘jump to’ feature do?

This feature is available in NSX-T 3.1 and only in the Environment category. It adds an additional option to the firewall rules in that category. Rather then stop processing after a allow or deny action, this specific rule can now continue processing in the Application category.

Image
Jump tot Application in Environment Category
Textarea

This all sounds very simple, but what could be a use case for this?

When I first heard about this feature, I thought it might have to do some with NSX-T federation, where ‘local’ admins could create rules to bypass rules created on a ‘global’ level. But the feature is only available in the environment category and not in the emergency category.

One use case I could think for this feature is to create exceptions to a 'allow any' rule without creating a mix of deny/allow rules in the 'environment' tab. This makes sense when we look at our 'Circle of Trust' model where we want to create Circles wherein traffic is always allowed. A Development environment/circle would for example allow developers to test out new features and traffic without having to worry about a firewall. But from a security perspective we want to allow as little traffic as possible to the rest of the environment. So in the 'environment' tab we would create an 'any any allow' rule from Development VMs to Development VMs.

But what if you would like to make an exception to this rule?

Before NSX-T 3.1 we needed to create an additional block firewall rule before the allow Any for Development or create more complicated rule sets. Personally, I don’t like the idea of having multiple deny rules in the rule base because if can complicate troubleshooting and there always is a risk for implementation errors.

First let me show you how we needed to do things before NSX-T 3.1 In this next example we see two Security Policies each with one firewall rule. The second Policy allows traffic from all Development VM’s towards all Development VM’s. With the first rule we can now make an exception to this rule, for example deny ICMP towards all Development VM’s. Of course, ICMP may not be the best use-case but this could also be NetBIOS or Multicast or what ever you need to configure.

Image
Example of firewall rules before NSX-T 3.1
Textarea

As stated before, I don’t like this approach and would rather only have one deny rule at the end of the firewall rule base. In NSX-T 3.1 we now have the option to jump to the Application category.

Image
Example of firewall rules in NSX-T 3.1
Textarea

With this setup the result is the same as long as there are no other Development rules in the Application category. ICMP traffic towards the Development VM’s will hit rule 5105 and instead of being dropped there it will continue to the Application category where it will hit the default deny rule with id 2.

Image
Default deny rule in NSX-T
Textarea

This makes monitoring and troubleshooting easier because all traffic is denied on the same and not multiple rules. Also, two entries are shown in the log files, one for the jump to rule (GOTO_FILTER) and one for the deny rule (DROP).

Image
Logging for the Jump-To rule
Textarea

The last question is do we start actively using this feature or should we wait for the next release? And why isn’t there any information available in the Administration Guide or in the release notes?

At least  from the release notes I can tell this feature doesn’t seem to work properly with Layer-7 APPIDs or maybe I'm just interpreting thing incorrect.   

Issue for jump to rule
Textarea

Hopefully VMware will release some documentation about this feature to provide some clarity. Thanks for reading the blog and if you have any questions, remarks or better use cases please send them to me.

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 Robin directly, in order to receive a quick response.

More about RedLogic