Ron Fuller, double CCIE, co-author of NSX Fundamentals Live Lessons and NSX Essentials book, dives into one really powerful aspect of NSX, the distributed firewall and how policies can be created.
The separation of network traffic has been fundamental to security compliance, for years we have been achieving this primarily through vlans and portgroups, switching and routing is done on physical devices, even if the traffic is on two virtual machines in the same esx host.
Unlike traditional firewalls NSX has the ability to run a centrally managed firewall in the kernel of each host. This is incredibly scalable, as performance depends the number of available hosts and their network cards, so firewall capacity increases with each additional host.
The distributed firewall manages east-west traffic, or traffic between virtual machines either on the same host or in hosts the same transport zone (the transport zone is a NSX construct that can span different clusters and distributed switches). VMware claim, that by embedding the firewall functionality in the kernel, near to line rate throughput can be achieved. For example put 5 hosts with 2x10GB cards together and you have a firewall capable of managing a total of 100 GB of east-west traffic. In another session at VMWorld I saw a demo of 70 GB throughput between vms in two separate hosts using 100 GB cards.
Traditional firewalls have used 5-Tuple rule sets (Src IP, Dst IP, Src Port, Dst Port, Protocol) with the default gateway typically the limit of the firewall policy.
NSX segmentation although able to use 5-tupple sets, also leverages intelligent integration with vCenter to perform firewall policy based on a set of grouping concepts.
- Operating System
- Machine Name
- Application Tier
- Regularity Requirements
- Security Posture
The move away from 5-tuple rules is clearly a huge paradigm shift from grandfather firewalls, and will require a whole new skill set to work at scale.
As a simple demonstration of the ability to group and automatically assign vCenter objects to Security Groups. In the example below membership of a Security Group is based on on the VM Name and a NSX Security Tag*, NSX will add all objects that meet these criteria to the Group as well as adding any newly created objects. In turn the Group is assigned to one or more policies.
*A suggestion that I heard in one of the NSX sessions was when assigning dynamic membership of Security Groups use two elements, for example both name and security tag, this would avoid issues in fenced environments where machine names are duplicated
NSX Distributed Firewall Policy Creation Methods
For example in transitioning a brownfield site, modelling after existing firewalls is not a recommended strategy, primarily because none of the above benefits will be realised, but additionally traditional firewalls are more oriented to north-south traffic rather than micro-segmentation of east-west traffic
The following graphic shows the effort level required in analyzing traffic to establish firewall policy.
This is the clear favorite, although a separately licensed product, you can request a free Network Assessment from VMware here. This is really worth doing if you are considering the move to SDN, keep in mind only a distributed switch is required to capture traffic with vRNI.
vRNI combines and IPFIX/Netflow with vCenter/NSX objects, VLANs, and outputs this in graphical format or cvs. vRNI can automate the creation of Security Groupings and recommend Security Policies / Firewall Rules.
Traffic flows and be analyzed and filters such as port and src vm can first be used to give a very clear indication of traffic flows.
Focusing on a specific VLAN/VXLAN allows inspection of traffic on a single flow or all flows.
vRNI then provides recommendations on firewalls.
These recommendations should be vetted by the firewall admin before being published.
vRNI can be taken for a test drive using demo hands on lab here
NSX Distributed Firewall Policy Creation Tips
There are multiple ways to create policy, and the choice of method should be given careful consideration.
The API has been used to great affect to create and manage a large numbers of rules.
Suggested tips when using the API
- Not all fields specified in the official API guide are needed
- Direction should be set to in or out
- If no source or destination is specified the API will assume ANY
- AppliedTo is a critical field, indicate on what object the rule is applied
- Create an ANY ANY rule at the top of the policy while importing mass creating rules
- Establish a clear naming convention for objects and services used in rules
Possible Issues when using the API
- Enable ARP snooping as some VMs may not have vmtools, and NSX needs to know the VM IP address
- If a deleted VM is referenced in a dFW rule, the dFW may become out of Sync and manual cleanup of the rule is required
- The API does not correctly place a New Section, or Rules in a specific location, this can be overcome by pushing the entire policy or entire section
- Save backup of policies as it is easy to DELETE everything by mistake through the API
- Generation ID numbers mean that if multiple admins are pushing rules, conflicts can arise and one admin may not have configuration correctly set – one admin at a time
This session is available for viewing here, if the link doesn’t work search for SEC7568