SDN/SDDC Retreat in Miami, Florida (November 4th-6th)
Separate SDN hype from real life!

Virtual Firewall Taxonomy

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.


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).


  1. And many of physical firewalls can be virtualized. So one physical firewall can have multiple virtual firewalls inside. They all have their own routing table, rule base and management interface.

    This is also another meaning for virtual firewalls.

  2. Hello,
    You said: "the moment you start looking deeply into the packets, the only hardware offload you can do is TCP checksuming and segmentation/reassembly"

    Can you take a look to Palo Alto Networks technologies and make some comments on that matter?

    1. Nevot, if you're associated with Palo Alto Networks in any way and think I misrepresented what they do, put me in touch with the technical people that would correct my myopia.

      If this is a generic "that might be interesting" type of comment - thank you, will put it on my to-investigate list (but that list is long and getting longer).

    2. I cannot comment on nevots affiliation, I am not involved with Palo Alto however. But I have seen colleagues using Palo Alto boxes (don't ask me which ones), and they can do pretty impressive stuff. As far as I understood, the boxes are L7 firewalls which do pattern matching on packet contents in hardware and virtually in line speed. They have rules for most protocols, eg. you can have rules that deny certain operations of the SMB protocol.

      So yes, I think Palo Alto is pretty interesting :). Since I only know the comments on Palo Alto by my colleagues, I am also interested in what you think about them.

      Btw the guy starting the company (Nir Zuk) started Netscreen before (now part of Juniper), AFAIK they did the first implementation of stateful packet inspection in hardware. I have worked with Netscreen boxes before, and I like them, so I am probably a little bit biased.

    3. FWIW: Nir Zuk started up OneSecure, which was acquired by Netscreen for their IPS technology in 2002. Netscreen's CTO at startup was Ken Xie, who went on to start Fortinet after the Juniper deal.

      Both Juniper IPS and many parts of Fortinet seem similar to Netscreen of old.

  3. There are at least some open source "bump-in-the-wire inter-VLAN virtual firewalls", i think for example pfSync in transparent mode fits into this category.

  4. No, not related to PA, only user.
    That is, they say they are doing stateful inspection and application recognition on hardware (FPGAs), and I only wanted to know your opinion, related to your previous statement.

    Put it to your list. It may be great reading a post about them.


  5. Dont forget firewalls that run in IOS

  6. Well we just did a PoC on a couple of PA-5050´s.

    They failed because.

    -No IPV6 hardware acceleration and broken IPV6 if over 50% CPU ( will get fixed in 5.0)

    -Very high cpu usage if you have alot of HTTP traffic.
    We had about 65% cpu usage for 1 gbps of traffic.

    -Support didnt work. It took them over 5 weeks to identify a problem with Syn Cookies. Over 50% cpu and syn cookies enabled would result in packet drops.

    This is just the list with the major issues we had.
    The Palo Alto platform is not wirespeed for sure. If somebody wants all the data please contact me.

    So right now we are running FortiNET 3950B in a PoC with 3 XH0 Securti engiens.

    FortiNET actually do alot of IPS in ASICS or FPGA.

    We are only seeing 6% CPU with the same amount of traffic.

    The Palo Alto gui feels very modern compared to the FortiNET but the engineering is not very solid compared to FortiNET.

  7. Check out Embrane solution, I used it and for my tasks nothing is lack. I think it's a perfect multi tenant virtual and scalable solution.

  8. I'm amazed at all the limpy, barely-there virtual security products that try to pass for firewalls -- e.g., vShield Edge, vShield App, and Cisco's VSG. These are are glorified L2/L3/L4 packet filters, barely able to tell an ARP from an NDP and with a "kitschy UI in front of Linux iptables" (thanks Ivan!). Consider their Application layer gateway (ALG) support:

    vShield Edge: FTP
    vShield App: FTP, Microsoft RPC, Linux RPC, Sun RPC, Oracle TNS
    Cisco VSG: FTP, RSH, and TFTP

    Shouldn't intra-tenant security have more protocol awareness than a perimeter firewall? E.g., infrastructure protocols (NFS, CIFS/SMB, DNS, LDAP, MS RPC with UUID discrimination), application protocols (HTTP, Oracle, SIP, SMTP, RTSP), and the app data (SQL, SOAP, XML). Now, this veers dangerously into WAF and IPS territory but, IMHO, what's the point of doing intra-tenant security without understanding the apps?

    vShield App might have a nice GUI, but it's actual security protection is no better than L4 ACL's on the free Nexus 1000v combined with the firewall built-in to every modern OS. If it was my security budget, I'd start with that, add a solid perimeter firewall, and then throw every remaining dollar at badass IPS and WAF vendors -- SourceFire, Imperva, TippingPoint, etc.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.