In a previous blog, I’ve written about the differences between Firepower Threat Defense and ASA software. And although the basic OS appears to be ASA with Snort set in between ASA ingress and egress, some basic concepts of the ASA (or actually the PIX) have disappeared in FTD. And it will have an impact once you migrate from ASA (with or without firepower) to FTD devices
The Cisco ASA firewall has implemented the concept of security levels on interfaces. Each interface must have an interface name and interface level (IP-address is only necessary if you use routed or IRB interfaces). The concept for this is quite easy, let’s take the basic ASA edge deployment into mind.

With interface security levels the ASA keeps two principles into mind when a packet comes into the firewall for a new connection:
- Traffic is always allowed from a higher security level to a lower security
level, unless an access-listprohibts this - Traffic is never allowed from a lower security level to a higher security
level, unless there is an access-list explicitly permitting the traffic and a static translation is created
So, in this example, the client with internal IP 10.1.1.10 is allowed to go outbound to the
If you then take into account that IOS/PIX/ASA access-lists always have an implicit deny
In FTD things are working quite differently
Element | Description |
source zone(s) | Within FTD it is possible to logically combine different interfaces into a single zone. One or more zones can be used as selection criteria |
destination zone(s) | Also one or more destination zones can be used as selection criteria, for |
source network(s) | This is the classic selection criteria for a layer3 firewall, based on one or more source IP networks. |
destination network(s) | This is the classic selection criteria for a layer3 firewall, based on one or more destination IP networks. |
VLAN’s | It is possible to match traffic based on the |
Users | This is part of the next generation firewall that is inside FTD, per user (or group) policy rules can be matched |
Applications | Also part of the next generation firewall, in which a lot of applications are already defined. It is also possible to define custom applications using openAppID as well |
Source port(s) | Classic criteria for the source ports. Within FTD there is a default group called “high ports” that you can use for client connections |
Destination port(s) | Classic match criteria for the destination ports. It is possible to use one or more ports to match |
ISE/SGT attributes | This is used if you have a pxGrid ISE integration with FirePower and wish to match on |
URL Categories | This is also part of the next generation firewall feature set, in which you can use URL categories (like |
File Policy | This option (within the rule details) specifies which file detection policy is to be used in AMP for networks. |
IPS Policy (with |
It is possible to define different Intrusion Policies within FMC. Within a specific |
Action | The resulting action that FTD will take when the packet is matching this rule. |
FTD Policy actions
There are different actions that FTD can take once a packet has matched the access rule, being
Action | Description |
Allow | This traffic |
Block with reset | Block this packet and send TCP resets to client and server to reset this packet |
Interactive Block | This is similar |
Interactive Block with Reset | This is similar |
For grouping
But what happens if no rule inside the policy is matched? Well, then the default Action comes into play. As soon as you create a new access policy, FMC asks what the default action will be of the new policy

Block all traffic | Just block all traffic, similar to the implicit deny any any |
Intrusion prevention | Allow |
Network discovery | Allow traffic for |
Within a Firepower on ASA rule, I usually choose the “Intrusion Prevention” or “network discovery” rule, as there is still a firewall outside the FirePower module that has access-lists as well.
But in FTD that is not true!! If you choose “network discovery” or “intrusion prevention“, you will basically allow
If you want to change this

So in summary, if you start working with FTD and come from an ASA background, make sure your that you define the access rules both ways and have explicit block rules in your access policy. Either via the default action or per traffic-flow in a category.
This is an easy to understand and useful blog on Firepower. Thank you!
Actually, It’s a very nice article for the people who are interested to migrate to FTD from the ASA’s.