VMware Communities
defect
Contributor
Contributor

Vista "Unidentified Network" Issue

There is an issue with VMware Workstation's network adapters in that they are placed in the 'unidentified network' location which by default is a 'public location'. If any network location in Vista is public then the public location firewall rules apply (currently for me that means non discoverable etc).

The unidentified network location can be manually changed to private but this setting does not persist between host reboots (I believe this is by-design).

I would think that the Vmware adapters should be placed in a different location to prevent this problem but I'm not sure why Vista is identifying (or should I say failing to identify) the adapters. I'm attempted to set the IP addresses manually for both adapters as well as adding a gateway (the same IP) as I've heard this might help in getting identification to work but the settings get forced by (presumably by VMware) each time (strangely enough the forced IPv4 properties for both adapters is blank).

Can someone shed some light on this issue - I'm surprised there aren't any other posts there about this as it's a bit frustratiing (being forced to run in public location mode).

Reply
0 Kudos
75 Replies
ejobrien
Contributor
Contributor

That reminds me, I've also noticed that installing the VMWare upgrades removes the fix. This is very annoying.

Reply
0 Kudos
shirt
Contributor
Contributor

Even after applying *NdisDeviceType, my network connection is not there. i have attached a snapshot of the same. let me know,if any other changes needs to done.

Thanks,

Reply
0 Kudos
ejobrien
Contributor
Contributor

That sounds like it may be an unrelated problem. The *NdisDeviceType change is to fix a specific issue, where Vista sets the vm networks as unidentified, and accordingly changes the firewall to the public profile. Even before applying the change, I didn't have any problems with connectivity.

It looks like the *NdisDeviceType change has worked, as your vm networks are not displaying a Network Category of "Public Network".

In the "Network and Sharing Center" the vm networks shouldn't appear.

Reply
0 Kudos
Enickma
Contributor
Contributor

I can't believe this hasn't been a bigger fire drill. This basically comes down to VMware customers that run Vista NOT being able to manage thier firewalls. That would strike me as a major issue. Thanks to VMware, and the folks on this thread for helping with the resolution. Of course, there are still some nightmare headaches where the rubber meets the road. So we've got a way to tell Vista to ignore vmnet adapters as it pertains to network identification....great. But in a practical sense....are you going to manually touch EVERY one of your Vista boxes running VMware to remediate them all? Are you going to want to mess with it every time someone adds a new virtual adapter, or an update reverts the setting? Of course not.

I wrote a VB script that enumerates the appropriate device class's sub-keys, enumerates the sub key values, and looks for a string value "vmnet" which identifies a vmware virtual adapter. Once it finds that, it looks at the data for the dword value *NdisDeviceType. if it's not there, it's created and set to 1. If it's 0, it's set to 1. If it's greater than 1, it's set to 1. If any of the mentioned changes occur, it then grabs the value of of the NetCfgInstanceId string, and uses that to determine which network adapter just got changed, and disables / re-enables that adapter....problem solved. If no VMnet adapters are found, or if the *NdisDeviceType dword is already 1, the script doesn't change anything. I'm testing this as a group policy enforced machine startup script, and it seems to be working perfectly. The script has to be ran with appropriate rights to modify HKLM. In Vista that means that even when logged in as an administrator, you've got to elevate to "run as administrator" in order for the script to work. If you want to manually run the script, simply open an adminstrative command prompt by right clicing CMD and selecting "run as adminstrator", and then launching the script from your prompt. If you run it as a machine startup script, it will execute with local system priveleges, which are also sufficient to modify HKLM. If deployed via startup script, it will run every time the system starts up. In that case, the only time you don't have the situation covered is if someone adds a new VMnet adapter... in that case, their firewall would go to public mode until the next reboot. If you really want to cover that, you could set an event trigger to run the script on the right PNP event...but I'm not too worried about that part of it.

Disclaimer! I am not a master script guru... I tend to write them as I need them, in a very utilitarian way. You may think this is a terrible script. You may find yourself realizing a better way to do this, wanting to make your own tweaks, or clean it up, so it looks like it was written by an actual script writer Smiley Wink ...feel free. It does seem to work perfectly well for me in it's present form. I tried to document each part of it, in order to make it as easy to understand as possible. If anyone has any questions about any part of it, I'll do my best to answer them.

Edit 8/26 Thanks to Cantoris for making me realize that I could make this script 1/3 it's size...simply by not being an idiot...lol. Smiley Happy New version attached

Edit 8/27 No longer using this version of the script...see post below.

Reply
0 Kudos
Enickma
Contributor
Contributor

After doing some more looking into the ControlSet001 vs. CurrentControlSet thing, I've decided to use a version of my script that uses CCS instead of CS001.

Making sure that these settings apply to the current configuration every time is important. I'm leaving the previous version that uses ControlSet001 attached to the last post in case someone wants it, but the CCS version is working fine, and it strikes me as more consistent under a greater variety of cicrumstances.

Reply
0 Kudos
Dragon_5150
Contributor
Contributor

If you are sure that all of the connection in your machine are secure, and ONLY IF THEY ARE SECURE

Open GPEDIT.msc, go to computer configuration, windows settings, security settigns, network list manager policies.

Open Unidentified networks and change it to private. This will stop thesettings from reverting every time.

Reply
0 Kudos
Roddles
Contributor
Contributor

What would be even better would be to able to identify the VMWare networks as Public or Private just like every other network that is identified on Vista. Then we wouldnt have this problem.

I just run the script mentioned a few posts earlier to resolve the problem, but its not the best solution obviously but it works.'

(Well done to Enickma for that script. works well).

Reply
0 Kudos
solidus
Contributor
Contributor

It sounds like the *NdisDeviceType fix is the best one so far. But before I knew about that, I found two other work-arounds, which may still apply to you if you can't or don't want to use the *NdisDeviceType fix or edit the registry.

  1. Just use bridging only, and give up DHCP and NAT. It removes the Unidentified Network entirely. This is the easiest fix if you only use bridging, like me.

  2. Change the defualt classification of Unidentified Networks to Private.This is another easy fix and would be pretty safe on workstations or servers already behind a firewall.

I have instructions with screenshot in my blog. I hope it helps someone.

-Chris

Reply
0 Kudos
saivert
Contributor
Contributor

Just made a ZIP containing both the Windows Script Host scrip and a PowerShell script

http://home.no.net/nxs/files/vmware_network_adapters_fix_for_vista.zip

VMWare should really fix this though so we don't have to use fixes like this.

Reply
0 Kudos
ejobrien
Contributor
Contributor

Thanks Saivert,

Tried out both scripts, and they work a treat.

Eugene

Reply
0 Kudos
DocX35
Contributor
Contributor

Thanks also Saivert,

These also work on Windows 7 RTM...

Thank you!

Reply
0 Kudos
simdoc
Contributor
Contributor

I just installed VMWare Workstation 7 on my Windows 7 RTM box and viola---the same problem is there!!! Why can't VMWare fix this problem instead of having to make us manually insert it?

Reply
0 Kudos
tavidal
Contributor
Contributor

All,

Had same issue as describe here, and I can't believe that VMware has not been able to or willing to fix this. Kudos to all that have commented on this topic and for the ones that helped create the script that fixes this issue, it worked perfectly for me. Like someone mentioned, without this fix, VMWare can't really say that the program is Vista compatible; incredible that this has not gotten more attention. Thanks to all again.

Reply
0 Kudos
FuNK3Y
Contributor
Contributor

Hi,

I was also annoyed by this problem, and therefore have written a little c# application that allows to show/hide NIC in the network sharing center using the tip described above.

Feel free to use it if it may be of any help...

Reply
0 Kudos
Cantoris
Contributor
Contributor

This is still an issue even now but at least not as much of a problem since each network interface in Windows7 can have its own profile.

Reply
0 Kudos
klepp0906
Contributor
Contributor

I mean.  Windows 11.  Still public unidentified VMnet1 and 8.  

prompts me for public firewall rules on restart cause for a second they somehow get priority first, prevents my wol packets from being sent entirely.  

ugh

Reply
0 Kudos