IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

IPsec RAVPN Concentrator HA can be achieved using a virtual interface protocol such as Hot Standby Router Protocol (HSRP) or Virtual Router Redundancy Protocol (VRRP). Using HSRP or VRRP, many VPN concentrators can be made to appear as a single IPsec peer to the IPsec clients. Should a VPN concentrator in the HSRP or VRRP peer group fail, the use of a virtual interface provides resiliency to the client, enabling the client to fail its IPsec session over to another concentrator participating in the HSRP or VRRP group. In this section, we will explore several tasks to consider when selecting virtual interfaces as the RAVPN design option for RAVPN HA.

IPsec RAVPN Concentrator High Availability Using VRRP

VRRP is a standards-based protocol enabling multiple interfaces on different IP routers (or in this case, RAVPN concentrators) to appear as a single virtual router interface. RFC 3768 defines VRRP as an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN.

Tip

For more information on VRRP and its many uses, please refer to the following sources of information:

http://www.ietf.org/rfc/rfc3768.txt

http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2284/products_tech_note09186a0080094490.shtml

In RAVPN environments, this VRRP LAN is typically a network segment attached to a firewall DMZ interface on the enterprise Internet edge. Multiple VPN concentrators will be attached to the DMZ LAN, each with their own unique physical interface IP in the VRRP group. These physical interfaces will all appear to the IPsec VPN clients as a VRRP virtual router interface. As such, the clients will need only one peer definition (the VRRP router interface) to take full advantage of the redundancy provided by having multiple concentrators in the enterprise Internet edge demilitarized zone (DMZ). Figure 9-1 illustrates an enterprise RAVPN deployment in which a cluster of three VPN concentrators is deployed in a dual-DMZ firewall design at the Internet edge.

Figure 9-1. Dual-DMZ VPN Concentrator Design with VRRP-Based HA

The VPN3000 concentrator configuration for IPsec, Internet Security Association and Key Management Protocol (ISAKMP), and Group/User Management is illustrated in Figures 9-2 through 9-10.

Remote access VPN tunnels are typically authenticated with IKE X-Auth for per-user SA authentication granularity. Authentication using IKE X-Auth requires that a Phase 1 SA be temporarily authenticated pending successful authentication with Internet Key Exchange (IKE) X-Auth in "Phase 1.5." The IPsec group password is used to provide the temporary authentication of the Phase 1 SA. Configuration of the RAVPN group and password on the VPN3000 is illustrated in Figure 9-2.

Figure 9-2. VPN3000 IPsec Group and Password Configuration

Figure 9-3 illustrates the following parameters that can be assigned to a given IPsec VPN client during IKE Mode config. In Figure 9-3, a VPN3000 concentrator is instructed to assign clients a DNS server of 200.1.1.17 and an IP address from the range of 192.168.0.0 to its clients. Also note that, in this configuration, SEP cards 1-4 are actively participating in the acceleration of IPsec on the concentrator for this group.

Figure 9-3. VPN3000 General Configuration (Client SEP Card, DHCP/Address Scope, and DNS Server Assignment)

Figure 9-4 illustrates the IPsec configuration for this group, including the transform (Encapsulating Security Payload (ESP) 3DES with MD5 Hash-based Message Authentication Code (HMAC) Authentication) and the tunnel type (Remote Access).

Figure 9-4. VPN3000 Group IPsec and ISAKMP Configuration

IKE mode config can be used to assign additional parameters, such as the IP subnet mask, client banner, split tunnel policy, and NAT-T policy. Figure 9-5 illustrates the configuration of these parameters for assignment to the client via IKE mode config.

Figure 9-5. VPN3000 Client Configuration (Banner, NAT-T Policy, Subnet Mask Assignment, IPsec Split Tunnel Policy)

There are many different methods to assign a client an IP address, as illustrated in Figure 9-6. In this chapter, we will assign IPsec VPN clients an IP address from an address pool defined locally on the IPsec VPN concentrator using IKE mode config. Figure 9-6 illustrates the corresponding configuration on the VPN3000 concentrator.

Figure 9-6. Defining Address Assignment Methods on the VPN3000

Figure 9-7 illustrates the configuration of the appropriate address pool corresponding to the defined address assignment method displayed in Figure 9-6.

Figure 9-7. Assigning Client Addresses from Defined IP Address Pool on the VPN3000 Concentrator

As we had discussed previously in Figure 9-4, Phase 1 SA authentication can be done with peruser granularity when IKE x-Auth is used. Figure 9-4 provides us with the appropriate group and password configuration for IKE Phase 1 authentication, and Figure 9-8 provides us with an example of user and password credentials that will be validated with x-Auth in "Phase 1.5" negotiation. In this case, we are using the VPN3000 itself as the user database for x-Auth. However, the VPN3000 can also be configured to authenticate user credentials supplied via x-Auth using an external RADIUS database.

Figure 9-8. Creating VPN3000 Internal User Database Accounts for Authentication and Authorization with IKE X-Auth

Figure 9-9 illustrates the configuration of general RAVPN user authentication and authorization parameters for a given user account on the VPN3000. In this case, any four of the available SEP modules are available for processing the termination of this user's IPsec VPN tunnel. IPsec is the only tunneling protocol configured for this client to use on this particular VPN concentrator.

Figure 9-9. VPN3000 Configuration for General RAVPN User Authentication and Authorization Policies with IKE X-Auth

IPsec transform sets can be configured on a per-user basis. Figure 9-10 illustrates the appropriate IPsec transform configuration at the user level.

Figure 9-10. Defining Per-User Allowed IPsec Transform Polices with IKE X-Auth on VPN3000 Concentrators

The VPN3000 concentrator must be configured with the appropriate routing protocol information in order for transparent IP connectivity to be maintained from IPsec RAVPN clients to enterprise resources located within the IPsec VPN concentrator's private network. The VPN3000 can support multiple means by which to achieve this:

• Static Routing: Typically, a static default route is used to route IP traffic from the concentrator's private network through the public interface and across the IPsec VPN tunnels. More specific static routes are required to route traffic in the opposite direction, inbound from IPsec RAVPN clients to IP-enabled resources on the enterprise's private network.

• OSPF: Instead of manually inserting more specific static routes pointing out of the concentrator's private interface, these routes can be learned dynamically via Open Shortest Path First (OSPF). A popular design option is use of a static default route pointing out of the concentrator's public interface with more specific IP subnets learned dynamically through OSPF on the concentrator's private interface.

• RIP: Cisco VPN3000 concentrators support Routing Information Protocol (RIP) as well as OSPF. Instead of learning more specific routes via OSPF (or manually defining static ones), RIP can be used as an alternative routing protocol on the concentrator's public or private interfaces.

In this example, we will explore the design option of using a combination of static default routing to the public network, with more specific IP subnets learned via OSPF from the enterprise network on the VPN3000 concentrator's private interface. Samples of the required configuration can be found in Figures 9-11 through 9-14.

Figure 9-11. VPN3000 Static Default Routing

The VPN3000 in this example uses OSPF to route traffic out of its private interface to the enterprise's corporate network. Figure 9-12 provides the appropriate routing configuration on the VPN3000, including OSPF area configuration and other area-level configuration parameters.

Figure 9-12. VPN3000 OSPF Routing Configuration

Figure 9-13 provides the interface-level configuration of the VPN3000's private interface, including IP address, administrative state (up/down), speed, duplex, and maximum transmission unit (MTU).

Figure 9-13. VPN3000 Private Interface Configuration

Figure 9-14 provides the interface-level configuration of the VPN3000's public interface, including IP address, administrative state (up/down), speed, duplex, and MTU.

Figure 9-14. VPN3000 Public Interface Configuration

Note

Cisco VPN3000 concentrators and ASA5500 Series VPN appliances do not support HSRP. VRRP is the only virtual router protocol for first-hop redundancy supported by the VPN3000 series VPN concentrators. Routing platforms running Cisco IOS support HSRP-based RAVPN HA, as discussed later in this chapter.

In the RAVPN HA design of Figure 9-1, network architects have elected to use VRRP-based tunnel termination for high availability. Concentrators VPN3060-A, B, and C all have public interfaces on the outside DMZ that are configured in the same VRRP group. Initially, VPN3060-A is configured as the VRRP "Master" (it has the highest configured VRRP priority in the group). As the master, VPN3060-A is responsible for sending multicast keepalive polls to the other concentrators in the VRRP group using the link local multicast IP address of 224.0.0.18. If one or both of the other concentrators does not see a configurable amount of keepalives in their corresponding timed intervals, the remaining concentrators in the VRRP group will undergo an election to assume the role as the VRRP master router. This process allows for resiliency in the concentrator cluster design, as illustrated in the following failures scenario for VPN3060-A in Figure 9-1:

1.	VPN3060-A, B, and C are all configured for VRRP on the DMZ-Outside network segment. VPN3060-A is currently the VRRP master, assuming forwarding responsibility for RAVPN clients. A link failure on VPN3060-A's public interface causes the concentrator to become unavailable to inbound IPsec VPN sessions from the VPN clients.
2.	VPN3060-B and C are configured to wait three successive timed intervals to receive a VRRP router advertisement from the master router before attempting an election for VRRP master router. After missing a VRRP advertisement from VPN3060-A in the third timed interval, VPN3060-B and C attempt to elect a new VRRP master through the exchange of their own VRRP router advertisement messages. As VPN3060-B has the second highest priority next to VPN3060-A, it becomes the new VRRP master router.
3.	When VPN clients attempt to negotiate IPsec VPN tunnels with the Concentrator Cluster using the VRRP Virtual Router IP address, the VPN3060-B will now be responsible for terminating the inbound IPsec VPN tunnels. Note The VPN clients in this example are configured with only one IPsec peer corresponding to the VRRP Virtual Router IP address for the IPsec VPN concentrators in that VRRP group. As such, the clients are unaware of any changes that occur in the concentrator cluster due to the failure described abovethey will always use the same IP address for their IPsec peer regardless of which VPN concentrator is the master for the VRRP group.
4.	VPN3060-A is configured to preempt the other concentrators when it recovers from a failure. This means that it will proactively attempt to reassume the role of VRRP master for the VRRP group after it recovers from a failure. VPN3060-A recovers from the failure in step 1, sending out a VRRP router advertisement message causing a new reelection to occur. VPN3060 has the highest priority in the group, thereby reassuming the role of VRRP master for the VRRP group.
5.	When VPN clients attempt to negotiate IPsec VPN tunnels with the Concentrator Cluster using the VRRP Virtual Router IP address, the VPN3060-A will now be responsible for terminating the inbound IPsec VPN tunnels.

Figure 9-15 illustrates the VRRP required on all VPN concentrators in the network topology illustrated in Figure 9-1.

Figure 9-15. VPN3000 VRRP-Based IPsec RAVPN HA Configuration

It is critically important to consider that, in the above RAVPN design, there is no dynamic communication of IPsec configuration or state between the Master VRRP concentrator and its backup VRRP concentrators. As such, on Cisco ASA5500 and VPN3000 series IPsec VPN concentrators, VRRP-based HA options are considered to be stateless. In a VRRP-based RAVPN HA design, the master and backup concentrators must have identical IPsec and ISAKMP settings, so that clients are able to use any concentrator that happens to be the VRRP master at any given point in time. Inconsistencies in these configuration settings can lead to inconsistent success in IPsec VPN tunnel negotiation across the cluster, as some concentrators will be appropriately configured to successfully terminate inbound IPsec VPN tunnels from VPN clients, while others will not.

Tip

IOS IPsec features can be configured to support HSRP-based termination of IPsec VPN tunnels in a stateful manner between two IOS-based IPsec VPN concentrators (routers configured for RAVPN). Chapter 6 covers the comparison of stateless vs. stateful IPsec VPN tunnel termination in greater detail.

Additionally the network design illustrated in Figure 9-1 requires that all of the VPN clients use the same VRRP Virtual Router IP address for IPsec peering to the concentrator cluster. While this does provision for high availability in the concentrator cluster, it does not provision for session load balancing. We will discuss how IPsec session load balancing can be achieved in highly available RAVPN implementations using Virtual Clustering later in this chapter.

In this section, we've discussed how VRRP can be used for VPN Concentrator High Availability. The concepts of RAVPN HA discussed above are all stateless in nature, meaning that, when VPN clients successfully negotiate IPsec VPN tunnels with the concentrator, this state is not communicated to the backup concentrators in the cluster. As such, when a failover occurs on a VPN concentrator terminating IPsec VPN sessions for multiple IPsec VPN clients, these clients must renegotiate Phase 1 and 2 SAs with the backup IPsec VPN concentrator. In the following section, we will explore a stateful RAVPN HA design using Cisco IOS-based RAVPN concentrators that enables us to avoid the renegotiation of Phase 1 and 2 SAs with the backup VPN concentrators when a failure occurs on master VPN concentrator.

IPsec RAVPN Concentrator HA Using HSRP

HSRP operates in a similar fashion to VRRP. HSRP can therefore be used in a similar fashion to VRRP to provide IPsec Local HA. Thus far, we've discussed design options for providing stateless IPsec RAVPN HA in a VPN concentrator cluster design using VRRP. With Cisco IOS, the same design principals of a stateless RAVPN HA concentrator cluster design can be extended to incorporate stateful failover across different concentrators in a given cluster. This section discusses an IOS-based concentrator design that uses HSRP for stateful RAVPN high availability.

In RAVPN concentrator cluster designs, HSRP provides high availability in a fashion similar to VRRP by electing an "active" (equivalent to the VRRP "master" concentrator) concentrator that is responsible for the forwarding of all traffic and session termination from all clients in the HSRP group. The other concentrators in the HSRP group are "standby" (equivalent to VRRP "backup" concentrators) until they assume active responsibilities due to a change in the network. Like VRRP, the HSRP active router sends periodic status messages to other concentrators in the HSRP group using a link local multicast address (HSRP=224.0.0.2, VRRP=224.0.0.18). If one or more concentrators in the HSRP group does not receive an HSRP status message within a configurable amount of timed windows, the standby concentrators then undergo an election to determine the new active HSRP concentrator/router. Like VRRP, the HSRP concentrator with the highest priority will assume the role of "active" and responsibilities for forwarding all traffic and terminating all inbound IPsec sessions for the HSRP group.

Tip

For more information on HSRP and its many uses, please refer to the following sources of information:

http://www.ietf.org/rfc/rfc2281.txt

http://www.cisco.com/en/US/partner/tech/tk648/tk362/tk321/tsd_technology_support_sub-protocol_home.html

The solution for RAVPN HA discussed in this section is not primarily differentiated by the use of HSRP over VRRP. Instead, the key difference in this design is that it is stateful instead of stateless. Figure 9-16 presents a design with IOS-based VPN concentrators to deliver stateful failover across the different concentrators in the cluster.

Figure 9-16. Dual-DMZ IOS-Based Concentrator Design with HSRP-Based Stateful HA.

The following illustrates the HSRP-based stateful failover process for the topology depicted in Figure 9-16:

1.	VPN7301-A, B, and C are all configured for HSRP on the DMZ-Outside network segment. VPN7301-A is currently with the highest HSRP priority making it become the active concentrator and assume forwarding responsibility for RAVPN clients.
2.	As clients successfully use the HSRP Standby IP interface currently active on VPN7301-A to terminate IPsec VPN tunnels, the state for each of these tunnels is periodically communicated using SSO and SCTP to the backup routers in the HSRP group (VPN7301-B and C). Tip The stateful IPsec high availability design described here is a local IPsec HA design applied to Cisco routers running IOS and acting as a concentrator cluster in an RAVPN for IPsec VPN clients. The design leverages stateful failover concepts for site-to-site IPsec Local HA using HSRP and SSO. For more information on HSRP and SSO specifics in the context of IPsec Local HA, please refer to Chapter 6.
3.	A link failure on VPN7301-A's public interface (GigE0/0) causes the concentrator to become unavailable to inbound IPsec VPN sessions from the VPN clients.
4.	VPN7301-B and C are configured to wait three successive timed intervals to receive a HSRP router advertisement from the master router before attempting to elect a new active HSRP router. After missing a HSRP advertisement from VPN7301-A in the third timed interval, VPN7301-B and C attempt to elect a new active HSRP router through the exchange of their own HSRP router advertisement messages. As VPN7301-B has the second highest priority next to VPN7301-A, it becomes new active HSRP router.
5.	The VPN clients that had established IPsec VPN tunnels with VPN7301-A when it was the active HSRP router in the cluster seamlessly fail their session over to VPN7301-B, the newly elected active HSRP router. This seamless transition of IPsec sessions is enabled by the proactive communication of IPsec state using SSO in step 1. Unlike the stateless HA scenario described previously using VRRP on VPN3000 and ASA5500 concentrators, the VPN clients transitioning their IPsec VPN sessions from VPN7301-A to VPN7301-B in this stateful HA failover process step do not have to renegotiate Phase 1 and 2 SAs with VPN7301-B.
6.	When VPN clients attempt to negotiate IPsec VPN tunnels with the Concentrator Cluster using the HSRP Standby IP address, VPN7301-B will be responsible for terminating the inbound IPsec VPN tunnels. Note The VPN clients in this example are configured with only one IPsec peer corresponding to the HSRP Standby IP address for the IPsec VPN routers in that HSRP group. As such, the clients are unaware of any changes that occur in the concentrator cluster due to the failure described abovethey will always use the same IP address for their IPsec peer regardless of which VPN router is the actively forwarding for that HSRP group.
7.	In this stateful IPsec RAVPN HA design, VPN7301-A is not configured to preempt the other routers in the HSRP group when it recovers from a failure. This means that it will rejoin the HSRP group as a standby router until another failure occurs and another HSRP election process is executed. Tip When an IPsec device recovers and attempts to preempt other IPsec routers in the HSRP group, it will likely not have the appropriate state information to seamlessly transition the existing IPsec sessions from the existing active IPsec router. This will cause the sessions to be dropped and renegotiated with the preempting IPsec VPN router. This behavior essentially negates the use of stateful HA, reverting back to a stateless failover. In stateful HA configurations, disabling preemption enables a router to relearn IPsec session state using SSO as a standby HSRP router. As such, when another failure occurs, this router is now prepared to assume the role of the active IPsec VPN router and to seamlessly transition IPsec VPN sessions in a stateful manner.
8.	IPsec VPN clients will continue to use VPN7301-B as their IPsec RAVPN peer until a change in the network forces another HSRP election. In the meantime, VPN7301-A has recovered as a standby HSRP router in the cluster, and is receiving periodic HSRP advertisements and IPsec SSO state messages from VPN7301-B. Therefore, when a change in the network forces another HSRP election, VPN7301-A will have the appropriate IPsec SADB entries for Phase 1 and 2 SAs to the VPN clients required to seamlessly assume forwarding responsibilities for those clients as the active HSRP router without forcing the VPN clients to renegotiate Phase 1 and 2 SAs.

The design process described above effectively increases HA baselined in the VRRP-based dual-DMZ concentrator design of Figure 9-1, but provides little in the way of session load balancing across the concentrators in the cluster in active/active/active scenarios. When deploying this design, administrators face the same load-balancing challenges faced in our discussion of VRRP-based RAVPN HA concentrator cluster deployment. The stateful design described in this section can leverage the use of multiple HSRP groups to load balance across the VPN routers VPN7301-A, B, and C when all three routers in the cluster are active.

Example 9-1 illustrates the configuration of the VPN routers VPN7301-A, B, and C for RAVPN IPsec session concentration using HSRP for stateful IPsec HA. In order to support IPsec stateful HA, VPN7301-A is configured to preemptively communicate the state of the SADB using SSO to VPN7301-B and C using the redundancy scheme "chap9-stateful" as shown in lines 8 and 9 of Example 9-1. Proactive communication of the IPsec SADB state to redundant IPsec gateways is accomplished with the SSO configurations in lines 11-22. The crypto engine is then instructed to use this SSO stateful failover configuration during the application of the crypto map in line 56. In addition to these SSO-specific configuration elements required for stateful failover, VPN7301-A's configuration has several elements required for RAVPN Termination, described in the following bulleted list:

• IKE X-Auth (Lines 4-5, 41, 43, 62, and 63): IKE x-Auth required to authenticated IKE SAs based on specific user accounts with either Terminal Access Controller Access Control System+ (TACACS+) or RADIUS (RADIUS is used in this example).

• IKE Mode ConfigGroup Key Definition (Lines 32-33): Required to complete the IKE Phase 1 SA before IKE x-Auth can occur (Phase 1.5).

• IKE Mode ConfigClient Address Assignment (Line 29): During IKE, Mode Config can be used to assign a variety of parameters to a VPN client, including IP addresses, domain names, and default gateways. Line 29 instructs the IOS VPN concentrator to assign clients IP addresses with Mode Config from the defined pool "chap9-stateful-pool."

• Dynamic Crypto Map Configuration (Lines 37-39): A dynamic crypto map is required, as the IPsec VPN peers' (VPN clients) IP addresses are unknown (they will vary based on their location and assigned DHCP address).

• Static Crypto Map Configuration (Lines 41-44): The static crypto map references the dynamic crypto map. To facilitate RAVPN Concentration, the static crypto map also references the authentication, authorization, and accounting (AAA) list to be used for authenticating and authorizing VPN clients with x-Auth. The crypto map also specifies whether or not to initiate IP address assignment or respond to an address assignment request with IKE Mode config. In this case, VPN7301-A is instructed to initiate IP address assignment with IKE Mode Config.

• Interface-Level Crypto Configuration (Line 56): This configuration line binds all of the crypto information defined in the static crypto map "chap9-stateful-static" to the crypto interface, FastEthernet0/0, on VPN7301-A. Additionally, because the dynamic crypto map "chap9-stateful-dynamic" was previously referenced in the static crypto map, the elements referenced in the dynamic crypto map configuration are also bound to this crypto interface. Note that the inter-device redundancy configuration "chap9-stateful" is appended to the end of the interface crypto map configuration. This effectively binds the stateful HA SSO redundancy configuration "chap9-stateful" to the crypto process configured for FastEthernet0/0.

• Address Pool Definition (Line 59): IKE Mode Config has been previously configured to assign VPN clients from IP addresses from this pool, "chap9-stateful-pool."

• RADIUS Server Configuration (Line 62-63): These commands configure the VPN7301-A to use the RADIUS Server IP "10.0.0.101" and key "cisco123" for authenticating VPN client credentials using IKE x-Auth.

Example 9-1. VPN7301A Stateful IPsec RAVPN HA Configuration

1  VPN7301-A#show running-config 2  ! 3  ! 4  aaa authentication login ravpn-auth group radius 5  aaa authorization network ravpn-auth group radius 6  ! 7  ! 8  redundancy inter-device 9   scheme standby chap9-stateful 10 ! 11 ipc zone default 12  association 6 13   no shutdown 14   protocol sctp 15    local-port 6666 16     local-ip 10.1.1.1 17     retransmit-timeout 200 5000 18     path-retransmit 10 19     assoc-retransmit 20 20    remote-port 6666 21     remote-ip 10.1.1.2 22     remote-ip 10.1.1.3 23 ! 24 ! 25 crypto isakmp policy 10 26  authentication pre-share 27  hash md5 28  group 2 29 crypto isakmp client configuration address-pool local chap9-stateful-pool 30 31 ! 32 crypto isakmp client configuration group chap9-stateful 33  key cisco123 34 ! 35 crypto IPsec transform chap9-stateful-trans esp-3des esp-md5-hmac 36 ! 37 crypto dynamic-map chap9-stateful-dyn 10 38  set transform-set chap9-stateful-trans 39  reverse-route 40 ! 41 crypto map chap9-stateful-static client authentication list ravpn-auth 42 crypto map chap9-stateful client configuration address initiate 43 crypto map chap9-stateful-static isakmp authorization list ravpn-auth 44 crypto map chap9-stateful-static 10 IPsec-isakmp dynamic chap9-stateful-dyn 45 ! 46 ! 47 interface FastEthernet0/0 48  ip address 10.1.1.1 255.255.255.0 49  ip directed-broadcast 50  speed auto 51  half-duplex 52  standby 1 ip 10.1.1.100 53  standby 1 priority 30 54  standby 1 preempt 55  standby 1 name chap9-stateful-static 56  crypto map chap9-stateful-static redundancy chap9-stateful 57 ! 58 ! 59 ip local pool chap9-stateful-pool 192.168.1.1 192.168.1.100 60 ! 61 ! 62 radius-server host 10.1.1.101 auth-port 1645 acct-port 1646 63 radius-server key cisco123

Note

VPN7301-B and C are configured in a similar manner to VPN7301-A. They use the same radius server and key and the same HSRP standby address among other similarities. Additionally, the IPsec and ISAKMP configurations are identical between VPN7301-A, B, and C. The main differences on VPN7301-B and C are:

SSO Peering Definitions: VPN7301-B must peer with A and C, and VPN7301-C must peer with A and B.

HSRP Priority Definition: VPN7301-A and B are configured with lower HSRP priorities.

Physical IP Addressing: VPN7301-B's and C's physical IP addresses are different from VPN7301-A, following the addressing information provided in Figure 9-16.

At this point, we've explored both stateful and stateless RAVPN HA designs, illustrating how system reconvergence can be expedited through the proactive communication of SADB state from the active concentrator (active router in the HSRP group) to the backup concentrators (standby routers in the HSRP group) resulting in a seamless failover from the VPN client's perspective (no renegotiation of IKE Phase 1 or 2 SAs). However, stateful and stateless IPsec VPN designs share one common design limitationneither provide for IPsec session load balancing, as all IPsec VPN client connections are terminated on the active HSRP (or master VRRP) router or concentrator in the concentrator cluster. Cisco VPN concentrators support dynamic per-session load balancing across the different concentrators in the cluster using Virtual Cluster Agent (VCA), which we will discuss in the following section.