Ipsec troubleshooting

In this part I will be discussing the following problem scenarios----

• IKE SA not established
• IPSec SA’s not established
• MTU/Fragmentation Issues

Problem Scenario 1: No IKE SAs

If we are unable to establish IPSec tunnel from Branch location to  Hub location

Check for Routing. Ping the Branch (using HUB’s IKE endpoint)

HUB# ping ip 40.10.1.1 source 30.3.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 40.10.1.1, timeout is 2 seconds:
Packet sent with a source address of 30.3.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Check for IKE SA

HUB# sh crypto isakmp sa 
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
30.3.1.1        40.10.1.1       MM_NO_STATE          0    0 ACTIVE (deleted)

IPv6 Crypto ISAKMP SA

Use IKE Debugs to troubleshoot  [ debug crypto isakmp ]

Problem Scenario 1a: 
No IKE SAs

ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP:      encryption 3DES-CBC
ISAKMP:      hash SHA
ISAKMP:      default group 2
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (basic) of 7200
ISAKMP:(0):Encryption algorithm offered does not match policy!
ISAKMP:(0):atts are not acceptable. Next payload is 0

ISAKMP:(0):Checking ISAKMP transform 1 against priority 65535 policy
ISAKMP:      encryption 3DES-CBC
ISAKMP:      hash SHA
ISAKMP:      default group 2
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (basic) of 7200
ISAKMP:(0):Encryption algorithm offered does not match policy!ISAKMP:(0):atts are not acceptable. Next payload is 0

ISAKMP:(0):no offers accepted!ISAKMP:(0): phase 1 SA policy not acceptable! (local 30.3.1.1 remote 40.10.1.1)

Check the IKE Policies

HUB# sh crypto isakmp policy 

Global IKE policy
Protection suite of priority 10
         encryption algorithm:    AES - Advanced Encryption Standard (128 bit keys).
         hash algorithm:            Secure Hash Standard
         authentication method:  Pre-Shared Key
         Diffie-Hellman group:   #2 (1024 bit)
         lifetime:                        7200 seconds, no volume limit
Default protection suite
         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).

                                                                                                                                                            

So once we change the encryption algorithm at spoke side to aes, phase 1 will come up.

Problem Scenario 1b:

No IKE SAs

ISAKMP:(1017): sending packet to 40.10.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH
ISAKMP:(1017):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(1017):Old State = IKE_R_MM3  New State = IKE_R_MM4

ISAKMP (0:1017): received packet from 40.10.1.1 dport 500 sport 500 Global (R) MM_KEY_EXCH
ISAKMP: reserved not zero on ID payload!
%CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 40.10.1.1 failed its sanity check or is malformed

It means we have a mismatch in pre-shared key, on correcting it our IKE SA should come up.

HUB# sh cry isa sa 
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
30.3.1.1        40.10.1.1       QM_IDLE           1019    0 ACTIVE

Problem Scenario 2: No IPSec SAs

If you notice that there is  no traffic is being received through the IPSec tunnel

IKE SAs exist, but no IPSec SAs

Check for IPSEC SA (look for inbound and outbound SPI’s)

HUB# sh crypto ipsec sa  peer 40.10.1.1

interface: GigabitEthernet0/1
     Crypto map tag: CMAP, local addr 30.3.1.1

    protected vrf: (none)
    local  ident (addr/mask/prot/port): (3.1.1.0/255.255.255.0/0/0)
    remote ident (addr/mask/prot/port): (4.1.1.0/255.255.255.0/0/0)
    current_peer 40.10.1.1 port 500
      PERMIT, flags={origin_is_acl,}
     #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
     #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #send errors 0, #recv errors 0

      local crypto endpt.: 30.3.1.1, remote crypto endpt.: 40.10.1.1
      path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
      current outbound spi: 0x0(0)

      inbound esp sas:
      inbound ah sas:

      outbound esp sas:
      outbound ah sas:
HUB#

Use IPSec Debugs to troubleshoot [ debug crypto ipsec ]

Problem Scenario 2a: No IPSec SAs

ISAKMP (0:1022): received packet from 40.10.1.1 dport 500 sport 500 Global (R) QM_IDLE     

ISAKMP:(1022): processing SA payload. message ID = -549695704
ISAKMP:(1022):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_3DES
ISAKMP:   attributes in transform:
ISAKMP:      encaps is 1 (Tunnel)
ISAKMP:      SA life type in seconds
ISAKMP:      SA life duration (basic) of 1800
ISAKMP:      SA life type in kilobytes
ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0 
ISAKMP:      authenticator is HMAC-SHA
ISAKMP:(1022):atts are acceptable.

IPSEC(validate_proposal_request): proposal part #1,
   (key eng. msg.) INBOUND local= 30.3.1.1, remote= 40.10.1.1, 
     local_proxy= 3.1.1.0/255.255.255.0/0/0 (type=4), 
     remote_proxy= 4.1.1.0/255.255.255.0/0/0 (type=4),
     protocol= ESP, transform= NONE  (Tunnel), 
     lifedur= 0s and 0kb, 
     spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
Crypto mapdb : proxy_match
         src addr     : 3.1.1.0
         dst addr     : 4.1.1.0
         protocol     : 0
         src port     : 0
         dst port     : 0
IPSEC(ipsec_process_proposal): transform proposal not supported for identity: 
     {esp-3des esp-sha-hmac }
ISAKMP:(1022): IPSec policy invalidated proposal with error 256ISAKMP:(1022): phase 2 SA policy not acceptable! (local 30.3.1.1 remote 40.10.1.1)

Check the IPSec Transform Sets

HUB# sh cry ips transform-set 
Transform set TS: { esp-aes esp-sha-hmac  } 
    will negotiate = { Tunnel,  },

On Correcting encryption algorithm in tranform-set , tunnel should come up.

Problem Scenario 2b: No IPSec SAs

Check the Crypto ACLs

HUB# sh access-list SPOKE-10-ACL
Extended IP access list SPOKE10-ACL
     10 permit ip 3.1.1.0 0.0.0.255 5.1.1.0 0.0.0.255
HUB#

On Correcting crypto access-list , tunnel should come  up.

Problem Scenario 3: Anti-Replay Issues

If you notice that some of the  applications are losing intermittent traffic, or that Voice quality  through tunnel is bad.

Check if the IPSec SA is showing anti-replay drops

HUB# sh cry ips sa peer 40.10.1.1 detail
interface: GigabitEthernet0/1
     Crypto map tag: CMAP, local addr 30.3.1.1

    protected vrf: (none)
    local  ident (addr/mask/prot/port): (3.1.1.0/255.255.255.0/0/0)
    remote ident (addr/mask/prot/port): (4.1.1.0/255.255.255.0/0/0)
    current_peer 40.10.1.1 port 500
      PERMIT, flags={origin_is_acl,}
     #pkts encaps: 2900, #pkts encrypt: 2900, #pkts digest: 2900
     #pkts decaps: 1909, #pkts decrypt: 1909, #pkts verify: 1909
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
     #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
     #pkts invalid prot (recv) 0, #pkts verify failed: 0
     #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
     #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
     ##pkts replay failed (rcv): 1000    #pkts internal err (send): 0, #pkts internal err (recv) 0

      local crypto endpt.: 30.3.1.1, remote crypto endpt.: 40.10.1.1
      path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
      current outbound spi: 0xC37422AA(3279168170)

      inbound esp sas:
       spi: 0x135E76B1(324957873)
         transform: esp-3des esp-sha-hmac ,
         in use settings ={Tunnel, }
         conn id: 41, flow_id: SW:41, crypto map: CMAP
         sa timing: remaining key lifetime (k/sec): (4419198/860)
         IV size: 8 bytes
         replay detection support: Y
        Status: ACTIVE

Default IPSec Anti-Replay window is 64

Packets received outside the window are dropped

Re-ordering of packets could happen due to QoS on the encrypting router (Spoke) or in the Transit Network

In current Cisco IOS versions, the Anti-Replay window can be increased up to 1024, or diabled altogether

                 crypto ipsec security-association window-size

                 crypto ipsec security-association replay disable

Not recommended to disable anti-replay; first try to fix the QoS issue in the network or encrypting router; give better QoS to Voice traffic, or use crypto LLQ; then try to increase the anti-replay window size.

Wireless Hacking

Understanding Wireless Technology

According to Wikipedia,

Wireless communication is the transfer of information without the use of wires. The distances involved may be short (a few meters as in television remote control) or long (thousands or millions of kilometers for radio communications). The term is often shortened to "wireless".

Wireless Network Setup:

Generally a wireless network consists of three components. :

• 802.11a/b/g/n devices.
• Wireless Access Points.
• Optionally, the network might contain an additional gateway which acts as an interface to the internet

Wireless Standards:

• 802.11 (legacy) : First wireless standard. Created in 1997. It is obsolete now. Speeds of 1,2 Mbps are supported.
• 802.11a: Created in 1999, Supports speeds of 6, 9, 12, 18, 24, 36, 48, 54 Mbps.
• 802.11b: Also created in 1999, Supports speeds of 5.5, 11 Mbps.
• 802.11g: Created in 2003, Supports speeds of 6, 9, 12, 18, 24, 36, 48, 54 Mbps.
• 802.11n: Created in 2009, it can supports speeds upto 150Mbps.

Types of Wireless Network Layouts:

• Peer-to-peer – Also called adhoc wireless LAN, is a network where stations communicate only peer to peer (P2P). There is a lack of a controlling base.
• Access Points – In this scenario, the wireless network represents a client-server model in which special Access Points act as central server onto which multiple wireless clients can connect
• Wireless distribution system – Wireless Distribution System is a system that enables the wireless interconnection of access points. It allows a wireless network to be expanded using multiple access points without the need for a wired backbone to link them, as is traditionally required.
• Extension to a wired network – This concept involves extending a wired network over wireless. An example could be wifi routers attached with ADSL modems.

Detecting Wireless Network:

Detecting a wireless network can be pretty straight forward, if the wireless AP is not set as hidden. The following ways can be used to detect wireless networks.

• Using operating system wireless monitors.
• Using handheld devices (such as wifi enabled cellphones). Also special software can be used on top of those cellphones which further aid this. (eg. WifiEye and Barbelo).
• Using passive scanners (Tool: Kismet, KisMAC).
• Using active beacon scanners (Tool: NetStumbler, MacStumbler, iStumbler).

Wireless Security standards:

The issues with the security of SSID led to the development and usage of wireless protocols and standards. The important standards are:

• Wired Equivalent Privacy (WEP)
• Wi-Fi Protected Access (WPA)
• Wi-Fi Protected Access v2 (WPA2)

Wireless Equivalent Privacy (WEP):

• WEP is a component of the IEEE 802.11 WLAN standards. Its primary purpose is to provide for confidentiality of data on wireless networks at a level equivalent to that of wired LANs.
• WEP accomplished eavesdropping by encrypting data with the RC4 encryption algorithm.
• WEP, however is weak and can be broken with minimum efforts.

Wi-Fi Protected Access (WPAv1):

• WPAv1 comes in two variants, WPA Enterprise and WPA PSK
• WPA Enterprise provides RADIUS based authentication using 802.1x.
• WPA Personal or PSK uses a pre shared key.

Wi-Fi Protected Access (WPAv2):

• WPAv2 also comes in two variants, WPA Enterprise and WPA PSK
• WPA Enterprise provides RADIUS based authentication using 802.1x.
• Difference b/w WPAv1 and WPAv2 is the fact that WPAv2 has to mandatorily include AES-CCMP algorithm. It reinforces the security of WPAv2.

MAC Sniffing & ARP Spoofing:

• Since MAC Address must appear in the clear even when WEP is enabled, they can be easily sniffed.
• An attacker can spoof his MACaddress as any of the available and connected MAC address and bypass MAC based restrictions.
• Using simple packet-capturing software, anyone can identify a valid MAC address using one packet. Spoofing MAC addresses is very easy.
• To perform a spoofing attack, an attacker must set up an access point (rogue) near the target wireless network or in a place where a victim may believe that wireless Internet is available.

Denial-of-Service attacks:

• Denial of service attacks can be unleashed on WLANs.
• Since WLANs send information in predetermined channels and frequencies, DOS attacks can be done when noise is broadcasted over same channels.

Man-in-the-Middle Attack( MITM):

Two types of MITM:

Eavesdropping (mostly passive)

• Possible when attacker has access to network traffic.
• Very dangerous when the victim is not using any additional security mechanism such as TLS, HTTPS. SSH etc.

Manipulation (mostly active)

• An active process in which attacker tries to manipulate traffic so that he can capture it.
• ARP poisoning enables these attacks.

Fake Access Points:

• A fake AP is a honeypot, which is a fake access point made to attract hackers and other wireless intruders in order to collect information about them.
• When a wireless client looks for a wireless connection, it can be lured into connecting to fake or rouge AP’s with lucrative names such as “free internet” etc.
• Once connected to the AP, the victim exposes his machine to the attacker, which can use vulnerabilities to attack services running on the victim.
• Also, one approach is to provide internet to the victim, and dumping all the traffic.
• Karmetasploit is an excellent metasploit module, designed for setting up fake AP’s and automatically exploiting them.

How does WEP work?

WEP uses secret keys to encrypt data. Both AP and the receiving stations must know the secret keys.

There are two kinds of WEP with keys of either 64bits or 128bits. The longer key gives a slightly higher level of security (but not as much as the larger number would imply). In fact the user keys are 40bits and 104bits long, the other 24bits in each case being taken up by a variable called the Initialization Vector (IV).

When a packet is to be sent it is encrypted using a combination of the IV and the secret key. The IV is different (in theory) for each packet, while the secret key is fixed. The resulting packet data looks like random data and therefore makes the original message unreadable to an outsider not knowing the key. The receiving station reverses the encryption process to retrieve the message in clear text.

What's wrong with WEP?

IV values can be reused

In fact the standard does not specify that the value needs to change at all. Reusing keys is a major cryptographic weakness in any security system.

IV length is too short

24 bit keys allow for around 16.7 million possibilities. Sounds a lot, but on a busy network this number can be achieved in a few hours. Reuse is then unavoidable.

Some manufacturers use ’random’ keys. This is not the best way to ensure against reuse. A better solution is to start with a key and increment by one for each subsequent key. Unfortunately many devices revert to the same value at start up and then follow the same sequence providing lots of duplicate values for hackers to work on.

Weak keys are susceptible to attack

Certain keys value combinations, ’Weak IVs’, do not produce sufficiently random data for the first few bytes. This is the basis of the highly publicized attacks on WEP and the reason that keys can be discovered.

Manufacturers often deliberately disallow Weak IV values. This is good in that it reduces the chances of a hacker capturing weak keys, but also has the effect of reducing the already limited key possibilities further, increasing the chance of reuse of keys.

Master keys are used directly

From a cryptographic point of view using master keys directly is not at all recommended. Master keys should only be used to generate other temporary keys. WEP is seriously flawed in this respect.

Key Management and updating is poorly provided for

Administration of WEP keys is not well designed and difficult to do on large networks. Users tend to change keys very infrequently which gives a potential hacker lots of time to collect enough packets to launch an attack.

Message integrity checking is ineffective

WEP does have a message integrity check but hackers can change messages and recompute a new value to match. This makes the checking ineffective against tampering.

What's New in WPA (Wi-Fi Protected Access)

WPA is wireless security with greater protection than WEP. Most wireless networks should use either WEP or WPA. WPA-PSK is not much more difficult to configure than the older WEP, but is not available on some older products. All computers, access points, and wireless adapters must use the same type of security. See your user manuals for configuration instructions.

WPA operates in either WPA-PSK mode (aka Pre-Shared Key or WPA-Personal) or WPA-802.1x mode (aka RADIUS or WPA-Enterprise). In the Personal mode, a pre-shared key or passphrase is used for authentication. In the Enterprise mode, which is more difficult to configure, the 802.1 x RADIUS servers and an Extensible Authentication Protocol (EAP) are used for authentication. The enhanced WPA2 uses Advanced Encryption Standard (AES) instead of Temporal Key Integrity Protocol (TKIP) to provide stronger encryption mechanism.

Advantages of WPA

• Provides extremely strong wireless security for the 2003 computing environment.
• Adds authentication to WEP's basic encryption.
• Has backward compatible WEP support for devices that are not upgraded.
• Integrates with RADIUS servers to allow administration, auditing, and logging.

Disadvantages of WPA

• Except when using with the preshared key (WPA-PSK), complicated setup is required, unsuitable for typical home users.
• Older firmware usually will not be upgraded to support it.
• Incompatible with older operating systems such as Windows 95.
• Greater performance overhead than WEP.
• Remains vulnerable to Denial of Service attacks.

Facts About WPA:

• To use WPA, all computers, access points, and wireless adapters must have WPA software.
• WPA was introduced in 2003. To run WPA between two computers both must have WPA software, and all access points and wireless adapters between them, as well. Equipment older than 2003 will often not be upgradable.

WPA has significant advantages over WEP:

• An encryption key differing in every packet. The TKIP (Temporal Key Integrity Protocol) mechanism shares a starting key between devices. Each device then changes their encryption key for every packet. It is extremely difficult for hackers to read messages — even if they've intercepted the data.
• Certificate Authentication (CA) can be used, blocking a hacker's access posing as a valid user.
• WPA computers will communicate with WEP encryption, if they cannot use WPA with a particular device.
• A Certificate Authority Server is part of the recommended configuration, to allow WPA computers assurance that the computers with whom they share keys are who they claim.
• Since WPA adds to packet size, transmission takes longer. The encryption and decryption are slower for devices using software, rather than dedicated WPA hardware.

The EAP types supported by WPA-Enterprise are

• EAP-TLS
• EAP-TTLS/MSCHAPv2
• PEAPv0/EAP-MSCHAPv2
• PEAPv1/EAP-GTC (Cisco-based implementation)
• EAP-SIM

WEP Cracking:

For cracking WEP airmon-ng,airodump-ng and aircrack-ng package are used in linux based system.

WEP Cracking works in the following manner

• First, the wireless card is put to the monitoring mode, using which raw packets can be dumped.
• A lot of interesting packets are needed, so in a low volume network, packet injection is done to increase the interesting packet numbers.
• Once the required number of packets are achieved, the problems with the implementation of WEP are exploited, which is primarily with the implantation of the RC4 Algorithm to encrypt the packets.

Redundant ISP links for an ASA

setup Redundant IPSEC VPN connections to leverage Redundant ISP links for an ASA (the logic and procedure is the same for IOS routers, except for change in command syntaxes for routing, crypto maps and crypto pre-shared keys).

To achieve this kind of VPN redundancy, we need to configure the following:

A)   Setup ISP redundancy with for example, SLA monitoring

B)   Setup the VPN on the ASA to use primary and secondary ISP links for VPN redundancy

C)   Setup the remote VPN endpoints to use the headend ASA’s primary and secondary ISP links as VPN peers (whichever is active)

Let’s look into configuring these stages in detail:

(Please refer to the attached network diagram, the config examples discussed below are based on this)

1. We need to setup a way to monitor the interfaces as to when the connectivity through primary ISP link goes down and then fallback to a backup ISP link. This is possible using SLA monitoring, as shown in the section below. With this, we will be configuring the ASA to switch to Backup ISP interface, when the primary ISP is down and fallback to primary when it comes back up.

interface Ethernet0/0
  nameif primary
  security-level 0
  ip address 172.16.10.1 255.255.255.0
!
interface Ethernet0/1
  nameif backup
  security-level 0
  ip address 172.16.20.1 255.255.255.0

route primary  0.0.0.0 0.0.0.0 172.16.10.10 1

route backup   0.0.0.0 0.0.0.0 172.16.20.10 254

sla monitor 123
 type echo protocol ipIcmpEcho 10.0.0.1 interface outside
 num-packets 3
 frequency 10

sla monitor schedule 123 life forever start-time now

track 1 rtr 123 reachability

Here you can find more details on the SLA monitoring configuration (I have not discussed this in detail here since our requirement is more towards configuring VPN) :

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00806e880b.shtml

2. After we configure the Redundant or Backup links, we can build the crypto config to leverage this ISP redundancy to achieve VPN redundancy over primary and backup interface. Here are the required configurations:

access-list nonat extended permit ip 192.168.101.0 255.255.255.0 192.168.102.0 255.255.255.0

access-list nonat extended permit ip 192.168.101.0 255.255.255.0 192.168.103.0 255.255.255.0

nat (inside) 0 access-list nonat

(nat exemption for VPN traffic)

nat (inside) 1 192.168.101.0 255.255.255.0

global (primary) 1 interface

global (backup) 1 interface

(We need to apply the global commands for both primary and secondary interfaces so that the active interface can be used for port translations, for inside users to go to internet.)

crypto map VPN-map 10 match address crypto-acl

crypto map VPN-map 10 set peer 10.10.10.1

crypto map VPN-map 10 set transform-set ESP-AES-SHA

crypto map VPN-map interface Primary

crypto map VPN-map interface Backup

(You would usually apply the crypto map to “Primary” interface, now we need to apply it to the “Backup” interface as well. With this, when the “Primary” interface is down <i.e if primary ISP link is down>, the crypto tunnels are formed through the Backup interface).

3. The third part of the setup is the configuration of crypto map on the other end of the tunnel to utilize the vpn redundancy at the headend. Now given that we are using two interfaces “Primary” and “Secondary”, we need to mention these as peer Ip addresses on the remote end, as shown below:

crypto map Outside_map 20 match address crypto-acl

crypto map Outside_map 20 set peer 10.10.10.1   20.20.20.1                     
          (Which means, the primary set peer value is 10.10.10.1, and if is down, device will try for 20.20.20.1 ip address for tunnel)

crypto map Outside_map 20 set transform-set ESP-3DES-MD5

crypto map Outside_map 65535 ipsec-isakmp dynamic Outside_dyn_map

After this, we need to setup pre-shared keys for ip addresses of both primary and secondary ISP interfaces on the Headend ASA, since when a connection is needed to either primary or secondary interface ip address, we should have a tunnel-group with matching pre-shared key to complete the ISAKMP negotiation:

tunnel-group 172.16.10.1 type ipsec-l2l

tunnel-group 172.16.10.1 ipsec-attributes

  pre-shared-key *

tunnel-group 172.16.20.1 type ipsec-l2l

tunnel-group 172.16.20.1 ipsec-attributes

  pre-shared-key *

If we have more than one tunnel for the headend ASA, then we need to follow the same procedure mentioned above to configure crypto maps on the remote ends (ASAs or IOS Routers or any other network devices)

Note: In case you are using Remote Access IPSEC VPN clients also, then to utilize this redundancy, we need to mention primary interface ip address as the “host address” in the vpn profile, and under the “backup servers” section at the VPN client, we need to mention the secondary interface ip address.

So with the above procedure we should be having our VPN Redundancy in place. Now let’s consider some use cases for this setup.

Use-Cases:

===========================================

1. Primary ISP is up and running, with this the VPN will be formed with the “Primary” interface, because the SLA monitoring refereed under Part 1 above, will put the route, “route Primary  0.0.0.0 0.0.0.0 172.16.10.10 1” into effect for routing packets, and the “crypto map VPN-map interface Primary” will be chosen.
   
2. If the Primary ISP goes down, then the SLA monitoring will detect that the Primary ISP is down and the route “route Backup   0.0.0.0 0.0.0.0 172.16.20.10 254” will be chosen. With this the “crypto map VPN-map interface Backup” entry will take effect because this is the outgoing interface that will be chosen for VPN traffic.
   
3. If the Primary ISP comes back up now, SLA tracking will detect this and the route “route Primary  0.0.0.0 0.0.0.0 172.16.10.10 1” & “crypto map VPN-map interface Primary” will be chosen and Primary ISP will be chosen for VPN tunnel negotiations.