ACL for VLANS not acting as expected

[elfordty]

HI there,

I am relatively new to ACLs in Inter-VLAN routing.

I have setup several VLAN's on my network and would like to restrict access to certain ones.  For my network I have the following two VLAN's, as an example

Vlan 20: 172.16.20.0 / 24

Vlan 18: 172.16.18.0 / 24

My IP Phone system is on vlan 18 and I don't want vlan 20 to be able to access vlan 18, with the exception of a few of the IT department PC's that need to access the IP phone controller, which is on vlan 18.

I have created this ACL

ip access-list extended "PHONES"
     10 permit ip 172.16.20.250 0.0.0.0 172.16.18.0 0.0.0.255
     20 deny ip 172.16.20.0 0.0.0.255 172.16.18.0 0.0.0.255
   exit

vlan 18# ip access-group "PHONES" in

From my understanding the first one in the ACL, number 10, should allow my computer on ip 172.16.20.250 access to that subnet and then block all other IPs from the 172.16.20.0 subnet.

However, my computer cannot access that subnet.

Can anyone provide assistance for this?

Thank you

Tyson

[Matcol]

Your PC will be sending your connection attempt/frames/packets to its default gateway address.

Where is its default gateway?

On what device?

Does that device have the VLAN18 subnet in its routing table?

If so, is the access list actually on the interface referenced by the route?

What I'm driving at is, have you correctly understood your network - which switches are switching and which one is doing the inter-VLAN routing? Have you understood the path your connection *should* be taking, and the path it is *actually* taking?

Also, can you actually ping that same address from your PC if you give your PC an address in VLAN18 and put it on a switchport in VLAN18?

[elfordty]

The default gateway for my PC (VLAN 20) is on our core switch - 172.16.20.254
The default gateway for the Phones (VLAN 18) is also on the core switch - 172.16.18.254

The core switch is the one that does the inter-vlan routing.

Before I started to play with ACLs I was able to ping anything on VLAN 18 from my PC, which is on VLAN 20.

The core swtich is the one where I am trying to configure my ACLs.  It is the only switch in my network that is setup for ip routing.

Yes this device (core switch) has VLAN 18 in the routing table as well as VLAN 20

[Matcol · Accepted solution]

I just checked access lists on a 5406 of mine, and I now remember figuring out this same problem a few years ago: the "direction" is actually "out". I remember I did figure out the logic of it back then, but I don't remember very well. Essentially, the packet is "in" the switch and it is going "out" to the VLAN interface, in order to go onto that VLAN, so you use "out" as the direction.

[elfordty]

Yes that does work.

Thanks for that.  I guess you have to think of the direction from the switches point of view and not the VLANs.

I just finished watching the CBT-Nuggets video on ACLs (for cisco but the concepts apply) and the speaker says to put your arms out and your arms are the different interfaces and you are the swtich.  Then it simulates the directions a lot better. Hehe

Anyways, thanks again

[harshini41]

Hai i am new to this forum.

[intangir]

My understanding is that ACE #20 is redundant since ACLs have an implicit deny at the end--you do not need to deny a subnet because everything not permitted will be denied implicitly anyway. This should also mean that not only the entirety of VLAN 20 (with exception to .20.250) but every other VLAN will not be able to be routed into VLAN 18 unless you make addtionals permit ACEs in the ACL.

The other way to tackle this would be to put an "in" ACL on Vlan20 ("in" meaning traffic coming into the switch on vlan 20) except it might be modified like this:

ip access-list extended "PHONES"
   10 permit ip 172.16.20.250 0.0.0.0 172.16.18.0 0.0.0.255
   20 deny ip 172.16.20.0 0.0.0.255 172.16.18.0 0.0.0.255

   30 permit ip any any
   exit

vlan 20 ip access-group "PHONES" in

Which would deny Vlan20 access to Vlan18 (with exception to .20.250) but still permit Vlan20's traffic to be routed anywhere else. Which might actually technically preferable since it's usually best practice to filter traffic prior to being routed--and "in" access rules aren't applied against switched traffic (with notable exception to traffic with the switch itself as the destination).