cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
865
Views
5
Helpful
7
Replies

Win10 SoftDisconnect feature and ISE Posture compatibility?

bravotom99
Level 1
Level 1

Just wondering if anyone has seen issues with Win10 and WIRED posture.  We have seen random issues with posture where clients say compliant but they are still have the redirect ACL on wired session.  When looking at the logs, we see a machine go through wired and wireless authentication at bootup and posture seems to send the result over the wireless connection with the wireless session ID.  We only allow one connection so the wireless is dropped but it seems like this feature will continue sending traffic over wireless before allowing wired to take over.

I am thinking it's a timing issue because we cannot reproduce the issue on demand but it happens often enough that it's been a major pain for users.  since this feature is enabled by default, i figured i'd ask if anyone else has seen weird issues.

 

https://docs.microsoft.com/en-us/windows-hardware/drivers/mobilebroadband/understanding-and-configuring-windows-connection-manager

 

From the article:

Initial connection

Windows automatically connects, and then immediately soft-disconnects in one circumstance. When the PC first starts or resumes from standby, all interfaces simultaneously attempt to connect in order to ensure that the user obtains network connectivity as quickly as possible. If multiple interfaces successfully connect, Windows begins soft-disconnecting interfaces immediately.

Soft disconnect works the following way:

  1. When Windows decides that a network should no longer be connected, it does not immediately disconnect. Abrupt disconnections degrade the user experience without providing an appreciable benefit, and are avoided when possible.

  2. As soon as Windows decides to soft-disconnect an interface, it informs the TCP stack that the network should no longer be used. The existing TCP sessions will continue uninterrupted but new TCP sessions will use this interface only if explicitly bound or if no other interface routes to the desired destination.

  3. more in the article linked above
7 Replies 7

Jason Kunst
Cisco Employee
Cisco Employee
I believe a better solution is anyconnect NAM (network access manager) will disable wireless if WIRED is connected. Otherwise you run into contention issues with the windows supplicant.

Colby LeMaire
VIP Alumni
VIP Alumni

I have experienced similar issues with one of my larger clients.  When they had both wireless and wired enabled, we would see successful authentications from both around the same time.  Posture on the client side says compliant but the message/report never makes it to ISE.  My client tried numerous settings in the BIOS and with GPO but we could never get a confirmation that any one thing worked.  And as you said, it was very difficult to recreate.  Although booting up with wired plugged in seemed like it would happen more often than just a user logging in or docking/undocking.  Almost as if the wireless and wired drivers are starting up at the same time and then it takes a bit for Windows to figure out that wired should be preferred.  But by then, the Anyconnect Posture module is in the middle of a session.  That setting that you reference sounds like it could be the issue or at least a contributor.

I’d recommend trying anyconnect Network access manager

@Jason Kunst- While I do agree that NAM would probably do a better job of controlling the interfaces and does offer more advanced options, NAM also adds another level of complexity for customers.  Complexity in getting the profiles correct, deploying the software/profiles, and in troubleshooting.  ISE and 802.1x is complex enough and the native supplicant should be enough for most use cases.  If this is a common issue across Windows 10 in general, it would be a good idea to isolate the issue and provide guidance to customers that still want to stick with the native supplicant.  Not to mention that NAM also has some licensing requirements too.


@Colby LeMaire wrote:

@Jason Kunst- While I do agree that NAM would probably do a better job of controlling the interfaces and does offer more advanced options, NAM also adds another level of complexity for customers.  Complexity in getting the profiles correct, deploying the software/profiles, and in troubleshooting.  ISE and 802.1x is complex enough and the native supplicant should be enough for most use cases.  If this is a common issue across Windows 10 in general, it would be a good idea to isolate the issue and provide guidance to customers that still want to stick with the native supplicant.  Not to mention that NAM also has some licensing requirements too.


Good point. From our side of things we don't have controls over what windows is doing with their NICs. Microsoft would be the source of truth on how to get their NICs and supplicant behaving the way the customer wants to. Perhaps there is a bug or an enhancement needed for it to work more like the customer is expecting? I will forward along to our SME as well to see if he has any advice as well.

I agree that this is something that needs Microsoft's attention.  I currently don't have a client experiencing the issue but if the original poster does, they can open a support case with Microsoft and get them to explain the behavior and what workarounds are available.

It's been a while since we've looked at NAM.  I didn't like it a few years ago and felt it was just another thing to cause problems.  We seem to be having better behavior by turning off SoftDisconnect for some users but since it's a sporadic issue, we need to let it bake for some time.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: