Configuration Changes
This is by far the biggest difference coming from ASA. In ASA-land, most of us are either making changes line-by-line in the CLI or, if you hate having a clean and legible config, using ASDM. With FTD you have two options for deployment that will directly influence how you interact with your firewall(s).
- Option 1 is to use the Firepower Management Center. This comes in both virtual and hardware appliance flavors. The FMC is designed to manage policies across multiple Firepower devices, but can be used to manage a single device. This option provides the most features, and most complete Firepower experience. You'll deploy your management center, and via the management interface on the FTD, register the FTD with the FMC.
- Option 2 is to use the onboard Firepower Device Manager (FDM). After giving your FTD a management IP address, you'll connect directly to the management IP via web browser to make all configuration changes. As of 6.2.2, some of the limitations you'll find with FTD are as follows:
- No dynamic routing
- Limited Identity policy options (AD integration for identity based access control). Limited in that you can only do active authentication, meaning the user is redirected to a Web Portal and has to sign-on.
- IPS and AMP policies are static/prebuilt policies that can't be tweaked.
- No Etherchannel
I will say this about FDM though, what it lacks in features is makes up for in appearance. See for yourself.
 |
| Firepower Management Console |
 |
| Firepower Device Manager |
So it's from here that you'll configure your access-lists, NAT, Interface addressing, etc, etc. Which brings us to another difference. In Firepower changes are not made in real time (contrary to those of us who use CLI heavily with ASA). Instead, you'll make whatever changes you intend on, then click "Deploy" to actually push/apply those changes to your Firepower device. This CAN be a little slow. If you're practicing with a virtual FTD (which I highly recommend) deployments can take less than a minute. However if you're working with a physical firewall, they may take several minutes to complete. My 5506-X for example, on average, takes ~2 1/2 minutes.
Packet Processing & ACLs
In ASA we have a concept of security levels. Out of the box behavior is that traffic from higher security levels is allowed to lower security levels, but not vice versa. This concept goes away in FTD. In FTD we have "Security Zones" which are essentially tags we use in policy configuration, and they don't have any other inherent properties that I'm aware of (no more nameif inside = security-level 100). So we need to be explicit about what traffic is allowed from what zone to what destination zone. Which brings me to the next big difference, ACLs. In ASA we have the option of per-interface ACL. You create an access-list specifically for, say, traffic coming from the outside interface inbound. This is another concept that's largely gone in FTD. Instead, we have an ACL applied globally (which you could do in ASA, but would normally be in conjunction with per-Interface ACLs). This isn't as cumbersome as it sounds though, so long as you're smart about creating your ACEs, we can create rule categories within our access control policies that help us keep things organized. Important to note as well, within the Access Control Policy (ACP), it's processed top to bottom, just like traditional ACLs. So keep that in mind when building out separate rule categories.
 |
| ACP Rule Category Example |
NAT and ACL; here's where we find some common ground. Just like on ASA 8.3+, ACLs are processed POST NAT. That means, like in the example above, if you have a Web Server being translated through your FTD, access control rules for allowing access to the Web Server need to specify the private/real IP of the server. Not the NAT IP.
The Command Line
Is. Not. Dead. Rejoice my CLI junkies. Rejoice. While it can't be used for configuration, if you're like me and have honed your troubleshooting skills on the ASA CLI... those skills aren't lost on FTD. Regardless of if you go the FMC or FDT route for deployment, can you can still SSH to the management IP (or console in you like) the Firewall itself and have full access ASA style commands. The shell does look different, but commands do indeed work. For example, lets look at output from a couple troubleshooting commands.
> show version
-------------------[ LAB-HQ-FW1 ]--------------------
Model : Cisco Firepower Threat Defense for KVM (75) Version 6.1.0 (Build 330)
UUID : 260e3aee-ce59-11e7-a99a-a6e8d2e44557
Rules update version : 2017-11-20-002-vrt
VDB version : 270
----------------------------------------------------
> show conn
5 in use, 44 most used
UDP inside 172.16.10.250:123 outside 104.131.139.195:123, idle 0:00:01, bytes 96, flags - N
UDP inside 172.16.10.250:123 outside 38.229.71.1:123, idle 0:01:53, bytes 96, flags - N
> show running-config
: Saved
:
: Serial Number: {omitted}
: Hardware: ASAv, 8192 MB RAM, CPU Pentium II 2660 MHz, 1 CPU (4 cores)
:
NGFW Version 6.1.0
!
hostname firepower
enable password {omitted} encrypted
names
!
interface GigabitEthernet0/0
nameif outside
cts manual
propagate sgt preserve-untag
policy static sgt disabled trusted
security-level 0
ip address dhcp setroute
!
interface GigabitEthernet0/1
nameif inside
cts manual
propagate sgt preserve-untag
policy static sgt disabled trusted
security-level 0
ip address 172.16.10.2 255.255.255.0
!
interface GigabitEthernet0/2
shutdown
no nameif
no security-level
no ip address
!
interface Management0/0
management-only
nameif diagnostic
cts manual
propagate sgt preserve-untag
policy static sgt disabled trusted
security-level 0
no ip address
!
ftp mode passive
ngips conn-match vlan-id
dns domain-lookup diagnostic
access-list CSM_FW_ACL_ remark rule-id 9998: PREFILTER POLICY: Default Tunnel and Priority Policy
access-list CSM_FW_ACL_ remark rule-id 9998: RULE: DEFAULT TUNNEL ACTION RULE
access-list CSM_FW_ACL_ advanced permit ipinip any any rule-id 9998
access-list CSM_FW_ACL_ advanced permit 41 any any rule-id 9998
access-list CSM_FW_ACL_ advanced permit gre any any rule-id 9998
access-list CSM_FW_ACL_ advanced permit udp any eq 3544 any range 1025 65535 rule-id 9998
access-list CSM_FW_ACL_ advanced permit udp any range 1025 65535 any eq 3544 rule-id 9998
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: LAB_DEFAULT - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434432
!
[omitted for brevity]
!
nat (inside,outside) after-auto source dynamic any interface description NERD Default NAT
access-group CSM_FW_ACL_ global
router ospf 1
network 172.16.0.0 255.240.0.0 area 0.0.0.0
no nsf cisco helper
no nsf ietf helper
no capability opaque
no capability lls
log-adj-changes
default-information originate
> show ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
172.16.0.1 1 FULL/BDR 0:00:32 172.16.10.1 inside
> packet-tracer input inside tcp 172.16.32.107 80 8.8.8.8 80
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 172.19.0.1 using egress ifc outside
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434432
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: LAB_DEFAULT - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached
Phase: 4
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection advanced-options UM_STATIC_TCP_MAP
service-policy global_policy global
Additional Information:
Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) after-auto source dynamic any interface description LAB Default NAT
Additional Information:
Dynamic translate 172.16.32.107/80 to 172.19.0.160/80
Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) after-auto source dynamic any interface description LAB Default NAT
Additional Information:
Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 73360, packet dispatched to next module
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
>
You get the idea. It's all there. You can look access-list hits, check on IKEv1 or IKEv2 security associations or look at IPsec SAs. Which was welcome news for me, however if you're a GUI user... fear not lol. These tools are indeed available in the Management Center. In 6.1 they're a bit limited and can be accessed from System > Health > Monitor. Then clicking on the firewall you want to execute these commands on, and selecting advanced troubleshooting. In 6.2 they've built these tools up a pretty good deal, and can now be accessed from Devices > Device Management and selecting the 
icon for Advanced Troubleshooting.
icon for Advanced Troubleshooting. |
| Firepower 6.1 Advanced Troubleshooting |
 |
| Firepower 6.2 Advanced Troubleshooting |
Different, but "good" different?
First off, I want to acknowledge that I didn't cover a lot of things in this post. That was intentional though. Firepower brings to the table some absolutely amazing (and much needed) features. Features like SNORT IPS, Advanced Malware Protection (AMP), URL and Application Filtering. In future posts I'll share my thoughts on these features, but spoiler alert - I love them lol. That said, as an ASA fanboy and CLI junkie I'm surprised how much I like working with FTD. I do leverage my ASA style troubleshooting, which makes the transition significantly easier. All that changes from a troubleshooting perspective with FTD is how your react when you discover configuration issues. Instead of adding/removing some lines from the config, now we're going into our management console (be it FDM or FMC) to make those changes. I thought this would be disruptive to my work flow, or maybe it would fundamentally slow me down... but it doesn't. At least until I click "Deploy" on my changes lol. Well, that's all for this post. Again, in future posts I hope to cover deploying an FTD from scratch and working with some of the NGFW features that set this platform apart.
