topic ASA 5520 Flow is Denied by Configured Rule in Network Security

ASA 5520 Flow is Denied by Configured Rule

jeremyn — Tue, 12 Mar 2019 01:50:59 GMT

Hello all,

New to the forums and the Cisco ASA 5520.

I am attempting to allow traffic from one vlan to another.

Vlan 1 is on Interface 0/2.vlan1
Vlan 2 is on int 0/3.vlan2
Each vlan can communicate inside it's own vlan, and the gateway on each responds to vlan specific clients

My problem is that I am unable to communicate between the two vlans. Using the ASDM packet tracer tool, I find that packets are denied by the default rule (on the second Access List lookup). It appears as if the packet never reaches the other interface. Any help is appreciated. The access rules are set up to allow traffic from one vlan to another (inbound), on both interfaces. Testing from either vlan to connect to the other fails. Below are the accee-rules for each vlans. Once I get basic connectivity working, I hope to clean it up.

access-list aVlan1; 3 elements; name hash: 0xadecbc34

access-list aVlan1 line 1 extended permit ip any 192.168.151.64 255.255.255.192 (hitcnt=0) 0xeb0a6bb8

access-list aVlan1 line 2 extended permit ip any 192.168.151.128 255.255.255.128 (hitcnt=0) 0x3a7dfade

access-list aVlan1 line 3 extended permit ip any 192.168.151.0 255.255.255.0 (hitcnt=0) 0x93302455

access-list aVlan2_access_in; 3 elements; name hash: 0x6dc9adc7

access-list aVlan2_access_in line 1 extended permit ip 192.168.151.64 255.255.255.192 192.168.150.0 255.255.255.240 (hitcnt=0) 0x054508b7

access-list aVlan2_access_in line 2 extended permit ip 192.168.151.128 255.255.255.128 192.168.150.0 255.255.255.240 (hitcnt=0) 0xc125c41e

access-list aVlan2_access_in line 3 extended permit ip host 192.168.151.3 192.168.150.0 255.255.255.240 (hitcnt=0) 0x4adc114c

Thanks,

ASA 5520 Flow is Denied by Configured Rule

Eddy Duran — Thu, 30 May 2013 00:24:48 GMT

Hello Jeremy,

What is the security level for those interfaces?

Try to add this command:

same-security-traffic permit inter-interface

I would like you to post the packet tracer if possible.

-Eddy Duran

ASA 5520 Flow is Denied by Configured Rule

jeremyn — Thu, 30 May 2013 15:31:04 GMT

Hi Eddy,

Thanks for your response. Each subinterface has a security level of 30. I need a day or so to determine if there will be any adverse effects of applying that rule.

Packet tracer and applicable rules below.

Thanks for the help,

Re: ASA 5520 Flow is Denied by Configured Rule

Jouni Forss — Thu, 30 May 2013 16:28:58 GMT

Hi,

Having each local firewall interface on the same "security-level" at the moment means that they have no chance of communicating with eachother (even with ACLs configured) unless the above mentioned configuration command is inserted.

If you were to insert the command the following things might happened depending on your configurations

An interface which has no ACL attached would be able to initiate connections towards any of the other interfaces with the equal "security-level" value.
An interface which has an ACL attached would be matched against its ACL rules and those would determine to which networks or hosts behind the other local interfaces the hosts behind this interface could connect to.

Generally if I would want to configure a setup where I have multiple local interfaces on the ASA and would want to rule out any traffic between them I would always use ACLs on each interface instead of using "security-level" value.

The way I would do it would be to

Create an "object-group network" which contains ALL the local networks
Create an ACL for each interface which starts with a "deny ip any object-group " which would by default block all traffic from the behind that interface to ANY other network behind the ASAs local interfaces
Create a permitting statement for the local networks behind that interface to "any" destination address which would essentially enable Internet bound traffic (as we have blocked all local networks before)

If I would have to need to enable some traffic between local networks behind different interfaces I would simply add "permit" statements at the TOP of the needed ACLs with a "remark" describing what traffic is allowed. The existing "deny" statement would still make sure that no other traffic between the local networks would be allowed unless I specifically allowed it in the top of the interface ACL.

Hope this helps

- Jouni

ASA 5520 Flow is Denied by Configured Rule

jeremyn — Thu, 30 May 2013 18:27:39 GMT

This does help, thanks Jouni,

Ideally, I would like to implement what you suggest but I think it would take some careful planning. In the mean time, I'd like to enable access between the two subinterfaces. Would changing the security level of the subinterface where traffic would be intiated from to a higher security level solve this problem? Alternatively I could drop the security level of the other subinterface.

Thanks,

ASA 5520 Flow is Denied by Configured Rule

Jouni Forss — Thu, 30 May 2013 18:34:48 GMT

Hi,

Increasing the "security-level" of the source interface might be the best choice at this point. (As I have no knowledge of the rest of the setup)

As you already have the ACL configured on the source interface, then increasing the "security-level" value of the interface wouldnt really change what traffic is allowed and what is not since the ACL will specify that. Changing the "security-level" would however get around the immidiate problem you are facing now which is that networks behind equal "security-level" interfaces cant communicate.

If you were to lower the "security-level" of the destination interface it might change the whole setup more. And I can only guess but to me it would seem that if you have several other local interfaces with value 30 without ACL and this destination was now changed to 29 for example then some traffic might start get allowed that you dont wish to be allowed

If one of the reply is the correct answer to your question, please do mark it as the correct answer. Also if you have found some information helpfull, please take the time to rate these replys

Naturally ask more and I will try to help out.

- Jouni

ASA 5520 Flow is Denied by Configured Rule

jeremyn — Thu, 30 May 2013 18:41:14 GMT

Thanks Jouni,

I will test this today and either mark as answered or follow up.

Cheers,

ASA 5520 Flow is Denied by Configured Rule

jeremyn — Thu, 30 May 2013 19:17:38 GMT

Hi I changed the security level of the first interface higher and tested an ip packet from that subnet to the other (40/30). It failed, citing the same default rule. It appears to be blocked at that interface and never reaches the other interface. Any other ideas?

Thanks,

ASA 5520 Flow is Denied by Configured Rule

Jouni Forss — Thu, 30 May 2013 19:27:09 GMT

Hi,

I am not sure what exactly you are testing. I imagine its certain destination IP and TCP/UDP ports connection.

Could you perhaps try this

Go to

ASDM
Tools -menu
Command Line Interface
Insert the following command (while filling the information to match your connection test)

packet-tracer input

Where

nameif = Is the name of the interface where the source host for this connection test is located at. In other words the name of the interface from where the packet is "input"
protocol = TCP or UDP
source ip = Is the hosts IP address that is initiating the connection
source port = Is the random source port for the connection attempt
destination ip = Is the destination IP address
destination port = Is the port on the destination host you are trying to reach

You can use the Send button to send the command to the ASA and it will print out the CLI format of the Packet Tracer output. You can then copy/paste it here (minus any possible public IP address information incase something shows)

- Jouni

ASA 5520 Flow is Denied by Configured Rule

Jouni Forss — Thu, 30 May 2013 19:28:55 GMT

Also,

Just to check, you have attached the ACLs to the interfaces right?

If not then the output you are seeing might be possible also.

You can use the command "show run access-group" to view the ACL attached to the interfaces

- Jouni

ASA 5520 Flow is Denied by Configured Rule

jeremyn — Thu, 30 May 2013 23:12:43 GMT

Sorry, no luck:

packet-tracer input wta2COB icmp 192.168.150.1 0 0 192.168.151.3

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.151.0 255.255.255.0 FACSURV

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: WTA2COB

input-status: up

input-line-status: up

output-interface: FACSURV

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

access-group aWTA2COB in interface WTA2COB

access-group FACSURV_access_in in interface FACSURV

Thanks for the continued responses.

ASA 5520 Flow is Denied by Configured Rule

Eddy Duran — Fri, 31 May 2013 02:39:53 GMT

Jeremy,

Thanks for the update.

Can you post the show access-list command from the unit? If possible a show run from the unit?

-Eddy Duran

Re: ASA 5520 Flow is Denied by Configured Rule

Jouni Forss — Fri, 31 May 2013 03:36:32 GMT

Hi,

The "packet-tracer" code is incorrect

You are testing ICMP with it and basicly inserting a ICMP Echp reply (Type 0 Code 0)

You need to use this

packet-tracer input wta2COB icmp 192.168.150.1 8 0 192.168.151.3

Which is ICMP Echp (Type 8 Code 0)

- Jouni

ASA 5520 Flow is Denied by Configured Rule

jeremyn — Fri, 31 May 2013 18:55:26 GMT

Thanks all,

I worked on this some more today, testing with some additional rules. The ASA is acting like it doesn't see my rules:

Added NAT statements:

nat (FACSURV) 0 access-list NoNAT

nat (FACSURV) 1 0.0.0.0 0.0.0.0

nat (WTA2COB) 0 access-list NoNAT

nat (WTA2COB) 1 0.0.0.0 0.0.0.0

Access rules below:

access-list aWTA2COB; 5 elements; name hash: 0xadecbc34

access-list aWTA2COB line 1 extended permit ip any 192.168.151.64 255.255.255.192 (hitcnt=0) 0xeb0a6bb8

access-list aWTA2COB line 2 extended permit ip any 192.168.151.128 255.255.255.128 (hitcnt=0) 0x3a7dfade

access-list aWTA2COB line 3 extended permit ip any 192.168.151.0 255.255.255.0 (hitcnt=0) 0x93302455

access-list aWTA2COB line 4 remark test

access-list aWTA2COB line 5 extended permit ip any any (hitcnt=0) 0xdbfec94c

access-list aWTA2COB line 6 remark test

access-list aWTA2COB line 7 extended permit icmp any any (hitcnt=0) 0x2cece62d

access-list FACSURV_access_in; 5 elements; name hash: 0x6dc9adc7

access-list FACSURV_access_in line 1 extended permit ip 192.168.151.64 255.255.255.192 192.168.150.0 255.255.255.240 (hitcnt=0) 0x054508b7

access-list FACSURV_access_in line 2 extended permit ip 192.168.151.128 255.255.255.128 192.168.150.0 255.255.255.240 (hitcnt=0) 0xc125c41e

access-list FACSURV_access_in line 3 extended permit ip host 192.168.151.3 192.168.150.0 255.255.255.240 (hitcnt=0) 0x4adc114c

access-list FACSURV_access_in line 4 extended permit ip any any (hitcnt=9) 0x9fedc480

access-list FACSURV_access_in line 5 remark test

access-list FACSURV_access_in line 6 extended permit icmp any any (hitcnt=0) 0xd74c33b6

Packet Tracer result:

packet-tracer input wta2COB icmp 192.168.150.1 8 0 192.168.151.3

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.151.0 255.255.255.0 FACSURV

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: WTA2COB

input-status: up

input-line-status: up

output-interface: FACSURV

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

I will open a TAC case today. If you have any further input, I'm willing to test.

Thanks,

Re: ASA 5520 Flow is Denied by Configured Rule

Jouni Forss — Fri, 31 May 2013 18:59:14 GMT

Hi,

Would you be willing to share the complete configuration?

If you want you can share it through a PM (private message) on the forums. (That is if you dont want to share it in this post I mean)

This would give a chance to go through the problem better.

- Jouni

Re: ASA 5520 Flow is Denied by Configured Rule

jeremyn — Mon, 03 Jun 2013 19:34:48 GMT

Hi guys,

I won't be able to share the full config. I am in training this week and will be unable to follow up on this ticket. I'd like to follow this up next week if possible. I may open up a TAC case here pretty soon, and will definitely follow up with the answer if I get it.

Thanks,

ASA 5520 Flow is Denied by Configured Rule

Jouni Forss — Mon, 03 Jun 2013 19:44:33 GMT

Hi,

I guess if you arent able to share the configuration (even through PM) then there is not much that we can do at this point.

You will simply have to go through this with TAC (to which you probably have to provide the configuration perhaps) and see what the problem is.

Usually when the "packet-tracer" output tells that you that the packet has been denied by an ACL-DROP then its most likely due to some global setting that is wrong or there is no ACL attached to an interface (though it seems that in your case the ACLs are attached)

Every now and then I run into these situation myself and have to scratch my head for a bit as the "packet-tracer" really doesnt give any help with its output.

- Jouni

ASA 5520 Flow is Denied by Configured Rule

jeremyn — Wed, 12 Jun 2013 18:37:14 GMT

Greetings again everyone,

Thanks to everyone for responding to my previous requests for help. I worked with a Cisco TAC the last couple days to resolve this issue. It turned out to be a NAT issue between the two vlans.

The original access-list for natting was this:

access-list NoNAT extended permit ip 10.0.0.0 255.0.0.0 10.0.0.0 255.0.0.0

access-list NoNAT extended permit ip 10.0.0.0 255.0.0.0 172.16.0.0 255.240.0.0

access-list NoNAT extended permit ip 10.0.0.0 255.0.0.0 192.168.0.0 255.255.0.0

access-list NoNAT extended permit ip 172.16.0.0 255.240.0.0 10.0.0.0 255.0.0.0

access-list NoNAT extended permit ip 172.16.0.0 255.240.0.0 172.16.0.0 255.240.0.0

access-list NoNAT extended permit ip 192.168.0.0 255.255.0.0 10.0.0.0 255.0.0.0

access-list NoNAT extended permit ip 192.168.0.0 255.255.0.0 192.168.0.0 255.255.0.0

access-list NoNAT extended permit ip 10.0.0.0 255.255.240.0 10.51.0.0 255.255.255.0

access-list NoNAT extended permit ip 10.21.0.0 255.255.240.0 10.51.0.0 255.255.255.0

nat (WTA2COB) 0 access-list NoNAT

nat (WTA2COB) 1 0.0.0.0 0.0.0.0

nat (FACSURV) 0 access-list NoNAT

nat (FACSURV) 1 0.0.0.0 0.0.0.0

The revised configuration was this:

access-list EXEMPT permit ip 192.168.150.0 255.255.255.0

access-list EXEMPT permit ip 192.168.151.0 255.255.255.0

nat (WTA2COB) 0 access-list EXEMPT

nat (WTA2COB) 1 192.168.150.0 255.255.255.0

nat (FACSURV) 0 access-list EXEMPT

nat (FACSURV) 1 192.168.151.0 255.255.255.0

From what I can tell, the 192.168 statement in the NoNAT access-list didn't work because it was for 192.168.0.0 /16, wherease the Exempt access-list applied for each subnet specifically. Let me know if I'm correct in that assumption.

Long term I'd like to update the NoNAT to reflect the smaller subnets and then apply the access-list to these interfaces.

Thanks,

ASA 5520 Flow is Denied by Configured Rule

Jouni Forss — Wed, 12 Jun 2013 18:47:49 GMT

Hi,

In general the NAT0 access-lists should ONLY contain the specific networks your are doing the NAT0 for. Especially when you are using smaller subnets of the larger network all around your network.

I have run into such problem in a hospital environment where someone had inserted NAT0 rules that basicly included all the 3 private IP address networks and this seemed to mess up the traffic forwarding completely. The "packet-tracer" output in this case didnt help at all and it was only when I played with the NAT configurations I was able to correct the situation.

I have never managed to cause such problems myself though as I always configure NAT rules using the specific network because its a quick way to cause problems with traffic forwarding, especially on the new software.

We didnt see your NAT0 ACL configuration before so didnt even think about NAT causing this problem. If it truly did.

- Jouni

ASA 5520 Flow is Denied by Configured Rule

jeremyn — Wed, 12 Jun 2013 21:52:58 GMT

My apologies for not sharing the full config. It looks like you are correct in that being the root issue and I will go through and reconfigure the access-list to be more specific. I'll mark your reply as the correct answer as it is helpful in finalizing the configuration.

Thanks!