Portals offer a secure window into network applications

SSL VPNs make the user front end as friendly as possible.

Clear Choice Tests show how portals offer a secure window into network applications.

At the core of every SSL VPN device is a Web server that end users see every time they use the VPN. While most network managers have been willing to put up with clumsy or bare-bones Web interfaces on their switches, routers and firewalls, the story is somewhat different with SSL VPN devices. End users aren't as forgiving, and the appearance of the SSL VPN Web pages they see, commonly called the SSL VPN portal, can be crucial to the success of the deployment.

SSL VPN vendors were slow to figure this out, so SSL VPN devices have a pastiche of customization techniques. We looked at the official, documented techniques that each vendor supports for customizing the appearance of the portal pages that end users see.

"Official, documented" is an important distinction. When you come right down to it, most of these SSL VPN devices are running customized Web servers, and most of these devices have disk drives with files on them. Find the right file sitting on disk, edit or replace it, and you may find that you can customize the SSL VPN device to look however you want. Of course, you may lose your changes every time you install an upgrade or patch, but that's the cost of getting every last frame, table and color shade perfect. Of course, each vendor has a professional-services arm that would be happy to help you customize the appearance as much as you want.

When it comes to pure customization, F5 Networks, Juniper and Nokia sit head-and-shoulders above all the other SSL VPN devices we looked at. All three have fairly similar capabilities to define colors, icons and layout of the portal. With F5's FirePass 4160 and Juniper's SA-6000, the capabilities are even stronger because the portal layout can be defined on a per-group basis. Nokia's Secure Access System 500s only allows definition systemwide.

In pure customization and sophistication, F5's FirePass 4160 edges out its peers with capabilities such as support for WAP phones and PDAs (both can receive customized portals more appropriate to their capabilities), "beginner" and "advanced" portals to accommodate different levels of user, even within the same group, and the ability to individually control exactly which of its 25 portal elements appear, and in what order.

F5 has other little touches that show the level of thinking that went into the portal (see picture). For example, if your PC does not pass the end-point security scan, and you're restricted from using some resources, F5's portal includes a system warning telling you this (and, of course, you can turn that off). Other simple things, such as letting users control the layout of their own portal, are capabilities that show how polished the portal technology is without requiring any deep technical maneuvers from the network manager.

The difference between the level of control of the portal provided by F5, Juniper and Nokia within their respective management interfaces compared with the other SSL VPN devices is fairly dramatic. If portal customization without going underneath the covers is important to your deployment, these three products should be on your short list.

In each SSL VPN device, resources (such as Web pages) and portal links are somewhat distinct. The resource is defined by a series of hosts and URL paths, which may encompass a number of different Web servers, all working together to provide the end user with secure access to the Web application.

The portal link is simpler: It is a single point of "touchdown" to the Web application. If a link is defined, it normally should be shown to the user only if access is allowed (and not shown if access is blocked, to minimize end-user confusion). The separation and linkage of resources and portal links continues to be an area in need of refinement with the SSL VPN devices tested. For example, this has long been a weak area in Juniper's administrative interface, because it doesn't consider a resource an atomic object, meaning that managing access control and portal presence of any Web application may require redundant definitions and a lot of hand-crafted controls.

Juniper's approach to linking resources and portals is similar to that of Aventail and Nokia (see picture): A simple checkbox can add a link to the portal when a resource is being managed. Other vendors, such as AEP, Caymas, Check Point and F5, link the portal and resource definition more tightly. The loosest and most dangerous approaches come from Array and Nortel , in which the portal is completely disconnected from access controls. For very static SSL VPN deployments, this difference is irrelevant, but if you plan on making frequent changes to your SSL VPN, you won't want to define everything twice (and, in the case of Array, be aware that the portal and the resource definition are case-sensitive).

User customization

Another area that strongly differentiates SSL VPN products is support for end-user customization and personalization. Some products allow the end user to create bookmarks, rearrange icons and save passwords. Depending on your deployment, these can be unimportant or vital to end-user satisfaction.

Password storage is a good example of a fine detail that can mean a lot. For any Web resource behind an SSL VPN device, there is the possibility that authentication will be required. A Web server might have a single, static username and password that is shared among users (such as a group intranet page), or it might have per-user authentication (such as a Webmail server). Managing these usernames and passwords is a part of being a good SSL VPN device. If the user types a username and password to connect to a resource, the SSL VPN should be able to store that password (if the system manager has enabled this option) to minimize the need for users to be constantly typing in usernames and passwords while at remote locations. If the resource uses the same sign-on credentials as the SSL VPN itself, a "single sign-on" capability should be able to automatically log the user on (if the system manager has enabled the option) without making them type the same username and password twice.

Juniper's SA-6000 leads the way in this area, by providing the greatest set of options (see picture). Users can elect to have their password cached across sessions by the SA-6000. Passwords can be statically locked into resources. And single sign-on (passing a user's logon credentials to a resource) is supported. Nokia and Nortel support two of these options, while all the other devices we looked at have fewer capabilities. Nortel, however, supports storage of user password only when a Lightweight Directory Access Protocol server is available, because it does not store them locally.

Of course, passwords aren't the only issue when it comes to user customization. The appearance and order of bookmarks, as well as automatic launching of clients all fall into the realm of matters the system manager may want to put into the hands of end users. AEP, Array, Aventail and Caymas don't give end user any options, while the other devices we tested offer some or all of these options.

Fortinet's portal is unique in that, unlike every other SSL VPN device tested, there are no prepopulated links to resources. The user is expected to log in and create his own bookmarks and shortcuts to resources protected by the SSL VPN device. Unfortunately, in the version we tested, a bug blocked all ability to define bookmarks, severely limiting the functionality of the portal. Fortinet has another strange characteristic worth mentioning: Its SSL VPN portal cannot run on Port 443 (the manual specifically prohibits it). One reason SSL VPN is preferred to IPSec is the easy ability to always get out on Port 443, even from the most restrictive network, so we cannot understand why Fortinet's designers ran with this decision.


A few SSL VPN devices have the ability to act as multiple, independent servers. For example, you might want to have one URL for employee intranet access and a different URL for partner extranet access, with a different looking portal in each case.

Array, Aventail, Caymas, F5, Juniper and Nortel all aim to support portal virtualization. Array and Nortel, with their service provider experience, have the best virtualization of any of the SSL VPNs tested, completely slicing their systems up into independently manageable entities. F5 and Juniper, and to a lesser extent Caymas and Aventail, also provide a more "enterprise-oriented" kind of virtualization by supporting multiple virtual SSL VPN deployments within a single device.

< Previous test: Manageability | Next story: How we tested >

Learn more about this topic

Aventail aims to create secure IP conferencing


Sabre flies with SSL


Krispy Kreme turns to Whale Communication for SSL VPN gateway


Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2005 IDG Communications, Inc.