cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5246
Views
5
Helpful
10
Replies

Inter-Vlan ACL's

rcarstens991
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

Jon Marshall
Hall of Fame
Hall of Fame

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

View solution in original post

10 Replies 10

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


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

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

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.

Don't forget to rate helpful posts.

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

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.

Don't forget to rate helpful posts.

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

Jon Marshall
Hall of Fame
Hall of Fame

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

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

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

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


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card