cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2359
Views
1
Helpful
6
Replies

ASA only checking implicit deny rule

hashimwajid1
Level 3
Level 3

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

 

 

 

 

 

6 Replies 6

Rahul Govindan
VIP Alumni
VIP Alumni

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? 

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

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

Remember to rate helpful posts and/or mark as a solution if your issue is resolved.

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?

Matt A
Level 1
Level 1

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/

ahqoujaq
Cisco Employee
Cisco Employee

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

Review Cisco Networking products for a $25 gift card