C9300 Strange behavior with enabled ACLs on the switchport

[StefanSeubert44470]

Hello people,
I am rolling out several dACLs via ISE on the network.
So far, everything has worked wonderfully. Here and there, of course, an ACE is missing, but that could always be analyzed and fixed in a short time.
But now I have a behavior with Igel ThinClients, which I do not understand.
In detail it is about the AD password change when the password has expired.
Users prompted at login could not change their password.
I then saw that the port UDP/TCP 464 was not unlocked. This was added, but the password change was still not possible.
We then took away the ACL again and created a PCAP via monitor capture. Unfortunately, I have not found any other ports that the ACL does not already take into account.
Next I wrote all domain controllers (20 pieces) per permit ip any host X.X.X.X into the ACL. Again the same result, password change not possible.
At last I wrote a permit ip any any at the first place of the ACL. Also without success.
With activated ACL I have also very mixed errors.
Without ACL the user changes the password and the Citrix session starts. He does not have to enter the new password again.

With active dACL we sometimes had the condition that the password is changed and the user is redirected to the login with the error "wrong password". If he now enters the new password, he gets access. At the next attempt the password is not changed.

Here is one of the ACL

permit udp any any range 67 68
permit icmp any any echo-reply
permit udp any 10.0.0.0 0.255.255.255 eq 123
permit udp any 10.0.0.0 0.255.255.255 eq 53
permit tcp any 10.0.0.0 0.255.255.255 eq 1494
permit udp any 10.0.0.0 0.255.255.255 eq 1494
permit tcp any 10.0.0.0 0.255.255.255 eq 2598
permit udp any 10.0.0.0 0.255.255.255 eq 2598
permit ip any host X.X.X.X (20x for each DC)

The problem also occurs when I configure an ACL on the switch with the one entry "permit ip any any" and bind it on the port with ip access-group xxx out.

My understanding is that dACL are applied to the session outbound. Thus, an incoming connection, if necessary, should reach the client. However, my captures did not show any incoming communication.

Has anyone by chance had a similar problem before? On our Windows FatClients dACLs are also applied, here the password change works without problems.

Firmware from the switch i tested is 17.6.3, 17.6.5 and 17.9.3

Thanks for your help.

[Arne Bier]

I was under the impression that dACLs are applied to the endpoint session at ingress.  Remember also that the pre-auth ACL (for Low Impact Mode) is added to the interface using the "in" keyword. I assumed then that dACLs follow the same logic (even though I have not found a way to verify that) - but if you look at the dACL syntax, the source / destination syntax seems to support that theory.

Have you tried removing the NAC on a client interface, and then running a monitor capture command (if the switch supports local packet capture) ? I think the Interface must be Up/Up before the monitor capture will work - might be tricky timing.

[StefanSeubert44470]

Hi Arne,

yes, you're right, I expressed myself incorrectly. I meant that the ACL is applied by the client towards the network, which corresponds to the command ip access-group XXX in if you would configure it statically on the interface.

I am a bit further along with my problem, or rather I found a workaround. But I still can't explain it to myself.
In our domain there are about 20 domain controllers, one per site and two in the data center.
In the Active Directory configuration of the thinclients the domain controller is specified as DNS entry, which returns all domain controllers. In my recording I see that there is communication with up to 8 different DCs. At each step a DNS lookup is done again and a different DC is used.
If I change the configuration and store only two domain controllers the ACL works as expected. The ThinClient use only the first one.
We will implement this now, because it also reduces the cross communication over the WAN.

I just can't explain why the ACL works when the thinclient is talking to a dedicated DC and the communication "seems" to be disturbed when 8 DC are involved.
My first thought here was AD replication, but then we should have had the problem before the ACL rollout.

BR Stefan

[ammahend]

Interesting, thanks for sharing, are thinclient the only ones effected ?

[StefanSeubert44470]

Hi annahend,

yes currently this only occurs with the Igel thinclients.
I assume that with fat clients (windows) the AD Sites and Services take effect and the fat client always communicates with its logon server.

BR Stefan