iscw module 3 lesson 6

© 2007 Cisco Systems, Inc. All rights reserved.ISCW-Mod3_L6 1

Implementing Secure Converged Wide Area Networks (ISCW)


Module 3 – Lesson 6

Configuring High-Availability VPNs


Module Introduction

Virtual private networks (VPNs) use advanced encryption techniques and tunneling to permit organisations to establish secure, end-to-end, private network connections over third-party networks such as the Internet

Cisco offers a wide range of VPN products, including VPN-optimised routers, PIX security and Adaptive Security Appliances (ASA), and dedicated VPN concentrators. These infrastructure devices are used to create VPN solutions that meet the security requirements of any organisation

This module explains fundamental terms associated with VPNs, including the IP Security protocol, and Internet Key Exchange. It then details how to configure various types of VPN, using various currently available methods


Objectives

At the completion of this sixth lesson, you will be able to:

Describe various methods to provide high availability for IPsec VPNs

Explain the methods used to determine when VPN has failed

Configure systems to provide enhanced availability


High Availability for IOS IPsec VPNs

IPsec-based VPNs provide connectivity between distant sites using an untrusted transport network

Network connectivity consists of links, devices, or paths across networks with unknown topologies. Any of these components can fail, making the VPN inoperable

IPsec VPNs that need high availability (HA) require redundancy in their design and implementation to survive failures

In this lesson, some of the techniques to provide HA will be investigated


Failures

IPsec VPNs can experience any one of a number of different types of failures:

Access link failure

Remote peer failure

Intermediate device failure

Path failure

VPNs should be designed and implemented with redundancy and high-availability mechanisms to mitigate possible failures


Redundancy

The next slide illustrates an implementation of IPsec in which maximum failover is configured. The duplication techniques must also be combined with high-availability mechanisms

Every component has been duplicated so that the solution will survive any possible single failure:

Two access links are used on both ends of the tunnel to mitigate a failure of any access link

The remote site is configured with two remote peers in case any one of the routers fails

Both sites use two VPN gateways to mitigate local device failures

Multiple independent paths are used between remote sites to mitigate an unknown failure anywhere in any of the paths


Redundancy

Common solutions use one or more of these options:

•Two access links to mitigate access-link failures

•Multiple peers to mitigate peer failure

•Two local VPN devices to mitigate device failures

•Multiple independent paths to mitigate all path failures


Failure Detection

The next slide illustrates the use of high-availability mechanisms to detect failures and reroute to secondary paths.

Failures in the IPsec path are typically detected using one of these two mechanisms:

Dead peer detection (DPD), which is a native IKE mechanism similar to the old proprietary IKE keepalives

Any routing protocol running across the IPsec tunnel will detect failures using the hello mechanism of the routing protocol

Detecting failures of local devices can be achieved by using the Cisco-proprietary Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP) or Gateway Load Balancing Protocol (GLBP)

In each case, the failure of one routing device results in a second active routing device taking over with little interruption of traffic


Failure Detection

Native IPsec uses DPD to detect failures in the path and remote peer failure.

Any form of GRE over IPsec typically uses a routing protocol to detect failures (hello mechanism).

HSRP is typically used to detect failures of local devices. VRRP and GLBP have similar failure-detection functionality.


How DPD and Cisco IOS Keepalive Features Work

DPD and Cisco IOS keepalives function based on a timer (often configured for 10 seconds).

Cisco IOS keepalives are always transmitted while periodic DPD will only send keepalives when there is no traffic flowing.

The benefit of Cisco IOS keepalives and periodic DPD is earlier detection of dead peers.

However, Cisco IOS keepalives and periodic DPD rely on periodic messages that have to be sent frequently. The result is communicating peers must encrypt and decrypt more packets, and more traffic flows between peers.


How DPD and Cisco IOS Keepalive Features Work

Rather than use periodic messaging, DPD defaults to an on-demand approach.

With on-demand DPD, messages are sent based on traffic patterns.

For example, if a router has to send outbound traffic and the liveliness of the peer is in question, the router sends a DPD message to query the status of the peer

If a router has no traffic to send, the router never sends a DPD message. If a peer is dead and the router never has any traffic to send to the peer, the router will not find out until the IKE or IPsec security association (SA) has to be renegotiated (the liveliness of the peer is unimportant if the router is not trying to communicate with the peer). However, if the router has traffic to send to the peer, and the peer does not respond, the router initiates a DPD message to determine the state of the peer.


IPsec Backup Peer

DPD and IOS keepalive features can be used in conjunction with multiple peers in the crypto map to allow for stateless failover.

DPD allows the router to detect a dead IKE peer. When the router detects the dead state, the router deletes the IPsec and IKE SAs to the peer.

If multiple peers are configured, the router switches over to the next listed peer for a stateless failover.


IPsec Backup Peer

One HA design option is to use native IPsec and its HA mechanisms:

DPD to detect failures

Backup peers to take over new tunnels when primary peer becomes unavailable


DPD Configuration Example

Router will first try primary peer.

If primary peer is not available or becomes unavailable (DPD failure detection), the router tries backup peers in order as listed in the crypto map.


‘crypto isakmp keepalive’ Command

crypto isakmp keepalive seconds [retries] [periodic | on-demand]

router(config)#

Seconds

Number of seconds between DPD messages; the range is from 10 to 3600 seconds. If you do not specify a time interval, you will receive an error message.

Retries

(Optional) Number of seconds between DPD retries if the DPD message fails; the range is from 2 to 60 seconds. If unspecified, the default is 2 seconds.

Periodic

(Optional) If periodic is included, DPD messages are sent at regular intervals.

On-demand

(Optional) The default behavior and the alternative to periodic messaging. DPD retries are sent only on demand. Note that because this option is the default, the on-demand keyword does not appear in configuration output.


Hot Standby Routing Protocol (HSRP)

Hosts that do not support dynamic router discovery are typically configured with a default gateway (router)

Running a dynamic router discovery mechanism on every host may not be feasible for a number of reasons, including administrative overhead, processing overhead, security issues, or lack of a protocol implementation for some platforms

HSRP provides failover services to these hosts

HSRP is not part of the IPsec or VPN suite of protocols.

HSRP simply provides the basis for more resilient and reliable VPN design.


Hot Standby Routing Protocol (HSRP)

With HSRP, a set of routers work together to present the illusion of a single virtual router to the hosts on the LAN

This set of routers is called an HSRP group or a standby group

HSRP selects a single router from the group that is responsible for forwarding the packets that hosts send to the virtual router

This router is known as the active router

Another router is designated as the standby router

In the event that the active router fails, the standby router assumes the packet-forwarding duties of the active router. Although an arbitrary number of routers may run HSRP, only the active router forwards the packets that are sent to the virtual router


HSRP

HSRP can be used at:

Head-end: Two head-end IPsec devices appear as one device to remote peers.

Remote site: Two IPsec gateways appear as one gateway to local devices.

Active HSRP device uses a virtual IP and MAC address.

Standby HSRP device takes over virtual IP and MAC address when active HSRP device goes down.


HSRP for Default Gateway at Remote Site

All remote devices use virtual IP as the default gateway.

The backup router is only used when the primary router is down.


HSRP for Head-End IPsec Routers

Remote sites peer with virtual IP address (HSRP) of the head-end.

RRI or HSRP can be used on the inside interface to ensure a proper return path.


IPsec Stateful Failover

IPsec VPNs using DPD, HSRP, or IGPs to mitigate failures only provide stateless failover

IPsec stateful failover requires:• Identical hardware and software configurations of IPsec on the

active and standby device• Exchange of IPsec state between the active and standby

device (that is, complete SA information)


IPsec Stateful Failover

Deploying stateful failover for IPsec has restrictions

1. Identical Cisco IOS images are needed.2. Only selected VPN accelerators can be used.3. Intrachassis failover is not supported.4. Inside and outside interfaces must be connected on a

LAN.5. Load balancing is not supported.6. L2TP is not supported.7. IKE keepalives are not supported.8. IPsec idle timers are not supported. 9. A stateful failover crypto map applied to a VRF

interface is not supported. 10. Not compatible or interoperable with the SSP


IPsec Stateful Failover and SSO

IPsec stateful failover works in combination with HSRP and stateful switchover (SSO)

SSO is responsible for synchronising ISAKMP and the IPsec SA database between the HSRP active and standby routers

Reverse Route Injection (RRI) is optionally used to inject the routes into the internal network


IPsec Stateful Failover Example

Configure IPsec to exchange state information between head-end devices.

Enable stateful redundancy.


Using an IPsec VPN to Back Up a WAN Connection

IPsec VPNs can be used as cost-effective and fast backups for an existing WAN.

Switchover options:

Using an IGP (for example, GRE over IPsec or VTI):

Use IGP metrics to influence primary path selection.

Optionally, use HSRP to track PVC status on remote site.

Using floating static routes for VPN destinations


Using an IPsec VPN to Back Up a WAN Connection

IGP used to detect PVC failures

Reroute to GRE over IPsec tunnel

Example Using GRE over IPsec

iscw module 3 lesson 6

Documents