Geographic IPsec VPN High Availability with IPsecGRE and Encrypted Routing Protocols
Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing ProtocolsTunneling traffic in GRE prior to encryption with IPsec enables the encryption of multicast traffic. This is due to the fact that the multicast traffic is represented as a payload of a unicast packet after it has been encapsulated with GRE. As such, once the packet has been encapsulated in GRE, it is presented to the crypto engine as a unicast packet. We have referred to this as IPsec+GRE in previous chapters. IPsec+GRE is a key design option for passing multicast traffic, including RPs that use multicast updates, through an encrypted tunnel. As such, sending routing protocol updates over an IPsec+GRE tunnel serves as an alternative to RRI for preserving IP routing continuity across an IPsec VPN tunnel. Solution Overview for IPsec+GRE with Encrypted Routing ProtocolsIPsec+GRE tunnels have increased in popularity primarily due to the increase in multicast application adoption. As these applications drive the amount of multicast traffic in the overall traffic profile upward, the need to secure this type of traffic increases proportionally. IGP multicast update traffic is one such critical multicast application that is often included in the crypto switching path. Tip Cisco IOS includes unicast RP update features for BGP and most IGPs. Encrypted unicast RP updates can be exchanged over the IPsec VPN tunnel to preserve IP routing continuity without the use of GRE. More information on Unicast RP updates is provided in Chapter 5. Sending RP updates across the IPsec tunnel enables RP adjacencies to be built between two networks situated on opposite sides of an IPsec tunnel, as illustrated in Figure 7-3. This solution therefore serves as an alternative to RRI for preserving IP routing continuity between IP networks across an IPsec VPN tunnel. Figure 7-3. IPsec+GRE with Encrypted Routing Protocol Updates The administrators of the network illustrated in Figure 7-3 face the same challenges as in the network topologies of Figures 7-1 and 7-2. Instead of using RRI to allow Network A and Network B to route between one another over the IPsec VPN tunnel, the administrators choose to create a GRE tunnel between C3845ISR-A and B through which RP updates are exchanged. All GRE traffic is then encrypted with a transform defined in the IPsec configuration on C3845ISR-A and B. This effectively allows the administrators of Network A and B to run the same routing protocol, preserving continuity of the routing tables of Network A and B by leveraging encrypted RP updates over the IPsec+GRE tunnel. The resulting forwarding numbered process along the path from Host-A to Server-B in Figure 7-3 is as follows:
The important difference in this design is that encrypted routing protocols essentially replace RRI as a means of IP routing continuity between Network A and Network B. With IPsec+GRE, routing protocols updates can be exchanged only once the IPsec tunnel is successfully established, which is more akin to a dynamic RRI implementation as opposed to a static one. Unlike either mode of RRI, redistribution of static routes in to the dynamic Interior Gateway Protocol (IGP) is not required. Instead, RP updates are automatically propagated throughout Network A and Network B. While the use of IPsec+GRE for encrypted routing protocols does deprecate the need for RRI, it does raise new requirements. Obviously, GRE tunnels must be created. Additionally, the crypto ACL is changed to include only GRE traffic between the tunnel endpoints. This is due to the fact that the crypto engine will now be presented with a GRE header resulting from the GRE encapsulation for inclusion in the crypto switching path based on a crypto ACL match, rather than the original headers now included as parts of the GRE payload. These necessary configuration elements are listed for C3845ISR-A and B of Figure 7-3 in Example 7-8, and the verification of the configuration is provided using the diagnostic commands in Example 7-9 later in our discussion of IPsec+GRE HA. Thus far, we've covered two options for establishing IP routing continuity between two networks across an IPsec VPN tunnel: IPsec+GRE with encrypted RP updates and RRI. Generally speaking, each method is used to accomplish the same task of enabling each end of an IPsec VPN tunnel to route to the opposite end. However, each method has different benefits and requirements. Keep several design considerations, such as the ones provided in the following list, in mind when choosing one or another:
At this point, the fundamental differences, requirements, and design drivers behind an RRI or IPsec+GRE decision should be clear. However, the IPsec+GRE solutions presented thus far have been limited to simple site-to-site designs without incorporating any elements of HA. We will now take a look at the design elements specific to geographic HA in IPsec+GRE, noting that these elements should indeed be coupled with the local HA design concepts covered in Chapter 6 for a full IPsec+GRE HA design. The numbered steps in Figure 7-4 are covered later in this section. Figure 7-4. Geographic HA with IPsec+GRE and Encrypted Multicast RP Updates The degree of availability of a given IPsec+GRE design such as the one illustrated in Figure 7-4 depends primarily on the reconvergence of three components:
Before any reconvergence can occur across the IPsec VPN tunnel, stale Internet Key Exchange (IKE) and IPsec SAs must be reaped from the SADB, and new ones must be established between valid peers. In Chapter 5, we discussed the use of IKE keepalives and DPD to expedite reconvergence of an IPsec VPN tunnel in a failover situation. If IKE keepalives or DPD is not used, stale SAs could remain present in the SADB for unacceptably long periods of time, potentially stalling the reconvergence of the IPsec VPN tunnel. Note The default SA lifetimes for IKE and IPsec SAs in Cisco IOS are 38400s and 3600s, respectively. IKE keepalives intervals can be configured as frequently as 10s apart. Therefore, using IKE keepalives potentially expedites stale SA cleanup from the SADB from as long as 3600s to as short as 30s (three missed IKE keepalives at 10s intervals). As such, IKE keepalives and DPD are a critical part of geographic HA concepts for both RRI and IPsec+GRE designs. IKE keepalives and DPD are also a critical part of IPsec peer availability, which is discussed in detail in Chapter 5. After the IPsec VPN peers have been managed appropriately, and a new IPsec VPN tunnel has been established, the GRE tunnel must be established. This component of the overall reconvergence process is not expected to be materially relevant to the routing protocol reconvergence that must occur once the GRE tunnel is established. Once the IPsec+GRE tunnel is established, RP neighbor adjacency must be built between the two GRE tunnel interfaces. This process can vary based on the routing protocol selected. However, consider, as an example, that most EIGRP interfaces use a default hold timer of 15s (three times the 5s hello interval), which is the time it will take for that EIGRP neighbor to be declared dead so that a new one can be established to a viable peer. For geographic IPsec HA deployments, the reconvergence component associated with RP reconvergence plays a critical role when deciding between IPsec+GRE vs. IPsec with RRI. Consider the failover scenario in Figure 7-4 in which the following steps are executed to facilitate reconvergence IPsec+GRE tunnel and associated EIGRP neighbor:
Similar to our discussion of RRI with multiple IPsec peers, IPsec+GRE in and of itself does not provide added degrees of availability to the design. Instead, IPsec+GRE is hardened using multiple, redundant, IPsec peers and redundant GRE tunnel interfaces that enable the IPsec+GRE tunnel to reconverge over a redundant path. This concept is referred to as path availability, and is discussed in greater detail in Chapter 5. Example 7-8 includes a sample configuration used on C3845ISR-A in Figure 7-4 providing HA using multiple IPsec peer definitions and redundant GRE tunnels. The failover process described previously for the IPsec+GRE deployment illustrated in Figure 7-4 is verified in Example 7-9. Internet Security Association and Key Management Protocol (ISAKMP) is configured to use preshared key (PSK) authentication with an MD5 hash, DES encryption (default), and a group 2 Diffie-Hellman modulus. A PSK of Cisco is used to authenticate IKE SAs with C3845ISR-A (200.1.1.2) and B (200.1.1.3). The cipher used on the cleartext traffic sent through the IPsec VPN tunnel to the spokes is ESP 3DES with MD5 HMAC authentication on the ciphered blocks. Unlike our previous discussions of RRI with multiple crypto maps, this IPsec+GRE design leverages multiple crypto map process IDs (10 and 20) to define different IPsec peers and crypto ACLs. This effectively enables the use of two IPsec+GRE tunnels to become active simultaneously, offering the ability to load balance across each in an active/active fashion. There are two crypto ACLs that are defined in their own respective process IDs (10 and 20) under the same crypto map, "chap7-IPsec+gre":
It is also important to note that there are two different routing protocol implementations relevant to the design. Unless the GRE tunnels are built across a directly connected L3 segment, a routing protocol is needed between the two GRE tunnel endpoints to successfully establish the GRE tunnel. This routing protocol will also be used to establish Phase 1 and 2 SAs that protect the GRE tunnels. In this case, Open Shortest Path First (OSPF) (OSPF 10) is used to accomplish both of these tasks. This routing protocol's updates and hellos will not be protected by IPsec. A second routing protocol is used to provide continuity between two routed domains on opposite sides of the IPsec VPN tunnel. In this case, EIGRP (EIGRP 10) is used to accomplish this by sending EIGRP hellos and updates across the GRE tunnel. These routing protocol updates and hellos will be encrypted because they are encapsulated with GRE, which is defined in the crypto ACLs 101 and 102 accordingly. Example 7-8. IPsec HA Configuration Using IPsec+GRE with Multiple Crypto-Process IDs and Redundant, Load-Sharing GRE Interfaces (C3845ISR-A)
The crypto engine entries shown in Example 7-9, lines 1-9, verify two active IPsec VPN tunnels, each with their own ISAKMP SA and 2 IPsec SAs. This confirms that the IPsec+GRE implementation is currently redundant in an active/active load-balanced format across the two tunnels. The output in Example 7-9, lines 11-18, confirms that both the local interface providing connectivity to private networks and the two GRE tunnels to the branches (C3845ISR-A and B) are all injected into the appropriate routing protocol (EIGRP AS 10) on C7304. Diagnostic output provided in Example 7-9, lines 20-26, confirms that there are three EIGRP neighbors currently established on C7304: one for connectivity to the private networks behind C7304 and two additional ones for connectivity to the private networks behind C3845ISR-A and B across the IPsec+GRE tunnels. Routes are being learned via EIGRP 10 over the two IPsec+GRE tunnel interfaces from C7304 to C3845ISR-A and B, respectively, as confirmed by Example 7-9, lines 28-40. Each route has two equal cost paths that C7304 will use to load balance over the two IPsec+GRE tunnels currently operating in an active/active fashion. Example 7-9. Verifying IPsec VPN Failover with IPsec+GRE with Multiple Crypto-Process IDs and Redundant, Load-Sharing GRE Interfaces (C3845ISR-A)
|
EAN: 2147483647
Pages: 113