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 ElectionFigure 9-18. VCA Cluster IPsec Session Load BalancingFigure 9-19. RAVPN DNS-Based IPsec Session Load BalancingThe 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:
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)
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:
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:
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.
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:
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
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. |