The SSL Alternative

Use SSL to give remote users secure access to Web-enabled and conventional applications.

November 7, 2003

30 Min Read
Network Computing logo

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.

Features List

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.

The second method, which is preferable to modifying the host file, is to use existing DNS servers to resolve host names to local host addresses. This requires a split DNS configuration where an external DNS server contains records for the external host and an internal DNS server contains records for the internal hosts.

We expected the products to support our existing Active Directory and RSA ACE/Server for authentication, and there were few surprises. Authentication against AD was accomplished through Microsoft's NTLM (NT LanMan) or via LDAP. Authentication against ACE/Server using SecureID tokens was through a native ACE client or RADIUS. Surprisingly, only Whale Communications e-Gap Remote Access was able to pull user group membership when authenticating against our domain using NTLM. Every other product used LDAP against AD. We also were surprised to discover that Array Networks' Array SP supports only RADIUS authentication to gather groups. This meant we had to modify the RADIUS configuration and use clear-text PAP (Password Authentication Protocol). This is a bad strategy: PAP authentication is vulnerable to brute-force attacks if the attacker can sniff the RADIUS authentication process. The only decent option when using RADIUS is to restrict use to one-time passwords.

Once the user achieves a secure connection, he or she should be bound by access restrictions. All the products provided basic functionality using authentication and group memberships. But access control is about granularity, and only the Nokia Secure Access System provided granular access controls. Its access controls could be based on predefined variables, such as source or destination IP address, URL, user name or group membership, time of day, and other items relating to the session. In addition, through a client-integrity scan, which searches for files and processes on the user system, the system sets variables based on local configuration. For example, if a user doesn't have a virus scanner, he or she may not be allowed to upload files to a file server. That's the kind of granular access control you want to enforce on remote users so that you can protect internal resources. However, there is a balance between access controls and complexity. Building ACLs (access-control lists) is hard, and it is easy to mistakenly deny access--or even worse, allow it.

The User Experience

The portal pages provided by the products we tested offer more than predefined links. The products from Neoteris, Nokia and Nortel have a wealth of configurable options so you can customize the portals. You may want to give a group of users access only to some internal links while another group is allowed to create its own links to internal resources. Customization is key. You should be able to manage all the portal options from the administrative console; this is the case for the portals from Neoteris, Nokia and Nortel.

However, because data is cached on the local computer, it may not be cleared when the user session ends or when the browser closes. You don't want internal data cached on a public system or an unprotected laptop. And not all applications have the "HTTP no cache" directives properly defined. At the very least, you should enable no-cache options on the SSL VPN gateway. Application wipers, which in the products we tested were ActiveX controls, provide cleanup options that can remove data and cookies from a remote system. But they offer limited value if they cannot be configured to remove cached content from specific locations. Whale Communications provides such functionality.

A final item on cache control: Some products--including Whale's--can be configured to deny access to the remote user if the application wiper cannot be installed. Either the browser doesn't support the plug-in, or the user doesn't have rights to run the plug-in.The Neoteris Access Series 5000 runs on the company's Instant Virtual Extranet (IVE) platform. The IVE is well-designed and offers a wealth of configurable features from network installation to user browser control. Both the administrative console and user browser experience are well-thought-out and highly configurable. Both let administrators customize the protections and features available to end users. The IVE has extensive user and group definitions that go far beyond those offered by the other products we tested. By leveraging back-end systems for authentication and group membership data, the IVE integrates easily with your current setup. The IVE also has easy-to-configure portal and access controls. However, the Neoteris product stumbles a bit in the areas of logging and troubleshooting. Details are plentiful, but the tools are difficult to use. Events weren't always logged during our tests, and we couldn't filter events for viewing. Your best bet is to send log files to syslog and learn to use grep and regular expressions. IVE also lacks a robust access-control system like those found in Nokia's NSAS and Nortel's Alteon products.

The IVE uses authentication-server objects to define both authentication methods and group membership. Setting up authentication for NTLM and SecureID was a snap. We pointed the IVE to our internal Active Directory server, and we were done. For the ACE/Server used with SecureID, we imported the ACE/Server configuration file. Simple. The next step was to map groups defined on external servers to groups defined on the IVE. We wanted our group members to have the same access to specific resources when they were remote, so we knew what access controls we needed to assign.

Neoteris did something unique with the IVE regarding group mapping. We were able to authenticate users to one server, while pulling group information from another server. As long as all our user names were defined the same way on multiple back ends, we could use our existing group definitions regardless of where users authenticated. For example, our ACE/Server user names matched those names listed in AD. When we authenticated users to the IVE using SecureID against the ACE/Server, we could then pull group membership from AD using the user names.

Next, we had several options when assigning a user to a group. We could base the group assignment on a group match against a directory attribute. Because we were using Active Directory, we used the "memberof" attribute of the user record based on the user name. Next, we assigned a mapping between the group returned from the directory and a local Authorization Group. We entered in the fully qualified distinguished name that would have been returned from the directory and mapped it to one of our internal groups. We could have mapped multiple "memberof" results to a single Authorization Group as well as define multiple mappings with the first match being put into effect.

Alternatively, we could have mapped users to a default group, in our case "Users," in the event the lookup failed. The other option was to map individual users to groups manually, and finally, we could map all users to one group. We chose the latter option during initial testing of the authentication servers, and then later used directory lookups.

Access controls and portal configuration are defined in the Authorization Group tabs. There are a host of options available in the Authorization Group. The authentication servers are selected automatically based on the group mappings, but authorization can be restricted to source IP address or specific browser types (based on the browser-supplied "User-Agent" string). A rudimentary host checker can be used to see if specific registry settings are set or if applications are running.

Each user group can have a different set of applications available, or it can inherit applications and settings from the "Users" group. Unfortunately, the applications have to be defined separately for each group, a task we found cumbersome. A user's group membership determines which links are available without your having to add links to each page manually. Additionally, we could configure cookie and credential persistence between logins, as well as allow users to enter arbitrary URLs, which point to internal resources and control Java applet network connections.

ACLs are based on a default open or default closed stance. Default open means all connections are allowed except those that are denied. Default closed means all connections are denied except those that are explicitly allowed. We chose the latter because it is a more secure approach. For Web access control, we needed to specify an access-control entry that defined the protocol, HTTP or HTTPS, the host name and the path. Wildcards "*" for any and "?" for one character are available to simplify URI building. Each type of access needs to be explicitly defined. For example, to allow OWA (Outlook Web Access) connections we defined two access-control rules that allowed access to our Exchange server, but only to the /exchange/*, /exchweb/* and /public/* directories. With the access-control entry, we could also have a bookmark or URL link on the portal page, automatically defined on the users page. For OWA, we needed only one link, which pointed to our Exchange server /exchange/* URI. ACLs for Windows and NFS file sharing are similarly defined.

Although there are many access-control functions in the IVE, we would have liked more granularity in the access-control entries, similar to what is offered by Nokia and Aventail. For example, we would have liked to grant access based on group membership and the client's source IP address, time of day, authentication method or the status of the local machine.

Non-32-bit application control is similar to Web access controls with a few notable exceptions. Terminal sessions via telnet or SSH were launched using a Java terminal applet, which tunneled the traffic over SSL to the IVE. Other applications are passed through a local port redirector, called a Secure Application Manager (SAM), that listens on a local host address and port. Neoteris has both an ActiveX and a Java-based SAM. In order for the application to connect to the SAM, the application must resolve the host name to the local host address. If you are running split DNS, you can have your external DNS resolve host names to the local host address. Otherwise, the host file must be modified on the local computer. Neoteris' ActiveX SAM, called Windows SAM or W-SAM, is unique because it can capture DNS resolution requests without having to modify the host file. That means local users don't need to have local administrator rights when using W-SAM. The type of SAM used is selectable by the administrator. It would be nice if you could choose the redirector based on browser type. It's a small thing, perhaps, but it makes supporting any browser easier.

The IVE portal can be locked down by the administrator so the user can't do much beyond what is configured or the features can be enabled to give the user more access, provided the resources pass the ACL. For example, users may be allowed to enter arbitrary URL, Windows UNC for file shares or even add tunneled applications as needed, and those changes can be added as bookmarks. The only aspect we didn't like is that file-sharing windows are opened in the same display pane.

Although the IVE didn't do everything we wanted, it has many features you won't find in other products.

Access Series 3.3, Neoteris, (408) 962-8200. www.neoteris.com Nokia is a relative newcomer in the SSL VPN space, but it's off to a fast start: The NSAS 1.0 release we tested demonstrated far superior features compared with the older product lines from several other vendors. First, the NSAS is downright simple to configure. While waiting for licenses, we spent a little over an hour configuring the access controls--a task that took us a day or several days with other products. The kicker is that our initial configuration worked as we expected. NSAS has an advanced access-control system that let us tailor the ACLs to our needs. At $54,995, the NSAS is pricey, but judging by the features built into NSAS, and the features Nokia has hinted at for future releases, we'd be willing to wager on this upstart.

NSAS is built on the IPSO 3.7 platform, Nokia's security-specific IP operating system. IPSO provides robust network-integration features, including support for multiple routing protocols and DNS. NSAS is enabled through Voyager, the IPSO Web interface. Simply enable NSAS and get a license.

Because we wanted to have both users and group membership to come from Active Directory, we used LDAP to authenticate users. Like every other product we tested except for Whale Communications' e-Gap, NSAS could not pull group membership information when using NTLM authentication, so we switched to LDAP against AD.

With NSAS, we could prioritize authentication methods. For example, we wanted all users to authenticate using Active Directory and only some users to use SecureID. We ordered the authentication servers so that ACE/Server would be tried first, and if that authentication failed, AD would be next. This added just a few seconds to the authentication process. Bear in mind that SecureID is time-sensitive and the passcode changes every 60 seconds. Always put SecureID authentication first so it won't time out.

Defining access-control rules was a snap. We defined a Web resource by giving it a unique name--OWA for Outlook Web Access, for instance. Next we typed in a description and the text that would show up in the user portal. Finally, we defined the URL and said when to use an internal proxy and whether auditing and debugging logs should be generated. Once set, the access-control page opened, and we set a simple access-control rule: We gave all Domain Users access to the resource by moving the Domain Users group into the allow category. We also could have added the link to the portal automatically. We added the link for the /exchange directory because that is the URL users will point to initially, but the Domain Users were simply given access to two other necessary directories, /exchweb and /public without links on the portal page.

In most cases, simple access-control rules will suffice, but to unlock the power of NSAS, use the advanced access-control rules. With these, we created access-control entries that took user context, such as location and authentication method, into consideration. For example, we wanted to grant external users access to the IIS Admin pages on a Web server only if they used SecureID to authenticate. If the user was internal, then he or she could use a user name-password login.

Using a form-based interface with drop-down menus and clickable operators, we created an access-control entry that said whether a user was coming from an external address and he or she used SecureID to authenticate or if the user was on an internal host and used any authentication method, he or she would be allowed access.

Neoteris' Access Series and other products can determine if applications are installed or running by using specialized DLLs supplied by the vendor or searching for registry entries. NSAS can be scripted to search for running applications or for files on the local system before letting a user connect to NSAS. Client integrity scans use a scripting language, pnuts, that is run through a Java applet and reports findings to NSAS, then access is granted or denied. The scripts can be configured to run before or after a user authenticates. We didn't spend much time creating scripts in the course of our testing, but we did modify the existing scripts that searched for files and processes to look for items specific to our environment.

NSAS includes a warning to the effect that the end-user system needs to have a modern browser--such as Netscape 6.2, IE 5.0, or Mozilla 1.0 or better--along with the Java JRE 1.4.1 plug-in. The JRE requirement is unfortunate because even though JRE is supposed to be backward-compatible, we have found it ain't always so. Be sure to test the JRE with all of your Java-enabled applications before deployment.

Unfortunately, Nokia doesn't supply an application wiper like the products from Neoteris, Nortel and Whale do. Application wipers aren't perfect--they don't always clean up all the cached data--but they do provide additional protection against leaving data behind on the hard drive.

Nokia Secure Access System, Nokia Corp., (877) 997-9199. www.nokia.com/securenetworksolutions The Alteon SSL Accelerator 410 VPN is at home doing double duty as an accelerator and an SSL VPN device. It offers features similar to those found in the top products we tested--they are just a bit tougher to get at. Like the Array SP, the Alteon 410 can host multiple virtual hosts configured on static IP addresses, TCP ports or both. This capability adds flexibility in a hosted environment and lets you implement graded authentication. The 410's access-control features are adequate, but not as robust or granular as those found in the products from Neoteris and Nokia. We had to update the software twice during testing to support OWA and Citrix Nfuse.

You can configure the 410 using a CLI or a browser. We started working with the CLI because the documentation is written for it and not for the WebUI. We don't mind a well-written CLI--sometimes we prefer it--but Alteon's CLI was difficult to get the hang of. In addition, it lacks input editing, line wrap and other features, and we ran into problems when we added a feature, then deleted it, then added it back again. The product would grouse about dependencies. The only solution was to revert to the last good configuration and re-enter all the commands again--ugh. The WebUI is just an attractive front end to the CLI and suffers from many of the same shortcomings.

Building access controls and portal links are separate tasks; we would have preferred to add a portal link when building access controls (as we could with Neoteris' and Nokia's products). User-access controls can be managed via groups. When the 410 authenticates a user from an external user database-- such as Windows Domains or RADIUS--the user's group affiliation, if available, is also captured.

We put all our users in the Active Directory default group of "Domain Users." We also defined a group called "IIS Admin" that contained users allowed to access our IIS server-management pages. We then created the two groups in the 410 and devised different access levels for each.

Once a user authenticates, the 410 presents all the links that are available to that user, according to his or her group memberships. For example, the only access rule for the "IIS Admin" group was to our IIS Admin page, and only those group members had the link. Role-based management greatly streamlines portal management, and Nortel's solution is enviably simple to implement.

More granular access control is achieved through extended profiles that let you define access based on the client's source IP address or authentication method. That's a start, but support for more complex access-control entries, like those supported by Nokia, is better.

The 410's user portal is superior to those of the other products we tested. User groups can be defined as one of three levels of users, novice through expert. Each portal level comes with a predefined set of features. Novice users, for example, are allowed to view only the resources defined by the administrator. Medium users can browse to arbitrary links and file shares provided they have the proper access control, and advanced users can define arbitrary port forwarding and terminal sessions.

Alteon SSL 410, Nortel Networks, (877) 655-2275 (US), (800) 466-7835 (Canada).www.nortelnetworks.com Whale Communications e-Gap is an interesting appliance that works differently from its competitors. The e-Gap Remote Access appliance contains two separate Windows 2000 servers, which transmit data via the e-Gap, a SCSI RAM disk. To make e-Gap work, we had to configure both the inside and outside systems. Fortunately, this was easy to do. Once in e-Gap, we defined shuttles, which in Whale-speak means a way to move data between systems. Then we set up the access controls. Because e-Gap is a Windows 2000 server, we added it to our internal domain and received full access to all our users and user groups without having to use LDAP. This is handy. Besides providing access control, Whale also supports HTTP URL filtering using regular expressions and comes with a full set of predefined filters.

Whale claims its e-Gap technology separates the inside of the network from the outside. When a packet hits either interface, e-Gap strips off the TCP headers, adds a cookie to identify a stream and places the TCP payload onto the SCSI RAM disk. Then the other side reads back the data, determines where it is headed and, if authorized, assembles a new TCP packet and sends it along. By itself, e-Gap can protect against network-layer attacks, just like a good proxy can, but a proxy doesn't do anything above Layer 4 and neither does e-Gap. And therein lies the usefulness of the e-Gap Remote Access product line-- robust but easy to configure, SSL-protected remote access.

Like the other products we tested, e-Gap's access controls can be based on group membership. The authorization tab in the application configuration lets you select which users and groups will have an application icon on their screens. We enabled remote access to our IIS Admin page. We created a user group called "IIS Admin" within Active Directory. When we defined the application in e-Gap, we restricted access to the members of the "IIS Admin" group only. We tested to ensure only those members received the URL and not others.

We wanted to set up graded authentication so only users who authenticated using both a user name-password pair and a SecureID token would have access to a set of applications. However, we didn't want to pass the SecureID credentials to the end application. Therefore, we had to modify the resource-validation script that is called whenever a user tries to access a resource. The script is written in Visual Basic, which makes it extensible. Under the direction of Whale, we cut and pasted a code snippet into the validation script. Next we had to edit the application parameters in the e-Gap configuration tool, then define an authentication realm (a fancy name for a set of credentials). The assumption is that whenever a server requests credentials, e-Gap checks to see if it has collected them. If it has, it forwards the credentials to the application; otherwise, it prompts the user for the credentials. So we added our Citrix Server and file sharing to the SecureID realm. We successfully tested process.

Support for non-HTTP applications is a bit more difficult. In other products, the process was as simple as defining the TCP/UDP port numbers and a few other parameters. For e-Gap, if an application wasn't defined, we had to contact support to find out how to edit the XML configuration file. Much of it was straightforward, but it's still a bit clunky given the rather smooth management features in the rest of the product.

The log files are contained in the log directory and are useless. You need to edit a registry key to turn up logging, then open the text files and process them manually.

e-Gap Remote Access 2.5, Whale Communications, (201) 947-9177. www.whalecommunications.comAventail is probably best known for its managed VPN service (see "Add some Fiberlink to your VPN Diet,"). It recently released the EX-1500 appliance for SSL VPN use. The EX-1500 has the makings of a solid product, but the version we tested had some surprising idiosyncrasies. However, Aventail is scheduled to release a new version by the time you read this. Also Aventail's Connect client (which we didn't test) offers some useful features. If you're looking at Aventail's line, make sure the company has solved some of the deficiencies we found before you sign on the dotted line.

The EX-1500 supports only two types of authentication--RADIUS, which we used for ACE/Server authentication, and ActiveDirectory over LDAP, which can be used for both user name-password sign-on and digital certificates. However, only one authentication method can be used per access type, either Web access or tunneled non-HTTP. We used LDAP to authenticate to our Active Directory. Group membership is pulled from AD using LDAP.

The appliance's access controls are simple to define, and we liked the many options available to us, including limits by source IP, destination IP, time of day, user name or group membership, and SSL key length. Unique among the products tested, the EX-1500 can disable a rule without having to delete it. This is handy when you're troubleshooting.

But this product crumbles when it comes to cookies. Cookie caching on the client cannot be controlled, so we could access OWA for one user while logged in to the EX-1500 as a different user. When one user logs out of the EX-1500, all credentials should be destroyed. Granting permissions to multiple resources in a Web server requires that all users have permissions to the common parent directory and assumes access to all subdirectories is allowed, which may not be the case. Dependencies in the management UI have to be deleted manually before a resource is deleted. Finally, any change to the access-control rules causes user connections to be dropped.

EX-1500 6.4.2, Aventail Corp., (877) AVENTAIL, www.aventail.com

SEA Tsunami is not as feature-rich as the offerings from Neoteris or Nokia, but it offers many more features than the products from Array and PortWise. SEA is a solid middle-tier product. Just as with the Neoteris IVE, we could assign an authentication server and a different group server; setting up the individual authenticates schemes was simple. SEA's access controls are adequate, but not as detailed as those offered by Nokia's NSAS. Its logging was moderately useful. But at $51,000 for 500 users, this product should have more advanced features akin to those in the Nokia and Neoteris products.

At first glance, SEA's authentication and ACL system seems robust, but soon we discovered it's overly complex and uses perplexing terminology. First we defined an authentication server for AD. Next we created a role, or a group and assigned nodes to a group. Then we learned that a node is a group. (So, call it a group and be done with it!) Next we assigned nodes to a role-- multiple nodes can be assigned to a role. Then we created access rules that defined available resources. We grouped rules and then assigned rules to roles. Because roles are based on hierarchy, child roles inherit rules from parent roles. Next we defined a portal, where links are marked for end users, and then we assigned portals to roles with inheritance. Whew. All this should be automated, which would reduce the chance of a configuration foul-up.

On the plus side, SafeWeb has simplified access rules by predefining many common access methods, including HTTP, Outlook/Exchange and telnet. There is also a generic TCP option that we used to create rules for Citrix Nfuse and Terminal Services.

Our tests also showed that the user portal is somewhat unstable. At times, clicking on a link would bring up the sign-in page in a frame. Sometimes the port redirector would fail to launch. When browser issues cropped up, our only recourse was to shut the browser down. One final note: Symantec was in the process of acquiring SafeWeb as we went to press.

SEA Tsunami, SafeWeb, (510) 601-8855. www.safeweb.com Array SP is a mixed bag of useful features and odd design choices. Its CLI will be familiar to any Cisco administrator, and its full-featured WebUI, Array Pilot, is equally as simple to navigate. Array SP can host multiple virtual sites each with its own parameters. However, most of its security features, including authentication and access control, are not robust enough for enterprise deployment.

Although Array SP supports common authentication methods and will even attempt multiple authentication methods, its group management is poorly conceived. Engineers from the company told us that the product is designed to use the same group membership format regardless of the membership-information source--either RADIUS or a directory (but not Active Directory). However, we had to modify the RADIUS dictionary or directory schema. Then we had to configure the groups access controls in RADIUS. Access control should be defined on the device, not in the directory. Also, we had to authenticate using RADIUS with clear-text PAP. Array claims no customer has asked for the more secure CHAP or MS-CHAP authentication schemes. Array, you're a security company: Your customers shouldn't have to ask.

Array SP 6.1.1, Array Networks, (866) MY-ARRAY, (408) 378-6800. www.arraynetworks.net PortWise's mVPN is a bust. We spent too much time troubleshooting configuration issues, talking to tech support and scratching our heads over a lot of seemingly spurious errors. To make matters worse, the product's logging was all but useless for troubleshooting. At least our support contact was helpful.

Many of mVPN's features are implemented through modules that must be loaded and configured while mVPN is stopped. Once the module is loaded, you can access the configuration parameters. Configuration can be accomplished through form-based pages, but we often found ourselves editing the parameters in Notepad instead. In any case, we had to be careful when deleting entries, because removing a host definition that is used in an ACL causes the mVPN to stop responding to any Web access. PortWise must take a cue from the other products we tested and provide better capabilities, including error and dependency checking, cleaner feature management and improved troubleshooting tools.

PortWise mVPN 3.5, PortWise, +46 (0)8 56291400. www.portwise.com

Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®; he covers all security-related topics. Write to him at [email protected].

Post a comment or question on this story.SSL VPN products provide secure remote access to internal resources using nothing more than a typical browser from nearly anywhere. Even non-HTTP applications, such as Lotus Notes, Outlook/Exchange and Citrix Metaframe clients, can be tunneled over an SSL VPN using a small, downloadable ActiveX control or Java applet.

We tested eight products in a typical deployment. Among our requirements: We wanted to leverage our existing Active Directory for authentication and authorization, have dynamic access control based on the users' group membership and see a well-thought-out user portal. Neoteris Access Series 5000's full-featured product won our Editor's Choice Award. The Nokia Secure Access System also boasts a wealth of options and should be on your shortlist.We installed each SSL VPN product in a reverse-proxy configuration where the external interface was on the 172.31.16.0/24 network and the internal interface was on the 192.168.1.0/24 network. All our intranet resources were on the internal network. We configured a Windows 2000 Active Directory and populated it with 500 users. We also created several custom groups, which we used to assign various access rights. For our internal servers, we used Microsoft Exchange Service Pack 2 for both Outlook/Exchange e-mail and Outlook Web Access. We used Citrix Metaframe XP Feature Release 2 to test NFuse classic integration. We also supported straight HTTP pages and terminal services. We authenticated all users against our domain using NTLM or LDAP version 3 to Active Directory. All our back-end servers were in the domain. We also tested two-factor authentication support using RSA ACE/Server 5.1 and SecureID tokens. We tested with both native ACE/Server authentication if supported or with RADIUS.

Our client configuration consisted of three different computers. We used Windows 2000 Pro, with Internet Explorer 6.0 SP1 and Netscape Navigator 7.1. Where a Java Runtime Environment was required, we used JRE 1.4. We also tested with a similarly configured Windows XP Pro computer. All base operating systems and applications were fully patched. We also tested MacOS X with Internet Explorer 5.2 and Safari 1.0. We also tested with MacOS 9 with Netscape Navigator 4.77 and Internet Explorer 5. In our tests, we pointed clients at the destination pages and made sure the pages rendered properly and ensured that the port forwarders worked.

We tested the level of integration with existing back-end servers, including support for non-HTTP protocols, like Citrix and terminal services, and single sign-on capabilities. Ideally, the SSL VPN portal provides single sign-on-like capabilities so that users need authenticate only once to the portal. We considered logging on to servers once in order to capture credentials and then caching those credentials between logins acceptable.

R E V I E W

SSL VPNs



Sorry,
your browser
is not Java
enabled




Welcome to

NETWORK COMPUTING's Interactive Report Card, v2. To launch it, click on the Interactive Report Card ® icon

above. The program components take a few moments to load.

Once launched, enter your own product feature weights and click the Recalc button. The Interactive Report Card ® will re-sort (and re-grade!) the products based on the new category weights you entered.

Click here for more information about our Interactive Report Card ®.


SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights