Sunday 20 March 2016

Cisco Firepower System - Firepower Managed Devices

The Cisco Firepower System is a collection of network security products and devices to manage traffic, where these products could be deployed either as hardware or software solutions

In terms of deployment, one could have multiple devices for traffic-sensing purpose ( These are referred as managed devices) installed in network. These managed devices monitor network traffic for analysis purpose and later report to a managing device (This is referred as Firepower Management Center.  Note- earlier it was known as Defense Center)
Another alternative deployment is inline mode deployment, where device is deployed in the band to traffic flow and can affect the flow of traffic.

The Firepower Management Center (FMC) gives you a centralized console to manage the devices from GUI. Using FMC you can perform administrative, management, analysis, and reporting tasks for multiple devices from single console.

One thing what you need to understand is that  most of the managed devices what you deploy in the network do not have a Firepower System web interface, so you would have to use FMC to manage them. Though you can use a CLI to perform initial setup for managed devices. again once the managed devices are up and running, you can get back to FMC GUI to manage them.

However also make a note that, 7000 and 8000 Series devices( also referred as Series 3 Appliances) have a limited web interface that you can use to perform initial setup and basic analysis and configuration tasks.

Deployment Options for Managed Devices

As mentioned in the earlier section of this post the managed devices deployed in the network monitors traffic for analysis purpose.
You can use your FMC/ Defense Center as a central management point to manage Sourcefire-branded managed devices, including virtual devices and Sourcefire Software for X-Series platforms.
Part A - (Passively deployed)
When the managed device is deployed passively which means not inline to traffic flow. here the managed devices gather many useful information using FireSIGHT™  where FireSIGHT is Sourcefire’s discovery and awareness technology that collects information about hosts, operating systems, applications, users, files, networks, geo-location information, and vulnerabilities, and with this comes the capability of  visibility to what is happening in your network.
You can use the FMC/Defense Center’s web interface to view and analyze data collected by FireSIGHT. Also understand that data gathered by FireSIGHT could be used for editing access control and modify intrusion rule states. 
Apart from this, one can generate and track indications of compromise(IoC`s) on hosts available in your network. This is done by FMC/DC based on correlated event data for the hosts  available.

Part  B - (In-Line Deployed)
When a managed device is deployed inline, the Firepower system can affect the flow of traffic with the help of access control. 
Access-Control allows you to define access policy, in a precise manner on how to handle the traffic either entering (based on Source or From), exiting (based on destination or TO), and traversing (Through traffic) your network. The data that is collect about the network traffic could be used to filter and control that traffic based on following - 
  • easily identify OSI L3/L4 characteristics: source/destination IP, port, protocol
  • Context-Aware Information about network traffic - like reputation value, risk, business relevance, application used, clients used, website or URL visited
  • Identifying the Users related to a particular traffic or connection from Microsoft AD and LDAP Authentications
  • checking Characteristics of encrypted traffic by decrypting it to see if traffic contains 
    a prohibited file, detected malware, or intrusion event
 You need to understand that Series 3 appliances that is 7000 and 8000 Series devices come with Network management features like NAT, Routing, switching, VPN support. Also these appliances support configuration for bypass interfaces, aggregated interfaces, fast-path rules, and strict TCP enforcement.


Overview of Managed Devices


Well in this section a small walk through the different devices that you would be managing using the FirePOWER Management Center/ Defense Center.

A) 7000 and 8000 Series Managed Devices

Cisco Firepower 7000 and 8000 Series appliances are physical devices. Different models of 7000 and 8000 Series devices are available with different range of throughput. Series 7000 and 8000 products come with more or less same capabilities. In general, 8000 Series devices are more powerful in terms of performance compare to 7000 Series; Also 8000 Series Appliances support additional features such as fast-path rules, link aggregation, and stacking.

B) NGIPSv

NGIPSv is the Virtual appliance, specifically a 64-bit virtual device which can be deployed as an ESXi host) using the VMware vSphere Hypervisor or vCloud Director environment. 
By default, NGIPSv uses 1 Gbps interfaces but one could use vSphere Client to modify the default sensing and management interfaces with vmxnet3 (10 Gbps) interfaces.
You must understand that regardless of the license, the NGIPSv Virtual Appliance does not support any of the features which are hardware-based features for example -  redundancy and resource sharing, switching, routing, fast-path rules etc.

C) Cisco ASA with FirePOWER Services

Cisco ASA with FirePOWER Services functions similarly to NGIPSv but here the FirePOWER services are not running in VM environment, rather runs on top of ASA.
In an ASA with FirePOWER services deployment, the packets are first inspected by ASA software which provides the first-line system policy and then passes traffic to the Firepower Software which is also running on the same ASA box for discovery and access control purpose.

Once again in this type of managed device, you must understand that regardless of the licenses installed and applied, ASA with FirePOWER Service running on top of it does not support any of the following Firepower features mentioned below:
  •  Like mentioned in case of NGIPSv, ASA with FirePOWER Services does not support ant hardware-enabled feature like-  device high availability, stacking, switching, routing, VPN, NAT, and so on. However, the ASA platform does provide these features as a part of ASA software. So key point is that these features are available on ASA running FirePOWER service on top of it, but the features are not a part of FirePOWER software. 
  • FMC GUI cannot be used to configure ASA FirePOWER interfaces. 
  • FMC cannot be used to shut down, restart, or otherwise manage ASA FirePOWER processes.
So in short we got to focus on these 3 options under managed device which includes - 
A) Firepower Series 3 appliances
B) Virtual NGIPS / NGIPSv
C) ASA with FirePOWER Services.


Now lets try to summarize the feature/ capability supported by these different device- 

1) Supported By Series 3 appliances (7000 & 8000 Series Appliances) - 
Device Stacking(8140,8200,8300 Models), High Availability, switching, routing, NAT, routed aggregate Interfaces,VPN, Firepower system GUI with limited capability, Link aggregation, CLI, External Authentication support, Strict TCP enforcement, fast-path rule feature which is supported only by 8000 series appliance.


2) Supported by NGIPSv and ASA with FirePOWER Services - 
Here very first any feature which is hardware enabled or hardware based is not supported by NIPSv and ASA FirePOWER. Though while comparing ASA with FirePOWER services features with NGIPSv features - restricted CLI  Access is supported on both , but ASA FirePOWEr gives capability to connect with eStreamer (Event streamer) Client which is not possible in NGIPSv. In this case Firepower device acts as Server and a custom developed client application can connect and stream the events related data from Firepower.
 

Friday 6 November 2015

Cisco Identity Services Engine 2.0

Cisco ISE 2.0  



Hii Guys this post is about the release of New version of Cisco ISE.

Cisco ISE 2.0 is out in the market and I must say its a major release, and guess what Cisco ISE-2.0 supports TACACS+ / T+. Yes T+ was one the highly requested feature.

1. New Simplified User Interface for ISE 2.0

I just tried the ISE-2.0 and must say the UI is very cool and much simplified.

Very first have a look at the Home Page of ISE-2.0




Take a look at the new User Interface. The UI technology is modernize for better browser and technology support. The Navigation support is also changed though more or less the pages are still kept the same.

Given Below are the new controls -
Guest Access and Work Centers are the New Tabs added to the GUI of ISE 2.0

Take a Look at these Tabs -

Operations Tab


Policy Tab



Guest Access Tab is something New in Cisco ISE 2.0. All Sponsor and Guest portal related settings are available at same place.



Administration Tab is Also more or less same like ISE 1.X versions. Except the Device Portal Management control.


Finally Work Centers is a completely new tab added to Cisco ISE 2.0




2. TACACS+ / T+ Support on ISE 2.0 for Device Administration





3. Tunnel support in ISE 2.0

Supports Tunnel for Cisco TAC. This feature is already on WSA/ESA and now is introduced in ISE 2.0 as well. This feature allows the admin to enable a secure tunnel for Cisco`s TAC to remotely access the appliance`s root OS.



4. Pre-defined Access Rules

Well Cisco ISE 2.0 comes with pre-configured default rule.This helps the engineer to save deployment time.


5.  Pre-defined 3rd party Network Device profiles


6. SXP capability in ISE 2.0

Propagate SGTs from ISE directly to enforcement devices. Also the Access layer devices does not need understanding of SGT in User-Data Center use-case.


7.  Cisco MSE integration with ISE 2.0

The integration of Cisco Mobility Services Engine(MSE) allows administrators to use ISE to authorize network access based on the users location.  Cisco MSE periodically checks for location changes and reauthorizes access based on the new location of user. This is done as a part of authorization policy using CoA.

Monday 2 November 2015

Translations on Cisco ASA 8.3 and above with Examples

Translation Examples on Cisco ASA 8.3 and Above

Hii Guys, Welcome back, hope you guys went through the differences between Twice NAT and Network Object NAT, As mentioned in the previous post, there are 3 Sections in translation table.
So lets begin with some example for NAT rules that you will configure in Section 1.
!
!

Lab Topology - 





Section 1 : TWICE / MANUAL NAT

Lets start with the very first example on Dynamic Policy NAT.
Now here in this example I want that when any host from inside subnet 10.11.11.0/24 is going to a specific destination may be Router R2- Loopbacks( 2.2.22.0/24 or 2.2.23.0/24) and also to R2 interface F0/0(1.1.1.2).  Inside network should get translated to the following range of IP address - 1.1.1.3 to 1.1.1.9 on outside.


Example 1: DYNAMIC POLICY NAT

Create object for Inside Subnet -10.11.11.0/24 
!
object network INSIDE
 subnet 10.11.11.0 255.255.255.0
exit

Create object group of type network for loopbacks behind R2 and R2 interface F0/0 
I want you guys to observe how objects are referenced under the object network group.
In later examples I will try to show you how to reference network object within network object group.

object-group network DESTINATION1
 network-object 2.2.0.0 255.255.0.0
 network-object host 1.1.1.2
exit

object network NAT-POOL1
 range 1.1.1.3 1.1.1.9
exit

nat (inside,outside) source dynamic INSIDE NAT-POOL1 destination static DESTINATION1 DESTINATION1




Example 2: DYNAMIC PAT
Well in this example I want Any host from either Inside, DMZ3 or DMZ4 zones, going to any host on outside network except R2 Loopbacks and R2-F0/0 to get PATed to Firewall Outside interface IP address. 

Use the object created in previous example
object network INSIDE
 subnet 10.11.11.0 255.255.255.0
exit

Create another network object for DMZ3  

object network DMZ3
 subnet 192.168.30.0 255.255.255.0
exit

object network DMZ4
 subnet 192.168.40.0 255.255.255.0
exit


Now in this example of Network Object I am going to refer to All Inside, DMZ subnets.
object-group network ANY-SOURCE
 network-object 10.11.11.0 255.255.255.0
 network-object 192.168.30.0 255.255.255.0
 network-object 192.168.40.0 255.255.255.0
exit


Here the interface keyword picks the IP address of outgoing interface which is Outside in this case.

nat(any,outside) source dynamic ANY-SOURCE interface





Example 3: DYNAMIC NAT+PAT Combination
Well this example is a combination of above two examples.
Here basically I will create one object for NAT and another object for PAT, So that as Order of translation is to do NAT followed by PAT, So if the IP Addresses in the NAT pool gets exhausted, it should move to PAT IP Address, which is defined using another network object.

object network INSIDE
 subnet 10.11.11.0 255.255.255.0
exit

object network NAT-POOL1
 range 1.1.1.3 1.1.1.5
exit

object network PAT-POOL1
  host 1.1.1.6
exit

Here in the Network Group Object

object-group network NAT-PAT-POOL
 network-object object NAT-POOL1
 network-object object PAT-POOL1
!
object-group network DESTINATION1
 network-object 2.2.0.0 255.255.0.0
 network-object host 1.1.1.2
exit
!
nat (inside,outside) source dynamic INSIDE NAT-PAT-POOL destination static DESTINATION1 DESTINATION1
!




Example 4: IDENTITY NAT 
Well here in this example of Identity NAT, the task is to Translate INSIDE subnet to itself, when the destination is either the subnet of DMZ3 zone or DMZ4 zone. 
So if the destination is not DMZ3 and DMZ4 some other translation rule must be used.
!
object network INSIDE
 subnet 10.11.11.0 255.255.255.0
exit
!
!
object-group network DMZ-ZONES
 network-object 192.168.30.0 255.255.255.0
 network-object 192.168.40.0 255.255.255.0
exit
!
!
nat (inside,any) source static INSIDE INSIDE destination static DMZ-ZONES DMZ-ZONES

Well now here I have used (inside, any) because I can`t use two egress interface name in one NAT rule. 
Also note that in production network I would prefer to create individual objects for DMZ3 and DMZ4, which I would group in Network Object.
Something like this -

object network DMZ3
 subnet 192.168.30.0 255.255.255.0
exit
!
object network DMZ4
 subnet 192.168.40.0 255.255.255.0
exit

object-group network DMZ-ZONES
 network-object object DMZ3
 network-object object DMZ4
exit





Example 5: STATIC POLICY NAT

                  10.11.11.0/24                       1.1.1.0/24
                        INSIDE                           Outside
     R1 ---------------------- FW --------------------------R2
10.11.11.0/24 --------------------------> 2.2.0.0/16 or host1.1.1.2


object network INSIDE
subnet 10.11.11.0 255.255.255.0
exi
!
!
object network R2-LOOPBACKS
 subnet 2.2.0.0 255.255.0.0
exi
!
!
object network MAPPED-NAT-SOURCE
range 1.1.1.99 1.1.1.103
exit
!

!
nat (inside,outside) source static INSIDE MAPPED-NAT-SOURCE destination static R2-LOOPBACKS R2-LOOPBACKS
!
!


SECTION 2 Rules - 

(Auto-NAT or Network Object NAT)



Example 1: STATIC NAT
Well this rule will go to Section 2 of the translation table,  now here I want a static translation for R3 Interface F0/0 IP address, which is 192.168.30.3 to be seen as 1.1.1.30 on outside interface of ASA.
so if any one tries to access IP address 1.1.1.30 from outside of ASA would end up reaching Router R3(192.168.30.3).

these rules are configured in section 2. observe the example carefully, NAT keyword is being used within the network object.
These same objects are used in ACLs as Well.


object network R3-F0
 host 192.168.30.3
 nat (DMZ3,outside) static 1.1.1.30
exi

Now as the Source of this traffic would be on outside interface of ASA, which is at low security level. The destination R3 is available in DMZ3 zone at security level of 50.

So you would have to explicitly (manually) allow this traffic on outside interface of the ASA.

Now there was a major change in order of processing on ASA software version 8.3 and above where Translate/Un-translate happens before ACL check.

so the packet received on outside interface of the ASA would be with destination IP as 1.1.1.30(Mapped_IP), which is translated IP address of R3-F0.

Once the destination IP address gets un-translated to 192.168.30.3(Real-IP), as per the order of processing, packet is checked against ACL, to be allowed towards R3-F0.

In this case the ACE in the ACL named OUT should be like this -  
access-list OUT permit icmp any object R3-F0

Here I am Using the same Network Object in ACL as well.

Have a look at another example for Router R4.
object network R4-F0
 host 192.168.40.4
 nat (DMZ4,outside) static 1.1.1.40
exi

access-list OUT permit icmp any object R4-F0

access-group OUT in interface outside


Example 2: STATIC PAT
Ok so this example here is of Static PAT, and the scenario is that you have two servers, R3(192.168.30.3) and R4(192.168.40.4) in DMZ3 and DMZ4 zone respectively .

I will translate both private IPs to a Single Public IP address of ASA outside interface.
Now Outside interface IP address of ASA which is 1.1.1.10 when accessed on tcp/8080 should redirect the user to R3-F0 (192.168.30.3) on tcp/80

and same IP address i.e. 1.1.1.10 when accessed on tcp/8999 should redirect the user to R4-F0 (192.168.40.4) on tcp/80.

object network R3-F0-WEB-PAT
 host 192.168.30.9
 nat (DMZ3,outside) static interface service tcp 80 8080
exi

access-list OUT permit tcp any host 192.168.30.9 eq 80

object network R4-F0-WEB-PAT
 host 192.168.40.9
 nat (DMZ4,outside) static interface service tcp 80 8999
exi

access-list OUT permit tcp any host 192.168.40.9 eq 80

access-group OUT in interface outside

This is another example where I have directly used the Real_IP address of R3 and R4 in the ACLs. but again as I have mentioned before, recommendation is to use the objects here in the ACLs as well. 


Example 3 :DNS REWRITE(Static Translation)

object network R3-F0
 host 192.168.30.3
 nat (DMZ3,outside) static 1.1.1.30 dns
exi

object network R4-F0
 host 192.168.40.4
 nat (DMZ4,outside) static 1.1.1.40 dns
exi





SECTION 3 Rules: (After-Auto NAT)

Example 1: DYNAMIC NAT/PAT/NAT+PAT-Combination

Guess what? the most general NAT rules come to this section of NAT table on ASA. Well if you see the NAT rule here in the given below example, yes it`s defined in global configuration mode, so its Manual/Twice NAT, but as it`s more general rule to go to Internet I have placed it in Section 3 using "after-auto" keyword.


object-group network ANY-SOURCE
 network-object 10.11.11.0 255.255.255.0
 network-object 192.168.30.0 255.255.255.0
 network-object 192.168.40.0 255.255.255.0
exit

object network GLOBAL-PAT-IP
 host 1.1.1.199
exit

nat (any,outside) after-auto source dynamic ANY-SOURCE GLOBAL-PAT-IP



Leave your comments below

Wednesday 21 October 2015

SLA Monitoring on Cisco ASA

Monitoring Static or Default Route on Cisco ASA Using SLA Monitor


So in this post I am going to cover a new topic from CCIE security version 4.0 Lab checklist.

Here the scenario is that Cisco ASA is connected to Two ISPs, ISP1 and ISP2 for example.
the link between ASA and ISP1 is up on ASA side and Down on ISP side.
Now if you have added a static route pointing to this ISP1 as default gateway. You are in trouble if something goes wrong on ISP site, may be the link on ISP side is down, but the link on your firewall is still up.

Now here one of the problem with static routes is that there is no inbuilt mechanism to determine if the default route is up or down. They default route remain in the routing table even if the next hop gateway i.e. ISP1 becomes unavailable.
This static routes is only removed from the routing table if the associated interface of the ASA itself goes down.

Hope the problem is clearly understood.

Well here I am looking out for a solution, where if the Primary Default gateway which is pointing to ISP1 as the next hop goes down, at this point if there is any backup route, the backup default route should be installed to the routing table and used.
Also when the primary default route is UP again, should be installed in the routing table and used.


The Cisco ASA implements this feature by associating a static route with a monitoring target that admin define, and this particular target is monitored using ICMP echo requests.
So lets say, you want to track DNS 4.2.2.2 as an object with the help of ICMP echo requests, If an echo reply is not received within a specified time period, the Tracking object is considered down and the associated route is removed from the routing table. i.e. the Primary route pointing to ISP1 as next-hop is removed.

Now there should be some backup route, this configured backup route is used in place of the removed primary route.

Well the admin must take care that the Object being tracked can respond to ICMP echo requests.
The target can be any network object that you choose, but you should consider using the following:

  • The ISP gateway address
  • The next hop gateway address (if you are concerned about the availability of the gateway)
  • A server on the target network, such as a AAA server, that the ASA needs to communicate with
  • A persistent network object on the destination network 

Topology

















Well this is the topology I am going to use for lab demonstration.

Configuration on Cisco ASA
ASA1(config)# show version

Cisco Adaptive Security Appliance Software Version 8.6(1)2
Device Manager Version 7.1(1)

Compiled on Fri 01-Jun-12 02:16 by builders
System image file is "disk0:/asa861-2-smp-k8.bin"
Config file at boot was "startup-config"

ASA1 up 4 hours 57 mins

Hardware: ASA5515, 8192 MB RAM, CPU Clarkdale 3058 MHz, 1 CPU (4 cores)
ASA: 4096 MB RAM, 1 CPU (1 core)
Internal ATA Compact Flash, 4096MB
BIOS Flash MX25L6445E @ 0xffbb0000, 8192KB

Encryption hardware device : Cisco ASA-55xx on-board accelerator(revision 0x1)
        Boot microcode        : CNPx-MC-BOOT-2.00
        SSL/IKE microcode     : CNPx-MC-SSL-PLUS-0014
        IPSec microcode       : CNPx-MC-IPSEC-MAIN-0014
        Number of accelerators: 1
Baseboard Management Controller (revision 0x1) Firmware Version: 2.4

----------- Output Omitted----------

Licensed features for this platform:
Maximum Physical Interfaces       : Unlimited      perpetual
Maximum VLANs                     : 100            perpetual
Inside Hosts                      : Unlimited      perpetual
Failover                          : Active/Active  perpetual
VPN-DES                           : Enabled        perpetual
VPN-3DES-AES                      : Enabled        perpetual
Security Contexts                 : 2              perpetual
GTP/GPRS                          : Disabled       perpetual
AnyConnect Premium Peers          : 2              perpetual
AnyConnect Essentials             : Disabled       perpetual
Other VPN Peers                   : 250            perpetual
Total VPN Peers                   : 250            perpetual
Shared License                    : Disabled       perpetual
AnyConnect for Mobile             : Disabled       perpetual
AnyConnect for Cisco VPN Phone    : Disabled       perpetual
Advanced Endpoint Assessment      : Disabled       perpetual
UC Phone Proxy Sessions           : 2              perpetual
Total UC Proxy Sessions           : 2              perpetual
Botnet Traffic Filter             : Disabled       perpetual
Intercompany Media Engine         : Disabled       perpetual
IPS Module                        : Disabled       perpetual


ASA1(config)# show bootvar
BOOT variable = disk0:/asa861-2-smp-k8.bin
Current BOOT variable = disk0:/asa861-2-smp-k8.bin
CONFIG_FILE variable =


Interface configuration on Cisco ASA -
int GigabitEthernet0/0
no shutdown
exi
!
interface GigabitEthernet0/1
no shutdown
exit
!
!
interface Redundant1
 member-interface GigabitEthernet0/0
 member-interface GigabitEthernet0/1
 nameif inside
 security-level 100
 ip address 10.11.11.10 255.255.255.0
exit
!
!
!
interface GigabitEthernet0/2
 nameif ISP1
 security-level 0
 ip address 1.1.1.10 255.255.255.0
 no shut
exit
!
 interface GigabitEthernet0/3
 nameif ISP2
 security-level 0
 ip address 2.1.1.10 255.255.255.0
 no shut
exi
!
!
Guys I am leaving routing in this topology to you. In case you find any problem in routing, leave a comment, I will share the configuration file for this topology.

Well now lets configure SLA Monitor Parameters. Now here I want to track object 4.2.2.2 through ISP1 Interface of my ASA firewall. The ASA sends ICMP echo packets to 4.2.2.2 with source IP equal to ISP1 interface IP Address. If Echo-Reply is not received within the timout period. The backup route is installed in the routing table and used.
Now in the back end the ASA is still trying to reach the tracking object 4.2.2.2, and the moment echo-reply is received from 4.2.2.2, Primary route through ISP1 is again moved to Routing table and used.

sla monitor 5
 type echo protocol ipIcmpEcho 4.2.2.2 interface ISP1
 timeout 700  < Timeout in seconds
 frequency 3  < how frequently the packets should be send
 num-packets 2  < Number of ICMP packets
exit
!
!Here basically scheduling is done for SLA monitoring which as per !this command will go on forever and the tracking of object 4.2.2.2 !starts now.
sla monitor schedule 5 life forever start-time now
!
!
!Well next we create a track which will use SLA Monitor 5 For !Response Time Reporter(RTR) purpose.
!
track 1 rtr 5 reachability 
!
!
!Finally bind the Track 1 to the Primary default Route, so the !object can be tracked through !ISP1 interface of the firewall.
!
route ISP1 0.0.0.0 0.0.0.0 1.1.1.2 1 track 1
route ISP2 0.0.0.0 0.0.0.0 2.1.1.3 2
!
!


Now When you check the routing table entry, you would see that the ASA is using ISP1 route.
!
ASA1(config)# show route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is 1.1.1.2 to network 0.0.0.0

C    1.1.1.0 255.255.255.0 is directly connected, ISP1
C    2.1.1.0 255.255.255.0 is directly connected, ISP2
C    10.11.11.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 1.1.1.2, ISP1
!
!
!
For the verification purpose I will go to Router R2 interface F0/1 which is not a directly connected interface between ASA and Router R2, rather F0/1 is the interface between R2 and R4(F0/0).

Now check the configuration given below. I shut down interface F0/1 of Router R2. which make the communication between ASA ISP1 interface (1.1.1.10) and R4 loopback (4.2.2.2) to fail, because in the path, on link is down. 
!
!
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int f0/1
R2(config-if)#shutdown
*Mar  1 02:23:17.975: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
*Mar  1 02:23:18.975: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
R2(config-if)#

Once you have done the above configuration change you may go back to ASA console and check the routing table entry. 
You would realize that as ASA isn`t able to track object 4.2.2.2 through the primary Default route, it brings in Backup Default Route to the routing table. 

check the output given below -

ASA1(config)# show route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is 2.1.1.3 to network 0.0.0.0

C    1.1.1.0 255.255.255.0 is directly connected, ISP1
C    2.1.1.0 255.255.255.0 is directly connected, ISP2
C    10.11.11.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [2/0] via 2.1.1.3, ISP2


As I have mention above that ASA in the backend still tries to track the object, you may bring up the Interface F0/1 of router R2, which allows ASA to reach 4.2.2.2, As the object can now be reached, The ASA moves back the Primary Default Route to the Routing table.

This you can check by going back to ASA console and using show route command. 


R2(config)#
R2(config)#int F0/1
R2(config-if)#no shutdown
*Mar  1 02:23:56.887: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
*Mar  1 02:23:57.887: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
R2(config-if)#



ASA1(config)# show route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is 1.1.1.2 to network 0.0.0.0

C    1.1.1.0 255.255.255.0 is directly connected, ISP1
C    2.1.1.0 255.255.255.0 is directly connected, ISP2
C    10.11.11.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 1.1.1.2, ISP1

ASA1(config)# show sla monitor operational-state
Entry number: 5
Modification time: 09:59:21.554 UTC Wed Oct 21 2015
Number of Octets Used by this Entry: 1480
Number of operations attempted: 2042
Number of operations skipped: 0
Current seconds left in Life: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Connection loss occurred: FALSE
Timeout occurred: FALSE
Over thresholds occurred: FALSE
Latest RTT (milliseconds): 40
Latest operation start time: 11:41:24.561 UTC Wed Oct 21 2015
Latest operation return code: OK
RTT Values:
RTTAvg: 40      RTTMin: 40      RTTMax: 40
NumOfRTT: 1     RTTSum: 40      RTTSum2: 1600


Hope you guys could execute the lab and got the output.
If you face any issue with this lab, feel free to leave a comment.

Keep learning , Keep sharing