05-29-2013 04:33 PM - edited 03-11-2019 06:50 PM
Hello all,
New to the forums and the Cisco ASA 5520.
I am attempting to allow traffic from one vlan to another.
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
Solved! Go to Solution.
06-03-2013 12:34 PM
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
06-03-2013 12:44 PM
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
09-14-2015 02:17 PM
06-12-2013 11:37 AM
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
06-12-2013 11:47 AM
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
06-12-2013 02:52 PM
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!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide