Exclusives Featured Tech Field Day Events

Microsegmentation: Worth Implementing Over a Host-Based Firewall?

Following the acquisition of Nicira by VMware and the subsequent release of NSX in 2013 one of the primary use cases that caught on within the enterprise was microsegmentation. The idea of wrapping a security policy around a VM regardless of location and current networking constructs is an attractive one. This is accomplished by means of a firewall that exists within the hypervisor and sits between the vNIC of the Virtual Machine and the vSwitch that it is connected to.

The Case for Microsegmentation

Inevitably when companies explore the prospect of microsegmentation, a common question arises. Why bother using a firewall at the hypervisor level when the VMs themselves have a host based firewall built into the OS or you could just use a hardware firewall to segment workloads? The latter is a pretty simple question to answer. Using a hardware based firewall to segment all your workloads adds significant cost. A very expensive, very powerful firewall would be needed to process all east-west traffic in a data center. Additionally the amount of administrative overhead required to provide such segmentation is significant and will cost an organization a high amount of working hours to design, build, and maintain.

As for the question of why not used a host-based firewall, the answer is a bit more nuanced and multi-faceted. This was explored at length during VMware’s recent presentation at Security Field Day. During the conversation Geoff Wilmington of VMware and the Security Field Day delegates explored the reasons and advantages of utilizing the hypervisor based firewall.

Use Cases and Advantages

Together Wilmington and the delegates identified many advantages that their hypervisor firewall has over a host based firewall running in a VM.


The security of your applications is the key driver for deploying a firewall in the first place, but security OF the firewall itself establishes the case for a hypervisor based firewall.  If an attacker were able to gain control of a VM or other endpoint, they now have the ability to disable or modify security measures that are used within that VM such as the native firewall or AntiVirus. By moving the firewall outside of the VM it is no longer directly exposed to an attacker who may gain control of a VM. The only way to affect the firewall at that point is to gain control of the hypervisor.


Most modern operating systems have their own firewall that can be leveraged for security. Learning the operating model and successfully executing a security plan for each individual OS and its firewall at scale can be cumbersome and difficult. Yes, you can manage all of your Windows VMs and their firewalls with Group Policy. Pretty soon though, you will have several Group Policy Objects (GPOs) and many may have conflicting policies or not be properly enforced on the correct OU or group within Active Directory.  All of a sudden the protections you thought you had put in place may be nonexistent.

What about all of your Linux VMs? Do you want to try to manage iptables at scale? There are many configuration management tools available that will let you do this. I have experienced this myself and would prefer to have not written many Puppet manifest files to ensure correct security policies are enforced on the correct VMs. The ubiquity of control given by NSX means that you do not need to learn and manage multiple ways to enforce security policy for all of the different operating systems in your infrastructure. Everything is managed in one console on one large, distributed, virtual firewall.


As previously mentioned, utilizing the NSX firewall rather than a physical firewall to segment traffic will greatly save on hardware costs in the data center. It will also save on the performance hit a VM would take when implementing a complex firewall ruleset. Moving to the hypervisor level, where traffic is evaluated in the kernel, reduces the load on the VMs. While it is true that this results in a performance hit on the hypervisor itself, it’s worth noting that the firewall’s performance will scale with the infrastructure itself. As the number of VMs in an infrastructure grows, so too will the compute power that is running them. The virtual datacenter and its clusters scale out as additional hosts are added. The distributed firewall running on each of them scales out as well.


Much in the way that moving the firewall out of the operating system prevents an attacker from making changes, it also enables greater governance and control within the organization. How often have you seen a developer or systems administrator disable the firewall in a VM for testing or troubleshooting an issue, only to see that it was never reenabled? The workflow for changing security policy would likely result in higher effort being devoted before asking a security team to change the policy on the hypervisor.

Ken’s Conclusion

I remember in the early days of NSX when a VMware SE told me that one of the most popular use cases for the product that they did not expect was microsegmentation. Well its been several years now, and it’s clear that VMware has leaned in completely to the microsegmentation use case. In fact, I think it would be fair to say it is the most compelling use case for the product. The reasons for adopting it are so varied that adoption of the product can be driven by many factors at the same time. In an age where just about anything from a VM, to a network device, or any number of IoT devices can be used as an attack vector, microsegmentation is practically a necessity and tools like NSX are an excellent way to achieve a stronger security posture.

About the author

Ken Nalbone

Ken is an IT infrastructure professional with over 15 years experience. His areas of specialty are the software-defined data center and cloud technologies. In addition to being a writer for Gestalt IT, Ken is an Event Lead for the Cloud Field Day and Tech Field Day series of events.

Leave a Comment