switch ACL behaving stateful

[MaxHibbin5605]

Below is my ACL, applied to the interface inbound. Catalyst 2960CX. The first line was intented to allow DHCP. The second is intended to create host isolation. The host connected on this interface has an IP that is part of the network described in line 2.  It worked as in, host could still get to internet for example but could not ping another host on that network. But when I look at it again, I can't explain why the hosts own traffic is not blocked when it is returning to the host, when doing so the destination IP is a match for that network and I thought ACLs are stateless. From reading, I would think this is possible if either the established or reflexive option is in use, neither of which I believe I have applied here. So what am I missing? Thanks in advance.

There is a reason I specified destination instead of source in the deny statement. I can add that detail but I don't want to muddy the water off the bat and am interested in what I am missing in my understanding as it is.

permit udp any eq 67 any eq 68
deny ip any 172.18.32.0 0.0.0.255
permit ip any any

[MaxHibbin5605]

So the other detail: it is a dacl coming from a radius server. I was forced to use "any" as the source in all lines, the switch rejected it otherwise saying "provisioning failed, reason: source not any".  I've been reading some more but I am not clear how it being a dacl affects the operation and why the source needs to be any and also as originally posted why it is working. Very confused at the moment.

[Richard Burts]

Your other detail is quite helpful. You are correct that with ACL the behavior is stateless. But with dacl you are dealing with 802.1x and the radius server not just the switch svi interface or port.

[MHM Cisco World]

can you more elaborate ?

[MaxHibbin5605]

Yes I can elaborate and thank you for the replies. I have been testing with 3 clients all on this same network. 

Laptop 1: 172.18.32.10
Laptop 2: 172.18.32.20
Printer : 172.18.32.30

Before pushing the dacl from radius (Clearpass not ISE) all clients can ping each other and the laptops can web to the printers configurtation page etc. Also they all have internet access. After applying the dacl the clients can NOT ping each other nor can the laptops get to the printer configuration page, (this is what I wanted - client isolation) however they CAN still get to the internet no problem. All that traffic still has the same destination IP when it arrives at the interface. So how is some traffic blocked as you would expect but not all traffic, how can clients still talk to internet, how is it treated differently?  I do realise that if it were working as I am saying I would expect, then I have a problem, I'm blocking all traffic, but now its just about knowing why, and being able to explain to someone else, why it works ok as written. I need help.

Here is the interface config: (vlan is also pushed via radius, redundant to mention but - all 3 are on the same vlan)

switchport access vlan 99
switchport mode access
switchport voice vlan 98
ip device tracking maximum 65535
authentication periodic
authentication timer reauthenticate server
access-session host-mode multi-domain
access-session control-direction in
access-session closed
access-session port-control auto
mab
dot1x pae authenticator
spanning-tree portfast edge
spanning-tree bpduguard enable
service-policy type control subscriber CONCURRENT_DOT1X_MAB

Here is the result of show ip access-lists interface

permit udp any eq bootps any eq bootpc
deny ip any 172.18.32.0 0.0.0.255
permit ip any any
Extended IP access list Auth-Default-ACL
10 permit udp any any eq domain
20 permit tcp any any eq domain
30 permit udp any eq bootps any
40 permit udp any any eq bootpc
50 permit udp any eq bootpc any
60 deny ip any any

The "Auth-Default-ACL" is news to me only appears when the dacl is applied, it is automatically being added by the switch I believe

I read this about why the source is restricted to having to be "any", but it didn't immediately make sense even if the Any was replaced with the client IP, and it was the only resource I could find that even mentioned this restriction

"While creating DACL, the keyword Any must be the source in all ACE in DACL. Once the DACL is pushed, the Any in the source is replaced with the IP address of the client that is connecting to the switch."

https://www.cisco.com/c/en/us/td/docs/security/ise/1-3/adminguide/b_ise_admin_guide_13/b_ise_admin_guide_sample_chapter_010100.html

[MHM Cisco World]

that true, IPDT is change any with host IP 
https://www.cisco.com/c/en/us/support/docs/lan-switching/8021x/119374-technote-dacl-00.html
but this behave is differ from SW to SW and from OS to OS.  
check above link for more info.

[MaxHibbin5605]

Thanks for the reply. But still if IPDT is changing the any in the source to the IP of the client, then that line would look like this, correct:

deny ip host 172.18.32.20 172.18.32.0 0.0.0.255

and as I see it that would not match any traffic inbound on the interface.. that was why I was confused why apply the IP of the client as source to an inbound acl?

[MHM Cisco World]

sorry see my below comment 

[MaxHibbin5605]

I'm sorry, I'm not sure what you are getting at. The purpose of the dacl is to deny clients on this network from talking to each other, but still able to have internet connectivity. 

[MHM Cisco World · Accepted solution]

"""and as I see it that would not match any traffic inbound on the interface.. that was why I was confused why apply the IP of the client as source to an inbound acl?"""
the Inbound to port is traffic initiate from Host toward port of SW, 
so sure the source IP of Inbound traffic is Host IP,
and the ACL is unidirection not bidirection, meaning the Source of Inbound traffic is not same as destination of Outbound traffic.

 

[MaxHibbin5605 · Accepted solution]

Thank you so much for sticking with it. I have been thinking wrong about inbound and outbound, wow. I understand now and its one of those moments where the light bulb finally turns on. In my mind the acl was applying inbound to the sw from upstream, inbound to the trunk I guess I was imagining, totally not the case, so it makes sense now. Thanks again, very much appreciated.

[MHM Cisco World]

You are so so welcome