Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers


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 Peers

In 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 RRI


The following is an explanation of the steps illustrated in Figure 7-1:

1.

Host-A on Network A sends traffic to Server-B on Network B, using a default route injected in to the network by C3845ISR-A. This traffic flow causes C3845ISR-A to initiate an IPsec VPN tunnel negotiation.

2.

C3845ISR-A and B negotiate Phase 1 and then Phase 2 IPsec SAs with one another, successfully creating an IPsec VPN tunnel between Network A and Network B.

3.

C3845ISR-A and B are configured for RRI. When Phase 2 SAs are successfully completed in step 2, C3845ISR-A creates static routes for Network B into its routing table. Likewise, C3845ISR-B injects static routes for Network A into its routing table.

4.

The administrators of Network A and Network B have configured their routing protocol processes on C3845ISR-A and C3845ISR-B to redistribute static routes into the routing protocols for Network A and Network B, respectively. The routing protocols distribute the route injected by RRI by sending RP updates back in to their RP domain.

Note

Routing Protocols (RPs) in this scenario are contained within Networks A and B. There is no exchange of routing protocol updates across the IPsec VPN tunnel established in Step 2 above. Multicast traffic such as the RP traffic used in this example cannot be encrypted in a site-to-site IPsec VPN. Instead, in this example, RRI is used to preserve routing information from Network A to B and vice versa across the IPsec VPN tunnel.

5.

After both RPs have converged to include the RRI-learned routes, C3845ISR-A uses the static route learned by RRI to forward traffic to Server-B to the next hop address of the IPsec VPN peer on C3845ISR-B. C3845ISR-B receives the traffic from C3845ISR-A and forwards it to Server-B, using a route learned by Network_B's IGP.

6.

Server-B forwards the return traffic to C3845ISR-B. C3845ISR-B uses the static route in its routing table learned via RRI in step 3 to forward the return traffic from Server-B to the next hop address of the IPsec VPN tunnel peer IP address on C3845ISR-A. C3845ISR-A receives the return traffic from C3745ISR-B and forwards it to Host_A using a route learned by Network_B's IGP.

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

1  C3845ISR-A#show running-config 2  Building configuration... 3  ! 4  ! 5  crypto map chap7-rri-1 10 IPsec-isakmp 6   set peer 200.1.1.2 7   set transform-set chap7-rri-1 8   match address 101 9   reverse-route 10 ! 11 ! 12 router eigrp 10 13  redistribute static 14  network 10.0.0.0 15  default-metric 1500 10 128 128 1500 16  no auto-summary 17 ! 18 ! 19 access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255


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

1  C3845ISR-B#sh run 2  Building configuration... 3  ! 4  ! 5  crypto map chap7-rri-1 10 IPsec-isakmp 6   set peer 200.1.1.1 7   set transform-set chap7-rri-1 8   match address 101 9   reverse-route 10 ! 11 ! 12 router eigrp 10 13  redistribute static 14  network 10.0.0.0 15  default-metric 1500 10 128 128 1500 16  no auto-summary 17 ! 18 ! 19 access-list 101 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255


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

1  C3845ISR-A#sh run 2  Building configuration... 3  ! 4  ! 5  crypto map chap7-rri-1 10 IPsec-isakmp 6   set peer 200.1.1.2 7   set transform-set chap7-rri-1 8   match address 101 9   reverse-route static 10 ! 11 interface Ethernet0/0 12  ip address 200.1.1.1 255.255.255.252 13  half-duplex 14  crypto map chap7-rri-1 15 ! 16 ! 17 router eigrp 10 18  redistribute static 19  network 10.0.0.0 20  default-metric 1500 10 128 128 1500 21  no auto-summary 22 ! 23 ! 24 access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255


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

1  C3845ISR-A(config)#crypto map chap7-rri-1 10 IPsec-isakmp 2  C3845ISR-A(config-crypto-map)#reverse-route static 3  *Mar  1 00:42:25.431: IPSEC(rte_mgr): VPN Route Added 192.168.2.0 255.255.255.0 via      200.1.1.2 in IP DEFAULT TABLE 4  C3845ISR-A#show crypto isakmp sa 5  dst             src              state         conn-id slot 6 7  C3845ISR-A#show crypto IPsec sa 8 9  interface: Ethernet0/0 10     Crypto map tag: chap7-rri-1, local addr. 200.1.1.1 11 12    protected vrf: 13    local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0) 14    remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0) 15    current_peer: 200.1.1.2:500 16      PERMIT, flags={origin_is_acl,} 17     #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 18     #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 19     #pkts compressed: 0, #pkts decompressed: 0 20     #pkts not compressed: 0, #pkts compr. failed: 0 21     #pkts not decompressed: 0, #pkts decompress failed: 0 22     #send errors 0, #recv errors 0 23 24      local crypto endpt.: 200.1.1.1, remote crypto endpt.: 200.1.1.2 25      path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0 26      current outbound spi: 0 27      inbound esp sas: 28 29      inbound ah sas: 30 31      inbound pcp sas: 32 33      outbound esp sas: 34 35      outbound ah sas: 36 37      outbound pcp sas: 38 C3845ISR-A#show crypto engine connections active 39 40   ID Interface            IP-Address      State  Algorithm       Encrypt  Decrypt 41 C3845ISR-A#show ip route static 42 S    192.168.2.0/24 [1/0] via 200.1.1.2


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 Peers


The 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

1  Host-A#ping 2  ! 3  ! 4  Target IP address: 192.168.2.1 5  ! 6  ! 7  Source address or interface: 192.168.1.1 8  ! 9  ! 10 Sending 50, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: 11 Packet sent with a source address of 192.168.1.1 12 !.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!. 13 Success rate is 50 percent (25/50), round-trip min/avg/max = 12/16/20 ms 14 15 C3845ISR-A#show running-config 16 Building configuration... 17 ! 18 ! 19 crypto map chap7-rri-1 10 IPsec-isakmp 20  set peer 200.1.1.2 21  set peer 200.1.1.3 22  set transform-set chap7-rri-1 23  match address 101 24  reverse-route 25 26 C3845ISR-A#show ip route stat 27 S    192.168.2.0/24 [1/0] via 200.1.1.2 28                     [1/0] via 200.1.1.3 29 30 C3845ISR-A#show crypto engine connections active 31 32   ID Interface            IP-Address      State  Algorithm           Encrypt  Decrypt 33    2 Ethernet0/0          200.1.1.1       set    HMAC_MD5+DES_56_CB        0        0 34 2000 Ethernet0/0          200.1.1.1       set    HMAC_MD5+3DES_56_C        0        25 35 2001 Ethernet0/0          200.1.1.1       set    HMAC_MD5+3DES_56_C        25        0


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:

1.

C3845ISR-A and C3845ISR-B successfully negotiate an IPsec VPN tunnel and inject RRI-learned static routes in to their routing protocol processes for Network A and Network B, respectively.

2.

A failure occurs on the serial link between C3845ISR-A and C3845ISR-B, causing IPsec VPN peers to miss three IKE keepalives and tear down the IPsec VPN tunnel.

3.

C3845ISR-A and B remove the RRI-learned route in step 1 from their routing table.

4.

Host_A continues to send traffic to Server-B, causing C3845ISR-A to initiate Phase 1 SA negotiation with C3845ISR-C.

5.

C3845ISR-A negotiates Phase 1 and 2 SAs with C3845ISR-C sequentially, using the backup IPsec peer definition (C3845ISR-C).

6.

C3845ISR-A and C are both configured for dynamic RRI. Therefore, once the IPsec VPN tunnel has reconverged from the failover in step 2, static routes for Networks A and B are populated in the routing tables of C3845ISR-C and A, respectively, once the crypto-protected address space defined in the crypto ACLs is reflected and populated in the IPsec SADB.

7.

C3845ISR-A and C are configured to redistribute static routes, effectively injecting the RRI-learned static routes in step 5 in to their routing protocols.

8.

Once both RPs have converged to include the RRI-learned routes, C3845ISR-A uses the static route learned by RRI to forward traffic to Server-B to the next hop address of the IPsec VPN peer on C3845ISR-C. C3845ISR-C receives the traffic from C3845ISR-A and forwards it to Server-B, using a route learned by Network_B's IGP.

9.

Server-B forwards the return traffic to C3845ISR-C. C3845ISR-C uses the static route in its routing table learned via RRI in step 3 to forward the return traffic from Server-B to the next hop address of the IPsec VPN tunnel peer IP address on C3845ISR-A. C3845ISR-A receives the return traffic from C3745-C and forwards it to Host_A using a route learned by Network_B's IGP.

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

1  C3845ISR-A#show running-config 2  Building configuration... 3  ! 4  ! 5  crypto map chap7-rri-1 10 IPsec-isakmp 6   set peer 200.1.1.2 7   set peer 200.1.1.3 8   set transform-set chap7-rri-1 9   match address 101 10  reverse-route 11 ! 12 ! 13 access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255


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

1 C3845ISR-A#show crypto engine connections active 2 3   ID Interface            IP-Address      State  Algorithm        Encrypt     Decrypt 4 5  C3845ISR-A#show ip route static 6 7  C3845ISR-A#debug crypto IPsec 8  Crypto IPSEC debugging is on 9  ! 10 ! 11 *Aug 11 08:11:20.307: Crypto mapdb : proxy_match 12         src addr     : 192.168.1.0 13         dst addr     : 192.168.2.0 14         protocol     : 0 15         src port     : 0 16         dst port     : 0 17 *Aug 11 08:11:20.307: IPSEC(crypto_IPsec_sa_find_ident_head): reconnecting with the      same proxies and 200.1.1.2 18 *Aug 11 08:11:20.307: IPSEC(rte_mgr): VPN Route Event create routes for peer or rekeying 19 *Aug 11 08:11:20.307:  IPSEC(rte_mgr): VPN Route Refcount 2 20 *Aug 11 08:11:20.307: IPsec: Flow_switching Allocated flow for sibling 80000006 21 *Aug 11 08:11:20.307: IPSEC(create_sa): sa created, 22   (sa) sa_dest= 200.1.1.1, sa_proto= 50, 23     sa_spi= 0x768C7B66(1988918118), 24     sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2003 25 *Aug 11 08:11:20.307: IPSEC(create_sa): sa created, 26   (sa) sa_dest= 200.1.1.2, sa_proto= 50, 27     sa_spi= 0x5A5D5B9B(1516067739), 28     sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2004 29 C3845ISR-A#show crypto engine connections active 30 31   ID Interface            IP-Address      State  Algorithm           Encrypt     Decrypt 32    6 FastEthernet0/0      200.1.1.1       set    HMAC_MD5+DES_56_CB        0           0 33 2001 FastEthernet0/0      200.1.1.1       set    3DES+MD5                  0           3 34 2002 FastEthernet0/0      200.1.1.1       set    3DES+MD5                  3           0 35 C3845ISR-A#show ip route static 36 S    192.168.2.0/24 [1/0] via 200.1.1.2





IPsec Virtual Private Network Fundamentals
IPSec Virtual Private Network Fundamentals
ISBN: 1587052075
EAN: 2147483647
Year: N/A
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net