Many companies use VPNs to deliver corporate network access to off-site employees. Today, most remote access VPNs apply IP security extension (IPsec) to encrypt private IP packets sent across public IP networks. As workforces grow and diversify, however, IPsec VPN clients have proven cumbersome for end users and costly for network administrators. By leveraging the ubiquitous Web browser as a client platform, SSL VPN appliances represent a promising alternative for delivering simple-but-secure off-site access to private business services and data.
Why use an SSL VPN appliance?
Gartner projects that by 2008 SSL VPNs will be the primary remote access method for more than two-thirds of business teleworkers, three-quarters of contractors, and 90% of employees who require casual access to corporate networks. As a browser-based solution, SSL VPNs can be activated quickly, on nearly any system, without requiring permanently installed client software. These benefits appeal to companies that have tired of administering laptops for travelers and teleworkers and that need to expand remote access without increasing an already heavy IT workload.
Users can often self-enroll with an SSL VPN appliance from a home or public PC, obtaining immediate access over any available Internet link. Once the user is authenticated, group or individual rules grant access to URLs representing systems, services and data behind the SSL VPN appliance. Target applications are typically presented through a browser window, implemented by dynamically downloaded ActiveX controls or Java applets. SSL -- or its IETF successor, TLS -- are used to compress, hash, encrypt and tunnel all messages between the user and the VPN appliance. In a nutshell, SSL VPN appliances can deliver secure access with fewer client-side dependencies.
Deploying an SSL VPN appliance
Dig beneath this glossy surface and you'll discover significant differences between SSL and IPsec VPNs. For example, IPsec VPNs provide access to specified subnets or the entire corporate network, and connected hosts must be assigned IP addresses from the private network's address space. Because SSL VPNs deliver access to specified URLs, resource rules can be more granular -- and can more easily hide internal network topology. From a network engineering perspective, SSL VPN integration is simpler because the appliance can be deployed on your firewall's DMZ without adding or renumbering IP subnets.
On the other hand, IPsec VPNs create a robust, general-purpose platform that supports any IP-based application. Depending on their design, SSL VPN appliances may require incremental effort to support new applications. For example, detailed configuration may be required to map URLs to application objects and rewrite URLs to hide internals. Every SSL VPN appliance supports common business applications like enterprise email and network file system access, but proprietary or complex applications can require custom plug-in development or client-side port-forwarding code. For this reason, many companies initially deploy an SSL VPN appliance to augment their IPsec VPN -- for example, adding workers who need only email access to the SSL VPN while retaining the IPsec VPN to satisfy workers who really require broad network-layer access.
What to look for in an SSL VPN appliance
Of course, SSL VPN appliances must have hardened platforms and operating systems, managed through secure interfaces. Although early SSL VPN performance did not compare well with IPsec, today's enterprise appliances can use hardware acceleration and high availability to reliably support very large workforces. But beyond these fundamental considerations for any network security appliance, what features and factors should you consider when choosing an SSL VPN appliance?
VPN architecture: Under the covers, SSL VPN appliances are rather diverse:
- Web proxy appliances support Web applications only. The browser wraps ordinary HTTP inside SSL and sends it to the appliance, which checks policy, maps the URL, and forwards the HTTP request to the target internal server.
- Application translation appliances let users interact with applications through ActiveX or Java interfaces that mimic native application GUIs but send requests in HTTP format. The appliance must translate HTTP into each application's native protocol before forwarding that request to the target (non-Web) server.
- Port-forwarding appliances support TCP client/server applications by using a client-side agent to relay native application protocols over an SSL tunnel. The agent binds to application ports on the remote host, while the appliance relays tunneled messages to and from internal (non-Web) servers.
- Network extension appliances support just about any IP application by using a client-side agent to relay IP over an SSL tunnel. An installed agent intercepts and tunnels outbound IP to the appliance, which acts as a network layer gateway -- architecturally similar to IPsec but without standard IPsec restrictions.
Any given appliance may support more than one architecture, but starting here will help you understand product's client and application support.
Client support: Every SSL VPN uses the Web browser as a client platform, but many download client-side code that limits use on public PCs, non-Windows hosts, mobile devices, and Extranet partner systems. Can you live with client requirements -- for example, browser vendor/version restrictions or ActiveX enablement? Can the appliance deliver reduced functionality to restricted clients while offering more to employees who use a VPN portal page to self-install agent software?
Application support: Beyond email and file sharing, consider the applications required by your workforce, whether/how the appliance supports them, and the effort required to enable them. For example, port-forwarding appliances can often support many client/server applications without customization, but real-time and push applications (e.g., VoIP) may require a network extension appliance. Make sure you understand what will be involved in URL mapping and protocol translation for your required applications.
User authentication: SSL VPNs must authenticate users before delivering authorized services. Make sure the appliance supports your required user authentication methods and existing authentication servers and user databases (e.g., RADIUS, Active Directory, LDAP). Also, consider whether the appliance can pull authorization attributes from user accounts and the integration effort involved in establishing that flow.
Authorization: SSL VPNs often have the ability to enforce granular rules that control what the user (or group) can reach. Evaluate the authorization granularity supported for each required application/resource and whether the appliance can support your defined security policy. For example, some SSL VPNs can factor in remote device identity (location), letting you limit functions available to users on public or home PCs.
Endpoint security: It can also be useful to assess the security posture and state of a device before granting access. SSL VPN support is growing for NAC, NAP, TNC and product-specific interfaces that make it possible to check and/or enforce endpoint security -- by requiring current security patches or anti-virus on the endpoint, for example, or by limiting resources that can be reached by noncompliant endpoints. Consider how well the appliance fits with your company's endpoint security strategy and implementation. If you plan to support unmanaged endpoints, evaluate support for client-side safety measures such as browser cache/cookie/history cleanup and "sandboxing."
Auditing and reporting: Finally, consider how the appliance tracks and documents user access to enterprise resources and whether that information is sufficient to meet your company's internal/external reporting requirements.
Finding SSL VPN appliances
According to Synergy Research Group, annual SSL VPN sales reached $250 million worldwide in 2006, led by Juniper, Citrix, F5, Aventail, Nortel, Whale and Array. In a market that has experienced rapid growth and acquisition activity, it can be hard to keep up with vendor/product name changes and new market entries. Those shopping for an SSL VPN appliance today may wish to consider (at least) the following contenders:
- Array Networks SPX Series
- Aventail EX Series
- Caymas Systems ID-Driven Gateways
- Check Point Connectra
- Cisco Systems ASA 5500 Series
- Citrix Systems Access Gateway
- F5 Networks FirePass
- Juniper Networks Secure Access
- Nokia SSL VPN
- Nortel Networks VPN Gateway
- Blue Coat RA
- SonicWALL SSL VPN
- Whale Communications (Microsoft) Intelligent Application Gateway
To learn more about Virtual Private Networking technologies and architectures, consult SearchNetworking.com's VPN page. To read more about SSL VPN appliances and how they compare with one another, consult David Strom's September 2006 Information Security Magazine article, "Not so simple."
About the author: Lisa Phifer is vice president of Core Competence Inc., a consulting firm specializing in network security and management technology. Phifer has been involved in the design, implementation and evaluation of data communications, internetworking, security and network management products for nearly 20 years. She teaches about wireless LANs and virtual private networking at industry conferences and has written extensively about network infrastructure and security technologies for numerous publications. She is also a site expert to SearchMobileComputing.com and SearchNetworking.com.