[English]Ich stelle mal ein Problem hier im Blog vor, auf das ich beim Stöbern in Microsofts Answers-Foren gestoßen bin. Auf manchen Systemen kommt es vor, dass Clients nach dem Upgrade auf Windows 11 24H2 kein Netzwerk, weder per LAN noch per WLAN erhalten. Ursache ist ein fehlender Gateway-Eintrag, der auf Grund eines Bugs vom DHCP-Server nicht angefragt werden kann. Es hilft auch nicht, das Gateway manuell einzutragen, da es nach dem Neustart wieder verloren geht. Abhilfe scheint ein Update vom November 2024 zu bringen.
DHCP bei Windows
Das Dynamic Host Configuration Protocol (DHCP) ist ein Kommunikationsprotokoll, welches auch in Windows zum Einsatz kommt. Über das Protokoll kann ein Windows-Client die IP-Adresse und die Netzwerkkonfiguration von einem DHCP-Server beziehen.
Windows 11 24H2: Kein Netzwerk
Mitte Oktober 2024 hat sich ein Administrator im Microsoft Answers Forum für Windows 11 für IT Pros gemeldet und berichtete im Thread Win11 24H2 – DHCP issue – no Gateway über Probleme in seiner Umgebung. Er versuchte in Testgruppen einige Clients auf Windows 11 Version 24H2 zu aktualisieren.
Dabei ist er in einen merkwürdiges Problem gelaufen: Manche dieser Windows 11 24H2-Clients bekamen im Anschluss kein Netzwerk – weder per LAN noch per WLAN. Die Installation von Windows 11 24H2 wurde sowohl per WSUS als auch direkt mit einem USB-Stick getestet.
Das merkwürdige: Es betrifft nicht alle umgestellten Clients, aber der Administrator rauschte mit fünf Maschinen seiner Testgruppe in dieses Problem. Die gleichen Maschinen mit Windows 11 23H2 zeigten dagegen keine Probleme. Es deutete sich an, dass dieses Problem mit Windows 11 24H2 zusammen hängt, welches ja am 1. Oktober 2024 erst freigegeben wurde.
Fehlerursache: Kein DHCP-Gateway-Eintrag
Eine Analyse der betroffenen Clients ergab sehr schnell, dass das Gateway in der Netzwerkkonfiguration der betreffenden Windows 11-Maschinen fehlte. Man kann das Gateway zwar manuell eintragen, dann funktioniert alles. Aber nach einem Neustart war der Eintrag für das Gateway wieder weg.
Der Administrator schrieb, dass man DHCP-Server verwende und alle Einstellungen geprüft und für in Ordnung befunden habe. Die Konfiguration war vollständig, d.h. IP, Maske, DNS-Server sind korrekt eingetragen – nur das Gateway fehlte in der Netzwerkkonfiguration. Der Versuch, den Netzwerkstack mittels der Konsolenbefehle ipconfig /release oder /renew zurück zu setzen, halfen nicht. Wireshark zeigt nichts Auffälliges.
Ein weiterer Administrator bestätigte dieses Problem, und schrieb, dass sie es in ihrer Umgebung beobachteten. Das Einzige, was funktionierte, bestand darin, statische IP-Adressen an den Clients zuzuweisen. Dann funktionierte das Netzwerk einwandfrei, aber wenn er die Clients entfernte, kann dieser Rechner keine Domänen-IP-Adresse mehr empfangen.
Der Betroffene vermutete ein Problem bei der Authentifizierung in einem Domänennetzwerk, was auch für der Domänen-WiFi-Verbindung zutraf. Denn er konnte eine Verbindung zum Gast-WiFi-Netzwerk herstellen und erhielt Internetzugang. Auch sein Mobiltelefon als Hotspot verwendet, ermöglichte einen Internetzugang.
Ein weiterer Betroffener hat das Ganze dann analysiert und Wireshark verwendet, um den DHCP-Verkehr zwischen einem 23H2-Computer und einem 24H2-Computer zu untersuchen. In seiner Umgebung werden Benutzerklassen-IDs verwendet, damit die Rechner ein Gateway erhalten, um Benutzer davon abzuhalten, persönliche Geräte anzuschließen. Das Upgrade auf Windows 11 24H2 bewirkte, dass diese Client die DHCP-Erkennungsanforderung ohne die Benutzerklasseninformationen sendete, was zu den Problemen mit der DHCP-Verarbeitung führte.
Eine Lösung wurde gefunden
Die Diskussion mäanderte im MS Answers-Forum seit Mitte Oktober 2024, ohne weitere Rückmeldung Microsofts. Zum 5. Dezember 2024 hat sich ein Nutzer gemeldet und schrieb, dass er eine Lösung gefunden habe. Das Update KB5046617 für Windows 11 24H2, welches zum 12. November 2024 freigegeben wurde, habe in seiner Umgebung dieses Problem behoben. In der Tat heißt es im Support-Beitrag:
- [Internet connection] Fixed: A small number of devices cannot connect to the internet. This occurs when a DHCP server response has duplicate DHCP options. This stops IPv4 connections on certain networks.
Vielleicht hilft es weiter, falls jemand aus der Leserschaft in einer Unternehmensumgebung von diesem Problem betroffen ist.
MVP: 2013 – 2016
Was für ein Gateway? Wenn man DHCP mit einem DHCP-Server macht, der in einem anderen Subnetz steht, muss man für das Client-Netz im Routing ein entsprechenden DHCP-(IP-)Helper- bzw. DHCP-Relay-Eintrag (der eine Hersteller bezeichnet es so, der andere so, gemeint ist aber das selbe) anlegen, damit DHCP-Anfragen zum DHCP-Server weitergeleitet werden. Das macht man normalerweise auf dem Switch oder Router, welcher im Client-Netz als Gateway fungiert.
Ich glaube du denkst gerade in die falsche Richtung. Wenn ich das richtig verstanden habe ist das Problem, dass der Client per DHCP eine IP bekommt, aber die Option für das Gateway nicht übernommen wird bzw. seine Benutzerklassen-ID nicht sauber sendet und somit der DHCP kein Gateway liefert, da dort wohl nur bekannte Geräte eine Gateway bekommen sollen.
Das hat nichts mit DHCP-Helper zu tun, das ist eine andere Baustelle.
Habe ich auch erst nicht ganz verstanden. Gemeint ist aber sicherlich, dass die Clients kein Standard-Gateway bekommen. Daher "kein Netzwerk"…
So ist es imho.
Das wäre aber die Trivial-Situation, die jeder in seinem Heimnetz hat. Kann mir irgendwie nicht vorstellen, dass Microsoft so einen Trivial-Fehler übersehen könnte? Sind ja sicher schon ein paar Millionen 24H2 Installationen "da draußen"… Also entweder passiert es unter nur ganz speziellen/nicht so häufig anzutreffenden Umständen (bestimmte Netzwerkkarte, Treiberversion oder mit einem bestimmten DHCP-Server) oder es ist was anderes.
steht doch im Artikel
[Internet connection] Fixed: A small number of devices cannot connect to the internet. This occurs when a DHCP server response has duplicate DHCP options. This stops IPv4 connections on certain networks.
Auch ohne Gateway ist selbstverständlich "Netzwerk" möglich. Allerdings nur im eigenen Netz.
"Ursache ist ein fehlender Gateway-Eintrag, so dass der DHCP-Server zur Zuteilung der IP-Adressen und Netzwerkparameter nicht angefragt werden kann. "
Wenn ein DHCP-Discover abgesetzt wird, kennt der Client noch kein Gateway und braucht es dafür auch gar nicht. Das bekommt er erst genannt, wenn die Abfrage erfolgreich war.
Alles sehr verworren…
ein NetzWerk funktioniert ganz prima auch ohne Gateway.
man kommt halt nicht aus seinem Segment raus. Die billigste Firewall.
Um den DHCP Server zu erreichen braucht man natürlich kein Default Gateway, denn dieses kommt ja erst in der DHCP Antwort..
gell?
eigentlich müsste das ja schon beim Schreiben der Überschrift aufgefallen sein, wenn man die geringsten Grundlagen der Netzwerk Technik kennt, wo von ich eigentlich beim Autor ausgegangen war.
es wird doch kein Klick bait sein ala "Mann beißt Hund" weil "Hund beißt Mann" niemanden interessiert?
oder wird sich hier auf llm verlassen, das gerne mal Ursache und Wirkung verwechselt?
die Überschrift ist irreführend
[Internet connection] Fixed: A small number of devices cannot connect to the internet. This occurs when a DHCP server response has duplicate DHCP options. This stops IPv4 connections on certain networks.
Ok wieso schickt ein DHCP Server überhaupt Duplikate? Und vor allem, warum hat Windows in der Vergangenheit Duplikate zugelassen und jetzt wieder?
Wäre es nicht sinnvoller den DHCP Server soweit zu bringen, dass er keine Duplikate schickt?
Der Windows DHCP Client scheint sich an doppelten DHCP Optionen zu verschlucken.
möglicherweise widersprechen die sich. Aber eigentlich sollte der Client damit zurecht kommen…
im Eventlog scheinen keine Probleme hemeldet zu werden?
Es ist aber ziemliches stochern im Nebel.
Die DHCP Antworten scheinen OK
zu sein wie eine Analyse mittels wireshark ergeben haben soll.
das Problem tritt auch bei frisch installierten Clients auf.
Bisher hat das DHCP funktioniert.
Erst mit dem Update wird der Effekt sichtbar.
das liegt dann wohl am Update…
es ist eigentlich der Job von MS das Problem zu lösen, oder ist das ne Beta Version?
wozu braucht MS denn die Telemetrie Daten?
Kann es vielleicht sein, dass in dem Netz zwei DHCP-Servers sind? So, dass sie die gleiche Konfiguration verwenden? Aber auch das müsste gehen, wenn man es richtig macht, habe ich zuhause so am Laufen, damit im Fall dass der Router mal ausfällt, dass ich aus einem anderen (kleineren) Bereich des gleichen Subnetzes wenigstens eine IP bekomme (DNS- und Gateway-Angaben sind gleich), um eine Chance zu haben, mal zu gucken, was der Router so treibt. Die beiden DHCP-Dienste beschweren sich natürlich in ihrem Log, dass jeweils der andere die DHCP-Anfrage schon beantwortet hat. Meistens gewinnt bei mir aber der Hauptrouter, weil er am kürzeren Ende des Netzes ist.
Server und Bereichsoptionen?
an sowas dachte ich auch, das bereichsoptionen server optionen overrulen sollten, was ja legitim wäre. nur Windows verhaut es dann
Üblicherweise probed ein DHCP mit ICMP Ping, ob auf einem DHCPDISCOVER eine per DHCPOFFER angebotene IP bereits vergeben ist. Ein Client sammelt daher erstmal alle Antworten auch doppelte, bis zum finalen DHCPREQUEST der dann am Server mit DHCP ACK oder NAK beantwortet wird.
Im RFC steht ferner, dass ein Client ein Check ausführen sollte (SHOULD) z.B. mit Abgleich der ARP Tabelle. Scheint hier nicht erfolgt zu sein, sonst dürfte das Interface diese Config ohne Gateway gar nicht erst übernehmen dürfen.
Der Fehler dürfte symptomatisch für das Spielzeug-Produkt Windows und die Bude Microsoft sein, wenn im Jahre 2024 solche jahrzehntelangen Internet-Grundlagen nicht sauber implementiert werden und es auch noch in ein finales Produkt schaffen.
Seit wann ist dem DHCP-Client angeraten, den Gateway zu prüfen? Dieser Teil der RFC wäre mir jedenfalls neu.
Ausserdem denke ich, dass die doppelten Einträge in der einzelnen DHCPOFFER waren, denn der Client merged die verschiedenen Antworten nicht – er entscheidet sich für Eine (mEn die Früheste).
Letztens: Eine DHCP-Config ohne Gateway ist zwar eher unüblich, aber zulässig und in der Praxis auch funktional.
Schau doch bitte ins RFC:
"The client receives the DHCPACK message with configuration parameters. The client SHOULD perform a final check on the parameters"
> Letztens: Eine DHCP-Config ohne Gateway ist zwar eher unüblich, aber zulässig und in der Praxis auch funktional.
Hat aber offensichtlich kaum was mit diesem Problem zu tun, denn ich denke eher nicht, dass eine Fritzbox plätzlich Ihr Gateway nicht propagiert. Dann schon eher, dass Windows 11 einfach nur scheiße baut.
Der DHCP Client von Windows befolgt also genau die RFC, er checked die Optionen, die passen nicht, er wendet sie nicht an.
Das wissen wir nicht ohne die Datenpakete gesehen zu haben. Eine DHCPOFFER darf durchaus mehrere Gateways beinhalten.
Das betrifft Validität der einzelnen Parameter und bezüglich Gateway sagt die RFC nichts (wäre für Sie also ein aktuell nicht erreichbarer Gateway nicht zu übernehmen (und wenn nein: Warum?!)?).
Man kann die F!B und andere DAU-Router nicht so konfigurieren (einfach weil es die GUI nicht hergibt und kein CL-Zugang besteht), bessere DHCP-Server (inkl. OpenWRT) hingegen schon.
Von der F!B war im Artikel übrigens keine Rede.
Das wirkt mir alles irgendwie komisch…
Zum einen – was hat das Gateway mit DHCP bzw. das beziehen der IP mit dem Gateway zu tun? -> nix. Auch die Beschreibungen im MS Forum sind technisch quatsch.
Ja, man kann sicher Policys nutzen um via User Class bestimmten Geräten mit diesem Eintrag eben andere Optionen zu geben, aber welchen Sinn hat es, die Verteilung des Gateways da dran zu knüpfen? DHCP ist nix was wirklich manipulationssicher ist. Also die Pakete zumindest. Heißt also, wenn man aus Sicherheitsgründen?? Clients nur ein Gateway gibt, wenn dieser String gesetzt ist, bringt das genau was, wenn ein unbekanntes Gerät einfach statisch IPs vergeben kann? Nix… Sicherheit gibts nur mit Authentifizierung. Und das hat nix mit dem Gateway zu tun.
Was mich auch wundert – es wird von Update auf 24H2 geschrieben. Möglicherweise ist einfach der Grund gar nicht DHCP oder das Gateway, sondern die Art und Weise, wie diese User Class auf den Client kommt. Sprich ist die User Class nach dem Update überhaupt noch gesetzt?
Meiner Ansicht nach ist das alles ultra wischi waschi beschrieben und es fehlen so ziemlich alle troubleshooting Steps um das Problem in der Quelle einzugrenzen. Ja, es mag der Gateway Eintrag schuld sein, dass keine geroutete Verbindung zustande kommt – aber der fehlende Gateway Eintrag ist nicht die Ursache des Problems. -> leider kommt das irgendwie stark zu kurz.
Um es nochmal in Klartext zu sagen. Vor allem weil Leute auch hier schon wieder Verschwörungen zu der Unfähigkeit von Microsoft spinnen… Es gibt aktuell kein globales Problem. Der Fehler trifft bestenfalls in Sonderkonstellationen zu und auch in der beschriebenen Form – User Class ist leer beim DHCP discover ist mMn klar fraglich, warum man im DHCP Server kein Gateway senden soll(te), wenn der Eintrag fehlt. Es kann natürlich sein, dass der Client aufgrund eines Fehlers in der Implementierung für DHCP Responses generell ein Problem hat, wenn da irgendwas mit User Classes passiert, kein Gateway setzen zu wollen/können -> aber das ist schon wieder eine Interpretation, denn das steht in der Quelle im MS Forum so nirgendwo. Das steht, die User Class wird nicht gesendet. Nichts davon, dass im DHCP Response das Gateway gesetzt ist, aber der Client es nicht verarbeitet. Wahrscheinlich viel Wind um nix…
Viel Text! Ich kann es als nicht Betroffener nicht genauer präzisieren, sondern arbeite mit dem, was an Infos da ist.
Was ist denn Fakt? Es gibt Leute, die Probleme wegen fehlender Gateway Einträge in AD-Umgebungen feststellen. Im November 2024 Update ist laut MS was in diesem Bereich korrigiert worden. Ein Betroffener schreibt, das November Update habe geholfen.
Was folgt? Nicht betroffen? Gehen Sie weiter, es gibt nix zu sehen…
Betroffen – das Update installieren und testen. Fehler weg, dann freuen und habe fertig.
Fehler noch da? Zurück auf los.
Lebbe kann so einfach sein … oder was verstehe ich nicht
Wäre toll, wenn ein Betroffener die Datenpakete so einer fehlerbehafteten DHCP-Aushandlung aufzeichnen und uns verfügbar machen würde.
Ich habe den MS Answers-Forenbeitrag ja verlinkt – magst Du da mal nachfragen – vielleicht hat der eine Betroffene, der mit Wireshark unterwegs war, die Aufzeichnungen noch. Meine Sichtweise hatte ich ja in einem anderen Kommentar auf den Punkt gebracht: Es gibt einen Patch von November 2024, der laut Microsoft und Betroffenen das Problem löst. Aus diesem Blickwinkel ist die Diskussion was genau Phase ist, lediglich Nabelschau – auch wenn ich euch verstehe. Aber ich persönlich mag mich da nicht rein hängen – ich habe hier genug offene Baustellen, wo ich mich kümmern, nachfassen und für den Blog dann aufbereiten muss/will/darf.
Was ich damit meine ist eher, dass nicht überall, wo ein Problem gerochen wird, auch wirklich ein Problem drin ist. Natürlich hat Microsoft da irgendwas mit DHCP im Namen gefixt, nicht näher beschrieben ist das leider auch bei denen nicht ganz nachvollziehbar was nun genau. Die Frage ist ob das überhaupt einen Zusammenhang hat…
Die Thematik, dass die Erklärungen der betroffenen irgendwie allesamt technisch Quatsch sind und sonstwas für Gründe zu dem Verhalten geführt haben können, gepaart mit dem Umstand das einige? der Leute dort dann meinen, ein/das Update fixt ihr Problem, was letztlich aber ebenso nix mit dem ursprünglich beschriebenen Thema zu tun haben muss, macht das ganze doch stark undurchsichtig.
Wie gesagt, was mich wundert, dass eben bei mindestens einer der Aussagen User Class Einträge nicht richtig oder gar nicht gesetzt sind und auch nicht übermittelt wurden -> was erstmal natürlich ein Thema sein kann – aber warum zur Hölle wird dem nicht nachgegangen? Also nachgegangen im Sinne von, ja die Einträge sind gesetzt, die Einträge sind auch angekommen, wenn man es neu setzt, kommt es an usw.
Was ich hier einfach herauslese ist, dass der Betreiber des DHCP Systems eine warum auch immer existierende Policy geschrieben hat, die bei keinem oder falschem User Class Attribute eben kein Gateway zurück liefert. Das ist das, was da steht. Das heißt aber eben dann auch, das Verhalten ist offenbar so gewollt? Ergo also kein Problem?
Fragezeichen habe ich auch bei der Art und Weise des Updates.
– Fresh 24H2 von der grünen Wiese?
– Update einer 23H2 oder älteren 11er Version?
– Update einer 10er Version?
-> wie wurde geprüft ob die User Class Einträge gesetzt sind bzw. wurde das überhaupt geprüft?
-> natürlich, wenn nach einem Update das 24H2 via Rollback runter geputzt wird zum alten Zustand, geht es ziemlich sicher auch, wenn damit irgendwie ein Problem existiert.
Wenn ich die Tage mal bisschen Luft und lange Weile habe, teste ich das mal im Lab bei mir… Vielleicht lässt sich dem ja irgendwie auf die Schliche kommen.
danke für den Beitrag. Hat uns die Woche gerettet. Seit letzter Woche hatten plötzlich immer mehr Windows 11 24H2 Clients Probleme, insbesondere Notebooks von HP mit v.g. installierter Version.
Ist schon einfach nur noch krass mit welchen Problemen Windows 11 24H2 zu kämpfen hat.
Ich hatte das Problem der fehlenden Gateway auf einem PC nach dem Update von Windows 10 auf Windows 11. Eintragen der Gateway hat geholfen, seither ist dieser PC wieder am Netz.
ich würde mal auf den betroffenen Systemen den Treiber nebst Registry Einträgen komplett löschen.
Windows speichert da oft uraltes Zeug.
Allerdings soll es ja auch mit ganz frisch installierten Clients auftreten…
und natürlich sind doppelte DHCP Antworten kein Problem, sondern sogar ein notwendiges Feature.
Außer bei Windows…
mir kommen echt die Tränen, wenn ich sehe was aus Microsoft geworden ist. das grenzt an Sabotage.
ändere doch bitte
"DHCP-Problem wegen fehlendem Gateway-Eintrag"
in
"DHCP-Problem? Fehlender Gateway-Eintrag"
jetzt ist es irre führend formuliert, weshalb Du zwar Klicks hast, aber von den falschen Leuten.
Danke für den Beitrag @Günter
Hatte letzte Woche das Problem mit einem Windows 11 Pro 24H2 als HyperV Plattform zum Testen.
Weitere Maschinen mit 2019/2022/2025 HyperVs stehen auch parat
Der" HyperV "von Windows 11 Pro 24H2, ließ keine DHCP Pakete mehr durch, also weder der Host noch die Clients, bekamen DHCP Pakete ab**.
Netzwerkkarten Tausch, Treiber oder Virtueller Switch wechsel halfen nicht.
Hatte zum Testen den Server 2025 mit DHCP/DNS usw. laufen *sauber ohne Fehler*,
als 2 Testkandidat einen Server 2022 und auch der machte die gleichen Probleme auf dem Win11 HyperV 24H2
Andere Testmaschinen für meine VMs, mit einem Unterbau: Windows 11 Pro 23H2, Server 2019 V1809, 2022 und 2025 hatten da keine Probleme bei diesen VMS
Erst das zurücksetzten der betroffenen Maschine auf W11 23H2 brachten Erfolg!
**
Das Seltsame daran ist, dieser Test Client mit HyperV 24H2 lief schon paar Wochen und mitten aus dem Nichts, ging nichts mehr in Sache DHCP, also auch keine Gatewayinfo. Und keine Fehler im LOG, einfach keine DHCP Pakete o.O
Und an der Netzwerkstruktur lag es nicht, sobald im Testnetzwerk ein Fremder DHCP aktiviert wurde z. B. ein Router, NAS oder Linux mit einem DHCP Server, haben alle eingebunden Geräte sofort eine DHCP gesehen. Nur der Microsoft DHCP Server war nicht sichtbar für die Clients.
Einfach verrückt und traurig, was da bei Microsoft abläuft, echt, keine Woche mehr ohne Mist.
Bei sowas drehst du doch ab, als normaler User.
Vielleicht sollte Microsoft, neben dem Ausschaltenbutton, eine Windows Recoverybutton platzieren :o)
Da fällt mir noch ein "altes" Vista Problem ein:
Ohne Gateway Eintrag kann die Network Location Awareness das Netzwerk nicht identifizieren und auch nicht speichern. Die NLA merkt sich das Firewall Profil anhand der MAC Adresse des Gateways. Vista Clients ohne Gateway konnten auch keinen AD Join durchführen, da das Netzwerk nicht vollständig ist.
Es fühlt sich gerade danach an. Die DHCP Optionen werden nicht ordentlich implementiert, der Gateway fehlt, die NLA flippt aus und findet kein Netzwerk mehr.
Haben das Problem trotz Installation des erwähnten Updates immer noch.
Man kann es zwar durch Eintragen einer festen IP, Gateway etc. umgehen, das ist aber keine Dauerlösung.
Hat jemand dasselbe Problem auch weiterhin, trotz neuem Update?
Hi, wir haben das Problem auf einem Testclient (Terra) auch noch nach dem Update. Leider keine bisher Lösung gefunden… Bin wieder zurück auf 23H2!
Da muss MS wohl langsam nachziehen mit einem Fix, was. Ist ja schlimm, 24H2 ausrollen und die QS von denen hat scheinbar gepennt.
Am besten 24H2 erst einmal aussetzen und abwarten.
Und bitte keine langen Texte als Antwort jetzt, da MS hier alleinverantwortlich ist (tldr).
Wir müssen uns nur mit der Unfähigkeit herumschlagen :-)
Folgendes aus eigener Recherche hilft leider erst einmal auch nicht:
(1) Es gibt Hinweise darauf, dass ein Update der VC-Runtime die Verbindungsprobleme lösen könnte.
Versuchen Sie bitte die aktuelle Version davon auf Ihr System aufzuspielen:
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170
(2) Weiter wurde vor einigen Tagen von Microsoft die KB5046740 ausgeliefert.
Diese beinhaltet u. a. die folgenden Änderungen:
Korrekturen und Verbesserungen durch die KB5046740
Task-Manager Korrektur: Die Anzahl der Gruppen auf der Registerkarte „Prozesse" ist falsch oder immer null (0). Dies tritt auf, wenn Sie „Nach Typ gruppieren" einschalten.
Windows Subsystem für Linux (WSL) Korrektur: Sie konnten nicht auf Ihr Dev Drive zugreifen.
Internetverbindung korrigiert: Eine kleine Anzahl von Geräten kann keine Verbindung zum Internet herstellen. Dies tritt auf, wenn eine DHCP-Serverantwort doppelte DHCP-Optionen enthält. Dies stoppt IPv4-Verbindungen in bestimmten Netzwerken.
Hallo an alle,
stehe gerade genau vor diesem Problem. Win 10 Clienten im Netz zugriff auf Server 2019 Essential tadellos. Im Zuge Supportende Win 10 sollte Upgrade der Clienten auf Win 11 erfolgen. 24h2 Iso genommen und Upgrade gemacht. Danach kein Zugriff auf Server mehr möglich (Meldung auf Server kann nicht zugegriffen werden Netzwerkpfad wurde nicht gefunden) Aufruf über IPV4 Adresse funktioniert. Alles zurück auf Win 10 funktioniert sofort wieder komplett.
Upgrade über Stick mit 22H2 und es funktioniert weiterhin alles wie gehabt.
Nachtrag:
Nach vielen Versuchen, ist das einzige was bei mir funktioniert hat, ein Tipp der eigentlich für NAS Laufwerke gedacht ist:
Win + R gpedit.msc eingeben und starten, oder nach Gruppenrichtlinien suchen.
Computerkonfiguration -> Administrative Vorlagen -> Netzwerk -> LanMan Arbeitsstation
Unsichere Gastanmeldungen aktivieren auf „Aktiviert" setzen.
Danke an Deskmodder.de
Windows 11 Upgrade: Meldung bei Speedport Smart 4/FritzBox im LAN oder WLAN-Modus: "gesichert kein Internet". Diagnose: "Es ist kein DNS zugewiesen".
Hallo zusammen,
hier ein Anliegen zu einem verwandten Sachverhalt: Seit einigen Tagen bin ich mit dessen Klärung beschäftigt. Alle bisher erhaltenen Tipps aus dem Netz habe ich ausprobiert – Hardware prüfen, statische DNS eingeben und wieder ´rausnehmen, Nezwerkadapter/Router/PC neu starten, Treiber aktualisieren, ipconfig-/netsh-Befehle eingeben – ohne Erfolg.
Im Einzelnen:
Ich habe mit einem Windows 11 24H2-PC (ISO-Upgrade auf einem zwölf Jahre alten DELL Optiplex 790 unter Umgehung der von Microsoft errichteten Barrieren aber Nutzung des Microsoft-Downloads; läuft gut) wahlweise über Ethernet oder Wifi Verbindung zu einem Speedport Smart 4 bzw. einer FRITZ!Box 7430. IP-Adresse, Gateway und DNS werden (automatisch oder statisch) korrekt konfiguriert. Bytes werden gesendet und empfangen. Indes, die Verbindungs-Meldung lautet: "gesichert, kein Internet". Diagnose: "Es ist kein DNS-Server zugewiesen" bzw. "Nicht identifiziertes Netzwerk". Wenn ich den PC wahlweise mit dem als Alternative vorhandenen "Windows 7" starte, verbindet er sich über Ethernet (Smart 4) oder Wifi (FRITZ!Box) prompt mit dem Internet.
Netzwerk-Adapter, Router und PC wurden mehrfach neugestartet, letztere auch stromlos gemacht. Ich habe die Problemermittlung von Windows laufen lassen – kein Problem erkannt. Ich habe zwischendurch IPv6 deaktiviert und über IPv4 feste DNS-Serveradressen im Range des Routers wie auch über öffentliche DNS-Server (etwa Quod9: 9.9.9.9) vergeben – wieder ohne Erfolg. Anpingen funktioniert.
Mit anderen Geräten (z.B. einem zweiten Optiplex 790 mit Windows 10) bin ich mit dem Smart 4 (LAN)/der FRITZ!Box (WLAN) verbunden und habe Internet-Zugang.
Wenn ich über das "Netzwerk- und Freigabecenter" der Systemsteuerung von Windows 11 auf "erweiterte Freigabeeinstellungen" gehe, die Netzwerkerkennung für alle Netzwerktypen einschalte und neustarte, steht beim Check wieder "Aus". Die Einstellung wird auch nach Verlassen der Systemsteuerung ohne Neustart wieder getilgt.
Inzwischen habe ich den Eindruck, es liegt am Upgrade auf Windows 11.
Gibt es klärende Kenntnisse und Erfahrungen in der Runde? Lässt sich das Problem eventuell über "regedit" lösen?
Vielen Dank und viele Grüße
Konsult
Ist das Update KB5046617 (oder neuer) für Windows 11 24H2, welches zum 12. November 2024 freigegeben wurde, auf dem Rechner installiert? Bis zu diesem Zeitpunkt gab es Probleme mit dem fehlenden, bzw. nicht funktionierenden Gateway-Eintrag. Ohne funktionierender Gateway-Eintrag kein Internet. Wenn nein, auf einem anderen Rechner aus dem Update-Catalog herunterladen, auf den Rechner kopieren und manuell installieren. Am besten gleich das 07/2025-Update.
Funktioniert die Namensauflösung mit nslookup? Werden hier die IP-Adresse(n) der DNS-Server angezeigt.
Kann der Router gepingt werden. Gibt ping 8.8.8.8 eine Antwort?
Frage, um besser verstehen zu können ob das Problem generell bei der Namesauflösung liegt oder eher beim Prüfen der Internet-Konnektivität bzw. der Verbindung selber.
Noch ein Tipp, das vergisst man gerne, macht aber manchmal ganze fiese Probleme. Nach dem Upgrade ist möglicherweise etwas nicht mehr kompatibel:
"If you have a third-party VPN or Antivirus installed, please try to temporarily uninstall it then check if the issue persists."
Vielen Dank, ChristophH.
Hier nun die Ergebnisse nach Berücksichtigung Deiner Tipps:
Modus: WLAN über Fritzbox 7430, die hinter einen Smart 4 geschaltet wurde. Das Windows 11-Update vom 12. August 2025 (KB5043080-x64 sowie KB5063878-x64) wurde erfolgreich manuell installiert. In der Fritzbox habe ich als DNS-Server 192.168.2.1, also den Smart 4 eingegeben. Auch die Windows-Firewalls wurden deaktiviert (andere habe ich nicht).
Ergebnis:
nslookup: Standardserver: Speedport.ip, 192.168.2.1
ping 8.8.8.8: timeout nach zwei Sekunden (hat aber auch schon funktioniert)
ipconfig /all: IPv4: 192.168.178.30, Standardgateway/DHCP: 192.168.178.1, DNS: 192.168.2.1 (hat aber auch in dieser Konfiguration schon mal nicht funktioniert)
ipconfig /release: kein Standard-Gateway
ipconfig /flushdns: konnte nicht geleert werden
Ich erhalte nach diversen Neustarts des PCs, des Netzwerk-Adapters wie auch des nach der Löschung neu konfigurierten "TP-Link Wireless USB Adapters" noch immer die Diagnose: "Es ist kein DNS zugewiesen".
Unter services.msc sind die Einstellungen des DHCP Client "automatisch" und des DNS Client "deaktiviert" (sie lassen sich nicht aktivieren).
Zur Info: In meinem Android Phone funktioniert die Fritzbox mit IP-Adresse: 192.168.178.31; Gateway: 192.168.178.1 sowie DNS: 192.168.2.1
Wie gesagt, Bytes werden empfangen und gesendet. Im sich verbindenden Fritzbox-Konfigurations-Programm wird der Optiplex 790 mit Windows 11 als verbunden angezeigt.
Für weitere Hinweise bin ich dankbar.
Viele Grüße
Konsult
Korrektur DNS:
ipconfig /all: IPv4: 192.168.178.30, Standardgateway/DHCP: 192.168.178.1, DNS: 192.168.2.1 (hat aber auch in dieser Konfiguration schon mal nicht funktioniert)
PS: In den "Netzwerk-Verbindungen" (nach Eingabe von ncpa.cpl) werden Standardgateway/DHCP: 192.168.178.1 aber kein DNS-Server angezeigt.
Das Fehlerbild ist sehr speziell, vermutlich Hardware-Abhängig. Irgendwie scheinen da die Netzwerkarten-Treiber die DNS-Information nicht richtig mitzubekommen, obwohl diese per DHCP geholt und im System gespeichert werden können.
Lief der Rechner vorher mit Windows 10 einwandfrei? Scheint so, als da in den Netzwerkbindungen etwas nicht (mehr) zusammen passt. Ev. ist die Netzwerkkarten-Hardware bzw. die Treiber dazu nicht Windows-11 kompatibel. Das könnte auch der Grund sein, warum am Ende der DNS-Client Dienst (dnscache) auf deaktiviert steht. Windows 11 macht da alles selber, da kann auch der Admin nicht mehr gross eingreifen.
Falls noch nicht versucht :
Systemdateien reparieren:
sfc /scannow
Systemimage prüfen und reparieren:
dism /online /cleanup-image /restorehealth
Im WWW findet man dazu detaillierte Beschreibungen und Anleitungen.
/EDIT/ Das Netzwerk ist ja kaputt, geht ev. nur offline. Suchen mit "dism offline repair windows 11"
Ich habe bisher einige wenige Rechner mit Baujahr 2014 per Inplace Upgrade auf Windows 11 gebracht. Ausser das man wegen TPM 1.2 TPM und teilweise den CPU-Check ausschalten musste, gab es keine Probleme. Die Netzwerkkomponenten waren von Intel.
Nochmals Dank, ChristophH.
Um eine lange Geschichte kurz zu machen (nach langen Stunden Installationen, Recherchen sowie Trial und Error im Verlauf eines Monats):
Nachdem ich Hardware-Probleme ausschließen konnte, habe ich per regedit unter Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache "Start" aufgerufen und dort den Wert "2" eingegeben (s.a. https://metrovpn.xyz/blog/enable-or-disable-dns-client.html).
Siehe da, es funzte, der DNS-Server wurde zugewiesen. Der Zugang per Ethernet und Wifi zum Internet gelingt. Die ipconfig-Befehle zeigen und machen, was sie sollen. Auch Updates werden direkt von Windows 11 abgerufen und installiert.
Allerdings wird mir per ncpa.cpl bei den Internet-Verbindungen gegen die Fakten jeweils "Kein Internet-Zugriff" angezeigt. Unten im Display erscheint die "Weltkugel".
Der per regedit unter HKLM\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\Internet "EnableActiveProbing" eingegebene Wert "1" ändert daran nichts (Tipp vom Februar 2020 mit Bezug auf Windows 10 hier im Blog.)
Gibt es aktuelle Hinweise, wie die Anzeige korrigiert werden kann?
Zur Info: Bevor ich die ISO-Datei für Windows 11 barrierefrei installiert habe, hatte ich "ct_registry_trick.reg" (dazu auch seriös: https://www.youtube.com/watch?v=z-bm8JTvBBU) laufen lassen. Die Installation ging glatt vonstatten.
Viele Grüße
Konsult
Hallo Konsult
"ct_registry_trick.reg" schaltet einfach alle Checks ab, welche das Setup macht. Ich kannte diese Datei nicht, finde darin aber keine Einstellungen welche meiner Ansicht nach die Netzwerkerkennung beeinflussen.
Ich habe einen Artikel gefunden, welcher die Funktion des "Netzwerkverbindunsstatusindikator" beschreibt (für Windows 10) – kannte ich noch nicht, hilft Dir vielleicht das Problem zu lösen:
"Netzwerkverbindungsstatusindikator (NETWORK Connection Status Indicator, NCSI) – Anleitung zur Problembehandlung"
https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking/troubleshoot-ncsi-guidance
Hinweise:
– der Dienst NLA (Network Location Awarness) hat auf meinem Referenzsystem die Start-Einstellung "manuell" und ist im laufend Betrieb nicht gestartet.
– Der im Artikel erwähnte Schlüssel [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet] ist bei unseren Rechnern mit Domänenmitgliedschaft leer, ansonsten wie unten dokumentiert auf meinem Win11-Referenzsystem konfiguriert.
– Lade nicht den kompletten Registry-Schlüssel NlaSvc in dein System sondern nur selektiv Einträge im Parameters-Schlüssel.
– Exportiere vorher den Schlüssel NlsSvc als Backup in eine Reg-Datei.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc]
"Description"="@%SystemRoot%\\system32\\netprofmsvc.dll,-209"
"DisplayName"="@%SystemRoot%\\system32\\netprofmsvc.dll,-208"
"ErrorControl"=dword:00000001
"ImagePath"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\
74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,73,\
00,76,00,63,00,68,00,6f,00,73,00,74,00,2e,00,65,00,78,00,65,00,20,00,2d,00,\
6b,00,20,00,6e,00,65,00,74,00,70,00,72,00,6f,00,66,00,6d,00,20,00,2d,00,70,\
00,00,00
"ObjectName"="NT AUTHORITY\\NetworkService"
"RequiredPrivileges"=hex(7):53,00,65,00,49,00,6d,00,70,00,65,00,72,00,73,00,6f,\
00,6e,00,61,00,74,00,65,00,50,00,72,00,69,00,76,00,69,00,6c,00,65,00,67,00,\
65,00,00,00,53,00,65,00,43,00,68,00,61,00,6e,00,67,00,65,00,4e,00,6f,00,74,\
00,69,00,66,00,79,00,50,00,72,00,69,00,76,00,69,00,6c,00,65,00,67,00,65,00,\
00,00,00,00
"ServiceSidType"=dword:00000001
"Start"=dword:00000003
"Type"=dword:00000020
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\LANIds]
"WLANDllName"="WlanApi.dll"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters]
"ServiceDll"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\
00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\
6e,00,65,00,74,00,70,00,72,00,6f,00,66,00,6d,00,73,00,76,00,63,00,2e,00,64,\
00,6c,00,6c,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Cache]
"OpportunisticInternetGatewaysV4"=hex:06,be,42,a5,b3,2d,78,00,00,ab,5d,02,00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet]
"ActiveDnsProbeContent"="131.107.255.255"
"ActiveDnsProbeContentV6"="fd3e:4f5a:5b81::1"
"ActiveDnsProbeHost"="dns.msftncsi.com"
"ActiveDnsProbeHostV6"="dns.msftncsi.com"
"ActiveWebProbeContent"="Microsoft Connect Test"
"ActiveWebProbeContentV6"="Microsoft Connect Test"
"ActiveWebProbeHost"="www.msftconnecttest.com"
"ActiveWebProbeHostV6"="ipv6.msftconnecttest.com"
"ActiveWebProbePath"="connecttest.txt"
"ActiveWebProbePathV6"="connecttest.txt"
"CaptivePortalTimer"=dword:00000000
"CaptivePortalTimerBackOffIncrementsInSeconds"=dword:00000005
"CaptivePortalTimerMaxInSeconds"=dword:0000001e
"EnableActiveProbing"=dword:00000001
"PassivePollPeriod"=dword:0000000f
"StaleThreshold"=dword:0000001e
"WebTimeout"=dword:00000023
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\ManualProxies]
/EDIT/:
Hast Du das mal probiert – er schreibt, er hätte EnableActiveProbing auf 0 setzen müssen, dann hätte es funktioniert. Nicht logisch, aber wenn es hilft:
https://www.borncity.com/blog/2020/02/24/windows-10-meldet-kein-internet-obwohl-verbindung-besteht/#comment-87976
und der in diesem Kommentar verlinkte Beitrag auf github hilft auch nicht?
https://www.borncity.com/blog/2020/02/24/windows-10-meldet-kein-internet-obwohl-verbindung-besteht/#comment-90956
Vergleichbare Probleme (insbesondere das Standardgateway betreffend) habe ich im Moment vermehrt beim Umstellen ehemaliger VMware-Umgebungen auf Proxmox.
Das Bild ist eigentlich immer gleich: Durch Wechsel der Virtualisierung wird ein neuer Eintrag für die Netzwerkkarte angelegt. Je nach Weg den man gegangen ist entweder ein "VMxnet Adapter #2" oder gleich der paravirtualisierte "Red Hat VirtIO Adapter".
Versucht man dort ein Default Gateway händisch einzutragen kommt die Aussage, daß diese Adresse bereits einem anderen Adapter zugewiesen ist – das Default Gateway bleibt leer und die VM ist nicht erreichbar.
Lösung ist, im Gerätemanager alle ausgeblendeten Geräte (set DEVMGR_SHOW_NONPRESENT_DEVICES=1) anzuzeigen und die betreffenden Netzwerkadapter zu löschen.
In Deinem Fall ist möglicherweise durch die Umstellung Windows 10 auf 11 noch ein alter Eintrag vorhanden oder es liegt eine andere Hardware-Besonderheit vor. Das könnte zum Beispiel sein, daß der Computer eigentlich ein Laptop ist und fallweise mit einer Dockingstation betrieben wird, die einen zusätzlichen Netzwerkadapter einblendet – oder eben nicht.
Vielen Dank, ChristophH. Ich genieße jetzt – vorerst – die restliche Sommerzeit. Dann sehen wir weiter.
Viele Grüße
Konsult
Hallo zusammen,
ich kann ebenfalls von sehr interessanten Problemen dieser Kategorie berichten. Auf 2 hardwaremäßig völlig identischen AMD PCs (ASUS B650 Mainboard, Win11 Pro) funktioniert der Internet Zugriff nur auf einem PC. Im März 2025 wurden beide PCs gekauft und mit Windows 10 von vorherigen ebenfalls identischen PCs übernommen. Nach einigen Wochen wurde Win11 Pro installiert. Aus unbekannten Gründen stellte Microsoft die Version 23H2 zur Verfügung, obwohl 24H2 schon längst verfügbar war. Die Software ist auf beiden PCs sehr ähnlich, aber nicht identisch. Hier mein kurzer Erfahrungsbericht:
PC1: Microsoft hat nie versucht automatisch 24H2 zu installieren. Erst im August habe ich dies manuell durchgeführt. Es gab nie Probleme mit dem Internetzugang via LAN. WLAN Zugang über NewFast und AVM USB Sticks funktionieren jedoch nicht.
PC2: Microsoft hat im Juli 2025 automatisch über Nacht 24H2 installiert. Das Netzwerk ging danach weder über LAN noch über WLAN (2 unterschiedliche USB Sticks – AVM und NewFast). Die oben angeführten typischen Fehlermeldungen wurden angezeigt. Tagelange Versuche mit diversen Tipps aus Fachkreisen liefen ins Leere. Auf Details möchte ich hier verzichten, weil es lange Texte werden würden. Da ich regelmäßig Images mache, konnte ich auf ältere 23H2 Versionen zurückgehen, die alle einwandfrei bis zum nächsten erzwungenen Update auf 24H2 funktionierten. Erst durch die von Microsoft angebotene Version des Rückgangs auf die vorherige Version stoppten die Zwangsupdates und PC2 hat nun wieder verlässlichen Internetzugang, wird aber in der FritzBox 7590 als nicht verbundenes Gerät angezeigt. Im übrigen hat KB5046617 keine Lösung gebracht, obwohl es längst Bestandteil der neueren Updates sein müsste.
Hochinteressant ist die Situation, dass nach dem 2. der 3 Zwangsupdates auf 24H2 Mitte August, der Netzwerkzugang via LAN und das WLAN für ca 1 Woche funktionierten und danach eines Morgens wieder nach automatischen Updates blockierten. Der Versuch die aktuellen RealTek Treiber direkt über die älteren Windows Treiber zu installieren scheiterte immer mit der Meldung, dass die älteren Treiber nicht ersetzt werden können. Scheinbar hat Microsoft hier eine Sperre eingebaut, die ich nicht umgehen kann.
Eine weitere Beobachtung in diesem Zusammenhang ist, dass die FritzBox 7590 seit den Zwangsupdates auf 24H2 alle Geräte außer dem Handy als nicht verbunden anzeigt. Spricht man einen der 3 Netzwerkdrucker an, werden die Druckaufträge unabhängig vom Druckertyp entweder sofort, verzögert oder manchmal überhaupt nicht ausgeführt. Auch 2 Notebooks erscheinen manchmal als verbunden und dann auch wieder nicht. Der Netzwerkzugang ist bei beiden möglich, aber manchmal auch zeitlich verzögert. Beide Notebooks wurden vor kurzem von Windows 10 auf Windows 11 (Home) mittels Rufus und einer ISO Datei upgegradet.
Trotz vielseitiger Spekulationen ist sicher, dass die Probleme definitiv in Zusammenhang mit 24H2 stehen, wobei selbst bei identischer Hardware, der Fehler nur bei einer kleineren Zahl an 24H2 PCs auftritt. Wenn Microsoft schon Zwangsupdates durchführt, dann sehe ich hier schon eine klare Verantwortung, dass solche Probleme seitens Mikrosoft gelöst werden, auch wenn es nur eine Mindertheit an PCs betrifft.
Obwohl seit 30 Jahren sehr aktiv als Entwickler und Softwareanwender tätig (wenn auch nicht als Netzwerkexperte), bin ich über das Verhalten von Microsoft nicht erstaunt. Ich habe in all den Jahren größtenteils sehr schlechte Erfahrungen gemacht, wenn eines der unendlich vielen Probleme durch fehlerhafte Software aufgetreten ist. Meist konnte ich Lösungen nur über Foren wie dieses finden. Microsoft Support ist generell nur Zeitverschwendung.
> Auf 2 hardwaremäßig völlig identischen AMD PCs (ASUS B650 Mainboard, Win11 Pro)
Ob die Hardware wirklich völlig identisch ist? Hast Du die Chipsätze geprüft? Sind die beiden PCs aus derselben Charge? Selbst wenn nur ein Chip anders ist, dann ist die Hardware nicht identisch. Und Hersteller verbauen meistens die kostengünstigsten Bauteile. Und schon ändert sich die Hardware. Wenn auch nur marginal.