February 20, 2026

WLAN verbunden, aber kein Internet: OSI-basiertes Debugging

„WLAN verbunden, aber kein Internet“ ist eines der häufigsten Support-Tickets – und gleichzeitig eines der missverständlichsten. Denn eine aktive WLAN-Verbindung bedeutet zunächst nur: Ihr Gerät hat sich auf Funkebene mit einem Access Point (AP) assoziiert und ist eventuell sogar authentifiziert. Ob danach tatsächlich Datenverkehr bis ins Internet durchkommt, hängt von vielen weiteren Bausteinen ab: Verschlüsselung und 802.1X, VLAN-Zuordnung, DHCP, Routing, DNS, Captive Portal, Proxy, Firewall-Regeln, MTU, sowie von der schlichten Funkqualität (Interferenzen, Roaming, Band Steering). Genau deshalb ist ein OSI-basiertes Debugging so wirksam: Statt willkürlich Einstellungen zu ändern, prüfen Sie systematisch pro Schicht, welcher Teil der Kette funktioniert und wo der Datenfluss abbricht. Dieser Leitfaden zeigt ein praxistaugliches Vorgehen für Einsteiger bis Profis: Wie Sie mit klaren Tests (statt Bauchgefühl) herausfinden, ob das Problem auf Layer 1/2 (Funk und WLAN), Layer 3 (IP und Routing), Layer 4 (Transport), oder Layer 7 (DNS/HTTP/Captive Portal) liegt – und wie Sie die Ursache so belegen, dass NOC, Netzwerk- und Security-Teams schnell handeln können.

Table of Contents

OSI-Orientierung: Was „verbunden“ bedeutet und was nicht

Damit die Fehlersuche nicht in Details zerfällt, hilft eine einfache Abgrenzung: „WLAN verbunden“ ist typischerweise ein Erfolg auf Layer 1/2 (Funk + 802.11). „Internet“ setzt funktionierende Schichten darüber voraus: IP-Adresse, Default Gateway, DNS und erfolgreiche TCP/HTTPS-Verbindungen. Wenn Sie diese Ebenen trennen, vermeiden Sie klassische Fehlschlüsse wie „Signal ist gut, also muss Internet gehen“ oder „DHCP ist okay, also muss DNS funktionieren“.

Layer 1 (Physisch): Funk, Kanal, Signalqualität, Interferenz.
Layer 2 (Sicherung): 802.11-Association, WPA2/WPA3, 802.1X/EAP, VLAN/SSID-Zuordnung, L2-Policies.
Layer 3 (Netzwerk): DHCP/Static IP, Subnetz, Gateway, Routing, NAT.
Layer 4 (Transport): TCP/UDP, Timeouts, Retransmits, MTU/MSS-Effekte.
Layer 7 (Anwendung): DNS, HTTP/HTTPS, Captive Portal, Proxy, Zertifikate.

Layer 1: Funkverbindung prüfen, bevor Sie „Netzwerk“ verdächtigen

Wenn WLAN „verbunden“ ist, aber keine Nutzdaten zuverlässig durchkommen, liegt die Ursache häufig bereits im Funk: Paketverlust, extrem niedrige Datenrate oder aggressives Roaming können die Verbindung so instabil machen, dass DHCP, DNS und HTTPS scheitern, obwohl die SSID verbunden bleibt. Hier geht es nicht um „Balken“, sondern um messbare Qualität.

Typische Layer-1-Symptome

Sehr schwankende Signalstärke: Verbindungsabbrüche, erneute Assoziation, stark variierende Latenz.
Hoher Paketverlust/Jitter: Ping zeigt Spikes, Web lädt sporadisch oder hängt.
Interferenz und überfüllte Kanäle: Besonders in 2,4 GHz; viele Clients teilen sich Airtime.
Band Steering/Roaming: Gerät springt zwischen 2,4/5/6 GHz oder zwischen APs, Sessions brechen.

Schnelle Funk-Checks (ohne Spezialtools)

Ping zur lokalen Gateway-IP: Wenn bereits hier hohe Latenz/Verlust entsteht, ist Funk/Layer 2 naheliegend.
SSID wechseln (Test-SSID, andere Band-Policy): Wenn eine zweite SSID stabil funktioniert, ist es meist Policy/VLAN/Portal oder Radio-Design.
Standortwechsel: Direkt neben dem AP testen: Verbessert sich das Verhalten stark, ist Funk die Hauptspur.

Ein Rechenanker für Signalqualität (SNR)

Für die Praxis ist das Signal-Rausch-Verhältnis (SNR) oft aussagekräftiger als RSSI allein. Je höher das SNR, desto stabiler sind Modulation und Datenrate.

$SNR = Signal - Rauschen$

Wenn SNR niedrig ist, kann das Gerät zwar verbunden bleiben, aber jede höhere Protokollebene leidet unter Retransmits und Timeouts.

Layer 2: „Verbunden“ heißt nicht „autorisiert“ oder „im richtigen VLAN“

Viele WLAN-Fehler liegen in Layer 2, weil hier moderne Unternehmensfeatures wirken: WPA2/WPA3-Enterprise (802.1X), dynamische VLAN-Zuordnung, ACLs pro User/Role, Client Isolation, DHCP Snooping/DAI (im kabelgebundenen Teil), sowie SSID-spezifische Policies. Ein Client kann „verbunden“ anzeigen, aber dennoch in einem Quarantäne-VLAN hängen oder nur bis zum Captive Portal durchgelassen werden.

SSID, Authentifizierung und Rollen prüfen

WPA2/WPA3-Personal: Passwort falsch ist meist „keine Verbindung“, aber bei Key-Caching können Übergangseffekte auftreten.
802.1X/EAP: Authentifizierung kann scheinbar „erfolgreich“ sein, aber die Policy weist ein restriktives Role/VLAN zu.
NAC/MDM-Policy: Nicht compliant = Internet blockiert oder nur Remediation-Portal.

Client Isolation und L2-Blockaden

AP-/SSID-Isolation: Clients können sich nicht gegenseitig erreichen; je nach Design kann auch der Weg zum lokalen Gateway betroffen sein.
Multicast/Broadcast-Filter: DHCP kann scheitern, wenn Broadcasts gefiltert werden.
Fehlerhafte VLAN-Zuordnung: Der Client erhält IP aus falschem Subnetz oder keine IP (VLAN-Mismatch entlang AP–Switch–Controller).

Für Hintergrund zu IEEE-Standards rund um 802.11 und 802.1X ist der Anchor-Text IEEE Standards (802.11 / 802.1X) als Einstieg hilfreich.

Layer 3: IP-Adresse, Gateway und Routing – die häufigste echte Ursache

Wenn WLAN verbunden ist, aber „kein Internet“ gemeldet wird, ist Layer 3 oft der erste harte Prüfpunkt. Ohne korrekte IP-Konfiguration ist jede weitere Analyse Zeitverschwendung. Der wichtigste Grundsatz: Prüfen Sie zuerst, ob der Client eine gültige IP, Subnetzmaske und ein Default Gateway hat – und ob das Gateway erreichbar ist.

DHCP: Bekommen Sie überhaupt eine sinnvolle Adresse?

APIPA/Link-Local (z. B. 169.254.x.x): DHCP-Lease fehlt; Ursache häufig VLAN/Relay/Policy.
Falsches Subnetz: Client hängt im falschen VLAN oder erhält einen Lease aus einem falschen Scope.
IP vorhanden, aber ohne Gateway/DNS: DHCP-Optionen fehlerhaft oder Policy setzt Optionen falsch.

Eine belastbare Referenz zu DHCP liefert der Anchor-Text RFC 2131 (DHCP).

Gateway-Erreichbarkeit: Der schnellste Routing-Abgleich

Ping zum Default Gateway: Wenn das nicht klappt, ist „Internet“ sekundär; erst L2/L3 im lokalen Segment lösen.
ARP-Status: Wenn der Client die MAC des Gateways nicht auflösen kann, wirkt das wie Routing, ist aber ein L2/ARP-Thema.
Nur Gateway erreichbar, aber nichts darüber hinaus: Routing/NAT/Firewall am Edge oder VRF-Fehler.

VRF, Segmentierung und Policy-Routing im Unternehmensumfeld

In modernen Netzen führt „WLAN“ nicht automatisch ins gleiche Routing wie „LAN“. Häufig existieren getrennte VRFs (Guest, Corp, IoT), unterschiedliche NAT-Regeln oder ein SD-WAN-Exit. Wenn der falsche Policy-Pfad greift, ist der Client zwar im Netz, aber ohne Internetzugriff.

Guest-VLAN ohne Internet-Freigabe: Absichtlich restriktiv, aber oft falsch dokumentiert.
Corporate-VLAN mit Proxy-Pflicht: Ohne Proxy-Konfiguration wirkt es wie „kein Internet“.
Routing-Loops oder Blackholes: Selten, aber mit Traceroute/MTR belegbar.

Layer 4: TCP/UDP, Timeouts und MTU – wenn „IP okay“ trotzdem nicht reicht

Viele Tickets bleiben hängen, weil der Client eine IP hat und das Gateway pingbar ist – trotzdem lädt keine Website. Dann lohnt sich der Blick auf Layer 4: Kommen TCP-Verbindungen zustande? Gibt es Retransmits? Werden bestimmte Ports geblockt? Und sehr wichtig: Gibt es MTU-/Fragmentierungsprobleme, die unter WLAN und Tunneln besonders häufig sind?

Port-Blockaden und Security-Policies

DNS geblockt: Internet wirkt „tot“, obwohl Routing funktioniert.
TCP/443 eingeschränkt: Viele Apps sind praktisch „offline“, weil HTTPS der Standard ist.
UDP/443 (QUIC) geblockt: Moderne Browser wechseln, Symptome wirken inkonsistent.

Eine zuverlässige Portreferenz bietet der Anchor-Text IANA Port Registry.

MTU/PMTUD: „Small works, large fails“ im WLAN-Kontext

WLAN selbst ist nicht automatisch „MTU-kritisch“, aber WLAN-Clients hängen oft an VPNs, Tunneln oder Captive-Portal-Ketten, die Overhead erzeugen. Wenn PMTUD nicht funktioniert (z. B. weil ICMP gefiltert wird), gehen kleine Pakete durch, größere HTTPS-Responses hängen. Das wirkt wie „WLAN ohne Internet“, ist aber ein MTU-Blackhole.

Indiz: Ping mit Standardgröße geht, aber große Transfers hängen.
Indiz: TCP-Handshake klappt, danach Retransmits, langsame oder abbrechende Downloads.
Indiz: Besonders häufig bei VPN/SD-WAN, PPPoE, Cloud-Edges.

Layer 7: DNS, Captive Portal, Proxy – die häufigsten „Internet wirkt kaputt“-Gründe

Viele Nutzer sagen „kein Internet“, meinen aber: „Websites laden nicht“. Das ist oft Layer 7, vor allem DNS und Captive Portal. Ein WLAN kann IP-Konnektivität haben, aber Anwendungen scheitern, weil Namen nicht auflösbar sind oder weil ein Portal zunächst Authentifizierung verlangt.

DNS: Wenn alles scheitert, obwohl IP-Routing funktioniert

Symptom: Ping zu IP-Adressen funktioniert, aber nicht zu Domains.
Symptom: Nur interne Namen funktionieren, externe nicht (oder umgekehrt).
Ursachen: Falsche DNS-Server per DHCP, DNS-Filter/Policy, DoH/DoT-Interaktion, Split-DNS.

Captive Portal und Walled Garden

Guest-WLANs nutzen häufig ein Captive Portal. Dann ist „verbunden, aber kein Internet“ oft korrekt: Der Client bekommt IP, aber nur Traffic zu Portal/Authentifizierung ist erlaubt. Ohne Browser-Login bleibt der Rest blockiert oder wird umgeleitet.

Indiz: Nur bestimmte Ziele erreichbar (Portal-Domain, walled-garden IPs), alles andere time-outet.
Indiz: HTTP wird umgeleitet, HTTPS bleibt hängen (weil TLS nicht transparent umleitbar ist).
Indiz: Das Betriebssystem zeigt „Anmelden erforderlich“ oder öffnet automatisch eine Portal-Seite.

Proxy- und Zertifikatsthemen

Enterprise Proxy erforderlich: Ohne PAC/WPAD oder manuelle Proxy-Konfiguration wirken Browser offline.
TLS-Inspection: Ohne korrektes Root-CA-Profil schlagen TLS-Verbindungen fehl, obwohl Routing und DNS okay sind.
Time/Certificate: Falsche Systemzeit kann HTTPS brechen und sieht aus wie „kein Internet“.

Beweisorientierte Tests: Eine kurze, belastbare Testmatrix

Um OSI-basiert zu debuggen, brauchen Sie Tests, die jeweils eine klare Ebene bestätigen oder widerlegen. Die folgende Matrix ist bewusst so gewählt, dass jeder Test ein eindeutiges Signal liefert.

Layer 1/2: Link/SSID verbunden, Roaming-Events, Paketverlust zum Gateway.
Layer 3 (IP): IP/Subnetz/Gateway/DNS vorhanden und plausibel; Gateway erreichbar.
Layer 3 (Routing): Erreichbarkeit einer externen IP (ohne DNS), z. B. ein öffentlicher Resolver.
Layer 7 (DNS): Namensauflösung für bekannte Domains; Vergleich interner vs. externer Namen.
Layer 4/7 (HTTPS): TCP/443 erreichbar; HTTP/HTTPS-Verhalten zeigt Portal/Proxy-Hinweise.

Praktisches OSI-Debugging: Schrittfolge, die im NOC funktioniert

Diese Schrittfolge ist dafür gedacht, den Fehler schnell einzugrenzen, ohne gleichzeitig mehrere Variablen zu ändern. Jeder Schritt hat eine klare „Wenn-dann“-Logik.

Schritt 1: Funk und Stabilität prüfen

Ist die Verbindung stabil oder flapped sie (Roaming, Disconnect/Reconnect)?
Gibt es auffällige Latenz/Verluste bereits zum lokalen Gateway?

Schritt 2: IP-Konfiguration verifizieren

IP-Adresse, Subnetzmaske, Default Gateway, DNS-Server prüfen.
Wenn keine IP: DHCP/VLAN/802.1X-Policy priorisieren.

Schritt 3: Local Gateway und ARP als harte Grenze

Gateway pingbar? Wenn nein: VLAN-Mismatch, Client Isolation, ARP/DAI/Port-Security oder Funkverlust.
Wenn ja: Weiter zu Routing/NAT/Firewall.

Schritt 4: Internet ohne DNS testen

Erreichbarkeit einer externen IP testen (reiner Routing-/NAT-Check).
Wenn das geht, aber Domains nicht: DNS-Problem (Option 6, Policy, Filter).

Schritt 5: Captive Portal/Proxy identifizieren

HTTP zeigt Redirect? HTTPS hängt? Das ist ein klassisches Portal-Muster.
Unternehmensgeräte: Proxy-Pflicht oder TLS-Inspection als Ursache prüfen.

Paketanalyse als Schiedsrichter: Wann ein Capture die schnellste Lösung ist

Wenn sich Teams uneinig sind oder das Problem intermittierend ist, liefert ein Mitschnitt die besten Beweise: DHCP-DORA, DNS-Queries, TCP-Handshakes, Retransmits, Portal-Redirects. Wichtig ist, gezielt zu capturen: auf dem Client, am WLAN-Controller/AP (wenn möglich) oder am Gateway/SVI. Für Einstieg und Filter ist der Anchor-Text Wireshark-Dokumentation praxisnah.

DHCP fehlt: Discover ohne Offer → VLAN/Relay/Policy.
DNS fehlt: Queries gehen raus, keine Replies → DNS-Policy oder falscher Resolver.
TCP scheitert: SYN ohne SYN-ACK → Firewall/Policy; SYN/SYN-ACK ok, dann Retransmits → MTU/Fragmentierung oder Funkverlust.
Portal: HTTP-Redirects und blockierte HTTPS-Verbindungen sichtbar.

Checkliste: „WLAN verbunden, aber kein Internet“ sauber dokumentieren

Eine kurze, beweisorientierte Dokumentation verhindert Ping-Pong zwischen Teams. Halten Sie fest, was auf welcher OSI-Schicht funktioniert und wo es bricht.

SSID/Band: Name, 2,4/5/6 GHz, Zeitpunkt, ob Roaming auffällig ist.
IP-Daten: IP/Subnetz/Gateway/DNS (inklusive ob DHCP oder statisch).
Gateway-Test: Ping/ARP-Ergebnis zum Default Gateway.
Internet-Test ohne DNS: Erreichbarkeit einer externen IP.
DNS-Test: Auflösung einer Domain; Unterschiede intern/extern.
HTTPS/Portal/Proxy: Beobachtung zu Redirects, Zertifikaten, Proxy-Pflicht.
MTU-Indizien: „Small works, large fails“, VPN aktiv, Tunnelpfad.

Outbound-Links für belastbare Grundlagen

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.