SSL VPNs with Cisco ASA - Secure Connectivity - Implementing Cisco IOS Network Security (IINS) Foundation Learning Guide, Second Edition (2013)

Implementing Cisco IOS Network Security (IINS) Foundation Learning Guide, Second Edition (2013)

Part IV: Secure Connectivity

Chapter 15. SSL VPNs with Cisco ASA

Upon completing this chapter, you will be able to describe the Secure Sockets Layer (SSL) VPN operational framework. You will be able to demonstrate the deployment of basic SSL VPNs on Cisco Adaptive Security Appliances (ASA) using Cisco Adaptive Security Device Manager (ASDM) and the Cisco AnyConnect VPN Client. This chapter prepares you to meet these objectives:

• Describe the use cases and operational requirements of Cisco SSL VPNs

• Describe the protocol framework for SSL and TLS

• Describe a configuration that is based on SSL VPN deployment options and other design considerations

• Describe the steps to configure Cisco VPN clientless mode on Cisco ASA and demonstrate the configuration on Cisco ASDM

• Describe the steps to configure Cisco full-tunnel mode on Cisco ASA and demonstrate the configuration on Cisco ASDM using the Cisco AnyConnect VPN Client

Mobility and IT consumer market trends influence the need for comprehensive remote-access security policies. SSL VPNs are commonly used as a remote-access service. As such, SSL VPNs must integrate strong cryptography and standards-based components with deployment and operational efficiencies and endpoint security. This chapter describes the SSL protocol framework and describes the benefits of the Cisco SSL VPN solution. The chapter also demonstrates the configuration of clientless and full-tunnel SSL VPNs using Cisco ASDM and the Cisco AnyConnect VPN Client.

SSL VPNs in Borderless Networks

Remote-access and mobility services have gone through drastic changes in the past few years. There are three market transitions driving the network architectures of the future:

Mobility: Over the next three years, there will be more than 1.3 billion new networked mobile devices. These devices will include mobile Internet devices, notebooks, smartphones, notebooks, tablets, and other devices.

Video: Video has truly become pervasive in both consumer and business environments. No longer simply a means of communication, it has become a key factor in reducing training and travel costs. It is also beginning to reshape business models, especially in retail.

IT consumerization: This is essentially what can be called the new workplace experience, in which consumer demand and new consumer devices influence technology decisions made by IT departments. Globalization has created a need for partners, customers, and employees to connect to each other and to the Internet over traditional boundaries from a variety of environments and devices.

These three market transitions are changing the IT environment and the strategic role that the network plays in delivery of new services. These market factors will influence the features that are found in remote-access products and technologies.

These transitions are also placing significant demands on the typical functions of the IT organization. Functional needs have remained similar: scalability, availability, performance, security, manageability, and cost of ownership. But as new (and potentially untrusted) devices connect to the network from multiple (and potentially untrusted) places, and as the IT organization moves beyond the infrastructure it can directly control, these parameters have become much more complex. In fact, the parameters are no longer linear; they are multidimensional, and the IT organizations, therefore, are struggling to meet their requirements in terms of the underlying network infrastructure.

The main challenges to IT organizations in providing remote and mobile access to corporate resources include the following:

• They need to provide an improved access experience, providing everywhere connectivity and management whether through wired, wireless, or remote access.

• To support the increasing number of mobile workers, corporate security administrators must provide context-aware security and policy enforcement. They must extend the application experience, regardless of the locations of the end users, what devices they are using, what network they are on, and where the information they are accessing is located. Administrators must also be able to support a heterogeneous set of laptops and mobile devices to encourage choice for their clients—the end users. Finally, they must provide this security unobtrusively and agnostic of the access network to minimize end-user concerns.

• The days of the standard corporate device are over. Businesses must meet the first two challenges in a way that will allow them to embrace the wave of new devices—smartphones and tablets, in addition to the traditional laptops—that workers are using.

Cisco SSL VPN

The Cisco SSL VPN technology provides remote-access connectivity from almost any Internet-enabled location with a web browser and its native SSL encryption. Cisco SSL VPN provides the flexibility to support secure access for all users, regardless of the endpoint host from which they establish a connection. If application access requirements are modest, SSL VPN does not require a software client to be preinstalled on the endpoint host. This ability enables companies to extend their secure enterprise networks to any authorized user by providing remote-access connectivity to corporate resources from any Internet-enabled location.

Cisco SSL VPN currently delivers three modes of Cisco SSL VPN access: clientless, thin client, and full client, as shown in Figure 12-2, earlier in this book. Cisco SSL VPNs allow users to access web pages and services, including the ability to access files, send and receive email, and run TCP-based applications without IPsec VPN client software. Cisco SSL VPNs are appropriate for user populations that require per-application or per-server access control, or access from desktops not owned by the enterprise.

In many cases, IPsec and Cisco SSL VPNs are complementary because they solve different problems. This complementary approach allows a single device to address all remote-access user requirements.

The primary benefit of Cisco SSL VPN is its ubiquity and versatility. SSL is available on computers, tablets, and smartphones. You use it when you shop or bank online.

An additional benefit of Cisco SSL VPN is that it is compatible with Dynamic Multipoint VPNs (DMVPN), Cisco IOS Firewalls, IPsec, intrusion prevention systems (IPS), Cisco Easy VPN, and Network Address Translation (NAT).

SSL VPNs and IPsec VPNs are complementary technologies that you can deploy together to better address the unique access requirements of diverse user communities. Both offer access to virtually any network application or resource. Cisco SSL VPNs offer additional features such as easy connectivity from desktops outside your company’s management, little or no desktop software maintenance, and user-customized web portals upon login.

Table 15-1 shows the most significant differences between IPsec VPNs and Clientless SSL VPNs. IPsec excels in the number of applications that are supported, the strength of its encryption, the strength of its authentication, and its overall security. The areas in which Clientless SSL VPN excels are its ease of use and ease of deployment.

Table 15-1. Clientless SSL VPN Versus IPsec VPN

When used for VPN connectivity, SSL does not require any special-purpose client software to be preinstalled on the system. Cisco SSL VPNs are also known as “clientless VPNs” because they rely on the existence of web browsers on the connecting host, a pre-installed client that already supports the protocol. This feature makes SSL VPNs capable of “anywhere” connectivity from company-managed desktops and non-company-managed desktops, such as employee-owned PCs, contractor or business partner desktops, and Internet kiosks. Any software that is required for application access across the SSL VPN connection is dynamically downloaded on an as-needed basis, minimizing desktop software maintenance.

Traditionally, when security was a primary issue, IPsec was the preferred choice. If support and ease of deployment were the primary issues, then SSL was considered. Nowadays, SSL VPN is usually considered the preferred choice, especially because it provides security comparable to IPsec. Cisco VPN products support both technologies in order to satisfy the largest number of customer requirements.

SSL and TLS Protocol Framework

Transport Layer Security (TLS) and its predecessor, SSL, are cryptographic protocols that provide secure communications on the Internet for such things as web browsing, email, Internet faxing, instant messaging, and other data transfers. Originally developed by Netscape, SSL has been universally accepted on the World Wide Web to transfer information privately over the Internet. Virtually all online transactions and browser-based monetary interactions that occur on the Internet are secured by SSL.

As mentioned earlier, SSL has evolved from Netscape’s original implementation. TLS is a standards-based alternative to SSL.

SSL and TLS provide confidentiality, integrity, and authentication services to the applications that use them. In that sense, these protocols encrypt and authenticate from the session layer up, including the presentation and application layers.

SSL is used to encrypt and authenticate the session layer and above. As such, it encrypts more than just HTTP (called HTTPS); it can also encrypt FTP (thus FTPS), POP (for POPS), LDAP (for LDAPS), wireless security (EAP-TLS), and others.

Cryptographically, SSL and TLS rely on public key infrastructure (PKI) and digital certificates for authenticating the VPN endpoints. In e-commerce environments, typically only the server side is authenticated and requires a digital certificate. Other applications are increasingly using mutual authentication, where both the client and the server use digital certificates to identify themselves.

Figure 15-1 shows the encapsulation of SSL/TLS.

Figure 15-1. SSL/TLS Encapsulation

SSL and TLS

There are slight differences between SSL and TLS, but the protocols remain largely similar. The terms are sometimes used interchangeably, but interestingly, the protocols are not interoperable. Some implementations include provisions to switch to the other protocol if necessary for a given session, especially in the case of TLS, which incorporates mechanisms to switch to SSL if the client connection requires it.

TLS 1.0 originated from SSL 3.0, and later versions of both protocols show a similar development path. Table 15-2 lists some of the differences.

Table 15-2. SSL and TLS


DTLS

TLS has a sister protocol called DTLS, for Datagram Transport Layer Security. The main difference between TLS and DTLS is that DTLS gets encapsulated in UDP at Layer 4, while TLS gets encapsulated in TCP, as shown in Figure 15-1.


SSL Cryptography

The SSL and TLS protocols support the use of a variety of different cryptographic algorithms, or ciphers, for use in operations such as authenticating the server and client to each other, transmitting certificates, and establishing session keys. Symmetric algorithms are used for bulk encryption, asymmetric algorithms are used for authentication and the exchange of keys, and hashing is used as part of the authentication process. Figure 15-2 illustrates some of the supported algorithms (in the figure, EC stands for Elliptic Curve).

Figure 15-2. Supported SSL Cryptographic Cipher Suites


Note

The listed encryption algorithms are just examples for SSL and TLS support. Multiple other cipher suites are supported but not listed.


SSL Tunnel Establishment

Figure 15-3 gives a simplified explanation of the key steps in establishing an SSL session:

Step 1. The user makes an outbound connection to TCP port 443.

Step 2. The security appliance responds with a digital certificate, which contains a public key that is digitally signed by a trusted certificate authority (CA). The ASA can also present a self-signed certificate. The client will have to accept the security warning mentioning that the validity of the signature cannot be confirmed, but the self-signed certificate is useable.

Step 3. The user computer generates a shared-secret, symmetric key that both parties will use.

Step 4. The shared secret is encrypted with the public key of the security appliance and transmitted to the router. The security appliance software is able to easily decrypt the packet using its private key. Now both participants in the session know the shared-secret key.

Figure 15-3. Major Steps of SSL VPN Tunnel Establishment

SSL utilizes encryption algorithms with key lengths that range from 40 to 256 bits.

SSL Tunnel Establishment Example

SSL and PKI, as explained in Chapter 12, are complex topics. Figure 15-4 and the following steps explain the essence of how an HTTPS session is established. This example is not meant to provide you with a detailed and accurate account of how an HTTPS session is set up, but rather to provide an understandable example without all the technicalities.

Figure 15-4. Example of an HTTPS Session

Steps A to I illustrate steps between the Blue Bank server and VeriSign.

Steps 1 to 11 illustrate steps between the HTTPS client and the Blue Bank server.

Step A. As a root CA, the VeriSign server has created a key pair. It used its own private key to sign its own public key—this is called a self-signed certificate. (Signing of certificates will be covered in Step E.) By the way, serious organizations such as VeriSign do not use their top root certificate to sign client certificates. (The hierarchy of CAs is beyond the scope of this book.)

Step B. Blue Bank wants to start offering an online banking service. It selects VeriSign as the public CA server (CA theory was covered in Chapter 12). The Blue Bank server acquires the digital certificate of VeriSign. (The creation of digital certificates will be covered in Step D.) It is highly probably that the Blue Bank server would already have installed on it the VeriSign digital certificate. Popular desktops and server OSs, such as those from Microsoft, already have this CA certificate installed in the certificate store. One of the easiest ways to see the content of the certificate store, and thus to see the trusted root certificates installed on a server or a workstation, is to start Internet Explorer and navigate to Tools > Internet Options, click the Content tab, click the Certificates button, and then click the Trusted Root Certification Authorities tab.

Step C. Blue Bank generates a private and public key pair.

Step D. Blue Bank petitions VeriSign to validate its public key in order to generate a digital certificate.

Step E. VeriSign proceeds to turn the Blue Bank public key into a digital certificate by adding information to the public key. Some of the fields added to the public key, as shown in Figure 15-4, are Subject Name (it could be Blue Bank URL), Validity (dates), and so forth.

Step F. VeriSign hashes some of the fields included with the information of the Blue Bank digital certificate and produces a digest.

Step G. VeriSign encrypts the digest and encrypts it with its private key. We now have a digital signature; so the definition of a digital signature is: a hash encrypted with a private key.

Step H. The Blue Bank digital certificate has been created. What is the Blue Bank digital certificate? It’s a validated public key signed by the CA.

What is a validated public key? It’s the public key, with fields added to it.

What is a signature? It’s the hash result encrypted with the CA private key.

Step I. Blue Bank installs its digital certificate, which is Blue Bank’s public key, signed by the CA.

Now, as a Blue Bank customer, you wish to open an online banking session, using your laptop.

Step 1. Your laptop is equipped with the root certificate of the CA used by Blue Bank, VeriSign. If the server on which you want to open an SSL session had its digital certificate issued by a CA that you are unfamiliar with, you would need to download the root certificate onto your computer. In our scenario, the laptop is running a popular OS and already has a copy of the VeriSign digital certificate in its certificate store.

Step 2. Your laptop browser queries the Blue Bank server to see if it accepts HTTPS sessions.

Step 3. Because Blue Bank accepts SSL sessions, the server sends a copy of its digital certificate to the laptop. Actually, sending a copy of the Blue Bank digital certificate happens only the first time that the particular laptop connects to the Blue Bank server. After that, the server and the client will only check whether they are using the right Digital Certificate Serial number (it’s one of the fields in Step E). When Blue Bank puts a new certificate in production, either because the previous one has expired or because the key has been compromised, it will ask the laptop for a certificate number that the laptop hasn’t heard about yet. In that case, the Blue Bank server will then push the new certificate to the laptop.

Step 4. The client proceeds to validate the certificate. It checks for the validity date and the name of the issuer. Because the client already knows about the issuer of the certificate, in this case VeriSign, it proceeds to validate the signature. To do so, it first hashes the pre-agreed fields from the digital certificate to get a digest.

Step 5. Continuing with the validation of the Blue Bank digital certificate, the client decrypts the signature originally created by VeriSign’s private key (Step G). To decrypt that signature, the client uses the VeriSign public key acquired in Step 1. If the hash digest calculated by the client in Step 4 matches the result found by decrypting the digital signature in Step 5, then the client knows two things for sure: the issuer (signing authority) was indeed VeriSign, and no one tampered with the content of the certificate. The authenticity of the certificate is proven by the fact that the client was successful at decrypting the signature using VeriSign’s public key, which means that the signature was created in the first place by VeriSign’s private key. And who has VeriSign’s private key? Only VeriSign—and it’s guarded ferociously.

Step 6. The ultimate goal of the client is to have an HTTPS session with the server, as shown in Step 12. This HTTPS session will use symmetric cryptography because it is much faster than asymmetric cryptography. The client and the server must at this stage agree on the encryption that they will use for the symmetric encrypted session in Step 12. Let’s say for our scenario that the client and the server agree that the encryption algorithm will be RC4-128 (Rivest Cipher, 128-bit) and exchange other essential information.

Step 7. As part of the process of coming up with a symmetric encryption key that will be used in Step 12, the client generates a value (called the pre-master value, also referred as a session key in Figure 15-4) that will be used to finalize the symmetric key used by the server and client.

Step 8. The pre-master value (session value) needs to be shared confidentially with the server, so the client encrypts it with the server’s public key, found with the Blue Bank digital certificate received in Step 3.

Step 9. The encrypted pre-master value (session value) is sent to the server.

Step 10. Using its private key, the Blue Bank server can decrypt the data it just received from the client and discover the pre-master value (session value) that is to be used in the fabrication of a symmetric encryption key.

Step 11. Both the client and the server now have a copy of the pre-master value (session value) and all the other values necessary to generate the same session key. They independently arrive at the same result, and that result is the symmetric key they will use for their SSL session.

Step 12. The SSL tunnel comes up. Only then will some browsers show you a padlock near the URL bar, and only then will Blue Bank present you with the login page where you will be required to provide your banking card number and password.

When the client gracefully logs out of the session or when the session times out, the client and the server both forget the session key that was generated in Step 11.

Cisco SSL VPN Deployment Options and Considerations

As shown in Chapter 12 (in Figure 12-2), Cisco SSL VPNs offer different types of access options: SSL Clientless and SSL full client mode, referred to as Cisco AnyConnect SSL VPN. A third option exists as SSL Clientless thin-client, which provides some more functionality with the SSL Clientless. Figure 15-5 shows the use case for the different ways to access the corporate network remotely.

Figure 15-5. SSL VPN Access Scenarios

Figure 15-5 shows the usage scenario for the following three types of SSL access:

Clientless: This option enables a user to connect to the network with few requirements beyond a basic web browser. The access provides the ability to reach web servers or webified resources such as file shares.

Thin client: A small applet or application (generally under 100 KB) is downloaded that provides access to a subset of application resources, generally TCP, and often an outbound and static port. This thin-client is part of the Clientless option.

SSL VPN client: A larger client is delivered to the end user and is required when users need full application access. The applications that can be accessed are very similar to those available via IPsec VPN. This client is delivered via a web page (the device that the user is connecting to) and never needs to be manually distributed or installed. This client is referred to as Cisco AnyConnect.

The architecture includes VPN termination points (Cisco IOS routers or ASA) and the Cisco AnyConnect VPN Client.

Figure 15-6 illustrates the differences between the two main deployment modes that are found in Cisco SSL VPN solutions:

• Clientless mode is easier to deploy but presents additional challenges in terms of endpoint security and application access.

• Full network access supports a wider variety of applications but presents additional operational challenges in downloading and maintaining the client software on remote hosts.

Figure 15-6. Two Main SSL Deployment Modes

SSL VPNs provide a flexible way of extending network resources and applications to remote users. When using a clientless SSL VPN deployment model, corporations have the additional flexibility of providing access to corporate resources even when the remote device is not corporately managed. In this deployment model, the Cisco ASA is used as a proxy device to network resources and provides a web portal interface for remote devices to navigate the network. Additionally, to access the SSL VPN network, the remote device system only requires a supported web browser with built-in SSL functionality. Although more flexible than client-based SSL VPNs, clientless SSL VPNs provide only limited network application or resource access and include additional security risks when using non-corporate-managed clients.

Full network access SSL VPNs operate much like standard IPsec VPN clients in the way that they provide network access. In comparison to the clientless SSL VPN deployment model, there are no network access restrictions for resources or applications. Full network access SSL VPNs require more planning for network deployment because they require a client to be installed on the remote systems. This requirement makes it difficult to deploy on non-corporate-managed systems because most SSL VPN clients require administrator privileges to install. The use of corporate-managed systems provides tighter control over endpoint security.

Cisco SSL VPN Client: Full Network Access

With an SSL VPN client (Layer 3), an SSL-VPN tunneling client is needed because users need full application access. Users need to use applications such as Microsoft Outlook, Cisco IP Communicator, Lotus Notes, Lotus Sametime, PeopleCube Meeting Maker, Telnet, Secure Shell (SSH), X Window System, and so on, but without having to install and administer an IPsec VPN software package. Cisco SSL VPN clientless and port-forwarding modes are not capable of this level of functionality.

The Cisco AnyConnect VPN client, using secure SSL connections to the security appliance, provides remote users with full VPN tunneling to corporate resources. This client is delivered via a web page (hosted on the Cisco ASA to which the user is connecting) and never needs to be manually distributed or installed.

The following are among the many features of the Cisco AnyConnect VPN client:

Optimal gateway selection: Determines and establishes connectivity to the most optimal network access point, eliminating the need for end users to determine the nearest location.

Mobility-friendly: Designed for mobile users, it can be configured so that the VPN connection remains established during IP address changes, loss of connectivity, hibernation, or standby.

Broad operating system support:

• Windows 7 32-bit (x86) and 64-bit (x64)

• Windows Vista 32-bit (x86) and 64-bit (x64), including Service Packs 1 and 2 (SP1/SP2)

• Windows XP SP2+ 32-bit (x86) and 64-bit (x64)

• Mac OS X 10.5 and 10.6.x

• Linux Intel (2.6.x kernel)

• Apple iOS 4 (requires an optional AnyConnect Mobile license)

• Windows Mobile 5.0, 6.0, and 6.1 (Professional and Classic) (requires an optional AnyConnect Mobile license)

• Android 2.1 and up

Wide range of deployment and connection options:

• Predeployment, including Microsoft Installer, or automatic headend deployment (administrative rights are required for initial installation) via ActiveX (Windows only) and Java

• Connection modes:

• Standalone via system icon

• Browser initiated (web launch)

• Clientless portal initiated

• CLI initiated

• Application programming interface (API) initiated

Ease of client administration: Allows an administrator to automatically distribute software and policy updates from the headend security appliance, eliminating administration that is associated with client software updates.

Preconnection posture assessment (Premium license required): In conjunction with Cisco Secure Desktop, Host Scan verification checking seeks to detect the presence of antivirus software, personal firewall software, and Windows service packs on the endpoint system before granting network access.

Client firewall policy: Added protection for split tunneling configurations, used in conjunction with Cisco Secure Mobility to allow for local access exceptions (for example, printing, tethered device support, and so on).


The Many Faces of AnyConnect

When we hear references to AnyConnect, most of us think of the SSL VPN full tunnel client mode. However, AnyConnect is now much more than that. AnyConnect Release 3.0 integrates many modules that offer functionality on wired, wireless, and remote-access networks; many of those modules were standalone clients in the past. As an example, in the past, looking under your Start menu, you might see a Cisco SSL VPN client, a Cisco 802.1x client, a Cisco ScanSafe client, a Cisco NAC client, a Cisco VPN IPsec client, and so forth. Those independent Cisco clients have been migrated to modules that now are integrated under the Cisco AnyConnect umbrella. So, Cisco AnyConnect now is your “network access unified client.” In this chapter, however, we will strictly see the SSL VPN full tunnel client mode aspect of AnyConnect.


SSL VPN on Cisco ASA in Clientless Mode

The following is the procedure for configuring a clientless SSL VPN using Cisco ASDM. The configuration process is demonstrated in this section following the presentation of the configuration scenario.

Task 1. Launch the Clientless SSL VPN Wizard from ASDM.

Task 2. Configure the SSL VPN interface.

Task 3. Configure user authentication.

Task 4. Configure user group policy.

Task 5. Configure a bookmark list.

Task 6. Verify the Clientless SSL VPN Wizard configuration.

Clientless Configuration Scenario

Figure 15-7 shows a sample configuration topology that we will use for our scenario. All screen shots that follow are based on this scenario. We will use ASDM to configure the ASA firewall.

Figure 15-7. Clientless SSL VPN Configuration Topology

In this scenario, a clientless SSL VPN session is established from a remote client and terminates on the ASA. The user will land on the ASA default portal page, customized to include bookmarks to provide access to internal resources such as file servers.

Task 1: Launch the Clientless SSL VPN Wizard from ASDM

In Cisco ASDM, choose Wizards > VPN Wizards > Clientless SSL VPN Wizard, as shown in Figure 15-8. When the wizard launches, the first page provides an introduction to the Cisco AnyConnect VPN client product. Although it’s not labeled as such, the introduction page is the first step of the wizard.

Figure 15-8. Launching the Clientless SSL VPN Wizard from ASDM on Cisco ASA

Task 2: Configure the SSL VPN Interface

Step 2 of the SSL VPN Wizard is the SSL VPN Interface page. By default, the ASA will use a self-signed certificate to send to the client for authentication. If required, the ASA may be configured to use a certificate that is purchased from a well-known certificate authority, such as VeriSign, to connect clients. In the event that a certificate is purchased, you may select it in the Certificate drop-down menu of the Digital Certificate section, as described in the following steps.

To configure the SSL VPN interface, complete the following steps, demonstrated in Figure 15-9:

Step 1. Enter a name for the clientless SSL VPN connection in the Connection Profile Name field.

Step 2. In the SSL VPN Interface drop-down menu, choose the interface to be used with the clientless SSL VPN connection.

Step 3. (Optional) Select a third-party certificate that has been installed on the ASA for use in connecting SSL VPN clients. If no certificates were installed, as in our scenario, the ASA will use a self-signed certificate.

Step 4. Click Next.

Figure 15-9. Configuring the SSL VPN Interface on Cisco ASA


Note

The SSL VPN Interface screen in the SSL VPN Wizard provides several links in the Information section. These links identify the URLs that need to be used for the SSL VPN service access (login) and for Cisco ASDM access (to access the Cisco ASDM software download).


Task 3: Configure User Authentication

User authentication may be managed by external authentication servers (such as RADIUS) or it may be managed locally by using the ASA local user database.

To configure user authentication using the local user database, complete the following steps, illustrated in Figure 15-10:

Step 1. Click the Authenticate Using the Local User Database radio button.

Step 2. Enter a username and password for the desired user.

Step 3. Click Add to add the user to the local user database.

Step 4. Click Next.

Figure 15-10. Configuring User Authentication for Cisco SSL VPN on Cisco ASA

Task 4: Configure User Group Policy

On the Group Policy wizard page, you may select an existing user group policy to modify or you may add a new user group policy for the clientless SSL VPN connection.

To create a new user group policy, complete the following steps, as shown in Figure 15-11:

Step 1. Click the Create New Group Policy radio button.

Step 2. Enter a name for the new user group policy.

Step 3. Click Next.

Figure 15-11. Configuring User Group Policy for Cisco SSL VPN on Cisco ASA


Note

By default, the created user group policy inherits its settings from the default group policy, DfltGrpPolicy. You may modify these settings after you have completed the SSL VPN Wizard by navigating to the Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies submenu.


Task 5: Configure a Bookmark List

A bookmark list is a set of URLs that is configured to be used in the clientless SSL VPN web portal. By default, there are no configured bookmark lists and they must be configured by the network administrator.

To create a bookmark list and add bookmark entries to it, complete the following steps, as shown in Figures 15-12 and 15-13:

Step 1. Click Manage to create a new bookmark list.

Step 2. In the Configure GUI Customization Objects dialog box, click Add to add a bookmark list that is based on the included template.

Step 3. In the Add Bookmark List dialog box, enter the bookmark list name in the corresponding field and click Add to create bookmarks for this list.

Step 4. The Add Bookmark dialog box opens, shown in Figure 15-13. Enter a name for the bookmark in the Bookmark Title field.

Figure 15-12. Configuring a Bookmark List for Cisco SSL VPN on Cisco ASA

Figure 15-13. Creating a Bookmark List


Bookmark List

Think of the bookmark list as a bookmark container. Within that container, you will have listed multiple URLs for HTTP, HTTPS, FTP, and CIFS servers, which will be demonstrated next. Also, you could have destinations to SSL thin-client services listed in this bookmark list, such as RDP, Telnet, and SSH. For more details on thin clients, refer to CCNP Security VPN 642-648 Official Cert Guide, Second Edition, by Howard Hooper (Cisco Press, 2012).


Step 5. Enter the URL value for the bookmark as cifs. The following list of URL values is displayed in the drop-down menu:

• http

• https

• cifs

• ftp

Step 6. Enter the server destination IP address or hostname to be used with the bookmark entry.

Step 7. (Optional) Enter the URL endpoint browser that can fetch certain information that is sent along to the webserver or web application.

Step 7. (Optional) Enter the name in the Subtitle field. The subtitle will appear under the bookmark entry on the web portal.

Step 8. (Optional) Select the thumbnail image to be used with this bookmark entry in the Thumbnail field.

When you’re finished creating a bookmark and click OK, you are brought back to the Add Bookmark List page. Click OK on the Add Bookmark List page to return to the wizard bookmark list page, where you click Next to return to the Summary page.


Note

To use thumbnails with bookmarks, the images must first be uploaded to the ASA.


Task 6: Verify the Clientless SSL VPN Wizard Configuration

Verify that the information that was entered in the SSL VPN Wizard is correct. As shown in Figure 15-14, click Finish to finish the wizard and send the configuration to the ASA.

Figure 15-14. Verifying the SSL VPN Configuration Created by the ASDM SSL VPN Wizard

Log In to the VPN Portal: Clientless SSL VPN

For verification, open a compliant web browser and enter the login URL for the SSL VPN into the address field, as shown in the upper-left portion of Figure 15-15. The address that you enter should be the configured address URL.

Figure 15-15. Logging In to the VPN Portal Using Clientless SSL VPN

Enter the previously configured username and password and click Login.


Note

The prefix to the path changes depending on whether you require authentication. The security appliance uses /+CSCOE+/ for objects that require authentication, and uses /+CSCOU+/ for objects that do not. The security appliance displays /+CSCOE+/ objects on the portal page only, while /+CSCOU+/ objects are visible and usable in either the login page or the portal page.


Once the user is logged in, the main portal page will be displayed to the user, as shown in Figure 15-16. The default homepage displays configured web application bookmarks and Common Internet File System (CIFS) bookmarks. In the event that many bookmarks are available, one or the other type of bookmarks may be selected for display by using the buttons in the left navigation pane.

Figure 15-16. Resources Accessible in the Portal

To the left of each configured bookmark is the imported thumbnail image file that is used by the bookmark. If there are other sites that must be accessed but that are not configured as bookmarks, they may be accessed using the Address bar at the top of the portal page.


Portal Customization

The login page shown in Figure 15-15, the portal page shown in Figure 15-16, and the logout page (not shown) can all be customized with colors, corporate logos, and so forth. More information on this topic can be found in the Cisco Press book CCNP Security VPN 642-648 Official Cert Guide, 2nd Edition.


SSL VPN on ASA Using the Cisco AnyConnect VPN Client

Suppose that you need more functionality than what Clientless SSL VPN, via the portal, can give you. For example, let’s say you are an engineer and need to run customized software that reaches the computer-aided design (CAD) server and prints on a plotter.

Because Clientless SSL VPN doesn’t provide you with the adequate functionality, you wish to use the Full client. You will need to configure both the ASA and the client. Though the Remote Access client, Cisco AnyConnect VPN Client gives you a choice of IPsec (IKEv2 only) or SSL full client remote access; in our scenario, we will focus only on the SSL VPN full client mode.

There are three major phases to configuring SSL VPN full-tunnel mode using Cisco ASDM so that remote clients will connect using Cisco AnyConnect:

Phase 1. Configure Cisco ASA for Cisco AnyConnect.

Phase 2. Configure the Cisco AnyConnect VPN Client.

Phase 3. Verify VPN Connectivity with Cisco AnyConnect.

These phases are discussed in turn following the presentation of the configuration scenario.

Cisco AnyConnect Configuration Scenario

For this scenario, we will use the same topology as for the portal, as shown earlier in Figure 15-7. We will add one element to this topology: an address pool for the VPN AnyConnect client. The VPN gateway, which in our example is the Cisco ASA, will provide IP addresses to connecting clients using the address pool 10.33.33.100 to 10.33.33.200.

Figure 15-17. Launching the AnyConnect VPN Connection Setup Wizard from Cisco ASDM

In our scenario, we will first initiate a clientless session. After working from the web clientless portal, we will discover that a full VPN tunnel is required to progress in our work. From the clientless portal, we will click the AnyConnect option to proceed with the Cisco AnyConnect VPN Client download and installation. We will then start an SSL VPN full-tunnel session using the newly installed AnyConnect client. All screen shots that follow are based on this scenario. We will use ASDM to configure the Cisco ASA firewall.

Phase 1: Configure Cisco ASA for Cisco AnyConnect

Eight tasks are required for configuring the Cisco ASA for AnyConnect, which will be further outlined in this section:

1. Configure the connection profile.

2. Configure VPN protocols and the device certificate.

3. Configure the client image.

4. Configure the authentication methods.

5. Configure the client address management.

6. Configure the network name resolution servers.

7. Configure the network address translation exemption.

8. Configure the AnyConnect client deployment summary.

To configure the Cisco ASA, we will use the AnyConnect VPN Connection Setup Wizard. From Cisco ASDM, choose Wizards > VPN Wizards > AnyConnect VPN Wizard to open the Introduction page of the wizard, shown in Figure 15-17.

Task 1: Connection Profile Identification

After you click Next on the Introduction page of the wizard, the first task is to configure the connection profile identification, used to identify the ASA to the remote-access users, as shown in Figure 15-18.

Figure 15-18. Setting the Connection Profile Identification

Complete the following steps:

Step 1. In the Connection Profile Name field, enter a name that remote-access users will access for VPN connections. Connection profiles appear as tunnel-group in the CLI. This connection profile name will be displayed in a drop-down list on the initial clientless session, allowing the user to log in using the profile and download the Cisco AnyConnect VPN Client. The drop-down list appears whenever you have created connection profiles in addition to the default connection profile named DefaultRAGroup—it is called group because what is called a connection profile within ASDM is called a Tunnel-Group at the CLI. So, connection profiles (found in ASDM) are also called Tunnel-Group (at the CLI).

Step 2. In the VPN Access Interface drop-down menu, choose an interface that remote-access users will access for VPN connections.

Step 3. Click Next to continue to the next page of the AnyConnect VPN Connection Setup Wizard.

Task 2: VPN Protocols and Device Certificate

The next task is to specify the VPN protocol allowed for this connection profile, as shown in Figure 15-19. The Cisco AnyConnect VPN Client defaults to SSL. If you enable IPsec as a VPN tunnel protocol for the connection profile, you must also create and deploy a client profile with IPsec enabled using the profile editor from Cisco ASDM. AnyConnect IPsec supports only IKEv2.

Figure 15-19. Selecting the VPN Protocol and the Certificate

Complete the following steps to define protocols and certificates:

Step 1. Check the check box for each of the desired protocols. In this example, only SSL is chosen.

Step 2. Choose an identity certificate from the Device Certificate drop-down list. This certificate identifies the ASA to remote-access clients. Clicking the Manage button opens the Manage Identity Certificates dialog box, which allows you to create new certificates and manipulate existing certificates.

Step 3. Click Next to continue to the next page of the AnyConnect VPN Connection Setup Wizard.

Task 3: Client Image

ASA can automatically upload the latest Cisco AnyConnect VPN Client package to the client device when it accesses the enterprise network. You can use a regular expression to match the user agent of a browser to an image. You can also minimize connection setup time by moving the most commonly encountered operating system for your organization, for example Windows, to the top of the list.

To configure the location of the Cisco AnyConnect SSL VPN Client, complete the following steps:

Step 1. Click Add to add a new image definition, as shown in Figure 15-20.

Figure 15-20. Browsing to Select the Client Image

Step 2. Click Browse Flash if the image file is already located on the Cisco ASA, or click Upload if you have a copy on the local machine to upload to the security appliance.

Step 3. The Browse Flash dialog box opens, as shown in Figure 15-21, allowing you to navigate through files and folders in flash memory. Select the image of the Cisco AnyConnect VPN Client, and click OK to continue.

Figure 15-21. Selecting the Client Image

Step 4. Click Next to continue to the next page of the AnyConnect VPN Connection Setup Wizard.

Task 4: Authentication Methods

User authentication may be managed by external authentication servers (such as RADIUS) or it may be managed locally using the ASA local user database.

In Figure 15-22, the requirements call for configuring user authentication using the local user database.

Figure 15-22. Selecting the Authentication Method

Complete the following steps:

Step 1. Choose the LOCAL value from the AAA Server Group drop-down menu.

Step 2. Configure a username and password for the desired user. Notice that existing users appear in the pane on the right.

Step 3. Click Add to add the user to the local user database. The username will move to the pane on the right.

Step 4. Click Next to continue to the next page of the SSL VPN Connection Setup Wizard.

Task 5: Client Address Assignment

SSL VPN clients receive new IP addresses when they connect to the ASA. Clientless connections do not require new IP addresses. Address pools define a range of addresses that remote clients can receive. The IP address pool configuration is required for successful client-based SSL VPN connectivity. Without an available IP address pool, the full-tunnel Cisco AnyConnect SSL VPN to the security appliance will fail.


Full Client Virtual Adapter

Later in this chapter, we will see that a remote-access user wishing to use a Full client—usually to have more functionality than what the clientless portal can offer—sees a virtual adapter added to the list of network adapters in his computer. We are used to seeing wireless and wired adapters listed under network properties. These network adapters, to fully join a network, usually use DHCP to receive an IP address, a DNS, and so forth. AnyConnect installs a virtual adapter on your workstation, which enables your workstation to look and feel as if it’s connected on the corporate network, though you are physically a distance away. This virtual adapter, similar to your wired and wireless adapters, requires and receives from the ASA an IP address, and a DNS server, so it becomes a client of your corporate LAN. So, for the next few tasks, we will configure for AnyConnect connectivity similar attributes that we would need to configure for our DHCP clients.


Using the options on the Client Address Assignment wizard page, you can select an existing IP address pool or click New to create a new pool, as shown in Figure 15-23. For our particular scenario, complete these steps as follow:

Step 1. Click New to define the desired address pool.

Step 2. In the Add IP Pool dialog box, create the pool by configuring the following items:

Name: A name to be associated with the IP address pool.

Starting IP Address: Starting IP address of the range to be assigned to the client SSL VPN connections.

Ending IP Address: Ending IP address of the range to be assigned to the client SSL VPN connections.

Subnet Mask: Choose the desired subnet mask of the IP address pool from the drop-down menu.

Step 3. Click OK to accept the newly configured IP address pool.

Step 4. Click Next to continue to the next page of the SSL VPN Connection Setup Wizard.

Figure 15-23. Selecting the Address Pool That Will Be Assigned to AnyConnect Clients

Task 6: Network Name Resolution Servers

The next step, shown in Figure 15-24, lets you specify which domain names are resolved for the remote user when accessing the internal network. Simply complete these fields, if necessary:

DNS Servers: Enter the IP address of the DNS server.

WINS Servers: Enter the IP address of the WINS server.

Domain Name: Type the default domain name.

Figure 15-24. Selecting Network Name Resolution Servers

Click Next to continue to the next page of the SSL VPN Connection Setup Wizard.

Task 7: Network Address Translation Exemption

If NAT is enabled on the ASA, the VPN traffic must be exempt from this translation. Complete the following steps, shown in Figure 15-25, to configure NAT exemption, which is necessary in our scenario:

Step 1. Check the Exempt VPN Traffic from Network Address Translation check box.

Step 2. Choose the interface connected to the internal network that needs to be exempted from NAT. In this example, the inside interface contains the hosts that the VPN clients will access.

Step 3. Type the host or subnet IP addresses that are to bypass NAT in the Local Network field. You can also click the ... button and select the addresses from the Browse Local Network dialog box. The traffic between Cisco AnyConnect VPN Clients and the internal networks defined here will be exempt from NAT.

Step 4. Click Next to move to the next page of the SSL VPN Connection Setup Wizard.

Figure 15-25. Configuring NAT Exemption

Task 8: AnyConnect Client Deployment Summary

The final two wizard pages are informational:

AnyConnect Client Deployment: The message explains how you can install the Cisco AnyConnect VPN Client program to a client device using either of two methods. The first method is web launch, which installs automatically when accessing the ASA using a web browser. The second method is predeployment, which manually installs the Cisco AnyConnect VPN Client package.

Summary: Provides a summary, shown in Figure 15-26, of your selections from the previous wizard pages.

Figure 15-26. AnyConnect Wizard Summary

Click Finish to complete the SSL VPN Connection Setup Wizard.

Phase 2: Configure the Cisco AnyConnect VPN Client

To download the Cisco AnyConnect SSL VPN Client to the host system, you must complete the following steps:

Step 1. Open a compliant web browser and enter the login URL for the SSL VPN into the address field, as shown in Figure 15-27.

Figure 15-27. Connecting to the Portal to Eventually Request an AnyConnect Installation Download

Step 2. Ensure that the connection profile created for the client is selected in the Group drop-down menu, enter the previously configured username and password, and click Login.


Installing AnyConnect

AnyConnect can be preinstalled on the remote client using the standalone installation program that Cisco offers. Another option is to have the AnyConnect installation downloaded to the remote-access computer from the ASA using the AnyConnect version available in flash, as shown earlier in Figure 15-21. This is the approach we will take in our scenario. Other variants of this option exist, such as having the AnyConnect installation pushed to your remote client as soon as the ASA receives an authenticated HTTPS session. Those variants are explained in detail in the Cisco Press book CCNP Security VPN 642-648 Official Cert Guide, Second Edition.


In our scenario, start with a clientless session but then choose to upgrade to a full client session by clicking the AnyConnect option on the left side of the portal page. A process will begin a series of compliance checks for the target system. The following items are checked on the host system:

Platform Detection: The ASA first queries the client system in an attempt to identify the type of client connecting to the security appliance. Based on the platform that is identified, the proper software package may be auto-downloaded.

ActiveX: Detects whether ActiveX is available on the host system for client download. For ActiveX to operate properly with the Cisco ASA, it is important that the security appliance is added as a trusted network site. ActiveX will be used for client download in the event that a web portal is not in use.

Java Detection: Detects whether a supported version of Java is available on the host system for client download. Java will be used for client download in the event that a web portal page has been configured.

If all the preceding checks succeed, Cisco AnyConnect will be downloaded and installed automatically on your remote system. All along, the progress is shown, under the title WebLaunch, for the system inspection and the status of the download. Once the client completes the auto-download of the Cisco AnyConnect SSL VPN Client, the web session automatically launches the Cisco AnyConnect SSL VPN Client and attempts to log the user into the network using the same credentials that are supplied when logging into the web portal.

If the ActiveX or Java checks are not successful, the ASA will nevertheless offer you the chance to download manually the Cisco AnyConnect VPN Client located in its flash, as shown in Figure 15-28.

Figure 15-28. Cisco AnyConnect Installed from a VPN Clientless Session

After the download, the Cisco AnyConnect VPN Client is installed. You can then proceed to launch AnyConnect, as shown in Figure 15-29, which will initiate the SSL full client VPN connection to your ASA. You will have concurrently both a clientless session and a full SSL session on the ASA.

Figure 15-29. Starting Cisco AnyConnect Client

When the AnyConnect connection is established, an icon with a sphere and a lock will appear in the system tray, identifying that the client has successfully connected to the SSL VPN network, as shown in Action 1 of Figure 15-30.

Figure 15-30. AnyConnect Icon in Computer System Tray and Details on the Connection

Phase 3: Verify VPN Connectivity with Cisco AnyConnect VPN Client

Additional connection statistics and information may be shown by clicking the icon in the system tray shown in Figure 15-30, Action 1, and then selecting Advanced, as shown in Figure 15-30, Action 2. This client interface may also be used to log the user out.

The Statistics tab on the Client interface presents more information, and allows you to review packet and byte counters, shown in Action 3, as well as the overall settings of the VPN (crypto suite, IP address obtained, split tunneling policy, and others).

In our scenario, future SSL VPN sessions may be launched through the web portal or through the installed Cisco AnyConnect SSL VPN Client.

Verifying VPN Connectivity from Cisco ASA

In Cisco ASDM, you can monitor established VPN sessions by navigating to Monitoring > VPN > VPN Statistics > Sessions. From the window, shown in Figure 15-31, you can view session statistics for the ASA.

Figure 15-31. Monitoring the VPN Sessions Status from ASDM

The top pane shows a summary of active, cumulative, peak concurrent, and inactive VPN sessions. This pane includes VPN sessions of all types, including IPsec, clientless SSL, and site-to-site sessions.

The bottom pane displays individual VPN sessions. You can filter the type of session to display by using the Filter By drop-down menu above the pane. This menu allows you to specify the type of sessions that the statistics in the bottom pane represent. You will need to click Filter to refresh the output according to the filter.

This bottom pane includes the username and IP addresses used in each session, as well as the connection profiles that were matched, the cipher suite in use for the session, and other session statistics such as duration and packet/byte counters.

Clicking Details to the right of the bottom pane provides additional details for each VPN session, as shown in Figure 15-32.

Figure 15-32. Detailed Information on Current VPN Session

Summary

The key points covered in this chapter are as follows:

• Market trends drive the need for effective remote-access security and present challenges to the IT organization.

• The SSL protocol uses the cryptology concepts presented in this chapter.

• Cisco SSL VPN solutions include clientless and full client tunnel modes of operation.

• Cisco SSL VPN clientless mode can be configured on Cisco ASA using Cisco ASDM.

• Cisco SSL VPN full client tunnel mode can be configured on Cisco ASA using Cisco ASDM and the Cisco AnyConnect VPN Client.

References

For additional information, refer to this resource:

CCNP Security VPN 642-648 Official Cert Guide, Second Edition (Cisco Press)

Review Questions

Use the questions here to review what you learned in this chapter. The correct answers are found in the Appendix, “Answers to Chapter Review Questions.”

1. Which two current market trends create challenges to remote connectivity and Cisco SSL VPN services?

a. Consumerization

b. Bandwidth availability

c. Ubiquitous access to corporate resources

d. Increase in malware

e. Cost of VPN infrastructures

2. Which option is the main difference between TLS and SSL?

a. SSL operates at the transport layer.

b. TLS is standards-based.

c. SSL uses digital certificates.

d. TLS supports Suite B algorithms.

3. When deploying Cisco SSL VPNs, which of the following options provides the most depth in application support?

a. EasyVPN

b. Thin Client

c. Full Client

d. Clientless

4. Which solution would you recommend for a user who requires access strictly to web-based applications?

a. EasyVPN

b. Thin Client

c. Full Client

d. Clientless

5. You wish to use the SSL VPN to access your network. However, the administrator has not installed a third-party certificate for Cisco SSL VPN sessions. What will happen to your SSL VPN session?

a. The SSL VPN session will fail because it requires a server-side certificate.

b. The ASA will present a self-signed certificate.

c. A root certificate will need to be imported into ASA.

d. The SSL VPN will fail because the client automatically rejects untrusted certificates.

6. Clientless SSL VPN is best suited for?

a. Complex applications

b. Users who needs to print on a LAN printer

c. Web-enabled applications, file sharing, email

d. All IP-based applications

7. Match the cryptographic algorithms with their function within SSL. Multiple algorithms can be matched to one single function.

Function

a. Confidentiality

b. Integrity

c. Authentication

d. Key management

Algorithm

1. RC4

2. DSA

3. SHA-2

4. 3DES

5. MD5

6. DSS

7. AES

8. DH