Chapter 10: Designing and Building SSL Remote Access VPNs (WebVPN)

Cisco Press

1 2 3 4 5 6 7 8 Page 8
Page 8 of 8

In this example, one master browser is configured (, configured using the master keyword), with one other WINS server ( 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 telnet (line 1)
group-policy webvpn.grp.policy attributes
 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 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

 enable Outside0/1
 default-group-policy webvpn.grp.policy
 authentication aaa
 enable Outside0/1
 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 ( 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     : (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  : 

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.


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

  1. How many versions of SSL are there, and which can be implemented on Cisco equipment?

  2. What are some of the main advantages and disadvantages of SSL remote access VPNs?

  3. What type of protocol is SSL transported over?

  4. What protocols does SSL consist of?

  5. What are the functions of the record protocol?

  6. What software is required on client workstations for port forwarding to function?

  7. What types of applications can be used with port forwarding?

  8. What is SSL VPN e-mail proxy?

  9. How is the Cisco SSL VPN Client installed on remote access users' workstations?

  10. How does the Cisco Secure Desktop assess the location of a remote access user's workstation?

Copyright © 2007 Pearson Education. All rights reserved.

Learn more about this topic

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2007 IDG Communications, Inc.

1 2 3 4 5 6 7 8 Page 8
Page 8 of 8
SD-WAN buyers guide: Key questions to ask vendors (and yourself)