Corporations looking for new ways to enable roaming users to connect securely to their internal networks have latched onto Virtual Private Network Secure Sockets Layer (VPN SSL) gateway products. Unlike older VPN products that use secure TCP/IP protocols, the SSL products primarily make use of Web browsers to establish their connection. This, the theory goes, makes them easier to install and more parsimonious in their client software, thus useful for unmanaged situations. However, the SSL products still require a great deal of administration, configuration, and support.
The motivation behind SSL products is worthwhile: make it easier to support roaming users without having to install a thick client that is closely tied to a particular operating system and requires an IT department to touch each endpoint. By just using a Web browser, users can connect to internal networks securely and from just about any machine they can find, such as airport kiosks or their home PCs.
However, this is more a bedtime story than reality, as you’ll see from our tests of five leading products. The irony is that many corporate IT departments that start down the SSL VPN path because of minimum client requirements will find out after evaluating these products that the requirements aren’t so minimal to support a heterogeneous network.
We tested four hardware solutions from F5, Aventail, Cisco, and Juniper Networks, and one software product from Check Point. (CheckPoint also sells their product as an appliance.) Each of them has two different interfaces – one that manages the gateway and sets up the various configuration parameters; and one for users to connect to the internal network resources. Each product also has additional network extension software that runs on each client PC. Because the VPN doesn’t have access to the protocol stack running on the remote machine – unlike IPsec VPNs which do – they have to made some adjustments to enable more complex network applications to access internal servers and other resources, such as AJAX pages or accessing database-backed Web sites.
The products were tested in a purpose-built test lab on the Stanford University campus (see How We Tested). Ironically, we did our tests in the same building where 36 years ago the first Internet router was invented, and where for many years Stanford operated its Internet point of presence. Despite all this dusty history, we had a tremendous test environment that made each product sweat to complete our tests. We did the tests with the help and cooperation of the backbone networking group that runs the main data center and operates the major network infrastructure on campus. Stanford presently uses a collection of homegrown applications to keep track of their users and networking resources. They also have an older Cisco IPSec VPN configuration that they were interested in replacing with an SSL VPN gateway.
Our tests included four particular measurements, described in more detail below:
- Enterprise management and control features
- Client support
- Applications support
- Authentication and access control
Notice that these tests do not include any measurement of gateway or client performance. While we make mention of vexing setup issues, we didn’t try to setup each box on our own. Each vendor was invited to send its top technical support personnel to our lab and work with us for a day to get the product functioning. Juniper was the only vendor to finish their setup and satisfactorily complete all of our tests within the time allotted: the remaining vendors needed extra time to figure out their issues. Because of this and other reasons, we give Juniper the highest marks in our review, and Checkpoint’s Connectra the lowest. The other three had their moments and we describe all of their comparative features below in more detail. Juniper was also the most expensive, with a 1000-user configuration costing more than $ $75,000, a 10% premium over the second priciest F5 Firepass unit.
As we quickly found out during our tests, we needed to assemble a medium-sized team together to gather all the expertise required to configure our five products. We feel this is quite typical of any large-scale VPN rollout, and you should be prepared to assemble a similar team when testing and then deploying your own SSL gateway.
This is because the SSL gateway touches many different parts of your enterprise computing infrastructure. If you have segregated your support into desktop, server, network backbone, network applications, and end-user computing departments, as Stanford does, then you will need representatives from each of these groups to work together to produce the information you will need to test the product, let alone successfully operate in any production environment. For example, while testing our products we needed to correctly specify the parameters for Stanford’s LDAP and RADIUS servers (one person), how to connect to their Windows file servers (someone else), a third person to configure their desktops, a fourth for the firewalls, routers and switches, a fifth to setup our Linux server, and a sixth to answer specific security questions that we couldn’t get answered by anyone else, such as troubleshooting authentication issues and more complex Windows Servers issues that we’ll get to later.
This team is needed because you will run into situations where you have a particular application that can’t be setup without some head-scratching. Such was the case with our Avocent KVM over IP box – none of the vendors were able to support it without some changes to their basic routines.
Let’s examine how each of the products performed for our four categories, and why Juniper did so well.
Enterprise management and control featuresAnyone who will deploy an SSL VPN will have to spend a lot of time getting accustomed to its administrative interface. The issue for these products, unlike a lot of centrally managed ones, is that because they touch a lot of different places in the network you will have different people assigned to different roles in their administration. Juniper and Firepass seemed to understand this situation the best, and we’ll get to this in a moment.
Layouts of administrative menus certainly are subjective, but we found ourselves coming back to Juniper’s whenever we wanted to get something done quickly: they seemed to be setup more logically, at least in our way of thinking about VPNs. They also had clear-cut menus to control Linux, Mac, and Windows clients that were easiest to work with, and were able to handle multiple administrators easily.
With these products, all but Cisco’s use a separate Web server to set up and control configuration parameters — Cisco has a separate client for this purpose, which seems outdated. We examined how multiple boxes can be administered, whether administrators can see who is logged in at any given moment and kill that particular user’s session, and what auditing, reporting, and debugging features were available. Cisco’s administrative tools were the worst and F5’s Firepass were the best for this category.
On all of these products, it was easy to check the wrong item on one particular screen and turn a working system into a useless piece of junk with just a few mouse clicks. For example, we could easily destroy a lot of hard work in setting up the entire endpoint security subsystem with a few misplaced clicks, or ruin our authentication connections just as easily. Nevertheless, there are several things that stand out. Cisco’s administrative interface, called ADSM, is so miserably designed that it presented problems for their support engineers working with us for the review, and often they couldn’t quickly locate the appropriate screen. [See cisco-topmenu screenshot] ADSM has multiple hierarchies of menus within menus, making it easy to get lost several screens down.
The biggest differentiator among the five products was the ability for multiple users to manage the box concurrently, and have different administrative roles. This is critical in large-scale deployments where multiple people will be adding users, changing access policies, and setting up individual portal pages. Connectra was the least capable here: only a single administrator can login at any given moment and make changes to the configuration. Cisco’s also lacks the ability to assign multiple administrators different roles so that departments can manage their own users. Aventail isn’t much of an improvement: It comes with three administrative pre-built templates that offer some granularity for multiple people to manage their software, but it isn’t the level of granularity that F5 or Juniper offers. We like the ability of Firepass to specify the particular menu choices that each admin user could use. There is a page called “Administrative Realms” that offers complete granularity when it comes to assigning particular admin rights to different subsets of the overall functionality. [see “f5 adminrealms” screenshot]
We also liked the way the various functions and menu layouts of Firepass’ admin interface was the best of the five. It is clean and well laid out, and while some of the menu choices are a bit obscure, such as adding a connection for SSH under “legacy hosts,” most are displayed in a manner that makes it easy to add policies and set up your applications with not too much fumbling around since it segregates things into network, application, and portal access.
Each of these products could do a better job in debugging tools, especially when it comes to setting up authentication servers (which we’ll get to in that section). Speaking of debugging, a nice feature of Firepass is the ability for an administrator to login to the gateway as a user, and if something isn’t working to go directly into the configuration console to make changes without having to login with a separate browser session. This makes testing various configurations easier, and the other products were more cumbersome to switch between administrator and ordinary user.
Aventail has a nice initial installation routine which steps you through the process to setup the basic IP parameters and has you creating a test user account and your sample applications: we found this very appealing to familiarize yourself with the product and to get started. But its administrative interface lacks the “breadcrumb” display to show you the complete path that you took through its sometimes convoluted menu trees, something that most of its competitors have.
Client support
The most important part of any SSL VPN is how they support the actual users of the product, and we tested both Firefox and Internet Explorer browsers (and Safari on the Mac) on a variety of operating systems, along with testing each product’s endpoint security checking and remediation routines. Juniper had the best overall client support.
Each SSL product has the same collection of basic client features: they all support Windows XP/2000 and recent versions of Internet Explorer to connect to their gateways. Beyond that things got spotty for particular browser/operating system combinations — for example, none of the vendors supported Macs running Internet Explorer, which is no surprise as Microsoft no longer supports this combination either. All of the products except for Aventail offered solid support for Firefox browsers too.
All of the products offer a network extension client for Windows and IE, but none of them have a network extension client that completely works with Windows 98 or completely supports the Mac OS. Only Aventail had a Mac OS network extension clients that worked on the newer Intel-based Macs at the time we did our tests in June. (The rest promised to have it in their next release, and we tested a beta version from Juniper.) Aventail’s Mac network extension client is a bit cumbersome, in that users must authenticate twice — once in the browser, and then once in the client preferences.
Juniper had the best support for Windows 98, provided it was running the latest version of Internet Explorer, but not all applications worked completely, such as the Java-based SSH client. Connectra’s network extension client kicks off a series of warnings with Zone Alarm, which is ironic because they are owned by the same parent company. (Both Juniper and Cisco’s client had similar behavior.) Firepass’ client kicks off a series of Windows Registry changes that are flagged by Spybot. These aren’t such a big deal, since most end users will be only installing the VPN extension client once, but still indicate the lack of maturity in this space.
All of the products required administrative access to the remote client machine for the initial install of their network extension client (Permeo is one example of software that doesn’t require this). This could be a problem for corporations that lock down their machines with restrictive logins and don’t allow users to install their own software.
Speaking of locking down machines, part of the client support offered is how each vendor offers endpoint security. This is still very much a work in progress, and some — such as CheckPoint — offer this as an extra cost option, while others have partnered with a variety of suppliers to do health assessments and remediation. The tradeoff in implementing these is that your users will have to be prepared to wait while the endpoint checking routines are completed and security software is installed on the fly before they can actually begin using the VPN connection for useful work.
One of the first places to start off with endpoint security is in checking the particular anti-virus software that is running on the remote client, and either preventing access or sending the client to a quarantined network segment where they can bring their PC up to par. Both Firepass and Juniper make use of the Opswat database of dozens of AV versions (a complete list is available here: http://www.opswat.com/antivirussdk.shtml). Cisco supports more than a dozen, while the others have more limited AV support, such as Connectra (see connectra-antivirus screenshot). . Aventail will offer its Opswat support in its next release.
All of the products offer varying degrees of control over what endpoint conditions they check for either prior to any login, or just after a login: Juniper and CheckPoint have the most granularity here in terms of type of OS and conditions such as whether particular anti-virus, firewalls, and other malware blockers are actively running on the endpoint prior to granting access to the internal network. For example, Juniper’s remediation measures include the ability to delete specific files or terminate particular processes, or to run custom scripts. For network administrators who are comfortable with creating firewall rule sets, this is a very similar process to assemble a particular endpoint policy. Firepass has a nifty visual policy editor that works like a flowchart, and adds features such as the ability to check for particular IE versions and the presence of Google Desktop indexing engine.
All of the vendors offer a desktop “sandbox” mode whereby a Windows user can login to a completely protected workspace that prevents users from saving files locally, cleans up afterwards and leaves no evidence of files or cookies behind. This can be used in completely insecure environments such as at an Internet café or other public computers. But this sandbox isn’t available for Mac or Linux users. Juniper has the most fine-grained control over what users can and can’t do once they are inside this protected environment, such as permit access to printers, to make changes to the Windows Control Panel, or allow particular IE browsers with particular encryption key strengths.
Applications support
We tested a variety of simple and complex applications to see how well they would work on each product. We tried to connect to a Windows file share on the local LAN, connect to an FTP and SSH server, and view a variety of Web servers that were all behind a firewall. We also tried to run Outlook Web Access and connect to a Java-based Avocent KVM over IP server. With each of these applications, we tested with the browser-based client, connecting to a custom Web portal page that had links to each application, and with the network extension client (if it was available for that particular platform). Juniper had the widest support for applications, and has a nice way to debug URLs entered into its portal configuration screen (see juniper-badurl screenshot).
The biggest issue with our tests was the difficulty in which vendors had to connect to a Windows File server shared drive. This is a relatively simple task that unfortunately confounded three of our vendors. Juniper and Aventail both supported this application, and we describe this oddity in the sidebar on Windows File Sharing below.
Certain complex Web applications, such as the Java-based Avocent KVM over IP that we were using, gave us trouble. Aventail was the only product of the ones tested that could support the Avocent KVM session inside a browser, but it only worked with Internet Explorer. The others required their network extension clients to enable viewing remote desktops over their VPN connections. The next release of Cisco’s gateway will fix the KVM issue, according to the vendor representatives (and until then a version can be specially ordered by customer request).
The biggest issue with Cisco’s product is the lack of Intel-based Mac support for network extension clients, but even their thin client couldn’t browse Windows file shares on these Macs, which is a bug. . CheckPoint and Firepass also had some issues and couldn’t support all the applications as well as Juniper’s clients did.
Corporate VPN administrators will need to carefully examine every application and test to make sure that it works for each client, and under both thin and network extension clients. This is where SSL VPNs are weakest: the IPSec crowd can handle a wider range of applications without any configuration, since they own the entire protocol stack.
Authentication and access control
These products all work more or less with using a variety of authentication and authorization servers to provide access to the VPN network. We tested the products with existing Radius and LDAP servers that were setup on the Stanford network, as well as a test RSA Secure ID application to provide two-factor authentication. All five products were able to use all three of these servers, although it took some doing to get everything working.
We also examined each product to see how granular their access levels could be — such as restricting users to only login at particular time of day, or with specific source IP addresses. Connectra clearly lagged behind the others in terms of setup and features, and Cisco was superior in this category.
The most vexing part of our setup was in connecting each box to the Stanford LDAP server for our tests. This was a combination of our own mistakes in getting the various parameters correct (such as entering the correct IP address of each server) and each product’s poor debugging tools in telling us when we made our mistakes. (We wished these vendors had taken a page from Nokia’s debug features, which are the industry leader.) Connectra had the worst set of debugging tools, while Aventail and Juniper had the best — Juniper provides syntax examples that you can use to type in the correct strings, and Aventail has the clearest screens that prompt you for the required information (see aventail-ldapconfig screenshot). These tools are critical to avoid frustrations with the initial setup.
Interestingly, while we were debugging the authentication process on one product we observed that our box was being scanned by someone with an IP address from an Italian ISP.
Getting the RSA Secure ID ACE server setup was simple for those vendors that explicitly support it. Only Aventail among the vendors tested didn’t offer this support, so we had to connect to the ACE server via Radius protocols.
[See Aventail LDAPconfig screen shot]
Cisco, Aventail and Juniper segregate their different authentication realms for each user group on their Web-based login pages, Connectra and Firepass don’t offer this feature. This makes it easier for testing purposes to ensure that each realm is working properly, but probably isn’t so user-friendly a feature.
Each product comes with two network interfaces and can be run in what is called dual-homed configuration — where one interface is connected to the public network, and one lives on a private network with access to protected resources. However, we weren’t able to connect Juniper and Aventail’s product in this fashion because of how both products work with external network resources. In both cases, they assume that all authentication servers are attached on its internal network. In our situation, these Radius and LDAP servers were outside the protected network and operated on the general campus network. So we had to operate both of these products on a single interface, which may not be acceptable in certain corporate situations. One plus for Cisco is that you can assign authentication servers on either its internal or external interfaces, which was why — along with the ease of setting up the authentication servers — we give them top marks for the overall category.
There is no way to setup access levels for Connectra by time of day or by source IP address, things that are both supported by the others.
Summary
As you can see, these are complex products with all sorts of finer points to their operations. Our tests brought to light the current state of the art with SSL VPNs — they are quirky, they are difficult to install and setup, and they offer spotty support for users beyond the Windows 2000/XP and IE envelope. Certainly, if you have a very heterogeneous network, or a large group of custom-built corporate applications, you will have a long test and rollout ahead. Clearly, Juniper’s product stands out as the best overall, and best in three of the four individual categories. Firepass comes in second best.
Specific product report cards:
CheckPoint Connectra NGX R61
URL:
http://www.checkpoint.com/downloads/latest/connectra-ngx.html
Pros: Solid endpoint security tools (available at an extra fee), 15-day eval license for software-only product, active/active clustering support
Cons: Miserable Mac client, poor debugging tools for authentication/authorization server setup, requires three IP addresses to operate, and poor differentiated administration
Checkpoint was the weakest of the five products we tested. It is the only VPN of the five tested that also comes as a software-only package. You can obtain a CD for the cost of shipping a two-week, fully functional trail version. This installs on an reasonable Intel PC within 15 minutes and can be up and running within an hour if you take your time with the configuration.
The biggest issues we had with Connectra was the lack of differentiated, departmental-based administrative roles, although Checkpoint is making an effort to change this in the future. It also has the weakest support for authentication servers. If you already have other Checkpoint products, such as firewalls and IPS’s, you can manage all of this gear from a single console. Connectra had the poorest overall client support, and particular bad support for Mac clients . It, along with Aventail, offered the best clustering support for high-availability situations.
| Feature | Checkpoint Conectra NGX R61 |
| Cost 100 users | $15,000 (1) |
| Cost 1000 users | $60,000 (1) |
| Extra cost items | Endpoint Integrity: $5,500 (100 users), $13,500 (1000 users) |
| Enterprise mgmt | B- |
| Client support | C+ |
| Apps support | B |
| AAA control | C+ |
| FINAL GRADE | C+ or B- |
Note 1: Software-only solution, can be installed on any reasonable server
F5 Firepass 4100
URL: http://www.f5.com/products/FirePass/
Pros: Sophisticated end-point pre- and post-login checking tools with nifty visual policy editor, instant configuration updates, multiple concurrent administrators supported, Firefox network extension plug in
Cons: Spotty Mac support, no integration with BigIP box, mediocre debug and troubleshooting tools for authentication
The F5 Firepass is the most recent of the five products we tested: its version 6 was freshly minted and began selling the week before our tests began in mid-June. The new features added in version 6 include sophisticated endpoint checking routines, and a long list of supported anti-virus programs care of the Opswat team. F5 has this nifty visual policy editor that anyone who has done any flowcharting will glom onto. However, testing and deploying the right series of policies is still somewhat cumbersome because of all the choices available, and just because it is visual doesn’t mean that it is intuitive. If you have their BigIP load balancing boxes, the management interface for the VPN box is a separate piece of software, although eventually F5 plans on merging the two for a single, integrated management view.
| Feature | F5 Firepass 4100 |
| Cost 100 users | $24,990 |
| Cost 1000 users | $69,990 |
| Extra cost items | None |
| Enterprise mgmt | A- |
| Client support | B |
| Apps support | B |
| AAA control | B |
| FINAL GRADE | B |
Aventail ST EX-2500
URL: http://www.aventail.com/products/appliances/ex-2500.asp
Pros: Great Mac support, Active/Active clustering, good LDAP setup/debug tools
Cons: Can’t support external authentication servers outside the protected internal network, no support for Windows 98
The Aventail product is an interesting study in contrasts. It has both leading-edge functionality and yet is missing basic key ingredients, often in the same functional area. It was the only product not to offer native RSA ACE SecureID support, yet they had some great debgging tools for setting up LDAP servers. While their focus is on IE browsers running on Windows 2000/XP, they do offer support for Mac clients too. They charge extra for their thin client terminal emulation client software, which they OEM from WRQ/Attachmate.
While we didn’t test high availability, you can connect two of the Aventail appliances and they will operate in an active/active mode, meaning that both can service requests and be fully aware of each other’s state. This was similar to what Connectra offers — for the others, you need to install a load balancer or additional gear to provide true high-availability.
| Feature | Aventail ST EX-2500 |
| Cost 100 users | $26,995 |
| Cost 1000 users | $62,995 |
| Extra cost items | Terminal Emulation ($4995 – $19,990) |
| Enterprise mgmt | B- |
| Client support | B- |
| Apps support | B |
| AAA control | B |
| FINAL GRADE | B- |
Juniper SA-6000 SP
URL: http://www.juniper.net/products/ssl/sa_6000.html
Pros: Best non-Windows client support, solid administrative features, more logical menu organization
Cons: Can’t support external authentication servers outside the protected internal network, high overall cost
Of the five products that we tested, Juniper was the clear winner in overall usability, features, and flexibility of operations. The unit that we tested was the higher-end box that has a second power supply and second hard disk for redundant operations. We pulled out the power supply for our tests, mainly because the unit beeps if this isn’t connected.
Juniper’s product took the least amount of time to get setup and working, despite some complex menus and some oddly placed items. There are a couple of downsides, however. The box supports a higher-performance protocol called ESP that needs to be enabled on your network infrastructure, we didn’t test this because we were not testing performance. When setting your configuration, you need to be careful to save your changes before you navigate to another menu, it doesn’t save changes automatically.
It has, for an extra license, the ability to support secure Web-based conference and screen-sharing sessions, which is a nice touch.
| Feature | Juniper SA-6000 SP |
| Cost 100 users | see note |
| Cost 1000 users | $ see note below |
| Extra cost items | Web conferencing ($7,495 to $11,995) |
| Enterprise mgmt | B+ |
| Client support | B+ |
| Apps support | A |
| AAA control | B |
| FINAL GRADE | B+ |
Note: We tested the SA-6000, which is the highest-end box that Juniper sells, mainly designed for the service provider/carrier marketplace. The price range on this box for 100/1000 users is $40,990 – $81,995. A more appropriate comparison would have been to use the next capable model SA-5000, which has a top price of $75,985.
Cisco ASA 5540
URL: http://www.cisco.com/en/US/products/ps6120/index.html
Pros: Supports both IPsec and SSL gateways, flexible feature set for authentication servers
Cons: Lousy administrative interface, limited administrative realms
If there is a feature missing from the Cisco VPN gateway, we would be hard pressed to find it, and that in a nutshell is the issue we have with this product. You can do all sorts of tricks with this box, including setting up both IPsec and SSL VPN clients from the same gateway, and setting various user and group policies that are extremely intricate that you dare not touch them once you have them working. The issue is that Cisco’s administrative interface is complex and a bear to setup. Balancing this, it had the most flexible support for authentication servers of the products tested, and offers superior active/active high availability clustering. However, this configuration requires four separate gateways to be connected together as a cluster.
.
| Feature | Cisco ASA 5540 |
| Cost 100 users | $24,990 |
| Cost 1000 users | $55,995 |
| Extra cost items | None |
| Enterprise mgmt | D |
| Client support | C |
| Apps support | B |
| AAA control | B+ |
| FINAL GRADE | B- |
SSL VPN Notable Features Chart
| Feature | Checkpoint Conectra NGX R61 | F5 Firepass 4100 | Aventail ST EX-2500 | Juniper SA-6000 SP | Cisco ASA 5540 |
| Support for multiple admin realms | No | Good | Fair | Good | Poor |
| Opswat AV SDK support | No | Yes | Next release | Yes | No |
| Firefox support | Yes | Browser plugin | Poor | Yes | Yes |
| LDAP troubleshooting tools | Poor | Fair | Good | Good | Fair |
| Support for outside AAA servers | Yes | Yes | No (1) | No (1) | Yes |
| Access by TOD, source IP, etc. | No | Yes | Yes | Yes | Yes |
| Mac-Intel net extension client | Next release | Next release | Yes | Next release | Next release |
| # NICs per box (3 ) | Varies (2) | 4 | 2 | 2 | 2 |
| Active/Active HA cluster | Yes | No | Yes | No | Yes |
| Native RSA ACE server support | Yes | Yes | No | Yes | Yes |
Notes:
(1) Must run single-homed to connect to any outside authorization/authentication servers
(2) Software-only solution, can be installed on any reasonable server
(3) Not included any interfaces for clustered connections
Sidebar: How we tested
We sent out invitations to 12 vendors to participate in our tests, and selected the five best responses for this article based on market share, features, and the ability to support a large complex network such as Stanford’s.
We setup a test lab on the Stanford University campus that made use of their existing production network and tapped into resources on their enterprise backbone. All of the VPN gateways were placed on a separate server network, along with a Windows 2003 Server, a Linux server, and the RSA Secure ID ACE appliance that was used for two-factor authentication with its key fobs. We also setup an Avocent DSR 1031 KVM switch that allowed us to control all of these servers via a Web browser, and was used to test the ability of each VPN to support complex Web applications. All of these servers were placed behind a firewall that blocked all access with the exception of a client coming from one of the VPNs. A separate network contained four client PCs running Windows XP with SP2, Windows 2000, Windows 98 SR2, and Mac OS X v10.4, each with the latest patches and updates applied.
Each Windows client ran both Internet Explorer v 6.0 and Firefox v 1.5 browsers. The Mac ran IE v 5.2, Firefox v 1.5, and Safari v2.0.3.
The test lab also connected to the production Microsoft Active Directory server that was also running Radius and LDAP services, and an Exchange 2003 server that was configured for IMAP, POP and Outlook Web Access.
Our thanks to the Stanford IT department for their help in creating such a rich test environment, and especially their director of networking systems, Mark Miyasaki.. Specifically, we thank Paul Murray, Johan van Reijendam, Steve Tingley, Russell Scheil, Ross Wilper, Sean Riordan, Leroy Altman, and Jason Craig for all their help with this project. –D.S.
Sidebar: Windows File Sharing Issues
One of the most interesting results of our testing was the difficulty in which all of the vendors had in supporting the most basic VPN activity: the ability to mount a Windows file server and connect to one of its shared drives, and open and copy files to this network share. Only Juniper was able to complete this task in the time allotted, and even they had to struggle to figure out the problem. We didn’t purposely set things up to trip up our vendors, but they all did stumble on this issue.
What was the problem? In a nutshell, it is because the Stanford network is a wide-open network – meaning its servers are directly connected to the Internet, with no intervening firewalls. To protect themselves and these resources, Stanford’s server support group has locked down their user authentication to use what is called NTLM version 2. This requires stronger authentication than the original version that supported the LAN Manager-style username and password combinations that are sent over the wire in the clear.
http://support.microsoft.com/default.aspx?scid=KB;en-us;239869
The issue is that the SSL gateways can’t talk this protocol to the Windows file servers, and so users must use the network extension client so that they can authenticate themselves. If we tried to setup a share for the thin clients using each vendor’s portal pages, the logins would fail. In some cases, we could browse the Stanford network and see the lists of servers available via the Web portals, but not connect. Juniper’s product has a setting in their configuration menus that specifically turns on v2 authentication, while Aventail required a manual editing of their “start.sh” file to enable NTLM v2. F5 and Cisco don’t support this protocol. Checkpoint told us the problem was longer passwords that didn’t parse in their Samba client, and they are fixing it in their next release. — D.S.
Pingback: SSL VPNs: Not So Simple | Web Informant