SSL VPN interoperability across applications proves 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.

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.