Name Resolution (DNS) doesn't work for internal LAN addresses from Guest machines (always resolves to 198.105.254.228)

[thomasoatman]

Good morning.

The name resolution from inside my guest VMs is not working.

ping on any non-internet-existing address resolves to 198.105.254.228

For instance, inside one vm, trying to ping another:

   C:\>ping win7dev

   Pinging win7dev.local [198.105.254.228] with 32 bytes of data:

A ping from the Host works:

   C:\>ping win7dev

   Pinging win7dev [192.168.0.28] with 32 bytes of data:

My setup:  (I work from home so this is a very simple network)

     Windows 8.1 Home

     VMWare Workstation 11.1.2

     Time Warner Cable through a Netgear AC1750 WiFi Cable Modem

     Bridged networking with Physical Network Replicated

This page would seem to be useful but the resolution did not help:

http://useragent.xyz/why-is-ping-resolving-to-an-ip-198-105-254-228-for-any-random-hostname-that-i-t...

The only solution VMWare Support is offering is to hard code all my VM's IPs and setup hosts files everywhere.

[thomasoatman]

So.  As I was typing this question up and talking to VMWare Support, it occurred to me to setup the router itself for a different DNS Server.

The original setup on the router was getting the addresses automatically:

I changed it to use Google DNS:

This resolved my issue.  But I am no CNE so I don't know if this will cause any other problems.

[thomasoatman]

Okay.  mostly fixed.

the VMs can resolve each other.  But they can't resolve the name of the Host machine.

So..  Inside a VM, I try:

   C:\>ping AnotherVm

   Pinging anothervm [192.168.0.26] with 32 bytes of data:

But ping the host::

   C:\>ping TheHost

   Ping request could not find host TheHost. Please check the name and try again.

[wila]

Hi,

I tried to resolve this with Thomas, but could not.

Some more info.

He changed DNS config on some of the guests to have the router (192.168.0.1) first and register their names with the router.

Some guests have netbios protocol enabled and probably get names that way. But using netbios isn't very great in this day and age.

Using nslookup to his router never resolved anything for local network.

eg.

nslookup win7dev 192.168.0.1

does not give a result.

while putting google.com (or any other domain) in there did resolve properly.

Ping via ip between the machines works.

Putting hosts as DHCP reserved does not add them to local DNS either.

The configuration options in the netgear are surprisingly limited, even in the "Advanced" menu, the only DNS option is the screenshot above.

Note that he is using wireless as his main network.

One oddity we noticed in the netgear was that it showed the guest with the same MAC address as the host even while in the guest the network card had the normal MAC address (00:0c:etcetera)

Ideas, welcome.

--

Wil

[Dayworker]

The problem seems to be the "Time Warner Cable through a Netgear AC1750 WiFi Cable Modem". Mostly if not cable providers prevent the usage of multiple devices and/or own DNS settings. I believe the DNS settings are hard-coded in the router firmware.

I suggest to use a second router behind the Netgear to solve this barrier. This router gets an IP from the Netgear via DHCP and opens its own net for LAN/WLAN. In this net can you do what you want.

[wila]

I might have misunderstood Thomas, but he said the modem wasn't from Time Warner.

The "prevent usage of multiple devices" is something I don't expect to see on a home connection these days. 10 years ago, yes.

Besides he has multiple devices working just fine, they get an IP and DNS settings via the local DHCP server in the router/modem.

But I completely agree on the modem/router to be highly suspicious.

Adding an additional router that works properly is a solution, but I'm not sure he likes that.

Besides he might have to make adjustments then for other software that is sensitve for "double NAT" issues.

Perhaps better would be to just add a device that does DNS?

I suggested him to use a firewall VM, but maybe a Raspberry Pi or something might be a better solution as that works without a desktop computer being up and running and then have that RPI provide DHCP/DNS to the rest of the network.

--

Wil