Product Group Tests

SSL VPNs (2005)

by Jon Tullett September 23, 2005
products

GROUP SUMMARY:

We were delighted to see that all the vendors taking part in this group test have made great strides to improve their products, but there has to be a winner. We awarded Best Buy for this group to Array Networks' Array SPX 5000 for its excellent set of features and unsurpassed scalability. While the interface could use some work, this is a very strong enterprise SSL VPN performer. An excellent interface and its use of endpoint security tools wins the Aventail Smart SSL VPN a Recommended award. Although not as beefy as the SPX 5000, it is a well-constructed package that will suit many different sizes of organizations.

Not long ago, these products were geared to extending specific applications to an enterprise's remote users. But Jon Tullett is pleasantly surprised at how vendors have rounded out their offerings

Not long ago, SSL VPN products comprised quite specific templates for known applications such as extending messaging systems like Microsoft Exchange, or thin client front-ends like Citrix. Endpoint security was clumsy, when it was present at all, and tunneling support left much to be desired.

But in the past couple of SSL VPN tests, we have seen marked improvements industry-wide. Part of this is down to much better web support from the backend applications, making the SSL front-end much easier to integrate, but a large part seems to be simply a recognition by vendors (and customers) of what the core features need to be, and how they should be addressed.

As a result, we were again impressed by the technology on offer by the participating vendors. The products were much more consistent than they have been before, with the basics covered well and most offering enterprise options for high availability, and centralized policy management.

We tested them for suitability in large enterprises, with internal web applications, thin clients running legacy systems, and Exchange email servers. With hypothetical users logging in from home, from the road and from public internet systems, we wanted to control access based on the user's credentials as well as location. So we looked closely at the granularity of authentication schemes, with an eye for failure states and how they could be accommodated.

However, there were still areas where some outperformed others, especially in scalability, support for multiple platforms, delegated admin, and ease of management.

In most cases, we found the test products supported a wide range of authentication techniques, covering Radius, SecurID, LDAP, local usernames, and NTLM. Some went much further, but the core was consistent across the test.

Application support was also better than we expected. Few of the products offered more than basic proxying and forwarding, but we had no problem extending web applications to remote users.

Endpoint security is one of the grails of remote access. Two needs are paramount. First is controlling the initial state of the client. Is it secure? Does it have AV software installed? Is the patch level acceptable? Second is the final state of the system – cleaning the cache, removing temporary files.

In general, we found endpoint agents would perform adequately under ideal conditions, but poorly otherwise. It is usually just too easy for a user to break out of the sandbox. If you really want fully enclosed control over the remote desktop, you might turn instead to Citrix, Microsoft Terminal Services or similar thin-client options. Some of the agents were simply obstructive to the end user, which we feel pushes the security compromise a step too far.

Tunneling support under SSL is much better supported nowadays. Setting up SSL/TLS tunnels is straying into IPsec territory, and vendors have had some tough nuts to crack with protocol problems, performance and split tunneling (where certain traffic is redirected via the VPN, but the rest sent across the default gateway). Some imaginative workarounds have been seen to tackle these problems in the past, but most now simply rely on the locally-residing agent to do the client setup.

Because the feature set of these products has advanced so much, it was inevitable the role of the client software would also grow. From pure browser-based SSL front-ends, every product now uses an agent for endpoint control and tunneling at a minimum. As a result, the claims of "client-less" SSL VPNs are now outright false, although you could argue that the browser actually counts as a client.

But the important factor is that client software implies a degree of reliance on the local system, so we were disappointed to see that many products limited feature support to Windows and Internet Explorer. Organizations with Macs or deployments of alternative browsers may have to think carefully about their choice of SSL VPN. IPsec proponents would be quick to point out that these platforms have seamless IPsec clients today, but we are confident that as vendors support Java clients over ActiveX controls, these concerns can be addressed.

Choosing an SSL VPN used to mean carefully deciding which applications you wanted to extend, and then trying to find a product to support them. This has evolved to checking client support and integration into endpoint security policies, but the industry has achieved real depth of application support. IPsec is still the best tool for site-to-site communication, but extending applications to remote users via SSL can be a quick win for any administrator.

SC Webcasts UK

Sign up to our newsletters

FOLLOW US