The day of the network level remote access VPN server may be nearing its end. A new collection of technologies, collectively referred to as "SSL VPNs" are rapidly increasing market share and are well-positioned to overtake the numbers seen in the current network level VPN installed base.
If you're new to SSL VPNs, you've probably heard a lot of talk about them, read vendor literature, and had informal discussions with friends and colleagues about them. At first it's hard to wrap your mind around how SSL VPNs might fit into your organization, because unlike network level VPN solutions, different implementations of SSL VPNs allow significantly different levels of network access.
In this article, I'll talk about some of the issues you should consider when considering a potential SSL VPN rollout. While SSL VPN rollouts tend to be simpler and more straightforward than a traditional network level VPN infrastructure, protestations of "plug and play" ease of deployment may be a bit overstated.
What's an SSL VPN?
An SSL VPN remote access solution has several advantages over the traditional network level SSL VPN. Some of these advantages include:
- SSL VPNs allow the VPN client to traverse firewalls and NAT devices that do not have the application layer intelligence to support PPTP, L2TP/IPSec or IPSec tunnel mode VPN client connections to remote network level VPN servers and gateways.
- SSL VPNs enable you to easily and strictly limit server and application access to users based on user credentials. The risk of users accessing unapproved network resources is significantly reduced.
- SSL VPNs greatly simplify the end-user experience of accessing corporate information resources. Users don't have to understand the somewhat abstract nature of virtual network layer connectivity. They are presented with a clear and intuitive landing page and click links to access information resources.
- SSL VPNs represent a heterogeneous collection of remote access technologies that enable you to provide only the level of access each type of user in your organization requires.
With these advantages (and many more) in mind, it's clear why SSL VPN remote access solutions are demonstrating increasing rates of adoption.
Before you Implement SSL VPN
Some of the issues that you will need to consider before and during an SSL VPN rollout include:
- Reasons for deploying an SSL VPN
- From where remote access SSL VPN connections should be allowed
- Public Key Infrastructure (PKI)/certificate deployment
- Split DNS infrastructure
- Securing the SSL VPN gateway
- Securing the network services segment
- Level of network access required by SSL VPN users
Note that this is not a comprehensive list of implementation issues, but a subset of issues that I find the most important to consider before and during your SSL VPN rollout.
Reasons for Deploying an SSL VPN
Before purchasing an SSL VPN solution, you should first consider what business problems you're trying to solve with it. Many companies with which I'm acquainted start with the assumption that they "need" an SSL VPN, but when pinned down, they can't provide compelling reasons for deploying one. You don't want yours to be one of those companies.
What are the remote access problems you are experiencing with your current network level VPN infrastructure? What applications do users need to access from remote locations? Do you already have technologies in place that provide an SSL VPN experience and don't even realize it?
Outlook Web Access (OWA) as an SSL VPN Solution
One of your problems might be secure remote access to Exchange Server 2003 resources. You want to allow remote access to Microsoft Exchange 2003 Outlook Web Access, but you're concerned that you can't do it securely. You might be considering an SSL VPN solution to solve the security problem.
If the problem is remote access to Microsoft Exchange Server 2003 OWA, then you don't need a dedicated SSL VPN device to provide secure remote access.
Instead, you can use a lower cost firewall or reverse proxy solution, such as Microsoft's ISA Server 2004 firewall or the Bluecoat Web proxy solution. Reverse proxies can be used to pre-authenticate users, perform stateful application layer inspection on SSL session contents, and pre-authorize users so that even if users authenticate, they must also be authorized to use the OWA site. The ISA Server 2004 firewall SSL VPN solution also presents users with an intuitive logon page generated by the ISA firewall, and the ISA firewall never allows unauthenticated and unauthorized connections to reach the OWA Web site.
Outlook 2003 RPC over HTTP as an SSL VPN Solution
Another problem many organizations have is that users want to use the Outlook 2003 full MAPI client to connect to Exchange Server resources. Most firewalls on the market today either do not have the application layer intelligence to understand and secure the Exchange RPC protocol, or the firewall administrator has disabled Exchange RPC support. You might be considering an SSL VPN solution to enable full MAPI client access for Outlook 2003 client.
In this case, a full-fledged dedicated SSL VPN is not required. When Outlook 2003 is paired with Exchange 2003, the Outlook 2003 client can use the RPC over HTTP protocol to connect to an RPC over HTTP proxy to obtain full MAPI client access to the Exchange Server over an SSL link. The RPC over HTTP proxy acts as an SSL VPN gateway that de-tunnels the Exchange RPC protocols wrapped in the SSL encrypted HTTP header.
If you have other server applications that have integrated support for Web based connections, the same principles apply. You can use a pre-authenticating, pre-authorizing, application layer inspection firewall or reverse proxy in front of the Web service instead of deploying a full-fledged SSL VPN solution.
Reasons to Deploy a Dedicated SSL VPN Solution
Questions to ask yourself before getting serious about an SSL VPN deployment include:
From Where Should Remote Access SSL VPN connections be allowed?
One of the major advantages of an IPSec based VPN solution (such as IETF compliant L2TP/IPSec or proprietary IPSec tunnel mode) is that in order to establish the connection to the VPN gateway, the remote access VPN client had to have a computer certificate installed. This enabled you to control what computers connected to your organization and enforce some level of centralized control over the client's overall software environment and client software "hygiene".
SSL VPN solutions enable any device with a Web browser to access corporate information resources. Because of this, you need to consider what types of devices you want to access your network through the SSL VPN connections.
For example, which of the following devices do you want connecting to your network through an SSL VPN connection?
- Airport kiosks
- Internet "pay to play" devices in restaurants, bars and Internet cafes
- Computers on users' home networks
- Laptops that connect to multiple unmanaged or poorly managed networks
- Corporate managed laptops that belong to the corporate Active Directory domain
- PDAs, Smartphones and other small form factor devices
- Multi-user machines that have no client protection mechanisms installed
If you choose to allow remote access to the SSL VPN from any Internet connected device, then you should look only at SSL VPN solutions that provide some mechanism for client software "hygiene" checking. These SSL VPN solutions use a variety of methods and technologies to check the current software state of the SSL VPN client and make sure that the client conforms to client software requirements you set for SSL VPN clients.
If you decide to allow only corporate managed devices to connect to the SSL VPN, then you should consider an authentication method that is incompatible with "anywhere" access. Two-factor authentication is useful in this regard, as it's very difficult for users to implement in non-corporate controlled environments and can obviate the need for username/password authentication.
Public Key Infrastructure (PKI)/Certificate Deployment
SSL VPNs by definition use SSL as the encryption protocol securing the link from intrusion. A core requirement for all SSL deployments is a public key infrastructure. The PKI must support machine, and optionally user, certificate deployment.
SSL VPN deployments are much simpler to implement when there is an established PKI in place. However, even if you do not have an established PKI, the deployment of certificate services does not need to represent a significant stumbling block for your SSL VPN rollout.
PKI considerations include:
- Will you use a commercial CA?
- Will you use a private CA and create your own certificates?
- How will you deploy machine certificates to your SSL VPN gateways?
- Will you need to deploy user certificates for user certificate authentication?
- How will your CRL be made available to Internet?
- Will you use smartcards for user certificate authentication or will you install user certificates on corporate managed devices authorized to use the SSL VPN?
Having your PKI in place and deciding how you will use and deploy certificates before implementing an SSL VPN can make the difference between a successful and unsuccessful SSL VPN deployment. Put PKI on the top of your list of things do to before purchasing your SSL VPN gear of choice.
Split DNS Infrastructure
A split DNS infrastructure allows transparent access to resources regardless of location. A split DNS prevents users from having to remember to use different names to access SSL VPN resources based on the user's current location.
The typical split DNS infrastructure maintains two zones for the same domain: one zone is authoritative for resources accessed by clients on the corporate network, and the other zone is authoritative for corporate resources accessible from the Internet.
The SSL VPN gateway will be located somewhere within the confines of the corporate network, behind either a stateful packet inspection-only firewall, and a blended mixed stateful packet and application layer inspection firewall. When users are located on the corporate network, you want them to access the SSL VPN gateway using the internal address bound to the SSL VPN gateway's interface(s). When users are located off-network at remote locations, you want users to access the SSL VPN gateway using a public address that forwards SSL connections from Internet hosts to the SSL VPN gateways private interface(s).
Make sure your split DNS infrastructure is in place before you roll out your SSL VPN solution. Failure to do so will make the SSL VPN gateway unavailable to either internal or external network users, or will create network performance issues as internal network users attempt to loop back through perimeter firewalls to access the SSL VPN gateway.
Securing the SSL VPN Gateway
All network devices should be hardened, and all Internet facing devices must be exceptionally hardened to prevent attacks from hackers, viruses, worms and spyware. You should also secure the SSL VPN device from lower level attacks at the MAC and network layers.
Most SSL VPN gateway devices are dedicated appliances that have been pre-hardened by the vendor. However, you should query the vendor on the underlying operating system on which the SSL VPN software runs and the specific hardening procedures that were used on the device. Do not accept vendor statements such as "it runs on Linux, so it must be secure". Demand an accounting of the hardening protocol.
You should also do what you can to prevent exploits and attacks from ever reaching the SSL VPN gateway. While all organizations have front-end and perimeter firewalls in front of their SSL VPN gateways, not all firewalls are equally suited to provide the specific protection required by SSL VPN gateways.
The ideal network level protection for the SSL VPN gateway is a firewall that provides strong stateful packet inspection and stateful application layer inspection on the perimeter. These blended firewalls protect the SSL VPN gateway from network level attacks that can cause DoS conditions on the SSL VPN gateway. They also can help prevent attacks that take place at the application layer from ever reaching the SSL VPN gateway.
In addition, advanced firewalls of this type support pre-authentication and pre-authorization at the perimeter, before connections are ever forwarded to the SSL VPN gateway. Firewalls of this class, such as ISA Server 2004 firewalls or Bluecoat appliances, significantly enhance the level of security provided for your SSL VPN gateway.
Securing the Network Services Segment
Some SSL VPN gateways support tunneling native application protocols in an SSL encrypted HTTP header. This HTTP encapsulation of the native application protocols enables the SSL VPN client to traverse firewalls and NAT devices. After the connection reaches the SSL VPN gateway, the HTTP header is removed and the native application protocol is exposed and forwarded to the destination information service.
At this point, the SSL VPN gateway and other firewalls in the path between the SSL VPN gateway and client do not protect the server application hosting the information resource from exploits carried by the native application protocol. Plan to place a perimeter firewall between the network services segment hosting the server resources and the SSL VPN gateway to mitigate attacks carry through the de-tunneled protocols.
Level of Network Access Required by SSL VPN Users
The major factor differentiating various SSL VPN technologies is the level of network and application access provided by the SSL VPN solution. The level of access determines what type of SSL VPN you want to bring into your organization.
Access level considerations and decisions you should make before implementing an SSL VPN solution include:
The level of network access required determines the type of SSL VPN solution you want to implement. Many organizations are less interested in attractive landing pages than they are with mitigating access issues related to traversing firewalls and NAT devices. These organizations want the same full functionality provided by network level VPNs, but need universal firewall traversal. If this fits your requirements, check into SSL VPN solutions that provide full network level access via an SSL VPN connections, such as those offered by Check Point and Net6.
All SSL VPNs other than those that front-end for integrated Web services require a client piece. There is a myth that SSL VPN functionality is clientless, which is clearly not the case. However, SSL VPN clients can download the client software "on the fly" after connecting to the SSL VPN gateway. These client pieces enable the SSL VPN client to receive and format the data returned by the SSL VPN gateway.
However, if you want full network level access through an SSL VPN solution, you will need to install a "thick" SSL VPN client and configure and manage the client in the same way that you configure and manage traditional PPTP, L2TP/IPSec and IPSec tunnel mode VPN clients.
SSL VPN gives new options
SSL VPN technology enables organizations to provide secure remote access to corporate hosted information resources without the overhead and barriers incumbent in traditional network level VPNs. While SSL VPN solutions typically have a lower overhead for installation and maintenance, there are still a number of issues that you need to consider and decide upon before selecting an SSL VPN solution and implementing that solution on your network.