IPsec RAVPN Concentrator HA Using the VCA Protocol

VCA has become a very popular means by which to provide Local HA in VPN concentrator cluster designs. In a design that uses VCA, the VPN concentrators participating in the cluster are known as VCAs. The VCAs each communicate their status to one another using the VCA protocol. VCA architecture is proprietary to Cisco Systems IPsec VPN concentrators. Additionally, VCA is not supported in Cisco IOS, and is supported only in VPN3000 series concentrators and the ASA5500 series Adaptive Security Appliances. The example in this section uses ASA5500s to illustrate the load-balancing and HA concepts provided by VCA. Example 9-2 provides the IPsec RAVPN user, group, IPsec, and ISAKMP configurations that will support the VCA configurations illustrated in Figure 9-17, Figure 9-18, and Figure 9-19 later in this section.

Figure 9-17. VCA Cluster Master Concentrator Election

Figure 9-18. VCA Cluster IPsec Session Load Balancing

Figure 9-19. RAVPN DNS-Based IPsec Session Load Balancing

The ASA5540 VPN Appliance configuration in Example 9-2 requires security level interface configurations in the same manner that one would configure a PIX firewall. From the ASA5540 VPN concentrators perspective, configuring security level 0 on Ethernet0/0 makes Ethernet0/0 the VPN concentrator public interface. Defining security level 100 on Ethernet0/1 makes it the VPN concentrator's private interface.

In a manner similar to the IOS configuration previously discussed in Example 9-1, a dynamic crypto map, "chap9-3-dyn," is configured on all ASA5500s to accommodate change in VPN client IP addresses as they move from one location to another (line 27). RRI will inject a route for the host in to the corporate network after the SADB is populated with a Phase 2 SA for that IPsec VPN client (line 28). The dynamic crypto map is referenced in the static crypto map "chap9-3-stat" so that it can be bound to one or more physical interfaces on ASA5540-A.

ISAKMP configuration ASA5540 is configured in two parts. First, a standard ISAKMP policy is configured, including authentication method, encryption cipher, hash, SA lifetime, and Diffie-Hellman Group Modulus. This part of ASA5540's ISAKMP configuration is provided in Example 9-2, lines 31-36. Second, a tunnel group is configured to configure various extensions to IKE, including IKE x-Auth and IKE Mode Config. The tunnel-group configuration for ASA5540 is included in Example 9-2, lines 39-45. The tunnel group configuration for ASA5540-A in Example 9-2 enables the following capabilities:

• Tunnel-Group Type Definition (Line 39): The Tunnel Group is defined as a Remote Access Tunnel group, enabling parameters for RAVPN within the tunnel group configuration options.

• IKE Mode ConfigAddress Assignment (Line 41): Allocates IP addresses from the range specified in the pool "chap9-3-pool" when assigning VPN clients their IP addresses.

• IKE X-AuthAuthentication (Line 42): Specifies the AAA Server Group "chap9-3-xauth" (which in turn uses a RADIUS server, "10.1.1.101," and a key of "cisco123") for use when authenticating VPN clients with RADIUS.

• IKE X-AuthAuthorization (Line 43): Specifies the AAA Server Group "chap9-3-xauth" (which in turn uses a RADIUS server, "10.1.1.101," and a key of "cisco123") for use when authorizing VPN clients with RADIUS.

• IKE Pre-Shared Group Key (Line 45): A group key is required to complete IKE Phase 1 Authentication before IKE x-Auth can occur during Phase 1.5 negotiation.

Warning

Normally, wildcard or preshared group keys are not recommended as a best practice unless they are supplemented with a more granular form of authentication such as IKE x-Auth. This is because of the group member eviction difficulties they present. When group keys are used with IKE x-Auth, this risk is mitigated because of the required authentication of individual user credentials in conjunction with the validation of the group key. Caution should be taken when wildcard or group preshared keys are used without a more granular supplemental form of IKE authentication such as IKE X-Auth.

Example 9-2. ASA5540A Basic IPsec RAVPN Configuration (Figure 9-17, Figure 9-18, and Figure 9-19)

1  ASA5550-A# show run 2  : Saved 3  : 4  ASA Version 7.0(2) 5  names 6  ! 7  interface Ethernet0/0 8   nameif outside 9   security-level 0 10  ip address 10.1.1.1 255.255.255.0 11 ! 12 interface Ethernet0/1 13  nameif inside 14  security-level 100 15  ip address 10.0.0.1 255.255.255.0 16 ! 17 ! 18 aaa-server chap9-3-xauth protocol radius 19 aaa-server chap9-3-xauth host 10.0.0.101 20  key cisco123 21 ! 22 ! 23 ip local pool chap9-3-pool 192.168.1.1-192.168.1.100 24 ! 25 ! 26 crypto IPsec transform-set chap9-3 esp-3des esp-md5-hmac 27 crypto dynamic-map chap9-3-dyn 10 set transform-set chap9-3 28 crypto dynamic-map chap9-3-dyn 10 set reverse-route 29 crypto map chap9-3-stat 10 IPsec-isakmp dynamic chap9-3-dyn 30 crypto map chap9-3-stat interface outside 31 isakmp enable outside 32 isakmp policy 10 authentication pre-share 33 isakmp policy 10 encryption 3des 34 isakmp policy 10 hash sha 35 isakmp policy 10 group 2 36 isakmp policy 10 lifetime 86400 37 ! 38 ! 39 tunnel-group chap9-3-group type IPsec-ra 40 tunnel-group chap9-3-group general-attributes 41  address-pool chap9-3-pool 42  authentication-server-group (outside) chap9-3-xauth 43  authorization-server-group chap9-3-xauth 44 tunnel-group chap9-3-group IPsec-attributes 45  pre-shared-key * 46 Cryptochecksum:4b678d738ff3aa2976e916cca5687442 47 : end

Note

The configurations for ASA5540-B and ASA5540-C use the same base RAVPN IPsec configuration. The only difference is the change in IP addresses on the Inside and Outside interfaces:

ASA5540-B, Outside = 10.1.1.2/24

ASA5540-B, Inside = 10.0.0.2/24

ASA5540-C, Outside = 10.1.1.3/24

ASA5540-C, Inside = 10.0.0.4/24

Unlike single-group VRRP or HSRP-based IPsec RAVPN HA designs, all VPN concentrators in a VCA-enabled cluster forward traffic in a load-balanced fashion. VCA achieves this by directing incoming sessions to the least-loaded concentrator in the VCA cluster. Like HSRP and VRRP-based RAVPN HA designs, VCA employs the use of configurable priority levels to elect a "master" VCA in the cluster (the other concentrators in the cluster are referred to as "secondary" concentrators). The master VCA is responsible for polling the secondary concentrators for their current load attributable to inbound IPsec VPN client session processing. Unlike HSRP and VRRP, there is no concept of preemption, meaning that, when a VCA rejoins concentrator cluster, it will join as a secondary concentrator. With VCA, election of the master concentrator occurs only when the current master concentrator fails. Figure 9-17 illustrates a VCA-enabled concentrator cluster design that we will use to illustrate the designation of a master concentrator in the VCA cluster.

The following ordered sequence of events corresponding to the network topology in Figure 9-17 describes the VCA master election process when all three VPN concentrators are brought online together, and the election process that occurs when the VCA master (ASA5540-A) goes offline and then returns:

1.	The concentrators are powered up in following order ASA5540-A (Priority 1) first, followed by ASA5540-B (Priority 5), then ASA5540-C (Priority 10). This is shown in steps 1a, 1b, and 1c, respectively. Even though ASA5540-A has the lowest priority in the VCA cluster, it becomes the master concentrator, as it was the first concentrator to join the cluster.
2.	When ASA5540-B and C are brought online after ASA5540-A, they send User Datagram Protocol (UDP) messages on 9023 (default) to ASA5540-A with their session load information, defined as the percentage of consumed IPsec sessions on the concentrator (active sessions/max sessions). ASA5540-A uses this information to load balance IPsec sessions from VPN clients across the three active concentrators in the cluster (ASA5540-B and C). ASA5540-B and C join as secondary controllers regardless of their priority.
3.	A link failure occurs, causing ASA5540-A's public interface to become unavailable.
4.	ASA5540-B and C to elect a new VCA master. ASA5540-C becomes the master controller, as it has the highest configured priority.
5.	ASA5540-B sends keepalives to ASA5540-C with its session load information. ASA5540-C uses this information to appropriately load balance inbound IPsec sessions from the VPN clients between itself and ASA5540-B (ASA5540-A is currently offline).
6.	ASA5540-A recovers from link failure in step 3, and joins as a secondary controller in the VCA cluster. ASA5540-A sends a keepalive message to ASA5540-C, the current master, with its current session load information. ASA5540-C uses this information to load balance inbound IPsec sessions from the VPN clients across all three active concentrator clusters (ASA5540-A, B, and C).

Note

VCA priorities are defined as part of the VCA IPsec session load-balancing configuration on the ASA5500. Example 9-3 provides a sample of this configuration later in this chapter.

Although the VCA protocol does not always elect the concentrator with the highest priority value as the master concentrator (as is the case with HSRP/VRRP with preemption enabled), it is still good practice in platform diverse VCA concentrator clusters to assign higher priority values to platforms with higher session capacity. In situations where VCA priorities are identical, the VCA secondary with the lowest IP address will assume the role of master VCA concentrator during an election. Table 9-1 provides a list of VPN3000 default VCA priority values.

Table 9-1. VPN3000 Default VCA Priority Values

VCA Concentrator Platform	Default VCA Priority Values
VPN3005	1
VPN3015	3
VPN3030	5
VPN3060	7
VPN3080	9

Tip

In scenarios in which all IPsec VPN concentrator platforms in the VCA-enabled RAVPN design are identical, setting all of the VCA priority values to the highest setting (10), can potentially speed reconvergence by decreasing the time it takes to complete the VCA election process.

Once a master concentrator exists in the cluster, secondary concentrators can join the VCA cluster and immediately participate in the VCA IPsec session load-balancing operation. The secondary concentrators use the VCA protocol, sending messages over a configurable UDP port number to the VCA master concentrator declaring their session load to the master concentrator. When a VPN client initiates a new IPsec VPN tunnel to the concentrator cluster, the VCA master concentrator redirects the IPsec session to the concentrator with the lowest IPsec session load. The session load is defined as the currently number of active IPsec sessions managed by the concentrator divided by the maximum number of sessions supported by the concentrator.

Tip

Although each VCA-enabled concentrator has a default value for the number of supported sessions, this value is a configurable VCA option.

VPN clients use the VCA Virtual IP address for the concentrator cluster (shared by all concentrators in the cluster). When a client attempts to build an IPsec VPN tunnel to the concentrator cluster using the VCA Virtual IP address, the VCA master concentrator returns the physical public IP address of the concentrator in the cluster with the lowest session load. The IPsec VPN client subsequently initiates an IPsec VPN tunnel with that concentrator determined to have the lowest session load in the VCA cluster. The result is that each IPsec VPN client is assured that it is building an IPsec VPN tunnel with the IPsec VPN concentrator with the greatest amount of available processing resources relative to any of the other VPN concentrators in the VCA cluster at any given point in time. Figure 9-18 illustrates the load-balancing operation of VCA clustering in a dual-DMZ firewall design with three clustered ASA5540s used for IPsec VPN tunnel termination from RAVPN clients.

Once a VCA master concentrator has been elected and secondary VCA concentrators have been identified in the cluster, the VCA master concentrator can begin to distribute the load of IPsec VPN sessions inbound from various VPN clients to the secondary VCA concentrators in the cluster. The following ordered sequence of events corresponding to those events illustrated in Figure 9-18 describes the process of distributing IPsec VPN sessions inbound from VPN clients across the different IPsec VPN concentrators participating in a cluster using the VCA protocol:

1.	The concentrators are all configured in the same cluster. ASA5540-A is currently the VCA master concentrator for the cluster. ASA5540-B and ASA5540-C send keepalive messages to ASA5540-A with their session load information, indicating that they currently are managing 51 and 50 IPsec sessions, respectively. ASA5540-A stores this information to execute future load-balancing decisions.
2.	Client-A initiates an IPsec VPN tunnel to the Concentrator Cluster using the VCA Virtual IP of 200.1.1.100. Initially, this session is destined for ASA5540-A, the master concentrator in the cluster.
3.	ASA5540 redirects the session to ASA5540-C (200.1.1.103), as it has the lowest session load level (50 sessions) relative to its IPsec session capacity.
4.	Client-B initiates an IPsec VPN tunnel to the Concentrator Cluster using the VCA Virtual IP of 200.1.1.100. Initially, this session is destined for ASA5540-A, the master concentrator in the cluster.
5.	ASA5540 redirects the session to ASA5540-B (200.1.1.102) even though ASA5540-A and B's loads are identical. This is because the VCA master will redirect client sessions to its secondary concentrators until it has the lowest load in the cluster. The rationale behind this is that the VCA master is burdened by the overhead of session redirection and should therefore redirect sessions to secondary concentrators with equal session loads (equaling an overall lesser load due to the absence of VCA session administration overhead on the secondary controller).
6.	Client-C initiates an IPsec VPN tunnel to the Concentrator Cluster using the VCA Virtual IP of 200.1.1.100. Initially, this session is destined for ASA5540-A, the master concentrator in the cluster.
7.	ASA5540 does not redirect the session, but instead returns its own physical IP address (200.1.1.101) to the VPN client for IPsec peer, as ASA5540-A has the lowest number of managed sessions (ASA5540-A has 50 sessions, and ASA5540-B and C both now have 51 sessions after accepting sessions from Client A and B in steps 3 and 4, respectively).

Example 9-3 provides the necessary configuration required for an ASA5500 to participate in a VCA cluster. The following configuration specifies a priority of 9, making ASA5540 the most likely concentrator in the cluster to become the VCA master concentrator. In addition to the VCA priority, all of the participating concentrators in the VCA cluster must be configured with an identical VCA cluster IP address. In this case, ASA5540-A is configured to participate in the VCA cluster with the VCA cluster IP address of 200.1.1.100. It is instructed to encrypt exchanges between concentrators in the cluster with a key of "cisco123."

Example 9-3. ASA5540A VCA Load-Balancing Configuration

ASA5540-A(config)# Vpn load-balancing ASA5540-A(config-load-balancing)# priority 9? ASA5540-A(config-load-balancing)# cluster key cisco123 ASA5540-A(config-load-balancing)# cluster ip address 200.1.1.100 ASA5540-A(config-load-balancing)# cluster encryption? ASA5540-A(config-load-balancing)# participate

Note

The load-balancing configurations on ASA5540-B and C are identical to ASA5540-A in every way except for the priority definition (ASA5540-B = 5, ASA5540-C = 3). The cluster key and IP address must be identical across all VPN concentrators in the VCA-enabled cluster. The concentrator with the highest priority has the best chance of becoming the master concentrator.

It is important to note that, in Figure 9-17, Figure 9-18, Example 9-2, and Example 9-3, identical VPN concentrator platforms were selected to more clearly illustrate the load-balancing process in a concentrator cluster using VCA. One major benefit of the VCA protocol is that it factors each platform's capacity in to its load-balancing scheme. As such, if a smaller concentrator (such as a VPN3005) capable of supporting a smaller amount of sessions were to be introduced to the VCA cluster, the master concentrator would factor the smaller capacity of the VPN3005 when redirecting IPsec VPN client sessions. This is achieved by each concentrator's definition of session load: the number of current sessions divided by the number of maximum sessions. In the case of the VPN3005 joining a cluster of ASA5540s, the VPN3005 would express its load as a percentage of the active sessions relative to its platform session capacity to the master, thereby providing the master VCA controller with a metric incorporating the platforms session capacity. As such, a VCA master controller will often continue to assign IPsec sessions to higher-capacity concentrators, such as the ASA5530 concentrators previously, even if they have a greater raw session count than lower-capacity concentrators such as the VPN3005.

Through proper implementation of VCA-enabled concentrators in an RAVPN design, IPsec VPN clients can be assured that they are terminating their IPsec tunnel on the concentrator with the highest degree of available computational resources of any concentrator in the VCA cluster. VCA therefore offers a method of load balancing that yields the most efficient use of IPsec processing resources in Cisco-based IPsec RAVPN concentrator designs of any of the designs discussed.