Windows 10 version 1809 Hyper-V Virtual Ethernet Adapter vs AnyConnect

While this problem occurred months ago, I didn’t think of writing this blog post until now but better late than never, I guess.

Introduction

As Windows 10 moves forward with more and more updates every year the rest of us have to do what we can to keep up. Changes in Windows 10 lead to a lot of time spent making sure all your other software runs without compatibility issues when the new Windows versions are getting tested before being pushed out to end-users.

One issue in particular that I myself have run into is that newer versions of Windows 10 (starting with version 1809) tend to mess with two modules in the Cisco AnyConnect suite: the Network Access Manager (NAM) and the VPN module. I ran into the issues on both AnyConnect 4.5 and 4.6 versions.

The cause of the issue is that if you are running Windows 10 Enterprise (which most businesses are), you most likely have useful security features such as Credential Guard and Device Guard running. I am not going to go into detail on what these features do but using these features requires a Hyper-V Virtual Ethernet adapter to be installed, which will be installed by the operating system automatically.

Up until Windows 10 version 1809, this Hyper-V Virtual Ethernet Adapter hasn’t been interfering with AnyConnect at all (in my experience) but now something has changed and to AnyConnect, this virtual ethernet adapter looks just like any real network adapter you have in your computer (like your wired Ethernet adapter or your wireless network adapter).

The problem with the Network Access Manager module

The issue first presented itself when computers every time a computer running Windows 10 version 1809 boots. If you are using AnyConnect’s Network Access Manager module to manage your network connection, the Hyper-V Virtual Ethernet Adapter would be chosen as a “valid” wired Ethernet connection. Not only is the Hyper-V Virtual Ethernet Adapter always up and running, but it also has a self-generated IP address in the private 172.X.X.X IP range.

In the image below you can see that AnyConnect NAM seems to have a functioning wired network connection when it actually just has managed to get hold of the Hyper-V Virtual Ethernet Adapter instead of a real network adapter. In this case, my PC was not connected to the actual wired network at all and therefore it should’ve connected to the wireless network on its own.

And if we dig a little deeper in AnyConnect there’s more information to be had. We can see that AnyConnect thinks it has connected to an “Open” (non-authenticating) wired network and that the Hyper-V Virtual Ethernet Adapter is being utilized for the connection.

To temporarily restore the real network connectivity I could either connect the computer to a real wired network and select the wired connection profile or a wireless connection profile in the AnyConnect list of available networks.

The problem with the VPN module

The problem with the VPN module is a bit similar to what happens with the Network Access Manager module problem. After connecting to the ASA running Remote Access VPN, authentication works as it should when I log in with my username and password. However, after the VPN session is established, you can see that the Network Access Manager module has assigned the VPN IP address (given to you from your ASA IP Pool) to your REAL wired or wireless network adapter. This breaks the VPN connection only seconds after being established, causing the VPN to enter a disconnect/reconnect loop instead of working steadily.

Unfortunately, I didn’t take any screenshots of this process.

Solution

The solution to dealing with these problems, in the long run, is to prevent the Hyper-V Virtual Ethernet Adapter and the Cisco AnyConnnect Secure Mobility Client Virtual Miniport Adapter from using the Cisco AnyConnect Network Access Manager Filter Driver. Speak to your friendly sysadmins regarding wide implementation of the PowerShell commands below. Please note that these commands have to be run on bootup EVERY SINGLE TIME. They should be implemented in such a way that they are run very early in the computer/Windows bootup process before Network Access Manager gets a chance to mess it up.

Fix for Network Access Manager module (run as Administrator in PowerShell):

Disable-NetAdapterBinding -InterfaceDescription *Hyper-V* -ComponentID CSCO_acnamfd

What this command does is uncheck this box below in the properties for the Hyper-V Virtual Ethernet Adapter.

Fix for VPN module (run as Administrator in PowerShell):

Disable-NetAdapterBinding -InterfaceDescription *Cisco* -ComponentID CSCO_acnamfd

Similar to the image above, this command will uncheck the use of your wired and wireless network adapter for your Cisco AnyConnect VPN module. This way AnyConnect VPN will use the IP address assigned to it from the ASA when communicating over VPN, instead of trying to use the IP address of your wired or wireless network (which simply wouldn’t work).