FTD behaviour with BLOCK ANY ANY rule

[psycoma]

Hello All,

We have an FTD Active/Standby appliances of 4115 with FMC cluster of 6.4.x managing it. We run it in transparent mode because of historical reasons. It works fine, but one thing I don't really understand. In ACP we have default action as Network Discovery, while as a last rule we have any/any rule with a BLOCK as an action.

We have multiple rules above BLOCK one, they are working pretty fine and allowing traffic. But recently we have started troubleshooting one of few new flows and it uncovered weird events. For example, we suppose to have traffic between hosts A and B, it is crossing FTD appliance, although NO RULES were created for it yet with those specific source zone/destination zone/src network/dst network etc. That's why I was under impression it should be denied by the last rule, which is blocking anything else and logging it. But in traffic capture I see that traffic's SYN leaving outgoing interface of FTD (no SYN ACK sent back as this traffic seems to be blocked on remote end) and in SYSLOG output I see that TCP connection been built and then torn down because of SYN TIMEOUT. But other types of traffic from the same subnet like UDP/ICMP is blocked instantly. Also interesting thing that I don't see any connection events regarding those TCP flows except UDP or ICMP was denied between those hosts. Given the fact it is been allowed somehow that might be logical as FMC doesn't display it before actual TCP connection is established.

So, the problem is I see SYN packets are been allowed in configuration above without no specific rule, while I was expecting to have even first SYN denied right away.

Am I missing anything?

Thanks!

[Ilkin]

In such a case, it is a good idea to identify the rule that the packets match on the firewall and the inspection (Snort) engines,  and also check the conditions/reasons of the intended rule (that is supposed to match). At minimum considering these 3 points would be helpful:

1. Order of operation in NGFW 

2. Existence of destination NAT

3. Some access control rules are deployed with different actions on the firewall and inspection engines. For example, an rule with an application condition and block action is deployed with the permit action on the firewall engine and the drop action of the inspection engine. The reason is that the application identification is performed only by the inspection engine, hence the firewall engine must allow traffic till the application is identified.

All of the 3 points above are described in the guide Clarify Firepower Threat Defense Access Control Policy Rule Actions.

Point 3 above is described in the section "Scenario 2. Drop Due to Snort Verdict".

[psycoma]

Hello Ilkin, thanks for your response. My questions was rather simpler: is there any difference between how BLOCK action works on TCP/UDP/ICMP traffic? As I see UDP/ICMP is blocked right away starting from the first packet, which is fine and logical. But with TCP it seems like TCP SYN is still forwarded via egress interface for further anlysis? I would think of something like TCP Intercept...

Thanks.