Category list

Network and Path Redundancy

IPSec VPNs are a La:yer 3 VPN technology for securing IP traffic and therefore rely on a stable IP-enabled foundation for stability and HA. As such, one critical design consideration for IPSec VPNs is the incorporation of resiliency and HA between the two IP-enabled termination points of the IPSec VPN tunnel. Consider the three sample network topologies illustrated in Figures 5-1 through 5-3. We will use these topologies to illustrate how IPSec HA increases as single points of failure within the underlying IP foundation between the two IPSec tunnel termination points are eliminated.

Figure 5-1. Site-to-Site VPN without Path Redundancy

The topology in Figure 5-1 illustrates a scenario in which no redundancy is designed into the underlying IP infrastructure. This type of design provides many different points at which the IPSec VPN tunnel could fail due to a failure in one of the many nodes in between the termination points of the IPSec tunnel:

Interface Failure The two serial interfaces connecting WAN_EdgeA and WAN_EdgeB present single points of failure for the VPN tunnel. If one of those interfaces on either router were to fail, then the Internet Key Exchange (IKE) and IPSec SAs comprising the IPSec VPN tunnel would have to be renegotiated upon recovery of that interface. IPSec can be configured to use multiple interfaces to eliminate these failure points, increasing the availability of the IPSec VPN. Figure 5-2 illustrates a topology in which path redundancy is designed between two VPN gateways at the interface level on WAN_EdgeA and WAN_EdgeB.

Figure 5-2. Dual-Interface Path Redundancy
WAN Infrastructure/Carrier Failure In the design illustrated in Figure 5-1, the integrity of the IPSec VPN tunnel depends directly on the stability of the WAN link between WAN_EdgeA and B. A failure on the provider network would cause the IPSec VPN tunnel to be renegotiated once the failure is repaired. For traffic requiring higher availability in the crypto path, a backup WAN link can be deployed, as depicted in Figure 5-2.
Node Failure Even with redundancy built into the design at an interface and link level between the two IPSec VPN gateways, there still exists the possibility that the IPSec VPN tunnel could fail due to a system failure on the VPN gateway itself. Figure 5-3 depicts a topology that provides a greater degree HA at the WAN edge.

Figure 5-3. WAN Gateway, Interface, and Carrier Redundancy

The topology in Figure 5-3 eliminates all single points of failure between sites A and B, including interface-level, link-level, and node-level failure points. Although it is the most costly of the three designs, the topology in Figure 5-3 provides the greatest degree of path availability for the IPSec VPN tunnel, and it is therefore the soundest IPSec HA design.

Figures 5-1 through 5-3 illustrate how designing resiliency into the infrastructure supporting an IPSec VPN tunnel increases the effectiveness of the IPSec HA design itself by stepping through the elimination of single points of failure. Every removal of a single point of failure along the IPSec VPN tunnel path, however, also increases the cost of the overall solution. As a result, administrators should consider the business requirements of application data to be included in the encrypted path when investing in this area of IPSec HA.

IPSec Tunnel Termination Redundancy

The IPSec HA design in Figure 5-3 eliminates all single points of failure between the two tunnel termination points of the IPSec VPN except onethe tunnel termination point itself. Indeed, all of the network topologies discussed up to this point present single points of failure at the actual tunnel termination point itself. In this section, we will discuss three methods for designing HA into the termination of the IPSec VPN tunnel:

Tunnel Termination on Highly Available Interfaces Terminating the IPSec tunnel on an interface that is resilient to the failure of any other physical interface on the gateway increases the availability of the IPSec Tunnel.
Tunnel Termination on HSRP/VRRP Virtual Interfaces With Cisco IOS, IPSec VPN tunnels can be terminated on HSRP Virtual Interfaces. This effectively allows box-level redundancy at the termination points of the IPSec tunnel itself.
Tunnel Termination with Multiple Peer Statements Redundant IPsec VPN peer statements can be used to provide redundancy to multiple redundant points of termination on the opposite end of the IPSec VPN tunnel.

In addition to these tunnel termination redundancy methods, redundancy can be built into the IPSec VPN tunnel infrastructure between the termination points of the IPSec VPN tunnel. The availability of the routing protocol that provides the underlying transport between IPSec VPN tunnel termination points therefore has a material impact on the system-level IPSec VPN HA.

Multiple Physical Interface HA with Highly Available Tunnel Termination Interfaces

Now that redundancy has effectively been built into the path between the two tunnel termination points of the IPSec VPN tunnel (Figure 5-3), what happens when a failure occurs on one of the actual IPSec tunnel termination points themselves ? All of the extra funding invested in path HA would be negated by such a failure. Figure 5-4 extends the design depicted in Figure 5-3 to include termination-point redundancy using high-available loopback interfaces.

Figure 5-4. Tunnel Termination on Highly Available Interfaces

The design illustrated in Figure 5-4 extends path HA to the tunnel termination point itself by utilizing a secondary Fast Ethernet port on the VPN gateways, IPSec_A and IPSec_B. Cisco IOS allows the administrator to source the IPSec VPN tunnel from a loopback interface on IPSec_A and IPSec_B, effectively allowing the two VPN gateways to maintain the IPSec VPN tunnel independently of a failure on one of the two Fast Ethernet interfaces on the box. Likewise, the target termination points are loopback interfaces, allowing for tunnel termination point HA on both the origination and termination sides of the IPSec tunnel.

Tunnel Termination HA Using HSRP/VRRP Virtual Interfaces

Using loopback interfaces to terminate the IPSec VPN tunnel, as displayed in Figure 5-4, allows the VPN gateways to leverage redundant interfaces (Fa0/0 and Fa0/1) on IPSec_A and IPSec_B for increased HA. However, this solution does not provide redundancy in a scenario in which the gateway itself fails. To design for box-level tunnel termination point redundancy, HSRP/VRRP virtual interfaces can be used to originate and terminate the IPSec VPN tunnel. Figure 5-5 presents an extension of Figure 5-3 that includes box-level tunnel termination HA using an HSRP Virtual Interface.

Figure 5-5. Tunnel Termination Point HA Using HSRP Virtual Interfaces

The design illustrated in Figure 5-5 allows for a greater scope of tunnel termination redundancy. Not only does it eliminate the termination interface itself as a single point of failure, but it also eliminates the VPN gateway itself as a single point of failure. For example, if IPSec_A1 were to experience a total system failure due to, say, a power failure in the building, IPSec_A2 would take over as the IPSec VPN tunnel termination point, thereby preserving the consistency of the IPSec VPN. This type of design has two variations:

Stateless IPSec HA Stateless IPSec HA describes a situation in which a IPSec VPN tunnel is terminated on a virtual interface using HSRP and VRRP, but no state is communicated between the redundant IPSec VPN gateways in the HSRP group that are serving as the physical points of termination for the IPSec VPN tunnel. This method of box-level tunnel termination redundancy involves a teardown of the IPSec VPN tunnel itself using IKE keepalives when a failure occurs on the active HSRP router (IPSec_A1/B1 in Figure 5-5). Once this teardown occurs, a new tunnel is created using the same virtual interface. This process involves the renegotiation of Phase 1 and 2 SAs with the newly active HSRP/VRRP-enabled HSRP Router. As we'll discuss in Chapter 6, "Site-to-Site Local HA Solutions," the teardown and renegotiation of SAs in a stateless design can lead to a somewhat lengthy reconvergence of the IPSec VPN tunnel in a failover scenario. For environments where reconvergence is critical and HA needs are paramount, a stateful IPSec HA design should be considered .
Stateful IPSec HA Stateful IPSec HA can also be deployed using the same topology as a stateless IPSec HA design, such as the one in Figure 5-5. Unlike stateless IPSec HA designs, stateful IPSec HA designs are capable of communicating the state of the IPSec and ISAKMP SADB to the redundant IPSec VPN gateway in the HSRP/VRRP group prior to failover. This allows the IPSec VPN tunnels on the failed node to failover to the redundant node without the remote end of the IPSec VPN tunnel noticing that a failover has occurred. With IPSec VPN gateways running Cisco IOS, SADB information is communicated from the active IPSec VPN gateway to the standby IPSec VPN gateway using Stateful Switchover (SSO) and the Stream Control Transport Protocol (SCTP). The communication of SADB information between active and standby VPN gateways in the HSRP group allows the standby IPSec VPN gateway in the HSRP/VRRP group to take over as the IPSec VPN tunnel termination point in failover scenario without the teardown and renegotiation of Phase 1 and 2 SAs required in stateless IPSec HA operations (the standby router already has those SAs in its SADB prior to failover). The deprecation of the requirement of reaping stale SAs and renegotiating new ones in a failover scenario leads to dramatically reduced reconvergence times with stateful IPSec HA.

Note

The details of stateful and stateless IPSec HA design between routers in an HSRP group, including configuration, failover operations, and steps to minimize reconvergence delay impact, are discussed in greater detail in Chapter 6, "Site-to-Site Local HA Solutions."

HA with Multiple Peer Statements

In many cases, such as in situations in which geographic IPSec HA is required, it may not be feasible to terminate an IPSec tunnel on a virtual interface using HSRP and/or VRRP. Figure 5-6 depicts an example of one such situation.

Figure 5-6. Geographic IPSec HA Using Multiple Peering Statements in Each Crypto Map on IPSec_A1, A2, B1, and B2

In Figure 5-6, IPSec_A1 and IPSec_A2 are now located in different wiring closets, and therefore do share the same Layer 3 boundary facing the WAN edge routers (WAN_EdgeA1 and WAN_EdgeA2). The same conditions exist at site B for routers IPSec_B1 and IPSec_B2. As such, HSRP or VRRP hellos cannot be sent between IPSec_A1 and A2 or between IPSec_B1 and B2 for IPSec tunnel termination on a virtual interface. In this situation, multiple peering statements can be included in the crypto maps for routers IPSec_A1, A2, B1, and B2, creating a backup IPSec VPN tunnel for encrypted traffic on egress from each IPSec VPN gateway. Figure 5-7 shows the loopback-to-loopback IPSec peering sessions between IPSec_A1, A2, B1, and B2 using redundant peering statements to protect traffic from Network_A to Network_B in the encrypted path.

Figure 5-7. Loopback-to-Loopback IPSec Peering Sessions with Redundant Peer Statements

Note

Further explanation of design considerations and configuration of sourcing and terminating IPSec tunnels on loopback interfaces can be found in Chapter 6, "Site-to-Site Local HA Solutions." More detail on IPSec VPN design with redundant IPSec peering statements can be found in Chapter 7, "Site-to-Site Geographic HA Solutions."

RP-based IPSec HA

Because IPSec itself is a Layer 3 VPN technology, IPSec is dependent on the existence of a stable IP transport between tunnel termination points to operate effectively. This means that IPSec requires accurate and timely updating of routing information on intermediate nodes between the termination points of the IPSec tunnel.

The routing protocol of the IP infrastructure underneath the IPSec tunnel is responsible for communicating routing information to nodes in between the IPSec tunnel termination endpoints. If there is an RP failure between the two termination points of the IPSec tunnel, then IPSec traffic will not be able to flow between the two endpoints, eventually leading to expiration of the previously negotiated SA lifetimes or timeout of the IKE keepalives (if enabled). Fortunately, IPSec is not path-discriminateIPSec traffic will take any available Layer 3 path from the tunnel source to tunnel destination before tearing down the tunnel. Administrators can therefore leverage the use of routing protocols between tunnel endpoints to provide numerous routed paths between source and destination.

Figure 5-8 illustrates a design in which the dedicated WAN circuits incorporated into the designs in Figures 5-1 through 5-7 are replaced with uplinks to an ISP, presenting a much higher degree of HA beyond the interface of the WAN_Edge routers. The ISP has many different paths through which to route packets between the WAN_Edge routers as opposed to just one with the dedicated WAN circuits.

Figure 5-8. RP-Based HA between IPSec Tunnel Termination Points

Therefore, by replacing the dedicated WAN circuits between the WAN_Edge routers with dual uplinks on each router to an ISP, the design in Figure 5-8 affords the IPSec VPN a much greater degree of RP-based HA, since the number of Layer 3 paths between endpoints has been greatly expanded. Furthermore, through the use of dual uplinks to the ISP, the design makes no concession in interface-level or box-level IPSec HA. In fact, the design in Figure 5-8 can use the same loopback-to-loopback peering model with redundant peering statements on each IPSec VPN gateway illustrated in Figure 5-7. The change in transport from dedicated WAN circuits to dual uplinks to the ISP on each gateway, while providing greater HA to the IPSec VPN itself, does not necessarily change the peering model of the IPSec VPN itself.

Warning

You may have noticed already that, as with most value-added services, increased HA usually comes with increased cost. In the context of the design illustrated in Figure 5-5, this cost is represented by the doubling of fee-based WAN links on the WAN_Edge routers (8 ISP uplinks versus 4 dedicated WAN circuits). Because of this, investing in increased HA is a business decision, and the needs of the business should be carefully evaluated when investing in the increased benefit of added IPSec HA. If overlooked, administrators face the risks associated with over-designed IPSec deployments, including increased maintenance, management, complexity, and costs.