Rational Survivability

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.

/Hoff

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
  with ClusterXL.
• 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.