VMware Communities
klepp0906
Contributor
Contributor

VMware NAT adapter is showing up as first/priority when scanning local network

So i've been trying to solve this for a solid week.   can NOT figure it out.

Coming here is my last hoorah so to speak.

I'm using an application called Aquilatech Wake-On-LAN.   It's an open source wake on lan utility knife sort of jobbie.  It has a feature to scan the local network for PC's to add automatically.  I set the IP range to scan the limited range of IP's i have set for my local network.   It picks them all up properly and displays the IP address, the host name, the mac address, the NIC name, and the Operating system.

The only pc that is giving me trouble is my main pc.   The one with vmware installed.

It picks the host name and the operating system up properly, but thats it.   The NIC card it pegs as "VMware Virtual Ethernet Adapter for VMnet8" and as such, it lists its IP and Mac address.

What's interesting is the IP of the NIC is well outside the range I've set to scan.   192.168.1.1 - 192.168.1.3.   Should pick up 3 pc's and it does.  Except for the virtual adapter with an ip of 192.168.204.1.

Anyhow, I can edit this information manually and get it in and functioning of course.   I'm just trying to ascertain why its behaving this way as to avoid any type of fallout elsewhere down the road.   And to perhaps learn something.

My research led me to Get-NetIPInterface ala powershell, which displays the interface index metric for all the installed interfaces.   While i had hoped this was the answer, it is not.   The Vmware cards already have a lower priority (higher number) than my physical adapter.

If anyone can get this sorted for me i'd be elated.

Reply
0 Kudos
3 Replies
louyo
Virtuoso
Virtuoso

A SWAG: I don't know anything about Aquilatech but they probably use something like nmap. You have 2 subnets. Nmap will not provide data like mac addresses across subnets (don't think that has changed, I have not tried that in a long time). If you look at a map of the VMNet8 subnet, you will see one address that is a gateway and another that is the VMware "NIC", and the third that is your .

In some scans, on a NAT setup, nmap will show a response from every address. This same thing happens on some VPN connections.

---------------------------------------------

# Nmap 7.60 scan initiated Sat Apr  4 18:08:07 2020 as: nmap -sn -oN nmap.log 192.168.172.0/24

Nmap scan report for T5810 (192.168.172.1)

Host is up (-0.20s latency).

MAC Address: 00:50:56:C0:00:08 (VMware)

Nmap scan report for _gateway (192.168.172.2)

Host is up (0.00019s latency).

MAC Address: 00:50:56:FD:20:A4 (VMware)

Nmap scan report for 192.168.172.254

Host is up (0.00019s latency).

MAC Address: 00:50:56:E5:AC:BF (VMware)

Nmap scan report for ubuntu (192.168.172.145)

Host is up.

# Nmap done at Sat Apr  4 18:08:12 2020 -- 256 IP addresses (4 hosts up) scanned in 5.65 seconds

-----------------------------------------------

Lou

dariusd
VMware Employee
VMware Employee

Heh.  I was just about to point you to Machine scan seeing incorrect interface ID & IP/Mac during scan · Issue #167 · basildane/WakeOnLAN ·...​ but then I noticed it was from you.  :smileygrin:

So... Looking through the code, I think function GetWmIdata (GetWMIdata) in Search.vb has a logic defect (if I am understanding the code correctly – I last used Visual Basic about 20 years ago, and last used CIM/WMI many years ago, so take my analysis with a large pinch of salt).  Upon connecting to a remote host, it fetches the computer name and OS name, then loops through every IP-enabled NIC on the host.  For each NIC in the host, it:

  • Picks the last IP address assigned to the NIC and uses that as "ipaddress";
  • Extracts the description from the NIC and uses that as "netinterface";
  • Extracts the MAC address from the NIC and uses that as "macaddress";
  • Checks the NIC for power-management capabilities, wake capabilities and WoL capabilities.

When multiple NICs are present, it appears to continue looping away until it has enumerated them all, but in each case it overwrites any previously-discovered properties with those of the latest-discovered NIC (except for the power-management and wake capabilities... those end up set to true if any NIC has those capabilities).  I do not see any code there which actually verifies that it is choosing the properties from the NIC which is connected to the interface over which it is performing the probe... or even that the interface is reachable from the network from which the probe is being performed.  It simply walks the list of NICs in the system and ends up using the properties from the last NIC it finds, whichever that happens to be.

I think function GetWMIdata needs to evaluate the reachability of that interface from the scan host, and take that into consideration when choosing which NIC's properties to return.

Hope this is of some use (and is not completely misleading or wrong...).

Thanks,

--

Darius

klepp0906
Contributor
Contributor

great information gentlemen.  I appreciate it very much!  Unfortunately my programming acumen doesnt even touch rudimentary.   I'm one the kids today would call a "script-kiddie" at best lol.

I'll certainly pass that information on in hopes that (seeing as it is open source) someone can address the shortcoming. 

That being said - either way its a relief to know its not an issue on my end that would prevent or break any functionality elsewhere down the road.  (a config issue persay)

For awhile I was unable to wake other pc's but only from 1 specific pc, and 1 specific app.   Turned out it was due to my virtualbox adapter having the same/equivalent interface metric as my physical adapter.  Digging deeper the metric assigned has been a known problem with virtualbox over a decade.  Just never addressed i guess.

I appreciate the time very much guys Smiley Happy

Reply
0 Kudos