Update Cisco ASA 5506-X with Firepower

A customer bought a Cisco 5506-X with Firepower. It was delivered with Firepower version 5.4.1 (221). The upgrade process of a Cisco ASA is normally pretty straightforward. So I thought maybe a Firepower (FP) module is as easy to upgrade as an ASA box. I thought wrong.
Within ASDM it is possible to manage and upgrade the FP module. The first thing to stick out is the fact that ASDM on numerous occasions couldn’t contact the FP module. So after serveral tries I was able to manage the module from ASDM.
According to the Cisco manual it is possible to download the updates from within the ASDM. But after several tries and a lot of error messages I gave up on ASDM. So then there is only one solution. Go back to the good old CLI!

First of all I had to get the image file to the ASA box.This time I used a http server, the code looks like beneath:

Firewall# copy <interface> http flash:
Address or name of remote host []? <ip address>
Source filename []? asasfr-5500x-boot-6.0.0-1005.img
Destination filename [asasfr-5500x-boot-6.0.0-1005.img]? 

Now the FP module has to be rebooted with a new image, this can be done from the ASA cli:

Firewall(config)# sw-module module sfr recover configure image disk0:/asasf$
Firewall(config)# sw module sfr recover boot
Module sfr will be recovered. This may erase all configuration and all data
on that device and attempt to download/install a new image for it. This may take
several minutes.

Recover module sfr? [confirm]
Recover issued for module sfr. 

To monitor what’s going on, you have to enable debugging:

Firewall(config)# debug module-boot
debug module-boot  enabled at level 1

This step will take a while. I waited for about 20 minutes. After that you have to configure the FP module again. So login to the module and run the setup:

Firewall(config)# session sfr console 
Opening console session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.


Cisco FirePOWER Services Boot Image 6.0.0

asasfr login: admin
Password: Admin123


Cisco FirePOWER Services Boot 6.0.0 (1005)
Type ? for list of commands
asasfr-boot>setup


Welcome to Cisco FirePOWER Services Setup 
 [hit Ctrl-C to abort]
Default values are inside []

Enter a hostname [asasfr]: <Name>
Do you want to configure IPv4 address on management interface?(y/n) [Y]: Y
Do you want to enable DHCP for IPv4 address assignment on management interface?(y/n) [N]: N
Enter an IPv4 address [192.168.8.8]: <IP address>
Enter the netmask [255.255.255.0]: <Netmask>
Enter the gateway [192.168.8.1]: <Default Gateway>
Do you want to configure static IPv6 address on management interface?(y/n) [N]: N
Stateless autoconfiguration will be enabled for IPv6 addresses.
Enter the primary DNS server IP address: <DNS server>
Do you want to configure Secondary DNS Server? (y/n) [n]: N
Do you want to configure Local Domain Name? (y/n) [n]: Y
Enter the local domain name: <domain name>
Do you want to configure Search domains? (y/n) [n]: Y
Enter the comma separated list for search domains: <Domain name>
Do you want to enable the NTP service? [Y]: Y
Enter the NTP servers separated by commas: <NTP pool>
Do you want to enable the NTP symmetric key authentication? [N]: N
Please review the final configuration:


Hostname:Firewall
Management Interface Configuration

IPv4 Configuration:static
IP Address:<IP address>
Netmask:<Netmask>
Gateway:<Default Gateway>

IPv6 Configuration:Stateless autoconfiguration

DNS Configuration:
Domain:<Domain>
Search:<Domain>
DNS Server:<DNS server>
NTP configuration: <NTP pool>
CAUTION:
You have selected IPv6 stateless autoconfiguration, which assigns a global address
based on network prefix and a device identifier. Although this address is unlikely
to change, if it does change, the system will stop functioning correctly.
We suggest you use static addressing instead.

Apply the changes?(y,n) [Y]: Y
Configuration saved successfully!
Applying...
Restarting network services...
Restarting NTP service...
Done.
Press ENTER to continue...{Enter}


After the previous step it’s time to get the new FP version on the FP module:

asasfr-boot>system install http://<ip address>/asasfr-sys-6.0.0-1005.pkg
   
Verifying.    .. 
Downloading.    ..   
Extracting.    ..  
Package Detail
Description:Cisco ASA-SFR 6.0.0-1005 System Install
Requires reboot:Yes 

Do you want to continue with upgrade? [y]: Y
Warning: Please do not interrupt the process or turn off the system.
Doing so might leave system in unusable state.


This really takes al long time. So don’t forget if you are performing this upgrade in a production environment to get an updateslot of at least three hours!
In my case it took 100 minutes before the FP module was in the UP state again.

Now you have to accept the new EULA en go trough the initial setup again.


Firewall# session sfr 
Opening command session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.


Cisco ASA5506 v6.0.0 (build 1005)

firepower login: admin
Password: Admin123
Last login: Wed Nov  2 16:08:16 UTC 2016 on pts/0

Copyright 2004-2015, Cisco and/or its affiliates. All rights reserved. 
Cisco is a registered trademark of Cisco Systems, Inc. 
All other trademarks are property of their respective owners.

Cisco Fire Linux OS v6.0.0 (build 258)
Cisco ASA5506 v6.0.0 (build 1005)

Last login: Wed Nov  2 16:08:16 UTC 2016 on cron
Last login: Wed Nov  2 16:08:16 UTC 2016 on pts/0
You must accept the EULA to continue.
Press  to display the EULA: {Enter}
END USER LICENSE AGREEMENT

IMPORTANT: PLEASE READ THIS END USER LICENSE AGREEMENT CAREFULLY.  IT IS VERY
IMPORTANT THAT YOU CHECK THAT YOU ARE PURCHASING CISCO SOFTWARE OR EQUIPMENT
FROM AN APPROVED SOURCE AND THAT YOU, OR THE ENTITY YOU REPRESENT
(COLLECTIVELY, THE "CUSTOMER") HAVE BEEN REGISTERED AS THE END USER FOR THE

--Output Removed for the Sake of Brevity - Press Space Bar (A LOT!)--

Please enter 'YES' or press  to AGREE to the EULA:  YES

System initialization in progress.  Please stand by.  
You must change the password for 'admin' to continue.
Enter new password: Password123
Confirm new password: Password123
You must configure the network to continue.
You must configure at least one of IPv4 or IPv6.
Do you want to configure IPv4? (y/n) [y]: Y
Do you want to configure IPv6? (y/n) [n]: N
Configure IPv4 via DHCP or manually? (dhcp/manual) [manual]: {Enter}
Enter an IPv4 address for the management interface [192.168.45.45]: 
Enter an IPv4 netmask for the management interface [255.255.255.0]: 
Enter the IPv4 default gateway for the management interface []: 
Enter a fully qualified hostname for this system [firepower]: 
Enter a comma-separated list of DNS servers or 'none' []: 
Enter a comma-separated list of search domains or 'none' [example.net]: 
If your networking information has changed, you will need to reconnect.

For HTTP Proxy configuration, run 'configure network http-proxy'

Creating default Identity Policy.
Creating default SSL Policy.

Update policy deployment information
    - add device configuration
    - add network discovery
    - add system policy
    - add access control policy
    - applying access control policy

You can register the sensor to a Firepower Management Center and use the 
Firepower Management Center to manage it. Note that registering the sensor 
to a Firepower Management Center disables on-sensor Firepower Services 
management capabilities.

When registering the sensor to a Firepower Management Center, a unique 
alphanumeric registration key is always required.  In most cases, to register
a sensor to a Firepower Management Center, you must provide the hostname or 
the IP address along with the registration key.
'configure manager add [hostname | ip address ] [registration key ]'

However, if the sensor and the Firepower Management Center are separated by a
NAT device, you must enter a unique NAT ID, along with the unique registration
key.
'configure manager add DONTRESOLVE [registration key ] [ NAT ID ]'

Later, using the web interface on the Firepower Management Center, you must 
use the same registration key and, if necessary, the same NAT ID when you add 
this sensor to the Firepower Management Center.
> exit
Remote card closed command session. Press any key to continue.
 Command session with module sfr terminated.

Now login to your ASA via ASDM and you will see that your box is upgraded.

Backup ASA config with PowerShell

During my years in the networking business one of my frustrations is that it is very hard to backup the configuration of an ASA. There are some commercial products like Solarwinds that can accomplish this goal, but it costs money. An open source alternative like Rancid is also available but is pretty hard to configure.
Determined to find a solution I started searching the internet and came across some PowerShell scripts.  I’m not a PowerShell specialist, but I do know how to put together the separate scripts. So to be clear, I did not invent the scipts I just put them together.

So let’s take a look at the script:

Read-Host  “Enter Password” -AsSecureString | ConvertFrom-SecureString | Out-File c:\<map>\cred01.txt
–I don’t want to sent the password of the ASA user plain over the network. So with the above line I make sure the password is encrypted. It is possible to convert the password back to plain text, but then you’ll need access to the server. So it is not rocksollid save, but safer then sending the password in plain text over the internet. If you make sure that the useraccount only has minimal rights on the ASA, there is minimal change of getting unwanted guests on your ASA. The line converts the plain password to an encrypted password and writes it to a .txt file.

$ASApw = Get-Content “c:\<map>\cred01.txt” | ConvertTo-SecureString #-AsPlainText #-Force
$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($ASApw)
$ASApw = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
–The above three lines are needed to convert the encrypted password from the credentials file. This is needed because the ASA is unable to read an encrypted password.

$ASAIP = “<ip address>”
$ASAUser = “<username>”
$ASAEnablepw = $ASApw

#Modifies the ASA firewall
#Starts by writing a “commands” file#
echo en >>unicode.txt
echo $ASAEnablepw >>unicode.txt
echo “conf t” >>unicode.txt
echo “no pager” >>unicode.txt
echo “show run” >>unicode.txt
echo “pager 24” >>unicode.txt
echo “copy running-config startup-config” >>unicode.txt
echo “running-config” >>unicode.txt
echo exit >>unicode.txt
echo exit >>unicode.txt

#Converts the file to ASCII format (separate file)#
$lines = gc “unicode.txt”
$lines | out-file -encoding Ascii -filepath commands.txt
–The above lines writes the actual ASA commands to the commands.txt file.

#Using the command file and plink.exe connects and runs the commands#
c:/Windows/System32/plink.exe -ssh -l $ASAUser -pw $ASApw $ASAIP -m commands.txt > “c:\<map>\ASA.txt”
–To make things work you need to download the Plink tool. It is the command line version of Putty. It can be downloaded for free. I put the tool in de c:\windows\system32 folder, but you can place it everywhere you want. This line writes the configuration of the ASA to an .txt file.

#removes the files it created earlier#
del unicode.txt
del commands.txt

As you can see it’s actually a pretty easy script an above all it’s free.
To make a daily backup, create a task through “Task scheduler”.

Cisco Champion 2016

I’m proud to announce that I’m a Cisco Champion in Enterprise Networks for the second year in a row!

logo

Cisco Guest Blog

Check out my guestblog @ Cisco: http://blogs.cisco.com/perspectives/dmz-basics

 

Connect to OSPF area 0 over GRE tunnel

We all know that all OSPF areas have to be connected to area 0. But sometimes you encounter
a situation where it is not possible to connect an area to area 0. This can happen because of
poor network design or because two or more networks merge together. There are several options
to deal with this problem. In the CCNP curriculum you learn that a virtual-link is the way
to go on this problem. But there is an other option which is not as popular, but in my opinion
is even more elegant. I’m talking about a GRE tunnel solution.

Let’s take the topology as shown in the picture below.

OSPF_GRE_TOPOLOGY

Router R2 is connected to R1 in area 0. R2 and R3 are connected in area 1 and R3 is connected
to R4 in area 2. Which means that R3 has no connection to area 0.

Below the configurations of routers R1 to R4 before the configuration of the GRE tunnel.

R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
switchport access vlan 10
!
!
interface FastEthernet2/0
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.100.100.254 255.255.255.0
!
router ospf 10
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 10.0.0.0 0.0.0.3 area 0
network 10.100.100.0 0.0.0.255 area 0
!
R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
!
interface FastEthernet1/0
ip address 10.0.1.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.0.2 255.255.255.252
duplex auto
speed auto
!
!
router ospf 10
router-id 2.2.2.2
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 1
network 10.0.0.0 0.0.0.3 area 0
network 10.0.1.0 0.0.0.3 area 1
!
R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
!
interface FastEthernet1/0
ip address 10.0.1.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.3.1 255.255.255.252
duplex auto
speed auto
!
!
router ospf 10
router-id 3.3.3.3
log-adjacency-changes
network 3.3.3.3 0.0.0.0 area 1
network 10.0.1.0 0.0.0.3 area 1
network 10.0.3.0 0.0.0.3 area 2
!
R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
switchport access vlan 10
!
!
interface FastEthernet2/0
ip address 10.0.3.2 255.255.255.252
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.200.200.254 255.255.255.0
!
!
router ospf 10
router-id 4.4.4.4
log-adjacency-changes
network 4.4.4.4 0.0.0.0 area 2
network 10.0.3.0 0.0.0.3 area 2
network 10.200.200.0 0.0.0.255 area 2
!

To make this topology work there needs to be a connection from R3 to area 0. To make this happen
make the following configurations to router R2 and R3.

R2
!
interface Tunnel0
ip address 172.18.2.1 255.255.255.0
tunnel source Loopback0
tunnel destination 3.3.3.3
!
!
router ospf 10
network 172.18.2.0 0.0.0.255 area 0
!
R3
!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
tunnel source Loopback0
tunnel destination 2.2.2.2
!
!
router ospf 10
network 172.18.2.0 0.0.0.255 area 0
!

If you do a “show ip ospf neighbors” on R2 you can see there is a full neighborship between router
R2 and R3 in area 0.

show ip ospf neighbors R2-R3
And with the “show ip route” command you see the network from “area 2” is now in the table.

show ip route R2-R3
Now ping from PC1 to PC2 and this will succeed.

ping PC2-PC2

More interesting is a traceroute from PC1 to PC2, this will show the traffic is actually going
trough the GRE Tunnel!

traceroute PC1-PC2

GRE over IPsec tunnels (Part 2)

In my last post I wrote about GRE over IPsec, but only with static routes. One of the benefits of GRE over IPsec tunnels is that you can send multicast traffic  over the tunnel. With a plain IPsec tunnel this is not possible. So to prove that multicast traffic can cross the GRE over IPsec tunnel I took the topology of my last post and removed the static routes from the configuration of the HQ and Branch routers.
Below the used topology:
GRE_over_IPsec

Then configure the EIGRP configuration on both routers.

R1#sh run | se eigrp
router eigrp 10
network 10.10.10.0 0.0.0.255
network 172.18.2.0 0.0.0.255
no auto-summary
R1#

The syslog below confirms that the EIGRP adjacency is up and running:
EIGRP_adj

Then use the “debug ip packet detail” command to verify that multicast is used and allowed:
EIGRP_multicast

To prove the solution is working check the routing table.
sh_ip_route

And that’s all there to configure dynamic routing over a GRE over IPsec tunnel.

GRE over IPsec tunnels (Part 1)

Why a IPsec over a GRE tunnel? A couple of things come to mind. Things like encryption of tunneled traffic and the possibility to send multicast traffic over the tunnel.

GRE on itself only tunnels traffic by encsapsulating the traffic within an additional GRE and IP header. But if you Wireshark the traffic it’s just plain text and therefore readable. In a plain IPsec tunnel it is not possible to send multicast traffic over the IPsec tunnel. But if you’re using OSPF or EIGRP you need to be able to send multicast traffic over the IPsec tunnel.

To prove the above I created a case study. First I will show how to configure a normal GRE tunnel, after that a GRE over IPsec tunnel with static routes. In a separate post I will write about GRE over IPsec tunnel with dynamic routing.

So for this case study I used the topology as shown below.

GRE_over_IPsec

Below the configuration of the HQ router, the branch router is the same but use different IP addresses.

First configure the physical internet facing interface, the vlan interface for the internal subnet and the needed routes.

!
interface FastEthernet1/0
ip address 109.232.100.1 255.255.255.0
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.10.10.1 255.255.255.0
!
ip route 10.10.11.0 255.255.255.0 172.18.2.1
!

Then create the tunnel interface

!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
ip mtu 1400
tunnel source FastEthernet1/0
tunnel destination 109.232.100.2
!
Don’t forget to change the MTU size to 1400, because of the overhead created by the GRE encapsulation.

Now it’s possible to ping from PC1 at HQ to PC3 at the bracnch office. If you look at the traffic you will see it’s encapsulated in a GRE packet, but there is no encryption:
GRE_capture

To create an IPsec connection do the following on the HQ and Branch routers:
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key sjiekismiechdat address 109.232.100.2
!
!
crypto ipsec transform-set test esp-3des esp-md5-hmac
!
!
access-list 101 permit gre host 109.232.100.1 host 109.232.100.2
!
!
crypto map s-2-s 10 ipsec-isakmp
set peer 109.232.100.2
set transform-set test
match address 101
!
!
interface Tunnel0
crypto map s-2-s
!
!
interface FastEthernet1/0
crypto map s-2-s
!

Now send some traffic from PC1 to PC3 and use the “show crypto session” command to verify that the GRE over IPsec connection is established:
crypto_session

Now we know the tunnel is up and it’s possible to exchange traffic between PC1 at the HQ and PC3 at the branch office. Now let’s look at the traffic with Wireshark.
ESP

As you can see there are only ESP packets, in other words the encryption of the IPsec tunnel is working.

In my next post I will talk about dynamic routing with GRE over IPsec.