This design option for IPsec VPN Geographic HA leverages two components to deliver continuity of cleartext routed domains across an untrusted network in a highly available fashion: Reverse Route Injection (RRI) and Multiple IPsec Peering statements. Each delivers complementary functions to deliver the overall solutionRRI is used to preserve routing information across the IPsec VPN tunnel, while multiple IPsec peering statements are used to deliver redundancy. Solution Overview for RRI with Multiple IPsec PeersIn our discussion of IPsec VPN HA, you have learned that it is important to preserve Layer 3 continuity between cleartext networks on either side of an IPsec VPN tunnel. One method that we have introduced to preserve this continuity is RRI. When two networks want to communicate across an untrusted intermediate network using an IPsec VPN tunnel for data confidentiality, authenticity, integrity, and nonrepudiation, RRI can be configured on each IPsec VPN tunnel endpoint to inject routes to the remote (on the opposite side of the IPsec VPN tunnel) cleartext network back into its local cleartext routed domain. Figure 7-1 illustrates the injection of remote routes in to a local routed domain in an IPsec environment using RRI. Figure 7-1. Simple Site-to-Site IPsec VPN Design with RRIThe following is an explanation of the steps illustrated in Figure 7-1:
This process illustrates dynamic RRI in a basic geographic site-to-site IPsec VPN example. As we'll later see when discussing RRI using multiple IPsec peering statements, the use of RRI in and of itself does not necessarily provide for IPsec HA. Instead, RRI is a component of HA when coupled with multiple peering statements or spread across multiple IPsec VPN tunnel termination points using the stateless or stateful local HA techniques discussed in Chapter 6. Examples 7-1 and 7-2 illustrate the basic configuration and verification of C3845ISR-A and B, respectively, for a simple site-to-site IPsec VPN deployment without geographic or local HA. Example 7-1 provides several notable configuration tasks relevant to successful RRI implementation. C3845ISR-A is configured to use dynamic RRI (Line 9) to insert the static routes corresponding to the destination IP address in crypto ACL 101 (Lines 8 and 19) using a next-hop IP address of 200.1.1.2 (C3845ISR-A's IP). These routes will be injected only after an IPsec SA is present in the C3845ISR-B's security association database (SADB). C3845ISR-A uses the RP EIGRP AS 10 to populate this route in the routing table of other networked nodes in Network A. To do this, the RRI-learned routes must be redistributed in to the routing protocol by issuing the redistribute static command provided in Line 13 of Example 7-1. Enhanced Interior Gateway Routing Protocol (EIGRP) requires that the routes be given an EIGRP-specific metric, which is accomplished either by adding a metric for static routes only or by creating a default metric for redistributed routes, as shown in Example 7-1, line 15. RRI will use the destination IP network (192.168.2.0/24) in crypto ACL 101 to populate a static route in the routing table. The next hop for this route will be the IPsec peer defined in the crypto map, 200.1.1.2 (Example 7-1, line 6). Example 7-1. Simple Site-to-Site RRI (Dynamic) Configuration on C3845ISR-A from Figure 7-1
Like C3845ISR-A in Example 7-1, C3845ISR-B is configured to use dynamic RRI to insert the static routes corresponding to the destination IP address in crypto ACL 101 using a next-hop IP address of 200.1.1.1 (C3845ISR-A's IP). Because the router is configured for dynamic RRI (Example 7-2, line 9), these routes will be injected only after an IPsec SA is present in the C3845ISR-B's SADB. C3845ISR-B uses the RP EIGRP AS 10 to populate this route in the routing table of other networked nodes in Network A. To do this, the RRI-learned routes must be redistributed in to the routing protocol. EIGRP requires that the routes be given an EIGRP-specific metric, which is accomplished either by adding a metric for static routes only or by creating a default metric for redistributed routes as shown later. RRI will use the destination IP network (192.168.1.0/24) in crypto ACL 101 to populate a static route in the routing table. The next hop for this route will be the IPsec peer in the crypto map, 200.1.1.1. Example 7-2. Simple Site-to-Site RRI (Dynamic) Configuration on C3845ISR-B from Figure 7-1
The process and examples discussed thus far illustrate the behavior of dynamic RRI, where static routes are dynamically created upon the creation of a Phase 2 IPsec SA. There is another form of RRI, called static RRI, where RRI will create static routes on the IPsec VPN gateway as soon as a crypto map referencing a valid crypto ACL, peer, and transform set is applied to a valid crypto interface. Note that, in the process illustrated in step 1 above, the initial traffic flow triggering the IPsec VPN tunnel negotiation uses a predefined default route injected by C3845ISR-A. In the above process, a predefined route is required, as dynamic RRI will not inject a route for hosts on Network A to use until a Phase 2 SA is created (step 3). Static RRI, however, would have injected routes for Network B in to Network A as soon as the crypto ACL was referenced on a valid crypto map on a valid crypto interface. Therefore, with static RRI, the RRI learned routes could have been used instead of the predefined default route injected in step 1. Examples 7-3 and 7-4 illustrate the configuration and verification of static RRI respectively. Caution Static RRI injects a route before the establishment of a Phase 2 SA, which provides a way for interesting traffic to trigger the establishment of a Phase 2 SA. However, if the IPsec tunnel cannot be established (for example, if the path is severed between the two IPsec tunnel endpoints), traffic destined for the RRI-learned static route could potentially become black-holed, as that static route will always exist in the routing table regardless of the presence of an IPsec (Phase 2) SA in the SADB. Example 7-1, lines 5-9, define the crypto map to be used. The crypto map "chap7-rri-1" applies, at a minimum, the transform set, IPsec peer, and crypto ACL to a crypto interface. In this example, crypto acl 101 defines the traffic to be included in the crypto switching path on this interface. The crypto map also applies the 3DES/MD5-HMAC transform referenced in the transform set "chap7-rri-1" and the peer 200.1.1.2. Static RRI is configured on this crypto map (Example 7-1, line 9), immediately injecting a static route in to the routing table. Once this crypto map has a valid crypto ACL, peer, and transform set, the application of the crypto map to the interface static RRI immediately injects the appropriate static route in to the routing table (see Example 7-4 for verification). EIGRP AS 10 is configured to redistribute static routes, which is required to inject the RRI learned static routes in to the dynamic routing protocol. This effectively injects RRI-learned static routes for Network B into the private network behind C3845ISR-A (Network A). In order for EIGRP to successfully redistribute the static routes, a metric must be defined specific to the redistribute static command, or with the default-metric command as listed below. ACL 101 defines the traffic to be included in the crypto switching path. RRI will use the destination IP address of the crypto ACL defined in the ACL to populate the RRI static route destination in the routing table. RRI will use the IPsec peer defined in the crypto map as the next-hop IP for this route. Example 7-3. Static RRI Configuration
Note from the console output in Example 7-4, lines 18-20, that a Phase 2 SA is not required to inject RRI-learned routes with static RRIthe static route will exist in the routing table regardless of whether IPsec has successfully established Phase 2 SAs or not. Also note from the console output in Example 7-4, line 3, that RRI inserted a static route immediately, prior to the negotiation of IPsec or IKE SAs Example 7-4. Static RRI Verification
Note The default behavior of RRI in Cisco IOS for static crypto maps was to inject static routes as soon as a valid crypto ACL was referenced on a valid crypto interface. For dynamic crypto maps, the default behavior of RRI in Cisco IOS was to inject static routes upon the successful creation of a Phase 2 SA. In IOS versions 12.3(14)T and later, the default behavior for both static and dynamic crypto maps and RRI is to inject static routes upon the successful establishment of a Phase 2 SA. Until this point in the chapter, we have discussed only simple RRI scenarios used to preserve routing table continuity between two networks situated on opposite ends of the IPsec VPN tunnel. We've discussed how this can be done without the use of routing protocol exchanges across the IPsec VPN tunnel using RRI, and the differences between static and dynamic RRI methods. These discussions and examples have yet to include any means of HA. Indeed, all of the methods previously are single-peer definitions with one termination at each end of the tunnel. Chapter 6 discusses several methods of designing local HA in IPsec VPNs, and we will now expand those discussions to include geographic HA methods using the definition of multiple IPsec VPN peers. Figure 7-2 illustrates a variation on Figure 7-1 that adds geographic HA by adding multiple IPsec peering statements on Network_A's IPsec VPN gateway, C3845ISR-A. These peers point to two separate IPsec VPN gateways on Network B, C3845ISR-B and C. (The number steps in Figure 7-2 are discussed later in this section.) Figure 7-2. Geographic HA with RRI and Multiple IPsec PeersThe redundancy added by defining multiple peers on IPsec VPN gateway C3845ISR-A does not radically change the RRI processes we've discussed in the simpler design illustrated in Figure 7-1 and Example 7-1 through Example 7-4. However, it does heighten the need for dynamic RRI over static RRI. This is due to the fact that, when multiple peers are defined, static RRI creates two identical routes to different next-hop IP addresses (the opposite end of the IPsec VPN tunnel). Example 7-5 illustrates static RRI behavior when multiple IPsec peers are defined, in which C3845ISR-A attempts to do per-packet load balancing between multiple next-hops (peers) for the same RRI-learned route. Two peers defined here cause static RRI to inject a static route with two equal cost paths in to the routing table (one valid next-hop to each of the defined peers, 200.1.1.2 and 3, respectively). Because static RRI injects two entries in to the routing table, one corresponding to a valid peer and another corresponding to a dead peer, half of the packets are dropped. This occurs because the router attempts to load-balance between a valid peer and an invalid peer (all traffic forwarded to the invalid peer is subsequently dropped). The connection entries in the crypto engine reflect the packet loss described above. Only half of the fifty packets are encrypted/decrypted using the current active IPsec SA in the crypto engine SADB. The router attempts to forward the other half to an invalid peer, and they are subsequently dropped. Example 7-5. Static RRI with Multiple IPsec Peering Statements
The behavior of Example 7-5 will lead to other unexpected behavior, potentially including the black holing of valid IP traffic to the inactive peer IP address. In order to avoid this behavior, dynamic RRI should be used for highly available IPsec VPN designs where RRI is required. Unlike static RRI, dynamic RRI will install only the static routes with the next hop address of the IPsec peer address resident in the current SADB Phase 2 SA entry. Consider a failover scenario in the network depicted in Figure 7-2. The following numbered list outlines the expected behavior of the IPsec VPN reconvergence process for the dynamic RRI implementation with multiple IPsec peer definitions in Figure 7-2:
While RRI provides continuity for IP routing across IPsec VPN tunnels, it is the use of multiple peering statements on C3845ISR-A that provides the redundancy that lends itself to a highly available design. This design option can be further tuned to yield a greater degree of availability using IKE keepalives or IKE dead peer detection (DPD). For more information on IKE keepalives and DPD, please refer back to previous discussions in Chapter 5. Example 7-6 provides sample configurations for the HA design illustrated in Figure 7-2 using RRI with Multiple IPsec Peer definitions on C3785-A. The successful reconvergence process described above is verified using the diagnostic commands included in Example 7-7. The crypto map in Example 7-7 is configured with redundant peers. Dynamic RRI is configured under the crypto map, injecting static routes for the destination IP address configured in Crypto ACL 101 to the next-hop of the IPsec peer actively populated in the SADB. Unlike Static RRI, this route is populated only upon population of the SADB with the appropriate Phase 2 SA. RRI uses the destination IP defined in crypto ACL 101 (192.168.2.0/24) to populate the static routing table upon successful creation of a Phase 2 SA. Example 7-6. C3845ISR-A Configuration Using Dynamic RRI with Multiple IPsec Peer Definitions
As confirmed by the diagnostic output of Example 7-7, lines 1-4, the crypto engine has no active SADB entries. As such, RRI will not populate the static routing table with the appropriate static routes (Example 7-7, lines 5-6). With static RRI, the configuration of Example 7-6 would populate the routing table with a static route regardless of the state of C3845ISR-A's SADB. Debugging the crypto IPsec process enables us to determine exactly when the RRI-learned static route is populated in the routing table by dynamic RRI (Example 7-7, line 18). A Phase 2 SA is created, also illustrated in Example 7-7 below (lines 21-28). The destination proxy address is the RRI-learned route, and the IPsec peer IP of this SA is the RRI-learned route's next hop. IPsec SAs are now confirmed to exist in C3845ISR's SADB, as shown by the diagnostic output pertaining to C3845ISR-A's crypto engine in Example 7-7, lines 29-34, following. As expected, dynamic RRI created a route for the destination proxy address (192.168.2.0/24) defined in crypto ACL 101 and the IPsec peer address used in the Phase 2 SA (200.1.1.2). Example 7-7. Verifying C3845ISR VPN Failover with Dynamic RRI and Multiple IPsec Peer Definitions
|