The main use case for NSX is still security. With NSX we have the possibility to use NSX Edge Firewalling for North-South Traffic and NSX Distributed Firewalling (DFW) for East-West Traffic. Due to two vendor strategy and throughput the most companies are using the NSX DFW Firewalling inside the data centre and a hardware vendor firewall for north-south traffic. This blog entry has the focus to DFW and NSX-T but be aware that the difference regarding Distributed Firewalling between NSX-v and NSX-T is low.

1. Start small and end big!

When starting with NSX DFW you should not start like: “I want to have micro-segmentation between every server with each dedicated port in my whole infrastructure”. Think more like to start small and to end big which means to secure the traffic initially between zones or applications. It is not a good idea to restrict every port and protocol inside the applications from the beginning. If it is mandatory from the start you can activate micro-segmentation only within areas which are really critical.

The other challenge is that it is not easy to get all information about IP`s and Ports from the application owners. There are assistant tools like vRealize Network Insight and NSX Intelligence if you use NSX-T but in any case it would create efforts if you don`t get this input from the application owners.

2. Security Policy Methodology

There are three security methodologies which can be used. Network-centric is the traditional approach, grouping objects can be done via IP addresses or MAC addresses. The infrastructure methodology is based on segments or segments ports, identifying where application VMs are connected.

If no dependencies to the physical, network and logical infrastructure exist it is highly recommended to use the application security policy methodology. The application-centric approach is based on the application type, i.e. VM`s tagged as “Database-Servers” or application environment tagged as “Prod-Area”. With this approach you are ready for automation, cloud-native applications and a self-service portal.

3. Rule Ordering

With NSX-T DFW there are 5 pre-defined categories existing:

Ethernet
Emergency
Infrastructure
Environment
Application

Picture 2: Distributed Firewall - Category specific rules

Within each category you can define different sections or policies, in picture 2 you can see the category INFRASTRUCTURE with policy Section1 and rule Rule1. Rules are processed in order from the top down. It is recommended to place the rules which hit most towards the top of the ruleset to reduce the number of rules that need to be processed through the ruleset.

4. Configuration Limits

It is very important to observe the configuration maximums, you can verify it under the link https://configmax.vmware.com . Some of the maximums are hard limits and others are soft limits due to testing regulations. In any case if possible it is not recommended to exceed this. It is also important to check the configmax page for every dedicated version because changes are happing from time to time.

5. Applied To Field

One important point is to use the “Applied To field” in a smart way. When DFW is used there like in Picture 2 the rule is applied to the whole Distributed Firewall which means the rule is published on every vNIC filter of a VM where DFW is configured. Thus use for the “Applied To field” security groups where possible, i.e. app-servers in Picture 3. The risk is high to reach the maximum limit per vNIC if you use everywhere the DFW as applied to parameter. The rules limit per vNIC with the current NSX-T Version 2.5.1 is 4000 rules per vNIC.

Picture 3: Distributed Firewall - Apply To Field

6. Rule Explosion via Services

The rules limit of 4000 rules per vNIC seems to be very high but you have to understand how it is pushed to the ESXi hosts. For every service entry which you create within the NSX-T Manager GUI there is one rule create on the ESXi vNIC filter. In Picture 4 there is a example visible with the rule name App Server. This rule has three different services NTP, SMTP and SNMP configured. In Picture 5 it is shown that the filter for the vNIC creates for the ports 123, 162 and 25 three rule entries.

A workaround to avoid this problem is to configure service entries with ports. In Picture 6 it is visible that the ports 123 and 161 are configured with comma separation. Picture 7 shows the service predefined service “UDP Set” in the rule with the name “App Server”. Finally you can see that on the vNIC level there is only one rule created for the ports 123 and 161 of the service entry “UDP Set”.

Picture 7: DFW rule example with customized service “UDP Set”

7. DFW Thresholds

DFW Threshold profiles provide an ability to apply CPU & memory thresholds for DFW on ESXi hosts. The profiles can be applied to NSGroups consisting of ESXi Transport nodes. The transport nodes will then provide alerts when CPU and memory thresholds for DFW has exceeded/fallen below the set threshold values. This only works on ESXi based transport nodes.

The default threshold is configured to 90 % for CPU and memory, it is recommended to change the value to 80 %.

8. DFW Drafts

Another feature which has been released with the new NSX-T 2.5. version is the DFW Draft feature. Rules can be saved as Draft before it has been published. The system allows to have multiple users work on the same draft with a locking mechanism to disable overriding of rules from different users.

After the ruleset has been published the system creates a copy, the configuration can be re-deployed to rollback to an existing state.

9. DFW Exclusion List

One important feature for DFW is the exclusion list option. During troubleshooting or for some VM`s which needs not to be micro-segmented there is the possibility to exclude dedicated VM`s from the DFW without a deactivation of the whole DFW on the ESXi host. With NSX-T it can be configured on NSGroup (Security Group), Logical Switch or Logical Port level.

10. Stateless Rules

The DFW firewall is from default a stateful firewall. It is possible to change this behaviour on the policy (section) level if mandatory. Stateless rules do not create entries in the connection table and will always need to be evaluated against the rule base. It is recommended to place stateless rules as close to the top of the rule base.

Summary

If you start with Distributed Firewall it is important to have a detail planning to get a good structure of your firewall ruleset. The planning process could be from a high level view like this:

Understand the Application
Define the Methodology
Breakdown Application
Prepare Documentation
Secure the Application

Micro-segmenation is also not only a technical challenge, you need to involve several stakeholders, like security administrators, application owners or security officer, this depends on your company organisation. The NSX Distributed Firewall can work on Layer 3/4, Application Level Gateway (ALG) and Layer 7 with APP-IDs but it could be also taken into account how it works together with other security solutions like AppDefense, IPS/IDS, perimeter firewalls, NSX Third Party Integration on Guest or Network Introspection Level. When you consider all this you have a real great value of NSX Distributed Firewalling!

Design NSX Firewall Policies in a smart way

VLAN/Subnet Security

Lateral Movement