How We Tested: SSL VPN Appliances

By Andrew Garcia  |  Posted 2004-05-10 Print this article Print

Here's how eWEEK Labs tested four SSL-based VPN appliances.

The SSL VPN products eWEEK Labs tested offer multiple network interfaces, but we chose to deploy each with only one interface configured. This minimized the exposure of system assets to the Internet.

Click here to read the reviews.
We placed each product, in turn, into the local test network behind SonicWall Inc.s Pro 330 firewall. We configured the firewall to pass only inbound Secure Sockets Layer traffic to the device under test. From this location, the VPNs had ready access to network applications and authentication services.

None of the VPNs we tested comes with redundant power supplies, so clustering units for high availability will be important for enterprise use.

The vendors of the VPNs that we tested each provided two SSL VPN units for testing as high-availability clusters. We evaluated system responsiveness when one member of a cluster failed, ease of cluster setup and cluster synchronization capabilities.

Each SSL VPN cluster was configured to authenticate users to two separate external resources. Half our test users authenticated to Active Directory via LDAP, and half authenticated to Funk Software Inc.s Steel-Belted RADIUS server installed on a Windows 2000-based server.

We configured each product pair to offer remote access to a variety of common network applications, including intranet Web servers, Microsoft Corp.s Outlook Web Access, Windows Terminal Services, Common Internet File System sharing, Secure Shell and Telnet.

Each product we tested offers a range of client solutions. We configured access to our services with the goal of minimizing the need for the administrator to touch the remote machine, utilizing clientless or thin clients when possible.

We delegated access to network applications according to Active Directory group membership, taking special note of the ease with which we could import this group information. We crafted a series of access control policies for network services based on this group membership. Users authenticated via RADIUS were given access to only intranet Web servers.

We tested remote application access from both Windows and Linux clients.

With Windows 2000-based clients, we used Internet Explorer 6 Service Pack 1 and Mozilla 1.6, each with Sun Microsystems Inc.s Java Plug-In 1.4.2_04. The Linux clients were Java-enabled Fedora Core Linux workstations running Mozilla 1.6.

Check out eWEEK.coms Security Center at for security news, views and analysis.
Be sure to add our security news feed to your RSS newsreader or My Yahoo page:  
Andrew cut his teeth as a systems administrator at the University of California, learning the ins and outs of server migration, Windows desktop management, Unix and Novell administration. After a tour of duty as a team leader for PC Magazine's Labs, Andrew turned to system integration - providing network, server, and desktop consulting services for small businesses throughout the Bay Area. With eWEEK Labs since 2003, Andrew concentrates on wireless networking technologies while moonlighting with Microsoft Windows, mobile devices and management, and unified communications. He produces product reviews, technology analysis and opinion pieces for, eWEEK magazine, and the Labs' Release Notes blog. Follow Andrew on Twitter at andrewrgarcia, or reach him by email at

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel