Ein nicht erreichbares Standard-Gateway beheben Sie in drei Schritten: Prüfen Sie mit ipconfig oder ip route, ob überhaupt ein Gateway zugewiesen ist. Testen Sie es per ping und arp -a. Ist die Adresse falsch, fehlt oder antwortet nicht, erneuern Sie den DHCP-Lease, korrigieren die statische Konfiguration oder starten den Router neu.
Symptome
- Browser meldet „Keine Internetverbindung“, obwohl das WLAN-Symbol verbunden ist
- ping auf die Gateway-IP liefert „Zeitüberschreitung der Anforderung“ oder „Zielhost nicht erreichbar“
- tracert bricht schon beim ersten Hop ab
- Netzwerkadapter zeigt IPv4-Adresse, aber Feld „Standardgateway“ ist leer
- Interne Freigaben funktionieren, jede externe Adresse jedoch nicht
Häufige Ursachen
Fehlender oder falscher DHCP-Lease
Der Client hat per APIPA eine 169.254.x.x-Adresse gezogen oder erhält eine IP aus einem falschen Scope ohne passendes Gateway-Option-3-Feld vom DHCP-Server.
Statische IP im falschen Subnetz
Die manuell gesetzte Gateway-Adresse liegt außerhalb der Subnetzmaske des Clients. Das Betriebssystem verwirft die Route stillschweigend und meldet das Ziel als nicht erreichbar.
ARP- oder Layer-2-Störung
Der Switchport ist im falschen VLAN, Spanning-Tree blockiert oder der ARP-Cache enthält einen veralteten MAC-Eintrag für das Gateway.
Firewall- oder Endpoint-Schutzregel
Lokale Firewalls (Windows Defender, iptables) oder EDR-Agenten blockieren ICMP oder verwerfen den ausgehenden Verkehr auf den Router. Das Gateway scheint dann tot, obwohl es antwortet.
Defekter oder eingefrorener Router
CPU-Überlast, überlaufende NAT-Tabelle oder ein Firmware-Bug führen dazu, dass das LAN-Interface Pakete nicht mehr verarbeitet, obwohl die LEDs normal leuchten.
Schritt-für-Schritt-Lösung
- Aktuelle IP- und Gateway-Zuweisung auslesen
Öffnen Sie unter Windows cmd und führen Sie ipconfig /all aus. Unter Linux nutzen Sie ip addr und ip route, unter macOS ifconfig und netstat -nr. Prüfen Sie: Ist eine IPv4 im erwarteten Subnetz vorhanden? Steht dort eine plausible Gateway-Adresse, oder ist das Feld leer bzw. eine 169.254-Adresse aktiv? - Erreichbarkeit des Gateways gezielt testen
Setzen Sie ping <gateway-ip> ab, idealerweise mit -t (Windows) oder ohne Zähler (Linux). Ergänzen Sie arp -a, um zu sehen, ob eine MAC-Adresse für das Gateway gelernt wurde. Fehlt der ARP-Eintrag komplett, liegt das Problem auf Layer 2, nicht bei der IP-Konfiguration. - DHCP-Lease erneuern oder statische Werte korrigieren
Bei DHCP-Clients: ipconfig /release und ipconfig /renew unter Windows, sudo dhclient -r && sudo dhclient unter Linux. Bei statischer Konfiguration prüfen Sie, ob Gateway und Client im selben Subnetz liegen (z. B. 192.168.10.1 zu 192.168.10.50/24). Falsche Masken sind die häufigste stille Ursache. - Physische Verbindung und Adapter neu initialisieren
Tauschen Sie das Patchkabel oder wechseln Sie den Switchport. Deaktivieren und aktivieren Sie den Adapter über ncpa.cpl bzw. ip link set eth0 down/up. Beim WLAN: einmal komplett aus dem Netz löschen und neu verbinden, um zwischengespeicherte Fehlkonfigurationen zu entfernen. - ARP-Cache und Routing-Tabelle bereinigen
Führen Sie unter Windows netsh interface ip delete arpcache und route print aus. Unter Linux ip -s neigh flush all und ip route show. Fehlt eine default-Route, ergänzen Sie sie temporär mit route add 0.0.0.0 mask 0.0.0.0 <gateway> bzw. sudo ip route add default via <gateway>. - Lokale Firewall und Sicherheits-Agent kurz deaktivieren
Schalten Sie testweise Windows Defender Firewall oder ufw ab und wiederholen Sie den Ping. Antwortet das Gateway jetzt, liegt eine Regel oder ein EDR-Filter dazwischen. Aktivieren Sie den Schutz wieder und passen Sie die konkrete Regel an, statt ihn dauerhaft auszuschalten. - Router prüfen und kontrolliert neu starten
Melden Sie sich am Router an und kontrollieren Sie CPU-Last, DHCP-Pool und LAN-Interface-Status. Bei überlaufender NAT-Tabelle oder eingefrorenen Diensten hilft ein sauberer Reboot über die Weboberfläche, nicht das Ziehen des Netzsteckers. Halten Sie die Firmware anschließend aktuell. - Zweites Gerät im selben Segment gegentesten
Verbinden Sie einen Laptop mit dem gleichen Switchport oder SSID. Erreicht dieses Gerät das Gateway problemlos, liegt der Fehler am ursprünglichen Client (Treiber, Profil, Sicherheitssoftware). Scheitert es ebenfalls, konzentrieren Sie sich auf Router, Switch oder VLAN-Konfiguration.
Symptom, wahrscheinliche Ursache und erste Maßnahme
| Symptom | Wahrscheinliche Ursache | Erste Maßnahme |
|---|---|---|
| IPv4 169.254.x.x | DHCP-Server nicht erreichbar | Kabel/Port prüfen, ipconfig /renew |
| Gateway-Feld leer | DHCP-Option 3 fehlt oder statisch unvollständig | Scope-Optionen am DHCP prüfen |
| ping Gateway: Zielhost nicht erreichbar | Falsche Subnetzmaske | Maske und IP-Bereich abgleichen |
| ping Gateway: Zeitüberschreitung | ARP/Layer-2-Problem oder Firewall | arp -a prüfen, Firewall testweise aus |
| tracert bricht bei Hop 1 ab | Router-Interface überlastet oder eingefroren | Router-Status prüfen, Reboot |
| Nur ein Client betroffen | Treiber oder lokales Profil | Adapter zurücksetzen, Treiber neu |
| Ganzes VLAN betroffen | Trunk oder VLAN-Tagging falsch | Switch-Konfiguration kontrollieren |
So beugen Sie vor
- DHCP-Reservierungen für Server und Drucker führen, statt statische IPs manuell zu pflegen
- Monitoring auf das LAN-Interface des Gateways legen, z. B. per SNMP oder ICMP-Check
- Router-Firmware quartalsweise prüfen und in einem Wartungsfenster aktualisieren
- Konfigurationsbackups des Routers versioniert ablegen, um Fehlkonfigurationen zurückzurollen
Häufige Fragen
Warum zeigt ipconfig eine IP, aber kein Standardgateway an?
In fast allen Fällen fehlt DHCP-Option 3 im zuständigen Scope oder der Client hat eine APIPA-Adresse aus dem Bereich 169.254.0.0/16 gezogen, weil kein DHCP-Server geantwortet hat. Prüfen Sie zuerst die DHCP-Konfiguration und die physische Verbindung zum Switch. Bei statischer Konfiguration tragen Sie das Gateway manuell nach und achten darauf, dass es im gleichen Subnetz liegt.
Ist ein nicht antwortender Ping immer ein Beweis für ein defektes Gateway?
Nein. Viele Router blockieren ICMP an der LAN-Seite aus Sicherheitsgründen oder priorisieren es niedrig. Testen Sie zusätzlich mit tracert, arp -a und einem HTTP-Aufruf der Router-Weboberfläche. Nur wenn keiner dieser Wege funktioniert und der ARP-Eintrag fehlt, ist das Gateway tatsächlich unerreichbar.
Wann sollte ich statt weiter zu diagnostizieren einfach neu starten?
Ein gezielter Neustart des Routers ist sinnvoll, wenn CPU-Auslastung oder NAT-Sessions in der Weboberfläche auffällig hoch sind oder mehrere Geräte gleichzeitig den Zugang verlieren. Bei Einzelfällen bringt ein Router-Reboot meist nichts und verschleiert die Ursache. Dokumentieren Sie vorher Uptime, aktive Sessions und Log-Meldungen.