Best Practices

This section explores the features that you can use on the VPN 3000 series concentrator to avoid experiencing a single point of failure for both LAN-to-LAN and Remote Access Client tunnels. In today's network, resiliency with the VPN connection is very crucial. The VPN 3000 Concentrator includes three features that ensure high availability. The following sections delve into the details of these three features.

• Redundancy using VRRP

• Redundancy and load sharing using clustering

• Redundancy using IPsec backup servers

Redundancy Using VRRP

As the name implies, the Virtual Router Redundancy Protocol (VRRP) provides redundancy for VPN connection to the Concentrator. When you have two or more Concentrators sitting in parallel in your network, you can configure VRRP so that a user can access to the VPN even if one VPN Concentrator is out of service because of a system crash, power failure, hardware failure, physical interface failure, or system shutdown or reboot. In VRRP imple-mentation, Redundant VPN Concentrators are identified by group, a single Master is chosen for the group, and one or more VPN concentrators can be backups of the group's Master. The Master communicates its state to the backup devices, and if the Master fails to communicate its status, VRRP tries each backup in order of precedence. Then the responding backup assumes the role of Master.

In the case of IPsec LAN-to-LAN connections, switchover is fully automatic. This means that when the tunnel is dropped, a new tunnel is re-established automatically and this process is transparent to the LAN-to-LAN users. But, for Remote Access VPN clients, when users are disconnected from the failing system, users are notified of the disruption and can reconnect without changing any connection parameters. Typically switchover occurs within 3 to 10 seconds.

Following are some important points to remember when implementing VRRP in your VPN 3000 series Concentrators deployment:

• When the Master is restored, there is no auto switchover to back the Concentrator. This is done manually.

• The failover is not stateful, so the tunnel must be rebuilt, and the traffic must be retransmitted.

• VRRP is not a load-sharing mechanism; it's a standby mechanism and cannot be used with clustering.

• If either the public or private interfaces of the Master system go down, the other interfaces shut down automatically and the backup VPN device takes over. The backup VPN device takes over only when it stops receiving VRRP messages on both the public and private interfaces.

• Some failures might not be detected by VRRP. For example, if a Cisco Catalyst switch is between the Master and backup devices that connect to each other, and if you shut down the switch port, this does not bring down the link layer. Therefore, the VPN concentrator does not detect the interface as DOWN (this can be verified in Configuration > Interfaces screen). The VPN Concentrator therefore continues sending messages to the backup device. In this case, because the backup device is still receiving VRRP messages on at least one interface, it does not take over as the Master.

• When a Cisco switch is configured that is connected to primary and secondary concentrators, port fast must be turned on to eliminate the inherent delays with Spanning Tree Protocol (STP) that in turn cause a delay in recognizing that a backup VPN Concentrator has taken over as the Master. With port fast, this delay can be reduced to 15 seconds. For details on how to configure port fast, refer to the following link: http://www.cisco.com/warp/public/473/12.html

The following procedure shows how to configure VRRP on the Master and backup systems:

Step 1.	Go to Configuration > System > IP Routing > Redundancy.
Step 2.	Check Enable VRRP check box to turn VRRP.
Step 3.	Leave the Group ID at its default, which is 1. You can specify anything between 1 and 255.
Step 4.	Enter a Group Password (maximum of 8 characters) in the Group Password field.
Step 5.	From the drop-down list of Role, select Master or Backups based on which Concentrator you are configuring.
Step 6.	The Advertisement Interval is 1 second by default. You can specify up to 255 seconds.
Step 7.	Under Group Shared Addresses, define both the Private and Public interface IP address. The Public interface IP address will be used by the VPN Client or LAN-to-LAN peer to build up the tunnel. The Private Shared address will be used by the local LAN host of this VPN Concentrator. Figure 8-10 shows a configuration example of turning on VRRF on the Master Concentrator with private shared IP address of 10.1.1.1 and public interface shared IP address of 20.1.1.1. Figure 8-10. Redundancy Configurations
Step 8.	Click Apply and save the configuration.
Step 9.	Follow steps 1 through 8 for all the concentrators that are participating in the VRRP.

As mentioned before, VRRP is used for high availability not for load sharing. For redundancy and load sharing for VPN Client, you must use clustering, which is discussed next. It is important to note that you must not configure VRRP with Clustering. If both Load Sharing and Redundancy are required for Remote Access VPN, configure Clustering only.

Redundancy and Load Sharing Using Clustering

Clustering provides a robust redundancy mechanism by way of load sharing for a Remote Access VPN Client. If you have two or more VPN concentrators sharing the same private network, you should consider configuring clustering, which will give you both load sharing and backup features. When you have all the VPN concentrators up and load sharing is configured, load balancing directs session traffic to the least loaded device. In this way, load balancing distributes the load among all devices. It makes efficient use of system resources and provides increased performance and high availability.

Logically two or more concentrators are on the same LAN and public networks are grouped together into a virtual cluster to implement load sharing. All the concentrators in the virtual cluster carry session loads; however, one VPN concentrator in the virtual cluster acts as the virtual cluster Master that directs incoming calls to the other concentrators, called secondary devices. The virtual cluster Master monitors all devices in the cluster, tracks how busy each is, and distributes the session load accordingly.

The role of virtual cluster Master is not tied to a physical device; it can shift among devices. Selection of a virtual cluster Master is interesting. If the devices in the virtual cluster are powered up at different times, the first device powered up assumes the role of the virtual cluster Master, and the remainder become secondary devices. If all the devices in the virtual cluster are powered up at the same time, the highest-priority device becomes the virtual cluster Master. However, in these circumstances, if more than one device has the same highest priority, the one with the lowest IP address becomes the virtual cluster Master. When the Master fails, one of the secondary devices becomes Master based on priority, and if the devices are at the same priority level, then the decision will be based on the lowest IP address.

As priority plays an important role, it is very important that you assign the proper priority to devices. If your network has different models of VPN Concentrators, the rule of thumb is to choose the device with the greatest load capacity to be the virtual cluster Master. Therefore, assign the highest priority. Table 8-7 shows recommended priorities that are based on different models of hardware capacity. However, if you have the same models of VPN 3000 concentrators, use configure priority 10 for all the devices to shorten the decision-making time to select the virtual cluster Master.

Table 8-7. Priority Suggestions for VPN Concentrators

VPN Concentrator Model	Priority Default
3005	1
3015	3
3030	5
3060	7
3080	9

The virtual cluster appears to outside clients as a single virtual cluster IP address. This IP address is not tied to a specific physical device. It belongs to the current virtual cluster Master; hence, it is virtual. A VPN client attempting to establish a connection connects first to this virtual cluster IP address. The virtual cluster Master then sends back to the client the public IP address of the least-loaded available host in the cluster. In a second transaction (transparent to the user), the client connects directly to that host. In this way, the virtual cluster Master directs traffic evenly and efficiently across resources.

If a machine in the cluster fails, the terminated sessions can immediately reconnect to the virtual cluster IP address. The virtual cluster Master then directs these connections to another active device in the cluster. Should the virtual cluster Master itself fail, a secondary device in the cluster immediately and automatically takes over as the new virtual session Master. Even if several devices in the cluster fail, users can continue to connect to the cluster as long as any one device in the cluster is up and available.

Note

Load balancing works only for remote access VPNs with Cisco VPN Client Release 3.0 and later, or Cisco VPN 3002 Hardware Client Release 3.5 and later. All other clients, including LAN-to-LAN connections, can connect to the VPN concentrator on which load balancing is enabled, but they cannot participate in load balancing. Clustering can only be used as an alternative to VRRP. It is not possible to use both options simultaneously.

Work through the following procedure to configure clustering:

Step 1.	Identify the filters that you have applied on the interfaces by browsing to Configuration > Interfaces window.
Step 2.	Open the Configuration > Policy Management > Traffic Management > Filters window.
Step 3.	Select the filter you have applied to the Private interface from Filter list.
Step 4.	Click on Assign Rules to Filter to open the Configuration > Policy Management > Traffic Management > Assign Rules to Filter window.
Step 5.	Make sure that VCA In (forward/in) and VCA Out (forward/out) are in the Current Rules in Filter list. If they are not in this list, add them and then click Done.
Step 6.	Follow steps 1 through 4 for the Public interface as well. Click the Save Needed icon to save your edits.
Step 7.	Open the Configuration > System > Load Balancing window to enable and configure load balancing as shown in Figure 8-11. Figure 8-11. Sample Configuration of cluster on a Concentrator
Step 8.	Enter an IP address in the VPN Virtual Cluster IP Address box from the Public interface IP address network. This is the address VPN Client uses to connect.
Step 9.	In the VPN Virtual Cluster UDP Port, keep the default port unless another application is using this port in your network.
Step 10.	Check the Encryption check box to enable encryption for the communication among the clustering devices.
Step 11.	If you have Encryption checked, specify an IPsec Shared Secret that is common among the Concentrators in the virtual cluster group.
Step 12.	Check WebVPN Redirect via DNS if you want to enable DNS redirection instead of IP Address redirection for WebVPN sessions.
Step 13.	Under Device Configuration, check the Load Balancing Enable check box to include this VPN Concentrator in the virtual cluster.
Step 14.	For Priority, enter a value between 110 (refer to Table 8-7 to make this decision).
Step 15.	In the NAT Assigned IP Address text box, enter the translated (public) IP address if this device is behind a NAT device and the IP of this box is translated by the NAT devices. Otherwise, leave it at the default, which is 0.0.0.0.
Step 16.	Click Apply and finally Save to complete the configuration of one of the concentrator participants of the virtual cluster.

Follow steps 1 through 16 to configure the remainder of the concentrators participating in clustering.

Redundancy Using IPsec Backup Servers

If you do not want to configure VRRP, or a cluster for Remote Access VPN redundancy, you can accomplish this by configuring the IPsec Backup Servers. You can configure a backup server in either of the two ways:

• Manually on the VPN Client You can add multiple host names or IP addresses of VPN Concentrators or clusters per connection on Remote Access VPN Client. To do that, click on Backup Servers tab and then Add, which will allow you to define the VPN Concentrator or the cluster's name or IP address. Be sure to check Enable Backup Servers. On the VPN Concentrator, be sure that you configure User Client Configured List for IPsec Backup Servers under Client Config tab of group configuration under Configuration | User Management | Groups | Modify.

• Automatically Push from the VPN Concentrator You can configure group profiles on VPN Concentrator so that VPN Concentrator will push the IPsec Backup Servers list to the VPN Client after the successful connection establishment. To perform this task, go to Configuration > User Management > Groups > Modify to edit the group. Then go under Client Config tab, and select Use List Below for the IPsec Backup Servers. Be sure to define the list of the Backup Concentrators in the box provided.