Chapter 17: IPSec Remote Access Server (Part 2)

IPSec Remote Access Server Example

To help illustrate how to configure an appliance as an Easy VPN server, I’ll use the network shown in Figure 17-2. One tunnel group will be set up with local authentication. A local address pool is used for the internal addresses of the group, with addresses ranging from 10.0.1.224 to 10.0.1.254. I’ll break up the configuration into separate parts to make it easier to read and explain.

Figure 17-2: Easy VPN server example

Here’s the first part of the Easy VPN server configuration:

ciscoasa(config)# sysopt connection permit-vpn
ciscoasa(config)# crypto isakmp enable outside
ciscoasa(config)# crypto isakmp nat-traversal 30
ciscoasa(config)# crypto isakmp policy 10
ciscoasa(config-isakmp-policy)# authentication pre-share
ciscoasa(config-isakmp-policy)# encryption 3des
ciscoasa(config-isakmp-policy)# group 2
ciscoasa(config-isakmp-policy)# hash sha
ciscoasa(config-isakmp-policy)# lifetime 3600

The ACL bypass feature is enabled with the sysopt command. I’ve enabled ISAKMP on the outside interface of the appliance. NAT-T is enabled with the crypto isakmp nat-traversal command, using a keepalive interval of 30 seconds on the data connections. ISAKMP/IKE policy 10 defines how the management connection is protected, where pre-shared keys will be used for authentication.

Here’s the group policy configuration for the Easy VPN server:

ciscoasa(config)# group-policy eng_policy internal
ciscoasa(config)# group-policy eng_policy attributes
ciscoasa(config-group-policy)# default-domain value cisco.com
ciscoasa(config-group-policy)# dns-server value 10.0.1.10
ciscoasa(config-group-policy)# vpn-idle-timeout 15
ciscoasa(config-group-policy)# exit

The policy is called eng_policy and has a domain name and DNS server assigned with an idle timeout of 15 minutes for user inactivity.

Here’s the tunnel group configuration for the Easy VPN server:

ciscoasa(config)# ip local pool eng_pool 10.0.1.224-10.0.1.254
                      mask 255.255.255.0
ciscoasa(config)# access-list ACLnonat permit ip 10.0.0.0 255.0.0.0
                      10.0.1.224 255.255.255.224
ciscoasa(config)# nat (inside) 0 access-list ACLnonat
ciscoasa(config)# tunnel-group engineers type ipsec-ra
ciscoasa(config)# tunnel-group engineers type general-attributes
ciscoasa(config-tunnel-general)# authentication-server-group LOCAL
ciscoasa(config-tunnel-general)# default-group-policy eng_policy
ciscoasa(config-tunnel-general)# address-pool eng_pool
ciscoasa(config)# tunnel-group engineers ipsec-attributes
ciscoasa(config-tunnel-ipsec)# pre-shared-key thisISaSECRET
ciscoasa(config-tunnel-ipsec)# isakmp keepalive threshold 30 retry 5
ciscoasa(config-tunnel-ipsec)# exit
ciscoasa(config)# username richard password mysecret privilege 0

I’ve created a local address pool and exempted it from address translation. The tunnel group, “engineers,” is a remote access tunnel group. The general attributes specify that authentication is done locally (the user account is defined at the bottom of the list), the policy to use (“eng_policy”), and the addresses to use for the remote internal addresses (“eng_pool”). The IPSec attributes for the tunnel group define the pre-shared key to use for authentication and enable DPD with a keepalive interval of 30 seconds.

The following is the Phase 2 configuration for the Easy VPN server:

ciscoasa(config)# crypto ipsec transform-set eng_trans
                      esp-3des esp-md5-hmac
ciscoasa(config)# crypto dynamic-map dyn_map 1 set
                      transform-set eng_trans
ciscoasa(config)# crypto dynamic-map dyn_map 1 set reverse-route
ciscoasa(config)# crypto map stat_map 10000 ipsec-isakmp
                      dynamic dyn_map
ciscoasa(config)# crypto map stat_map interface outside

A transform set has been created, called eng_trans, and it’s referenced in a dynamic crypto map (“dyn_map”) entry, along with RRI. The dynamic crypto map is then embedded in a static crypto map (“stat_map”), and the static map is activated on the appliance outside interface.

Note

Based on the number of commands and the chance of missing something in the configuration, most administrators prefer using ASDM to at least initially set up an Easy VPN server on the appliance, and then use the CLI to change and manage it.

VPN Load Balancing

Load balancing is a Cisco-proprietary feature that allows a cluster of Easy VPN servers to logically appear as one server to all the remotes. Load balancing is done on a connection- by-connection basis, not on a traffic or packet-by-packet basis. In other words, as remotes request VPN connections, these connections are spread across multiple members of the cluster, where each cluster member is solely responsible for the connections assigned it. So load balancing in this sense is not a true form of load balancing, but does split the remote access client connections across multiple cluster members.

Not all remote access protocols, servers, and clients are supported, however. For remote access protocols, IPSec and WebVPN are supported; PPTP and L2TP are not. And within IPSec, only Easy VPN connections are supported: site-to-site connections are not. For server products, the ASA 5510s and higher, as well as the 3000 concentrators, support load balancing; IOS routers and the PIX appliances do not. The Cisco VPN software client for IPSec and the AnyConnect Client v2.0 and higher for WebVPN are supported, as well as the VPN 3002, PIX 501 and 506E, and the ASA 5505 hardware clients.

Clustering Overview

There are four components to load balancing VPN connections:

• Cluster

• Master

• Client or remote

• Load calculation

A cluster is a group of ASA security appliances and/or 3000 VPN concentrators. The cluster is identified by a single virtual IP address, shown in Figure 17-3. When clients make a connection to the cluster, they connect to the virtual IP address, which would be 192.1.1.4 in Figure 17-3. The virtual IP address must be an unused address in the subnet the external interfaces of the cluster members are connected to. One cluster member is elected as the master of the cluster, and it will handle the inbound remote access IPSec and WebVPN AnyConnect connection requests.

Figure 17-3: Load balancing

For ISAKMP Phase 1 connections, the client makes the initial connection to the virtual IP address, and the master will process the initial connection attempt. The master will look at the load of each cluster member and choose the one that has the least load. Load is calculated by taking the number of active VPN sessions on a member and dividing it by the total that the member supports. Given this formula, load is not a true calculation of load, like the amount of traffic or CPU utilization of a member. However, given this formula, members that support more connections will end up with more connections, and members that support fewer connections will end up with fewer connections, so the connections are distributed based on the capabilities of the members.

Note

To elect a master and to share load information, the cluster members need to communicate with each other. Cisco uses a proprietary protocol called the Virtual Cluster Agent (VCA) that uses UDP and connects to port 9023 by default. This protocol is also used as a keepalive mechanism to discover new and dead members.

The master will then redirect the connecting client to the physical IP address of the cluster member with the least load. Physical addresses are IP addresses assigned to the cluster members on their external interfaces; in Figure 17-3, the physical addresses are 192.1.1.1, 192.1.1.2, or 192.1.1.3. Note that during the redirection process, if the master has the least load, the redirection will take place to the master’s physical IP address. Because the redirection process in Phase 1 is proprietary to Cisco, only Cisco clients will understand it.

Tip

For unsupported clients like Microsoft L2TP/IPSec or IPSec L2L peers, point them to a physical IP address of one of the members—not the virtual address of the cluster. By using this approach, you can take advantage of the features of clustering for Cisco IPSec remote access and AnyConnect clients while still being able to support other devices.

One of the main advantages of clustering is load balancing, as I previously mentioned; however, clustering does have other advantages. Since the cluster is represented by a single IP address, the clients only need to know the virtual address to establish a tunnel to the corporate site. And assuming that you are using DPD, which allows clients to discover dead servers, a client can reconnect to the master and redirect the client to an active cluster member with the least load.

Clustering Configuration

Configuring load balancing is straightforward. Here are the commands to configure load balancing:

ciscoasa(config)# vpn load-balancing
ciscoasa(config-load-balancing)# interface lbpublic logical_if_name
ciscoasa(config-load-balancing)# interface lbprivate logical_if_name
ciscoasa(config-load-balancing)# cluster ip address virtual_IP_address
ciscoasa(config-load-balancing)# priority number
ciscoasa(config-load-balancing)# nat IP_address
ciscoasa(config-load-balancing)# cluster port port_number
ciscoasa(config-load-balancing)# cluster encryption
ciscoasa(config-load-balancing)# cluster key shared_secret_key
ciscoasa(config-load-balancing)# participate

The vpn load-balancing command takes you into a subcommand mode to set up clustering. The interface lbpublic command specifies the logical name of the external interface, and the interface lbprivate command specifies the internal interface (required). These two interfaces will generate VCA messages periodically as a discovery and keepalive mechanism. The cluster ip address command specifies the virtual IP address of the cluster (required). The virtual IP address must be an unused IP address in the subnet of the lbpublic interface.

The priority affects who becomes the master. The priority can range from 1 to 10. The member with the highest priority becomes the master. If no priority is configured, it defaults to 1 on the ASAs. This is untrue on the VPN 3000 concentrators: the lower-end models have a smaller priority, and the higher-end models have a higher priority. Because of how the VPN 3000 concentrators calculate load, they calculate it incorrectly for ASAs running 7.1 and higher. Therefore, it is recommended to have an ASA as the master in this situation.

If the addresses on the public interfaces of the cluster members are RFC 1918 addresses, including the virtual IP address, you’ll need to set up static translations on a layer 3 device in front of the cluster members for each of the physical IP addresses as well as the virtual IP address. Whatever public address is used as the virtual IP address in this situation, it must be denoted as a translated address with the nat command.

If you don’t change the port number for VCA communications, it defaults to UDP 9023. This can be changed with the cluster port command. However, if you change the port number on one member, you must make the same change on every member of the cluster.

Tip

If you want to set up two clusters in the same subnet, changing the port number in one set logically separates the two clusters. Clients then need to know a virtual IP address in either of the clusters to connect, and then load balancing will occur within the connected cluster.

Optionally you can encrypt the VCA messages by configuring an encryption key. This is done with the cluster key command. Encryption is disabled by default. If you enable encryption, the key you use must be the same on each cluster member.

The last command just listed, participate, enables load balancing on the ASA. Once enabled, it will generate VCA messages on the lpublic and lprivate interfaces to discover other cluster members and to participate in load balancing.

Clustering Example

I’ll use the network shown previously in Figure 17-3 to illustrate how cluster is configured. In the following example, I’m setting up the master, which is ASA1:

ciscoasa(config)# vpn load-balancing
ciscoasa(config-load-balancing)# interface lbpublic outside
ciscoasa(config-load-balancing)# interface lbprivate inside
ciscoasa(config-load-balancing)# cluster ip address 192.1.1.4
ciscoasa(config-load-balancing)# priority 10
ciscoasa(config-load-balancing)# cluster encryption
ciscoasa(config-load-balancing)# cluster key VCAsecretKEY
ciscoasa(config-load-balancing)# participate

For other cluster members, probably the only difference in their configuration will be the priority that you configure, which should be smaller than the master priority.