Networking

SolutionBase: Troubleshooting SSL VPN Deployments

SSL VPNs can make it easier for mobile users to connect to your network, but they can also increase the amount of headaches you have for network support. Here are some things to keep in mind when troubleshooting SSL VPN deployments.

SSL VPNs are an increasingly popular remote access solution for companies dependent on remote access to information resources hosted on the corporate network. While in the past, remote access to information contained on the corporate network was considered a luxury or "perk", the ability to access corporate hosted information from anywhere, at anytime, is a sine qua non for any company that desires to be competitive in today's Internet-connected world.

While setting up and managing SSL VPN is typically easier than deploying and managing a traditional network layer VPN, there will still be times when you need to troubleshoot connectivity and configuration issues. Here are some tricks you can use to fix a troublesome SSL VPN.

SSL VPN Advantages

SSL VPNs have a number of advantages over traditional network level VPNs (PPTP, L2TP/IPSec and IPSec tunnel mode). These 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.

SSL VPNs represent a diverse collection of remote access technologies and work very differently from vendor to vendor. However, there are a handful of issues that are common to almost all SSL VPN deployments. These issues involve:

  • Certificate deployment and PKI Infrastructure
  • User and computer authentication protocols
  • DNS host name resolution
  • Web browser configuration and interposed firewalls and proxies

Certificate Deployment and PKI Infrastructure Issues

In spite of the often stark contrast between the technologies used among different SSL VPN vendors, one common thread that ties them all together is the fact that they use SSL (TLS) as their encryption protocol. SSL is used to secure data at the application layer, while leaving lower level protocols in the TCP/IP stack unencrypted.

SSL requires a Public Key infrastructure or PKI. Core components of the PKI are certificate authorities (CAs) and digital certificates. Digital certificates can be used to authenticate users and computers and are a key component to the operation of the SSL encryption protocol. Without creation and deployment of digital certificates, SSL VPNs would be impossible.

Depending on your company's requirements, you may or may not need to deploy your own PKI. You have the option of rolling out your own certificate deployment infrastructure, or you can purchase commercial certificates. The disadvantage of commercial certificates is that they can be prohibitively expensive and the disadvantage of implementing your own certificate infrastructure is that it can be prohibitively complex.

Common certificate related problems include:

  • Incorrect common or subject name on the SSL VPN gateway's or reverse proxy's server certificate
  • Absent CA certificate in the SSL VPN client's machine certificate store
  • Inability of the SSL VPN client to access the Certificate Revocation List (CRL)

When an SSL VPN client sends a connection request to the SSL VPN gateway, it must send a HTTP CONNECT request. Contained within the CONNECT is the name of the host with which the client expects to be communicating. If the subject/common name on the Web site certificate installed on the SSL VPN gateway or reverse proxy is not the same as the one included in the HTTP CONNECT sent by the client, then the SSL negotiation fails and the client receives an error message.

A PKI is all about trust. Trust is based on the fact that both the client and server trust the same certificate authority that issued the SSL VPN gateway's or reverse proxy server's Web site certificate. This requires that both the client and the SSL VPN gateway or reverse proxy have the CA certificate of the issuing CA in their Trusted Root Certification Certificate store and they must both trust the entire certificate hierarchy.

In most cases, the SSL VPN gateway has the required CA certificate installed, but the clients do not. This situation is typically seen when organizations create their own PKI. This is rarely seen when using commercial certificate authorities because the most popular root CAs are already included in Windows clients' machine certificate stores.

Poor performance

A common troubleshooting issue is related to poor performance. SSL VPN clients may take an inordinate amount of time to connect to the SSL VPN gateway or reverse proxy server, but once the SSL connection is established, things go very quickly. The most common reason for this situation is that the Certificate Revocation List (CRL) is not accessible by the SSL VPN client. You can solve this problem by either making the CRL available to Internet hosts, or by configuring the SSL VPN client's Web browser to bypass CRL checking.

User Authentication Protocol Issues

Digital certificates are used to authenticate computers. In the most typical deployment, the Web site certificate on the SSL VPN gateway or reverse proxy is used to authenticate it to the SSL VPN client. In some cases, the SSL VPN gateway or reverse proxy can also require the client machine to authenticate itself.

In contrast to client machine authentication, user authentication is always required. User authentication is a key component of the SSL VPN security model. SSL VPN clients can use any authentication protocol supported over an HTTP channel. User credentials are always presented after the SSL tunnel is established, so even clear text based user authentication protocols are secure.

Examples of user authentication protocols include:

  • Basic authentication
  • Digest authentication
  • Integrated Windows (NTLM/Kerberos) authentication
  • User certificate authentication
  • Smartcard authentication
  • RSA SecurID authentication

The value in different authentication protocols for SSL VPN deployments isn't so much based on the "strength" of the authentication protocol or its ability to obscure the username and password, as the ability to prevent unauthorized users from using a legitimate user's credentials to gain access.

Some problems related to user authentication protocols include:

  • SSL VPN client machine does not support the SSL VPN gateway's authentication protocol.
  • SSL VPN gateway cannot access an authentication server.

One of the design goals of an SSL VPN infrastructure is that users can access corporate information resources from any Web browser in the world. This "access anywhere, anytime" feature is a major reason for SSL VPN acquisition. However, not all client operating systems and devices support the same user authentication protocols.

For example, you may want to support a broad mix of clients, including Windows, UNIX, Mac and Linux SSL VPN client connections. If you configure the SSL VPN gateway to support only Windows Integrated authentication, then only the Windows clients will be able to access the gateway (for the most part). If you plan to support a broad mix of client operating systems, then you should choose Basic authentication.

The SSL VPN gateway or reverse proxy typically pre-authenticates the SSL VPN users before forwarding the connection to the server on the corporate network. This means that the SSL VPN gateway or reverse proxy must be able to communicate with the authentication servers, or maintain a user list on the gateway or proxy itself.

If the SSL VPN gateway or reverse proxy belongs to a domain, then it must be able to directly communicate with a domain controller. If the SSL VPN gateway or reverse proxy does not support domain membership, it must be able to use LDAP calls, or RADIUS messages, to communicate with the authentication server. A break anywhere in the communications chain between the gateway and authentication server will cause authentication to fail.

DNS Host Name Resolution Problems

SSL VPN clients must be able to resolve the name of the SSL VPN gateway or reverse proxy server regardless of their location. Many companies issue laptop computers that employees use for both on-site and off-site computing. In order to avoid issues with users needing to remember a different naming scheme based on their locations, it's critical that you create a split DNS supporting your SSL VPN deployment.

A split DNS splits the same domain name into two or more DNS zones, typically hosted on different physical DNS servers (although not required for DNS servers that customize their responses based on source address of the request). There must be one zone that services requests coming from hosts on the corporate network and one zone that services requests from hosts located on the Internet. A key component of the split DNS is that there is no relationship between the resource record information contained on the internal and external DNS zones. It is a common misunderstanding that a split DNS presents a security risk. It does not.

For example, you want users to always use the name ssl.domain.com to reach the SSL VPN gateway or reverse proxy server. You can accomplish this by creating a DNS zone on the corporate network with the name domain.com and then create a Host (A) record for ssl.domain.com in that zone which maps to the internal network IP address of the SSL VPN gateway (internal network hosts typically will not use the reverse proxy to access the SSL VPN gateway). Next, you create a DNS zone on an external DNS server for the same domain name, domain.com. This DNS server is the authoritative DNS server for Internet requests to the domain.com domain. Then you create a resource record for the public address SSL VPN clients must use to access the SSL VPN gateway. This is typically the IP address of a front-end NAT firewall or reverse proxy.

The user devices are typically configured to use DHCP for IP addressing information. When users are located on the corporate network, the DHCP server provides the DHCP clients with the IP address of the internal DNS server. When these clients access the SSL VPN gateway at ssl.domain.com, they receive the internal address of the SSL VPN gateway. When the client systems move to an external location, they will receive via DHCP the address of a public DNS server (or one that can access information on the public DNS). The public DNS server resolves ssl.domain.com to the public address that forwards the connection to the SSL VPN gateway.

A split DNS infrastructure provides transparent access to corporate hosted resources regardless of location. Users do not need to remember different names based on their current location, which can significantly reduce Help Desk call volume.

Web browser Configuration and Interposed firewall and Proxy Problems

The client side component is often the most difficult issue you have to troubleshoot. While one of the design goals of an SSL VPN is universal access through a "clientless" connection, the fact is that a Web browser (client) is required to make the SSL VPN link. This is true for all SSL VPN deployments (with the exception of the network extension SSL VPN client).

However, the only time the Web browser is the only client-side component of the SSL VPN client equation is when it connects to server services that have integrated Web support, such as Microsoft Exchange Server's Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync. If the SSL VPN gateway will provide remote access to server services that are not Web enabled, a second client piece must be added. These are typically ActiveX controls or similar browser add-ons. If the user is at a location that does not support downloading and installing extra software, then the SSL VPN connection or data access attempt will fail.

Another common problem with Web browser configuration is support for HTTP 1.1 through proxy connections. HTTP 1.1 includes a number of enhancements that improve performance and reliability for Web connections. If the SSL VPN client is located behind an HTTP 1.1 compliant Web proxy, the user might find that pages don't load properly. For example, he may experience partial page loads or receive Page Not Found errors.

If there are no errors, but the SSL VPN client tries to generate multiple requests over a single channel and not wait for replies, the user can experience significant performance issues. The solution is to configure the Web browser to support HTTP 1.1 through proxy connections.

Problem(s) solved

SSL VPNs solve some of the major problems encountered with traditional network level remote access VPN solutions. SSL VPNs are also generally easier to install, configure and maintain. Troubleshooting issues are often specific to the particular SSL VPN technologies used by the vendor. However, there are some common troubleshooting issues that extend across all SSL VPN solutions. These issues revolve around PKI, user authentication, host name resolution, Web browser configuration and interposed Web proxies and firewalls.

Editor's Picks

Free Newsletters, In your Inbox