We invited 14 vendors to participate in our tests of SSL VPNs: Array Networks, Aspelle, Aventail Corp., Citrix Systems, F5 Networks, Neoteris, Netilla Networks, Nokia, Novell, Nortel Networks, PortWise, Rainbow Technologies, SafeWeb and Whale Communications. However, Novell declined, saying the test crossed too many products lines (this has never been a problem before). Aspelle never confirmed its participation, and Citrix said it couldn't spare hardware. F5 begged off, saying it had just completed the acquisition of URoam and was between product launches. Netilla also claimed to be between product revisions, and Rainbow just wasn't a fit for our tests. Still, we ended up with an excellent list of contenders.
We awarded Neoteris Access Series 5000 our Editor's Choice because it provides a full-featured product with a wealth of configuration options, good authentication and access-control features, and sound application support. Note that NetScreen Technologies has just announced plans to acquire Neoteris. It will be interesting to see how the product develops under NetScreen's stewardship.
We wanted to test products that provide secure access to Web and non-Web applications over SSL. In addition, the product had to support 500 concurrent users with varying access and application needs, and support up-to-date browsers, specifically Netscape Navigator and Internet Explorer.
Because many of the applications your remote users need to access are not Web-enabled, client support on remote desktops can be dicey, and networking problems often pop up. Among the applications that are not Web-enabled are those using common mail protocols, including SMTP, POP3 and MAPI, and remote shell programs, such as telnet and VNC, which also are unencrypted. With a typical VPN, you can deny external access to those applications or use some encryption technology to protect the traffic passing over untrusted networks.
With non-Web applications, you need a client program, or have to download and execute an ActiveX control or Java applet on the remote user's computer that redirects network traffic from its intended destination to the SSL VPN gateway. The client application is a local proxy server that accepts connections on a local host address on the remote user's computer and proxies the traffic over the SSL VPN through the SSL VPN gateway to the destination server. ActiveX or Java applet support is required, along with the permissions in the browser to run them. Java support typically requires a minimum version of JRE. For company-owned computers, that's not a problem, but access from a public kiosk is likely to be spotty at best.
click to enlarge
The next hurdle is getting the remote user application to talk to the local host proxy. You don't want users to have to reconfigure the destination servers in applications. The most common method for setting up the application to talk to the proxy listener is to use DNS to resolve host names to the local host proxy address. There are two ways to do that. You can let the SSL VPN client application modify the local hosts file dynamically so that host names resolve to a local host address. This works fine, but the user needs to have administrative privileges to write to that file.
The other gotcha is that if the proxy listener or computer crashes, the local host file may not be restored, and this can bring about host name resolution problems. Only the products from SafeWeb and Whale restored the host file to its original condition when we powered the computer off and then on again.