cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
191
Views
0
Helpful
4
Replies

Cisco FTDv Not Matching Rule set to "Allow" have to set it to "Trust"

LJ Gabrillo
Level 5
Level 5

For the setup, I'm basically running a demo version of FTDv. Also enabled the trial licenses for IPS, Malware Defense, URL, Essentials.

I'm currently encountering an issue in which I have to set the action of the Policy to "Trust" to make it work. Setting it to "Allow" blocks the traffic. The troubleshooting i've done so far is doing a packet-tracer, system support firewall-engine-debug and system support trace. Based on the traces, the traffic it matches the Implicit Policy (Default) when the action of the rule is "Allow" however, when set to "Trust" it works

firewall-engine-debug output:

10.1.1.111 8 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 New firewall session
10.1.1.111 8 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Starting with minimum 0, id 0 and dst network first with zones -1 -> -1, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 8, icmpCode 0
10.1.1.111 8 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 match rule order 2, 'Default Action', action Block
10.1.1.111 8 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 MidRecovery data sent for rule id: 1, rule_action:4, rev id:3879646918, rule_match flag:0x1
10.1.1.111 8 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Generating an SOF event with rule_id = 1 ruleAction = 4 ruleReason = 0
10.1.1.111 8 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 deny action
10.1.1.111 8 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Deleting Firewall session flags=0x0, logFlags=0x1000

trace output:

10.1.1.111 0 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Packet 1116: ICMP, 03/24-06:07:06.246691, Type: 8 Code: 0
10.1.1.111 0 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Session: new snort session
10.1.1.111 0 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Firewall: starting rule matching, zone -1 -> -1, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999997, icmpType 8, icmpCode 0
10.1.1.111 0 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Firewall: block rule, 'Default Action', force_block
10.1.1.111 0 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Stream: pending block, drop
10.1.1.111 0 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Policies: Network 0, Inspection 0, Detection 2
10.1.1.111 0 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Verdict: blacklist
10.1.1.111 0 -> 1.1.1.1 0 1 AS=0 ID=0 GR=1-1 Verdict Reason: firewall, force_block


Configuration wise:
-This is a simple User to Internet Policy, literally just LAN to ANY. Everything works basically if the policy is set to "Trust". Setting it to allow blocks everything and matches it to the implicit deny action.
-Intrusion Default Network Analysis Policy has been set to "No Rules Active" 

Screenshot of my policy

LJGabrillo_0-1742796554141.png

Appreciate any inputs. Really confusing why this isn't matching an "allow" policy. 

 

1 Accepted Solution

Accepted Solutions

LJ Gabrillo
Level 5
Level 5

UPDATE: Looks like this is a BUG. Found this
https://bst.cisco.com/quickview/bug/CSCwk78400

I'm guessing im sticking to setting the zone to ANY for now. Still has no fix.

 

View solution in original post

4 Replies 4

ulineosan
Level 1
Level 1

The "Trust" action allows the traffic with no additional checks, while the "Allow" action passes the traffic to the snort engine.

edit: link: https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212321-clarify-the-firepower-threat-defense-acc.html

Yes you are correct, but that is not my question (not asking the difference between Trust and Allow). My concern is that I have to use "Trust" to make the policy hit the traffic. However, our requirement is that it should be "Allow"

I want my policies to have action "allow" so that I can enable sec features such as IPS and File Filter.

LJ Gabrillo
Level 5
Level 5

UPDATE: I sorta found a workaround, it seems the issue in the ZONE config. After setting the policy to use "Any" Zone, traffic is working now.

I do not see any issues with my zone configuration, tripled check and verified that the zone is mapped to the correct interface.

LJ Gabrillo
Level 5
Level 5

UPDATE: Looks like this is a BUG. Found this
https://bst.cisco.com/quickview/bug/CSCwk78400

I'm guessing im sticking to setting the zone to ANY for now. Still has no fix.

 

Review Cisco Networking for a $25 gift card