Overview
This chapter will introduce the concepts of SSL VPNs. Cisco refers to their SSL VPN implementation as WebVPN. Cisco supports three implementations of WebVPN: clientless, thin client, and network or tunnel client. This chapter will focus on the former two and the next chapter on the latter implementation. The topics discussed in this chapter include
-
Introducing SSL VPNs and the different access methods
-
Configuring basic WebVPN components for clientless access
-
Defining group policies for WebVPN clientless users
-
Creating tunnel groups for WebVPN users
-
Becoming familiar with the clientless and thin client home page
-
Supporting non-web traffic using port forwarding, plug-ins, and smart tunnels
-
Verifying and troubleshooting clientless and thin client access
Introduction to SSL VPNs
“WebVPN” is the Cisco marketing term that describes the use of SSL to provide a VPN remote access solution. Some vendors also support LAN-to-LAN (L2L) connections, but the only current Cisco L2L technology is using IPSec. SSL VPNs are becoming more popular as a VPN solution. Common uses for SSL VPNs include accessing web-based and e-mail applications, accessing company resources from noncompany computers, and accessing a small number of non-web-based applications.
SSL was originally designed to protect data between a user’s web browser and a web server, typically for financial and security transactions. However, many networking vendors have taken this standard and adapted it to a VPN role. When using SSL, TCP is used as a transport to carry the data between the user’s desktop and the SSL gateway. SSL provides the following protection features:
-
Confidentiality RC-4, DES, 3DES, and AES encryption algorithms
-
Authentication Digital certificates and/or a username and password
-
Packet integrity MD5 and SHA-1
Compared with other VPN implementations, SSL VPNs don’t require a specialized client to be installed on the user’s desktop to set up a VPN; however, most vendor SSL VPN implementations lack anti-replay protection.
Connection Modes
Cisco’s SSL implementation supports three SSL VPN access modes:
-
Clientless mode
-
Thin client mode
-
Network client or tunnel mode
The following sections will cover the access modes in more depth.
Clientless Mode
“Clientless” is a misnomer for the first access method, since a web browser is used as a “client”; however, Cisco and other vendors use this term to describe a special client that doesn’t need to be installed on the user’s desktop: the assumption is that a web browser is already there. Cisco clientless implementation supports Windows 2000, XP, and Vista, as well as Linux and the Mac OS, where language localization can be easily integrated into the access. With clientless mode, only web-based applications are protected, with no protection for most non-web-based applications. In clientless mode, the SSL gateway acts as a proxy for the user when accessing resources behind the SSL gateway. The Cisco implementation supports proxying for HTTP, HTTPS, IFS Windows file share (CIFS, or Common Internet File Services), and e-mail (POP3S, SMTPS, and IMAP4S).
Thin Client Mode
The main limitation of clientless mode is that it doesn’t support non-web-based applications. Thin client mode was created to add support for some, but not all, of these applications. In thin client mode, the SSL gateway acts as a TCP proxy, proxying TCP connections from the user to resources beyond the gateway. Cisco supports three thin client implementations: port forwarding, plug-ins, and smart tunnels. All require that a web browser and Java 1.5 or later be installed on the user’s desktop to operate correctly.
With the thin client function, the user logs into the SSL gateway via clientless mode and then starts the thin client function; optionally you can have the thin client process start up automatically once the user logs in. Some modification of the supported applications may be necessary to successfully protect them across the SSL tunnel. Currently Cisco does not support all non-web-based applications using the thin client mode. Some common supported applications include telnet, SSH, e-mail, Citrix, VNC, Windows Terminal Services, and many others.
Tunnel Mode
The main problems of thin client mode include
-
Only a small number of TCP applications can be proxied.
-
Users might have to reconfigure their application to have it successfully tunneled across the SSL VPN.
Tunnel mode implementation was created by Cisco to deal with these problems. Tunnel mode function is more similar to how the IPSec remote access client (Easy VPN remote) functions, where most IP protocols and applications function across the tunnel without any user changes. The users use their applications as they normally would without a VPN in place. Tunnel mode requires a special Java-based client to be installed on the user’s desktop. The Cisco original tunnel mode client was called the SSL VPN Client (SVC); this has now been replaced by the AnyConnect client and is similar to the IPSec client in functionality and features. The SVC client is supported in version 7.0 through 7.2 of the ASAs and the AnyConnect client in version 8.0.
The tunnel mode client advantages over the IPSec client are that it is more user-friendly and can be automatically installed over a WebVPN clientless connection (optionally you have to send it to the user in a stand-alone install package and have the user install it manually). The tunnel mode client is only around 3 MB in size and doesn’t require a reboot after installation. However, its disadvantage is that it cannot provide the same kind of protection as the IPSec client—it lacks anti-replay capabilities.
WebVPN Restrictions
WebVPN is not supported on the PIXs, unfortunately. Cisco’s current products that support WebVPN include the ASAs, the 3000 concentrators, and the IOS routers. Cisco no longer develops code for the 3000 concentrators since they are end-of-sale (EOS). Today all initial WebVPN development is done on the ASAs and eventually ported to the routers.
| Tip | Currently the routers are about 6 to 12 months behind the ASAs in their WebVPN capabilities. So if you want the latest and greatest for WebVPN, use the ASAs. |
Here are the current restrictions when using clientless or thin client mode for WebVPN:
-
Web browser cookies must be enabled—otherwise after authenticating, the user will be asked to authenticate again (the authentication credentials are stored in cookies).
-
Port forwarding doesn’t work if CA identity certificates are used: Java doesn’t have the ability to access the client SSL certificate in the web browser key store.
-
Microsoft Outlook MAPI is unsupported for clientless and thin client; it is supported for tunnel mode connections.
-
Contexts are unsupported for any type of VPN: SSL, IPSec, PPTP, and L2TP.
-
A user cannot connect to sites that have expired certificates: the appliance will drop the connection. (Remember that the ASA is proxying the connections, and it, not the user, is the one that will reject the expired certificate.)
-
You cannot apply address translation policies to the clientless and thin client connections; however, you can for tunnel mode connections.
-
The following Modular Policy Framework (MPF) features are unsupported for clientless and thin client connections: application inspection, QoS and traffic policing, and connection limits; however, tunnel mode connections are supported.
| Note | By default an ASA only supports a license for two WebVPN sessions—you need to purchase the appropriate license for the number of simultaneous WebVPN sessions you’ll need to support. |
Basic WebVPN Configuration
The remainder of this chapter will focus on setting up an ASA as an SSL VPN gateway for clientless and thin client connections. Chapter 20 will cover tunnel mode connections. In this section, I’ll cover some basic concepts on setting up WebVPN on the ASAs, including defining SSL connection policies, enabling WebVPN, allowing for both WebVPN and ASDM on the same interface, using DNS to resolve names to addresses, having an external web proxy to proxy the traffic instead of the ASA, and defining general WebVPN access properties.
Implementing SSL Policies
The following two sections will discuss how to exempt WebVPN inbound connections from ACL checks and controlling the encryption algorithm(s) the user can use for the SSL traffic.
Allowing WebVPN Traffic
By default WebVPN traffic is not exempted from ACL checks when going from a lower- to higher-level interface; once the traffic is decrypted, it is run through the inbound ACL on the lower-level interface. You must either include permit statements for the decrypted traffic in the ACL, or implement the ACL bypass feature, which I covered in Chapter 15. To implement the ACL bypass feature, execute the following command:
ciscoasa(config)# sysopt connection permit-vpn
This command exempts all decrypted VPN traffic, including SSL VPNs, from being processed by the ACL on the inbound interface.
Controlling SSL Encryption Algorithms Used
One problem with SSL is that even though many encryption algorithms are supported, the user’s web browser ultimately controls what algorithm to use, the weakest of which is RC-4. You can restrict what encryption algorithms and SSL versions are used with the following configuration:
ciscoasa(config)# ssl encryption {3des-sha1 | aes128-sha1 |
aes256-sha1 | des-sha1 | rc4-md5 |
rc4-sha1 | null-sha1}
ciscoasa(config)# ssl server-version {any | sslv3 | sslv3-only |
tlsv1 | tlsv1-only} The defaults are to allow any encryption algorithm and any SSL version. The ssl encryption command is used to restrict the encryption algorithm(s) and HMAC functions that can be used by the user’s web browser. The ssl server-version is used to restrict the SSL version the user’s web browser is allowed to use. By default all versions are allowed; the most secure is SSL version 3.
Enabling WebVPN
Enabling WebVPN is an easy proposition. Most WebVPN commands are executed in the WebVPN subcommand mode (webvpn command):
ciscoasa(config)# webvpn
ciscoasa(config-webvpn)# enable logical_if_name
ciscoasa(config-webvpn)# port port_#
First, you must enable WebVPN with the enable command, specifying the logical name of the interface it will be enabled on, like outside. Optionally you can change the SSL port number used for HTTPS connections with the port command; if you omit this, it defaults to 443.
I would highly recommend that you configure port redirection: most users forget to type in "https://" when accessing the ASA, and instead enter "http://". You can set up port redirection, where, if the user connects to port 80 on the ASA, the ASA will automatically redirect the web browser to port 443. This is accomplished with the http redirect command:
ciscoasa(config)# http redirect logical_if_name port_#
Here’s an example:
ciscoasa(config)# http redirect outside 80
This command will redirect port 80 connections to the HTTPS port (443 by default).
| Tip | Using port redirection will greatly cut down on the number of phone calls from forgetful users trying to connect by using clientless or thin client mode to the ASA when they forget to type in https:// in the address bar of their web browser. |
Supporting Both WebVPN and ASDM
ASDM, discussed in Chapter 27, is a GUI interface used to manage the appliance. ASDM uses SSL to protect the interaction between the administrator’s PC and the appliance. WebVPN and ASDM can coexist on the same interface; however, they both can’t use port 443 for their SSL connections, which is the default for both if not overridden. In WebVPN, you can change the port number with the port command in the WebVPN subcommand mode, but then users have to remember what port to use for their SSL tunnels. Instead, I recommend that you change the port number for ASDM. Here’s the syntax for specifying the ASDM port:
ciscoasa(config)# http server enable port_#
Here’s an example that listens for ASDM on port 444:
ciscoasa(config)# http server enable 444
ciscoasa(config)# http 192.168.3.0 255.255.255.0 outside
To access ASDM, use https://IP_address:444, as an example. ASDM is discussed in Chapter 27.
Performing DNS Lookups
When acting as a proxy for WebVPN, the ASA must be able to resolve names (found in URLs) to IP addresses using DNS. By default DNS lookups are not configured on the ASAs. Here’s the basic configuration to enable DNS lookups and to specify a DNS server(s) to use:
ciscoasa(config)# dns lookup logical_if_name
ciscoasa(config)# dns name-server IP_address [...IP_address6]
ciscoasa(config)# dns server-group DNS_server_group_name
ciscoasa(config-dns-server-group)# domain-name domain_name_for_group
ciscoasa(config-dns-server-group)# name-server IP_address
ciscoasa(config-dns-server-group)# retries #_of_retries
ciscoasa(config-dns-server-group)# timeout seconds
To allow DNS lookups to occur on a particular interface, use the dns lookup command; this specifies the interface a DNS server is connected to. To globally define DNS servers to use, configure the dns name-server command—you can list up to six DNS server addresses.
Optionally you can create different groupings of DNS servers to be used by different tunnel groups (different groups of users), which override the global DNS server configuration. To create a DNS server group, use the dns server-group command. The name you enter here must be referenced in the tunnel group configuration (discussed later in the chapter). The domain-name specifies for what domains the configured servers of the group will resolve addresses. When doing a DNS lookup, the default number of retries is 2 and the default timeout is 2 seconds—these can be changed globally or overridden in the DNS server group configuration with the retries and timeout commands respectively.
To see the DNS host table of resolved hostnames, use the show dns-hosts command:
ciscoasa# show dns-hosts
Host Flags Age Type Address(es)
a1.dealgroup.com (temp, OK) 0 IP 10.0.1.11
a2.dealgroup.com (temp, OK) 0 IP 10.0.1.12
server.dealgroup.com (temp, OK) 0 IP 10.0.1.99 Implementing Web Proxying
For clientless connections, you have two approaches to performing the proxy process for the web connections: have the appliance perform the proxying, or use an external web proxy. The next section will discuss how to use an external web proxy. If the ASA is performing the proxy process, you might want to enable web caching to speed up the download process—this is discussed in the second section.
Defining External Web Proxies
Instead of having the ASA proxy the web connections, you can have an external proxy server perform this function, thereby offloading this process-intensive process to a different device. The http-proxy and https-proxy commands perform this function:
ciscoasa(config)# webvpn
ciscoasa(config-webvpn)# {http-proxy | https-proxy} host_IP [port]
[exclude url] [username username
{password password}]
ciscoasa(config-webvpn)# {http-proxy | https-proxy}
pac URL_for_pacfile} The host_IP is the proxy server; you can optionally change the port number the proxy server is listening on.
Here’s a simple example of configuring an external proxy:
ciscoasa(config)# webvpn
ciscoasa(config-webvpn)# http-proxy 10.0.1.15
Optionally you can exclude URLs that are forwarded to the proxy, using these additional special expressions:
-
* To match any string, including slashes (/) and periods (.). You must accompany this wildcard with a character string, like “*.cisco.com”.
-
? To match any single character, including slashes and periods.
-
[x-y] To match any single character in the range of x and y, where x represents one character and y represents another character in the character set.
-
[!x-y] To match any single character that is not in the range.
Here’s an example that excludes all URLs for “mycompany.com” for the 10.1.1.1 proxy to handle:
ciscoasa(config-webvpn)# http-proxy 10.1.1.1 port 80
exclude *.mycompany.com
If the proxy requires a username and password, you can provide this information. Here’s an example:
ciscoasa(config-webvpn)# http-proxy 10.0.1.15 username proxyuser
password myhiddenpassword
The pac parameter identifies a proxy autoconfiguration file (using a URL) to download to the user’s web browser. Once it is downloaded, the PAC file uses a JavaScript function to identify a proxy for each URL the user tries to access. This allows you to use different proxies for different web connections. Here’s an example:
ciscoasa(config-webvpn)# http-proxy pac http://www.example.com/pac
Implementing Web Caching Policies
You can have the appliance cache web information when it acts as a proxy and control the cache process with a group policy configuration. Here are the commands to control the caching process:
ciscoasa(config)# webvpn
ciscoasa(config-webvpn)# cache-fs limit size_in_MB
ciscoasa(config-webvpn)# cache
ciscoasa(config-webvpn-cache)# cache-static-content enable
ciscoasa(config-webvpn-cache)# disable
ciscoasa(config-webvpn-cache)# expiry-time minutes
ciscoasa(config-webvpn-cache)# lmfactor value
ciscoasa(config-webvpn-cache)# min-object-size size_in_KB
ciscoasa(config-webvpn-cache)# max-object-size size_in_KB
commands control the size of objects that can be cached for WebVPN sessions by the ASA.
Defining General WebVPN Properties
Some general properties you can define for clientless access include the following:
ciscoasa(config)# webvpn
ciscoasa(config-webvpn)# default-idle-timeout seconds
ciscoasa(config-webvpn)# internal-password enable
ciscoasa(config-webvpn)# keepout "string"
ciscoasa(config-webvpn)# onscreen-keyboard {all | logon} The default idle timeout for clientless WebVPN connections is 30 minutes (1800 seconds). This can be globally changed with the default-idle-timeout command. If the WebVPN password is different than what an internal web server uses, you can have the user supply both passwords, where the first is used by the ASA and the second by the internal server. You need to use the internal-password enable command to enable this feature. When you need to temporarily take WebVPN out of service, you can have a particular text string displayed on the screen instead of the login page. This is configured with the keepout command. If you are concerned about keystroke capturing programs during the WebVPN login process or afterward, you can have an onscreen keyboard displayed, where the users use their mouse to enter their login credentials or information after they log in. The onscreen-keyboard command enables this feature—this feature is disabled by default.
