Network World
Thursday, July 9, 2009
DNSstuff.com
Get information about your IP
IP Information
50+ On-demand DNS and network tools
Clear choice test: SSL VPNs dissected
Introduction | Complete scorecard | Test archive
Inside this test package
SSL VPN Product-by-product summary
SSL VPN Tests by Topic

Getting scalability, high availability from SSL VPN wares

Most vendors tested keep things up and running.

Review  By Joel Snyder, Network World, 12/19/05

Any network architect building a production SSL VPN service will want to make it as reliable and scalable as possible. We took a whirlwind pass through the high-availability and scalability capabilities of the 11 products in our test to get an idea of the spectrum of options.

Google OS could put squeeze on other flavors of Linux
07/09/09
Much of the discussion around Google's new PC operating system has focused on a looming battle with Windows, but the biggest losers could be other Linux OSes that have been enjoying some moderate success on netbooks, industry analysts said.

Google lists HP, Acer among Chrome OS partners
07/09/09
Google is already working with several companies to develop devices around the new Chrome OS, including Hewlett-Packard and Acer, the company said in a blog post late Wednesday.

Cyber attack in South Korea set to resume, says AhnLab
07/09/09
A denial of service attack that took down some of South Korea's highest profile Web sites on Wednesday is set to resume Thursday evening, according to computer security specialist AhnLab.

F5 Networks was unable to participate in this portion of our test because of logistical problems, and because SonicWall and Check Point do not have built-in high availability, they also were not tested. However, we did evaluate the features of all three in this section.

We found several types of high-availability and scalability features in our testing. High availability included both active/passive (commonly called master/slave) and active/active support. To support scalability, a few products included internal load-balancing technology, but most required external load balancers. Products requiring load balancers generally supported scalability with some form of configuration sharing.

High availability is a simple idea: The service should survive loss of some component, typically the SSL VPN gateway itself. But high-availability measures present a few complications to SSL VPN deployments. It's not rocket science, but it's not easy to do right, either, as our testing showed. In high availability (and in scalability), one of the problems to be solved is configuration sharing, making sure that any change on one device is then propagated to all of the devices so that the configuration is completely consistent.

High availability is usually handled with a virtual IP address, one that represents the highly available service. The virtual IP address usually is shared across a pair of SSL VPN devices; one of the two is the active master responsible for all traffic to that address, and the other is the passive slave, in communication with the active device and ready to take over the virtual IP and traffic in case of failure of the master. In a single data center, high availability focuses on dealing with the failure of either a single device or connectivity to that device. You start by making sure that the virtual IP address is always available by building a capability to move the virtual IP from one system to another when there is a problem.

Chart: HA and scalability is not one size fits all

In the event of a failure, moving a virtual IP one node to another is pretty basic stuff, as is the configuration sharing between the master and slave needed to make it work reliably.

What's more difficult is making any failover seamless to the end user. As with any high-availability scenario, the problem lies in how to maintain the state of the end-user's session in the event of a device failure. With SSL VPN devices, there are two main types of sessions - Web-based SSL VPN and network extension/port forwarding SSL VPN - with different high-availability issues to consider.

Web-based applications tunneling through an SSL VPN have two types of state associated with them that are important to high availability. All SSL VPN devices generate a cryptographic cookie - usually called a session ID or session cookie - that is used to reauthenticate a user's browser every time it comes back for another Web page or image. Without that state information, the SSL VPN device would have no secure way to keep track of the user. This is why cross-site scripting attacks are so frightening to SSL VPN devices, if someone can steal your session cookie, he may be able to impersonate you until your session ends.

The second type of state information is the cookies (such as an Amazon.com shopping spree or, more commonly, an Outlook Web Access session) that are part of a user's session. Web sites doing any kind of session-oriented application (such as a Web-based e-mail session) use cookies to keep things in order. For example, when you use Outlook Web Access, a cookie called "sessionid" is stored in your browser, so that as you go from page to page, the Outlook Web Access server knows who you are and what you have been doing. Secure SSL VPN boxes don't actually pass those cookies directly to the end user's system, because they might then be left lying around for the next user to use or abuse. Instead, they are maintained on the SSL VPN device. Not all SSL VPN devices do that, but the most security-focused use this technique.

When a high-availability event occurs (such as an involuntary power cord attenuation), the user's cryptographic cookie needs to be in place on the backup SSL VPN device for everything to work smoothly. In our testing, Aventail, Caymas, Fortinet, Juniper and Nokia all handle this correctly. With AEP, Array and Nortel, the user must reauthenticate to the SSL VPN after a high-availability event occurs. (Nortel says it is solving this problem in its 5.5 release, due in January.)