„No Internet“ mit dem OSI-Modell troubleshooten (vollständige Checkliste)

„No Internet“ ist eine der häufigsten und zugleich unspezifischsten Störungsmeldungen – im Büro, im Homeoffice oder im NOC. Genau deshalb lohnt sich ein strukturiertes Vorgehen: Wenn Sie „No Internet“ mit dem OSI-Modell troubleshooten, zerlegen Sie das Problem in überprüfbare Teilfragen, statt im Kreis zu testen. Häufig steckt nicht „das Internet“ dahinter, sondern eine lokale Ursache: ein instabiler Link, ein falsches VLAN, ein fehlendes Default Gateway, ein DNS-Problem oder eine Firewall-Regel. Diese Checkliste führt Sie Schicht für Schicht durch ein vollständiges Troubleshooting – so, dass Sie nach jedem Schritt wissen, ob Sie tiefer (Layer 1–2), logisch weiter (Layer 3–4) oder anwendungsnah (Layer 5–7) suchen müssen. Sie erhalten konkrete Prüfungen, typische Fehlerbilder, schnelle Gegenproben und Dokumentationspunkte, mit denen sich ein „No Internet“-Ticket sauber lösen oder belastbar eskalieren lässt. Das Ziel ist nicht, jeden Spezialfall abzudecken, sondern in der Praxis schnell von Symptomen zu Fakten zu kommen – ohne blinden Aktionismus und ohne unnötige Wiederholungen.

Vorbereitung: Scope, Symptome und zwei Minuten, die später Stunden sparen

Bevor Sie in die OSI-Schichten springen, klären Sie drei Dinge. Erstens: Wer ist betroffen (ein Gerät, eine Nutzergruppe, ein Standort, alle)? Zweitens: Was genau bedeutet „No Internet“ (keine WLAN-Verbindung, kein Link am Kabel, keine IP-Adresse, keine Webseiten, nur bestimmte Dienste)? Drittens: Seit wann besteht das Problem und gab es Änderungen (Firmware-Update, neue Firewall-Regel, Provider-Störung, Umbau im Patchfeld)? Diese Vorarbeit verhindert, dass Sie auf dem falschen Layer suchen.

• Betroffenheit eingrenzen: Einzelner Client vs. gesamtes VLAN/Standort vs. alle Netze.
• Symptom präzisieren: „Keine IP“, „DNS geht nicht“, „Ping auf Gateway geht nicht“, „nur HTTPS kaputt“.
• Change-Check: Letzte Änderungen an Switch, Firewall, DHCP, WLAN, Provider, Zertifikaten.
• Gegenprobe: Zweites Gerät im gleichen Netz testen (Laptop/Smartphone) oder anderes Netz (Hotspot).

Quick-Triage: Drei Tests, die die Richtung vorgeben

Diese drei Checks entscheiden meist, ob Sie mit Layer 1–2 oder Layer 3–7 starten. Führen Sie sie möglichst auf dem betroffenen Gerät aus:

• IP-Status prüfen: Hat der Client eine gültige IPv4/IPv6-Adresse, Subnetz/Prefix und ein Default Gateway?
• Gateway-Test: Ping zum Default Gateway (oder Nachbarprüfung via ARP/NDP).
• DNS vs. IP trennen: Ping zu einer bekannten IP (z. B. 1.1.1.1) und Namensauflösung testen (z. B. www.example.com).

Wenn keine IP vorhanden ist, sind Layer 2/3 (DHCP, VLAN, WLAN) sehr wahrscheinlich. Wenn Gateway nicht erreichbar ist, suchen Sie primär in Layer 1–2 (Link/VLAN) oder Layer 3 (Gateway-Interface down, falsches Subnetz). Wenn IP-Ping funktioniert, aber Namen nicht, ist DNS (Layer 7) vorn.

Layer 1: Physische Verbindung – Link, Signal, Strom

Beim „No Internet“-Fehlerbild ist Layer 1 überraschend häufig die Ursache: wackelige RJ45-Stecker, defekte Patchkabel, falsch gesteckte Ports, beschädigte LWL-Optiken, schwache WLAN-Signalqualität oder Strom-/PoE-Probleme. Layer 1 ist der schnellste Ausschluss, weil Sie ihn direkt messen können.

Checkliste Layer 1 (Kabel/LWL/WLAN)

• Link-Status: Ist der Interface-Link up? Leuchtet die Port-LED stabil oder flapped sie?
• Kabeltest/Gegenprobe: Anderes Patchkabel verwenden, anderen Switchport testen (wenn erlaubt).
• Speed/Duplex: Autonegotiation-Status prüfen, Speed/Duplex-Mismatch ausschließen.
• Error-Counter: CRC/FCS-Errors, Input/Output Errors, Drops, Link Resets prüfen.
• LWL-Optiken: Rx/Tx-Power (DOM/DDM) im Toleranzbereich? Stecker sauber?
• WLAN-Basis: RSSI/SNR prüfen, Kanalüberlastung, Roaming-Events, Client-Isolation.

Typische Layer-1-Symptome bei „No Internet“

• Link wechselt zwischen Up/Down, besonders bei Bewegung am Kabel
• Viele CRC-Fehler, die mit Last zunehmen
• WLAN verbunden, aber sehr niedrige Datenrate oder häufige Reconnects

Layer 2: Data Link – VLAN, SSID-Zuordnung, MAC und Switching

Wenn der physische Link stabil ist, liegt „No Internet“ oft an Layer 2: falsches VLAN am Access-Port, Trunk lässt VLAN nicht durch, WLAN-SSID ist auf falsches VLAN gemappt, STP blockt, Port-Security sperrt oder ein Loop verursacht Broadcast-Stürme. In Unternehmensnetzen ist Layer 2 der klassische Bereich nach Changes.

Checkliste Layer 2 (Switching/WLAN-Bridge)

• VLAN am Client-Port: Access-VLAN korrekt? Bei Voice/Data getrennt: stimmt die Zuordnung?
• Trunk-Prüfung: Ist das VLAN auf allen relevanten Trunks erlaubt? Native VLAN konsistent?
• MAC-Learning: Wird die Client-MAC am erwarteten Port gelernt? Gibt es MAC-Flapping?
• STP-Status: Port in Forwarding? Topology Changes auffällig hoch?
• Port-Security/Err-Disable: Wurde der Port wegen Policy gesperrt (z. B. zu viele MACs)?
• WLAN-Mapping: SSID korrekt auf VLAN gemappt? Captive Portal/Guest-Isolation aktiv?

Schnelle Gegenproben auf Layer 2

• Testgerät am gleichen Port anschließen (wenn möglich) oder am Nachbarport im selben Raum
• Client in ein anderes VLAN/SSID setzen (z. B. Guest vs. Corporate) und vergleichen
• Broadcast-/Multicast-Indikatoren prüfen (ungewöhnliche Last, Paketstürme)

Für Paketanalysen und Filter, die Ihnen bei DHCP, ARP oder STP helfen, ist der Einstieg über den Anchor-Text Wireshark-Dokumentation sinnvoll.

Layer 3: Network – IP-Adressierung, Gateway, Routing, NAT

Layer 3 beantwortet die Kernfrage: Kann der Client sein Netz verlassen? „No Internet“ entsteht hier durch fehlendes oder falsches Default Gateway, falsche Subnetzmaske/Prefix, IP-Konflikte, fehlerhafte statische Routen, VRF-Missmatch oder Down-States am Gateway-Interface. In vielen Umgebungen kommt NAT hinzu: Der Client hat zwar intern Connectivity, aber nach außen scheitert die Übersetzung oder die Default Route.

Checkliste Layer 3 (Client-seitig)

• IP-Adresse prüfen: Ist die Adresse im erwarteten Subnetz? Keine APIPA (169.254.0.0/16) bei IPv4?
• Subnetz/Prefix: Stimmt die Subnetzmaske bzw. der IPv6-Prefix? Falsche Maske erzeugt „Gateway unerreichbar“.
• Default Gateway: Ist ein Gateway gesetzt? Passt es zum Subnetz?
• ARP/NDP: Wird die MAC des Gateways aufgelöst? Bei IPv6: Nachbarn (NDP) vorhanden?
• IP-Konflikt: Hinweise auf Duplicate Address Detection (IPv6) oder sporadische Ausfälle (IPv4).

Checkliste Layer 3 (Netzwerk-seitig)

• Gateway-Interface: Ist das SVI/Interface up? Sind Fehler oder Flaps sichtbar?
• Routing-Tabelle: Existiert eine Default Route (0.0.0.0/0 bzw. ::/0) oder eine Route zum Upstream?
• Upstream-Erreichbarkeit: Ping/Traceroute vom Gateway zu externen IPs (nicht nur Namen).
• VRF/Segmentierung: Ist der Client im richtigen VRF/Segment? Ist das Internet-Gateway dort geroutet?
• NAT (falls vorhanden): Gibt es Übersetzungen? Sind NAT-Pools erschöpft? Passt die Policy?

Traceroute richtig nutzen, ohne falsche Schlüsse

Traceroute zeigt Ihnen die Stelle, an der Antworten ausbleiben. Das ist nicht automatisch „dort ist es kaputt“, aber es ist ein belastbarer Hinweis. Nutzen Sie je nach Umgebung auch TCP-basierte Traceroutes (Port 443), wenn ICMP/UDP gefiltert wird. Für Hintergrundwissen zu Internet-Standards und Routing-Konzepten ist der Anchor-Text RFC-Editor (Netzwerkstandards) eine verlässliche Quelle.

Layer 4: Transport – Ports, Firewalls, Session-States

Wenn IP-Routing grundsätzlich funktioniert, bleibt „No Internet“ häufig als Layer-4-Problem übrig: Ports werden gefiltert, Stateful Firewalls verwerfen Rückverkehr, NAT-States laufen aus, oder es gibt asymmetrisches Routing. Aus Anwendersicht fühlt sich das wie „Internet tot“ an, obwohl Ping zu externen IPs funktionieren kann.

Checkliste Layer 4 (TCP/UDP)

• Porttest zu 443: Funktioniert ein TCP-Handshake zu einem externen Ziel (z. B. HTTPS)?
• Vergleichsport 80/443: Wenn 80 geht, 443 nicht: TLS/Inspection/Policy prüfen.
• Firewall-Logs: Drops/Denies für die Client-IP? Richtige Zone/Policy?
• State/NAT-Tabellen: Sind Sessions vorhanden? Gibt es ungewöhnlich viele half-open Sessions?
• Asymmetrie: Kommt der Rückweg über denselben Firewall-Cluster? Hinweise: sporadische Timeouts.

Typische Layer-4-Fehlerbilder bei „No Internet“

• Webseiten laden nicht, aber DNS-Auflösung klappt und Ping zu IP funktioniert
• Nur einzelne Anwendungen betroffen (z. B. Teams/Zoom), weil spezielle Ports oder UDP benötigt werden
• Funktioniert kurz nach Reconnect, bricht dann ab (Session-Timeout, Inspection)

Layer 5–6: Session und Darstellung – TLS, Proxies, Loadbalancer, Inspection

In der Praxis äußert sich ein Layer-5/6-Problem oft so: „Ich bin verbunden, aber nichts geht.“ Der TCP-Port ist offen, doch der TLS-Handshake schlägt fehl, ein Proxy verlangt Authentifizierung, oder SSL-Inspection verursacht Zertifikatsfehler. Auch falsche Systemzeit kann hier überraschend häufig „No Internet“-Symptome auslösen, weil Zertifikate als ungültig gelten.

Checkliste für TLS/Proxy/Inspection

• TLS-Handshake prüfen: Zertifikatskette, Ablaufdatum, SNI, unterstützte Cipher Suites.
• Proxy-Konfiguration: Ist ein Proxy gesetzt (PAC/WPAD/manuell)? Erreichbar? Auth erforderlich?
• SSL-Inspection: Ist das Inspection-Zertifikat auf dem Client vertrauenswürdig installiert?
• Zeit/NTP: Stimmt die Systemzeit? Große Abweichungen verursachen HTTPS-Fehler.

Wenn Sie Zeitprobleme ausschließen möchten, ist der Anchor-Text NTP-Dokumentation hilfreich, um typische Ursachen und Prüfpfade zu verstehen.

Layer 7: Anwendung – DNS, HTTP, Captive Portals und „Internet geht nicht“ trotz Connectivity

Layer 7 ist der Bereich, in dem „No Internet“ häufig als Sammelbegriff auftaucht: DNS-Resolver antwortet nicht, Captive Portal blockiert bis zum Login, ein CDN liefert regional falsche Antworten, oder eine Sicherheitslösung blockt Kategorien. Entscheidend ist, dass Sie auf Layer 7 immer zuerst DNS vs. IP trennen und dann messbare Anwendungsindikatoren erheben (Statuscodes, Response-Zeiten, Fehlermeldungen).

Checkliste DNS (häufigster Layer-7-Auslöser)

• Resolver erreichbar: Kann der Client den konfigurierten DNS-Server erreichen?
• Auflösung testen: A/AAAA/CNAME, korrekte Antworten, keine NXDOMAIN-Flut.
• Split-DNS: Interne Namen vs. externe Namen – falscher Resolver kann „Internet“ wirken lassen.
• Cache-Effekte: Client-Cache, Browser-Cache, Proxy-Cache berücksichtigen.

Checkliste HTTP/HTTPS (Web als Indikator, nicht als Beweis)

• Statuscodes: 2xx/3xx vs. 4xx (Client/Policy) vs. 5xx (Server/Upstream).
• Captive Portal: Wird HTTP umgeleitet? Blockiert HTTPS bis zur Anmeldung?
• Security-Filter: Webfilter/WAF/EDR blockiert? Kategorien oder Regionen betroffen?
• Vergleichstest: Funktioniert dieselbe URL in einem anderen Netz (Hotspot) oder auf einem anderen Gerät?

Für unabhängige Messungen aus vielen Netzen (z. B. DNS- und Reachability-Checks) ist der Anchor-Text RIPE Atlas Messplattform nützlich.

Vollständige OSI-Checkliste für „No Internet“ (zum Abhaken im Ticket)

Diese Liste ist so aufgebaut, dass jeder Punkt eine Entscheidung erzwingt: bestätigt, ausgeschlossen oder weiterer Test nötig. Sie können sie direkt als internes Runbook übernehmen.

Layer 1 – Physisch

• Link up und stabil (keine Flaps)
• Anderes Kabel/Port getestet (wenn möglich)
• Speed/Duplex plausibel, kein Mismatch
• Error-Counter unauffällig (CRC/FCS/Drops)
• Bei LWL: Rx/Tx-Power in Toleranz
• Bei WLAN: ausreichender RSSI/SNR, keine dauernden Reconnects

Layer 2 – Switching/Bridging

• Client im richtigen VLAN/SSID
• VLAN über alle Trunks bis zum Gateway verfügbar
• MAC wird am erwarteten Port gelernt, kein MAC-Flapping
• STP-Port in Forwarding, keine auffälligen Topology-Changes
• Keine Port-Security-/Policy-Sperre (Err-Disabled, Quarantäne)

Layer 3 – IP/Routing/NAT

• Client hat gültige IP/Prefix, keine APIPA, keine Duplikate
• Default Gateway gesetzt und passend zum Subnetz
• Gateway per Ping/ARP/NDP erreichbar
• Routing vorhanden (Default Route/Upstream), VRF korrekt
• Upstream-Erreichbarkeit vom Gateway bestätigt (IP-basierte Tests)
• NAT (falls genutzt) arbeitet: Translation/Pool/Policy plausibel

Layer 4 – Ports/Firewalls/Sessions

• TCP 443 Handshake möglich (Client → extern)
• Firewall-Logs prüfen: keine Drops/Denies für Client/Segment
• State/NAT-Tabellen nicht erschöpft, keine massiven half-open Sessions
• Asymmetrisches Routing ausgeschlossen oder erklärt

Layer 5–6 – TLS/Proxy/Inspection

• TLS-Handshake funktioniert (Zertifikate/SNI/Cipher ok)
• Proxy korrekt konfiguriert, erreichbar, Auth ok
• SSL-Inspection-Zertifikat vorhanden und vertrauenswürdig (falls aktiv)
• Systemzeit/NTP plausibel (keine große Drift)

Layer 7 – DNS/HTTP/Captive Portal

• DNS-Auflösung klappt (intern/extern korrekt), Resolver erreichbar
• HTTP/HTTPS liefert erwartete Statuscodes und Inhalte
• Captive Portal erkannt/abgeschlossen (falls vorhanden)
• Sicherheitsfilter (Webfilter/EDR/WAF) als Ursache bestätigt oder ausgeschlossen

Messwerte und Belege: So dokumentieren Sie „No Internet“ professionell

Gerade bei Eskalationen zählt, dass Sie nicht nur „geht nicht“ melden, sondern einen reproduzierbaren Nachweis liefern. Notieren Sie immer Zeitpunkt, betroffene IP/MAC, VLAN/SSID, Gateway, Testergebnis und die exakte Fehlermeldung (z. B. TLS-Alert, DNS-Response). Das spart Rückfragen und beschleunigt die Zuordnung.

• Identität: Client-IP, MAC, Hostname, Nutzer, Standort, SSID/VLAN, Switchport.
• Baseline: Seit wann, seit welchem Change, Vergleich mit funktionierendem Gerät.
• Layer-Belege: Link/Errors, MAC-Table, ARP/NDP, Routing-Auszug, Firewall-Log-Snippet, DNS-Antwort.
• Entscheidung: Welche Hypothese wurde bestätigt oder verworfen?

Häufige „No Internet“-Ursachen nach Umgebung (damit Sie schneller priorisieren)

Je nach Kontext sind bestimmte Ursachen wahrscheinlicher. Das ist kein Ersatz fürs OSI-Modell, aber eine gute Priorisierungshilfe.

Homeoffice und kleine Büros

• Provider-Störung oder Router/Modem hängt (Neustart, Status-LEDs, Sync)
• WLAN-Signal schwach, Kanal überlastet, Mesh-Knoten instabil
• DNS-Probleme durch Router-Resolver oder fehlerhafte Kindersicherung/Webfilter

Unternehmensnetz und NOC

• VLAN/Trunk-Änderung nach Wartung, falsches Mapping von SSID zu VLAN
• DHCP-Scope voll oder Relay/Helper falsch, IP-Konflikte
• Firewall-Policy/Zone geändert, NAT-Policy greift nicht
• Proxy/SSL-Inspection verursacht TLS-Fehler, Zertifikate abgelaufen

Wenn Sie rechnen müssen: Paketverlust sauber ausdrücken (optional für Tickets)

Wenn Nutzer „Internet bricht ständig ab“ melden, ist Paketverlust ein häufiger Indikator. Für ein Ticket ist es hilfreich, eine Loss-Rate nachvollziehbar zu dokumentieren, statt nur „viel Loss“ zu schreiben.

$\mathrm{LossRate}=\frac{\mathrm{verlorenePakete}}{\mathrm{gesendetePakete}}\times 100\%$

Wichtig für die Interpretation: Ein Test mit ICMP kann Loss anzeigen, obwohl Anwendungsdaten stabil laufen, wenn ICMP unterwegs niedriger priorisiert wird. Deshalb sollten Sie Loss idealerweise mit mindestens zwei Perspektiven prüfen (z. B. ICMP und ein TCP-basierter Test auf Port 443) und die Ergebnisse dem passenden OSI-Layer zuordnen.

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.