Cisco FTD Prefilter Policy is the first level of access control and gives the capability to allow or filter a specific traffic at L3/L4 without the need to be forwarded to CPU intensive access control policy. It is also known as “fastpath” because it quickly allows or denies traffic, without deep packet inspection.
For example, you might want to allow ICMP for troubleshooting purposes and also drop Telnet traffic for security reasons. They do not need to be inspected by CPU-intensive engines like access-control policy, IPS policy, file policy and so on.
cisco FTD prefilter Topology
Just to review the topology, we have one FTD with two zones, inside and outside zones with IP subnet 192.168.10.0/24 and 192.168.1.0/24. Outside zone is connected to internet. inside zone is connected to the LAN. There are two computers for testing purposes, one with IP address 192.168.10.10 in inside zone and one with IP address 192.168.1.88 in outside zone.
As an example we will permit ICMP traffic and drop Telnet traffic in prefilter policy which will process the traffic before any access control.
Even if the opposite of prefilter policies are configured in access control policy, we expect that pre-filter policies to be applied at the first level with higher priority.
Cisco FTD Prefilter Configuration
Block ICMP and Allow Telnet in Access Control Policy
Before we start configuring pre-filter policy, we will configure access control policy to block ICMP and allow telnet, exactly the opposite of what we are going to implement in the pre-filter policy.
Configure Prefilter Policy
In prefilter policy, there is a “default prefilter policy”. No rule is configured in this policy, except for the default rule that all plaintext tunnel traffic are analyzed, which means it is forwarded to the access control policy for deep inspection.
In a few minutes I’ll be talking about tunnel traffic in the prefilter policy. For now we will ignore it.
Prefilter Policy Action Options
We will add a new prefilter policy, “rayka_pre_filter_policy”. In this policy we will add two rules. fastpath ICMP and block telnet traffic between any two zones.
There are three options for the action to be taken for each rule.
Analyze: it will forward the traffic to the access control policy for deep inspection.
Block: it drops traffic that matches the rule
Fastpath: This traffic bypasses any extra inspections and will be forwarded to egress interface.
We will also enable logging in prefilter rules so we can check if they are matched.
“rayka_pre_filter_policy” must be enabled in access control policy since by default, “Default Prefilter Policy” is enabled. Prefilter policy must be enabled in access control policy.
Monitor Prefilter Policy Logs
Now we can check if our prefilter policy works with sending icmp and telnet traffic from inside zone to outside zone and checking if they are matched with prefilter policy or access control policy.
As we expect, telnet traffic is dropped and icmp traffic is permitted as we have configured in prefilter policy.
Logs can be also checked to make sure that traffic are matched with prefilter policy and not with access control policy.
Tunnel Traffic fastpath with Prefilter Policy
with prefilter policy, you also have the option to fastpath or block tunnel traffic like GRE and IP-in-IP Tunnels. This is because tunnel traffic has a large overhead over firewall to be deep inspected since they are twice encapsulated.
Therefore, you can filter tunnel traffic as a whole if you are not allowed to have tunnel traffic in your network, or you can fastpath tunnel traffic between specific endpoints.
When you choose “analyse” action for a specific tunnel and endpoints, that means that tunnel traffic must be forwarded to access control for further processing.