Vendor Interoperability Impact on Path Availability

It is critical in an IPSec HA design that the IPSec VPN gateways and intermediate routers between the two gateways are capable of supporting and managing the availability of the path which the IPSec VPN tunnel traverses. Recall from our discussion of IPSec HA design in Chapter 5 that this is a critical component of path availability: the ability to ensure the availability of the path between two encrypted domains. In Chapter 7, "Solutions for Geographic Site-to-Site High Availability," we explored several mechanisms for addressing path availability design considerations within the context of IPSec HA. This section introduces several barriers that IPSec vendor interoperability presents to these design solutions and discusses some additional design alternatives that may be better suited to the vendor-diverse environment in which these limitations exist:

1.	Limited support for selected routing protocols
2.	Lack of support for reverse route injection
3.	Lack of support for GRE tunnels

IPSec HA Design Considerations for Platforms with Limited Routing Protocol Support

As a Layer 3 VPN technology, IPSec relies on underlying Layer 3 information to establish and maintain the IPSec VPN tunnel. Although IPSec tunnels can be established on point-to-point links, such as a serial link between a branch router and a headend router used for IPSec VPN tunnel aggregation, one key benefit of IPSec is that it can be used to provide data confidentiality between two endpoints which are multiple hops away.

One such common IPSec VPN topology that is used to encrypt communications between networks multiple hops apart from one another is that of an RAVPN deployment, in which IPSec VPN clients encrypt communication from remote network across an ISP to a VPN concentrator at the enterprise campus or internet edge De-Militarized Zone (DMZ). IPSec is also used to provide data confidentiality across routed environments in extranet deployments. In this section, we will explore the impact of limited RP support on site-to-site IPSec VPN extranet deployment, as depicted in Figure 8-3.

Figure 8-3. Lack of RP Support and the Impact on Site-to-Site IPSec VPN High-Availability

Note

Common IPSec VPN deployments such as remote-acess VPN (RAVPN) and extranet deployments are presented in greater detail in Chapter 4, "Common IPsec VPN Issues." Additionally, RAVPN High Availability is discussed in detail, including configuration and design options, in Chapter 12, "Solutions for Handling Dynamically Addressed Peers."

Figure 8-3 shows a common deployment of IPSec VPNs in an extranet environment. In this scenario, the enterprise offers connectivity to its extranet partners over the internet. As such, all extranet communications between the enterprise and its extranet partners are spanned across multiple Layer 3 hops. This design requires that the extranet partner's IPSec gateways support adequate RP capabilities in order to establish and maintain the IPSec VPN tunnel.

Consider the scenario in which an extranet partner's IPSec VPN gateway does not support the appropriate RP capabilities required of this deployment. Because the IPSec VPN gateway is only capable of sending IP traffic, including all IPSec control plane traffic, to networks on the same directly connected segment, that IPSec VPN gateway is incapable of forwarding control plane traffic to the appropriate Layer 3 IPSec tunnel termination point.

Routing Protocol support on the extranet edge routers concentrating inbound IPSec tunnels from the extranet partners is also critically important. Without the additional Layer 3 awareness that routing protocols provide, the aggregation routers will not be able to forward IPSec and Internet Security Association and Key Management Protocol (ISAKMP) traffic to the appropriate destination extranet-partner IPSec gateways. Static routes, if supported on the gateway, provide some relief from this limitation. However, they do not address scalability and management issues that arise on the aggregation routers, since administrators must manually configure routes each time a partner residing on a different IP network is added to the extranet. Additionally, the manual configuration required when using static routes for this type of deployment reduces the usefulness of dynamic crypto maps, since the manual addition the static routing entries themselves add additional administration to the IPSec aggregation points (static routes and static IPSec peers can be added during the same configuration window).

In many situations, lack of RP support can be addressed by the addition of a static default route (if supported) pointing to an external router that can handle the additional required RP responsibilities. One such example in which this is common is when a PIX firewall is used to terminate IPSec VPN connections. Regardless of the workaround used to add the required Layer 3 capabilities, it is important that the Layer 3 infrastructure supporting the IPSec VPN tunnel is scalable, functional, and can quickly adapt to changes forcing reconvergence within the IPSec VPN tunnel itself.

IPSec HA Design Considerations for Lack of RRI Support

Reverse Route Injection (RRI) enables IPSec VPN gateways to dynamically inject VPN routes into their local protected routed domain upon the establishment of a Phase 2 SA. RRI therefore serves as an effective method for preserving dynamic routing information for unicast traffic across an IPSec VPN tunnel.

In Figure 8-4, there must be a means to exchange RP information between the two routed domains on the opposite ends of the IPSec VPN tunnel (routed domains A and C).

Figure 8-4. IPSec Vendor Interoperability and Lack of RRI Support.

Recall from our previous discussions that there are several options for doing so, including:

1.	Injection of static routes or a single default route
2.	Cleartext exchange of routing protocols between A, B, and C
3.	Encrypted routing protocols using IPSec+GRE
4.	Reverse Route Injection

Figure 8-4 focuses on the last of these design options. Vendor interoperability and the impact of the lack of RRI support is illustrated when Host_A4 on segment A attempts to reach Server_B4 on segment C on the opposite end of the IPSec VPN tunnel. Because segment A's VPN gateways (IPSec-GW-A4 and IPSec-GW-B4) do not support RRI (and are not equipped nor configured for any other means of routing information propagation), all the routing tables on all other nodes within segment A will not contain any of the routes for segment B. Therefore, Host_A's communications to Server_B will fail at the first Layer 2/3 boundary it encounters within segment A.

RRI would solve this problem by dynamically creating a static route based on the protected address space populated in IPSec-GW-A4's SADB upon successful negotiation of a Phase 2 SA. These static routes can then be redistributed into segment A's RP to populate the routing tables of the remaining Layer 3 nodes within the segment.

Note

RRI is introduced in greater detail in Chapter 5, "Designing for High Availability." For more information on Local and Geographic HA design considerations, please refer to Chapters 6, "Solutions for Local Site-to-Site High Availability," and 7, "Solutions for Geographic Site-to-Site High Availability," respectively.

IPSec HA Design Considerations for Lack of Generic Routing Encapsulation (GRE) Support

IPSec+GRE provides a means to exchange encrypted multicast RP updates across an IPSec VPN tunnel, thereby serving as an effective path availability design alternative to RRI. Additionally, IPSec+GRE designs provide effective support for native multicast traffic flows themselves, while native RRI does not, thereby making IPSec+GRE the compelling design alternative where multicast traffic must be transmitted with data confidentiality in the crypto switching path.

For the purposes of our discussion here, we will consider an extreme case in which GRE encapsulation is not supported at all on a VPN gateway terminating an IPSec tunnel (shown in Figure 8-5).

Figure 8-5. IPSec Vendor Interoperability and Lack of GRE Support.

Figure 8-5 illustrates a scenario in which multicast traffic, including RP updates, are exchanged between two extranet partners. Therefore, double-encapsulation (IPSec+GRE) is used to support the encrypted exchange of routing protocol updates and multicast application traffic between the two partners. The failure occurs on Extranet Partner B's IPSec VPN gateway, which is capable of handling ESP encapsulation and decapsulation but is unable to handle the GRE encapsulation and decapsulation.

There are varying degrees of support for GRE on IPSec VPN gateways affecting the performance of the solution. Therefore, it is important to understand the impact of all of the data permutations to be included in the switching path when selecting an IPSec gateway.

Tip

GRE offload scenarios are a relatively common design alternative for IPSec+GRE deployments in which there is inadequate GRE performance or support capabilities on the IPSec VPN gateway itself. For more information on IPSec+GRE with GRE offload deployments, please refer to Chapter 10, "Further Architectural Options for IPsec."