ISCW Module 3 Lesson 6

2007 Cisco Systems, Inc. All rights reserved.
ISCW-Mod3_L6 1
Implementing Secure
Converged Wide
Area Networks
(ISCW)
2007 Cisco Systems, Inc. All rights reserved. ISCW-Mod3_L6 2
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

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ISCW Module 3 Lesson 6

Caricato da

Copyright:

Formati disponibili

2007 Cisco Systems, Inc. All rights reserved.

Potrebbero piacerti anche