Recently, I have had problems getting Windows Update and Windows Activation to work. This is a network level problem, not specific to any one machine and affects both servers (WS2012r2) and desktops (Win 10 Pro), both physical & virtual machines. Sometimes, the problem resolves itself if I let the PC sit for a few days, but usually not - and never for activations. I've been through all of the "fix Windows Update/Activation" steps, multiple times with multiple machines without success, so I did a clean install on a test machine with Wireshark installed. I'm not going to post Windows error codes here because I just want to find out what Wireshark can tell me about these failures. If anyone can help me understand what I'm looking at in this capture file, I'd be grateful! asked 05 Jul '17, 11:23  LoveToFlyGuy |
2 Answers:
You are looking at countless attempts of the machine to set up a TLS-encrypted connection with the Microsoft update server. As the encryption uses Diffie-Hellman key exchange, there is no way to decipher the payload and even the result of the handshake unless you would use a MITM-attack on it. But it seems that there is actually no payload at all, as after the end of cipher suite negotiation, the client actively closes the TCP session without transferring any TLS payload at all. So if we leave aside a bug of the Microsoft upgrade client, the only idea I could have would be that some security element between the machine attempting the upgrade and the Microsoft server (reverse DNS shows that 157.56.96.58 does belong to Microsoft range) tampers with the Diffie-Hellman exchange and the client recognizes it somehow (or the server does and says the negotiation has failed). If you can isolate one of the machines from the rest of the network and let it bypass your current security elements (firewalls) when talking to the internet, and if it upgrades successfully this way, you'll know there is something wrong about your firewally. Another thing which surprises me is that your machine sends a DNS request, asking for an IP of answered 05 Jul '17, 13:55  sindy edited 05 Jul '17, 13:56 |
Thanks for the help, sindy. I finally tracked the problem to our Meraki firewall incorrectly identifying certain CDN IPs as belonging to malware domains, and silently blocking them. There were no logs showing the blocking, as Meraki apparently doesn't think admins would need that information. I only discovered the cause because I was reading release notes prior to deploying a recent Meraki firmware update. That issue was listed as being addressed in the update. answered 17 Jul '17, 10:03 LoveToFlyGuy |
Thanks sindy!
That's more-or-less what I thought was going on. Why it's happening is still a mystery, because I have the local (Windows) firewall turned off, and Defender disabled (as much as it can be) with no effect. I've also temporarily set our WAN firewall to not restrict outbound traffic and enabled WAN ping response as a test - again without effect, and there are currently no intermediary firewalls in place.
You have given me some great avenues to explore!
This is totally unrelated.
This may or may not help. Some of the security boxes behave funny and interfere with the traffic even if configured not to do so, so when I said "bypass", I really had in mind "bypass", i.e. connect the machine under test in such a way that its communication to the Internet does not go through that security box at all.
If you have a virtualization environment, just install a new Windows machine which can connect only to internet and nowhere else so that, if conquered by malware, it cannot infect anything else.
If you only have physical machines, connect one of them somewhere else where network security is provided by another type of security box, or just switch on the security software provided Windows itself and use a mobile connection (Public network setting of Windows networking).