Names don’t get resolved from Windows 2012 R2 Virtual Machines which are using NVGRE to connect to the Internet on SCVMM
This was a very interesting and weird issue which I worked upon a few days back.
We had a few Hosts running 2008 R2 VMs and 2012 R2 VMs. We had a mix of Virtual Networking as well. Some of the VMs were using the VLAN enabled Networks. And some other were using NVGRE Networking, where the VMs Network will point to another VM which acts as a Gateway to the Internet to these VMs. You can get more information about NVGRE in SCVMM in the article below:
https://blogs.technet.com/b/scvmm/archive/2013/09/17/whitepaper-hybrid-clouds-with-nvgre.aspx
So the issue was that all the Routing was working fine from all the VMs. But only part which was not working was the Name resolution and too only from 2012 R2 VMs. The name resolution was working fine from 2008 R2 VMs. Which was very odd, as if it would have been an issue with NVGRE configuration in VMM, then even normal Routing would not have worked. But we still went ahead and checked the complete configuration for NVGRE and everything looked to be properly setup.
Then we collected some Network Captures on the Gateway VM while trying name resolution from one of the 2012 R2 VM, and we could see the DNS Queries coming there and in fact we could see those DNS Queries even going out to the Public DNS servers, as shown below:
As we can see above the DNS Queries were going out but there was no response which was coming back or atleast we can not see any response in the Network captures.
So we did some research on this weird behavior and we found the below Article from one of our MVPs Thomas Maurer:
And we followed the action plan suggested by Thomas in the above Article to Disable the “Encapsulated Task Offload” on the Broadcom NICs on these Hosts where the 2012 R2 VMs were running.
After that the name resolution started working fine on those 2012 R2 VMs as well.
So, as you saw, it was one of those cases where NIC drivers can cause a lot of weirdness.
Again thanks to Thomas Maurer for his Excellent Article which helped us in resolving this issue .
Author:
Nitin Singh
Support Escalation Engineer
Microsoft Security and Manageability Division