How We Tested: SSL VPN Appliances | eWeek

How We Tested: SSL VPN Appliances

Written By
Andrew Garcia
Andrew Garcia
May 10, 2004
2 minute read
eWeek content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

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.

/zimages/1/28571.gifClick hereto 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.

/zimages/1/28571.gifCheck outeWEEK.coms Security Centerat http://security.eweek.com for security news, views and analysis.
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page:http://us.i1.yimg.com/us.yimg.com/i/us/my/addtomyyahoo2.gif

eWeek Logo

eWeek has the latest technology news and analysis, buying guides, and product reviews for IT professionals and technology buyers. The site's focus is on innovative solutions and covering in-depth technical content. eWeek stays on the cutting edge of technology news and IT trends through interviews and expert analysis. Gain insight from top innovators and thought leaders in the fields of IT, business, enterprise software, startups, and more.

Property of TechnologyAdvice. © 2026 TechnologyAdvice. All Rights Reserved

Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.