High Availability in IPsec is very important for both LAN-to-LAN and Remote Access VPN connections. It is beyond the scope of this chapter to present every best practice for designing a robust IPsec VPN network (any design guide will do that). However, this section provides some detail on the features available that might assist you in configuring the resiliency for both LAN-to-LAN and Remote Access VPN connections. Resiliency for IPsec can be obtained in either of the two following ways:
Stateful FailoverThe Stateful failover feature is introduced in Versions 12.2S and 12.3(11)T. This feature enables a router to continue processing and forwarding packets after an outage for VPN traffic. The IPsec head end router maintains a full IPsec session and state information at a backup head end router to take over the active IPsec sessions should the primary head end router fail. With Stateless Failover (which is discussed in the following section), there is no way to maintain an IPsec session through a failed IPsec router. Sessions must time out and connectivity be re-established, causing network downtime. IPsec Stateful Failover is implemented using the Stateful switchover (SSO) and Hot Standby Routing Protocol (HSRP) feature. HSRP provides network redundancy for IP networks, which means that HSRP monitors both the inside and outside interfaces so that if either interface goes down, the whole router is considered to be down and ownership of Internet Key Exchange (IKE) and IPsec security associations (SAs) is passed to the standby router (which transitions to the HSRP active state). SSO allows the active and standby routers to share IKE and IPsec state information so that each router has enough information to become the active router at any time. Before you configure Stateful Failover, you must ensure that you have the identical Hardware, the same software version, and the same configuration on both sides. Configuring stateful failover for IPsec involves configuring HSRP by assigning a virtual IP address, and enabling the SSO protocol for replicating the IKE and IPsec SA information. For a more detailed information on this feature, refer to the following link: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_11/gt_topht.htm Stateless FailoverIn Stateless Failover, the state information (IKE and IPsec SAs) are not replicated to the backup peer. So the remote peer must take the following two actions:
The Loss of IP connectivity could be caused by many variables, such as device failure, local link failure, or loss of connectivity to the service provider (SP), and so on. A more detailed discussion on how to achieve Stateless Failover on Cisco IOS Router is presented in next few sections. Loss of Connection Detection MechanismPresently, Cisco IOS software offers the following mechanisms to detect the loss of IP connectivity for IPsec VPN implementation:
Stateless Failover Mechanism OptionsNow that you are comfortable with the link failure detection mechanism, it is time to explore the various options available to be configured once the link failure occurs and is detected by one of the mechanisms discussed in the preceding section. This section explores some of the options that are available for reconnecting with the standby device when the link failure occurs. Backup Peer for Basic LAN-to-LAN IPsecWith either IPsec keepalive or DPD configured, you can define multiple IPsec peers under the single crypto map. The first one in the list will be used to build up the IPsec tunnel. If the first one in the list fails, the second peer in the list will be tried. In Example 6-40 under IKE Keepalive in the previous section, the following configuration defines multiple peers under the same crypto map statement: crypto map to_Doha 10 isakmp-ipsec ! With this configuration, Router will always try to build up the IPsec tunnel with peer ! 30.1.1.1. If this peer is down for any reason, peer 40.1.1.1 will be tried. set peer 30.1.1.1 set peer 40.1.1.1 set transform-set strong match address 101 Hot Standby Routing Protocol (HSRP) and Reverse Route Injection (RRI)HSRP and RRI together can provide a robust resilience mechanism for hub and spoke connections. HSRP is used for IP redundancy to assist in failing over between two devices when an interface or link becomes unusable. HSRP tracks the state of the router's interfaces and IP connectivity, which provides a mechanism to switch between primary and secondary devices on a failure. HSRP has now been closely coupled with IPsec to track state changes and provide a better solution for stateless IPsec failover. It is now possible to use the HSRP Virtual IP Address (VIP) as a peer endpoint address. HSRP is an active-standby solution, which means that when the primary one is active, the secondary does not have any traffic passing through it. However, it is possible to have multiple active HSRP groups defined, thus allowing half the peers to be active on one device and the other half on the second device. A side benefit of HSRP is that the remote peer now has a much simpler configuration because only one peer needs to be definedthat of the HSRP VIP. In the event of a failure, all SAs must be re-established. So, as you can see, HSRP provides the redundancy guarantee for spokes. However, this might create problems as well. When failover occurs, devices behind the head-end devices need to know which head-end currently owns the active SAs for IPsec traffic; otherwise, those devices may return the replies to the wrong routers. RRI was developed to correct the routing behavior of the upstream devices and to ensure that a return gets back to the active peer. RRI allows for static routes to be automatically inserted into the routing process for those networks and hosts protected by a remote tunnel endpoint. These protected hosts and networks are known as remote proxy identities. Each route is created based on the remote proxy network and mask, with the next hop to this network being the remote tunnel endpoint. Using the remote VPN router as the next hop forces traffic through the crypto process to be encrypted. Once the static route is created on the VPN router, this information is then propagated to upstream devices, allowing them to determine which is the correct VPN router to receive returning traffic to maintain IPsec state flows. RRI works with both static and dynamic crypto maps. In Figure 6-6, if you have two routers in parallel on the Doha site, and if you want to configure HSRP and RRI, both of the Doha routers must be configured in exactly the same way. The important configuration elements are the interface standby group information, interface crypto map command, crypto map, keepalives, and routing as shown in Example 6-41. Example 6-41. Configuration of Primary Router on the Doha Site
The following is a listing of some important points about HSRP and RRI implementation:
Generic Routing Encapsulation (GRE) Tunnels over IPsecTo attain redundancy with the GRE over IPsec, the remote peer of the IPsec tunnel should be configured with two GRE tunnels, one to the primary head-end VPN router and the other to the backup VPN router. Both GRE tunnels are secured with IPsec: each one has its own IKE SA and two IPsec SAs. Because GRE can carry multicast and broadcast traffic, it is possible and very desirable to configure a routing protocol for these virtual links. Once a routing protocol is configured, the failover mechanism comes automatically. The Hello or keepalive packets sent by the routing protocol over the GRE tunnels provide a mechanism to detect loss of connectivity. In other words, if the primary GRE tunnel is lost, the remote site detects this event by the loss of the routing protocol Hello packets. Once virtual-link loss is detected, the routing protocol chooses the next best path. For this case, the backup GRE tunnel is chosen. Therefore, the second part of VPN resiliency is obtained by the automatic behavior of the routing protocol. Because the backup GRE tunnel is always up and secured (MM and QM have already been negotiated), the failover time is determined by the Hello packet mechanism and the convergence time of the routing protocol. Aside from providing a failover mechanism, GRE tunnels also provide the ability to encrypt multicast/broadcast packets and non-IP protocols. It is recommended to use EIGRP as a routing protocol because it performs better than OSPF for GRE over IPsec. In Figure 6-6, if you have another router in Doha, when one of the tunnels is down, packets flow through the other tunnel, so the Dhaka LAN still should be able to access resources to the Doha LAN. Example 6-42 shows the configuration of Dhaka. This router is configured with GRE, EIGRP, and IPsec. Important configuration elements are the redundant peers and multiple crypto maps, GRE tunnel interfaces, the bandwidth setting on the backup GRE interface, the routing protocol, and multiple access control lists (ACLs) as shown in highlighted areas. Example 6-42. Configuration of GRE over IPsec for Dhaka
Note To control which tunnel should be primary and which one should be secondary, you can use delay, and the bandwidth command. If you do not specify any of these, the traffic will be load sharing on both tunnels, and they will act as backups for each other. |