Based on readers’ comments and recent discussions with fellow packet pushers, it seems the marketing departments and industry press managed to thoroughly muddy the virtualized security waters. Trying to fix that, here’s my attempt at virtual firewall taxonomy.

Virtual versus physical

While numerous vendors sell dedicated firewall hardware (clearly physical firewalls), most of those boxes have an x86 chipset inside. Some of them might have dedicated forwarding/filtering hardware but the moment you start looking deeply into the packets, the only hardware offload you can do is TCP checksuming and segmentation/reassembly.

Then there are software-only vendors that expect you to buy an off-the-shelf server and operating system platform on which you’ll run their software.

Finally, companies like Linerate Systems have multi-tenant firewalls running on commodity x86 hardware.

All the above-mentioned products are physical firewalls because regardless of how they’re implemented, there is no other software running on the same platform. You can have endless debates whether a firewall running on a dedicated operating system is safer than the one running on top of Linux, but please keep them to yourself.

A virtual firewall, on the other hand, is software running as a hypervisor kernel module or in a VM on top of a general-purpose hypervisor. The fundamental difference between a virtual and a physical firewall is that the virtual one shares compute, networking and storage resources with other (potentially malicious) VMs.

Chris Hoff wrote a great blog post describing the security aspects of virtual and physical firewalls, so I’ll not go down that particular winding path. Let’s just say that what matters most when dealing with this particular can of worms is the religious persuasion of your security auditor.

And now for the real stuff ...

Transparent or routed?

Physical firewall functionality comes in two flavors:

• Inter-subnet (inter-VLAN) firewalls that perform packet filtering and IP routing.
• Transparent (bump-in-the-wire) firewalls that perform packet filtering and layer-2 forwarding. In their simplest incarnation, they have two interfaces and send accepted traffic received on the inside interface to the outside interface and vice versa.

Virtual firewalls also come in two flavors: inter-VLAN (routed) firewalls and NIC-level firewalls, which are attached directly in front of a VM NIC, filtering traffic being sent from and received by individual VMs.

I haven’t seen a bump-in-the-wire inter-VLAN virtual firewall yet, but should I stumble upon one I wouldn’t be surprised; the vendors tend to explore all the nooks in the solution space.

Inter-VLAN virtual firewalls

These firewalls typically run in a multi-vNIC VM (with every virtual NIC being assigned to a different security zone).

In the vanilla inter-VLAN virtual firewall category we have vShield Edge and Vyatta firewalls (and other products with kitschy UI in front of Linux iptables). Cisco’s vASA is a tiny bit smarter; it can do vPath service chaining in VLANs where it’s deployed together with VSG.

These firewalls can work over any virtual networking technology – apart from vASA (which relies on vPath) they’re not aware of the technology used to implement virtual networking – all they know is that someone connected their virtual NICs to different port groups (to use the vSphere lingo).

NIC-level firewalls

This is an interesting new category of firewalls – they are (logically) sitting in front of individual VMs, inspecting all the VM traffic (like physical firewalls, subnet-level virtual firewalls inspect only the traffic entering and leaving a virtual network segment).

The simplest product in this category is XenServer vSwitch Controller, which uses OpenFlow to download static ACLs to Open vSwitch residing in Xen hypervisor.

Most other NIC-level firewalls rely on VMware’s VMsafe Network Security API (lovingly known as dvFilter) – a kernel module intercepts vNIC traffic and processes it within the kernel module or within a VM running in the same vSphere host.

Juniper’s vGW is a dvFilter-based firewalls that does all the filtering in the kernel module (the VM that still has to be running in every vSphere host is doing only configuration, management and logging tasks).

vSphere App/Zones is another dvFilter-based firewall, but it does the actual filtering in the VM, so all the inspected traffic has to traverse the firewall VM, resulting in significantly reduced performance as compared with vGW.

Finally, there HP’s TippingPoint that uses a dvFilter-based solution to intercept the VM traffic and send it to an external TippingPoint IDS/IPS appliance.

Cisco’s VSG is slightly different – it uses a VM for traffic inspection, but doesn’t require a firewall VM to be running in each hypervisor host. VSG uses service insertion (vPath) implemented in the Nexus 1000V switches to get access to VM traffic. It can also insert shortcuts in the Nexus 1000V switches, resulting in higher performance.

Summary

A picture is supposedly worth more than a thousand words. Here it is:

More information

Check out my virtualization webinars (all of them are included in the yearly subscription).