FTD NAC L2 Block not working

[David Rollins]

I have configured a rule in the Default NAC that is supposed to block a Layer 7 protocol application. When I analyze hit counts, it shows the rule has been matched. And when I analyze connection events, the traffic is showing as dropped. This is the 2nd rule in the access policy.

The rule is configured as such:

Rule_Name src_zone "any" dst_zone "any" src_net "any" dst_net "any" applications "chatGPT" src_port "any" dst_port "any" Action "Block"

ChatGPT is just the example application I'm using for this discussion.

Here is the issue. When I looked at the command line, this rule has an advanced permit ip any any. The reason it was brought to my attention, was that we were trying to configure a Layer 3 deny rule, (rule 33) and the permit ip any any was allowing the traffic.

How is this possible? Can anyone provide insight or resolution?
The default action for the Default NAC is "Block all traffic".

[Rob Ingram]

@David Rollins I assume you are looking at the lina "show run" ? - When you create a rule with features that are run by Snort, such as Geolocation, URL filtering, Application detection, etc, they are deployed on Lina side as a permit any any rule, the packet is then sent to Snort for deep inspection and an action taken.

You can run "system support trace" or "system support firewall-engine-debug" or "packet-tracer" to troubleshoot further and confirm which exact rules are matched.

[David Rollins]

Yes I looking at lina and doing a show run. I ran packet-tracer first. That's what lead me to the rule in the first place. I only went to lina to confirm the packet-tracer. Because I just couldn't believe what I was seeing.
This "chatGPT" rule is allowing all traffic based on the permit ip any any.

[David Rollins]

I have 3 other (Layer 7) rules that don't show up in lina show running.

[MHM Cisco World]

MHM

[David Rollins]

I'm telling you, I'm doing a packet tracer. The packet tracer is telling me no matter what traffic I select as the source and destination, it matches on this chatgpt rule. Phase 3 - Type access-list. Result ALLOW
And every phase in the packet trace is allow. Even the snort. 

So if all the Access policy rules are accomplishing what they are configured to do. Then packet tracer is just not very good at matching rule sets. So essentially, packet tracer doesn't work.

[MHM Cisco World]

Can I see complete Packet-tracer 

MHM

[David Rollins]

I really wish I could, so you could see what I see. But I'm on a closed network. 
I have tested some of my other rules, that are blocking. So I know they work. I just don't know why Packet tracer isn't matching properly. I think I will have to open a TAC case.

[MHM Cisco World]

MHM

[MHM Cisco World]

MHM

[MHM Cisco World]

Hi friend 
since the APP ACP rule have two ports 
one in Lina and other in Snort 
the lina part is permit any any 
so cisco recommend to put ANY ACP rule for APP in down list 
I think here you config it in UP list and it match traffic that must be deny 
so remove the ACP APP and add it again in down list 

If above not work' try tune the l7 rule by specified the source and destiantion prefix put it in down list before deny ip any any (l3 rule)

[Marius Gunnerud]

Packet tracer does not take the SNORT verdict into account.  For the packet to be inspected by SNORT the LINA needs to allow the packet and that is why you are seeing the allowed verdict by LINA.  However in LINA there should should be a step that states the packet will be sent to SNORT.

To see the verdict returned by SNORT you would need to issue the command "system support trace", enter the server and client IP and then run a test.

[David Rollins]

@MHM Cisco World , if I understand you correctly. In order to keep the rule as it is configured and still be able to use Packet Tracer, the deny rule for the application protocol needs to moved to the bottom. So basically right before the Deny All statement. 
I get what you and @Marius Gunnerud are saying. But this seems to be a flaw of packet tracer then.
Because if I keep the rule as is and move it down to the bottom, a novice admin troubleshooting might still see this in packet tracer as a permit any any and be confused by it. 
And "fine tuning" the rule defeats the purpose to deny all source subnets going to all destination subnets, in all zones; from ever being able to use the application protocol in question.

[MHM Cisco World]

Yes move it to bottom 

MHM

[Marius Gunnerud]

I would not say it is a flaw of packet tracer, a more accurate statement would be that it is a limitation.  Packet tracer was not designed to be used in SNORT as it was originally created for ASA (aka. LINA in Firepower world).  So packet tracer works exactly as intended.

Also, and this is just an assumption, since SNORT works on the backplane of LINA and is for all intents and purposes separate from LINA, one of two reasons might point to why SNORT verdict is not part of packet tracer.  1. It is difficult, if not impossible, to include SNORT the way LINA and SNORT are integrated, or 2. Cisco has been focusing on developing other functionality in Firepower and not spent time trying to integrate LINA and SNORT into packet tracer.

You are correct that if an administrator bases their findings purely on what he or she sees in packet traces it can be a little misleading.  So perhaps, and in my opinion this should be done regardless, create a troubleshoot flow chart for Firepower.  This way, if an engineer is stuck they can refer to the chart and if all boxes are checked then escalate.