IPSec Remote-Access EVS Setup

Now that you have a basic understanding of how a remote-access connection is built, I discuss how you would use a router as an EVS, including how to configure it to support remote-access IPSec clients. The following sections discuss the configuration details of this process. Again, I focus only on the basics of this configuration.

Configuration Process

When setting up IPSec remote-access connections on your EVS router, you perform these basic tasks:

Task 1? Define your AAA policies for authentication of devices (preshared keys and RSA signatures) and users (XAUTH).

Task 2? Define the group information for your remote-access clients, which includes the policies for the groups.

Task 3? Create your IKE Phase 1 policies.

Task 4? Create your dynamic crypto map, which is used for remote-access connections.

Task 5? Create your static crypto map, which includes the dynamic crypto map as an entry (the static crypto map references the dynamic crypto map).

Task 6? Verify your configuration to ensure that your client connections are correct.

The following sections cover these tasks.

Task 1: Authentication Policies

To perform client authentication for remote access, you can have your router perform XAUTH authentication locally or forward authentication requests to an AAA server. In either method, you need to enable AAA:

Router(config)# aaa new-model

If you will have the router perform the authentication, you configure the following command for each user:

Router(config)# username username secret password

This command was discussed in Chapter 3, "Accessing a Router."

For an AAA server, you need to configure one of the two following commands, based on whether you are using TACACS+ or RADIUS as your security protocol.

If you are using TACACS+, use this command:

Router(config)# tacacs-server host IP_address [single-connection] 

  [port port_#] [timeout seconds] [key encryption_key]

If you are using RADIUS, use this command:

Router(config)# radius-server host IP_address [auth-port port_#] [acct-port port_#] 

  [timeout seconds] [retransmit retries] [key key_value]

  [alias {hostname|IP_address}]

These commands were discussed in Chapter 5, "Authentication, Authorization, and Accounting."

With either local or remote authentication, you need to set up AAA authentication and authorization with the following two commands:

Router(config)# aaa authentication login authen_list_name method

Router(config)# aaa authorization network author_list_name method

The aaa authentication login command handles XAUTH user authentication. Do not use the keyword default for the authen_list_name because this affects all login methods. Instead, give it a unique name, which you will reference later in your remote-access configuration (in the crypto map dynamic_map_name client authentication list command). The methods that you can list are group tacacs, group radius, or local.

The aaa authorization network command handles the authorization of the remote-access IPSec connection. This author_list_name must match the list_name in the crypto isakmp client configuration group command, discussed later.

Task 2: Group Policies

After setting up AAA, you can go ahead and define your users' group policies. For each group, you can configure the following information:

Router(config)# ip local pool IP_pool_name

  beginning_IP_address ending_IP_address

Router(config)# crypto isakmp client configuration group

  author_list_name [max-users #_of_users] [max-logins #_of_logins]

Router(config-isakmp-group)# pool IP_pool_name

Router(config-isakmp-group)# key pre_shared_key

Router(config-isakmp-group)# domain domain_name

Router(config-isakmp-group)# dns 1st_server_IP 2nd_server_IP

Router(config-isakmp-group)# wins 1st_server_IP 2nd_server_IP

Router(config-isakmp-group)# split-dns domain-name

Router(config-isakmp-group)# acl ACL_#_or_name

Router(config-isakmp-group)# include-local-lan

Router(config-isakmp-group)# firewall are-u-there

Router(config-isakmp-group)# access-restrict interface_name

Router(config-isakmp-group)# save-password

The ip local pool command creates an address pool of internal addresses that will be assigned to your remote-access clients. The pool must have a unique pool name, and you must list the beginning and ending IP addresses in the pool. You will reference this in your group configuration.

The crypto isakmp client configuration group command creates your remote-access group. Note that you must enter the group name here, which needs to match the author_list_name in the aaa authorization network command discussed previously. When a client initiates a remote-access connection, it passes the group name to the server (router), and the server uses this to apply the policies from the respective group to the user's access. The optional max-users parameter is used to restrict the number of connections to a remote access group. This value can range from 1 to 5000. The optional max-logins parameter restricts the maximum number of simultaneous logins for the specified group. This can range from 1 to 10. These last two parameters are new in IOS 12.3(4)T.

When you execute the crypto isakmp client configuration group command, you enter a subconfiguration mode where you can enter the group's policies:

• EVCs that are connecting in client mode need to be assigned an internal IP address. The pool that you use for these addresses was defined previously by the ip local pool command; you reference that pool here with the pool command.

• If your IKE Phase 1 policy states that you will use preshared keys, you need to configure the key command with the group's preshared key value. Otherwise, if you are using certificates, you omit this value.

• The domain command specifies the DNS domain name to assign to the remote-access client.

• With the dns command, you can assign up to two DNS server IP addresses to the client. With the wins command, you can assign up to two WINS server addresses.

• The split-dns command is new in 12.3(4)T and enables you to specify which domains the DNS servers in the dns command should be used in. For example, if you specify a domain name of quizware.com in the split-dns command, only this domain uses the DNS servers in the dns command for resolutions. Basically, these DNS resolutions are tunneled across the IPSec connection; otherwise, the EVC uses the DNS servers locally assigned to it for resolution.

• The acl command specifies a name or number of an ACL. Any traffic matching a permit statement in this ACL must be protected; anything else is ignored, from an IPSec perspective. This is used to set up split tunneling on the EVC, and it protects specified traffic to the central site and allows unprotected access to other sites. The default is that all traffic must be sent to the EVS when the IPSec tunnel is up between the EVC and EVS.

• The include-local-lan command is new in 12.3(2)T and is an alternative to split tunneling with the acl command. The include-local-lan parameter allows the client to perform split tunneling where access to its local LAN segment is allowed in an unprotected fashion, but all other traffic must be sent to the central site's EVS. This allows the EVC to access local resources. One restriction with this command is that you must use an AAA RADIUS server for the authenticated user.

• The firewall are-u-there command is new in IOS 12.3(2)T. This command implements the Are You There (AYT) VPN feature, where the EVS has the software EVC check for the existence of a local firewall. Supported client firewalls include Black Ice and Zone Alarm. If you configure this option and the client device does not have a supported firewall operational, the EVS drops the connection. (The EVS probes this information from the EVC.) One nice thing about the Cisco VPN 3.x and 4.x clients is that they already have a stripped-down version of ZoneAlarm integrated into the client software, called Cisco Integrated Client (CIC). The use of this feature adds more security to your VPN solution; however, it does require that you use RADIUS authentication for users in this group. Another feature of AYT is that when this policy is pushed down to the client, the Cisco client software periodically checks to make sure that the client is there. If it is not, the Cisco client does not allow outbound traffic until the client enables the supported firewall product.

• The access-restrict command is new in 12.2(13)T and enables you to restrict the termination of a client's IPSec connection to a specific interface. This command has bearing only if you have applied the crypto map that this group's configuration is associated with to multiple interfaces on your router. You can define multiple restricted interfaces, if that is necessary. Note that this command works only if the users in this group all are being authenticated with RADIUS.

• The save-password command, new in IOS 12.3(2)T, allows the client to store the XAUTH (user) password locally on the client device. The default is to not allow this to occur, and I highly recommend that you leave it this way for PC or laptop clients. However, for PIX, router, or 3002 clients, you need to enable this option. Therefore, if you have a mixture of both types of clients, create at least two groups: one for the PC and laptop clients, and the other for the hardware clients. This command requires the use of AAA authentication through RADIUS.

Task 3: IKE Phase 1 Policies

After you define your remote-access groups, you are ready to move to your IKE Phase 1 policies. Many of the commands discussed in the previous chapter are also used here. First, you need to configure an IKE Phase 1 policy that matches the capabilities of the clients in your remote-access group(s). This is accomplished with the following commands, which were covered in the previous chapter:

Router(config)# crypto isakmp policy priority_#

Router(config-isakmp)# authentication {rsa-sig | rsa-encr | pre-share}

Router(config-isakmp)# encryption {des | 3des | aes | aes 192 | aes 256}

Router(config-isakmp)# hash {md5 | sha}

Router(config-isakmp)# group {2 | 5}

Router(config-isakmp)# lifetime #_of_seconds

One important item to point out about this configuration is the last command: lifetime. Many software EVCs do not specify the lifetime, which means that the lifetime of the EVS is used. You can control this value with the lifetime command. Also remember that at least one policy on the EVC must match one policy on the EVS.

You can use three additional IKE Phase 1 commands for remote-access connections:

Router(config)# crypto isakmp keepalive #_of_seconds #_of_retries_seconds

Router(config)# crypto isakmp xauth timeout #_of_seconds

Router(config)# crypto isakmp nat keepalive #_of_seconds

The crypto isakmp keepalive command, new in IOS 12.2(8)T, implements DPD and specifies two parameters: the number of seconds and the length of the retry period. The number of seconds can range from 10 to 3600 and specifies how often DPD messages are sent to the EVC. If the queried EVC does not reply to the EVS's DPD query, the EVS waits for the time period specified by the #_of_retries_seconds parameter. For example, if the two values are 60 and 10, respectively, the EVS sends DPD messages every 60 seconds. When a reply is missed for one of the messages, the EVS router tries sending the message again in 10 seconds.

The crypto isakmp xauth timeout command specifies the length of time that the client user has to enter a username and password during XAUTH authentication. This value can range from 5 to 90 seconds, with the default at 60 seconds.

The crypto isakmp nat keepalive command specifies the polling period if NAT-T is being used by the peers. Note that you do not need to enable NAT-T; if your IOS is 12.2(13)T or later, the NAT-T feature is enabled by default. In this instance, the two peers test the connection between themselves to detect whether any address translation is occurring between them: If this is true, the two peers automatically use NAT-T; otherwise, normal IPSec data connections are built between the two peers. Your only option with NAT-T is to specify the number of seconds that keepalives should be generated, to ensure that the address translation entry on the address-translation device stays active. The value can range from 5 to 3600 seconds. By default, NAT keepalives are not sent between the two peers. Use the show crypto ipsec sa command to verify whether your IPSec data connections are using NAT-T. If they are using NAT-T, the tunnel mode for the SA will be UDP-encaps.

Task 4: Dynamic Crypto Maps

You must complete two tasks to establish the unidirectional data connections in IKE Phase 2: create a dynamic crypto map and reference the dynamic crypto map in a static map configuration. Static crypto maps are used with L2L connections, in which you know the remote peer's identity and capabilities. However, static crypto maps do not work well when some of the connection parameters are unknown and will not be known until the remote device connects to the router.

Overview of Dynamic Crypto Maps

Dynamic crypto maps are used for remote-access connections when you typically do not know the peer's identity or capabilities until connection time. For example, you typically do not know a remote-access client's IP address if the client is connecting through a dialup, cable modem, or DSL connection from an ISP. Dynamic crypto maps should be used to accept inbound connections from remote-access clients; they cannot initiate outbound connections as a static crypto map entry can. Plus, they require the use of dynamic ISAKMP/IKE to perform the negotiation of parameters.

Actually, a dynamic crypto map is like an embedded crypto map. As mentioned earlier, with your remote-access VPN connection, you use two maps: a static and a dynamic one. The dynamic crypto map specifies the parameters to use to protect the client's remote access connection. Only one crypto map can be applied to a router's interface, and you might need to have both remote-access and L2L connections. Cisco gets around this problem by referencing the dynamic crypto map within a static crypto map by creating a separate entry in the static crypto map for the dynamic map (thus the reference to "embedded").

The "dynamic" in dynamic crypto map implies that when the remote-access client initiates the connection to the server, the server dynamically learns the connection parameters to use for the connection?thus the term dynamic. Because you typically do not know a lot of the connection information for the EVC, you must make sure that this static map reference is assigned the lowest priority (highest crypto map entry or sequence number). In other words, you want to use the dynamic entry as only a last resort: Use the static entries for L2L connections and then the last entry or entries for remote-access connections.

Creating a Dynamic Crypto Map

To create a dynamic crypto map, use the following command:

Router(config)# crypto dynamic-map dynamic_crypto_map_name sequence_#

Router(config-crypto-map)#

The dynamic crypto map must be given a unique name among all dynamic crypto maps on the router. As with static crypto maps, you can have multiple entries within a dynamic map. Each entry needs a unique sequence number. These sequence numbers are processed from lowest to highest numbers. Therefore, make sure that when you configure your security parameters for the map entries, you put the most secure parameters in the lowest-numbered entry.

Most of the commands that you can configure for a static map entry are also available for a dynamic map entry, including those listed in Table 20-1. Based on the information listed in this table, in most cases, the only command that you configure in a dynamic crypto map entry is the set transform-set command. Remember that this command specifies the transform(s) to use to protect the data connection, such as ESP in tunnel mode using 3DES encryption and MD5 for packet authentication. The EVS figures out all other parameters that are not listed in the dynamic crypto map when the client connects to it.

Table 20-1. Dynamic Crypto Map Commands

Command	Use	Other Information
set transform-set	Required	This specifies the transform set to use for the remote-access clients. It is the only required parameter.
match-address	Optional	This command specifies the ACL to use to define what traffic is to be protected. Because the client address or addresses are not know until connection time, this command is used rarely. If you use this command, your ACL can have only one permit entry. If the ACL has more than one of these entries, the first one is processed and the rest are ignored.
set peer	Optional	This command specifies the identity of the peer. Because this typically is unknown until connection time with a remote-access connection, it is used rarely.
set pfs	Optional (not supported for EVCs)	This command specifies the use of DH to share new keying information for rebuilding expiring data connections. Cisco does not support this with its EVCs.
set security-association lifetime	Optional	This command specifies the lifetime of the data SA, in seconds or kilobytes. This command also is supported in Global Configuration mode.
reverse-route [remote-peer]	Optional	This command adds a static route for the internal address of the remote-access client. Using the remote-peer option adds both the client's public address and the internal address as static routes to the router's routing table.

To create a transform set, use the following command:

Router(config)# crypto ipsec transform-set name_of_transform_set

  transform_#1 [transform_#2 [transform_#3]]

Refer to Table 19-1 in Chapter 19 for the details of the parameters for this command.

Most parameters are not known for remote-access clients (except how you will protect them with a transform), so your configuration will look like this:

Router(config)#  crypto dynamic-map map_name sequence_#

Router(config-crypto-map)#  set transform-set transform_set_name(s)

Router(config-crypto-map)#  reverse-route

In reality, the reverse-route command is necessary only if you have two or more EVS routers at the central site handling remote-access connections; otherwise, you can omit this command.

Using a Dynamic Crypto Map

After building your dynamic crypto map, you need to reference it in a static crypto map entry by using the following command:

Router(config)# crypto map static_crypto_map_name sequence_# ipsec-isakmp

  dynamic dynamic_crypto_map_name

As you can see from this command, this is basically the same as a static crypto map entry; the only difference is the dynamic parameter at the end, along with the name of the dynamic crypto map.

Verifying a Dynamic Crypto Map

After you have created your dynamic crypto map, you can view it with the following command:

Router# show crypto dynamic-map [tag dynamic_crypto_map_name]

Optionally, you can list the name of the dynamic crypto map to limit your output with the tag parameter. Example 20-1 displays sample output from this command.

Example 20-1. Using the show crypto dynamic-map Command

Router# show crypto dynamic-map

Crypto Map Template "EASYVPN" 900

        No matching address list set.

        Current peer: 0.0.0.0

        Security association lifetime: 

                        4608000 kilobytes/3600 seconds

        PFS (Y/N): N

        Transform sets={ transdynamic-1, transdynamic-2, }

As you can see in Example 20-1, only two transforms were defined for the dynamic crypto map called EASYVPN: transdynamic-1 and transdynamic-2.

Task 5: Static Crypto Map

The last step in your configuration is to configure your static crypto map. Here are the commands you use:

Router(config)# crypto map static_map_name client authentication 

  list authen_list_name

Router(config)# crypto map static_map_name isakmp authorization 

  list author_list_name

Router(config)# crypto map static_map_name client configuration

  address initiate|respond

Router(config)# crypto map static_map_name sequence_#

  ipsec-isakmp dynamic dynamic_map_name

Router(config)# interface type [slot_#/]port_#

Router(config-if)# crypto map static_map_name

The first command in this configuration, crypto map client authentication, references the use of the aaa authentication login command discussed earlier for XAUTH authentication: It specifies how authentication is to be done for remote-access clients. The authen_list_name here must match the authen_list_name in the aaa authentication login command.

The crypto map isakmp authorization command references the aaa authorization network command, specifying that authorization should be done for remote-access VPN connections. The author_list_name in both these commands must match.

The crypto map client configuration address command allows the router to assign information to the remote-access client. If you specify the initiate parameter, the router can assign addressing and policy information to the client without the client's prompting. The respond parameter has the router wait for the client's prompt for this information and then has the router respond with the policy information. If you are not sure whether the client will prompt for policy information, configure this command twice: once with the initiate parameter and once with the respond parameter.

I already discussed how to associate the dynamic crypto map in a static map entry in the last section with the crypto map ipsec-isakmp dynamic command. Remember to place the dynamic crypto map reference as the highest sequence number so that L2L crypto map entries have a higher priority. Finally, you must activate the static crypto map on the router's public interface or interfaces with the crypto map command.

Task 6: Remote-Access Verification

The same show and debug commands discussed in the previous chapter for verifying and troubleshooting IPSec L2L connections apply to remote-access connections. However, you can use one additional command for verification and troubleshooting:

Router# show crypto session {group | summary}

The group parameter has the IOS display the remote-access groups that are currently active on the router (there is a current connection to a user in a group). Example 20-2 shows sample output from the show crypto session group command.

Example 20-2. Using the show crypto session group Command

Router# show crypto session group

 Group:    Connections

 quizware: 2

In this example, there are two current user connections in the group called quizware.

The summary parameter shows the users that are connected for each of the groups defined on the EVS, which is new in IOS 12.3(4)T. Example 20-3 shows sample output from the show crypto session summary command.

Example 20-3. Using the show crypto session summary Command

Router# show crypto session summary

 Group quizware has 2 connections

  User (Logins)

  richard (1)

  natalie (1)

In Example 20-3, there are two connections in the group called quizware: one for the user richard and one for the user natalie.

Copyright eTutorials.org 2008-2023. All rights reserved.