NSX-T DFW Jump to Application

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.

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.

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.

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.

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).

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.   

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.