AnyConnect Compliance Module routing decisions

[Baconframe]

Hi!

We recently deployed 802.1X with Posture for our wired network (with MachineAuthentication / EAP-TLS) which is mostly a Windows 10 client environment. I would say that the overall experience is good, but some of the clients are having issues to authenticate properly. However, the problem is only seen if the client PC is connecting to the network via a docking station (using a separate NIC). The AnyConnect Compliance Module will search for the policy servers but be unable to detect any - which will then result in the client being stuck in "Posture Session status: Unknown" at the ISE side. But If we disable the other NICs (the wired NIC of the actual PC and the wireless NIC) the Compliance Module will actually be able to find the Policy Servers while utilizing the NIC of the docking station. I get the feeling that the Compliance Module will try to route the policy traffic via these NICs even though there is no active connection at these NICs. I thought that the AnyConnect Compliance Module would base its routing decisions on the routing table of the client. Which seems to not be the case, since we tried adding static routes pointing directly to the policy servers using the NIC of the docking station as a gateway and it would still be unable to detect the servers (as long as the other NICs were not disabled).

We have also tried to alter the windows order priority of the NICs resulting in:

1st NIC of Docking Station (if any present and active)

2nd Actual NIC of Client PC

3rd Wireless NIC

But unfortunately no success.

I would say that maybe 2-3% of the client are having these issues, so it is probably related to the clients themselves, but I have honestly no clue of what could be causing this.

Have you guys ever seen anything like this?

We use:

ISE version 2.6 with 3 installed patches

AnyConnect 4.8 with compliance module 4.3.1126

(Please let me know if there is any other information that I could provide for you)

[Colby LeMaire]

The AnyConnect agent won't make routing decisions itself.  I think the issue you are running into is due to a relatively new feature in Windows 10 called "Soft Disconnect."  With Soft Disconnect enabled, the OS will allow previously established communications to continue on other NIC's even if Wired becomes active and is preferred.  One way to see if this could be the issue is to look at the ISE Live Logs and see if you are getting multiple authentication success events for the same host (one on wireless and one on wired) within a short period of time (~1-2 minutes).  The good news is that this feature can be disabled with a GPO setting.  You can read more about this feature and how to disable it here:

https://winaero.com/blog/enable-or-disable-soft-disconnect-from-a-network-in-windows-10/

[Baconframe]

This could actually be the case here, because I remember seeing authentication requests from two different MAC-addresses belonging to the same identity (the actual wired NIC from the PC and the docking station). Since the wireless network is purely a guest network with no access to the policy servers I suppose I won't be able to verify this within the ISE logs, but it could surely be the very same problem.

I'll try to get a hold of a user and verify this. Thank you for this input it is much appreciated!

[Baconframe]

We tried the solution which was suggested by Colby but we would still see the same outcome unfortunately (unknown endpoint at the ISE side), but we also discovered that it might only be 2-3 users that have the very same issue. And these endpoint clients seem to be another type of laptop and docking station that deviates from the standard setup. We'll look into replacing these.

We have however more users with similar problems, but these are more or less "intermittent" and are usually solveable by reconnecting the network cable (or cycling the NIC in some way). However, this is not a produkt of the posture problem, because these clients are not even able to authenticate via the initial EAPoL transmission (in some scenarios). I found that others are experiencing this as well:

802.1X environment problems with authentication after 1903 update 

However, there seem to be no universal solution to this issue, only small fixes that will mitigate the problem in 8 out 10 cases (which would explain why only some of our users are having these issues).

[Marcelo Morais]

Hi,

 please try the following command:

show logging application ise-psc.log | inc cpm.posture

Take a look at the difference in output when using the Dock Station (without disable any other NIC) and the Wired NIC.

Hope this helps.