A virtual firewall is firewall software that runs in a virtualized or cloud environment instead of on a dedicated appliance. It filters traffic between virtual machines, networks and containers, including east-west traffic that never crosses a physical device. It is configured and tested like any other firewall.
Why do virtual machines need their own firewall?
In a physical network, traffic between two servers usually passes a switch and maybe a firewall. On one hypervisor, two virtual machines can talk through a virtual switch without leaving the host. A perimeter firewall never sees that traffic. NIST SP 800-125B, on securing virtual network configurations, covers this problem and the controls for it.
Where can a virtual firewall sit?
There are three common placements.
- A firewall VM. A firewall vendor image, run as a guest, that traffic is steered through. Easy to understand, but it needs routing that forces traffic to pass it.
- A hypervisor level feature. Filtering applied at the virtual network interface of each machine, outside the guest. A compromised guest cannot turn it off from inside.
- A cloud control. Security groups, network ACLs and similar services that act as stateful filters on virtual interfaces. You do not see an appliance, but the function is the same.
NIST SP 800-41 Rev. 1 describes firewall types and policy in general. Its guidance on default deny, documented rules and testing applies to all three.
What does it see and miss?
It sees addresses, ports and protocols, and sometimes application data if it inspects deeper. It does not see traffic that bypasses it, such as a VM given a second interface on a different network. It also cannot judge traffic inside an encrypted tunnel without decrypting it.
A constructed rule review
An engineering team has a web tier, an application tier and a database tier in one cloud network. Their rules say "allow all from the application subnet to the database subnet". A review finds the application tier only needs TCP 5432 to two database addresses. The team narrows the rule to that, then notices the web tier can also reach the database directly, which was never intended. They remove it. Two small edits, and a stolen web server no longer has a path to the data.
What mistakes show up most often?
Three come up again and again. First, rules copied from an old physical network that no longer match the new layout, leaving gaps and dead entries. Second, a firewall VM that traffic can route around, because nothing forces packets through it. Third, no one owns the rule set, so changes pile up with no explanation.
A useful habit is to write the business reason in each rule's description. When the application is retired, the rule can be found and removed instead of lingering for years.
How to check or apply this
- Draw the allowed flows between tiers on one page before writing rules.
- Set default deny, then add only the flows on the page.
- Put each rule's owner and purpose in its description.
- Test from a machine in each zone, trying flows that should fail as well as ones that should work.
- Export rules on a schedule and diff them to catch drift.
- Review for unused rules every quarter and remove them.
- Make sure new interfaces on a VM inherit the same policy.
Quick check
Is a virtual firewall less secure than a hardware one?
Not by nature. Security depends on rule quality and on whether traffic is forced through it. Hypervisor level enforcement can be harder for a compromised guest to evade.
Are cloud security groups virtual firewalls?
Functionally yes. They are stateful filters applied to virtual network interfaces, managed through the cloud provider instead of a separate appliance.
Sources
- NIST SP 800-125B, Secure Virtual Network Configuration for Virtual Machine Protection
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
Last reviewed: 18 October 2026.
