01-11-2014 01:16 AM - edited 03-04-2019 10:02 PM
Hi All,
I am having some issues getting ACL to function they way I would like. I have many clients on differnet vlans (vlan 6-10) and my ASA (10.1.99.254) on vlan 99 for internet access. I need vlans 6-10 to have access to the ASA for internet, but vlans 6-10 should not have access to each other. Right now I am applying the access-group rules in the out directon on the vlan 6 SVI.
vlan 6-10.2.1.0/24
vlan 7-10.2.2.0/24
vlan 8-10.2.3.0/24
vlan 9-10.2.4.0/24
I tried
10 permit ip 10.1.99.254 0.0.0.255 10.2.0.0 0.0.255.255
20 deny any any
I was able to ping the ASA and did was not able to access the other vlan's. However, I also did not have any internet access. DNS replies were not being passed no was ICMP traffic passed the ASA.
The switch is a 3560G
Any help would be appriciated.
Solved! Go to Solution.
01-11-2014 11:25 AM
Robert
The acl should not stop devices within the same vlan talking to each other, it only stops devices outside that vlan so what you are seeing is not right.
In terms of your general question, usually you use inbound acls on the source vlan rather than outbound acls on the destination vlan. You can use either but blocking packets at the source is the more common approach.
So if i understand correctly you need to block all traffic between any vlan 10.2.x.x/24 subnet ?
If so and you are not bothered about specifying the source IP subnet in each acl -
ip access-list extended
deny ip any 10.2.0.0 0.0.255.255
permit ip any any
int vlan 10
ip access-group in
so lets say vlan 10 is 10.2.5.0/24. What the above does is block any packets coming from clients in vlan 10 with a destination IP of 10.2.x.x. Any other packets will be allowed. This same acl could be applied to all 10.2.x.x L3 vlan interfaces.
Note that in the acl i used the source of any rather than "10.2.5.0 0.0.0.255". This is because with "any" the same acl could be applied to all the 10.2.x.x vlans inbound without any modification. You could if you wanted to be more precise do a specific acl for each vlan ie. for the same example above -
ip access-list extended
deny ip 10.2.5.0 0.0.0.255 10.2.0.0 0.0.255.255
permit ip 10.2.5.0 0.0.0.255 any
this would be more specific and would stop any non 10.2.5.x client on that vlan from sending packets but most communication wouldn't work anyway as the return packets would not be routed properly to the client. But as i say this makes the acl unique to the specific vlan so you would need different acls per vlan.
Some additional points -
1) if the clients use DHCP and the DHCP server is a 10.2.x.x device you would need to allow that before the deny line
2) the clients will not be able to ping their default gateway ie the L3 vlan interface. This is not a problem because the destination IP is never usually the L3 vlan interface but if you wanted to be able to do that you would need a permit line before the deny line. Note also that this would mean your acl would be different for each vlan because the L3 vlan IP is different per vlan
3) if you use the same actual acl for every vlan interface then any hits on the acl will be for all vlans so you won't be able to see the hits per vlan. This may or may not be important to you. That is often why you seen unique acls (in terms of number or name but not necessarily entries) used. If you do want to see the hits per vlan then simply replicate the acl but with a new name per acl (assuming you go with the option of using "any" in your acls).
Hope all that made sense. Any doubts please ask further.
Jon
01-11-2014 02:06 AM
Hello
Change your acl s to deny traffic between each vlan and allow any other-that way you will have access to your asa and the Internet
Res
Paul
Sent from Cisco Technical Support iPad App
01-11-2014 10:47 AM
Thank you for your response. I now how the following config:
interface Vlan6
ip address 10.2.1.1 255.255.255.0
ip access-group ACL_client_vlansec out
no ip proxy-arp
!
Extended IP access list ACL_client_vlansec
10 deny ip 10.2.0.0 0.0.255.255 any
20 permit ip any any
This worked to deny access to all the other vlans, however it is also blocked intra-vlan traffic. Servers within the same vlan still need to be able to communicate. In vlan 6 I have a 10.2.1.5 and 10.2.1.6, which with this config cannot communicate.
We are anticipating creating 100's of these vlans to segragate clients so I am trying to create a wholesale ACL that can be applied to all client vlans to cut down on management. Will this be possible or am I going to have to individually deny each vlan on every vlan?
Each vlan is a 10.2.x.x/24
01-11-2014 11:58 AM
Hi,
on each vlan interface you'll have to apply an ACL inbound that denies access to other vlans (10.2.x.x) and permit any to get internet access and communicate with the ASA.
You could also use PVLAN or VRF-Lite to achieve this.
Regards
Alain
Don't forget to rate helpful posts.
01-11-2014 12:30 PM
Alain
Good idea with VRF-Lite. Do you have much experience of this because i always get a bit hazy on one aspect ie.
each L3 vlan interface is placed into it's own VRF. The L3 switch to ASA connection is not in any VRF. So each VRF needs a default route pointing out of the interface connecting to the ASA.
Is that correct ?
If so how does the return traffic get back into the right VRF. Do you need a static route for each vlan IP subnet in the global routing table pointing to the relevant VRF interface ?
If so do you always have to use statics with VRF-Lite ? I know with MPLS VPN you can use MBGP and route targets for this but do any routing protocols support doing a similiar thing with VRF-Lite ?
Jon
01-11-2014 02:30 PM
Jon,
No I don't have a lot of experience with this technology but I tried it a few times and it worked.
I used the static routes strategy to do the VRF leaking( from vrf to global and from global to vrf) like you described.
I know there are other ways to achieve this but haven't played with it yet.
I find it is well explained here:http://blog.ipexpert.com/2010/12/01/vrf-route-leaking/
Regards
Alain
Don't forget to rate helpful posts.
01-12-2014 06:12 AM
Alain
Many thanks for that link.
When i finally get GNS3 up and running again this is one of the first things i will be looking at
Jon
01-11-2014 11:25 AM
Robert
The acl should not stop devices within the same vlan talking to each other, it only stops devices outside that vlan so what you are seeing is not right.
In terms of your general question, usually you use inbound acls on the source vlan rather than outbound acls on the destination vlan. You can use either but blocking packets at the source is the more common approach.
So if i understand correctly you need to block all traffic between any vlan 10.2.x.x/24 subnet ?
If so and you are not bothered about specifying the source IP subnet in each acl -
ip access-list extended
deny ip any 10.2.0.0 0.0.255.255
permit ip any any
int vlan 10
ip access-group in
so lets say vlan 10 is 10.2.5.0/24. What the above does is block any packets coming from clients in vlan 10 with a destination IP of 10.2.x.x. Any other packets will be allowed. This same acl could be applied to all 10.2.x.x L3 vlan interfaces.
Note that in the acl i used the source of any rather than "10.2.5.0 0.0.0.255". This is because with "any" the same acl could be applied to all the 10.2.x.x vlans inbound without any modification. You could if you wanted to be more precise do a specific acl for each vlan ie. for the same example above -
ip access-list extended
deny ip 10.2.5.0 0.0.0.255 10.2.0.0 0.0.255.255
permit ip 10.2.5.0 0.0.0.255 any
this would be more specific and would stop any non 10.2.5.x client on that vlan from sending packets but most communication wouldn't work anyway as the return packets would not be routed properly to the client. But as i say this makes the acl unique to the specific vlan so you would need different acls per vlan.
Some additional points -
1) if the clients use DHCP and the DHCP server is a 10.2.x.x device you would need to allow that before the deny line
2) the clients will not be able to ping their default gateway ie the L3 vlan interface. This is not a problem because the destination IP is never usually the L3 vlan interface but if you wanted to be able to do that you would need a permit line before the deny line. Note also that this would mean your acl would be different for each vlan because the L3 vlan IP is different per vlan
3) if you use the same actual acl for every vlan interface then any hits on the acl will be for all vlans so you won't be able to see the hits per vlan. This may or may not be important to you. That is often why you seen unique acls (in terms of number or name but not necessarily entries) used. If you do want to see the hits per vlan then simply replicate the acl but with a new name per acl (assuming you go with the option of using "any" in your acls).
Hope all that made sense. Any doubts please ask further.
Jon
01-11-2014 05:09 PM
Thank you jon.marshall for the detailed response, very helpfull It is working perfectly now. I believe I had it working before, but was testing using the L3 gateway interfaces which was not accurate.
I have a bit more to add to this if you don't mind helping. I another vlan for internal use at vlan 100, 10.100.100.0 that I would like to protect from any of the 10.2.0.0/24 subnets, except for https port 443 traffic. vlan 100 and vlan 10 should be able to communicate only on 443 for web traffic, all else should be blocked. I tried just adding another line to permit 443 and then block the rest, but I cant use the eq parameter to specify the port. What am I missing?
Robert
01-11-2014 05:17 PM
I was able to get it working by specifying tcp instead of ip. This config seems to be working now:
Extended IP access list ACL_client_vlansec
10 deny ip any 10.2.0.0 0.0.255.255 (202 matches)
20 permit tcp any 10.100.100.0 0.0.0.255 eq 443
30 deny ip any 10.100.100.0 0.0.0.255 (8 matches)
40 permit ip any any (28 matches)
Are there any issues with running this or a better way to achieve the same thing?
Robert
01-12-2014 01:52 AM
Hello
You need.to.specify a specific.protocol such as.tcp
Access 100.permit tcp x.x.x.x y.y.y.y eq 443
Res
Paul
Sent from Cisco Technical Support Android App
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