Psec Stateless Failover

There are three primary stateless means to detect and react to a fault. The ideal reaction to a detected fault is to automatically send traffic a different way. The three failure detection methods are as follows:

■ An IGP within GRE over IPsec

■ Hot Standby Routing Protocol (HSRP) (or one of the related protocols) The sections that follow discuss each of these methods in greater detail.

Dead Peer Detection

Dead peer detection is a configuration option during the IPsec VPN setup. DPD also offers a stateless failover from one VPN tunnel to another. This means that the routers are not keeping track of which VPN tunnels are currently alive. Instead, traffic flows through the primary tunnel until it fails, at which time a secondary tunnel is selected.

DPD has two operational modes: periodic mode and on-demand mode.

DPD periodic mode has the following characteristics:

■ DPD keepalive messages are periodically sent between IPsec VPN peers.

■ DPD keepalive messages are in addition to the normal IPsec rekey messages that also regularly traverse the tunnel.

■ DPD keepalive messages are not sent if user data is transmitted through the VPN tunnel.

■ DPD keepalive messages are used only when there is a lull in tunnel traffic.

One negative consequence of periodic DPD mode is the potentially excessive tunnel overhead. IKE already has a regular set of keepalive messages that pass through the tunnel. This keepalive mechanism is the IPsec SA rekeying messages that occur as the IPsec lifetime nears expiration.

Use of an IPsec VPN tunnel normally means that packets are encrypted at one end and decrypted at the other. The addition of DPD keepalive messages adds more encryption/decryption overhead to the VPN endpoints. However, the addition of these DPD keepalive messages provides more timely failure detection.

In contrast, DPD on-demand mode has the following attributes:

■ It is the default DPD mode in a Cisco IOS device.

■ DPD keepalive messages are sent only if the liveliness of the remote peer is in question. If traffic is sent to the peer, a response is expected. If such a response does not arrive, a DPD keepalive message is sent.

■ DPD keepalive messages are never sent during otherwise idle tunnel moments.

■ It is possible that a router might not discover a dead peer until the IKE or IPsec security association (SA) rekey is attempted.

The use of on-demand mode reduces the additional tunnel overhead that normal mode introduced. However, an alternate IPsec VPN tunnel might not be used immediately upon the failure of the primary one. This is not as bad as it may sound. If there is no traffic traveling through an IPsec VPN, and the VPN fails, there truly is no need to change to the alternate tunnel until user data arrives.

The configuration of DPD in a Cisco IOS device is simply a modification of an existing IPsec VPN setup. As already discussed, DPD uses keepalive messages to determine if the primary peer has failed, and then swaps over to a backup peer. Figure 15-1 shows a sample DPD configuration and topology.

Figure 15-1 shows how a remote site is configured with redundant IPsec VPN tunnels back to a central office using DPD. The two Cisco IOS commands that enable DPD are crypto isakmp keepalive seconds [retries] [periodic | on-demand] set peer ip-address [default]

The crypto isakmp keepalive IOS command determines the mode and frequency of DPD. Remember that periodic mode sends DPD keepalive messages, which are continually sent to verify that the remote VPN peer is still alive. The default DPD mode is on-demand, which sends DPD messages only if the remote peer is believed to be dead. Default options do not appear in the configuration.

The crypto isakmp keepalive command has two timer options. The seconds option defines how often DPD keepalive messages are sent in periodic mode. The retries option defines how long to wait to resend DPD messages after the previous one has failed.

Figure 15-1 DPD Configuration

Figure 15-1 DPD Configuration

crypto isakmp keepalive 10 3

crypto ipsec transform-set to-central esp-3des esp-sha-hmac crypto isakmp keepalive 10 3

crypto ipsec transform-set to-central esp-3des esp-sha-hmac crypto map central-office 10 ipsec-isakmp set peer 172.20.1.1 default set peer 172.20.1.2 set transform-set to-central match address 120

access-list 120 permit ip 10.10.1.0 0.0.0.255 10.20.1.0 0.0.0.255

Figure 15-1 shows two peer configurations (with the set peer IOS commands). The primary peer (172.20.1.1) is indicated with the default option. This is the peer that is initially used between the remote and central offices. The secondary peer (172.20.1.2—the one without the default option) is not used until DPD determines that the primary peer has failed.

IGP Within a GRE over IPsec Tunnel

Chapter 14, "GRE Tunneling over IPsec," covered the use of GRE over IPsec. Remember that a normal IPsec VPN cannot transport dynamic routing protocols. A GRE tunnel is created for the routing protocol traffic, and then sent through the IPsec VPN for confidentiality and integrity.

OSPF and EIGRP have very fast convergence around failed links. The use of a backup GRE over IPsec VPN tunnel does provide redundancy, at the cost of additional IGP overhead in the VPN tunnel.

If two sites are connected with two or more GRE over IPsec tunnels, the IGP that runs across the tunnels can make very rapid routing decisions on alternative paths. Of course, it is important to create the tunnels such that there is no single point of failure in the paths. For example, if all the tunnels start on one router and end on a different router, the failure of either router eliminates all the tunnels.

HSRP

Most hosts are configured with a single gateway, or default, router. The address of this default router is typically delivered to the host during address acquisition via DHCP. However, if the gateway router fails, then all hosts that use it become isolated.

A good network design attempts to remove any single points of failure; however, such design options come at a price. The addition of a second gateway router not only costs money, but adds complexity to the network. The simple configuration of a second default gateway in the end hosts does not ensure a timely failover to the secondary gateway when needed.

It is possible to have the end hosts actually discover the gateways, or run routing protocols with the gateways. However, neither of these options is desirable for a number of reasons (administrative and processing overhead, feature support for some platforms, network security concerns).

HSRP offers the capability to use more than one router as a default gateway for end hosts. A group of routers form a logical gateway. This gateway IP address is used by the end hosts as their default gateway. A virtual MAC address is also used when the hosts broadcast (use ARP) for their default gateway.

Normally, the actual gateway IP address is configured on a single router. However, the HSRP group handles traffic destined for the logical gateway IP address. Within the group, the active router handles all packets destined for the logical IP address (and MAC address). A standby router exists to forward packets only if the active router fails.

Any number of routers can be in an HSRP group (although a large number quickly becomes impractical). There is only one active router per group (per gateway IP address). The remaining routers in the HSRP group elect the standby router. The active and standby routers periodically communicate with each other, which is how the standby router determines if the active router has failed. If the active router fails, the standby router takes control of the group and forwards traffic sent to the virtual group IP address. At this time, the remaining routers in the HSRP group elect a new standby router. Although the HSRP routers communicate with each other, this is still considered stateless VPN failover because the state of the IPsec VPN tunnels is unknown.

It is possible for one physical LAN to be home for multiple IP subnets. As such, each subnet would typically need a gateway router. With HSRP, each subnet would use a virtual standby group, where each standby group emulates a physical gateway router. HSRP groups can coexist and overlap on the same physical router. For example, one router could be the active router for one group and the standby router for another. In such a case, the router forwards traffic only for the active group. Another router forwards traffic for the other HSRP group.

Figure 15-2 shows a sample HSRP configuration and topology for the remote office. This actually shows the ultimate in redundancy, because there are two connections to the central office, and each uses a separate ISP. Because there are two physical connections, there are two different IPsec VPNs configured also. Not all remote sites are as fortunate.

Figure 15-2 HSRP Configuration at the Remote Office

IPsec VPN #1

Remote Office

.1 Router A

Figure 15-2 HSRP Configuration at the Remote Office

IPsec VPN #1

.1 Router A

Router B

Router A2

Router A2

Router

IPsec VPN #2

Router B

Router

Central Office .1 Router C

jf Router

Router A1:

IPsec VPN #2

interface fastethernet 0/1 ip address 10.10.1.1 255.255.255.0 standby 1 ip 10.1.1.5 standby 1 priority 150 standby 1 preempt

Router A2:

interface fastethernet 0/1 ip address 10.10.1.2 255.255.255.0 standby 1 ip 10.1.1.5

The hosts at the remote site would use 10.10.1.5 as their default gateway. This is the HSRP group IP address (virtual IP address) between Routers A1 and A2. Router A1 is configured with a higher HSRP priority (the default is 100), which means that it will initially be the active router. The preempt command says that if it has a higher priority (and it does), it will regain active HSRP status if it ever fails and comes back to life.

The HSRP service provided to end hosts does not interact with the IPsec VPN configuration. For the hosts, and thus at the remote site, HSRP simply selects the active default gateway.

Figure 15-3 shows how HSRP can be used at the central office to terminate IPsec VPN connections from remote offices.

Figure 15-3 HSRP Configuration at the Central Office

Figure 15-3 HSRP Configuration at the Central Office

crypto map central-office 10 ipsec-isakmp set peer 172.20.1.5

crypto dynamic-map from-remote 10 set transform-set trans1 reverse-route crypto map central-office 10 dynamic from-remote crypto map central-office 10 ipsec-isakmp set peer 172.20.1.5

crypto dynamic-map from-remote 10 set transform-set trans1 reverse-route crypto map central-office 10 dynamic from-remote interface fastethernet 1/0 ip address 172.20.1.1 255.255.255.0 standby 1 ip 172.20.1.5 standby 1 priority 15 0 standby 1 preempt standby 1 name vpn-remote crypto map central-office redundancy vpn-remote

In this example, HSRP is configured between Routers C and E for the benefit of incoming IPsec VPN connections—not the hosts shown at the central office. These two routers represent the IPsec VPN headend for all remote sites. The 172.20.1.0/24 LAN is globally reachable. The remote site is configured to terminate its VPN connection to 172.20.1.5. At the central office, this IP address is actually a virtual group IP address between Routers C and E. In this example, the remote site does not benefit from as much redundancy as it does in Figure 15-2.

Figure 15-3 shows the HSRP configuration for Router C. The HSRP configuration for Router E would be very similar. A separate HSRP group can be configured between Router C and Router E to offer the hosts at the central office a redundant gateway. Such a configuration would be similar to the one shown in Figure 15-2.

The interface crypto map statement indicates that the HSRP group vpn-remote provides redundancy. This HSRP group name is defined on the interface. The central office is also configured with a dynamic crypto map. This means that any remote office (source IP address) can initiate a VPN connection with the central office. It is possible that remote offices that use DSL or cable connectivity to the Internet do not have fixed external IP addresses, and thus cannot be statically configured at the central office.

It is important to remember that if Router C is active and fails, the IPsec VPN to it will also drop. The remote site will reestablish an IPsec VPN to the same remote IP address (the HSRP group IP address—172.20.1.5), which is then handled by Router E. When Router C comes back to life, the IPsec VPN again drops (because Router C becomes active and preempts Router E) and is reestablished to Router C.

Was this article helpful?

+1 0

Post a comment