Chapter 2: SSL VPN Technology

Cisco Press

1 2 3 4 5 6 7 Page 7
Page 7 of 7

Compared to clientless web access, the port-forwarding technology supports more applications but with less granular access control. The level of access control is still much more specific than the traditional IPsec clients, which provide full network-layer access to end users by default. This access and control trade-off makes port-forwarding technology a good choice for business partner access scenarios, where partners can access only specific application resources on the corporate network.

Terminal Services

To use the port-forwarding techniques, users must have client applications installed and configured to point to the local loopback address or the internal server address. You cannot assume that the client computers have these applications available. For some commonly used simple remote control applications, such as Windows terminal service, Citrix terminal service, VNC, Telnet, and SSH, some SSL VPN vendors provide extra convenience by delivering the remote control applications to the client computer.

We use Windows terminal service as an example of how this feature works. End users first log in to the SSL VPN; then they click the bookmark to launch the terminal service application. The client browser then downloads a package, which is often an ActiveX control or a Java applet, from the SSL VPN gateway and installs the package on the client PC. This package contains a customized Windows Remote Desktop Protocol (RDP) client, which enables the user to run a Windows terminal service connection to a corporate internal Windows terminal server. Also, in this case, the end user does not have to configure this RDP client. The traffic is automatically forwarded to the SSL gateway that intermediates the traffic between the RDP client and internal terminal server.

SSL VPN Tunnel Client

Traditional clientless web access and port-forwarding access do not satisfy the needs of power users and telecommuters who run VPNs on corporate-owned machines and like to have full access to the corporate resources. The IPsec VPN is a better fit to provide full network-layer access to the VPN users. Organizations that already have a remote access IPsec VPN can use the existing VPN solution to provide network-layer access and clientless SSL VPN for application-level VPN access. Today, most SSL VPN solutions also provide a tunnel client option for companies that have a greenfield remote access VPN deployment.

Again, unlike IPsec VPNs, SSL VPN tunnel clients have no standards, and different vendors use various tunneling technologies. However they do share some common characteristics:

  • The SSL VPN tunnel client can be downloaded on the fly from the SSL VPN gateway and installed on the users' computers. Normally, deliveries are through Java or ActiveX using established SSL connections. This way, there is no need to preinstall the VPN clients, as required by IPsec VPN solutions.

  • For installation, in most cases, tunnel clients require users to have administrative privileges.

  • The SSL VPN tunnel clients normally function in user space rather than kernel space. Because of this, the VPN users do not need to reboot after the VPN client is installed.

  • The tunnel client often installs a logic adapter (for example, a PPP adapter or a virtual adapter) on the user machine and gets an IP address assigned from an internal IP address pool. After the tunnel client captures and encapsulates the client traffic using the logic adapter, it transports the packets to the SSL VPN gateway using the established SSL connections.

Because the SSL VPN tunnel clients can be distributed and installed on the fly during the SSL VPN sessions, they save the IT management cost that would have been required by current IPsec VPN solutions.

Most current SSL VPN tunnel clients transport packets using SSL. The DTLS section covered the performance issue of this approach to support real-time applications. SSL VPN vendors are looking for solutions to resolve these issues. Currently a few methods have been adopted:

  • Advanced compression techniques to improve the performance.

  • IPsec transport. In this case, the SSL VPN tunnel client is delivered using SSL, but the data transport uses IPsec technology.

  • DTLS or alternative UDP mechanisms as data transport mechanisms.


This chapter covered the SSL and SSL VPN technologies in detail. The chapter started with basic requirements of a secure VPN and discussed how to use various cryptographic algorithms and applications to achieve these requirements. The piecing together of these technologies followed, with a discussion of the workings and implementations of the SSL/TLS protocol, which is the secure transportation base for an SSL VPN solution. The chapter concluded with a discussion of the SSL VPN and various remote access technologies that are deployed to build an SSL VPN solution. In summary, this chapter helps you to understand how SSL VPNs deliver secure communications and application access from a technology standpoint. With this understanding, you are well prepared to move on to the design and deployment of SSL VPN solutions.


SSL and TLS, Designing and Building Secure Systems, Eric Rescorla, ISBN 0-201-61589-3.

Applied Cryptography, Bruce Schneier, ISBN 0-471-12845-7.

Network Security, Private Communication in a Public World, Charlie Kaufman, Radia Perlman, Mike Speciner, ISBN 0-13-061466-1.

Network Security Principles and Practices, Saadat Malik, ISBN 1-58705-119-2.

RSA laboratories crypto FAQ,

RFC 2246, "The TLS Protocol."

The SSL Protocol, version 3.0,

RFC 2818, "HTTP over TLS."

PKCS standards,

RFC 3280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile."

RFC 2405, "The ESP DEC-CBC Algorithm with Explicit IV."

RC4 information at wikipedia,

The Diffie-Hellman introduction at wikipedia,

The RSA introduction at wikipedia,

The DSA introduction at wikipedia, Algorithm.

Copyright © 2007 Pearson Education. All rights reserved.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2008 IDG Communications, Inc.

1 2 3 4 5 6 7 Page 7
Page 7 of 7
SD-WAN buyers guide: Key questions to ask vendors (and yourself)