Introduction to Cisco Firepower Threat Defense (FTD) on ASA 5500-X

Introduction to Cisco Firepower Threat Defense (FTD) on ASA 5500-X

This week I’m working on testing out the new Firepower Thread Defense (FTD) 6.1 image for the ASA 5500-X, and hopefully getting familiar with how things work in the new setup. One of the things I’m most excited about is the onboard management interface — this is an HTML based interface that no longer requires ASDM, which is a huge step in the right direction, in my opinion.

I’m going to go cover the reimage process and see what a box looks like from a fresh start, as well as give some overviews of the management interface and the CLI. I’ll try not to dig too deep in this introduction but I’m hoping to provide a lot of screenshots of various screens and things I notice during the setup.

For your reference, you can find the 6.1.0 release notes here, and the Firepower Threat Defense 6.1.0 Configuration Guide here.


I’ll cover the gist of the reimage process now, but you can find the full instructions here.

The big thing to note during the reimage, is that it will wipe out everything you have on your device — configuration, ASA/ASDM images, Anyconnect packages — everything. So be sure to backup anything you want to keep.

To complete the reimage you’ll need console access to your ASA, a TFTP server, and the FTD cdisk file for your platform.

Let’s get started.

  1. Verify your hardware is the correct ROMMON version. FTD requires minimum version of 1.1.8. You can verify this using the show module command. Look at the Fw Version value.
    5515-X# sh module
    Mod  Card Type                                    Model              Serial No.
    ---- -------------------------------------------- ------------------ -----------
    0 ASA 5515-X with SW, 6 GE Data, 1 GE Mgmt, AC ASA5515            XXX
    Mod  MAC Address Range                 Hw Version   Fw Version   Sw Version
    ---- --------------------------------- ------------ ------------ ---------------
    0 84b8.022a.133f to 84b8.022a.1346  1.0          2.1(9)8      9.4(2)6
  2. Reload your ASA
  3. Interrupt the boot process by pressing ESC when prompted.
  4. In ROMMON, configure your network settings:
    rommon #0> interface gigabitethernet0/1
    rommon #1> address
    rommon #2> server
    rommon #3> gateway
    rommon #4> file ftd-boot-
    rommon #5> set
  5. Confirm your settings and commit the changes using the sync command
    rommon #6> sync
  6. Initiate the image download using the tftpdnld command:
    rommon #7> tftpdnld
  7. After the downloaded, the device will load the image and you’ll be at an FTD Boot console. From here use the setup command to configure the basic parameters for your box (Hostname, address, gateway, DNS, NTP).
  8. The last step is to download and install the actual FTD install package.
    > system install noconfirm

    The documentation says this step could take up to 30 minutes, but mine finished in less time.

Configuring the ASA using Firepower Device Manager

Once the box is back online, we’re now ready to test out the new onboard management interface, Firepower Device Manager. Browsing to the management address, we’re presented with a screen that almost brings a tear to my eyes:


Finally! After so many years of fighting with ASDM and trying to find the right Java version, we’re finally able to use a built in web interface. Ignore any limitations with the available functionality in FDM for now — just savor the moment.

The default login is admin and Admin123

After login we’re have to go through an initial setup wizard.


That’s fine, I guess, so let’s move through it. I’ll select Gig0/5 as my outside interface since I don’t have it hooked up to anything but the LAN right now.


Next we’ll setup the outside interface addresses for IPv4 and IPv6:


And the Management interface DNS. I choose DHCP during the CLI setup, so this info was already populated for me. All I did was change the hostname.


Click Next and wait patiently….


Uh oh, bold red text is bad, right?


Ok, fine. So it really wants to be able to talk to the outside world during the setup. My test box is remote, and since I only had 2 interfaces connected, I figured I would configure the box without an internet connection for now. Guess FDM had other ideas. So I’ll go back and change the outside interface to be Gig0/0, and we’ll leave the inside disconnected.

I went back through the last couple of screens after changing the outside interface, and was then asked to configure NTP:


Now we get to the licensing page. It looks like FTD will only use Smart Licenses, so I’ll be sure to familiarize myself with that in the very near future. For now I’ll use the 90-day eval license.


And bingo, we’re ready to rock and roll!


The Dashboard

After the confirmation window, we land at the device dashboard:


There’s not much to say about this. It’s got a nice clean look, and it gives you quick access to most of the basic settings on your box. I would compare it to the Device Setup and Device Management sections from ASDM.

Monitoring Menu


The System Dashboard within the monitoring menu is really similar to the ASDM landing page — you have some graphs of throughput, CPU, and Memory, as well as event counts and Disk usage. My test box doesn’t have anything connected to it, unfortunately, so I have to apologize since my screenshots won’t be showing much more than the layout.

If you look down the menu on the left side of the screen, you’ll see the Firepower categories. This is the same info you would see in the Firepower Management Center (FMC) console, or your Firepower Dashboards within ASDM if you’re running it direclty on the box.

Policies Menu

When you click on the Policies menu item, you land on the Access Control page. This is where you will build your policies for allowing/denying traffic and is analagous to the ASDM Access Rules page. There is a default rule already installed (part of the initial setup process) allowing all traffic from inside to outside.


You’ll quickly notice that much like other sections in the management interface, the access rule page feels a bit like the FMC, or even like the Palo Alto firewall interface, for those of you who are familiar with PA. The similarities are even more apparent when you add an access rule:


Clicking on the NAT item, you’ll see the default NAT rule that was also added during the intial setup:


Adding a new NAT rule is just as easy as it was in ASDM, although now you are required to create objects for everything:



Something to note here that differs from ASDM — hovering over objects does not reveal the IP address of the object, only the object name again.

The last page under the Policies menu is Identity and this is where you configure policies on obtaining user identity information.

The first thing to do here is define where you will pull identity information. You can choose between Active Directory or … Active Directory. AD is currently the only supported server type, and you’re only allowed to configure one server here.


Once you have a Directory Server configured you can add identity policy rules. The two types of Authentication available are Active and No Auth. Active Authentication is only used on HTTP traffic, per this note in the help documentation:

Keep in mind that regardless of your rule configuration, active authentication is performed on HTTP traffic only. Thus, you do not need to create rules to exclude non-HTTP traffic from active authentication. You can simply apply an active authentication rule to all sources and destinations if you want to get user identity information for all HTTP traffic.

Another thing to note from the help documentation is that Identity policies don’t actually block traffic — they’re used for gathering information only.

I won’t dig too deep into this right now, but there are two types of Active Authentication – HTTP and HTTP response, and one transparent method that uses integrated windows Authentication.

Objects Menu

Moving over to the objects menu, you’ll see that this is a very familiar space where we can define our host/network objects, port/port group objects, and security zones. The only thing to notice here is that we can configure application filter, URL, and geolocation objects for use in access control rules.


One final note about the Policies and Objects menus, is that much like ASDM, changes are queued for delivery to the device. As you begin making changes, you’ll noticean icon on the top bar with an orange dot:


Seems simple enough — queue changes to deliver them in bulk – got it. One thing I couldn’t find, however, was a cancel or reset changes button. So at this point in time it appears that changes made through the FTD interface are a one way street — better make sure you backed up your config before you started messing around with things.

On the plus side though, after the deployment is completed you can see a record of the changes that were made:



The beloved ASA CLI has also changed with the FTD image. After you first login, you can see that we are no longer in Kansas, er, in ASA land anymore. Instead, we’re running the Cisco Fire Linux OS:

    Copyright 2004-2016, 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.1.0 (build 37)
    Cisco ASA5515-X Threat Defense v6.1.0 (build 330)


At first glance things appear pretty similar — you can still run most of your show commands, including:

  • Viewing translations
          > show xlate
            1 in use, 1 most used
            Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
               s - static, T - twice, N - net-to-net
            NAT from outside: to any:
                flags sIT idle 51:12:07 timeout 0:00:00
  • connections
    > show conn all
    8 in use, 14 most used
    UDP outside NP Identity Ifc, idle 0:01:23, bytes 300, flags -
    UDP outside NP Identity Ifc, idle 0:01:07, bytes 600, flags -
    UDP outside NP Identity Ifc, idle 0:00:40, bytes 900, flags -
    UDP outside NP Identity Ifc, idle 0:00:37, bytes 900, flags -
    UDP outside NP Identity Ifc, idle 0:01:19, bytes 900, flags -
  • routes
    > show route
    Codes: L - local, C - connected, S - static, 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, V - VPN
        i - IS-IS, su - IS-IS summary, 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, + - replicated route
    Gateway of last resort is to network
    S* [1/0] via, outside
    C is directly connected, outside

and much, much more!

Suffice it to say that a lot of what you’re used to seeing from the CLI is still available as it relates to viewing your setup and troubleshooting. The big gotcha, however, is that it appears you can’t easily make changes from the CLI. There is no configure terminal any more, and the configuration commands left available to you are minimal:

> configure
  disable-https-access   Disable https access
  disable-ssh-access     Disable ssh access
  firewall               Change to Firewall Configuration Mode
  high-availability      Change to Configure High-Availability Mode
  https-access-list      Configure the https access list
  log-events-to-ramdisk  Configure Logging of Events to disk
  manager                Change to Manager Configuration Mode
  network                Change to Network Configuration Mode
  password               Change password
  ssh-access-list        Configure the ssh access list
  ssl-protocol           Configure SSL protocols for https web access.
  user                   Change to User Configuration Mode

Some of the available configure commands are a bit misleading as well. For example, configure firewall does not allow you to actually change anything about the firewall other than routed or transparent mode. Clearly the goal here is to get you out of the CLI and back into the Web interface. In fact, I wasn’t able to find anything really useful to configure from the CLI — just basic items that you would use to setup the box in the first place. If I find any more useful details I’ll update this post, but for now I’ll just assume that CLI is for troubleshooting only, and all configuration should be done from the GUI.

My Observations

First of all, I love the direction this is going and have wondered for years why Cisco stayed with ASDM given that the competitors are using built-in interfaces. That being said, I also realize and acknowledge that it takes a lot of effort to move away from a management tool like ASDM. I was at Cisco Live this year in Las Vegas, and the ASDM angst was palpable. In fact, when FTD was mentioned in one of my sessions, the crowd went wild when the presenter made the comment that there was no more ASDM in FTD. Many of us have years of experience with ASA’s (or even PIX), so ASDM is very comfortable to us, but it’s hard to deny the anguish it has caused over the years.

As for Firepower Threat Defense itself, it’s a great start and I can’t wait to see what the next releases bring. I’m calmly reminding myself that this is the dot zero first 6.1 release of FTD. Things take time, and the best things take more time.

Cisco EZVPN with IOS Router and ASA

I had an interesting request come across my desk, where I needed to configure a site-to-site VPN for some internet connected devices, but the devices were not allowed to connect internally to our network. So basically, I needed to tunnel the internet traffic back to our headend without allowing access to the internal network. The remote location also wouldn’t have a static IP. Having used EZVPN in the past, I figured this would be another great use case. Unfortunately I spent way too many hours trying to find a good example of how to get this setup working, so I figured I’d share my config for anyone else who may be struggling with a similar setup.


EZVPN with IOS and ASA

IOS Router Config (EZVPN Client)

crypto ipsec client ezvpn ez
 connect auto
 group MyTunnelGroup key MySecretKey
 mode client
 username MyVPNUser password MyPassword
 xauth userid mode local
interface Fa0/0
 description WAN Interface
 ip address dhcp
 crypto ipsec client ezvpn ez
interface Fa0/1
 description LAN Interface
 ip address
 crypto ipsec client ezvpn ez inside

The first section defines the properties for the EZVPN connection, and there are 3 items that need special attention:

  1. The group and key you configure here will match the TunnelGroup name and IKEv1 key you configure on the ASA
  2. The username and password are also defined on the ASA. This is the actual user that is being authenticated.
  3. The xauth mode needs to be configured as local so the router doesn’t have to prompt for credentials.

Other items to note:

  1. There are three modes for EZVPN, Client, Network Extension, and Network Plus. If this were a true L2L VPN, I’d use Network Extension or Network Extension Plus so that there was direct IP-IP connectivity between hosts on either side of the VPN. Since I don’t need that, I’m configuring Client mode which is similar to a PAT for all client traffic.
  2. The peer IP will be the outside address of your EZVPN server.

ASA Configuration (EZVPN Server)

access-list EZVPN-ACL standard deny
access-list EZVPN-ACL standard permit any4
group-policy MyGroupPolicy internal
group-policy MyGroupPolicy attributes
 dns-server value
 vpn-access-hours none
 vpn-simultaneous-logins 3
 vpn-idle-timeout 30
 vpn-session-timeout none
 vpn-filter value EZVPN-ACL
 vpn-tunnel-protocol ikev1
 group-lock none
 split-tunnel-policy tunnelall
 split-tunnel-all-dns enable
 vlan none
 nac-settings none
username MyVPNUser password MyPassword
username MyVPNUser attributes
 vpn-group-policy MyGroupPolicy
tunnel-group MyTunnelGroup type remote-access
tunnel-group MyTunnelGroup general-attributes
 default-group-policy MyGroupPolicy
tunnel-group MyTunnelGroup ipsec-attributes
 ikev1 pre-shared-key MySecretKey

The Tunnel Group defines the preshared key for the connection that was referenced in the group MyTunnelGroup key MySecretKey command on the client. The Tunnel Group config also points to a Group Policy that will control the policy for the tunnel. I created a new policy, but you could also use the default DfltGrpPolicy if it fit your needs.


The beautiful thing about EZVPN is that all of the policy aspects are controlled at the Server side. So while the current requirement is to block access to internal resources, I could easily change that on the server side without worrying about messing up the config on the client and bringing the tunnel down.

Redistributing Anyconnect VPN addresses into OSPF on Cisco ASA

I’m a big fan of the Cisco Anyconnect VPN client due to its easy configuration, and the relative ease of deployment to end users. When you deploy an Anyconnect VPN on your ASA, one of the important tasks is to decide how to advertise the VPN assigned addresses into the rest of your network. Fortunately, this is easy to accomplish using route redistribution.

Basic Setup

In this example, my VPN pool will be assigned from the range, and I will redistribute these routes into OSPF. Notice that the ASA automatically creates a static host route for a connected client:

ASA# sh route | i 192.168.254
S [1/0] via, Outside

So we have the building blocks for what we need, now let’s look at the configuration.

There are several different ways to accomplish this task, but I’ll demonstrate what I typically use.

Redistributing into OSPF

First, we’ll create a prefix list to match the address pool for our Anyconnect clients:

prefix-list VPN_PREFIX seq 1 permit le 32

This prefix list entry matches the subnet, as well as any routes with a mask less-than or equal to 32 bits. This works great, because our routes will all be /32.

Next we’ll create a route-map that we can reference inside OSPF:

route-map VPN_POOL permit 1
    match ip address prefix-list VPN_PREFIX

And finally, we’ll add enable redistribution in OSPF:

router ospf 1
    redistribute static subnets route-map VPN_POOL

If we look the routing table on another router in our network, we should see the route:

RTR#sh ip route | i 192.168.254
O E2 [110/20] via, 00:5:03, Vlan85

Advertising the subnet instead of individual host routes

If you like to keep your routing tables uncluttered, you might be inclined to only redistribute the entire VPN prefix, instead of the /32 routes. The important thing to remember here is that OSPF will not redistribute a route that is not already in the routing table.

We’ll simply add a static route for the VPN prefix:

route outside

Without any other modifications, we will now see routes like this in our network:

RTR#sh ip route | i 192.168.254
O E2 [110/20] via, 00:07:28, Vlan85
O E2 [110/20] via, 00:07:28, Vlan85

But we want to get rid of the /32 routes. So we have two options now:

  1. Modify the prefix-list to match only the /25 route
  2. Modify the OSPF redistribution command to ignore subnets.

Option 1: Modify the prefix-list

We’ll change the prefix list so we don’t even consider subnets with different masks:

no prefix-list VPN_PREFIX seq 1 permit le 32
prefix-list VPN_PREFIX seq 1 permit

Our redistribution command still has the subnets keyword, but since the prefix list won’t even allow smaller prefix lengths, we end up with just the one route.

Option 2: Modify the OSPF redistribution command

You can also remove the subnets keyword from the redistribution command:

router ospf 1
    redistribute static route-map VPN_POOL

This way it doesn’t matter if the prefix-list matches longer routes, OSPF just won’t redistribute them.

Final Configuration

In the end we have a configuration that looks something like this:

route outside
prefix-list VPN_PREFIX seq 1 permit
route-map VPN_POOL permit 1
 match ip address prefix-list VPN_PREFIX
router ospf 100
 redistribute static route-map VPN_POOL

The ASA will still show all of the /32 routes, plus the /25 route:

ASA# sh route | i 192.168.254
S [1/0] via, Outside
S [1/0] via, Outside

But routers inside the network will only see the /25 route:

RTR#sh ip route | i 192.168.254
O E2 [110/20] via, 01:45:03, Vlan85

I didn’t talk about modifying any of the OSPF metrics as the routes are being injected, but that would be something to consider if you do this in your environment.