AnyConnect NAM with RDP issues

[ksastoqu]

Hello Team,

The customer has a deployment of AnyConnect which only uses the NAM (VPN functionality is not in use) to access the wired network using dot1X EAP Chaining (both user and machine are authenticated).   

Version: Windows Version 1803 (OS Build 17134.1006)    

AnyConnect Version: 4.7.00136 and 4.7.04056 

They have several users which use NUC devices (small intel PCs) when they are in the office. From home, they use laptops but they often use those laptops to RDP into the NUC on their desk. This is where they experience issues.    

When the user leaves for home in the evening and logs off (not just locks) his user, he is unable to log in through RDP. The user can use RDP into Win10 and can enter his/her password however once that is done the login process hangs.

After this, the session disconnects and the device becomes unavailable (1 or 2 pings to the device are lost) for a very small   period of time. Afterwards the user can try the login process again but gets the same issue.   

They disabled dot1x completely on the switch: No change 

Removed AnyConnect from the device: Problem solved, user is able to log in                       

Upgraded AnyConnect to latest version: No change       

Also, they tried having another user log in to the physical device at the office, and then the remote user can RDP to the device,     kick the user off and connect without a problem.

Is this expected? What changes can be done to fix this?

[Ben Walters]

It seems like this is expected behavior, we had the same issue when we were first setting up 802.1x and the only workaround that TAC suggested was to use the "Extend user connection beyond log off" setting. The XML tag is : <extendUserConnectionBeyondLogoff>true</extendUserConnectionBeyondLogoff>.

We found that when using EAP chaining when the authentication switched from just machine to machine and user there is a very quick disconnect and reconnect and any local user won't even notice. However, it would disconnect the RDP session exactly as you described unless another user had logged on first. 

Once we enabled that setting though it seemed to resolve the issue, although once in a while the RDP will still disconnect and the user will have to retry a second time before they can RDP to the machine. 

[casdmg]

We are experiencing the same issue if a user is completely logged out of a machine.  I was under the impression that extend user connection was only applicable to LEAP.  TAC has not mentioned that as a fix as of yet but they haven't been super responsive.  Probably because the logs do not have any distinct errors in them.    

What inner methods are you using for EAP-FAST?  We are using EAP-FAST(eap-tls) leveraging certificates for user and machine authentication.  

[Mazocoli]

I have the same problems.

Even with all workaround, it's not 100%

I haven't test this:

Including all workaraound + <extend UserConnection Beyond Logoff>

Does it Solve 100% the problem ?

[pgiouvanellis]

Did you manage to solve the issue ?

I am facing the same issue with EAP-Chaining and the behavior is exactly the same as you described,

Notice that is ISE 2.6 implementation and Anyconnect 4.8 

Thank You,

Palaiologos

[stsargen]

This behavior is likely due to a Microsoft bug.  It is referenced by Cisco bug #CSCvo47467.  It has to do with Windows firewall quarantine policy.   See if disabling the firewall completely allows it to work.  If so then you are hitting this issue.

This was covered on a different thread.

https://community.cisco.com/t5/network-access-control/rdp-is-not-working-with-cisco-nam-user-and-machine-auth/td-p/3364738

[pgiouvanellis]

And what about the XML tag  : <extendUserConnectionBeyondLogoff>true</extendUserConnectionBeyondLogoff> 

which mention above ?

We use EAP-Chaining and is not available choice on Profile Editor .

Can i add it to xml manual and if yes where exactly i have to place the tag ?

Thanks .

[stsargen]

If you don't see the option then you are using an extremely old version of the profile editor, or you are not looking in the correct place.  I have attached a screenshot of where this can be found under the "User Auth" section of the network profile.

[pgiouvanellis]

You are right ,

It was under my nose.

Thank You.

[pgiouvanellis]

Hello ,

I tried both : 

- <extendUserConnectionBeyondLogoff>true</extendUserConnectionBeyondLogoff>

- Add Registry Key IntfQuarantineEnabled=0 

but none of them worked .

The behavior was the same .

Customer open RDP puts user account and then black page appeared , the push him out.

Is there anything else we can try .??

Thank You,

Palaiologos

[stsargen]

You can try to disable the Windows firewall completely.  If the issue is no longer seen then you are in fact hitting the issue above.  The only other option is to have the user stayed logged in on the local PC, or switch your NAM profile to use machine auth only.

[albowi]

We are experiencing the same, none of the above provided workarounds solved it.

it seem windows firewall is treating the NAMs network connection as either private or public. as our domain profile allows RDP

disabling the firewall did work, but is not a viable option. - we saw the dropped packets in the windows firewall log

we enabled RDP for private and local profiles and could connect. Afterwards we limited the scope that could connect in windows firewall.

- We are currently looking in to the windows firewall behaviour, but would stress that build 1803 has been out there for a while and Cisco and Microsoft should collaborate on solving this.

[stsargen]

If you have the capability I would suggest raising a case with Microsoft on this.  Cisco currently has a case open, but if more customers are reporting this issue to them it may set a higher priority with them.

[pgiouvanellis]

Hello ,

In my case it seems that the workaround with adding the registry key that is described to bug CSCvo47467

worked and we are able to RDP .

Thanks