topic Re: ASA only checking implicit deny rule in Network Security

ASA only checking implicit deny rule

hashimwajid1 — Fri, 12 Jul 2019 12:27:52 GMT

hi guys,

we are facing issue with our ASA 5515x which was working fine but after enabling Unicast Reverse Path Forwarding and removing some weak encryption/hashing Transform-set, now all traffic is being blocked by Implicit Deny rule from all interfaces.

i've disabled the URPF and configured back the other protocols a but still no traffic is coming/outgoing and Anyconnect also stopped working.

there is no hit on permit ip any any rule and all traffic is being deny by Implicit Deny rule.

sh run access-list Inside_access_in
access-list Inside_access_in extended permit ip any any

show access-list Inside_access_in
access-list Inside_access_in; 1 elements; name hash: 0xa231c4d3
access-list Inside_access_in line 1 extended permit ip any any (hitcnt=0) 0xe42c5ef9

show run access-list Dmz_access_in
access-list Dmz_access_in extended permit ip any any

show access-list Dmz_access_in
access-list Dmz_access_in; 1 elements; name hash: 0xb5611b21
access-list Dmz_access_in line 1 extended permit ip any any (hitcnt=0) 0x623158d6

Packet tracer from Inside to DMZ

packet-tracer input inside tcp 10.12.14.233 2000 192.168.4.5$

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.4.5 using egress ifc Dmz

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2aaacaa74570, priority=501, domain=permit, deny=true
hits=39497, user_data=0x9, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Inside, output_ifc=any

Result:
input-interface: Inside
input-status: up
input-line-status: up
output-interface: Dmz
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Packet tracer from Inside to Outside

packet-tracer input inside tcp 10.12.14.233 2000 8.8.8.8 80 $

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 151.253.72.140 using egress ifc Outside

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2aaacaa74570, priority=501, domain=permit, deny=true
hits=39901, user_data=0x9, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Inside, output_ifc=any

Result:
input-interface: Inside
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Re: ASA only checking implicit deny rule

Rahul Govindan — Fri, 12 Jul 2019 13:43:11 GMT

Few things to check:

1) Is the ACL applied on the inside interface using the access-group command?

2) What are the security levels of inside, outside and DMZ?

4) Any of the interfaces in a down state?

Re: ASA only checking implicit deny rule

hashimwajid1 — Fri, 12 Jul 2019 13:49:14 GMT

Hi Rahul,

Thanks

ACL are applied to Interfaces
security level is 0 fro both DMZ and Outside
all interfaces are up

show run | inc access-group
access-group Outside_access_in in interface Outside
access-group Dmz_access_in in interface Dmz
access-group Inside_access_in in interface Inside

show nameif
Interface Name Security
GigabitEthernet0/0 Outside 0
GigabitEthernet0/1 Dmz 0
GigabitEthernet0/2 Inside 100

show run | inc same-security
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

Re: ASA only checking implicit deny rule

Alan Ng'ethe — Fri, 12 Jul 2019 19:43:12 GMT

What happens when you remove 'access-list Inside_access_in extended permit ip any any' and leave the default implicit allow rule for traffic from the inside interface to outside?

GigabitEthernet0/2 Inside 100

GigabitEthernet0/0 Outside 0

Re: ASA only checking implicit deny rule

GRANT3779 — Fri, 12 Jul 2019 20:28:04 GMT

Have you definitely disabled urpf?
sh run ip verify reverse-path

Do you have logging enabled on the ASA? If not, you could temporarily enabled logging to buffer, attempt generate some traffic through the ASA then run
Show logging | inc x.x.x.x based on one of the IPs.
Can you still ssh to the device i assume?

Re: ASA only checking implicit deny rule

Matt A — Tue, 29 Aug 2023 09:53:56 GMT

In case anyone else is unlucky enough to come across this, priority=501/user_data=0x9 is the combination for TCP syslog being unavailable. So fix your TCP syslog server, or run "logging permit-hostdown".

https://xkcd.com/979/

Re: ASA only checking implicit deny rule

ahqoujaq — Tue, 29 Aug 2023 09:56:43 GMT

Hello,

Please check if your syslog server is reachable.

If you are using TCP as the logging transport protocol for sending messages to a syslog server, the ASA denies new network access sessions as a security measure if the ASA is unable to reach the syslog server. You can use the logging permit-hostdown command to remove this restriction.
command reference: https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/I-R/asa-command-ref-I-R/m_log-lz.html#wp4080049332