Cisco Press
SSL Remote Access VPNs
In Figure 10-1, remote access users at an Internet caf , airport Internet kiosk, and a hotel access the corporate network using variously HTTPS, POP3S, SMTPS, and port forwarding (TCP-based application traffic redirected over SSL). A telecommuter accesses the corporate network using the Cisco SSL VPN Client.
In this chapter, you will learn how SSL remote access VPNs compare to other types of remote access VPN. You will also find out the characteristics of SSL remote access VPNs, as well as how to design and implement them to provide exactly the type and level of functionality required.
Finally, you will learn how to properly secure SSL remote access VPNs—a very important consideration, particularly when users may be accessing the corporate network from untrusted locations such as Internet cafes and airport kiosks.
Comparing SSL VPNs to Other Types of Remote Access VPNs
When deciding whether to implement SSL remote access VPNs, it is essential to understand how they compare to other types of remote access VPNs and what their advantages and disadvantages are.
Some of the main advantages and disadvantages of SSL remote access VPNs are as follows:
SSL remote access VPNs are relatively simple to deploy because it is not necessary to install or administer a VPN client on remote user devices.
It is only necessary for remote user devices to have a web browser to access the corporate network. Remote users can use a web browser to access corporate networks from a wide variety of locations, including Internet cafes and airport Internet kiosks.
Clientless SSL remote access VPNs (those accessed using a web browser) provide a subset of the functionality provided by IPsec or L2TP/IPsec remote access VPNs.
SSL remote access VPN functionality can be enhanced by configuring the VPN gateway to dynamically download an SSL VPN client to remote user devices.
SSL VPNs can impose a relatively high CPU overhead on a VPN gateway if there are a large number of remote access users. This is due to the high CPU overhead incurred by public key operations associated with SSL.
The relatively high CPU overhead imposed by SSL remote access VPNs can be ameliorated by careful selection of SSL remote access VPN gateways.
Little configuration is required on firewalls and NAT devices to provide transit for SSL remote access VPN traffic because SSL is carried over (NAT-friendly) TCP.
Typically, TCP ports 443 (HTTPS) as well as (if e-mail proxy is configured) ports used for POP3 over SSL (POP3S), IMAP4 over SSL (IMAP4S), and SMTP over SSL (SMTPS) need to be opened for firewalls to ensure correct operation of SSL remote access VPNs.
One major disadvantage of SSL remote access VPN has been that universal access that they offer can lead to vulnerabilities being introduced into a corporate network. This is due to the untrusted nature of locations/workstations from which users can connect (Internet cafes, kiosks, hotels, and so on).
Cisco addresses these concerns with the Cisco Secure Desktop.
Now that you understand the advantages and disadvantages of SSL VPNs, it is time to move on to their operation, design, and implementation.
Understanding the Operation of SSL Remote Access VPNs
Before getting into the design and implementation of SSL remote access VPNs, it is a very good idea to take a look at the underlying mechanisms that allow their operation. This section examines the protocols and mechanisms are used to enable SSL remote accessVPNs.
The Secure Sockets Layer (SSL) is a security protocol that is used to secure e-commerce, web transactions, and more recently, to provide remote access VPN connectivity.
SSL was invented by Netscape Communications, and there are a number of versions:
SSL version 1 (SSLv1)—This version was not released by Netscape.
SSL version 2 (SSLv2)—This version was released and is still supported by many web browsers, but it has a number of well-known weaknesses and deficiencies, including its vulnerability to downgrade attacks (an attacker can force the negotiation of a weak cipher suite [which is then subject to attack]); its vulnerability to truncation attacks (an attacker can cause either the server or the client to believe that data transfer has finished by simply forging a TCP FIN); the fact that SSLv2 relies on MD5 MACs and SHA-1 is not available for use; the fact that the same key is used for encryption and authentication (so breaking the key of one leads automatically to the breaking of the other); and the ability of an attacker to intercept and hijack a client’s connection. So, SSLv2 is definitely not recommended.
SSL version 3 (SSLv3)—This version addresses the weaknesses of SSLv2.
Transport Layer Security (TLS version 1.0, RFC 2246)—This is an IETF standard that is based on but not compatible with SSLv3.
In this chapter, the term SSL is used as a generic term to describe SSLv3 and TLS.
SSL Overview: TCP, the Record Layer, and the Handshake Protocol
SSL sits on top of a reliable protocol, such as TCP. Application data can then be carried on top of SSL.
Figure 10-2 shows the overall SSL packet format.
Overall SSL Packet Format
The SSL protocol itself consists of the record protocol plus the handshake protocol, the alert protocol, the change cipher spec protocol, and the application data protocol.
Figure 10-3 shows the relationship between the record protocol and the handshake, alert, change cipher spec, and application data protocols.
The Record layer (protocol) has a number of functions, including the following:
Fragmentation—The record protocol fragments/reassembles data on transmission/reception, if required.
Compression—If negotiated between a client and server, the record protocol compresses/decompresses data.
Applies MAC—The record protocol applies/verifies a MAC.
Encryption—The record protocol encrypts/decrypts data.
Figure 10-3
Relationship Between the Record Protocol and the Handshake, Alert, Change Cipher Spec, and Application Data Protocols
As shown in Figure 10-3, the handshake, alert, change cipher spec, and application data protocols sit on top of the Record layer. These protocols have the following functions:
Handshake protocol (type 22)—This protocol consists of a number of messages exchanged between peers (the client and server) that allow those peers to negotiate SSL version, cryptographic algorithms, and parameters; optionally authenticate each other; and generate shared secret cryptographic keys using public key techniques.
Table 10-1 summarizes SSLv3 and TLS handshake protocol messages.
Table 10-1 Handshake Protocol Messages
Handshake Protocol Message | Type | Sent By | Description |
HelloRequest | 0 | Server | Notification that the client should begin negotiation again. |
ClientHello | 1 | Client | Used to (re-)initiate an SSL connection. Specifies list of cryptographic algorithms/parameters, plus optional compression method and random number. |
ServerHello | 2 | Server | Specifies chosen cryptographic algorithms/parameters and optional compression method. Includes random number. |
Certificate | 11 | Client/server | Contains certificate or certificate chain. |
ServerKeyExchange | 12 | Server | Used in ephemeral RSA or Diffie-Hellman handshake when server certificate message does not allow client to exchange premaster secret. |
CertificateRequest | 13 | Server | Used by the server to request the client’s certificate. Used when client authentication is required. |
ServerHelloDone | 14 | Server | Used to indicate that the server will not send any more messages at this stage of the handshake. |
CertificateVerify | 15 | Client | Used by the client to prove that it is the legitimate owner of its certificate. |
ClientKeyExchange | 16 | Client | Used to send the premaster secret to the server. |
Finished | 20 | Client/server | Ensures integrity of handshake exchange. |
Alert protocol (type 21)—This is used to signal error conditions. These error conditions include those that occur during an SSL handshake, when decrypting or integrity checking, or when closing a connection.
Change cipher spec protocol (type 20)—This protocol (which consists of a single message type) is used by the client or server to signal that subsequent SSL messages will be protected using negotiated cryptographic algorithms, parameters, and keys.
Application data protocol (type 23)—The application data protocol carries data from whichever application or applications are running over SSL. This data can include protocols such as HTTP, FTP, POP3, IMAP4, SMTP, as well as other higher-level protocol data.
Establishing an SSL Connection Between a Remote Access VPN User and an SSL VPN Gateway Using an RSA Handshake
As previously described, the function of SSL is to negotiate cryptographic algorithms, authenticate the server (VPN gateway) and optionally the remote access VPN client, and establish cryptographic keys.
The most common method of establishing an SSL connection between a remote access VPN client and a VPN gateway is using the Rivest, Shamir, and Addlemen (RSA) handshake with VPN gateway authentication. In this case, the remote access VPN client is not authenticated during the handshake, but may be authenticated using a separate mechanism after the SSL connection has been established.
Figure 10-4 illustrates the RSA handshake with VPN gateway only authentication.
Figure 10-4
SSL RSA Handshake
As shown in Figure 10-4, the RSA handshake with VPN gateway only authentication consists of the exchange of nine messages:
The first step in the RSA handshake is when the remote access client sends a ClientHello message to the VPN gateway (server). This message is used to propose a number of cryptographic parameters and algorithms (cipher suites), compression methods (if any), and well as being used to transmit a random number that is later used to generate cryptographic keys.
The VPN gateway now selects one of the cryptographic proposals (cipher suites), together with any compression method sent in the ClientHello and includes these chosen proposals in the ServerHello message that it sends to the remote access client.
The ServerHello message also includes a random number generated by the VPN gateway, which is again used to later generate cryptographic keys.
Next, the VPN gateway’s sends a Certificate message. This message contains the VPN gateway’s certificate (including its public key) along with any other certificates in a certificate chain.
Immediately after the Certificate message is ServerHelloDone. The VPN gateway sends this message to signal that it will not send any more messages at this stage of the handshake sequence.
The remote access client now sends the ClientKeyExchange message. This message includes a key, called the pre_master_secret, which is encrypted using the VPN gateway’s public key.
The pre_master_secret, together with the random numbers sent in the ClientHello and ServerHello messages is used to generate the keys later used to encrypt and authenticate SSL traffic.
The ClientKeyExchange message is followed by the ChangeCipherSpec and Finished messages.
The ChangeCipherSpec message signals that SSL messages from the client (starting with the Finished message) will from now on be protected using the negotiated cipher suite.
The Finished message contains a hash of all the messages previously sent in the handshake—this ensures that an attacker has not modified any of the previous handshake messages.
The VPN gateway now completes the RSA handshake by sending its own ChangeCipherSpec and Finished messages.
Now that you know what happens in theory, it is time to take a look at an SSL connection in practice.
SSL Connection Establishment: ClientHello Message
Figure 10-5 shows a packet capture of an SSL ClientHello message.
Figure 10-5
SSL ClientHello Message
If you look at the highlighted line in the main portion of the screen shown in Figure 10-5, you can see the message is, in fact, a ClientHello message. Below the highlighted line there are a number of message fields that can be described as follows:
Record layer header:
— Content Type—This field specifies the record type, which in this case is Handshake (type 22).
— Version—This defines the SSL version (major and minor versions). SSLv3 is 3.0 (0x0300), and TLS is 3.1 (0x0301).
— Length—The length of the record. According to the specification, a record can be up to a maximum of 214 bytes, although at least one browser type did erroneously send records of up to 216-1 bytes.
Handshake protocol header:
— Handshake Type—The handshake protocol message type. Here, the message type is ClientHello (1).
— Length—The length of the message.
— Version—The highest version of the SSL protocol that the client supports.
— Random number (Random.gmt_unix_time, plus Random.bytes)—This is the previously described random number that is later used to generate cryptographic keys.
Notice that the random number is, in fact, made up of the number of seconds since midnight, January 1, 1970 (4 bytes in UNIX format), as well as a 28-byte randomly generated number. The UNIX time is included in the random number to ensure that the same random number is not chosen twice (this would be possible if all 32 bytes of the random number were randomly chosen!).
— Session ID Length—The length of the Session ID field.
The Session ID length is zero here, and this indicates that the Session ID field itself is not present. The Session ID field is only present in the ClientHello if the client wants to resume a previous SSL session with the VPN gateway.
— Cipher Suites Length—The length of the Cipher Suites list.
Cipher Suites—There are a number of SSL cipher suites, including a number that require the VPN gateway to provide an RSA certificate, a number that are used for server authenticated (and optionally client authenticated) Diffie-Hellman, and a number that are used for anonymous Diffie-Hellman communications where neither the VPN gateway nor the client is authenticated.
The cipher suites themselves are fairly self-explanatory. For example, TLS_RSA_WITH_RC4_128_MD5 specifies RSA authentication with the RC4 stream cipher for encryption and Message Digest 5 (MD5) for integrity checking. One thing you might notice if you closely examine the cipher suites in Example 10-5 is the lack of any support for AES. This is due to the lack of any AES cipher suites in the base TLS v1.0 specification (RFC 2246 [SSLv3 includes no support for AES, by the way]). RFC 3268 describes support for AES cipher suites with TLS, and this support is integrated into the TLS v1.2 specification, which is under discussion in the IETF TLS working group at the time of this writing. It may be interesting to note that support for AES with HTTPS is added in Microsoft Vista (support is also included in Firefox).
— Compression Methods Length—The length of the Compression Methods field.
— Compression Methods—This specifies methods of compression that the client is willing to support. RFC2246 does not specify any compression methods because of intellectual property concerns, and so this client specifies NULL compression, meaning no compression.
Note that RFC3749 does specify the DEFLATE compression algorithm for use with SSL (DEFLATE itself is defined in RFC1951).
SSL Connection Establishment: ServerHello, Certificate, and ServerHelloDone Messages
The next messages in the SSL handshake sequence are ServerHello, Certificate, and ServerHelloDone. The VPN gateway sends these messages (see Figure 10-6).
Figure 10-6
SSL server_hello, Certificate, and ServerHelloDone Messages
If you take a look in the main portion of Figure 10-6, you can see the common SSL record header (Content Type, Version, Length), followed by the ServerHello, Certificate, and ServerHelloDone messages.
The ServerHello message is similar to the ClientHello message, but there are one or two differences:
The Handshake Type field now specifies that this message is a ServerHello (2).
The Session ID Length field specifies a 32-byte length.
The Session ID field specifies a Session ID that can be used to resume the session at a later stage if desired.
The Cipher Suite field specifies the cipher suite chosen by the VPN gateway from those sent by the client in the ClientHello message.
Immediately after the ServerHello is the Certificate message. The Certificate message is relatively simple and consists of the following fields:
Handshake Type—In this case, this field is used to specify that this is a certificate message (11).
Length—The length of this message.
Certificates Length—The length of the certificate(s) included in this message.
Certificates—The certificate or certificates sent by the VPN gateway, including the following:
— Certificate Length—The length of this certificate.
— Certificate—The certificate itself.
Note that a number of certificates can be included.
Next is the ServerHelloDone message. As you can see, it consists of only two fields:
Handshake Type—The type of handshake message, which is ServerHelloDone (14).
Length—The length of the message, which in this case is zero (remember that ServerHelloDone simply indicates that the VPN gateway does not have any more messages to send at this stage).
SSL Connection Establishment: ClientKeyExchange, ChangeCipherSpec, and Finished Messages
After the VPN gateway sends the ServerHello, Certificate, and ServerHelloDone messages, the client responds with the ClientKeyExchange, ChangeCipherSpec, and Finished messages.
Figure 10-7 shows the transmission of the ClientKeyExchange, ChangeCipherSpec, and Finished messages. The Finished message is the first in the handshake to be encrypted.
Figure 10-7
Transmission of the ClientKeyExchange, ChangeCipherSpec, and Finished Messages
Figure 10-7 again shows the common Record layer header, followed by the ClientKeyExhange, ChangeCipherSpec, and Finished messages:
The common Record layer header, including the following
— Content Type—Specifies that this is a Handshake message (22).
— Version—This is a TLS (SSL version 3.1) message.
— Length—The length of this message is 134 bytes long.
A ClientKeyExchange message, including the following
— Handshake Type—This is a ClientKeyExchange message (16).
— Length—This message is 130 bytes long.
A ChangeCipherSpec message, including the following
— Content Type—This is a ChangeCipherSpec message (20).
— Version—This is a TLS message.
— Length—The length of this message is 1 byte.
An encrypted Finished message (“Encrypted Handshake Message”).
The remote access client now completes the handshake by sending ChangeCipherSpec and Finished messages.
Figure 10-8 shows the ChangeCipherSpec message sent by the client.
Figure 10-8
ChangeCipherSpec Message Sent by the Client
Figure 10-9 shows the Finished message sent by the client.
Figure 10-9
Finished Message Sent by the Client
The format of the Record layer header has already been described, and so will not be described again here. Notice, however, the final line in the output in the main portion of the screen shown in Figure 10-9—this line shows that the Handshake message is encrypted. This should be no surprise, as you will remember that the Finished message is, in fact, the first message that is encrypted in the handshake.
And that is it—the handshake is complete, and the client and VPN gateway are ready to send application data to each other over the SSL connection. Figure 10-10 shows application data sent over the SSL connection.
The Record layer header Content Type field shows that this is an Application Data message. The length of the message is 264 bytes, but the payload is encrypted and so is not shown.
SSL Handshake: SSLv2, SSLv3, or TLS?
Before finishing this section, it is worth pointing one apparent anomaly that is sometimes seen in the SSL handshake (see Figure 10-11).
Application Data Sent over the SSL Connection
Figure 10-11
SSL Handshake Anomaly
First, take a look at the upper portion of the screen capture. Look at the SSL messages; you will notice the familiar beginning of the RSA handshake (compare with Figure 10-4). If you are the observant type, you will have noticed one apparent anomaly—the TLS handshake begins with an SSLv2 ClientHello message!
Now take a look at the lower portion of the screen and you see the detail of the SSLv2 ClientHello. If you look closely at the fields of the Record header, you will notice that although this is an SSLv2 ClientHello, the Version field in the record header specifies TLS!
What is going on? Well, this is a common method that web browsers/clients use to check whether a server/VPN gateway can support SSLv3 or TLS. This method of checking support for SSLv3 or TLS works because the Version fields in SSLv2 and SSLv3/TLS are interpreted differently (SSLv2 is represented as 0x0002, whereas SSLv3 and TLS are represented as 0x0300 and 0x0301 respectively—note the difference in the way the high-order and low-order octets are used).
So, if a client sends an SSLv2 ClientHello with the Version field set to TLS (0x0301), and the server/VPN gateway supports TLS, it will parse the SSLv3/TLS version field and identify support for TLS, then respond using TLS handshake messages, as appropriate! A server/VPN gateway that supports only SSLv2, on the other hand, will not identify this as TLS.
Note – SSLv3 and TLS (RFC2246) also include a variation on the regular RSA handshake called an ephemeral RSA, as well as another type of handshake that takes advantage of the Digital Signature Standard (DSS) and Diffie-Hellman algorithms.
The ephemeral RSA handshake permits SSL connections to be established between export clients (which use weak cipher suites) and U.S. domestic servers (which use strong cipher suites) using a strong key.
The DSS/DH handshake, on the other hand, was designed to overcome any issues with patents on the RSA algorithm.
Since U.S. export controls for strong cryptographic software have been relaxed, the ephemeral RSA handshake has become much less relevant. The patent for the RSA algorithm has now expired, and so the DSS/DH handshake has also become less relevant. For these reasons, neither the ephemeral RSA handshake nor the DSS/DH handshake is discussed in this chapter.
Understanding the SSL RSA Handshake with Client Authentication
The RSA handshake described in the previous section ensures that the server/VPN gateway is authenticated by the client (using the certificate sent by the server in the Certificate message). But, how about if you want the server to authenticate client during the handshake, too? In this case, the SSL handshake with client authentication, illustrated in Figure 10-12, is used.
Figure 10-12
SSL Handshake with Client Authentication
If you compare Figure 10-12 with Figure 10-4, you can see that the handshakes are very similar. There are one or two differences, however:
In response to the ClientHello, the VPN gateway sends a CertificateRequest message in addition to the ServerHello, Certificate, and ServerHelloDone messages.
As the name suggests, the CertificateRequest message is used to request that the client send its certificate (or certificate chain) to the VPN gateway as well as to specify which key types are acceptable (for example, RSA) and the CAs it will accept as issuers of certificates (the client’s certificate must be issued by one of these).
The client replies with Certificate and CertificateVerify messages in addition to the ClientKeyExchange, ChangeCipherSpec, and Finished messages.
The Certificate message contains the client’s certificate or certificate chain, and the CertificateVerify message is used by the client to prove that it possesses the private key corresponding to the public key contained in its certificate.
The CertificateVerify message consists of a digital signature (using the private key corresponding to the public key in the certificate). Only the owner of the client’s certificate should possess the private key, and so the client is able to prove that it really is the owner of the certificate sent in the certificate message.
So, the client authenticates the VPN gateway using the Certificate that the VPN gateway sends (this is the same as the regular RSA handshake with no client authentication), and the VPN gateway authenticates the client using the Certificate and CertificateVerify messages that the client sends.
Resuming an SSL Session
So far, this chapter has described SSL handshakes that allow the establishment of new SSL sessions. This section describes the resumption of a previous SSL session. Figure 10-13 shows the exchange of SSL messages necessary to resume a previous SSL session.
You might be wondering why you would want to resume an SSL session instead of just establishing a new one (as described in the previous two sections). The answer is that the public key operations that are necessary when establishing a new session are cryptographically expensive/processor intensive, whereas resuming a previous session does not require these expensive public key operations.
Figure 10-13
Resuming an SSL Session
As you can see in Figure 10-13, to resume an SSL session, the follows happens:
The client sends a ClientHello message.
This message has the same format as that shown in Figure 10-5, with the difference that a Session ID field is included (the Session ID Length field is nonzero).
The Session ID in the ClientHello identifies a previous session, and the VPN gateway responds with a ServerHello confirming the resumption of that session, before changing to the previously negotiated cipher suite and ensuring the integrity of the handshake using the ChangeCipherSpec message and Finished messages, respectively.
The client now completes the resumption of the session by sending ChangeCipherSpec and Finished messages. After these messages have been sent, Application Data messages can begin to flow between the client and VPN gateway.
Closing an SSL Connection
The final action in an SSL connection is its closure. This is illustrated in Figure 10-14.
Figure 10-14
SSL Connection Closure
In Figure 10-14, the client initiates connection closure by sending a close_notify Alert message to the VPN gateway. The client then sends a TCP FIN message to terminate the underlying TCP connection.
The VPN gateway responds by sending its own close_notify Alert message, followed by a TCP FIN. The SSL connection is now closed.
Although Figure 10-14 shows the client initiating SSL connection closure, it is possible for either the client or the VPN gateway (server) to initiate connection closure.
Note that if a client or VPN gateway receives a TCP FIN before receiving a close_notify Alert, it marks the connection as being unresumable—this prevents truncation attacks, where an attacker inserts a TCP FIN into the traffic stream between the client and VPN gateway.
Using Clientless SSL Remote Access VPNs (WebVPN) on the Cisco VPN 3000 Concentrator
As discussed at the beginning of this chapter, one great advantage of SSL VPNs is that they do not require dedicated client software—the only software that is required is a standard web browser and e-mail software such as Microsoft Outlook Express, if e-mail functionality is required via POP3/IMAP4/SMTP.
This section examines how it is possible to provide file server access, website access, and TCP application access using clientless SSL remote access VPNs. Before enabling these types of access of SSL, however, it is necessary to complete basic SSL remote access VPN configuration tasks on the VPN 3000 concentrator.
Completing Basic SSL Remote Access VPN Access Configuration Tasks on the Cisco VPN 3000 Concentrator
Before you can enable SSL remote access VPN functionality such as file access or port forwarding, it is necessary to complete a number of basic configuration tasks:
Step 1 Enroll and obtain a (SSL) certificate for the VPN 3000 concentrator from a certificate authority (CA) (optional).
Step 2 Enable WebVPN for relevant user groups (or create a group specifically for WebVPN access).
Step 3 Specify acceptable versions of SSL and configure cryptographic algorithms associated with SSL cipher suites.
Step 4 Enable SSL on the VPN 3000 concentrator’s public interface.
The sections that follow describe these steps in further detail. Before moving on to step 1, however, it is worth mentioning that on the Cisco VPN 3000 concentrator, WebVPN uses global DNS settings rather than those specified under a group. So, make sure that you specify global DNS settings under Configuration > System > Servers > DNS.
Step 1: Enroll and Obtain a (SSL) Certificate for the VPN 3000 Concentrator from a Certificate Authority (Optional)
As described earlier in this chapter, clients authenticate the VPN gateway during the RSA handshake using the VPN gateway’s certificate (or certificate chain).
The certificate that the VPN gateway uses to identify itself is shown under the SSL Certificates heading (public interface) in Administration > Certificate Management (see Figure 10-15).
By default, the SSL certificate for the public interface is self-generated (it is not obtained from a CA). Although it is okay to use this certificate for testing, it is usually a good idea to enroll the VPN 3000 concentrator with a CA and obtain a certificate to use for the SSL handshake.
Obtain the CA’s certificate, and then click Enroll under the Actions section under the SSL Certificates heading (public interface) to obtain a certificate for the SSL handshake. Obtaining the CA’s certificate and enrolling with the CA can be achieved using the procedures described previously in Chapter 8, “Designing and Implementing L2TPv2 and L2TPv3 Remote Access VPNs,” and Chapter 9, “Designing and Deploying IPsec Remote Access and Teleworker VPNs.”
SSL Certificate
Note that during the SSL handshake, client web browsers will display a warning concerning the certificate(s) sent by the VPN gateway. Users can bypass this warning simply by clicking in the affirmative when asked whether the certificate should be accepted. If you do not want this warning to display, you can install the certificate of the CA with which the VPN gateway enrolled into the certificate store of the browser.
Step 2: Enable WebVPN for Relevant User Groups
The next step is for WebVPN to be enabled for relevant user groups. As shown in Figure 10-16, this is simply accomplished by going to Configuration > User Management > Groups, choosing the relevant group, clicking Modify Group, choosing the General tab, and checking the WebVPN box under Tunneling Protocols.
Step 3: Specify Acceptable Versions of SSL and Configure Cryptographic Algorithms Associated with SSL Cipher Suites (Optional)
Next, it is a good idea (although optional) to go to Configuration > Tunneling and Security > SSL > Protocols, and specify acceptable versions of SSL as well as cryptographic algorithms associated with SSL cipher suites (see Figure 10-17).
Figure 10-16
Enabling WebVPN for Relevant User Groups
Figure 10-17
Specifying Acceptable Versions of SSL, as Well as Cryptographic Algorithms Associated with SSL Cipher Suites
As you can see in Figure 10-17, the encryption (and hashing) algorithms associated with cipher suites that you can enable are 3DES-168/SHA, RC4-128/MD5, DES-56/SHA. By checking or unchecking these, an administrator can control the algorithms associated with the cipher suite that is accepted by the VPN gateway (and sent in the ServerHello message to the client). In Figure 10-17, only 3DES-168/SHA is enabled.
It is also possible to specify which versions of SSL that the VPN gateway will accept or negotiate with clients by choosing the appropriate option in the drop-down box. SSLv2 has a number of well-known vulnerabilities, and so, unsurprising, the VPN 3000 concentrator supports only SSLv3 and TLS.
Note – When deciding which versions of SSL to accept or negotiate, it is important to note that although most recent versions of popular web browsers support both SSLv3 and TLS (and often SSLv2), some browsers do not have TLS enabled by default.
For example, TLS is not enabled by default in Internet Explorer 6.0 (SSLv2 and SSLv3 are). TLS (v1.0) can be enabled in Internet Explorer 6.0 by going to Tools > Internet Options > Advanced and checking it under Security. In Internet Explorer 7.0, on the other hand, SSLv3 and TLS are enabled by default, while SSLv2 is disabled.
Firefox 1.0 supports SSLv2, SSLv3, and TLS (v1.0) by default.
In summary, if possible, it is a good idea to establish which types of browser users will be connecting from. If this is not possible (if users will be connecting from Internet cafes, and so on), it is a good idea to accept or allow the negotiation of SSLv3 (and optionally TLS).
In Figure 10-17, the VPN gateway has been configured to negotiate either SSLv3 or TLS with clients.
Finally, it is possible to configure the interval at which the VPN gateway will rekey (establish new cryptographic keys) with workstation running the Cisco SSL VPN Client. You can find more information on the Cisco SSL VPN Client later in this chapter.
Step 4: Enable SSL on the VPN 3000 Concentrator’s Public Interface
The last of the basic steps is enabling SSL on the public interface of the Cisco VPN 3000 concentrator. This can be achieved by going to Configuration > Interfaces, clicking the public interface, and then choosing the WebVPN tab (see Figure 10-18).
As shown in Figure 10-18, it is possible to enable SSL on the public interface by allowing HTTPS, POP3S, IMAP4S, and SMTPS.
Enabling SSL on the Public Interface
To enable SSL for basic features such as access to file and HTTP servers, as well as TCP application access via port forwarding, you must check the Allow WebVPN HTTPS sessions box.
If proxy e-mail access is also required, you must also check the Allow POP3S sessions, Allow IMAP4S, and Allow SMTPS sessions boxes as appropriate. POP3 and IMAP4 can be used for inbound e-mail access, and SMTP is used for outbound e-mail—you should check the boxes according to which protocols are used by your e-mail clients and servers.
Another useful option is Redirect HTTP to HTTPS. If this box is checked, the VPN concentrator will cause the browsers of remote access user who type http://ip_address_or_name_of_VPN_concentrator to instead access the Cisco VPN 3000 concentrator using HTTPS (https://ip_address_or_name_of_VPN_concentrator).
It is also a good idea to navigate to Configuration > Tunneling and Security > SSL > HTTPS and verify that HTTPS is enabled (the default), the TCP port used for HTTPS, and to enable client authentication if desired.
Configuring Additional Basic SSL Options
The HTTPS configuration options shown in Figure 10-19 are as follows:
Enable HTTPS—This option, if checked, enables HTTP over SSL (the default).
HTTPS Port—This is used to specify the TCP port used for HTTPS (default 443).
Client Authentication—This option, if checked, configures client authentication with the RSA handshake.
Note that when client authentication is enabled, the client must obtain the certificate of CA and also obtain an identity certificate.
See the section, “Understanding the SSL RSA Handshake with Client Authentication” earlier in this chapter for more information on this topic.
Configuring File and Web Server Access via SSL Remote Access VPNs
One of the most basic levels of access that you can enable via an SSL remote access VPNs is file and/or web server access.
To enable file server access, it is necessary to complete the following tasks:
Step 1 Configure one or more NetBIOS name servers.
Step 2 Configure WebVPN file servers and shares.
Step 3 Enable file access for the WebVPN user group(s).
Step 1: Configure One or More NetBIOS Name Servers
You can accomplish configuration of a NetBIOS name server by going to Configuration > System > Servers > NBNS (see Figure 10-20).
Configuring NBNS Addresses
The first step is to enable NBNS by checking the Enabled box.
Next, you can choose WINS or Master Browser in the Server Type drop-down box.
The IP addresses of primary, secondary, and tertiary NBNS servers can then be configured in the appropriate boxes.
Finally, you can configure the timeout period in seconds, as well as the number of timeout retries. Unless you have a good reason, it is a good idea to leave these at their defaults (2 and 2).
Step 2: Configure WebVPN File Servers and Shares
To configure server names and shares for users to access, go to Configuration > Tunneling and Security > WebVPN > Servers and URLs > Add.
Figure 10-21 shows the configuration of file access for SSL remote access VPN users.
Figure 10-21
Configuring File or Web Server Access
You can type a description of the file or web server in the Name box. This description appears on the WebVPN home page when SSL remote access VPN users successfully authenticate on the VPN 3000 concentrator.
In the Server Type drop-down box, you can choose the server type (either Common Internet File System [CIFS], HTTP, or HTTPS). CIFS is based on the Server Message Block (SMB) protocol and can be used to request file and print services from Windows or other servers.
You must then specify the name of the server or share in the Remote Server box. When using CIFS, you must specify the server name or share in the //server/share format.
When all the boxes have been completed, click the Apply box.
Step 3: Enable File and URL Access for the WebVPN User Group(s)
After server names and shares have been configured, the next step is to enable file access under the appropriate group or groups.
Under Configuration > User Management > Groups, choose the appropriate group, click Modify Group, click the WebVPN tab, and you will see the page shown in Figure 10-22.
Figure 10-22
Enabling File and/or Web Server Access Under Group Settings
Check the Enable File Access box to enable (appropriately enough) file server access.
Checking the Enable File Server Browsing box allows users to browse files and folders on servers (server file and folder permissions permitting).
It may also be a good idea to check the Enable File Server Entry box to place server names or file paths on the home page of SSL remote access VPN users.
When a user connects to the VPN 3000 concentrator and authenticates, he/she will see the share listed in the home page (see Figure 10-23).
Figure 10-23 shows file shares, including in the one created in Figure 10-21. By clicking these links, the remote access VPN user will be able to access those resources (see Figure 10-24).
Figure 10-23
Accessible File and Web Servers
Figure 10-24
Accessing Files on a File Server
As shown in Figure 10-24, it is possible (file server and VPN 3000 concentrator configuration permitting) to browse files and folders, open, create, rename, and copy files to the server.
Note – The Java Runtime Environment (JRE) version 1.4 or later must be installed on client workstations for file access to function correctly.
It is also worth noting that it might be necessary to modify local policies on a Windows 2003 domain controller when configuring file access. Specifically, it might be necessary to open the Domain Controller Security Policy (found under Administrative Tools) and under Local Policies > Security Options disable the Microsoft network server: Digitally sign communication (always) policy (right-click and choose Properties).
Figure 10-25 shows modification of the Microsoft network server: Digitally sign communication (always) policy.
Modifying Security Options on a Windows 2003 Domain Controller
Configuration of URL access is similarly configured as follows:
Step 1 Configure HTTP/HTTPS proxy server addresses as required.
Step 2 Configure URLs under Configuration > Tunneling and Security > WebVPN, click Servers and URLs (see Figure 10-21), click Add, and then add a URL. The server type should be specified as HTTP or HTTPS as appropriate.
Step 3 Enable URL entries under Configuration > User Management > Groups, choose the appropriate group, click Modify Group, choose the WebVPN tab (see Figure 10-22), and check Enable URL Entry.
It is possible to control remote users’ web access by configuring HTTP/HTTP proxy server addresses on the VPN 3000 concentrator. In this case, HTTP/HTTPS connections from remote users are forwarded from the VPN 3000 concentrator to the proxy server(s).
As shown in Figure 10-26, configuration of HTTP/HTTPS proxy servers is achieved under Configuration > Tunneling and Security > WebVPN > HTTP/HTTPS Proxy.
Figure 10-26
Configuring HTTP/HTTPS Proxy
Configuration is fairly self-explanatory:
HTTP Proxy—This is the IP address of the proxy server to which HTTP WebVPN requests are redirected by the VPN 3000 concentrator.
HTTP Proxy Port—The TCP port used by the HTTP proxy server.
HTTPS Proxy—The IP address of the proxy server to which HTTPS WebVPN requests are redirected.
HTTPS Proxy Port—The TCP port used by the HTTPS proxy server.
Default Timeout—The timeout, in minutes, for WebVPN sessions if one is not set in group settings.
Enabling TCP Applications over Clientless SSL Remote Access VPNs
Apart from file and web server access, another form of access via clientless SSL remote access VPNs is that for TCP-based applications. Remote access VPN users can access TCP-based applications via a VPN 3000 concentrator using a mechanism called port forwarding.
One of the most popular applications to enable using port forwarding is Windows Terminal Services, which allows remote access users to remotely access a desktop and applications that are installed on a Windows server, with screen bitmaps transported over the network between the remote users and the server. This method of server desktop and application hosting conforms to the thin-client model.
Note – To enable Citrix MetaFrame support with WebVPN, you must check the Enable Citrix MetaFrame box on the WebVPN tab under Groups.
Note that in this case, an SSL certificate with a fully qualified domain name (not an IP address as the common name) must be installed on the public interface on the VPN 3000 concentrator.
This section covers how to enable Windows Terminal Services for port forwarding over SSL. Other TCP-based applications can be similarly enabled.
Figure 10-27 illustrates the port-forwarding concept. In Figure 10-27, on the client, traffic sent to IP address 127.0.0.x, TCP port 3389 (Windows Terminal Services) is redirected over SSL to the VPN 3000 concentrator. The VPN 3000 concentrator then forwards this traffic to the application server. Return traffic from the server is then sent to the VPN 3000 concentrator, which then forwards it over SSL to the client.
Configuration of port forwarding is fairly straightforward. The first step is to enable port forwarding by checking the Enable Port Forwarding box under the user group, as illustrated in Figure 10-22.
Figure 10-27
The TCP Port-Forwarding Concept
After port forwarding has been enabled for the user group, it is then simply a case of going to Configuration > Tunneling and Security > WebVPN > Port Forwarding, clicking Add, and specifying TCP port forwarding parameters (see Figure 10-28).
The various boxes shown in Figure 10-28 are fairly self-explanatory.
You can enter a description for the application in the Name box—this is displayed on the remote access VPN client when the user enables application access.
Next, the port that the client uses to connect to the application should be specified in the Local TCP Port box. This setting controls which TCP traffic will be redirected over SSL to the VPN 3000 concentrator by the remote client. In the example shown, traffic using TCP port 3389 (the default Windows Terminal Services port) will be redirected over SSL to the VPN 3000 concentrator.
The IP address or name of the application server must then be entered in the Remote Server box.
If the IP address of applications servers are specified then they are accessed from the user workstation by specifying the IP address 127.0.0.1.
If the names of application servers are specified, the hosts file on Windows user workstations are modified during WebVPN access, with the first application used for port forwarding being mapped to IP address 127.0.0.2, the second application being mapped to IP address 127.0.0.3, and so on.
Figure 10-28
Configuring Port Forwarding
Finally, configure the TCP port that the application uses on the application server in the Remote TCP Port box. This TCP port will often be the same as that entered in the Local TCP Port box.
Click Add, and port forwarding will be ready for use for the particular application just configured.
For port forwarding to function, the Sun JRE must be installed on the clients, and this requires the person installing the software have administrative rights on that workstation. Because administrative rights are required for the installation of the JRE, it is unlikely that remote access users will be able to access applications using port forwarding from locations such as Internet cafes or airport Internet kiosks.
Note – JRE can be downloaded from the Sun website. At the time of this writing, the download location is as follows:
Note that Microsoft Java cannot be used for port forwarding.
Also, make sure that either Negotiate SSLv3 or Negotiate SSLv3/TLS is chosen under Configuration > Tunneling and Security > SSL > Protocols. If one of these two options is not chosen, port forwarding will not function.
Remote access VPN users must connect to the VPN 3000 concentrator and access their home page using their web browser. Users can then click the Start Application Access link on either the home page itself or on the pop-up dialog box (make sure that pop-ups are allowed!) to enable application port forwarding for the SSL connection. Take a look back at Figure 10-23 to see the Start Application Access link on the home page.
When a user clicks the Start Application Access link, a Java applet opens the Application Access window on the client, and application port forwarding is enabled.
Figure 10-29 shows access to Windows Terminal Services using port forwarding over SSL.
Figure 10-29
Access to Windows Terminal Services Using Port Forwarding over SSL
In the upper-left corner of the screen in Figure 10-29, you can see the Application Access window. As you can see, it lists the application names, associated local and remote TCP ports, remote application server IP addresses, the number of application data bytes sent (Bytes Out) and received (Bytes In), and the number of sockets open for particular applications. The application names, TCP ports, and remote application server IP addresses are, as previously described, configured under Configuration > Tunneling and Security > WebVPN > Port Forwarding (see Figure 10-22).
The main window in Figure 10-29 shows the remote desktop on the remote Windows Terminal Server accessed via the VPN 3000 concentrator.
One important detail in Figure 10-29 is the local IP address used to access the remote TCP application. Notice that the local IP address shown in the Application Access window (and in the upper-left corner of the main window) is 127.0.0.1. This is the IP address that is typed into the Computer box of the Remote Desktop Connection application used on Windows XP to access the Windows Terminal Server. Of course, 127.0.0.x is used to specify the local system, and this (TCP) traffic is then redirected over SSL to the VPN 3000 concentrator.
As previously mentioned, when using DNS names, the redirection of application traffic that port forwarding relies upon is achieved by the modification of the local system’s Hosts file. The Hosts file is modified when application access is enabled (a copy of the original file is saved during application access, and restored later).
Figure 10-30 shows a modified Hosts file that enables application traffic redirection during application access.
Figure 10-30
Modified Hosts File
In Figure 10-30, the Hosts file has been modified to include four entries, two corresponding to port forwarding to wints.mjlnet.com/wints (127.0.0.2) and two corresponding to termsrv.mjlnet.com/termsrv (127.0.0.3).
When enabling an application for port forwarding over SSL, it is important to establish that the application is, in fact, TCP based, and if so, which TCP ports it uses. After this information has been confirmed and obtained, the application should be enabled for port forwarding in a similar manner to that for Windows Terminal Services described in this section.
If you want to enable a remote access VPN user to Telnet to a terminal server (router) via the VPN 3000 concentrator, for example, you first need to establish that the application is TCP based (it is, of course), and the TCP port(s) that it uses (port 23).
After these facts have been established, port forwarding for Telnet to the terminal server can be configured as shown in Figure 10-31.
Figure 10-31
Configuring Port Forwarding for Telnet
In Figure 10-31, the name Telnet To Term Server has been configured for the Telnet port forwarding connection. This name is, of course, displayed on the WebVPN home page and in the Application Access window.
The local and remote TCP ports are configured as 23, and the remote server (terminal server) IP address is configured as 10.10.10.1 (an internal IP address).
Figure 10-32 shows how Telnet to the terminal server functions on a remote access VPN client. As shown, the user Telnets to the local IP address (127.0.0.x) to connect to the remote terminal server. Telnet packets are then redirected over SSL to the VPN 3000 concentrator that then proxies the Telnet connection to the terminal server.
Figure 10-32
Port Forwarding for Telnet on a Remote Access VPN Client
Configuring E-mail Proxy for SSL Remote Access VPN Users
E-mail proxy describes the process by which the VPN 3000 concentrator terminates POP3S (POP3 over SSL), IMAP4S (IMAP4 over SSL), and STMPS (SMTP over SSL) connections from remote access VPN clients and proxies those connections to internal e-mail servers.
Figure 10-33 depicts e-mail proxy for POP3S, IMAP4S, and SMTPS connections from remote access VPN clients.
In Figure 10-33, remote access VPN user Mark is using an e-mail client such as Outlook Express. His e-mail client is configured to connect to the VPN 3000 concentrator using POP3S (for incoming e-mail) and SMTPS for outgoing e-mail. The VPN 3000 concentrator proxies these connections to an internal e-mail server.
The configuration of e-mail proxy consists of enabling the appropriate e-mail protocols on the public interface and then configuring protocol port numbers, e-mail server IP addresses or names, and methods of authentication.
Enabling e-mail protocols (POP3S, IMAP4S, and SMTPS) on the public interface of the VPN 3000 concentrator by going to Configuration > Interfaces, choosing the public interface, and clicking the WebVPN tab. See Figure 10-18 on page 929 for information on the method of enabling e-mail protocols.
Figure 10-33
E-Mail Proxy for POP3S, IMAP4S, and SMTPS Connections
You can configure e-mail protocol port numbers, e-mail server IP addresses or names, and methods of authentication under Configuration > Tunneling and Security > WebVPN > Email Proxy (see Figure 10-34).
The first two parameters (VPN Name Delimiter and Service Delimiter) are, as their names suggest, used to delimit VPN and e-mail server usernames and passwords.
The VPN Name Delimiter is used to separate the VPN usernames/passwords and e-mail server usernames/passwords. This delimiter is used when configuring the e-mail client—in the box on the e-mail client where the username is entered, the username that the VPN 3000 concentrator uses to authenticate the user, as well as the username that the e-mail server uses to authenticate the user must be configured. These usernames are separated in the box using the delimiting character specified by the VPN Name Delimiter.
So, for example, if the username used to authenticate the user on the VPN 3000 concentrator is mark, the username used to authenticate the user on the e-mail server is markj, and the delimiting character specified on the VPN 3000 concentrator is :, then mark:markj should be entered into the username box on the e-mail client (more on this later).
Figure 10-34
Configuring E-Mail Protocol Ports, Server Addresses or Names, and Methods of Authentication
Similarly, the Service Delimiter is used to separate the e-mail server username from the e-mail server name itself. The default is @, which is often the delimiting character used on e-mail servers. If the delimiting character is different for your e-mail servers, the Service Delimiter should be modified using the drop-down box as appropriate.
Underneath the VPN Name Delimiter and Service Delimiter parameters are the settings for POP3S, IMAP4, and SMTPS ports, default e-mail server IP addresses or names, and methods of authentication.
The ports used for POP3S, IMAP4S, and SMTPS must match those specified on e-mail clients.
The default e-mail server IP addresses or DNS names should be entered into the appropriate boxes. Note that these are the mail servers to which e-mail traffic is sent when e-mail client do not explicitly specify e-mail servers.
As far as methods of authentication are concerned, it is possible to use one or more of the four different methods of authentication for POP3S, IMAP4S, and SMTPS:
Email Server—If this box is checked then it indicates that the e-mail server(s) will authenticate POP3S, IMAP4S, and SMTPS. This box must be checked for POP3S and IMAP4S.
Concentrator—This box must be checked if authentication of users on the VPN 3000 concentrator is also required.
In this case, the e-mail server and concentrator usernames passwords must be separated in the e-mail clients’ configuration using the VPN Name Delimiter character, as previously described.
Piggyback HTTPS—When this box is checked, a regular HTTPS (WebVPN) session must have already been established via a web browser with the VPN 3000 concentrator.
Certificate—If this box is checked, clients are required to authenticate themselves during the RSA handshake using a certificate.
Client configuration is fairly simple—clients should be configured such that they point to the VPN 3000 concentrator instead of directly to an e-mail server.
If you are using Outlook Express, for example, you must configure an e-mail account as normal; if you are using VPN 3000 concentrator authentication in addition to e-mail server authentication for POP3S or IMAP4S, however, you must configure the username and password appropriately (see Figure 10-35).
Configuring the Username and Password on Outlook Express When Using E-Mail Proxy
If you take a look under the “Incoming Mail Server” header in the Servers tab of the account properties, you will notice that the account name is mark:markj.
Because e-mail proxy via the VPN 3000 concentrator is being used, and Concentrator authentication is configured (see the Concentrator box in Figure 10-34), the VPN 3000 concentrator username (mark) is specified first, and the e-mail account name (markj) is specified next. The two usernames are separated using the VPN Name Delimiter (:) specified on the VPN 3000 concentrator (again, see Figure 10-34). If the usernames on both the VPN 3000 concentrator and the e-mail server are the same, it is only necessary to specify the username once (for example, mark).
Now, if the e-mail client in question wants to access e-mail on a mail server that is not the default (see configuration of Default E-Mail Server in Figure 10-34), the e-mail server name must be specified in this same box in this format:
(e-mail_server_username)[Server Delimiter](e-mail_server_name)
So, if the e-mail server is mserver2.mjlnet.com (not the default specified in Figure 10-34), the account name should be mark:markj@mserver2.mjlnet.com.
Next, the password on the Outlook Express account properties Server tab must be configured using a similar format—the VPN 3000 concentrator user password must be specified first, with the e-mail server account password configured second. The two must again be separated using the VPN Name Delimiter.
If the VPN 3000 concentrator is configured to authenticate users and the password user mark is hello, and the e-mail server password for user markj is hithere, the password specified in the Password box on the client must be hello:hithere.
One other important setting to notice on the Server tab is the My server requires authentication check box under Outgoing Mail Server heading. It may be necessary to check this box if you receive an error when attempting to connect to the e-mail server via the VPN 3000 concentrator.
Having configured authentication, the next step is to specify POP3S and SMTPS ports under the Advanced tab, as shown in Figure 10-36.
Figure 10-36
Configuring SMTPS and POP3S Ports on Outlook Express When Using E-Mail Proxy
Under the Server Port Numbers heading you must check both of the This server requires a secure connection (SSL) boxes (for both SMTP and POP3).
Having checked the boxes, you must now specify the ports to use for each protocol. These ports must match those specified on the VPN 3000 concentrator. In Figure 10-36, for example, the SMTPS and POP3S ports are configured as 988 and 995, respectively—these match those specified on the VPN 3000 concentrator in Figure 10-34.
Implementing Full Network Access Using the Cisco SSL VPN Client
By this stage, you will know that the type of access offered by clientless SSL remote access VPNs is much more restricted than that offered by IPsec remote access VPNs. If you do want to offer more functionality via an SSL remote access VPN, you can use the Cisco SSL VPN Client.
The Cisco SSL VPN Client is loaded on the VPN 3000 concentrator and then dynamically downloaded from the VPN 3000 concentrator by remote access VPN users. The Cisco SSL VPN Client offers remote access connectivity comparable to that offered by IPsec remote access VPNs.
One advantage of the Cisco SSL VPN Client is that it does not have to be permanently installed on client workstations and does not require particular configuration or administration, unlike IPsec remote access VPN client software. The Cisco SSL VPN Client software package is also relatively small in size.
It is worth mentioning, however, that for the SSL VPN Client software to be downloaded and installed, the remote access user must have administrative privileges on the workstation. Cisco does, however, provide an install enabler utility (STCIE.EXE) that must itself be installed by an administrator but will then allow other users to download and install the Cisco SSL VPN Client on-demand.
When compared to IPsec remote access VPNs, the disadvantages of an SSL VPN Client include the fact that the client software is downloaded from the VPN 3000 concentrator, which takes a variable amount of time depending on connection speed. Having said that, it is possible to configure the VPN 3000 concentrator to leave the SSL VPN Client software installed on the client workstations rather than causing it to be uninstalled whenever the SSL VPN connection between is terminated (the default).
Installing and Enabling the Cisco VPN Client Software
The first step in enabling use of the SSL VPN Client is to upload it to the VPN 3000 concentrator. You can accomplish this by going to Configuration > Tunneling and Security > WebVPN > Cisco SSL VPN Client (see Figure 10-37).
Figure 10-37
Installing the SSL Cisco VPN Client
Choose Install a new Cisco SSL VPN Client, click the Browse button, browse to the location of the Cisco SSL VPN client software, and click Apply to install the software on the VPN 3000 concentrator.
After the client software is installed, the next step is to enable the use of the SSL VPN Client software for the appropriate user groups, as well as configure IP address pools (described in Chapters 8 and 9).
You can enable the user of the SSL VPN Client software by going to Configuration > User Management > Groups, choosing the appropriate group(s), clicking Modify, and clicking the WebVPN tab. The page shown in Figure 10-38 will then appear.
Checking the Enable Cisco SSL VPN Client box will, as it suggests, enable the use of the SSL VPN Client for the group.
It is also possible to require the use of the SSL VPN client by checking the Require Cisco SSL VPN Client box.
As discussed earlier in this section, the default behavior when using the SSL VPN Client is that the SSL VPN client software is removed when the client disconnects from the VPN 3000 concentrator. If the Keep Cisco SSL VPN Client box is checked, however, the client software remains on the client workstation even after disconnect. This clearly obviates the requirement to dynamically download the client software each time the client workstation connects to the VPN 3000 concentrator.
Figure 10-38
Enabling the Use of the Cisco SSL VPN Client
Understanding Remote Access Connectivity When Using the Cisco SSL VPN Client
When the Cisco SSL VPN Client is enabled for a particular user group, and when a user in that group connects to the VPN 3000 concentrator and logs in via the WebVPN login page, the Cisco VPN SSL Client will begin to download (assuming it is not installed already). After the SSL VPN client has downloaded, it extracts and installs (see Figure 10-39).
One thing to notice in Figure 10-39 is the text shown in the upper left (Click here to skip installation of the Cisco SSL VPN Client and proceed to the WebVPN Home page). This text does not appear if the Require Cisco SSL VPN Client box is checked in the WebVPN tab of group settings (see Figure 10-38).
After the SSL VPN Client software has been installed, a key symbol will appear on the right of the taskbar. Clicking the key will display information about the Cisco SSL VPN Client and SSL connection, as shown in Figure 10-40.
Figure 10-39
Cisco SSL VPN Client Extracts and Installs
Information About the Cisco SSL VPN Client Connection
There are three tabs:
Statistics tab—Displays information about the connection, including address information (the IP address of the VPN 3000 gateway and the IP address assigned by the VPN 3000 concentrator to the SSL VPN Client tunnel interface/adapter); the number of bytes and frames sent and received over the tunnel; the encryption and hashing algorithms used by the cipher suite negotiated by the client and VPN 3000 concentrator; whether the client is allowed to access its local LAN and whether split tunneling is enabled; and how long the connection has been up
Route Details tab—Shows information about local LAN routes and secure routes that have been installed
About tab—Shows the version of the Cisco SSL VPN Client software that is installed
The Reset button on the Statistics tab can be used to reset to zero statistics relating to the number of bytes and frames sent and received over the SSL connection.
The Close and Disconnect buttons cause the Cisco SSL VPN Client information dialog box to close and cause the SSL connection to terminate respectively.
Strengthening SSL Remote Access VPNs Security by Implementing Cisco Secure Desktop
One of the main advantages of SSL remote access VPNs is that they can provide access from almost any location—from a hotel, from an Internet caf , or from a kiosk at an airport. Paradoxically, this ubiquity of access is also one of the main disadvantages of SSL remote access VPNs—these locations are often insecure, and a SSL remote access VPN implementation can, if you are not very careful, allow a hacker or cracker access to sensitive information including usernames, passwords, and data downloaded to the workstation from which a user is connecting.
This access to sensitive information can result from the installation of malware such as keystroke loggers as well as simply because web browser sessions leave traces such as caches, histories, temporary files, cookies, and password autocompletion. In addition, any data downloaded over an SSL remote access VPN and written to a hard disk is not effectively removed by its simple deletion—some or all of that data can be accessed fairly simply by someone with a minimal amount of technical expertise using readily available software tools.
So, having possibly horrified you with the possibilities of the compromise of SSL remote access VPNs, it is time to take a look at how the previously mentioned vulnerabilities can be addressed.
Cisco has software that helps to address these vulnerabilities called Cisco Secure Desktop. This software can be dynamically downloaded to client workstations upon initial connection via an ActiveX, Java, or .exe file.
The Cisco Secure Desktop suite can provide different levels of protection based on the location from which remote access users are connecting. In addition to the removal and overwrite of cache, histories, temporary files, and so on, the Secure Desktop suite can provide access based on the presence of antivirus software, firewall software, and operating systems and service packs.
Secure Desktop operates as follows:
A remote access VPN user connects to the VPN 3000 concentrator.
The Cisco Secure Desktop is dynamically downloaded from the concentrator to the user workstation, and the location of the workstation is assessed.
Depending on the location, a secure, virtual desktop is created; a cache cleaner is applied; and/or a VPN feature policy is applied on the user workstation. The secure desktop includes an encrypted sandbox or hard drive partition.
The user continues with his/her SSL remote access VPN session.
When the user logs out from the VPN 3000 concentrator, the secure desktop is eliminated, with all cache, history, temporary files, and user data (including e-mail attachments) being overwritten using the U.S. Department of Defense (DoD) method for secure data elimination.
Information elimination using overwrite ensures that data cannot be retrieved by another user at a later time.
Figure 10-41 illustrates the operation of Cisco Secure Desktop.
Operation of Cisco Secure Desktop
Installing the Cisco Secure Desktop
The first step in implementing the Cisco Secure Desktop is to install the software on the VPN 3000 concentrator. You can accomplish this by going to Configuration > Tunneling and Security > WebVPN > Secure Desktop > Setup (see Figure 10-42).
Installing the Cisco Secure Desktop
Choose Install a new Secure Desktop, browse to the location where the software is stored, and click Apply. If all is well and good, a page with a message stating that the software has been correctly uploaded will now display.
Configuring the Cisco Secure Desktop for Windows Clients
After the software has been installed, you can go to Configuration > Tunneling and Security > WebVPN > Secure Desktop > Manager to begin configuration.
As previously described, the Cisco Secure Desktop is location based. That is, the Cisco Secure Desktop applied depends on the location from which users connect.
Click the Windows Location Settings heading in the subtree on the left side of the Cisco Secure Desktop window. You will then see the Windows Location Settings page shown in Figure 10-43.
Figure 10-43
Specifying Locations Within Cisco Secure Desktop
In the Location name box, you can specify the names of locations from which user can connect to the VPN 3000 concentrator and add them in turn by clicking the Add button. In Figure 10-43, two locations have been added, home and other.
When users connect to the VPN 3000 concentrator, they are matched against the configured locations in the order that they are listed in the Windows Location Settings window. So, it is important to list to locations in the correct order.
Configuration of the security setting associated with each location is achieved by clicking the location names in the left pane of the window.
You might be wondering how the VPN 3000 concentrator knows that, for example, a user is connecting from his home office and not some other location such as an Internet caf or kiosk. Locations are identified by the Secure Desktop when it downloads to a user workstation depending on whether a certificate is installed on the machine, whether the machine NIC is assigned a certain IP address, or whether a machine has a certain registry setting or file.
Figure 10-44 shows the configuration of the identification criteria for a location (in this example, home).
Figure 10-44
Configuration of the Identification Criteria for a Location
If you take a look at the Identification pane in Figure 10-44 (Identification for home), you will see that there are three options (check boxes):
Enable identification using certificate criteria—By checking this box, it is possible to use the fields of a certificate installed on the user workstation to identify its location.
Enable identification using IP criteria—Checking this box enables an administrator to specify a range of IP addresses. If a user workstation is assigned an IP address within this range, the workstation’s location is identified on this basis.
Enable identification using File or Registry criteria—This box, if checked, allows identification of a location based on a file or registry entry on a user workstation.
In Figure 10-44, the identification of the location home is based on the existence of a file called mjlsetup.exe on the user workstation.
In summary, when a user connects to the VPN 3000 concentrator, the Cisco Secure Desktop dynamically downloads, and the location of the workstation from which the user is connecting is assessed based on the configured criteria.
Having configured the location criteria, it is important to specify which Cisco Secure Desktop suite module or function will be applied on a user workstation according to its location. The modules and functions are as follows:
Cache Cleaner—As the name suggests, this module deletes and disables information including browser caches, temporary files, and autocompletion information, including passwords.
VPN Feature Policy—This module provides selective WebVPN access depending on the presence of components such as antivirus software, operating system type and service pack level, firewall software, and other Secure Desktop components.
Secure Desktop—This module provides a secure, encrypted space (desktop) on Windows XP and Windows 2000. The user session is then created within this secure desktop.
The particular module that is used on a workstation at a particular location depends on the selection specified at the bottom of the Identification pane (see Figure 10-44).
It is possible to choose either Secure Desktop or Cache Cleaner for a particular location by checking the appropriate box next to Use Module. If you do not choose Secure Desktop or Cache Cleaner, the VPN Feature Policy is used for a location.
Configuring the Windows Cache Cleaner
The Cache Cleaner settings for a particular location can be configured by clicking Cache Cleaner in the subtree of that location on the left side of the Cisco Secure Desktop Manager.
Figure 10-45 shows the configuration settings for the Cache Cleaner.
Figure 10-45
Configuration Settings for the Cache Cleaner
Specific settings for Cache Cleaner include the following:
Launch hidden URL after installation—If this setting is checked, a URL can be entered which is launched after the installation of the Cache Cleaner.
Show message at the end of successful installation—If this setting is checked, a message displays on the user workstation confirming the successful installation of the Cache Cleaner.
Launch cleanup upon inactivity timeout—When this option is checked, the Cache Cleaner begins operation after a period of inactivity on the user workstation.
Launch cleanup upon closing of all browser instances—This setting, if checked, causes the Cache Cleaner to begin operation when all browser windows are closed.
Disable cancellation of cleaning—This prevents user cancellation of cache cleaning.
Clean the whole cache in addition to the current session cache (IE only)—Checking this setting ensures that the Internet Explorer cache is cleaned when the Cache Cleaner starts.
Configuring VPN Feature Policy Settings
To configure VPN Feature Policy settings for a location, click the VPN Feature Policy on the subtree of the location; the screen shown in Figure 10-46 will appear.
Figure 10-46
Configuring VPN Feature Policy Settings
Settings for the VPN Feature Policy include Web Browsing, File Access, Port Forwarding, and Full Tunneling.
These settings (levels of access) can be enabled, enabled if certain conditions are fulfilled, or be disabled from a user workstation by choosing ON, ON if criteria are matched, or OFF, respectively, in the corresponding drop-down boxes.
If you choose the ON if criteria are matched option, the criteria that must be fulfilled for a particular level of access to be enabled can be specified by clicking on the ellipsis (. . .) button.
The criteria that can be matched include the presence of antivirus software, firewall software, operating system and service pack, and other Secure Desktop features on the user workstation.
Configuring Secure Desktop Options
When the Secure Desktop is specified for a particular location, you can configure the associated options by clicking Secure Desktop General, Secure Desktop Settings, and Secure Desktop Browser in location subtree.
Figure 10-47 shows the options associated with Secure Desktop General.
Figure 10-47
Configuring Options Associated with Secure Desktop General
Secure Desktop General settings include the following:
Automatically switch to Secure Desktop after installation—When checked, this setting causes the Secure Desktop to load immediately after installation.
Check for keystroke logger before Secure Desktop creation—This setting, if checked, causes a check for a keystroke logger to run before the creation of the Secure Desktop on the user workstation.
This setting only works if the user has administrator privileges on the workstation.
Enable switching between Secure Desktop and Local Desktop (recommended)—If this option is checked, the user can switch between the secure desktop and the regular desktop on the workstation.
It is a very good idea to check this option so that users can respond to any application prompts.
Enable Vault Reuse (User chooses a password)—If checked, a Secure Desktop vault can be reused (and not overwritten between sessions).
The user selects a password to allow access to this Secure Desktop.
Enable Secure Desktop inactivity timeout—When checked, this option causes the Secure Desktop to automatically close after a period of inactivity.
Open following web page after Secure Desktop closes—This setting, if checked, causes a URL to be opened after the Secure Desktop closes.
Suggest application uninstall upon Secure Desktop closes—When this setting is checked, the user is asked whether he/she wants the Secure Desktop uninstalled after it closes.
Force application uninstall upon Secure Desktop closing—The Secure Desktop is forcibly uninstalled after the Secure Desktop closes when checked.
Clicking Secure Desktop Settings in the subtree allows further Secure Desktop options to be configured (see Figure 10-48).
The further four options contained under Secure Desktop Settings are as follows:
Put Secure Desktop in restricted mode—When this setting is checked, only the browser that was originally used to start the Secure Desktop can be used in the Secure Desktop itself.
Restrict Registry tools on Secure Desktop—If checked, this option ensures that a user cannot modify the registry within the Secure Desktop.
Restrict DOS-CMD tools on Secure Desktop—This setting, if checked, prevents the use of the DOS prompt within the Secure Desktop.
Restrict Printing on Secure Desktop—When this option is checked, users cannot print from within the Secure Desktop.
Configuring Secure Desktop Settings
The options under Secure Desktop Settings can be chosen to ensure the highest level of security for the Secure Desktop.
Configuring Cache Cleaner Options for Mac and Linux Users
The Mac and Linux Cache Cleaner heading under the subtree in the Secure Desktop Manager allows the configuration of options associated with the Cache Cleaner for Mac and Linux users.
Figure 10-49 shows the configuration options for the Mac and Linux Cache Cleaner.
Mac and Linux Cache Cleaner options are as follows:
Launch cleanup upon global timeout—When checked, this option causes the Cache Cleaner to run after a period of inactivity on the user workstation.
Let user reset timeout—If this setting is checked, a user can reset the timeout time period.
Launch cleanup upon exiting of browser—This option, if checked, causes the Cache Cleaner to start when all browser instances are closed.
Enable Cancel button of cleaning—When this box is checked, users are able to cancel cache cleaning.
Enable web browsing if Mac or Linux installation fails—This option ensures that web browsing is allowed if the installation of the Cache Cleaner fails.
Figure 10-49
Configuration Options for the Mac and Linux Cache Cleaner
The Successful Installation Policy options allow the configuration of VPN Feature Policy settings for Mac and Linux users:
Web browsing—If ON is chosen, web browsing is allowed from Mac and Linux workstations.
File Access—Allow (ON) or disallow (OFF) file access.
Port Forwarding—Allow or disallow port forwarding.
Note that VPN Feature Policy settings on Mac and Linux workstations do not depend on criteria such as the presence of antivirus software or access from a particular location (unlike Windows VPN Feature Policy settings).
Note – Having configured Cisco Secure Desktop, make sure that you save the configuration within the Cisco Secure Desktop—the configuration is independent of that for the VPN 3000 concentrator as a whole.
Enabling the Cisco Secure Desktop
After all the relevant settings have been configured within the Cisco Secure Desktop Manager, it is time to enable the Cisco Secure Desktop. You can accomplish this under Configuration > Tunneling and Security > WebVPN > Secure Desktop > Setup (Figure 10-50).
Figure 10-50
Enabling the Secure Desktop
Choose Enable Secure Desktop and click Apply. The Secure Desktop is now enabled.
Enabling SSL VPNs (WebVPN) on Cisco IOS Devices
Enabling SSL VPNs on Cisco IOS Software is relatively straightforward and consists of eight basic steps:
Step 1 Configure domain name and name server addresses.
Step 2 Configure remote AAA for remote access user login authentication.
Step 3 Enroll with a CA and obtain an identity certificate.
Step 4 Enable WebVPN.
Step 5 Configure basic SSL parameters.
Step 6 Customize login and home pages (optional).
Step 7 Specify URLs.
Step 8 Configure port forwarding.
These steps are described in detail in the sections that follow.
Step 1: Configure Domain Name and Name Server Addresses
The first step in configuring a Cisco IOS SSL remote access VPN gateway is to configure the default domain name and name server IP addresses. Example 10-1 shows the configuration of the default domain name and name server IP address.
Example 10-1 Configuration of the Default Domain Name and DNS Server IP Address
! ip domain name mjlnet.com ip name-server 10.10.10.55 !
The ip domain name name command is used to configure the default domain name that the router uses to complete any unqualified host names.
The ip name-server server-address1 [server-address2_serveraddress6] command configures the IP addresses of up to six name servers.
Step 2: Configure Remote AAA for Remote Access User Login Authentication
Example 10-2 shows the configuration of remote AAA for remote access user authentication.
Example 10-2 Configuration of Remote AAA for Remote Access User Authentication
! aaa new-model (line 1) ! ! aaa group server radius sslauth (line 2) server 10.10.10.51 auth-port 1645 acct-port 1646 (line 3) ! aaa authentication login default group sslauth (line 4) ! radius-server key mjlnetkey (line 5) !
The aaa new-model command (line 1) enables authentication, authorization, and accounting.
The aaa group server radius group-name command in line 2 is then used to configure a group of RADIUS servers. In this case, the name of the group of servers is sslauth.
In line 3, the server ip-address [auth-port port-number] [acct-port port-number] command is then used to specify the IP addresses of RADIUS servers in the group, along with the ports used for authentication/authorization (auth-port) and accounting (acct-port). In this case, there is only one server in the group (10.10.10.51), and the ports used for AAA are the defaults (1645 and 1646).
The aaa authentication login [default | method-list-name] group group-name command (line 4) configures login authentication using the default method list and the (previously created) RADIUS server group called sslauth. Login authentication is required for SSL remote access VPN users.
Note that it is possible to configure local authentication for SSL remote access VPN users using the aaa authentication login [default | method-list-name] local command in conjunction with a local username/password database configured using the username username password password command.
In a practical sense, however, a local username/password database is much more difficult to administer than a local user database on a VPN 3000 concentrator—this is why RADIUS is recommended when configuring SSL remote access VPNs using Cisco IOS Software. RADIUS can also be used for WebVPN on the VPN 3000 concentrator.
Finally, the radius-server key {0 string | 7 string | string} command in line 5 configures the key that is used to authenticate communications between the router and the RADIUS server (as well as encrypting user passwords sent to the server).
Step 3: Enroll the IOS Router with a CA and Obtain an Identity Certificate
Enrolling the Cisco IOS router with a CA and obtaining an identity certificate consists of the following:
Setting the time on the Cisco IOS router
Configuring the router’s host name and IP domain name
Generating RSA keys on the router
Declaring the CA
Authenticating the CA
Enrolling the router with the CA
These tasks are described in detail in the section “IKE Digital Signature Authentication,” starting on page 448 in Chapter 6, “Deploying Site-to-Site IPsec VPNs.”
Step 4: Enable WebVPN
As shown in Example 10-3, the webvpn enable global configuration mode command is used to enable SSL remote access VPNs (WebVPN).
Example 10-3 Enabling SSL Remote Access VPNs (WebVPN)
mjlnet.vpn.gw.02#conf t Enter configuration commands, one per line. End with CNTL/Z. mjlnet.vpn.gw.02(config)#webvpn enable mjlnet.vpn.gw.02(config)#exit mjlnet.vpn.gw.02#
It is worth noting that if the Cisco IOS device is configured as a HTTP secure (HTTPS) server, it is necessary to add the gateway-addr ip-address parameter along with the webvpn enable command (webvpn enable gateway-addr ip-address). This parameter causes WebVPN to be only enabled on the (interface) IP address specified.
Step 5: Configure Basic SSL Parameters
Having enabled WebVPN, the next step is to configure basic SSL parameters, including cryptographic algorithms (and associated cipher suites), and specify the SSL trustpoint.
Example 10-4 shows the configuration of basic SSL parameters.
Example 10-4 Configuration of Basic SSL Parameters
!webvpn ssl encryption 3des-sha1 ssl trustpoint sslcert !
The webvpn global configuration command is used to enter WebVPN configuration mode.
Next is the ssl encryption [3des-sha1] [des-sha1] [rc4-md5] command. This command specifies the encryption and hashing algorithms that the router will accept from the client as constituents of cipher suites.
So, when a client proposes a number of cipher suites in its ClientHello message, the router will accept one of those that uses the algorithms that you specify using the ssl encryption command. The accepted cipher suite is, as previously described, sent to the client in the ServerHello message—see the section, “Establishing an SSL Connection Between a Remote Access VPN User and an SSL VPN Gateway Using an RSA Handshake” earlier in this chapter for more information of the proposal and acceptance of cipher suites.
The ssl trustpoint trustpoint-name command specifies the PKI trustpoint, which in turn configures parameters (including the certificates, CRL configuration, and so on) that are used for authentication during the SSL RSA handshake. Make sure that the trustpoint name configured using the ssl trustpoint-name corresponds to that specified using the crypto pki trustpoint name command in Step 3.
Step 6: Customize Login and Home Pages (Optional)
As a final, optional, configuration step, it is also possible to customize the appearance of the WebVPN login and home pages using your own text and colors. Example 10-5 includes the commands that can be used to customize the text in login and home pages.
Example 10-5 Commands Used to Customize the Login and Home Pages
! webvpn title "TITLE.here" url-list "URL.List" heading "HEADING.here" login-message "LOGIN.Message.here" !
The effect of the commands shown in Example 10-5 is best illustrated by examining Figures 10-51 and 10-52.
Customizing Text in the WebVPN Login Page
Figure 10-52
Customizing Text in the WebVPN Home Page
A quick comparison between Example 10-5 and Figure 10-51 shows that the title title-string command can be used to specify the HTML title string in the top right corner of the WebVPN login screen.
The login-message message-string command is used to specify the text in the login box in the upper centre of the login screen.
In Figure 10-52, you can see that heading heading-string command is used to configure the text heading on upper left of the home page.
Finally, the text specified in the url-list list-name command is placed on the left of the home page and within the floating toolbar (shown in the lower right in Figure 10-52). URLs that a user can access are listed below this text.
Colors in the login and home pages can also be modified using the following commands:
title-color color—Configures the color of the title bars of the login and home pages.
The color parameter can be specified as comma-separated red, blue, green values; as HTML color values, beginning with a hash character (#); or the name of an HTML color, with no spaces.
For more information on HTML color values, do a search using your favorite Internet search engine—a huge number of sites describe these values.
text-color [black | white]—This command is used to specify the color of the text in the title bars.
secondary-color color—Use this command to specify the color of the secondary title bars of the login and home pages. The color parameter is specified in the same way as with the title-color command.
secondary-text-color [black | white]—This specifies the color of the text in the secondary bars.
One final command that you can use to customize the appearance of the login and home pages is logo [file filename | none]. As you can probably guess, this command can be used to specify the logo image that is used (in place of the default Cisco logo in Figures 10-51 and 10-52). The image specified must be JPG, GIF, or PNG or a size less than 100k. The filename parameter is used to specify both the location and name of the image file.
Step 7: Specify URLs
The url-text text url-value url to configure the URLs that remote access users can access. The text parameter is used to specify the text that users can click to access the specified URL—the URL itself is specified with the url parameter. The text specified using this command displays under the text configured using the url-list command discussed in the previous section.
Example 10-6 shows some examples of the use of the url-text command.
Example 10-6 Specifying URLs Using the url-text Command
! webvpn url-list "URL.List" url-text "URL.TEXT" url-value "http://www.mjlnet.com/engineering" url-text "URL.TEXT2" url-value "http://www.mjlnet.com/designs" url-text "URL.TEXT3" url-value "http://www.mjlnet.com/projects" !
Step 8: Configure Port Forwarding
It is also possible to configure port forwarding on a Cisco IOS router. To configure this feature, use the port-forward {list list-name} {local-port port-number} {remote-server server-name-or-ip-address} {remote-port port-number} command, as shown in Example 10-7.
Example 10-7 Configuring Port Forwarding
! webvpn port-forward list terminal-services local-port 3389 remote-server 10.10.10.52 remote-port 3389 !
If you compare the port-forward command shown in Example 10-7 to the example of TCP port forwarding described in the section “Enabling TCP Applications over Clientless SSL Remote Access VPNs” earlier in this chapter, you will see that the command syntax is fairly self-explanatory:
The list-name parameter configures a name that identifies a TCP application and is displayed in the Application Access window on the client.
The local-port parameter is used to specify TCP port of traffic on a client that is redirected over SSL to the Cisco IOS router
The server-name-or-ip-address parameter specifies the DNS name or IP address of the TCP application server
The remote port parameter specifies the TCP port of the application on the application server.
Example 10-7 shows the configuration of port forwarding for a Windows Terminal Server (10.10.10.52) using the default TCP port 3389.
Deploying SSL VPNs (WebVPN) on the ASA 5500
You should be getting the hang of this by now—you know all about SSL remote access VPNs including underlying operation, basic SSL parameters, customizing login and home pages, specifying URLs, port forwarding, e-mail proxy, and file access. So, this section is not going to bore you by reexamining these concepts in too much detail.
Configuring SSL VPNs (WebVPN) on the ASA is a very similar process to enabling SSL VPNs on the Cisco VPN 3000 concentrator or Cisco IOS router:
Step 1 Configure the HTTP server.
Step 2 Enable WebVPN on the outside interface.
Step 3 Configure the WebVPN group policy and attributes.
Step 4 Configure remote access user authentication.
Step 5 Specify URLs.
Step 6 Configure file access and browsing.
Step 7 Configure port forwarding.
Step 8 Specify an SSL trustpoint, SSL version, and SSL encryption algorithm (optional).
Step 9 Customize login and home pages (optional).
These steps are examined in the sections that follow.
Step 1: Configure the HTTP Server
The first step in configuring WebVPN is to enable the HTTP server on the ASA and optionally configure HTTP redirect using the http server enable and http redirect interface [port] commands in global configuration mode command (see Example 10-8).
Example 10-8 Enabling the HTTP Server
! http server enable http redirect Outside0/1 80 !
The http redirect command in Example 10-8 allows users that connect to the ASA on TCP port 80 (HTTP) on outside interface Outside0/1 to be redirected to port 443 (HTTPS).
Step 2: Enable WebVPN on the Outside Interface
Having enabled the HTTP server, the next step is to enable WebVPN on the outside interface using the enable outside-interface-name command in the WebVPN mode (see Example 10-9).
Example 10-9 Enabling WebVPN on the Outside Interface
! webvpn enable Outside0/1 !
In Example 10-9, the webvpn global configuration mode command is used to enter WebVPN mode.
The enable interface-name command then enables WebVPN on interface Outside0/1.
Step 3: Configure the WebVPN User Group Policy and Attributes
As described in Chapter 9, the ASA uses a similar policy-inheritance mechanism to the Cisco VPN 3000 concentrator—there is a user policy, a user group policy, and a default group policy. The user policy inherits setting from the group policy, which in turn inherits settings from the default policy.
The user group policy for WebVPN is configured as shown in Example 10-10.
Example 10-10 Configuration of Group Policy for WebVPN
! group-policy webvpn.grp.policy internal group-policy webvpn.grp.policy attributes vpn-tunnel-protocol webvpn webvpn! !
The group-policy name internal global configuration mode command is used to configure an internal user group policy with (in this case) the name wevpn.grp.policy.
The group-policy name attributes command then begins the configuration of attributes associated with the user group named web.grp.policy.
The vpn-tunnel-protocol webvpn specifies that this user group is restricted to WebVPN only (and does not include IPsec).
User group attributes relating to WebVPN are then configured under the webvpn command (more on this later).
Step 4: Configure Remote Access User Authentication
To authenticate remote access users during login, you can use either the local username/password database or a AAA server.
Example 10-11 shows the configuration of a local username/password database.
Example 10-11 Configuration of a Local Username/Password Database
! username pete password ueQDRVFmwEjd4hRT encrypted username dave password IkTiDoEuVyjoxmBU encrypted username john password hN7LzeyYjw12FSIU encrypted username mark password 7EwWZdAmpPRnJfI1 encrypted ! !
In Example 10-11, a local username and password database (consisting, in this case, of four users) is configured using the username username password password global configuration mode command. The ASA encrypts passwords by default, and so the encrypted keyword is added in the configuration file.
As previously described, a local username and password database is not scalable, and so is only suitable for small-scale deployments. For larger-scale deployments, users can be authenticated using RADIUS, TACACS+, NT domain, Kerberos, and SDI.
If you want to use an authentication server for user authentication, you can use the aaa-server server-tag protocol server-protocol and aaa-server server-tag [(interface-name)] host server-ip [key] [timeout seconds] commands.
The aaa-server protocol command is used to specify group AAA parameters and protocols associated with servers, and the aaa-server host command is used to configure parameters associated with a particular server (such as IP address and key).
Step 5: Specify URL Lists
The next step is to specify the URLs that the remote access users can access via links on his/her home page. As shown in Example 10-12, you can accomplish this by configuring a URL list.
Example 10-12 Specifying URLs Using the url-list Command
! url-list URL.List "URL.TEXT" http://www.mjlnet.com/engineering url-list URL.List "URL.TEXT2" http://www.mjlnet.com/designs url-list URL.List "URL.TEXT3" http://www.mjlnet.com/projects !
The url-list list-name displayname url command configures the URLs that users can access. The listname parameter groups URLs together, and the displayname parameter configures the names that will be displayed, and users can click to access the specified URLs.
Having configured the URL list, you should now link to the list under the user group (WebVPN) attributes using the url-list {value name | none} command (see Example 10-13).
Example 10-13 Linking to the URL List Under the User Group
! group-policy webvpn.grp.policy attributes webvpn functions url-entry (line 1) url-list value URL.List (line 2) !
The url-list {value name | none} command in highlighted line 2 links to the URL list configured in Example 10-13 (URL.List in this example).
If you want remote access users to also be able to manually enter URLs that they want to access via WebVPN (in addition to URLs accessible via the URL list), you can configure the functions url-entry command shown in highlighted line 1.
After the URL list is configured, you can then optionally configure an HTTP or HTTPS proxy server in WebVPN mode, as demonstrated in Example 10-14.
Example 10-14 Configuring an HTTP/HTTPS Proxy Server
! webvpn http-proxy 10.10.10.1 80 https-proxy 10.10.10.1 443 !
The webvpn global configuration mode command is used to enter WebVPN mode.
The http-proxy ip-address [port] and https-proxy ip-address [port] commands are then used to configure the IP addresses of HTTP and HTTPS proxy servers (10.10.10.1, in this case). Note that the default ports for HTTP and HTTPS are specified in this example (ports 80 and 443, respectively).
Step 6: Configure File Access, Entry, and Browsing
As shown in Example 10-15, to enable file access and file sharing, it is necessary to first configure one or more WINS servers/NetBIOS name servers (NBNS) using the name-server {ip-address-or-hostname} [master] [timeout timeout] [retry retries] command, and then to enable file access, entry, and browsing as appropriate using the functions command.
Example 10-15 Configuring File Access, Entry, and Browsing
! webvpn nbns-server 10.10.10.51 master timeout 2 retry 2 nbns-server 10.10.10.52 timeout 2 retry 2 ! group-policy webvpn.grp.policy attributes webvpn functions file-access file-entry file-browsing !
In this example, one master browser is configured (10.10.10.51, configured using the master keyword), with one other WINS server (10.10.10.52) in WebVPN mode. The timeout keyword can be used to specify the time before the ASA will resend a query, and the retry keyword can be used to specify the number of times to retry queries to WINS/NBNS servers respectively. In this case, the timeout and retry values are set to their defaults of 2 and 2.
The functions file-access file-entry file-browsing command is then used to enable file access, entry, and browsing under the group policy (webvpn.grp.policy in this example).
Step 7: Configure Port Forwarding
You can configure port forwarding using a list in global configuration mode, then referencing that list from the user group, and finally enabling port forwarding using the functions command (see Example 10-16).
Example 10-16 Configuring Port Forwarding
! port-forward tcp.apps 1350 10.10.10.99 telnet (line 1) ! group-policy webvpn.grp.policy attributes webvpn functions port-forward (line 2) port-forward value tcp.apps (line 3) port-forward-name value Port-Forwarding (line 4) !
The port-forward {listname localport remoteserver remoteport description} command in highlighted line 1 is used to configure the TCP applications that remote access users can access. The parameters used with the port-forward global configuration mode command are as follows:
The listname parameter configures a name that identifies a set of TCP applications. In this case, the list of TCP applications is tcp.apps.
The localport parameter is used to specify a TCP port of traffic on a client that is redirected over SSL to the ASA. In highlighted line 1, the port-forward command configures TCP traffic on port 1350 to be redirected from remote access clients over SSL to the ASA.
The remoteserver parameter specifies the DNS name or IP address of the TCP application server to which the ASA will send TCP traffic forwarded by the remote access clients. In this example, the address of the TCP application server is 10.10.10.99. Note that you can specify DNS server addresses using the dns name-server ip-address global configuration mode command, and the interface on which to enable DNS lookup using the dns domain-lookup interface-name command.
The remote port parameter specifies the TCP port of the application on the application server (TCP port 23 [Telnet], in this example).
The port-forward {value listname | none} in highlighted line 3 (under the user group attribute configuration) then references the port-forward list configured in highlighted line 1.
In highlighted line 4, the port-forward-name {value listname | none} configures the name that identifies TCP port forwarding on the WebVPN home page (the remote access users can click the name in the home page to launch port forwarding). In this case, the name is configured as Port-Forwarding.
Finally, the functions port-forward command in highlighted line 2 enables port forwarding on the ASA.
Step 8: Configure E-mail Proxy
Example 10-17 shows the configuration of e-mail proxy on the ASA.
Example 10-17 Configuration of E-mail Proxy
! pop3s enable Outside0/1 server 10.10.10.52 default-group-policy webvpn.grp.policy authentication aaa smtps enable Outside0/1 server 10.10.10.52 default-group-policy webvpn.grp.policy !
In this Example 10-17, e-mail proxy for POP3S and SMTPS are specified.
The pop3s global configuration mode command commences the configuration of POP3S.
The enable interface-name command enables POP3S on the specified outside interface (in this case, Outside0/1). The server {ip-address-or-hostname} command is used to configure the IP address or host name of the default e-mail server to which POP3S traffic from remote access users’ e-mail clients will be directed by the ASA (10.10.10.52 in this example).
The default-group-policy group-policy command is then used to specify the default user group, which in this case is webvpn.grp.policy.
Finally, the authentication {aaa | certificate | piggyback} command configures (in this example) the ASA to use a username and password for e-mail proxy authentication. Because no specific authentication server is configured in this particular example, the local username and password database is used for e-mail proxy authentication.
Alternative methods of e-mail proxy authentication to use are certificate authentication (authentication certificate) and piggyback authentication (authentication piggyback).
If certificate authentication is configured, the remote e-mail client must present a certificate for authentication (and the certificate must be issued by a CA trusted by the ASA [the CA’s certificate must be installed on the ASA]). For more information on certificate authentication with the ASA, see Chapter 9.
Piggyback authentication requires the remote access user to already have established a standard WebVPN session with the ASA before connecting using his/her e-mail client.
The smtps command then begins the configuration of SMTPS on the ASA.
The enable interface-name command again enables SMTPS on the specified outside interface, the server {ip-address-or-hostname} command again specifies a default e-mail server IP address or host name, and the default-group-policy group-policy command again configures the default user group policy (webvpn.grp.policy).
In the case of SMTPS, mail host authentication (authentication mailhost) is available in addition to the other method of authentication. When mail host authentication is used, the remote e-mail client must present a username, password, and other information. Mail host authentication is used by default with POP3S (and IMAP4).
Depending on the specific types of e-mail client that remote users are using, you may also want to configure support for IMAP4S. Configuration is very similar to that for POP3S and SMTPS—you begin configuration with the imap4s global configuration mode command, enable IMAP4S on the outside interface (interface interface-name), specify a default e-mail server (server {ip-address-or-hostname}, and configure authentication (authentication {aaa | certificate | piggyback}).
Step 9: Specify an SSL Trustpoint, SSL Version, and SSL Encryption Algorithm (Optional)
The ASA can optionally be configured to specify an SSL trustpoint and to restrict the SSL client hellos that it accepts and the versions of SSL that it will negotiate and the cryptographic algorithms that the ASA will negotiate with the remote access client.
Specifying an SSL Trustpoint
By default the ASA uses a self-signed certificate during SSL negotiation, but it is also possible for the ASA to use a certificate obtained from a CA.
You can enroll the ASA with a CA and obtain an identity certificate using the method described in Chapter 9. After that has been accomplished, you can specify that the identity certificate obtained from the CA should be used for SSL negotiation using the ssl trust-point {trustpoint [interface]} command in global configuration mode.
The CA trustpoint configured using the crypto ca trustpoint should be referenced using the trustpoint parameter with the ssl trust-point command. If you want to limit the ASA to use only the certificate when negotiating SSL on a certain (outside) interface, you can specify that interface using the interface parameter.
Restricting Acceptable SSL Versions
It is also possible to specify the version of SSL that you want the ASA to use with remote access clients using the ssl server-version [any | sslv3 | tlsv1 | sslv3-only | tlsv1-only] global configuration mode command. By default, the ASA will accept SSLv2 client Hellos, and negotiate SSLv3 and TLSv1 (but not SSLv2). The various keywords used with the ssl server-version command have the following meanings:
any—This keyword causes the ASA to accept SSLv2 client Hellos and negotiate either SSLv3 or TLS version 1 with the remote access clients.
sslv3—This causes the ASA to accept SSLv2 client Hellos and negotiate to SSLv3.
tlsv1—The ASA accepts SSL version 2 client Hellos and negotiates to TLSv1.
sslv3-only—The ASA accepts SSLv3 client Hellos only and negotiates SSLv3 only.
tlsv1-only—The ASA accepts TLSv1 client Hellos only and negotiates TLSv1 only.
Think carefully before changing the default (any) because port forwarding will only work if the ASA is configured to negotiate SSLv3 or SSLv3/TLSv1. It will not work if the ASA is configured to negotiate TLSv1, TLSv1 only, or SSLv3 only because Java download will not function.
Configuring the Cryptographic Algorithms That the ASA Will Negotiate with Remote Access Clients
Finally, it is also possible to configure the cryptographic algorithms that the ASA will negotiate with remote access clients using the ssl encryption global configuration mode command. At the time of this writing, the keywords (and cryptographic algorithms) that can be specified using this command are as follows:
3des-sha1—This keyword configures the ASA to accept the 3DES and SHA-1 algorithms.
des-sha1—This configures the ASA to accept the DES and SHA-1 algorithms.
rc4-md5—This configures the ASA to accept the RC4 and MD5 algorithms.
By default, the ASA will accept all of these cryptographic algorithms (in the order specified above).
Step 10: Customize Login and Home Pages (Optional)
As with Cisco VPN 3000 concentrators and Cisco IOS routers, it is possible to customize the appearance of the WebVPN login and home pages on the ASA. This can be accomplished using the following commands (configured under WebVPN configuration mode [entered using the webvpn global configuration mode command]):
login-message [string]—This command can be used configure a message that displays when a user logs in (the default is, “Please enter your username and password”).
logo {file filename | none}—This specifies a logo that is shown on the login and home pages. The default is the Cisco logo (the logo format can be JPG, PNG, or GIF, and must be less than 100k in size).
logout message [string]—This can be used to specify a message that is shown when a remote access user logs out (the default is “Goodbye”).
username-prompt [prompt]—A string indicating input of a username on the login screen. The default is Login:.
password-prompt [string]—The string indicating input of the password on the login screen, with the default being Password:.
title [string]—This is a string that is shown as a title in the login page and as a title bar. The default is WebVPN Service.
title-color {color}—The color of the title bars on the login page, home page, and file access page. The color can be specified as a comma separated RGB value, an HTML color value, or an HTML color name (the default is HTML value #999CC [lavender]).
text-color [black | white | auto]—The color of the text in the text bars on the login page, home page, and file access page (the default is white).
secondary-color {color}—The color of the secondary title bars on the login page, home page, and file access page. The default secondary color is lavender (HTML color value #CCCCFF).
secondary-text-color—The color of the secondary text bars on the login page, home page, and file access page. The default is black.
Verifying SSL VPNs on the ASA
You can use a number of commands to verify the operation of WebVPN on the ASA 5500. One of the most useful is show vpn-sessiondb (see Example 10-18).
Example 10-18 show vpn-sessiondb webvpn Command Output
mjlnet.VPN.GW.10# show vpn-sessiondb webvpn Session Type: WebVPN (line 1) Username : mark (line 2) Index : 1 IP Addr : 172.16.34.145 (line 3) Protocol : WebVPN Encryption : 3DES (line 4) Bytes Tx : 17529 Bytes Rx : 12469 (line 5) Client Type : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.12) Gecko (line 6) Group : DfltGrpPolicy (line 7) Login Time : 17:05:18 UTC Sat Nov 12 2005 (line 8) Duration : 0h:01m:35s (line 9) Filter Name : mjlnet.VPN.GW.10#
Highlighted line 1 shows that the session type is WebVPN.
In highlighted lines 2 and 3, you can see the username and IP address of the remote access client.
Then, in highlighted line 4, you can see that the SSL session is using 3DES encryption.
Highlighted line 5 shows the number of bytes transmitted (Tx) and received (Rx), and highlighted line 6 shows information relating to the browser being used by the remote access client (Mozilla/5.0 [Firefox] in this case).
Highlighted line 7 shows that the group policy that has been applied is the default (DfltGrpPolicy).
In highlighted lines 8 and 9, you can see the time when the remote access user logged on and the duration of the session, respectively.
Summary
SSL remote access VPNs are a relatively new type of VPN (although the protocol itself is not new). They have a number of advantages and disadvantages when compared to other types of remote access VPN—no specific client software is required by remote access user (only a web browser is required); only limited functionality is offered by clientless SSL remote access VPNs (although more functionality can be achieved using the Cisco SSL VPN Client); little configuration is required on firewalls and NAT devices because HTTPS is typically permitted/SSL is carried over TCP; and SSL VPNs, if not correctly configured, can introduce vulnerabilities into a corporate network because of the untrusted locations from which they can allow access.
The operation of SSL remote access VPNs can include the basic RSA handshake, the RSA handshake with client authentication, resumption of an SSL session, and closing an SSL connection.
SSL remote access VPNs come in two basic forms: clientless SSL remote access VPNs, and SSL remote access VPNs using specific client software. Clientless SSL remote access VPNs can provide file and web server (URL) access, port forwarding, and e-mail proxy, whereas the Cisco SSL VPN Client provides access comparable to that provided by IPsec and L2TP/IPsec remote access VPNs.
As previously discussed, SSL remote access VPNs can potentially introduce vulnerabilities into a corporate network, but these can be addressed via the implementation of the Cisco Secure Desktop. The Cisco Secure Desktop has various modules, including Cache Cleaner, VPN Feature Policy, and the Secure Desktop itself, each of which can address different types/levels of potential vulnerability.
Review Questions
How many versions of SSL are there, and which can be implemented on Cisco equipment?
What are some of the main advantages and disadvantages of SSL remote access VPNs?
What type of protocol is SSL transported over?
What protocols does SSL consist of?
What are the functions of the record protocol?
What software is required on client workstations for port forwarding to function?
What types of applications can be used with port forwarding?
What is SSL VPN e-mail proxy?
How is the Cisco SSL VPN Client installed on remote access users’ workstations?
How does the Cisco Secure Desktop assess the location of a remote access user’s workstation?
Copyright © 2007 Pearson Education. All rights reserved.
