Windows 10 Creators Edition (1703) Windows Updates und IPv6 0x8024402C

Hi!
Hab mich gerade tagelang mit einem Notebook geplagt, der keine Windows Updates mehr machen wollte sondern immer im WindowsUpdateLog folgendes von sich gab:

[sls]SLS DatastoreLookup: 0x80248007
[sls]Retrieving SLS response from server...
[sls]Making request with URL HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/10.0.15063.0/0?.......

[susenginelib]Send request failed, hr:0x80072ee7
[downloadfile]WinHttp: SendRequestToServerForFileInformation failed with 0x8024402c; retrying with default proxy.
[susenginelib]Send request failed, hr:0x80072ee7
[downloadfile]Library download error. Error 0x8024402c. Will retry. Retry Counter:0
[susenginelib]Send request failed, hr:0x80072ee7
[downloadfile]WinHttp: SendRequestToServerForFileInformation failed with 0x8024402c; retrying with default proxy.
[susenginelib]Send request failed, hr:0x80072ee7
[downloadfile]Library download error. Error 0x8024402c. Will retry. Retry Counter:1
[susenginelib]Send request failed, hr:0x80072ee7
[downloadfile]WinHttp: SendRequestToServerForFileInformation failed with 0x8024402c; retrying with default proxy.
[susenginelib]Send request failed, hr:0x80072ee7
[downloadfile]Library download error. Error 0x8024402c. Will retry. Retry Counter:2
[susenginelib]Send request failed, hr:0x80072ee7
[downloadfile]WinHttp: SendRequestToServerForFileInformation failed with 0x8024402c; retrying with default proxy.
[susenginelib]Send request failed, hr:0x80072ee7
[sls]GetDownloadedOnWeakSSLCert Failed: hr = 0x8024402C
[sls]GetResponse failed with hresult 0x8024402c...
[agent]WU operation (CDiscoveryCall::Init ID 1, operation # 3) stopped; does<NULL> use network; is not at background priority<NULL>

Also man ipconfig /displaydns:


sls.update.microsoft.com
----------------------------------------
Eintragsname . . . . . : sls.update.microsoft.com
Eintragstyp . . . . . : 5
Gültigkeitsdauer . . . : 116
Datenlänge . . . . . . : 8
Abschnitt. . . . . . . : Antwort
CNAME-Eintrag . . . . : sls.update.microsoft.com.nsatc.net


Eintragsname . . . . . : sls.update.microsoft.com.nsatc.net
Eintragstyp . . . . . : 28
Gültigkeitsdauer . . . : 116
Datenlänge . . . . . . : 16
Abschnitt. . . . . . . : Antwort
AAAA-Eintrag . . . . : 2a01:111:f335:1792::f001:7a5


Eintragsname . . . . . : sls.update.microsoft.com.nsatc.net
Eintragstyp . . . . . : 28
Gültigkeitsdauer . . . : 116
Datenlänge . . . . . . : 16
Abschnitt. . . . . . . : Antwort
AAAA-Eintrag . . . . : 2a01:111:f307:1790::f001:7a5


Eintragsname . . . . . : a.ns.nsatc.net
Eintragstyp . . . . . : 1
Gültigkeitsdauer . . . : 116
Datenlänge . . . . . . : 4
Abschnitt . . . . . . : Weiteres
(Host-)A-Eintrag . . : 8.26.215.27


Habe testweise mal IPv6 deaktiviert ... in null komma nix sind die Updates reingekommen.

IPv6 wieder aktiviert und mal mit curl zu connecten versucht

C:\INSTALL\curl-7.53.1\src>curl -v https://sls.update.microsoft.com
* Rebuilt URL to: https://sls.update.microsoft.com/
* timeout on name lookup is not supported
* Trying 2a01:111:f335:1792::f001:7a5...
* TCP_NODELAY set
* Connected to sls.update.microsoft.com (2a01:111:f335:1792::f001:7a5) port 443 (#0)
* schannel: SSL/TLS connection with sls.update.microsoft.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 193 bytes...
* schannel: sent initial handshake data: sent 193 bytes
* schannel: SSL/TLS connection with sls.update.microsoft.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data


Hier ist der Output dann hängen geblieben. - Hatte so ein ähnliches Phänomen schon einmal mit incapsula.net und habe auf meiner Firewall die ausgehende MSS mit 1360 für NEW connections an 2a01:110::/29 überschrieben. - Siehe da jetzt geht´s auch über IPv6:

C:\INSTALL\curl-7.53.1\src>curl -v https://sls.update.microsoft.com
* Rebuilt URL to: https://sls.update.microsoft.com/
* timeout on name lookup is not supported
* Trying 2a01:111:f335:1792::f001:7a5...
* TCP_NODELAY set
* Trying 13.78.230.134...
* TCP_NODELAY set
* Connected to sls.update.microsoft.com (2a01:111:f335:1792::f001:7a5) port 443 (#0)
* schannel: SSL/TLS connection with sls.update.microsoft.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 193 bytes...
* schannel: sent initial handshake data: sent 193 bytes
* schannel: SSL/TLS connection with sls.update.microsoft.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with sls.update.microsoft.com port 443 (step 2/3)
* schannel: encrypted data buffer: offset 3835 length 4096
* schannel: sending next handshake data: sending 93 bytes...
* schannel: SSL/TLS connection with sls.update.microsoft.com port 443 (step 2/3)
* schannel: encrypted data buffer: offset 51 length 4096
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with sls.update.microsoft.com port 443 (step 3/3)
* schannel: stored credential handle in session cache
> GET / HTTP/1.1
> Host: sls.update.microsoft.com
> User-Agent: curl/7.53.1
> Accept: */*
>
* schannel: client wants to read 16384 bytes
* schannel: encdata_buffer resized 17408
* schannel: encrypted data buffer: offset 0 length 17408
* schannel: encrypted data got 1423
* schannel: encrypted data buffer: offset 1423 length 17408
* schannel: decrypted data length: 1394
* schannel: decrypted data added: 1394
* schannel: decrypted data cached: offset 1394 length 16384
* schannel: encrypted data buffer: offset 0 length 17408
* schannel: decrypted data buffer: offset 1394 length 16384
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 1394
* schannel: decrypted data buffer: offset 0 length 16384
< HTTP/1.1 403 Forbidden
< Content-Type: text/html
< Server: Microsoft-IIS/10.0
< X-Powered-By: ASP.NET
< Date: Fri, 01 Dec 2017 20:08:21 GMT
< Content-Length: 1233
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>403 - Forbidden: Access is denied.</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;}
h1{font-size:2.4em;margin:0;color:#FFF;}
h2{font-size:1.7em;margin:0;color:#CC0000;}
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;}
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
background-color:#555555;}
#content{margin:0 0 0 2%;position:relative;}
.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;}
-->
</style>
</head>
<body>
<div id="header"><h1>Server Error</h1></div>
<div id="content">
<div class="content-container"><fieldset>
<h2>403 - Forbidden: Access is denied.</h2>
<h3>You do not have permission to view this directory or page using the credentials that you supplied.</h3>
</fieldset></div>
</div>
</body>
</html>
* Connection #0 to host sls.update.microsoft.com left intact


Also mal IPv6 das Binding am Netzwerkadapter wegnehmen und schauen ob dann das Windowsupdate funktioniert
und vielleicht möchte microsoft.com.nsatc.net mal dafür sorgen, dass Windows Updates in kleineren Paketen geschickt werden ...

Have Fun with TEREDO, ISATAP, 6to4 und native IPv6, wenn die MTU wegen einer PPTP o.ä. Verbindung kleiner wird und irgendwer im Netz ICMPv6 Pakete falsch od. gar nicht verarbeitet


Schöne Grüße, Kletool

Weiterlesen...