Guest with NAT networking: can't resolve hostname with SSH

[sockmonkey72]

Hi,

I have a Windows 10 VM running in VMWare 8 Pro. When using NAT networking, the VM can resolve DNS hostnames in the browser, but cannot do so from SSH (I'm using mysysgit's installed SSH). Under NAT:

(mingw64) $ git pull

ssh: Could not resolve hostname bitbucket.org: Non-recoverable failure in name resolution

fatal: Could not read from remote repository.

I get this with any repository, not just bitbucket. Switching to Bridged networking solves the problem, but de-isolates my VM from the rest of my network, so I would prefer to find a solution to the NAT case.

Thanks for any ideas!

[ManuelSidler]

Hi sockmonkey72,

I have the same problem. The workaround for me was adding an entry to the hosts file.

[sockmonkey72]

Thanks. Hopefully VMWare will acknowledge the problem and get a fix in for this at some point. Adding an entry for each host I need to communicate with is a hardship.

[nancyz]

Hi there,

Welcome to Fusion community.

I set up a repository on https://www.assembla.com/, but I could not reproduce your problem. I get the following result when using git pull in windows 10 VM in NAT mode.

$ git pull

Already up-to-date.

Did you setup route to your git repository inside VM?

[NickiSibbern]

Hi.

I'm having the exact same problem, I created a repository on bitbucket.org set my network connection to NAT and then tried to do a git push to that repository which results in.

ssh: Could not resolve hostname bitbucket.org: Non-recoverable failure in name resolution

fatal: Could not read from remote repository.

Please make sure you have the correct access rights

and the repository exists.

after adding bitbucket to my windows host file it works.

[glennblock]

HI folks

I found I am also hitting this. I just had a call with VMWare and was able to reproduce it with their tech. We tested Windows 10 with both with VMWare 7 and 8 and the same result. If you are using shared network, then resolution via SSH does not work. I tested directly using ssh.exe and the same result. We also tested on a pure Windows 10 box and it works.

One alternative workaround I found which can be used for now for the git case is not use SSH and instead use the HTTPS url, that works fine, though not ideal.

Anyway, Yogesh, the person I spoke to said he's going to follow up with their techs to see what can be done.

I'll keep everyone posted.

[MikaelSmith]

I've also run into this, using Windows 10 in VMWare 8 Pro. Strangely it only started after upgrading Git from 1.9.5 to 2.6.2. Git seems to have significantly altered how it packages ssh between those releases, which might be related.

[raphytaffy]

So if I am trying to push to github.com, I would add an entry in C:\Windows\System32\drivers\etc\hosts:

127.0.0.1

github.com

Is this correct? I have tried this and it hasn't resolved my issue, so I just wanted to confirm that I am following the correct steps.

[NickiSibbern]

Hi Raphytaffy.

you need to add the github ip to host and not localhost

[raphytaffy]

Jeez, brain fart moment. Thanks!

Looking forward to the fix though as I don't want to repeat for every host.

[Mikero]

Hi 😃

Did Yogesh give you a support case number or a bug report number by any chance?

I'd like to follow up internally, I do this type of workflow all the time.

[glennblock]

Cool, here is the number: 15788929410

[nicohvi]

I'm facing the same problem, and adding the appropriate IP to the C:\Windows\System32\Drivers\etc\hosts file did the trick. (Showing the entire path here since I myself spent quite some time editing /etc/hosts which did absolutely nothing).

[www23456]

start wireshark on vm,  you can ping/nslookup github.com from win10 vm,  you will see whether there are

dns query/dns response packets for this "github.com".

compare with the case which has dns error:   git clone git@....

maybe there is something in git code handling the name resolve...

[klucks83]

I too ran into this issue and was able to resolve it by modifying the AddressFamily value within the ssh_config file located in the following path of <msysgit_installation_path>\etc\ssh\ssh_config.

In my case, I uncommented the AddressFamily attribute and changed the value to “inet”.  Once doing this I was able to resolve my git server’s FQDN without the need of a hosts file entry.

http://linux.die.net/man/5/ssh_config

AddressFamily

Specifies which address family to use when connecting. Valid arguments are ''any'', ''inet'' (use IPv4 only), or ''inet6'' (use IPv6 only).

[jrmitch120]

Boy, I would have never figured this out without this post.  Installing Visual Studio 2015 upgraded msysgit causing the error.  Using this fix worked for me.

[andrewskowronsk]

Thanks klucks83!  I never would have figured that out without your post. That fix is much nicer than hacking in the hosts file.

I hit it upgrading to Git for Windows 2.7.0 on a previously working Windows 10 VM (on Fusion 7.1.3).

[32bits]

I'm seeing the same problem with vmware fusion + windows 10 for git and for python.

[win6]

I'm providing additional analysis for this bug.

The cause of this problem is that DNS proxy of VMware NAT mechanism returns inappropriate response for IPv6 address  query.

Even a hostname has no IPv6 address, VMware's DNS proxy returns IPv4 reponse(A) for IPv6(AAAA) query.

The winhost-vmis placed inside VMware NAT. For example,

  winhost-vm# nslookup -q=AAAA github.com

  Name: github.com.localdomain

  Address: 192.30.252.131

The above is not appropriate response.  The correct response should be Non-Existing Domain (NX_DOMAIN).

There is one more condition for causing name resolving failure in cygwin/msys'sgetaddrinfoAPI. It internally uses AI_ALL flagin order to ensure OS compatibility and the flag causes "Non-recoverable failure in name resolution" when receiving above inappropriate DNS response.

It is Windowscygwin/msysspecific behavior (not illegal), and does not matter on Linux/glibcplatform.

[arctelix]

I am using babun on windows 10 and have the same issue.  Modifying the ssh_config as suggested does not seem to have any effect.

However, simply specifying a DNS server manually in your IPv4 network config, rather then obtaining it automatically, works perfectly.

I set mine to Google DNS servers: 8.8.8.8 and 8.8.4.4