ACL Deny Any Not Working As Expected On VLAN Interface

[Thades]

As the title says it is not working as I expect it to, it is probably working the way it is intended, which I am probably not understanding. I mocked up the following in Packet Tracer:

PC<-->Switch1<-->Switch0

Switch 1 is a 2960

Switch 0 is a 3560 MLS

VLAN10 Is the management VLAN with a subnet of 10.10.10.0/24
VLAN8 is 10.10.8.0/24.
VLAN9 is 10.10.9.0/24.

Switch 0 has routing turned on with the ip routing command

The PC has an IP of 10.10.8.31 and a gateway of 10.10.8.1 (switch 0).

Switch 0 has the VTP server mode and switch 1 is a client.

On switch 0, interface VLAN 10 has an IP of 10.10.10.1 255.255.255.0
On Switch 0, interface VLAN 8 has an IP of 10.10.8.1 255.25.255.0
On Switch 0, interface VLAN 9 has an IP of 10.10.9.1 255.255.255.0

If I do a ping from the PC (10.10.8.1) to Switch 0's management interface (10.10.10.1) I get ping replies.
If I turn off routing it stops

I made an acl standard with deny any.
I applied the access-group to interface VLAN 10 in.
I can still ping from the PC.

I was expecting the ACL to block everything in and out of interface VLAN 10.
I tried in and out and both at the same time and nothing. If I apply the ACL to interface VLAN 8, the pings stop.

What I am trying to accomplish is to say NO traffic to 10.10.10.0/24, except from 10.10.9.0/24. I was unable to with another ACL that had the source as 10.10.9.0, but it didn't not stop the pings, so I am trying this simple test, which does not seem to do what I want it to do.

Here is the relevant config section from Switch 0

!
interface Vlan1
no ip address
shutdown
!
interface Vlan8
mac-address 0002.4a04.bd01
ip address 10.10.8.1 255.255.255.0
!
interface Vlan9
mac-address 0002.4a04.bd02
ip address 10.10.9.1 255.255.255.0
!
interface Vlan10
mac-address 0002.4a04.bd03
ip address 10.10.10.1 255.255.255.0
ip access-group DENY_ALL in
!
ip classless
!
ip flow-export version 9
!
!
ip access-list standard DENY_ALL
deny any
!

Any ideas? Does turning on routing have something to do with it? I attached the pkt file too.

[paul driver]

Hello
That would be expected as the its to the switch/rtr itself and not to a host behind vlan 10 subnet, the only way to negate that host in vlan 8 to be denied as you describe it now would be to append that same acl ingress on vlan 8 svi

[Flavio Miranda]

@Thades 

 It will work if you just change the ACL from interface vlan 10 to interface vlan 8.

[Thades]

So, I see that that works, but does that mean every time I add a VLAN and make an interface, I need to add this DENY_ALL to everything? Does this also mean that I would need to add this to any physical ports or trunks? If I have a collapsed core, I'd need to add this to every access switch it seems or am I mistaken?

It seems like a long way around. I was hoping for a simpler solution that was a type of catch-all. Deny everything except.

If I have a management VLAN, I wouldn't want anything able to access/ping unless authorized.

[Flavio Miranda]

@Thades 

Control traffic using ACL is very laborious, time consuming, error prone, ineficient and, depending on How many ACL can degradate device resource.

 Thats why we have firewall.

[paul driver]

Hello @Flavio Miranda 
I would agree its fair comment however in times when a fw isn’t possible and a need to secure a device facing it external infrastructure exists then ACLs can play an important part of hardening an external facing device -
most rtr-switchs nowadays have auto secure functions that marco the job for you - but additional feature s like dynamic/reflective/routed acls -MPP/CoPP -cbac(old) -software zone base firewalls to name a few can still play a vital part in device & network security from external attacks.

[paul driver]

Hello
As i said based on your OP and how you were trying to ping the switch/rtr interface directly thats why it the acl didn't work when applied to vlan 10 and it did work when you changed it to vlan 8 ( where the source of the ping originated)

The acl would have worked applied to vlan 10 IF if you was trying to ping a host behind that subnet

Going forward what exactly are you trying to achieve? 

[paul driver]

Hello
The mgt vlan can be segregated just like all the other vlans and yes you would need to apply a routed acl to each L3 svi which will NOT be an implicit deny all as you have now but more specific acl matching the subnets you wish to exclude -no acl needs to be applied to any trunk either.

now if you think negating access via acl is to administrative then you other options would be either have a firewall as your k3 core or VRFs the latter being much harder to admin if future requirements wish you to leak between them.

[Thades]

I am just trying to secure our network. We have different subnets and VLANs. When we turn on routing, it seems everyone can get to everything. We have a collapsed core here. We have two Cisco Catalyst 9300s for the core, and Meraki switch stacks for access. For firewalls we have Fortigates. My predecessors never finished fully setting everything up, so I am now "it". They put the routing on the core switches instead of the firewalls. And I guess that is okay since the core is the "middle".

I don't want people to be able to "snoop" around and try to access things they aren't supposed to. Not always necessarily employees, but just in case any malware makes it onto a desktop. I don't need Department A to access Department B, and I definitely don't want anyone to access the management VLAN.

My understanding is that the management VLAN is for management of devices. So, I would throw switches on her via their interfaces that would have SSH open for example. If I am employee A on a PC, I have my own VLAN, let's say 8. I shouldn't be able to see anything on any other VLAN unless authorized. I was hoping everything was backlisted by default, but that doesn't seem to be the case.

I can include diagrams if it makes it easier.

[paul driver]

Hello
so you have options to secure the L3 core switches - routed acls on each vlan to deny users in the other vlans access or have each vlan it its own vrf and as per default each vlan will be segregated 

Obviously you need to understand all users in all vlans may require access to shared services(dhcp-printers/share drives etc..) so then you need to allow access

I would say the best approach based on why you have described at this time would be routed acls