ASA 5520 Flow is Denied by Configured Rule

[jeremyn]

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,

J

[jeremyn]

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,

J

[Jouni Forss]

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

[Peter Long]

Cisco ASA (acl-drop) Flow is denied by configured rule

Pete

[jeremyn]

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,

J

[Jouni Forss · Accepted solution]

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

[jeremyn]

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!