Design Guide | IPsec Fault Tolerance
Optimum end-to-end IPsec networks require fault tolerance in a number of areas both for ingress and egress traffic flows. The diagram below displays-individual components that are susceptible to failure. Design each element with redundancy in mind. Failure components include Backbone network, Access links and IPsec hardware gateway.
IPsec uses an underlying backbone network for endpoint connectivity. It does not deploy its own underlying packet forwarding mechanism and relies on backbone IP packet-routing functions. Usually, the backbone is controlled by 3rd-party provider, ensuring IPsec gateways trust redundancy and high availability methods applied by separate administrative domains.
Adding a second link to terminate IPsec sessions and enabling both links for IPsec termination improves redundant architectures. Access link redundancy requires designers to deploy either Multiple IKE identities or Single IKE identity.
Multiple IKE identity design involves two different peer IP addresses; one peer for each physical access link. IKE identity of initiator is derived from the source IP of the initial IKE message and this will remain the same. Single IKE identity involves one peer neighbor, potentially terminating on a logical loopback address.
Physical Interface Redundancy
Design physical interface redundancy by terminating IPsec on logical interfaces opposed to multiple physical interfaces. Useful when the router has multiple exit points and you do not want the other side to use multiple peers address. Single IPsec session terminating on loopback instead of multiple IPsec sessions terminating on physical interfaces. You still require the crypto map configured on two physical interfaces.
Issue the command to terminate IPsec on the loopback: crypto map VPN local-address lo0
In the event of single physical link failure, Phase 1 and Phase 2 do not converge. Convergence is based on underlying network routing protocol. No IKE convergence occurs if one of the physical interfaces goes down.
Asymmetric Routing & Routing Protocol Convergence
Asymmetric forwarding may occur in multipath environments. In the diagram below, traffic leaves spoke A, creating IPsec tunnel to interface Se1/1:0 on Hub A. Asymmetric traffic occurs when return traffic flows via Se0:0. The resulting effect is new IPsec SA between Se0:0 and Spoke A, introducing additional memory usage on peers. Overcome this by proper routing mechanism and IPsec state replication ( discussed later ).
Design to ensure routing protocol convergence does not take longer than IKE dead peer detection. Routing protocols should not introduce repeated disruptions to IPsec processes. If you have control of the underlying routing protocol, deploy fast convergence techniques so that routing protocols converge faster than IKE detects a dead peer.
IPsec Hardware Gateway
Redundant gateway involves a second IPsec gateway in standby mode. It does not have any IPsec state or replicate IPsec information between peers. Because either gateway may serve as active gateway for spoke return traffic you may experience asymmetric traffic flows. Also, failure of Hub peer gateway, all traffic between sites drop until IKE and IPSec SAs are rebuilt on the standby peer.
A common approach to overcome asymmetric routing is to deploy routing mechanism at gateway nodes. IPsec high availability can be incorporated with HSRP, which pairs two devices with a single VIP address. VIP address terminates IPsec tunnel. HSRP and IPsec work perfectly fine as long as the traffic is symmetric.
Asymmetric traffic occurs when the return traffic does not flow via the active HSRP device. To prevent this, enable HSRP on the other side of IPsec peers, resulting in Front-end / Back-end HSRP design model. Or deploy Reverse Route Injection ( RRI ) and static routes are injected only by active IPsec peer.
You no longer need Dead Peer Detection ( DPD ) as you are using VIP for IPsec termination. In the event of node failure, IPsec peer does not change.
A different method to resolve the asymmetric problem is to implement Reverse Route Injection ( RRI ).
Reverse Route Injection
RRI is a method that synchronizes return routes for the spoke to active gateway. The idea behind RRI is to make routing decision dependant of IPsec state. For end-to-end reachability, route to “secure” subnet must exist with a valid network hop.
RRI inserts a route to the “secure” subnet in the RIB and associates it with an IPsec peer. It injects based on Proxy ACL; matches destination address in the proxy ACL.
RRI injects a static route for the upstream network.
HSRP’s or RRI IPsec is limited in the sense that it does not carry any state between the two IPsec peers. A better high-availability solution is to carry state ( Security Association Database ) between the two gateways; offering stateful failover.