How do you compare virtual firewalls before you buy one?

To compare virtual firewalls, judge placement, inspection depth, throughput on your hypervisor or cloud, rule management and logging, not the feature list. A virtual firewall runs as software in a VM, container or cloud service, so test it in your environment with your traffic before choosing.

This guide describes criteria and does not rank products.

What is a virtual firewall for?

NIST SP 800-41 points out the original problem: network activity that passes directly between virtualized operating systems within one host cannot be monitored by an external firewall. Some virtualization systems offer built in firewalls or accept third party software firewalls as plug-ins. NIST wrote that this was a relatively new area, which is a useful reminder that the guidance there is from 2009 and the products have changed a lot.

More recently, NIST SP 800-215 notes that a next-generation firewall can be deployed as an appliance in a data center, as software running in a VM in a cloud, or as a cloud service. So the form factor is a choice, not a different category of capability.

Which criteria matter?

Placement. Does it see east-west traffic between workloads, or only traffic crossing the edge? Many breaches move sideways after the first foothold, so internal visibility matters.

Inspection depth. Packet filtering, stateful inspection, deep packet inspection and application awareness are different layers. SP 800-215 describes deep packet inspection as examining payloads as well as headers, and NGFW features such as TLS decryption and intrusion prevention. Decide which you need and what you will pay in latency for each.

Throughput and scaling. Vendor numbers are measured under ideal conditions. Measure with your packet sizes, your rule count, and with inspection features switched on. Check how it scales: bigger instance, more instances, or both, and whether state is shared between them.

Rule management. Can rules be written as code, reviewed, versioned and rolled out through your pipeline? Can they refer to workload tags rather than IP addresses that change?

Integration. Does it work with your cloud or hypervisor networking, your identity provider and your logging stack without custom glue?

Logging. Are logs complete, exportable and timestamped consistently? A firewall that cannot explain a drop is hard to operate.

Failure behavior. What happens when the instance fails or is overloaded: does traffic fail open or fail closed? Is that configurable?

A constructed example

A team has two candidates. One has a longer feature list. In a two day trial they replay a day of captured traffic. Candidate A, with all inspection features on, cuts throughput below their peak load. Candidate B meets peak load but only inspects TLS traffic it can decrypt, and half their internal services use mutual TLS it cannot terminate. The feature table showed neither problem. The test did.

What should the trial include?

Treat the trial as a small project with pass and fail criteria set beforehand. Include a rule change through your normal deployment process, a simulated instance failure, a log export into your monitoring system, and one deliberate policy violation that should be blocked and recorded. Time how long an engineer needs to explain one dropped connection from the logs.

How to check or apply this

1. Write your traffic flows: north-south and east-west, with volumes.
2. Choose the inspection layers you need and which you can skip.
3. Define pass and fail numbers for throughput, latency and failover.
4. Replay representative traffic with inspection features enabled.
5. Deploy a rule change through your pipeline and time it.
6. Check logs for completeness and export format.
7. Record total operating cost, including staff time, not only license cost.

Quick check

Sources

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• NIST SP 800-215, Guide to a Secure Enterprise Network

Last reviewed: 18 October 2026.