One of my key topics in my Blackhat presentation "The Four Horsemen of the Virtualization Security Apocalypse" focused on today's lack of state-synchronized high availability/load-balanced solutions for security virtual appliances that offer the same functionality as their physical appliance counterparts.
I used an example from a vendor I didn't name in one of my slides to illustrate that if you attempted to replicate the options you have today in physical appliances in a virtual construct, you would not be able to (using this particular solution suite as an example.)
That vendor was Check Point and I was referring to their SPLAT-based virtual appliance.
The version that was available for ESX environments when I created my presentation offered no load-balanced HA capabilities whatsoever as stated in the release notes.
However, today I received the announcement of Check Point's VPN-1 Virtual Edition (virtual appliance.)
Based upon what I am reading in the administrator's guide, VE now includes support for ClusterXL HA FW/VPN state-synchronized load sharing across one or more ESX hosts.
This is a great first step in the right direction.
We should expect more solutions to start arriving shortly to address many of the issues I brought up as the current "state of the art," and this is a good example of that.
There are numerous caveats and limitations, many of which I spoke directly about in my presentation with many of them related to the interdependencies of network topologies, virtual networking and interaction with VMware's integrated HA/clustering solutions...which was one of the other key topics in my talk ;)
I'll update some of them as an addendum to this post shortly. Updated below.
You can find information regarding Check Point's VPN-1 Virtual Edition here.
Updated: If you read the release notes, you'll notice these little gems. I don't have the time to go through each of these limitations, but they're significant and go to the point that all things are not equal in V versus P:
- Interface bonding on the virtual machine running the VPN-1 Virtual Edition is not supported
- VMotion is not supported
- VPN-1 gateways in the Bridge Mode must have their internal and external interfaces connected
to port groups that are configured in promiscuous mode.
- VPN-1 gateways in the Bridge Mode are not supported with ClusterXL.
- Virtual machines may be connected to a maximum of four different virtual switches. This may
limit the number of virtual networks protected by a VPN-1 Virtual Edition machine. This
limitation can be overcome using VLANs.
I'll give them props for this one, though, given its refreshing honesty:
- VPN-1 Virtual Edition does not protect the VMkernel.