VMWare VMNET Adapters Triggering Public Profile for Windows Firewall

Are you sick and tired of switching the VMWare virtual network adapters from the “public” network profile to a “private” network profile each time you reboot or do something else that causes Vista/Win2008 to forget what you told it to do ten minutes ago? This is probably a familiar sigh (I’m using Workstation):


As you can see, the lower two connections are seen to be in a “Public network.” This has the net effect of making Windows believe the whole machine is exposed to a public network, and it will trigger the public profile for Windows Firewall. This is normally a good thing, but in this case it’s just an annoyance. These two network connections are not actually external gateways that can let in the bad guys. They are just dummy adapters for VMWare’s host bridging which allow the virtual machine to access the host machine’s network. Because they don’t identify themselves properly, they are flagged as an “unidentified network,” and your changes are never persisted.

So what do you do? The magic information is buried in MSDN:

Vista automatically identifies and monitors the networks to which a computer connects. If the NDIS_DEVICE_TYPE_ENDPOINT flag is set, the device is an endpoint device and is not a connection to a true external network. Consequently, Windows ignores the endpoint device when Windows identifies networks. The Network Awareness APIs indicate that the device does not connect the computer to a network. For end users in this situation, the Network and Sharing Center and the network icon in the notification area do not show the NDIS endpoint device as connected. However, the connection is shown in the Network Connections Folder. Also, if NDIS_DEVICE_TYPE_ENDPOINT is set, the Windows Firewall ignores the connection when Windows Firewall enforces public, private, or domain policies.

So I hacked together a PowerShell script that will scan your adapters for VMWare’s virtual NICs and make the necessary registry changes. It will also disable/enable cycle the adapters so that the changes take effect. After this is done, you will see them in your Network Connections page – albeit lacking a network category -- and the connections will no longer appear in the Network and Sharing Center nor will they affect your Windows Firewall policy no matter how many times you reboot!


Here’s the script source below. It requires that you run it in an elevated shell in order to write the registry changes and cycle the adapters’ enabled state.

  1. # see http://msdn2.microsoft.com/en-us/library/bb201634.aspx  
  2. #  
  3. # *NdisDeviceType   
  4. #  
  5. # The type of the device. The default value is zero, which indicates a standard  
  6. # networking device that connects to a network.  
  7. #  
  8. # Set *NdisDeviceType to NDIS_DEVICE_TYPE_ENDPOINT (1) if this device is an  
  9. # endpoint device and is not a true network interface that connects to a network.  
  10. # For example, you must specify NDIS_DEVICE_TYPE_ENDPOINT for devices such as  
  11. # smart phones that use a networking infrastructure to communicate to the local  
  12. # computer system but do not provide connectivity to an external network.   
  13. #  
  14. # Usage: run in an elevated shell (vista/longhorn) or as adminstrator (xp/2003).  
  15. #  
  16. # PS> .\fix-vmnet-adapters.ps1  
  18. # boilerplate elevation check  
  20. $identity = [Security.Principal.WindowsIdentity]::GetCurrent()  
  21. $principal = new-object Security.Principal.WindowsPrincipal $identity 
  22. $elevated = $principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)  
  24. if (-not $elevated) {  
  25.     $error = "Sorry, you need to run this script" 
  26.     if ([System.Environment]::OSVersion.Version.Major -gt 5) {  
  27.         $error += " in an elevated shell." 
  28.     } else {  
  29.         $error += " as Administrator." 
  30.     }  
  31.     throw $error 
  32. }  
  34. function confirm {  
  35.     $host.ui.PromptForChoice("Continue", "Process adapter?",  
  36.         [Management.Automation.Host.ChoiceDescription[]]@("&No", "&Yes"), 0) -eq $true 
  37. }  
  39. # adapters key  
  40. pushd 'hklm:\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}' 
  42. # ignore and continue on error  
  43. dir -ea 0  | % {  
  44.     $node = $_.pspath  
  45.     $desc = gp $node -name driverdesc  
  46.     if ($desc -like "*vmware*") {  
  47.         write-host ("Found adapter: {0} " -f $desc.driverdesc)  
  48.         if (confirm) {  
  49.             new-itemproperty $node -name '*NdisDeviceType' -propertytype dword -value 1  
  50.         }  
  51.     }  
  52. }  
  53. popd  
  55. # disable/enable network adapters  
  56. gwmi win32_networkadapter | ? {$_.name -like "*vmware*" } | % {  
  58.     # disable  
  59.     write-host -nonew "Disabling $($_.name) ... " 
  60.     $result = $_.Disable()  
  61.     if ($result.ReturnValue -eq -0) { write-host " success." } else { write-host " failed." }  
  63.     # enable  
  64.     write-host -nonew "Enabling $($_.name) ... " 
  65.     $result = $_.Enable()  
  66.     if ($result.ReturnValue -eq -0) { write-host " success." } else { write-host " failed." }  
  67. }  

Have fun.

blog comments powered by Disqus

About the author

Irish, PowerShell MVP, .NET/ASP.NET/SharePoint Developer, Budding Architect. Developer. Montrealer. Opinionated. Montreal, Quebec.

Month List

Page List