beta 3: name resolution for NAT question

[silliker]

Can someone please explain how Fusion is handling name resolution under OS/X ?

The Fusion DHCP server is assigning my guest a DNS server. The guest is getting different results resolving hostnames than I get on the host.

I'm using a VPN client that is updating the dynamic store with supplemental DNS entries, and the supplemental entries seem to be ignored when Fusion is handling the name resolution request.

A explanation of what the actual process is here, as well as debugging steps to see what the OS thinks is happening would be quite helpful.

Thanks,

-a

[rcardona2k]

I'm not 100% certain on this but think that the VMware NAT DNS service is forwarding requests to the DNS servers configured on the host, i.e. bypassing /etc/hosts or local name resolution. You can sort of confirm this yourself by installing Ethereal in your Guest VM and inspecting the payloads from the machine that answers your DNS queries. You may be able to monitor the other side of the NAT using tcpdump on the OS X side too.

If you want to use host DNS services, I recommend using Apple's NAT, i.e. Internet Connection sharing. Set your guest VM to bridged or host-only networking and share your host's Internet connection with either a wired/wireless interface or the loopback adapter. In this way OS X is required to provide DNS services for your guest VM.

[silliker]

Thanks. Hopefully someone from the dev side will pipe up with what's actually happening here.

-a

[admin]

Hi silliker,

The VMware NAT daemon (vmnet-natd) acts as the DNS server for all NAT'ted guests, so you'll notice the DNS server's IP address be the .2 address on the NAT'ted subnet.

The VMware NAT daemon uses the resolver library \[man 3 resolver] on the Mac OS host to resolve names. So it's possible that the reslover library on Mac OS doesn't pick up all the DNS servers one can configure on Mac OS, and your VPN client is populating new DNS servers in some such place.

It would be good to get to the bottom of this, so that VMware can fix the NAT daemon so it works in your situation. Please file an SR about this, if you don't mind! Please include as much information as you can share about your set up.

Thanks for reporting this issue!

[silliker]

SR 187510481

[silliker]

This is still an issue after applying beta 4

[mrichmon]

I'm having the same issue when connected to my VPN solution.

From the hosted OS I can ping machines via IP address at the other end of the VPN but DNS lookups are failing. Explicitly setting up DNS servers from the VPN within the hosted OS resolves this issue but ties the hosted OS's networking to only work when I am connected to the VPN.

[silliker]

and RC1

[silliker]

Sigh. And the 1.0 release. I never did have any contact on the SR I opened 3 months ago to track this issue.

-a

[sarcasticfringe]

Has this issue ever been resolved? I'm having all sorts of lovely problems with networking. NAT can't resolve any names at all while a bridged connection keeps dropping connections to my CVS and SVN servers. So, it makes the VM pretty much useless for me. I noticed some mention of this in the release notes for latest patch/updated. But after installing it I still have all of the same problems. So, please help. I'll have to switch to BootCamp and boot Windows for now - I"m not happy about that.

[johncaruso]

Re: "Explicitly setting up DNS servers from the VPN within the hosted OS resolves this issue but ties the hosted OS's networking to only work when I am connected to the VPN."

You were close. The best workaround I've found is to explicitly configure the VPN DNS server's IP address on the main connection (NOT the VPN connection) on the Mac side (not on the hosted OS side). For example, if your Airport connection is your main connection and your VPN DNS server is 10.1.2.3, you'd add 10.1.2.3 to the Airport connection's DNS configuration.

The big downside to this is that the DNS IP you configure may not always be an IP from which you want to get DNS--e.g. if you were using the public wireless at a cafe and someone noticed your machine sending DNS requests to 10.1.2.3, they could adopt that IP and effectively hijack your DNS. As long as you're aware of that caveat and modify your configuration accordingly when you're on unsafe networks, though, it's a reasonable workaround.

The core problem appears to be that the calls the VMware NAT daemon makes to the resolver library bypass the trickery the Mac side normally uses to resolve DNS queries first from the public connection and then from the VPN connection. This is a problem that I think VMware should address, since it seems like a bug that the same DNS queries that work just fine under OS X don't work for a NAT'ed client running under Fusion.