Wie Windows 11 Netzwerkadapter, Profile und DNS nutzt – und warum manchmal „Kein Internet“ angezeigt wird

Adapter und Schnittstellen unter Windows 11: physisch, virtuell, Prioritäten und Metriken

Unter Windows 11 bildet der Begriff „Netzwerkadapter“ eine Sammelkategorie für sehr unterschiedliche Schnittstellen: klassische Hardware wie Ethernet- und WLAN-Controller, Funkmodule für Mobilfunk oder Bluetooth-Tethering sowie rein softwarebasierte Endpunkte wie VPN-Tunnel, virtuelle Switchports oder Loopback-Interfaces. Für die Netzwerkanalyse zählt weniger die „Art“ des Adapters als dessen Eigenschaften im TCP/IP-Stack: Link-Status, IP-Konfiguration, Bindungen an Protokolle und die Rolle in der Routenentscheidung.

Mehrere gleichzeitig aktive Adapter sind in Windows 11 der Normalfall, etwa WLAN parallel zu Ethernet, dazu virtuelle Adapter von Hyper-V, WSL oder VPN-Clients. Das System wählt dann für ausgehende Verbindungen einen Pfad anhand der Routingtabelle, der Interface-Metrik und spezifischer Zielrouten. Diese Priorisierung lässt sich beobachten und gezielt beeinflussen, ohne die Adapter „deaktivieren“ zu müssen.

Physische Adapter: Link, Offloads und Medienwechsel

Physische Adapter liefern einen klaren Link-Status („Media connected/disconnected“), der unmittelbar auf die IP-Schicht durchschlägt. Bei Ethernet ist der Medienwechsel oft deterministisch, bei WLAN kommen Roaming, Energiesparzustände und Bandwechsel hinzu. Windows 11 kombiniert dafür Treiberereignisse (NDIS) mit IP-Statusinformationen; dadurch kann ein Interface „Up“ sein, obwohl keine nutzbare Standardroute existiert, etwa in isolierten VLANs oder Gastnetzen.

Leistungsmerkmale wie RSS, RSC oder Checksum-Offload wirken auf Durchsatz und CPU-Last, verändern jedoch nicht die logische Pfadauswahl. Für Fehlersuche sind dagegen Duplex-/Speed-Aushandlung, WLAN-Authentifizierung und 802.1X-Status relevant, weil sie die Stabilität des Link-Layers bestimmen. Solche Aspekte erscheinen in der Adapterübersicht oft nur indirekt, lassen sich aber über Systemabfragen präzise auslesen.

Virtuelle Adapter: VPN, Hyper-V, WSL und Tunnels

Virtuelle Adapter entstehen durch Netzwerkvirtualisierung oder Tunneling. Ein VPN-Client installiert typischerweise ein virtuelles Interface und ergänzt Routen, DNS-Server und manchmal einen eigenen Proxy- oder Filtertreiber. Hyper-V erzeugt vEthernet-Ports am virtuellen Switch, WSL2 arbeitet mit einer NAT-Topologie, und zusätzliche Tunnels können über Teredo oder IP-HTTPS-Mechanismen bereitgestellt werden (soweit durch Richtlinien und Betriebsszenarien genutzt).

Wesentlich ist die Trennung zwischen „Adapter vorhanden“ und „Adapter routet“. Ein Hyper-V-vEthernet kann lokal erreichbar sein, ohne jemals als Standardgateway zu dienen; ein VPN-Tunnel kann dagegen bewusst den Default-Route übernehmen (Full Tunnel) oder nur bestimmte Präfixe (Split Tunnel). Daraus ergeben sich parallele DNS- und Gateway-Pfade, die je nach Name, Zielnetz und Metrik unterschiedlich aufgelöst werden.

Prioritäten: Routing, Metriken und automatische Auswahl

Windows entscheidet für jedes Ziel anhand der „besten“ Route: längstes Präfix gewinnt, bei Gleichstand zählt die niedrigste Metrik. Die Gesamtmetrik ergibt sich aus der Routenmetrik plus der Interface-Metrik. Standardmäßig nutzt Windows 11 eine automatische Metrik, die unter anderem Link-Geschwindigkeit und Adaptertyp berücksichtigt. Dadurch kann Ethernet häufig vor WLAN bevorzugt werden, selbst wenn beide eine Standardroute anbieten.

Komplex wird die Lage bei mehreren Default-Gateways, etwa Ethernet im Firmennetz und gleichzeitig ein VPN, das ebenfalls eine Default-Route setzt. Zusätzlich kann DNS über mehrere Interfaces verteilt sein; Windows priorisiert Schnittstellen, berücksichtigt aber auch Namensauflösungsrichtlinien (z. B. NRPT in Unternehmensumgebungen) und die Erreichbarkeit der DNS-Server. Für saubere Vorhersagen ist daher die Kombination aus Route, Metrik und DNS-Konfiguration entscheidend.

• Adapterzustand und IP-Konfiguration: Get-NetAdapter | Select-Object Name, Status, LinkSpeed, ifIndex
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address, IPv6Address, IPv4DefaultGateway, DNSServer
• Routingtabelle und effektive Pfadauswahl: Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric, InterfaceMetric
Get-NetRoute -DestinationPrefix 0.0.0.0/0
• Interface-Metrik prüfen/setzen: Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias, InterfaceMetric, AutomaticMetric
Set-NetIPInterface -InterfaceAlias "WLAN" -AutomaticMetric Disabled -InterfaceMetric 50
• DNS-Server je Interface: Get-DnsClientServerAddress | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Bindungen, Filtertreiber und „unsichtbare“ Eingriffe

Nicht jede Netzwerkwirkung entsteht durch IP-Routen. Filtertreiber (Firewall, Endpoint-Security, VPN-Clients, Packet-Capture) hängen sich in den Netzwerkpfad und können Pakete umleiten, kapseln oder blockieren, ohne dass sich die sichtbare Route ändert. Auch Bindungen an Komponenten wie IPv6, Client für Microsoft-Netzwerke oder Dateifreigabe beeinflussen zwar nicht die Metrik, aber die Dienste, die auf einem Adapter angeboten werden.

Für präzise Diagnosen ist deshalb die Unterscheidung wichtig: Routing und Metrik erklären, welcher Adapter „zuständig“ ist; Filter- und Binding-Logik erklärt, ob und wie Verkehr tatsächlich durchgelassen wird. In Umgebungen mit mehreren parallelen Adaptern liefert erst die Kombination aus Adapterstatus, Interface-Metrik, Routen und installierten Filtern ein konsistentes Bild.

• Netzwerkprofile und Schnittstellen-Zuordnung: Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory, IPv4Connectivity, IPv6Connectivity
• Treiberbindung und erweiterte Adaptereigenschaften: Get-NetAdapterBinding -Name "Ethernet"
Get-NetAdapterAdvancedProperty -Name "Ethernet" | Select-Object DisplayName, DisplayValue
• Winsock/Proxy als zusätzlicher Einflussfaktor: netsh winhttp show proxy

Von der IP-Zuweisung bis zum Gateway: DHCP, statische Konfiguration, Routing und parallele Pfade

DHCP unter Windows 11: Lease, Optionen und Reihenfolge der Parameter

In typischen Windows-11-Umgebungen bezieht ein Netzwerkadapter seine IPv4-Konfiguration über DHCP und erhält IPv6-Parameter meist über Router Advertisements (RA) sowie optional über DHCPv6. Windows verarbeitet dabei nicht nur die Adresse selbst, sondern ein Bündel an Parametern: Subnetzmaske bzw. Prefix Length, Standardgateway, DNS-Server, DNS-Suffixe und weitere Optionen wie NTP-Server oder WPAD. Entscheidend ist, dass diese Informationen immer adapterbezogen gespeichert werden. Bei einem Wechsel des physischen Mediums (WLAN zu Ethernet) oder bei parallelen Adaptern entstehen daher getrennte Konfigurationen, die jeweils eigene Leases und eigene DNS-Serverlisten mitbringen.

Bei IPv6 kommen zusätzlich Router Advertisements (RA) ins Spiel. Ein Adapter kann gleichzeitig SLAAC (autokonfigurierte Adresse), temporäre Privacy-Adressen und per DHCPv6 bezogene Zusatzinformationen nutzen. Windows entscheidet anhand der verfügbaren Informationen, welche Quelladresse für ausgehende Verbindungen bevorzugt wird. Gleichzeitig kann ein Netzwerk über DHCPv6 „nur“ DNS-Server liefern, während Adress- und Gateway-Informationen über RA kommen. In der Praxis erklärt das, warum die Analyse ohne Blick auf beide Protokollwelten schnell unvollständig bleibt.

• Lease- und DHCP-Details prüfen: ipconfig /all
Get-NetIPConfiguration -Detailed
• DHCP-Status je Adapter: Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias,Dhcp,ConnectionState
• DHCP-Lease erneuern (IPv4): ipconfig /renew
• IPv6-Konfiguration inkl. Präfixe sichtbar machen: netsh interface ipv6 show addresses
Get-NetIPAddress -AddressFamily IPv6

Statische Konfiguration: Prioritäten, Stolperstellen und saubere Trennung

Statische Einstellungen sind unter Windows 11 pro Adapter konsistent, aber fehleranfällig, sobald mehrere Parameter manuell gesetzt werden. Ein häufiger Bruch entsteht durch eine statische IP ohne passenden Prefix oder mit einem Gateway, das außerhalb des lokalen Subnetzes liegt. Windows akzeptiert viele dieser Konfigurationen zunächst, die effektive Erreichbarkeit scheitert jedoch später an ARP/ND-Auflösung oder daran, dass keine Route zum Gateway aufgebaut werden kann. Bei IPv6 ist außerdem relevant, dass ein Default-Gateway in der Praxis meist über RA gelernt wird. Eine manuell konfigurierte IPv6-Route kann RA-basierte Entscheidungen überschreiben und damit Pfade unerwartet umleiten.

Für DNS gilt: Statische DNS-Server pro Adapter haben Vorrang gegenüber DHCP-gelernten DNS-Servern, werden aber trotzdem in die globale Namensauflösung eingebracht. Damit kann ein einzelner „falsch“ statisch gesetzter DNS-Server die Auflösung bestimmter Zonen dominieren, obwohl der Internetpfad über einen anderen Adapter läuft. Windows verwendet eine Kombination aus Adaptermetriken, Namenssuffix-Suchliste und NRPT/Policy-Regeln, um Anfragen zu lenken; die Wirkung ist daher stärker als „nur“ ein lokaler Resolver-Eintrag.

• Statische IPv4-Adresse und Gateway setzen: New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.0.2.10 -PrefixLength 24 -DefaultGateway 192.0.2.1
• Statische DNS-Server pro Adapter setzen: Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 1.1.1.1,8.8.8.8
• Konfiguration verifizieren (Routing, DNS, IP): Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric,InterfaceMetric
Get-DnsClientServerAddress

Routing-Entscheidungen: Metriken, Default-Route und das „best route“-Prinzip

Windows wählt den Pfad zu einem Ziel anhand der Routingtabelle nach längstem Präfix (Longest Prefix Match). Stimmen mehrere Routen in ihrer Präfixlänge überein, entscheidet die niedrigere Summe aus Routenmetrik und Interface-Metrik. Genau hier entstehen typische Effekte bei parallelen Adaptern: Eine VPN-Verbindung bringt häufig spezifische Unternehmensrouten (Split-Tunnel) oder eine 0.0.0.0/0-Default-Route (Full-Tunnel) mit. Parallel ist ein lokaler WLAN- oder Ethernet-Adapter weiterhin aktiv. Ohne klare Metriken kann der Default-Pfad zwischen Adaptern wechseln, etwa wenn sich die Linkrate ändert oder ein Adapter kurzzeitig „Connected“ meldet, aber der Upstream blockiert ist.

Bei Dual-Stack-Netzen bewertet Windows IPv6-Ziele grundsätzlich eigenständig und nutzt eine separate Routingtabelle. Eine scheinbar „funktionierende“ Internetverbindung kann deshalb IPv4-basiert sein, während IPv6 im Zustand „No route“ oder „Link-local only“ bleibt. Umgekehrt kann IPv6 bevorzugt werden, wenn AAAA-Records vorhanden sind und die IPv6-Default-Route valide ist. Für Fehlerbilder wie „kein Internet“ trotz gültiger IP ist es daher zentral, Routen, Gateway-Erreichbarkeit und DNS getrennt zu prüfen, statt nur auf die Adresse zu schauen.

Parallele Pfade und Adapter: VPN, virtuelle Switches, Tethering und Priorisierung

Mehrere aktive Adapter sind unter Windows 11 der Normalfall: physische NICs, WLAN, VPN-Tunnel (z. B. IKEv2, SSTP oder WireGuard), Hyper-V-vEthernet, WSL/Container-Interfaces oder USB-Tethering. Jeder Adapter bringt eigene IP-Parameter und häufig eigene DNS-Server mit. Die Pfadauswahl folgt jedoch nicht der „zuletzt verbunden“-Logik, sondern den Routingregeln. Dadurch können parallele Wege entstehen, bei denen der Default-Traffic über Adapter A läuft, aber bestimmte Ziele über Adapter B. Dieser Zustand ist technisch korrekt, führt aber zu schwer interpretierbaren Symptomen, wenn DNS-Auflösung und Routing nicht zueinander passen (DNS über VPN, aber Default-Route über WLAN, oder umgekehrt).

Windows bietet zur Stabilisierung zwei Hebel: Metriken und gezielte Routen. Eine Interface-Metrik lässt sich automatisch berechnen oder manuell setzen. Manuelle Metriken sind besonders in Test- oder Übergangsszenarien hilfreich, etwa wenn ein LTE-Tethering nur als Fallback dienen soll. Für dauerhafte Unternehmenskonfigurationen werden spezifische Routen (z. B. zu internen Netzen) sauberer bewertet als das harte Erzwingen einer Default-Route, weil sie weniger Seiteneffekte für externe Ziele erzeugen. Wichtig bleibt, dass Änderungen konsistent mit DNS-Suffixen und ggf. VPN-internen Namensräumen erfolgen; sonst erscheint die Verbindung „eingeschränkt“, obwohl IP-Connectivity zu einigen Zielen besteht.

• Routingtabelle (IPv4) mit Metriken anzeigen: route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix,RouteMetric
• Interface-Metrik prüfen und setzen: Get-NetIPInterface | Select-Object InterfaceAlias,AddressFamily,InterfaceMetric,AutomaticMetric
Set-NetIPInterface -InterfaceAlias "Wi-Fi" -AutomaticMetric Disabled -InterfaceMetric 50
• Gezielte statische Route (Beispiel Split-Tunnel) hinzufügen: New-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceAlias "VPN" -NextHop 0.0.0.0

Gateway-Erreichbarkeit und Pfadprüfung: von der lokalen Nachbarschaft bis zum Upstream

Der Default-Gateway-Eintrag ist nur dann sinnvoll, wenn das Gateway auf Layer 2 tatsächlich erreichbar ist. Bei IPv4 wird dazu eine ARP-Auflösung benötigt, bei IPv6 Neighbor Discovery. Scheitert diese Nachbarschaftsauflösung, wirkt das System trotz „gültiger“ IP-Konfiguration offline. Auch asymmetrische Situationen sind möglich: Das Gateway antwortet auf ARP, leitet aber nicht weiter (z. B. Captive Portal, VLAN-Fehlzuordnung, Upstream-Filter). Windows kann dann lokale Netze erreichen, jedoch keine externen Ziele. Solche Zustände werden häufig als „eingeschränkte Konnektivität“ wahrgenommen, obwohl sie technisch präzise als Upstream- oder DNS-Problem einzuordnen sind.

Für eine belastbare Diagnose werden drei Ebenen getrennt geprüft: lokale IP-Parameter am Adapter, Erreichbarkeit des Gateways und schließlich ein externer Hop. Parallel muss die DNS-Auflösung validiert werden, weil ein korrektes Routing ohne funktionierende Namensauflösung im Alltag ebenfalls wie „kein Internet“ erscheint. Unter Windows 11 liefert die Kombination aus ICMP-Tests, Routenprüfung und DNS-Abfragen ein konsistentes Bild, insbesondere wenn mehrere Adapter konkurrieren und die „beste Route“ nicht intuitiv ist.

• Gateway und externer Hop prüfen: Test-NetConnection -ComputerName 8.8.8.8 -InformationLevel Detailed
tracert -d 8.8.8.8
• DNS-Auflösung gegen definierte Server testen: Resolve-DnsName example.com
nslookup example.com 1.1.1.1
• Nachbarschaftstabellen (L2-Erreichbarkeit) einsehen: arp -a
netsh interface ipv6 show neighbors

DNS und Verbindungszustände: Namensauflösung, NCSI-Erkennung, Profilwechsel und Auswirkungen auf Firewall/Freigaben

DNS-Auflösung unter Windows 11: Resolver-Reihenfolge und lokale Wissensquellen

Die DNS-Auflösung unter Windows 11 besteht aus mehreren Schichten, die nacheinander ausgewertet werden. Zunächst wirken lokale Datenquellen: die Hosts-Datei, bereits gecachte Antworten und (bei aktivem LLMNR/NetBIOS) lokale Namensauflösungsverfahren im Subnetz. Erst danach fragt der DNS-Client die konfigurierten DNS-Server ab. Welche Server tatsächlich verwendet werden, hängt von der Adapterkonfiguration (IPv4/IPv6 getrennt), VPN-Tunneln, Split-DNS-Konfigurationen und der Schnittstellenpriorität ab.

Windows pflegt einen DNS-Client-Cache, der sowohl positive als auch negative Antworten (NXDOMAIN) zwischenspeichern kann. Damit lassen sich Zustände unterscheiden, in denen ein DNS-Server erreichbar ist, aber bestimmte Namen nicht auflösbar sind, von Fällen, in denen keine DNS-Antworten eintreffen. Parallel existieren pro Schnittstelle registrierte DNS-Suffixe und Suchlisten, die bei unqualifizierten Namen (Single-Label/kurze Hostnamen) entscheidend sind. In Unternehmensnetzen prägen Richtlinien häufig die Suffixsuche und steuern, ob unqualifizierte Namen überhaupt ergänzt werden.

• DNS-Server und Suffixe je Schnittstelle: Get-DnsClientServerAddress
Get-DnsClient | Select-Object InterfaceAlias,ConnectionSpecificSuffix,UseSuffixWhenRegistering
• Resolver-Cache prüfen/invalidieren: Get-DnsClientCache
Clear-DnsClientCache
• Namensauflösung gezielt testen (inkl. Serverwahl): Resolve-DnsName example.com
Resolve-DnsName example.com -Server 1.1.1.1
• Komplette Schnittstellen- und DNS-Sicht in einer Momentaufnahme: ipconfig /all

Bei parallelen Adaptern (z. B. Ethernet plus WLAN plus VPN) entscheidet nicht „der schnellste“, sondern der von Windows gewählte Pfad. Für DNS bedeutet das: Anfragen können über einen anderen Adapter laufen als der, über den der Webverkehr erwartet wird, wenn Metriken und Namensrichtlinien (NRPT/DirectAccess-/VPN-Split-DNS) dies vorgeben. Dadurch entsteht ein typisches Fehlerbild: IP-Konnektivität ist vorhanden, aber die Namensauflösung liefert interne Antworten über den VPN-DNS oder scheitert wegen fehlender Erreichbarkeit der zuständigen DNS-Server.

NCSI und Verbindungszustände: Wie Windows „Internet“ und Einschränkungen erkennt

Der in Windows integrierte Network Connectivity Status Indicator (NCSI) bewertet nicht nur Link-Status oder IP-Konfiguration, sondern führt aktive Prüfungen aus. Dazu gehören DNS-Abfragen und HTTP-Checks gegen Microsoft-Endpunkte, um Captive Portals und „walled gardens“ zu erkennen. Die resultierende Anzeige in der Taskleiste („Internet“, „Kein Internet“, „Aktion erforderlich“) ist damit eine Heuristik: Sie kann korrekt sein, aber auch bei blockierten Prüfpfaden oder bei restriktiven Proxys abweichen, obwohl Internetzugang für Anwendungen über andere Wege funktioniert.

Typische Ursachen für „Kein Internet“ trotz funktionierender Browser-Sitzung sind blockierte NCSI-HTTP-Ziele, umgeleitete DNS-Antworten oder ein Proxy, der die NCSI-Checks nicht passieren lässt. Umgekehrt kann „Internet“ angezeigt werden, während einzelne Ziele nicht erreichbar sind, etwa bei DNS-Split-Brain oder wenn nur IPv6 oder nur IPv4 sauber geroutet wird. Für die Fehleranalyse ist daher entscheidend, NCSI-Anzeige, DNS-Auflösung und Routing getrennt zu prüfen.

• IP- und Gateway-Pfad verifizieren: Get-NetIPConfiguration
route print
tracert 1.1.1.1
• DNS und TCP getrennt prüfen: Resolve-DnsName www.microsoft.com
Test-NetConnection www.microsoft.com -Port 443
• NCSI-relevante Richtlinien/Schalter erkennen (falls gesetzt): reg query "HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet"

Profilwechsel (öffentlich/privat) und die unmittelbaren Folgen für Firewall und Freigaben

Der Netzwerkstandorttyp steuert in Windows 11 zentrale Sicherheitsentscheidungen: Das aktive Profil („Öffentlich“, „Privat“, in Domänenumgebungen zusätzlich „Domäne“) legt fest, welche Windows Defender Firewall-Regeln greifen und ob Dienste wie Netzwerkerkennung oder Datei- und Druckerfreigabe standardmäßig aktiv sind. Ein Profilwechsel wirkt sofort auf die Regelgruppen, die auf Profilen basieren, ohne dass Anwendungen selbst angepasst werden müssen.

„Öffentlich“ ist restriktiv ausgelegt: eingehende Verbindungen werden stärker blockiert, und Discovery-Protokolle sollen das Gerät in unsicheren Netzen weniger sichtbar machen. „Privat“ erlaubt typischerweise mehr eingehenden Verkehr innerhalb des lokalen Netzes (je nach Regelbasis), was für SMB-Freigaben, Medienstreaming oder Verwaltungstools relevant ist. In Domänennetzen entscheidet zusätzlich die Domänenprofilbindung; diese hängt von der erfolgreichen Domänenerkennung ab, die wiederum DNS, Zeitquelle und Erreichbarkeit von Domänencontrollern voraussetzt.

• Aktuelles Profil je Schnittstelle anzeigen: Get-NetConnectionProfile
• Profiltyp gezielt setzen (administrativ): Set-NetConnectionProfile -InterfaceAlias "WLAN" -NetworkCategory Private
• Firewall-Profilstatus und Standardaktionen prüfen: Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction
• Regelgruppen für Freigaben/Erkennung identifizieren: Get-NetFirewallRule -DisplayGroup "Datei- und Druckerfreigabe" | Select-Object DisplayName,Enabled,Profile,Direction,Action
Get-NetFirewallRule -DisplayGroup "Netzwerkerkennung" | Select-Object DisplayName,Enabled,Profile,Direction,Action

In gemischten Szenarien mit gleichzeitig aktiven Adaptern kann ein Profilwechsel zudem indirekte Effekte erzeugen: Anwendungen binden Listener an „Private“ oder „Public“-Profile, und Windows kann eingehende Regeln profilabhängig anwenden, während ausgehender Verkehr weiterhin über den bevorzugten Standardroute-Adapter fließt. Dadurch entsteht der Eindruck, ein Dienst sei „im Netz“, ist aber von außen nicht erreichbar, weil das aktuell aktive Profil des Adapters, an dem der Dienst tatsächlich lauscht, restriktiver ist als erwartet.