Kein Internet trotz IPv4: Schritt-für-Schritt Diagnose

„Kein Internet trotz IPv4“ ist eines der häufigsten Symptome im IT-Alltag – im Homeoffice genauso wie im Unternehmensnetz. Besonders frustrierend wird es, wenn der Rechner scheinbar korrekt konfiguriert ist: Eine IPv4-Adresse ist vorhanden, die Netzwerkkarte zeigt „verbunden“, vielleicht lässt sich sogar das eigene Gateway anpingen – und trotzdem laden Webseiten nicht, E-Mails kommen nicht an oder Cloud-Anwendungen bleiben hängen. Die Ursache liegt dann oft nicht an „dem Internet“, sondern an einer klar eingrenzbaren Stelle: DNS, Routing, Firewall, Proxy, MTU, NAT oder schlicht eine falsche Subnetzmaske. Eine strukturierte Diagnose spart Zeit, weil sie Tests in eine sinnvolle Reihenfolge bringt: erst lokal, dann bis zum Gateway, dann ins Weitverkehrsnetz und zuletzt auf Anwendungsebene. Dieser Artikel führt dich Schritt für Schritt durch eine praxisbewährte Diagnosekette – von den ersten Sekundenchecks bis zu typischen Spezialfällen wie VPN-Konflikten, Path-MTU-Problemen und Provider-Einschränkungen. Du erhältst konkrete Interpretationen für Ping, Traceroute und DNS-Tests sowie Hinweise, wann ein Ergebnis irreführend sein kann.

Schritt 1: Symptome präzisieren, bevor du testest

„Kein Internet“ ist ein Sammelbegriff. Bevor du Messungen startest, kläre, was genau nicht funktioniert. Das verhindert Fehlinterpretationen (z. B. DNS-Problem als Routing-Problem).

• Geht gar nichts? Oder nur bestimmte Seiten/Apps (z. B. nur Microsoft 365, nur VPN, nur YouTube)?
• Nur dieser Rechner? Oder alle Geräte im Netz (Smartphone, anderer PC)?
• Nur WLAN oder auch LAN? Unterschiedliche Fehlerquellen (Roaming, Funkkanal, VLAN-Zuordnung).
• Nur Namen oder auch IPs? Wenn IPs gehen, Namen nicht: DNS ist wahrscheinlich.
• Seit wann? Nach Update, Routerwechsel, Firewall-Änderung, neuer VPN-Client?

Schritt 2: Physikalische Verbindung und Interface-Zustand prüfen

Das klingt banal, ist aber häufig der schnellste Treffer. Wenn die physikalische oder logische Verbindung nicht stabil ist, sind alle weiteren Tests zweifelhaft.

• LAN: Link-LED am Port, Kabel, Docking-Station, Switchport, Speed/Duplex-Aushandlung.
• WLAN: Verbunden mit dem richtigen SSID? Starke Signalstärke? Captive Portal aktiv?
• Adapterstatus: Ist die Netzwerkschnittstelle deaktiviert oder im Energiesparmodus?
• Mehrere Adapter: VPN-Adapter, virtuelle NICs (Hyper-V/VirtualBox), USB-LAN – Priorität kann kippen.

Schritt 3: IPv4-Konfiguration auf Plausibilität prüfen

Wenn eine IPv4-Adresse vorhanden ist, heißt das nicht automatisch, dass sie korrekt ist. Prüfe die vier Kerndaten: IPv4-Adresse, Subnetzmaske, Default Gateway, DNS-Server.

• IPv4-Adresse: Passt sie zum Netz (z. B. 192.168.1.x im Heimnetz)?
• Subnetzmaske: Typische Werte sind /24 (255.255.255.0) oder in Firmennetzen andere Präfixe.
• Default Gateway: Muss im selben Subnetz liegen und erreichbar sein.
• DNS-Server: Intern vs. extern (Split-DNS) und Erreichbarkeit.

Wichtig: Eine APIPA-Adresse (169.254.0.0/16) deutet häufig darauf hin, dass DHCP nicht erreichbar ist. In dem Fall ist „IPv4 vorhanden“, aber nicht nutzbar.

Schritt 4: Lokale IPv4-Tests in der richtigen Reihenfolge

Eine gute Reihenfolge trennt lokale Probleme von Netzwerkproblemen. Arbeite dich von „ganz nah“ nach „weiter weg“ vor.

• Loopback prüfen: 127.0.0.1 muss erreichbar sein (lokaler TCP/IP-Stack).
• Eigene IP pingen: Prüft, ob das Interface sauber arbeitet.
• Default Gateway pingen: Prüft Layer 2/ARP und die erste Router-Stufe.
• Host im selben Subnetz pingen: Optional, wenn du einen bekannten Peer hast.

Wenn bereits der Ping zum Gateway scheitert, liegt das Problem fast immer lokal oder auf Layer 2: VLAN falsch, WLAN in Gastnetz, ARP-Konflikt, Port-Security, falsche IP/Maskenkombination.

Schritt 5: ARP und „Warum ist das Gateway nicht erreichbar?“

Wenn das Gateway nicht antwortet, ist ARP einer der häufigsten Gründe. Der Client muss die MAC-Adresse des Gateways kennen, um Frames ins lokale Netz zu senden. ARP ist in RFC 826 beschrieben.

• Kein ARP-Eintrag: Client bekommt keine Antwort auf ARP-Requests (VLAN falsch, Switch/Port blockt, Gateway down).
• Wechselnde MAC: Hinweis auf IP-Konflikt oder Proxy-ARP/Fehlkonfiguration.
• Statischer ARP-Eintrag: Kann Fehler „verstecken“ oder verursachen, wenn sich Topologie geändert hat.

Schritt 6: Teste ins Internet – aber richtig

Viele springen sofort zu „Ping google.de“. Das vermischt DNS und IP. Besser ist eine saubere Trennung:

• Test per IP: Ping auf eine bekannte öffentliche IPv4-Adresse (nur als Konnektivitätstest, nicht als Diensttest).
• Test per Name: Erst danach pingst oder öffnest du einen Hostnamen (DNS kommt ins Spiel).
• Test per TCP: Prüfe den realen Dienstport (z. B. HTTPS), weil ICMP oft gefiltert wird.

Ein Ping, der nicht antwortet, beweist nicht, dass „kein Internet“ vorhanden ist. Viele Systeme blockieren ICMP Echo. ICMP ist in RFC 792 definiert.

Schritt 7: DNS als häufigster Grund für „Kein Internet trotz IPv4“

Wenn IP-Verbindungen grundsätzlich funktionieren, Webseiten aber nicht laden, ist DNS sehr häufig der Übeltäter. DNS-Grundlagen sind in RFC 1034 und RFC 1035 dokumentiert.

• Resolver erreichbar? Kann der Client den DNS-Server anpingen oder per TCP/UDP 53 erreichen?
• Falscher DNS-Server: Häufig bei VPN (Split DNS), falscher DHCP-Option oder manueller Konfiguration.
• Captive Portal: Im Gast-WLAN sieht „IPv4 ok“ aus, aber DNS/HTTP wird umgeleitet, bis du dich anmeldest.
• DNS-Cache: Alte oder negative Einträge können Störungen verlängern.

Praxisregel: Wenn ein Ping zur Ziel-IP klappt, aber der Hostname nicht auflösbar ist, ist es sehr wahrscheinlich DNS – nicht das Internet.

Schritt 8: Routing- und Traceroute-Diagnose

Wenn du IP-Adressen außerhalb deines Netzes nicht erreichst, obwohl Gateway ok ist, liegt der Fokus auf Routing. Traceroute nutzt TTL und ICMP „Time Exceeded“. Router-Verhalten wird u. a. in RFC 1812 beschrieben.

• Traceroute endet direkt am Gateway: Gateway hat keine Route, WAN down oder Firewall blockt Weiterleitung.
• Sterne (* * *): Kann Filter oder Rate-Limit sein, nicht zwingend ein Ausfall.
• Hop-Wechsel: Bei ECMP normal; nicht sofort als Fehler werten.
• TTL exceeded: Hinweis auf Routing-Schleife oder falsche Routen.

Schritt 9: Firewall, Proxy und Sicherheitssoftware prüfen

Ein typisches Muster lautet: „Ping geht, aber Browser nicht“ oder „Einige Apps gehen, andere nicht“. Dann ist häufig eine Policy im Spiel.

• Lokale Firewall: Blockiert sie Browser/Ports oder fremde Netzprofile (öffentlich/privat)?
• Unternehmensproxy: Ist ein Proxy konfiguriert, der nicht erreichbar ist? Dann wirkt es wie „kein Internet“.
• DNS-over-HTTPS/Filter: Sicherheitsprodukte können DNS und HTTPS filtern und bei Störungen alles blockieren.
• Policy-Routing/VPN: Traffic wird in den Tunnel gezwungen, aber der Tunnel ist instabil.

Schritt 10: NAT und Provider-Fallen (besonders bei Heim- und KMU-Anschlüssen)

Wenn intern alles funktioniert, aber „nach draußen“ nicht, spielt NAT eine Rolle. Zwei häufige Stolpersteine:

• CGNAT: Du bekommst keine echte öffentliche IPv4, sondern teilst sie mit anderen. Das betrifft vor allem eingehende Verbindungen (Portweiterleitung klappt nicht) und kann Diagnose verwirren.
• Modem/Router-Kaskade (Double NAT): Zwei Geräte machen NAT, was Portweiterleitungen, VPNs oder bestimmte Protokolle erschwert.

Wenn du nachlesen möchtest, wie NAT historisch und konzeptionell eingeordnet wird, ist der IETF-Hintergrund zu NAT-Verhalten und Szenarien oft hilfreich, z. B. über die NAT-Übersichten beim IETF Datatracker.

Schritt 11: MTU- und Fragmentierungsprobleme erkennen

Wenn „kleine Dinge“ funktionieren (DNS, kleine Webseiten), aber größere Downloads, VPN oder bestimmte Web-Anwendungen hängen bleiben, ist MTU ein Top-Kandidat. Path MTU Discovery ist empfindlich, wenn ICMP-Meldungen gefiltert werden. Praktisch gilt: Je mehr Overhead (VPN, PPPoE), desto kleiner die nutzbare Payload.

$\mathrm{nutzbarePayload}=\mathrm{MTU}-\mathrm{Overhead}$

• Symptom: Einige Seiten laden, andere nicht; Upload geht, Download hängt; RDP/VoIP instabil.
• Ursache: ICMP „Fragmentation Needed“ wird geblockt oder MTU im Tunnel falsch.
• Hinweis: Wenn Traceroute/Ping ok wirkt, aber TCP-Verbindungen hängen, ist MTU eine realistische Erklärung.

Schritt 12: Typische Fehlerbilder mit schneller Zuordnung

Die folgenden Muster helfen, schneller die richtige Spur zu wählen:

• IPv4 vorhanden, aber 169.254.x.x: DHCP nicht erreichbar oder DHCP-Server down.
• Gateway nicht erreichbar: VLAN/SSID falsch, ARP/Layer-2-Problem, falsche Maske, Port-Security.
• Gateway erreichbar, externe IP nicht: Routing/WAN/Firewall am Gateway, ISP-Störung, falsche Default Route am Router.
• Externe IP erreichbar, Namen nicht: DNS/Resolver/Proxy/Captive Portal.
• Ping ok, Webseiten nicht: Proxy falsch, Firewall-Regel, TLS-Inspection, DNS-over-HTTPS-Filter, MTU.
• Nur nach VPN-Start kaputt: Split Tunneling falsch, DNS überschrieben, Route-Metrik geändert, Overlap privater Netze.

Schritt 13: VPN-Sonderfall: Wenn „Internet weg“ nur mit Tunnel passiert

VPNs verändern Routen, DNS und oft auch MTU. Deshalb ist das ein eigener Diagnoseblock:

• Route-Metriken: Zwingt der VPN-Client den gesamten Traffic durch den Tunnel (Full Tunnel), obwohl das nicht gewünscht ist?
• Adresskonflikte: Overlap zwischen lokalem Netz (z. B. 192.168.0.0/24) und Unternehmensnetz führt zu „schwarzen Löchern“.
• DNS-Split: Interne Namen müssen intern auflösbar sein, externe sollen weiterhin funktionieren.
• MTU im Tunnel: Besonders bei IPsec/SSL-VPN sind Fragmentierungsprobleme häufig.

Schritt 14: Wenn mehrere Geräte betroffen sind: Router/Firewall/ISP systematisch prüfen

Wenn mehrere Clients gleichzeitig kein Internet haben, ist die Wahrscheinlichkeit hoch, dass die Ursache zentral liegt: Router, Firewall, Modem, Provider oder eine zentrale Policy.

• Ist die WAN-Verbindung up? Linkstatus, PPPoE/DSL/Docsis-Status, IP am WAN-Interface.
• Hat der Router eine Default Route? Ohne Default Route keine Kommunikation ins Internet.
• Funktioniert DNS am Router? Viele Heimrouter agieren als DNS-Proxy; wenn dieser hängt, wirkt alles „offline“.
• Logs prüfen: Auth-Fehler, Lease-Timeout, Interface-Flaps, Paketdrops, Überlast.

Schritt 15: Stabilisierung und Vorbeugung, damit es nicht wieder passiert

Auch ohne „Fazit“ ist es sinnvoll, während der Diagnose präventive Stellschrauben mitzudenken. Viele Probleme kommen wieder, wenn Standards fehlen.

• DHCP sauber halten: Ausreichender Pool, Reservierungen dokumentieren, keine statischen IPs im DHCP-Bereich.
• Adressplan und VLANs dokumentieren: Verhindert falsche Masken/Gateways und erleichtert Fehlersuche.
• DNS resilient gestalten: Mehrere Resolver, klare Split-DNS-Regeln, Monitoring.
• ICMP sinnvoll erlauben: Nicht alles öffnen, aber essenzielle ICMP-Typen für Betrieb und MTU nicht blind blocken.
• Monitoring: Latenz, Paketverlust, WAN-Status, DHCP-Leases, DNS-Antwortzeiten.

Outbound-Links für verlässliche Referenzen

• ICMP für IPv4 (RFC 792)
• Anforderungen an IPv4-Router (RFC 1812)
• ARP: Address Resolution Protocol (RFC 826)
• DHCP für IPv4 (RFC 2131)
• DNS-Konzepte und Architektur (RFC 1034)
• DNS-Protokollspezifikation (RFC 1035)
• IETF Datatracker (Standards und Protokoll-Hintergründe)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.