Pakhnyushchyy - Fotolia
Learn how to configure NSX firewall rules
VMware NSX users can configure firewall rules into specific policies to protect individual VMs, regardless of their location in the virtual infrastructure.
VMware's NSX-T Data Center applies comprehensive firewall rules to VMs. Admins can configure NSX firewall rules at multiple layers of the network, group firewall rules into policies and apply rules to groups of VMs. These firewall configuration options enable IT organizations to monitor specific areas of the network and control access, even for an individual VM.
Firewall rules control both vertical -- north-south -- and horizontal -- east-west -- traffic within a given network. NSX-T Data Center includes a distributed firewall and a gateway firewall. Each offers predefined rules, which network and virtualization administrators can use to limit east-west and north-south traffic. They can configure firewall rules to only apply to specific groups of VMs, which protects those VMs no matter where they reside in the virtual infrastructure.
The benefits of NSX firewalls
VMware's NSX distributed firewall (DFW) provides firewall protection where virtual infrastructure requires it the most: individual VMs. You can use firewalls in Windows or Linux, but these host firewalls don't have a centralized, cross-vendor configuration feature.
It's unfeasible to configure these host firewalls to limit traffic between individual VMs. They aren't aware of the entirety of the virtual infrastructure, and a centralized firewall has no insight into the relationship between VMs to allow or block traffic. When you use a centralized firewall in the network, the system must transport all traffic through the host firewall, which can lead to network overhead and latency.
The NSX DFW is active in the hypervisor kernel and enforced on each VM network adapter. This setup can help limit lateral movement between VMs and offer a centralized configuration feature independent of OSes and applications.
Distributed firewalls are an important defense in a virtual infrastructure because they protect east-west traffic. Additionally, NSX-T Data Center's gateway firewall protects north-south traffic at the edge of the network, before it enters the hypervisor.
Getting started with NSX firewall rules
To make use of this virtualized firewall, deploy NSX fully, with the NSX Manager in place, and configure hypervisors. The NSX DFW runs on both ESXi and kernel-based VM.
NSX users can deploy the gateway firewall for stateful services because the firewall itself is a stateful service. NSX creates gateway firewall rules similar to distributed firewall rules. You can find gateway firewall rules under the north-south security section in the NSX administrator interface. The major difference is there's no Applied To field because NSX places and enforces at the edge where the gateway is located. Still, in an active-active tier 0 gateway, it's not possible to add a stateful firewall to the routing path.
NSX processes firewall rules for both distributed and gateway firewalls through five categories, listed top to bottom: Ethernet, Emergency, Infrastructure, Environment and Application (see Figure 1). The rules stack as a full list and execute from top to bottom within these categories. The arrows in the category titles indicate the order each category processes firewall rules: from left to right, starting with the Ethernet, or Layer 2, category.
When network traffic travels through a firewall and the system finds a rule that matches the traffic parameters, the system enforces the rule and processing stops. When rules match, traffic is either allowed through or blocked, according to the configuration.
NSX-T Data Center administrators can manage rules in the Category Specific Rules view. The All Rules view shows all the distributed firewall rules in a single list, organized by their final order.
Figure 2 offers a list of firewall rules that ends with the default Layer 3 rule. The default Layer 3 rule is the last rule processed from the Application category, if no other rule matches a traffic parameter. The default Layer 3 rule allows all traffic to pass through the network. This makes the NSX deployment convenient because systems run as usual without restrictions imposed. If set to block traffic, NSX would immediately disrupt systems and applications.
The best practice is to use an allowlist approach, which configures the default rule to block all traffic other than that which is explicitly permitted. With an allowlist approach, you don't leave VMs unprotected by the firewall. However, if you forget to configure a rule, users might complain about an application not working, because you've unintentionally blocked its traffic.
How to configure firewall rules
NSX combines firewall rules into policies. The administrator can group firewall rules based on any given criteria. Figure 3 shows an example of a policy with a collection of rules for a tiered application, named Phoenix.
Firewall groups make it easy to identify firewall rules, disable an entire policy and configure a policy for date- and time-based enablement. Use the clock icon found in the title bar of the policy to achieve date- and time-specific settings.
The layout of firewall rules includes a source; a destination; the service used to process rules; and the allow, drop and reject actions. Generally, all firewalls work in this way. Additionally, the NSX DFW can also group VMs and use those groups in the source and destination fields.
In Figure 3, NSX uses policy groups for the Phoenix application's web servers, app servers and database servers. When you add a VM to the virtual infrastructure as a web server for this application stack, it adds the VM to the web servers group. The firewall rule designated for web servers then protects the VM independent of where the VM runs, its network location and its IP address.
The Applied To field, seen in Figure 3, automatically enforces firewall rules on the entire NSX distributed firewall, unless configured otherwise. This means firewall rules work for all VMs -- NSX places these rules on the VMs, even if the rules aren't required. Ensure the VM groups in both the source and destination fields are in the Applied To field, which guarantees NSX only places rules on VMs where needed.
The service and profile fields are additional unique features of the NSX DFW. The service field is the Layer 4 service definition of a service or port, such as TCP port 22 for Secure Shell (SSH) and TCP port 443 for HTTPS. The profile field is the Layer 7 firewall functionality where you can select predefined applications, such as SSH or HTTPS. When NSX DFW evaluates packets, it identifies applications by the packets and allows or blocks traffic based on the application ID, regardless of the port used. For example, when SSH is on port 80, not port 22, NSX DFW stills block the traffic.
Manage firewall rules
When you create firewall rules for either the NSX DFW or gateway firewall, they're available only when you click the Publish button at the top of the configuration screen. New or changed rules aren't active and won't affect the virtual infrastructure until you publish them.
The NSX interface contains a feature to revert any changes made to firewall rules. Every time an administrator publishes firewall rules, NSX saves copies of the rule sets automatically. You can evaluate and restore previously saved rules when necessary. Figure 4 is an example of saved rules made within a single day. Every dot in the graph represents a timestamp for saved firewall rules.
When you click on a dot, the graph shows the changes made in that version. Use this information to repair and recreate rules, as well as restore an entire rule set to a previous version when needed.
