SSL VPN: Terms and conditions

A glossary of terms and conditions used in our Clear Choice Test of SSL VPN.

The SSL VPN market brings together many technologies to accomplish the goal of secure remote access. Understanding the strengths and limitations of SSL VPNs means understanding four critical terms: proxying, application translation, port forwarding and network extension.

SSL VPN devices start with at least one function: proxying Web pages. For the SSL VPN system that means connecting to a Web server, downloading a Web page and shipping it back over an SSL connection to the end user’s browser. The devil is in the details, but it’s pretty easy to understand.

Things get complicated when you start talking about anything other than a Web page. The next step up in complexity involves application translation. A good example of this is how SSL VPN devices treat file servers. The SSL VPN device will talk to the native file server protocol, such as Microsoft’s Common Internet File System (CIFS) or FTP. But the application protocol is translated by the SSL VPN device from FTP or CIFS on the inside, to HTTP and HTML on the outside so that the end user sees the file server as if it were a Web page, in effect “Webifying” the application.

The end user thinks that they’re talking to a Web server with a Web browser, but the SSL VPN device is translating the application protocol transparently to the user. All SSL VPNs include application translation for file servers, but some also have built-in Webmail clients (translating mail protocols SMTP and IMAP or POP to HTML over HTML).

Application translation works for some things, but not for others. Some applications, such as Microsoft Outlook or instant-messaging tools, have a particular look and feel that is lost during the translation to a Web-based interface. This brings us to port forwarding, a technique that works for well-defined applications. Port forwarding requires a very small application that runs on an end user’s system, often a Java or ActiveX tool. The port forwarder listens for connections on a port that is defined for each application. When packets come in on that port, they are tunneled inside of an SSL connection to the SSL VPN device, which unpacks them and forwards them to the real application server. To use the port forwarder, the end user simply points the application he wants to run at his own system rather than the real application server.

Port forwarding is a very effective technique, but does have severe limitations. For port forwarding to work, the applications need to be well-behaved and predictable in their network connectivity patterns and needs. Although there are port-forwarding tools written in Java that work across platforms, our experience was that port forwarders tend to be platform-specific. Port forwarding can also require the end user to follow different procedures when in the office than when out of the office. This has been cited as an issue with port forwarding, because the level of transparency is low compared with other kinds of SSL VPN access methods. Some vendors try fancy things such as editing the local “hosts” file on the PC to make the user think that they’re connecting to a remote system instead of their own. Although proper deployment can make port forwarding fairly transparent, it is often considered the bastard stepchild of SSL VPN access methods.

Many SSL VPN vendors have a variation on port forwarding usually called dynamic application redirection. This is a Windows-specific technique where any application’s data stream can be captured and redirected over an SSL tunnel back to the VPN gateway. The advantage of application redirection over pure port forwarding is that it operates without the network manager having to know ahead of time exactly what ports and IP addresses each application will use. Typical applications that work better with dynamic application redirection than with port forwarding include Microsoft Outlook, Lotus Notes, Windows Terminal Services and Citrix Presentation Services.

The fourth technology all vendors are including in their products is network extension. SSL VPN network extension connects an end user’s system to the corporate network, with access controls only based on network-layer information, such as destination IP address and port number.

Network extension also moves completely away from operating system independence and requires administrative access to every local system to install the client. Because many SSL VPN devices try to simplify and ease the installation by pushing the client down through the browser, users either have to be running as Administrators when they attempt to connect, or need to have previously installed the client on the same system as Administrator. SSL VPN network extension runs on top of the SSL protocol, trading off the higher security of IPSec for simplicity of management and greater robustness in the face of different network topologies, such as firewalls and network address translation.

Because SSL VPNs operate over TCP, however, there are some situations where encapsulating an application data stream over a network extension client running over SSL running over TCP can cause problems. Take VoIP, which runs over User Datagram Protocol (UDP). VoIP protocols expect that packets will be lost, and they operate just fine when a few packets are dropped. A typical data stream for many voice codecs will generate 50 packets per second, and when a packet is lost, the right thing for the SSL VPN device to do is just ignore it. Unfortunately, with SSL VPN tunneled over TCP, you can’t do that – the TCP-state machine insists on finding that lost packet and retransmitting it, long after it’s of any interest to the VoIP network connection. To avoid this quality-sapping scenario, SSL VPN vendors are beginning to develop hybrid devices that will try and use the more-efficient IPSec (or other datagram-based technique, such as UDP encapsulation) when possible and fall back to TCP-based SSL VPN network extension when needed.

SSL VPN end-point security in hindsight