Deploying Site-to-Site and Remote Access VPNs: A Comparison

Deploying SSL VPNs (WebVPN) on the ASA 5500

You should be getting the hang of this by nowyou 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 concentratorthere 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 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 SMTPSyou 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:

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:

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]):

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.

Категории