SSL VPN interoperability across applications proves tricky

Clear Choice Tests show interoperability between client and Web apps prove tricky.

Application and client interoperability is the most difficult piece of an SSL VPN deployment. Based on data collected from more than 1,400 test cases, we can report that vendors are making headway against the problems posed by exporting applications to remote connections of all types.

Because classic SSL VPN technology connects users with Web-based applications, we tested each product’s interoperability with nine Web-based applications to ascertain whether they could make these applications available. Out of our 65 Web application-only test cases, Juniper’s SA SSL VPN nailed 50, followed closely by Nokia’s Secure Access System (46), AEP’s Netilla Security Platform (45), Aventail’s EX-1500 (44) and F5’s Firepass (42).

The poorest showings came from Array’s SPX series (23), SonicWall’s SSL-VPN 2000 (20) and Fortinet’s Fortigate-360, which distinguished itself by not passing a single test, despite the heroic efforts of their technical support team.

Our interoperability tests ran with our required security policy in place. We didn’t try to work around problems by changing the security policy or disabling product features. That is not to say that all of these products don’t have a plethora of pushbuttons that can be used to adjust behavior during rewriting. Most are confusingly labeled and undocumented, but technical support would jump us right to these settings when a particular application didn’t work.

Interoperability issues are almost always the fault of the SSL VPN’s rewriter – sometimes called a munger – that modifies HTML, Java, JavaScript or Flash data streams pouring into the browser. The rewriter changes the Web application content so that any references (images, links, applets and so forth) will be pulled back to the SSL VPN device to be secured. Building a rewriter is akin to simulating the behavior of a Web browser, of JavaScript, of Java and of everything else so that it can be decoded and modified. It’s a hard task, and there are bound to be errors.

We threw two curveballs at the products by installing the latest version of Lotus Notes, Domino Version 7, and by throwing an Avocent KVM-over-IP application into the mix. None could handle Avocent’s KVM-over-IP application, and the Domino results were almost as bad (see full results ).

Most SSL VPN vendors have a solution for when simple rewriting isn’t going to work. A common one is to load a small application on the local system and have the local Web browser point back to that application as a proxy. The application then tunnels the traffic back to the SSL VPN gateway without requiring rewriting. Looking at how well each product handled Microsoft and Citrix terminal services and SSH will give you some indication of how well vendors implemented this type of technology.

A second alternative to rewriting is to simply do away with it by building a Layer 3 tunnel to the SSL VPN device by installing a network extension client on the local system and going for full network access. This approach might work in the remote-employee-access case, but it has other costs, such as the need for end-point security checking, reduced performance and interoperability across client platforms. You can see how well products would have handled this approach by looking at how they fared in our VoIP application interoperability tests.

Two vendors whose products we did not test, Citrix and Permeo, avoid rewriting altogether. If you want to connect to applications behind either of these systems’ SSL VPN device, you must use a client.

File services

A common SSL VPN deployment requirement is the ability to browse files stored on servers. Every SSL VPN device can do basic protocol translation, with file services on one side and Web pages on the other. The SSL VPN device talks to your file servers, but end users only need a Web browser to see directories and manipulate files.

Our tests asked SSL VPN products to talk to both SMB and FTP servers. SMB was an easy target, and most products did a fine job with it, with Fortinet’s and SonicWall’s products the only exceptions. SonicWall engineers said we were exercising a known bug by having more than one user log onto the file server, while Fortinet technical support referred our problem report to its engineering team.

Array and Nortel both lost points here, because their products were so incompatible with our Mac clients that we couldn’t log on in those scenarios. We also were disappointed with Check Point’s Connectra. On Windows, running Internet Explorer, Connectra has a file browser that looks exactly like the Windows’ Explorer file browser. It’s an incredible programming job, and it’s a lot easier than trying to map a drive over an SSL VPN. What was disappointing is that Check Point had no fallback: If you weren’t on Internet Explorer, not only did you not get the nice interface, but you didn’t get any fallback interface at all.

Our FTP interoperability test didn’t tell us very much. Most vendors have chosen not to support FTP. Only Nokia, Nortel and SonicWall offer it. The only reason that Nokia edged out Juniper in our interoperability testing raw scores is that it was able to handle FTP.

Halfway between the Web browser and a full network-extension client is the murky world of port forwarding and application redirection. These technologies take advantage of the fact that most common applications are very simple client/server, TCP-based data streams. As such, they don’t need full network access to operate over an SSL VPN, but can connect over a specific tunnel set up just for that application.

From a security point of view, port forwarding and application redirection are great technologies, because, as a network manager, you can enable people to run a wide variety of common applications across the SSL VPN without giving them full network access. If the application is listening on Port 1494, for example, the tunnel goes only to that host, that port, for this particular data stream. No other mischief is possible, and your only security concern is the exact application on the server you open to the SSL VPN users.

Port forwarding started off as a fairly awkward technology, usually handled by a Java applet that was pushed down by the browser. As SSL VPN vendors have learned more about how to interact with the Windows environment, they have worked to make this as seamless as possible. In many cases, the SSL VPN manager specifies the application down to the path level on a user’s local hard drive. When the application is launched, a tunnel is built around the application.

We tested the products against four of the most common client/server applications used as part of SSL VPN deployments: Windows Terminal Services, Citrix Presentation Server, Telnet and SSH. Because vendors have come up with so many strategies for handling these applications, we let each dictate how we would use the application rather than insist on doing it through pure port forwarding. That left us with a mix of vendor-provided Java applets, special Citrix and Terminal Services clients, and no small amount of under-the-covers black magic.

The clear winner in this space is AEP’s Netilla Security Platform, with 24 out of 28 points, followed by Nokia’s Secure Access System (23), Juniper’s SA SSL VPN (22) and Check Point Connectra (20). In this particular case, our choice of applications was particularly fortuitous because it showcased AEP’s thin-client technology, arguably the strongest part of its product. In this part of the test, Fortinet’s Fortigate-3600 (6) and SonicWall’s SSL-VPN-2000 (5) gave the poorest performance.

What we learned from this part of our testing is that the standard “port forwarding” term is a misnomer with these high-end products. Each has some sort of unique solution, but these are all both very application- and platform-dependent.

True tunneling

Network extension, a full Layer 3 tunnel, is now considered a core part of any SSL VPN product. Busy network managers use this when they don’t want to deal with the hassles of defining every application SSL VPN users will use, and there are some applications, such as VoIP, that can’t work with port-forwarding technology.

We tested specifically for VoIP (using SIP-based phones) performance on our client laptop platforms (Windows 2000, XP and Macintosh) to see how well Layer 3 tunneling over SSL VPN worked.

One clear answer is: not very well if you’re not an administrator. If you want to bring remote users into your network with network extension, you better either preinstall the client on their laptops or make sure that they have full control of any system they want to use. We found that only three vendors support Mac users: F5, Juniper and Nokia. AEP promised it would add Macintosh support in its next version.

We did run into a couple of surprises in our testing. Fortinet’s client came up on XP and worked for several applications, but not for SIP, despite our wide-open firewall policy. A few vendors, including SonicWall and Caymas, discriminated against our Firefox browser users by telling them that they had to run Internet Explorer to launch the client. However, across the board, once we got the clients installed with every other vendor, we had no problems running VoIP across the SSL tunnel. We’ll report the results of VoIP quality testing over SSL VPN in a few weeks.

No shows | Next test: High availability >