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
[View full size image]
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