Firefox: "The connection to the server was reset while the page was loading."
Chrome: "No data received - Error code: ERR_EMPTY_RESPONSE"
IE 10: can't load page (don't have the exact error message)
Loading the http version of that page works just fine.
Loading HTTPS version from PowerShell using Invoke-WebRequest works fine too. I can only reproduce it consistently when loading the page in a web browser. I'm guessing that PowerShell must send request headers that cause the Microsoft's servers to serve a different page than what is served to browers.
Accessing the meetup.com API over HTTPS from a .NET 4.5 application results in the following exception for two specific endpoints of the API (but all the other endpoints work fine):
"System.IO.IOException : Received an unexpected EOF or 0 bytes from the transport stream"
- Networking in general works fine on the guest.
- All HTTP connections works 100% fine.
- The immense majority of HTTPS requests also work fine.
- The problem only occurs for a few very specific HTTPS requests and it's reproducible at least 99% of the time for those particular requests (occasionally, one of those requests will go through before failing again the next time).
This problem has been driving me nuts for a good two days now. I tried everything I could think of to fix this to no avail. Eventually, last night, I remembered about the GPLPV drivers and wondered if they could be the culprit. So I uninstalled them and, lo and behold, everything works perfectly now.
For those who want to uninstall the drivers, uninstalling the package via Add / Remove programs will most likely nuke your VM. If this happens, Windows should let you still boot using the last know good configuration, which will bring it back up again but it will still be using the GPLPV drivers. The .bat script for the 0.10 version at the bottom of <http://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers> will take care of uninstalling them properly. A reboot and you should be good to go.
I can't reproduce this on 2008R2. Are you able to confirm if this problem only exists under 2012R2?
I have 2012R2 downloaded and ready to install but haven't had time yet. If you have found that this is a problem that is new to 2012R2 I'll try and hurry up and install it.
That 2012 R2 VM is the only one I've setup with Xen. But setting up a 2008 R2 machine should just be a matter of a few minutes so I'll do that and let you know if it's 2012-specific or not.
So I've setup a new VM on that same machine with a 64-bit install of Windows Server 2008 R2 Standard Edition with SP1. And I'm getting the exact same problem.
Before installing the GPLPV drivers, I could load https://login.live.com just fine in Firefox (haven't tried other browsers but I'm assuming that, just like with 2012 R2, it's not browser-specific). After installing the drivers, the page fails to load with a "The connection was reset" error message from Firefox.
This is weird. I could give you access to the VM if you wanted although I'm not sure if you'd like to spend time troublshooting an issue that appears to be isolated to a single machine. I haven't come accross any other mentions of the issue anywhere.
Re: GPLPV signed network drivers cause TCP connection resets on some HTTPS endpoints on Windows Server 2012 R2 guest
> Before installing the GPLPV drivers, I could load https://login.live.com just
> fine in Firefox (haven't tried other browsers but I'm assuming that, just like
> with 2012 R2, it's not browser-specific). After installing the drivers, the page
> fails to load with a "The connection was reset" error message from Firefox.
> This is weird. I could give you access to the VM if you wanted although I'm
> not sure if you'd like to spend time troublshooting an issue that appears to
> be isolated to a single machine. I haven't come accross any other mentions of
> the issue anywhere.
Can you get a tcpdump of what is going on? You'd need to do it in dom0 I think, and using the '-s0' option to capture full packets.
Also can you confirm that there is only the one Ethernet interface active in the DomU?
After you've done the tcpdump, can you mess around with turning off some of the offload options (adapter settings in windows) and see if that makes a difference.
There should be nothing strange about https though as compared to any other protocol.