Home > Virtualization > High Availability Security Virtual Appliances…Check Point Steps Up

High Availability Security Virtual Appliances…Check Point Steps Up

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
    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.
Categories: Virtualization Tags:
  1. No comments yet.
  1. No trackbacks yet.