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:

  • To what services and information resources do
    remote users need access?
  • Do these applications and services already
    include integrated support for SSL-based remote access?
  • Is there a way to “webify”
    applications that do not have integrated Web support without deploying a full
    SSL VPN?
  • Do user Help Desk calls related to network level
    VPN represent a significant cost to your organization?
  • Do users generate a lot of Help Desk calls
    because of misunderstanding or misconfiguration of network level VPN clients?
  • Are users abusing their network level VPN
    connections to access resources they do not need to remotely access in order to
    get their work done?
  • Are management and troubleshooting costs for network
    level VPN servers and gateways exceeding those acceptable to the organization’s
    IT department?

    • 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:

  • Do you want to allow remote access to a very
    small subset of network applications?
  • Do you want to allow remote access to all
    applications through the SSL VPN, but be able to restrict access to specific
    application and servers based on user credentials presented at log on?
  • Are all the applications you want to allow SSL
    VPN remote access to already “webified”, or
    will the SSL VPN gateway need to translate data
    returned by the server into a Web presentable format?
  • Will some users require unfettered access using
    all network protocols to any server on the corporate network?
  • Are you willing to deploy SSL VPN client
    software to SSL VPN remote access clients, or do you only want the SSL VPN
    client software to be deployed via a Web download after connecting to the SSL
    VPN gateway?

    • 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.