Managing Path Symmetry

IPSec is a stateful protocol, meaning that it relies on the maintenance of a state table (SADB) and security associations (SAs) to process information in the crypto switching path. It is therefore important to make sure that traffic is sent to, and received from, the appropriate tunnel termination points present in Phase 2 SAs. Figure 5-11 illustrates a situation in which the IPSec VPN tunnel is broken due to path asymmetry.

Figure 5-11. IPSec VPN Failure Due to Path Asymmetry

In Figure 5-11, a failure occurs on the IPSec tunnel between IPSec_A and IPSec_B due to asymmetric routing. In this case, all RP traffic is sent in the clear, resulting in one contiguous RP domain. When a failure occurs between INET_A and IEDGE_B1, the routing protocol reconverges in a manner that causes asymmetric routing between Site_A and Site_B. Specifically, after the failure, resources on Site_A chooses Path #1 to Site_B, while Site_B chooses Path #2. All interfaces on both IPSec_A and IPSec B are configured for IPSec, but there is a firewall prohibiting IPSec reconvergence along Path #2. This example illustrates just one scenario in which IPSec VPN tunnels can be broken when asymmetric paths exist between tunnel endpoints. We will discuss several methods for guaranteeing path symmetry in an IPSec VPN, including the tuning of routing protocol for path symmetry and the role of HSRP-based IPSec tunnel termination in path symmetry.

One way to resolve issues with IPSec reconvergence issues due to path asymmetry is to alter the routing protocol metrics to ensure that the IPSec VPN is originated and terminated on the appropriate source and destination tunnel endpoints, respectively. Figure 5-12 illustrates a situation in which the adjustment of routing protocol metrics on IEDGE_B2 and IEDGE_A2 help to avert IPSec issues due to a routing protocol reconvergence issues upon a serial link failure between INET_A1 and IEDGE_B1.

Figure 5-12. Adjusting RP Metrics to Avoid Issues with IPSec and Path Asymmetry

In Figure 5-12, the IEDGE routers at both Site_A and Site_B are configured to forward traffic to the next hop of IPSec_A1 and IPSec_B1, respectively, unless the IPSec VPN gateways are down. This configuration helps to avoid the path symmetry problems experienced previously, as illustrated in Figure 5-11, regardless of any topological changes in between Site_A and Site_B that may cause a shift in the Layer 3 paths between IPSec VPN gateways.

Note

There are many ways to instantiate the RP metric changes to achieve the behavior discussed above and illustrated in Figure 5-12static routes would be one option, policy-based routing could be another, and hard-coded routing protocol metrics yet another. The specific methods of RP tuning, however, are outside of the scope of this discussion.