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-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
05-29-2013 05:24 PM
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
05-30-2013 08:31 AM
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,
J
05-30-2013 09:28 AM
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
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
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
05-30-2013 11:27 AM
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,
J
05-30-2013 11:34 AM
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
05-30-2013 11:41 AM
Thanks Jouni,
I will test this today and either mark as answered or follow up.
Cheers,
J
05-30-2013 12:17 PM
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,
J
05-30-2013 12:27 PM
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
packet-tracer input
Where
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
05-30-2013 12:28 PM
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
05-30-2013 04:12 PM
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.
05-30-2013 07:39 PM
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
05-30-2013 08:36 PM
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
05-31-2013 11:55 AM
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,
J
05-31-2013 11:59 AM
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
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