Installing Firepower on Cisco ASA

Cisco ASA Firepower installation process is little bit complicated and require multiple steps in order to do

First please check the simple topology:

 

Part 1 installing FMC [FireSight Management Center] vm

You can download the .OVf file from Cisco.com and install it by using Esxi Vsphere tool to import
the file which is linux based

The following is used for installation process on the esxi

1. Open vsphere client
2. Go to file > deploy OVF template
3. Browse the .ovf file on your computer
4. Click next
5. Choose think provisioned as a size on disk
6. Choose the name of the VM for example [FireSight VM]
7. Choose the data store on your host
8. Select the network mapping
9. Finish then power it on

Note: there is no need to allocate resources because the vm is already have the resources allocated.

Installation Process:

1. After powering on the vm wait for the counter to finish
2. After the machine starts you can login to it using admin as username and password is Admin123
3. To login into root you need to use command sudo su -   and the password is Admin123
4. You need to add IP address for the FMC and you must be on Root user to be able to change settings
5. After you login as "root" type the command #configure-network then you will have auto-config questions

1. IPv4 configs
2. Subnet mask
3. Gateway

The Network settings will be updated.

NOTE: you need to enable the IP address of FMC to reach internet, so you need to add the IP on the firewall
 and also create route under static routing

After everything is done you can use the following command on your browser to login to FMC https://172.16.14.50    
for example.

NOTE: Management Interface will need to be shutdown and ip removed from it.

Part two Cisco Firepower image+ package upload to firewall and installation

You will need the following in order to accomplish this:

1. IOS version stable and recommended by cisco I used IOS 9.6.3.1 which was recommended by Cisco
2. ASASFR boot image which is ".img"
3. ASASFR system package which is ".pkg"
4. FTP server which will be used to upload both .img and .pkg to the Firewall and SFR
5. TFTP server  which will be used to upload Cisco IOS for ASA Firewall

Start installation of Cisco Firepower .img File:

1. Locate the image when you upload into Disk0:/ on the Firewall and of course you must have
1.  SSD installed on the Firewall
2. Copy the correct full name of the image for example "asasfr-5500x-boot-6.2.0-2.img"

Before you start installing the SFR make sure to do the following:

1. Shutdown IPS module and uninstall it.
2. Shutdown CXSC module and uninstall it
3. Shutdown SFR module and uninstall it

This can be done using the commands:

#sw-module module ips shutdown

#sw-module module ips uninstall

#sw-module module CXSC shutdown

#sw-module module CXSC uninstall

And same for SFR module

Make sure that they are down by using the command #show sw-module and see if they are "DOWN"

After this process you will need to start installing the Boot Image that you already uploaded to the Firewall Disk0:/

We will use the following commands to install it:

#sw-module module sfr recover configure image disk0:/asasfr-5500x-boot-6.2.0-2.img

#sw-module module sfr recover boot    [you can enable debugging to follow up the process during the
 boot process #debug module-boot

NOTE: in here you will need to wait for the process for 15 minutes so don’t rush it!!!!

Now after the installation finishes you will need to login to the SFR in order to upload the package file to it
 using FTP so first we will need to have IP address on the SFR

In order to upload the Package file to it

Lets setup these IP information:

#session sfr console  [note if the installation wasn’t finished then you won't be able to do this command]

Use the username admin and password Admin123 to login to the SFR console

Now start configure it #ASASFR-BOOT> setup

You will now be prompted to add information for IPv4, IPv6, NTP, DNS, Domain …etc. then you will be
asked if you want to apply it n/y??

After you finished the setup part, you will have ip address reachable in order to transfer the package to
 the Boot Image and install it

Use FTP tool like FileZilla for the transfer, locate the package file on it and create username and password
that will be used to access your FTP server and get the file

FTP command ASASFR-BOOT > system install ftp://username:password@IP-address/ASASFR.pkg    

The FTP process will take some time because the package size is big.

After upload finish the SFR will start to extract.

You will be asked if you want to upgrade then just say "Y" and press enter.

NOTE: this process will take up to 15 minutes so don’t rush it!!!!!

After this finishes and if everything is ok you should see the result by using

#show module   [it should be up]

FMC-ASA# show module sfr

---- ------------------------------ ---------------- --------------------------

 sfr ASA FirePOWER                  Up               6.2.0-362

Mod  Status             Data Plane Status     Compatibility

---- ------------------ --------------------- -------------

 sfr Up                 Up                   

#show failover  [you must see the SFR card in here and in UP/UP state]

Last Failover at: 18:16:40 AST Jul 6 2017

        This host: Primary - Active

                Active time: 241396 (sec)

                slot 0: ASA5512 hw/sw rev (1.0/9.6(3)1) status (Up Sys)

                  Interface Outside (X.X.X.X): Normal (Monitored)

                  Interface Inside (10.211.250.253): Normal (Monitored)

                  Interface DMZ (172.16.16.253): Normal (Monitored)

                slot 1: SFR5512 hw/sw rev (N/A/6.2.0-362) status (Up/Up)

                  ASA FirePOWER, 6.2.0-362, Up, (Not-Monitored)

        Other host: Secondary - Standby Ready

                Active time: 402 (sec)

                slot 0: ASA5512 hw/sw rev (1.0/9.6(3)1) status (Up Sys)

                  Interface Outside (X.X.X.X): Normal (Monitored)

                  Interface Inside (10.211.250.252): Normal (Monitored)

                  Interface DMZ (172.16.16.252): Normal (Monitored)

                slot 1: SFR5512 hw/sw rev (N/A/6.2.0-362) status (Up/Up)

                  ASA FirePOWER, 6.2.0-362, Up, (Not-Monitored)

NOTE: you might face some problem if you have the SFR installed on Different slot on active from the one on
 standby so you must use this command on the active

#no monitor-interface service-module   [this is very important because it can cause the 
standby ASA to become active at the same time and

cause connection problem]

Ok, after the SFR Card becomes UP you can start configuring it

#session sfr       [username admin and password Admin123]

Now setup IP addresses for the SFR itself [note the previous IP addresses were for the Boot Image not for the SFR system]

These IP's will be used to connect the SourceFire "firepower" to Firesight.

Now, Let's connect the Cisco Firepower to Cisco FireSight

1. Connect to SSH on the IP address of the SFR module "172.16.14.51"
2. Input the username admin and password is Admin123 "default"
3. Add the command system> configure manager add 172.16.14.50 cisco1234   
4.  (where 172.16.14.50 is the Firesight server, and cisco1234 is shared key between two systems)
5. Go to 172.16.14.50 (firesight) and then go to >Devices >device management> add device
6. Full the information for the Firepower and then click on register

At the same time you can use Firepower command line to check if the registration was completed
system> show managers and see if the status is complete or still pending.

Hope this was useful!

Samer R. Saleem

OSPF DR/BDR Election Manipulation- quick review

DR/BDR is very important part of Broadcast and Non-Broad cast multi-access OSPF network types and it is needed in an Area in order to get LSA1 from OSPF routers and rely LSA2 to the OSPF routers about the network information for all OSPF routers, please know that the below information is my notes that i have been writing down from my study for CCIE.

DR/BDR on OSPF is determined per interface level so you can have for each vlan/interface different DR/BDR from the other

You can increase priority for the DR by setting #ip ospf priority 255 [the maximum is 255] and [0] means the router or the

interface will not participate in election.

Choosing the DR is by priority, highest router id, highest loopback ip, highest physical interface ip

Choosing the DR/BDR is only on broadcast and non-broadcast network types on the OSPF

NOTE: preemption is not supported, so any device need to wait for the DR to fail until it can take over.

NOTE: if no router declared itself as DR then the router will say that I am the DR/BDR

You can check DR/BDR election process by #debug ip ospf adj    [and shutdown the DR router and monitor the debug messages]

*Jul  1 17:43:06.361: OSPF-1 ADJ   Et0/0: Neighbor change event

*Jul  1 17:43:06.361: OSPF-1 ADJ   Et0/0: DR/BDR election

*Jul  1 17:43:06.361: OSPF-1 ADJ   Et0/0: Elect BDR 150.1.1.1

*Jul  1 17:43:06.361: OSPF-1 ADJ   Et0/0: Elect DR 150.1.1.1

*Jul  1 17:43:06.361: OSPF-1 ADJ   Et0/0: Elect BDR 0.0.0.0

*Jul  1 17:43:06.361: OSPF-1 ADJ   Et0/0: Elect DR 150.1.1.1

On the hub/spoke the Full state will be with the DR only, so it must be HUB configured as DR in order each spoke will form

 full adjacency with it.

Because spokes are not active to talk OSPF between each other so the spoke will form full adjacency with DR and the BDR only.

If spoke becomes DR, the OSPF database will be broken and the routing will be incomplete.

That’s why you need to make sure all spokes priority are set to 0

NOTE: both DR/BDR will receive LSA1 in Area but only DR will rely the information back to the rest of the network. So if R5 was BDR but not DR, the OSPF DB will be broken

Because for example: R2 will send LSA1 to R5 and R4 but only R4 will be able to reply the information to all the routers but it's not the HUB so the process will fail.

NOTE: when you here the OSPF DB is broken, think about the DR location in the Network.

Proxy ARP - quick review

Proxy arp is a feature that is recommended to disable if you have a router facing interne.

 

and better to enable only on interfaces that are working in an internal LAN.

 

 

#ip proxy-arp  [will make the router advertise itself "mac address" as the mac address of the destination needed instead of the real device]

 Disable ARP proxy globally is 

# ip arp proxy disable and under interface is 

#no ip proxy-arp 

Ok, so now what is the proxy ARP? 

It’s a feature that is enabled by default on Routers that enabled the router to direct the traffic for

network that doesn’t have Reach-ability to destination when the router interface have the route to it.

If you disable the Proxy-ARP on interface the router 1 will not be able to reach router6 loop-back interface, the reason is it won't be able to get L2 mac address Of the destination, [the reason is using ip route to exit interface of the router instead of IP address of next hop]

if you enable debug for it #debug IP packets you will see encapsulation error,

which means router failed to build Layer 2 frame

The solution

 is to

• hard-code the ARP and mac address for the destination then it will be reachable.
• Or enable the proxy ARPon interface
• Use IP route to next hop address instead of pointing to the exit interface

MULTICAST BGP EXTENSION

First Question you need to know is why?
why we need BGP extension for Multicast?
the answer is simply we need to connect and multicast between two or more Domains "Autonomous systems" and BGP uses unicast to connect to its neighbors, so you have to use AF for Multicast in order to enable the multicast via BGP.


we will work on the topology below:

Important things to have before configuring mBGP-Multicast extension are:
1.FULL IGP routing table exchanged between routers and reach-ability
2. Interfaces on order Router facing EBGP neighbor should be passive for IGP
3. run EBGP border Routers or neighboring AS
4. run iBGP and make sure from Full BGP neighbor-ship and routes exchange
till the last router in your AS but using Confederations or Route-Reflectors in our case we will
use R6 and R1 from each side to be point of reflection for incoming iBGP routes learned from Border
Routers {don't forget to make border routers to act as next-hop for all the iBGP neighbors
5. configure BGP address-family for multicasting and this will require activating commands
6.redistribution point will be the border routers in order to bring reachability between
the two domains
7. use peer groups when needed to ease up configuration
8. choose the PIM mode you have been tasked to use Standard or Cisco
9. sparse mode is the common mode used and enable MSDP
NOTE: MSDP is used because RP's are in two different domains and in order to learn about sources in other domains we will use MSDP.
10. Verify your configuration by joining one router to multicast group and ping it from the remote site
11. use #show bgp ipv4 multicast summary to see the activated neighbors
12. use #show ip mroute x.x.x.x for the group
13. use #show ip rpf
14. use #show ip pim rp mapping  to verify your RP in each domain

GRE over IPSEC

Q-Why we will use IPSEC for transporting GRE payload?
A- our scenario is to connect two remote sites that are running OSPF AREA 0
discontinuously, we will connect the two peers using GRE over IPSEC

       R-A <------>R-B <-----> R-d <----->R-e <-----> R-F <------>R-Z

let's say R-B link to R-A is in OSPF AREA 0
R-F link to R-Z is in OSPF AREA 0 

the underlying routing protocol between R-B to R-F is [EIGRP]

so back to the question why we will use IPSEC for GRE transport, the reason is GRE doesn't support  Dynamic Routing protocols because GRE is used as normal Point-to-Point.

points to focus on:
1. reachability between R-B to R-F [loopbacks included]
2. reachability between R-B to R-A and R-F to R-Z [on OSPF]


steps: 
create GRE interface [ IP address, source, destination ] use the loopback for source and destination, this will help in reroute through alternative links in case of link failures.
GRE tunnel will be have the IP MTU reduced and TCP MSS changed as well.

GRE Tunnel will run OSPF in AREA 0 to be the link between the two discontiguous Area 0 

Configure the IPSEC tunnel:
1. configure ISAKMP "phase 1"
2. configure IPSEC "phase 2"

in ISAKMP which is phase 1, we need  following that both peers must have identical :
1. authentication   [pre-shared, PKI]
2. encryption type  [AES, 3DES, DES]
3. hashing type  [ MD5, SHA, SHA256, SHA384, ...etc]
4. Diffie Hellman group  [1, 14, 15, ....etc] how many bits your router can handle
5. Life time  [this is optional you can have different on peers]

in IPSEC which is phase 2, we have the following to configure:
1. configure the peer who you will connect  with
#set peer x.x.x.x
2. configure the data you are allowed over the IPSEC by using Access-list
#permit ip source destination
if you are using tunnel mode, you will have the links between R-B to R-A and R-F to R-Z in the access list, if you are using transport mode you will have to make the source is the router loopback to destination remote router loopback, in our scenario we will use transport mode. 

3. configure the transform set which is the way you will treat your data as encryption, by data we mean the data allowed in access list.
according to your ios version it may differs for the supported :

then you will match the access list using #match address acl-name
then set the transform set #set transform set  [for the matched acl]


now that you have everything configured

you should differentiate between GRE over IPSEC and IPSEC over GRE
in GRE over IPSEC you will have to configure the CRYPTO MAP on the physical interface or interfaces while on IPSEC over GRE you will need to configure CRYPTO MAP on the tunnel interface of the GRE.


so, after you applied the CRYPTO MAP on the physical interface you can start checking and verifying the configuration for each part, so let's start :

verify reachability on the loopback interface of the two peers
Router#ping 150.1.7.7 so lo0
Sending 5, 100-byte ICMP Echos to 150.1.7.7, timeout is 2 seconds:
Packet sent with a source address of 150.1.8.8 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/7/8 ms
this ICMP carried via EIGRP.



verify the GRE tunnel is up and running:

verify the  ISAKMP, Quick-Mode and status is active:

verify IPSEC security association which you have parameters to check:

a. SPI outbound/inbound

b. ENCAP/DECAP and Digest values [they should be increased when you even send ICMP]

c. check the ACL or "proxy identity" for local ident and remote ident. lines

NOTE: ACL's on both sides must be mirrored.

Verify Transform set:

it must be identical on both sides:

NOTE: we are using ESP.

verify the IP Route for OSPF and you should receive routes for remote peers through the tunnel interface:

the above output shows route from R-B to R-Z and coming via tunnel 0.

traffic destined to 150.1.9.9/32 will go to tunnel0, then tunnel0 will hand it over to the source of the tunnel which is loopback0, loopback0 will use the EIGRP as underlying protocol to go to remote site loopback0, when the router choose the exit interface the packets on that interface is encrypted because we have the CRYPTO map applied on it, by the way we will have the data encrypted and sent to the remote site.

MPLS L3VPN multihomed customer AS override

Topology description:
R3 , R4 = Provider Routers / Core network for ISP [P]
R1, R5 = Provider Edge Routers [PE]
R6, R7 = Customer Edge Routers [CE]

MPLS is running across ISP network, starting from PE left side to P routers in core to PE on Right side

ISP is running OSPF as IGP, so PE's inter E0/1 and R3 and R4 all running OSPF to exchange Routes

iBGP is running between R1 and R5 to establish mBGP VPN through ISP Network MPLS

the iBGP is using R1 and R5 Loopback interfaces to establish the connection

in this Lab i used eBGP Connection between CE and PE routers

from PE side we have to configure VRF toward the CE just in case we have more than CE with same IP ranges
BGP configuration on PE will be under Address-family IPv4 VRF
BGP configuration on CE side will be normal and under global routing table

on the PE we have the redistribution if we are using other than BGP between PE and CE
but since we are running EBGP [CE to PE] and iBGP [PE to PE] then there is no need to redistribute

on the Customer edges [sites] we are using BGP with AS 250 on both CE routers
when CE [left] sends prefixes to PE [left] it will include the path attributes, PE left will send to PE right and PE [right] will send to CE [right], CE [right] will check the prefixes and finds the Path attributes of itself on the routes so it will consider it as loop and BGP loop prevention mechanism is to drop any routes that has my AS in the path to the destination [default behavior] so what to do in this case to make both CE sites connects with each other?

there are two ways:
1. Allow AS IN  [implemented on CE routers to allow self AS numbers to be with the incoming routes]
2. AS override [implemented on PE sides toward the CE neighbor and it will change the AS number with AS number similar to PE AS number]
3. BGP Site of Origin [tagging routes]


check the configuration below:

PE-LEFT#show run | section router bgp
router bgp 100
 bgp log-neighbor-changes
 neighbor 5.5.5.5 remote-as 100
 neighbor 5.5.5.5 update-source Loopback0
 !
 address-family vpnv4
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf vpn
  neighbor 10.0.17.7 remote-as 250
  neighbor 10.0.17.7 activate
  neighbor 10.0.17.7 as-override
 exit-address-family
=========================================

same will be on right side PE
PE-RIGHT# show run | section router bgp
router bgp 100
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 !
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf vpn
  neighbor 10.0.56.6 remote-as 250
  neighbor 10.0.56.6 activate
  neighbor 10.0.56.6 as-override
 exit-address-family
PE-RIGHT#

now checking the BGP table on the CE will be like the picture below:

as you can see, we have path contains 100 100 which is the PE BGP AS number.

reachability check from CE right side to CE left side:

OSPF LSA types understanding

the most important part of OSPF understanding the getting to know LSA "link state advertisements" section

the understanding part should not only be for memorizing the LSA names

but you also need to know how to check each one of them in command line

and how is every LSA is generated and who generates the LSA


so basically as we learned that OSPF is uses hierarchical design and this is done by the backbone area 0

because all area must connect to it in order to reach the other area's


other than that, configuring areas will hide the routes from the other area and limit the LSA flooding that is happening in a single area

 so Area 0 will not advertise its LSA flooding when change done internally to other areas like area 1 and area 2


 now getting back to the LSA types we have the most important LSA:
LSA1  [ this is for all routers within the same area and each one say's i'm in this area ]
so LSA1 will be generated from all routers for every routers link to be sent to the ABR
LSA2  [ this is for IP address for DR interface within same area ]
all routers will have OSPF adjacency with the DR and BDR and they will generate LSA2 and this is only in OSPF network types where DR is elected, so its in [NMBA, Broadcast networks]
and then DR will send it to all routers so its like a map to be used internally between routers to reach each other.


LSA3  [ this is generated by the Area Border Router which has legs in two areas, and its summary for the networks advertised by the other area so its point of contact between area ]

LSA4 [ is when the ASBR gets routes from EIGRP or RIP into OSPF domain, the ASBR will send to the ABR of that area LSA1 messages and the ABR will generate LSA4 to send to next area.
LSA4 is like identified for the ASBR

LSA5   [ external routes that are coming from another router runs rip or eigrp or others ]
so when Rx redistributes EIGRP into OSPF domain it will send LSA1 to the ABR of that area, then the ABR will generate LSA5

LSA7  [ used in NSSA because routers will not allow LSA5 so it will set LSA5 to LSA7 to be allowed into OSPF domain ]

all of these LSA's can be seen under OSPF database using
#show ip ospf database     and adding its arguments to find each LSA self originated or advertised by other routers





Ok, now how to filter LSA's?

STUB = NO LSA4 NO LSA5
TOTALLY STUB = NO LSA3,4,5
NSSA= NO LSA5 but LSA7 is ok and will be translated back at the borders.
TOTALLY NSSA=  will generate LSA3 with default Route