Gast-WLAN Probleme: VLAN/Firewall/DNS Checks für schnelle Lösung

Gast-WLAN Probleme sind in Unternehmen, Praxen, Hotels und Coworking-Spaces ein Dauerbrenner: Gäste verbinden sich, sehen „WLAN verbunden“, aber Webseiten laden nicht, Apps bleiben hängen oder nur manche Ziele funktionieren. Für IT-Teams ist das oft ärgerlich, weil das Gastnetz bewusst eingeschränkt ist – und genau diese Einschränkungen (VLAN-Trennung, Firewall-Regeln, DNS-Policy, Captive Portal) die häufigsten Fehlerquellen sind. Dazu kommt: Gäste nutzen eine enorme Vielfalt an Geräten, Betriebssystemen und Browsern. Ein iPhone verhält sich anders als ein Android-Tablet, ein Windows-Laptop anders als ein Firmen-Mac mit VPN-Client. Wenn dann noch Provider-Filter, Proxy-Policies oder DNS over HTTPS (DoH) ins Spiel kommen, entsteht schnell ein Fehlerbild, das „wie WLAN“ aussieht, in Wahrheit aber ein Routing-, VLAN- oder DNS-Problem ist. Dieser Artikel liefert einen praxiserprobten Troubleshooting-Leitfaden, der auf schnelle Eingrenzung ausgelegt ist: Sie prüfen zuerst die VLAN-Kette (SSID → AP → Switch → Gateway), dann die Firewall/NAT-Weiterleitung und anschließend DNS und Captive-Portal-Mechanismen. So finden Sie in Minuten heraus, ob der Fehler im Funk, in der Segmentierung oder in der Security-Policy steckt – und können ihn zielgerichtet beheben.

Grundprinzip Gast-WLAN: Warum es anders funktioniert als „normales“ WLAN

Ein Gast-WLAN ist selten „einfach nur ein weiteres WLAN“. Es ist meist ein eigenes Netzwerksegment, das absichtlich von internen Netzen getrennt ist. Typischer Aufbau:

• Eigene SSID (z. B. „Guest“), häufig mit Captive Portal oder Voucher-Login
• Eigene VLAN-ID bzw. eigenes Segment/VRF, getrennt vom Corporate-LAN
• Firewall-Regeln für Isolation (kein Zugriff auf interne Subnetze, ggf. Client Isolation)
• NAT Richtung Internet (DIA oder über zentrale Firewall)
• Eigene DNS-Policy (z. B. externer Resolver, Filter, Walled Garden fürs Portal)

Genau diese Komponenten sind die Prüfstationen im Troubleshooting. Der größte Zeitgewinn entsteht, wenn Sie das Problem nicht „im WLAN“ suchen, sondern entlang dieser Kette.

Typische Symptome und was sie meist bedeuten

Gast-WLAN-Probleme sind oft selektiv. Nutzen Sie die Symptome als Fingerzeig, aber verifizieren Sie sie mit Tests.

• Verbunden, aber keine IP (169.254.x.x): DHCP/Relay/VLAN-Zuordnung defekt
• IP vorhanden, Gateway nicht pingbar: VLAN/Trunk/SVI down, falsche Portprofile, L2-Problem
• Gateway pingbar, aber Internet nicht: NAT/Firewall/Upstream-Routing/Policy
• Nur Namen gehen nicht, IP schon: DNS-Problem (Resolver, Filter, DoH-Interaktion)
• Portal-Seite lädt nicht: Walled Garden zu restriktiv, HTTPS/HSTS, DNS/Redirect blockiert
• Nur manche Webseiten nicht: DNS-Filter, Proxy, Kategorie-Policy, MTU/PMTUD, CDN/Geo

Der Schnellstart: Drei Checks, die in 60 Sekunden die Richtung zeigen

Wenn Sie einen Incident schnell triagieren müssen, reichen oft drei Basis-Checks, um den Fehlerbereich einzugrenzen.

• Check 1: Hat der Client eine gültige IP, Maske, Gateway und DNS?
• Check 2: Ist das Default Gateway erreichbar (Ping/ARP)?
• Check 3: Funktioniert eine externe IP (z. B. 1.1.1.1) – unabhängig von DNS?

Wenn Check 1 scheitert: DHCP/VLAN. Wenn Check 2 scheitert: VLAN/Trunk/SVI. Wenn Check 2 klappt, aber Check 3 scheitert: Firewall/NAT/Upstream. Wenn Check 3 klappt, aber Namen nicht: DNS.

VLAN-Checks: Der häufigste Fehlerbereich im Gast-WLAN

In der Praxis sind VLAN-Fehler die häufigste Ursache, weil die Gast-SSID meist ein eigenes VLAN nutzt und diese Zuordnung an mehreren Stellen korrekt sein muss. Denken Sie „SSID → AP → Switchport → Trunk → Gateway/SVI“.

SSID zu VLAN Mapping am WLAN-System

• Ist die SSID wirklich auf das korrekte Gast-VLAN gemappt?
• Gibt es dynamische VLAN-Zuweisungen (RADIUS/NAC), die Gäste in ein anderes VLAN schieben?
• Wird bei Captive Portal ein Rollenwechsel ausgelöst (Quarantäne-VLAN → Internet-VLAN)?

Switchport und Trunk: Allowed VLANs und Tagging

• Ist das Gast-VLAN auf dem AP-Uplink/Port-Channel erlaubt?
• Stimmt Native VLAN/Tagging (kein Native-VLAN-Mismatch)?
• Gibt es STP/Loop-Events, die das VLAN intermittierend beeinflussen?

SVI/Gateway-Status und ARP

• Ist das Gateway-Interface (SVI) up/up und im richtigen VRF/Context?
• Sieht das Gateway die Clients in der ARP/Neighbor-Tabelle?
• Gibt es Duplicate IPs oder ARP-Flapping im Gastsegment?

DHCP im Gast-VLAN

Wenn Gäste keine IP bekommen oder nur manche Geräte betroffen sind, prüfen Sie DHCP konsequent. DHCP-Grundlagen sind in RFC 2131 beschrieben.

• Ist der DHCP-Server erreichbar (lokal oder per Relay)?
• Ist der Pool groß genug oder erschöpft?
• Stimmen DHCP-Optionen (Default Gateway, DNS)?
• Blocken Security-Features DHCP (z. B. DHCP Snooping falsch konfiguriert)?

Firewall-Checks: NAT, Policies und typische Blockaden

Wenn VLAN und IP-Basis stimmen, liegt die Ursache häufig in der Firewall: Gäste sollen isoliert sein, aber trotzdem Internet bekommen. Genau diese Balance führt zu Policy-Fehlern.

Grundregel: Gäste brauchen fast immer NAT

In vielen Designs ist das Gastnetz RFC1918 (z. B. 10.50.0.0/16) und wird Richtung Internet per NAT übersetzt. Private IPv4-Adressräume sind in RFC 1918 definiert.

• Existiert eine NAT-Regel für das Gastnetz (Source NAT/PAT)?
• Greift die NAT-Regel in der richtigen Reihenfolge (vor allgemeineren Regeln)?
• Ist der egress (WAN-Interface/Zone) korrekt?

Policy-Reihenfolge und „Default Deny“

• Gibt es eine explizite Allow-Regel für Gast → Internet (mindestens TCP/UDP 80/443, DNS, ggf. NTP)?
• Blockt eine frühere Deny-Regel das Gastnetz (z. B. „deny RFC1918“ zu breit)?
• Trefferzähler/Logging: Welche Regel matched wirklich?

Client Isolation und interne Ziele

Viele Gastnetze setzen „Client Isolation“ (Peer-to-Peer blocken) ein. Das ist sinnvoll, kann aber Nebenwirkungen haben, wenn Gäste z. B. auf einen Präsentationsbildschirm oder einen Drucker im Gastnetz zugreifen sollen.

• Ist Client-to-Client Traffic im WLAN/Firewall bewusst blockiert?
• Gibt es Ausnahmen (z. B. nur zu einem Gerät/Service)?
• Wird Multicast/Bonjour/MDNS benötigt (häufiges Sonderthema)?

Asymmetrisches Routing nach Policy-Änderungen

Wenn Gäste über zwei Internet-Uplinks oder über SD-WAN gehen, kann asymmetrisches Routing entstehen. Stateful Firewalls/NAT mögen das nicht und droppen Rückverkehr. Symptome: „Manchmal geht es, manchmal nicht“, besonders bei Sessions. Ein Verständnis von TCP-Verhalten hilft; Referenz: RFC 9293 (TCP).

• Geht Hinweg über Firewall A, Rückweg über Firewall B?
• Gibt es ECMP/Load-Balancing, das Sessions verteilt?
• Ist State-Sync/HA korrekt (falls Active/Active)?

DNS-Checks: Wenn „Internet geht nicht“, aber IP eigentlich funktioniert

DNS ist im Gastnetz eine der häufigsten Ursachen für „gefühlt kein Internet“. Viele Webseiten und Apps benötigen mehrere DNS-Queries, und wenn diese langsam oder blockiert sind, wirkt alles kaputt. DNS-Grundlagen sind in RFC 1035 beschrieben.

Resolver-Erreichbarkeit und Policy

• Welcher DNS-Server wird per DHCP verteilt (Option 6)?
• Darf das Gastnetz UDP/TCP 53 zum Resolver erreichen?
• Ist der Resolver extern (Public) oder intern (Corporate DNS mit Filtern)?

DNS-Filter, Kategorien und „nur bestimmte Seiten gehen nicht“

• Werden Domains kategoriebasiert blockiert (Jugendschutz, Malware, Werbung)?
• Greifen Filter unterschiedlich je nach Gerät (DoH, Private DNS auf Android)?
• Sind CDNs betroffen, sodass nur Teile einer Website nicht laden (CSS/JS)?

DoH/DoT und „Portal/Filter greift nicht“

Viele moderne Browser nutzen DNS over HTTPS. Das kann Captive Portal und DNS-Interception aushebeln oder Filter umgangen erscheinen lassen. In Gastnetzen sollten Sie eine klare Strategie haben: DoH zulassen (und Filter anders umsetzen) oder DoH gezielt blocken/steuern.

• Wenn das Portal nicht erscheint: nutzt das Gerät DoH und umgeht DNS-Redirect?
• Wenn Filter „nicht greifen“: nutzt der Browser DoH zu einem externen Provider?

Captive Portal im Gastnetz: Walled Garden und HTTPS-Fallen

Viele Gast-WLANs nutzen Captive Portals. Wenn Login-Seiten nicht laden, liegt es häufig an einem zu engen Walled Garden oder an HTTPS/HSTS. Für HTTP-Redirect-Logik ist RFC 9110 hilfreich, für TLS RFC 8446.

• Ist die Portal-Domain inklusive aller Assets (CDN, Fonts, JS) vor Login erlaubt?
• Ist der Identity Provider (SSO) erreichbar, wenn das Portal extern authentifiziert?
• Ist das Portal-Zertifikat gültig (SAN, Chain, Ablaufdatum), damit Browser nicht blocken?
• Sind OS-Connectivity-Check-Ziele im Walled Garden, damit Geräte das Portal automatisch öffnen?

MTU und PMTUD: Der seltene, aber harte Klassiker

Wenn „kleine Dinge gehen, große nicht“ oder Login-POSTs im Portal hängen, kann MTU/PMTUD die Ursache sein, besonders bei Tunneln, Proxies oder bestimmten ISPs. Hintergrund: RFC 1191 (Path MTU Discovery).

• Symptom: Portal lädt halb, aber Login/SSO scheitert; große Downloads hängen.
• Ursache: Fragmentierung/ICMP blockiert, effektive MTU kleiner als erwartet.
• Fix: MTU entlang des Pfades prüfen, ICMP-Fehlermeldungen nicht pauschal blocken, MSS-Clamping wo sinnvoll.

Der Standard-Workflow: Gast-WLAN in 10 Minuten sauber eingrenzen

Dieser Ablauf ist als Incident-Runbook gedacht. Er priorisiert schnelle, belastbare Beweise statt Vermutungen.

Schritt: Client-Basis erfassen

• IP, Maske, Gateway, DNS (DHCP oder statisch?)
• SSID, Zeitpunkt, Standort/AP (falls verfügbar)

Schritt: VLAN-Kette prüfen

• SSID → VLAN Mapping korrekt?
• VLAN auf Trunks/Port-Channels allowed?
• SVI/Gateway up, ARP sieht Client?

Schritt: Firewall/NAT prüfen

• Gast → Internet Allow-Regel vorhanden und trifft?
• NAT-Regel greift und egress stimmt?
• Logs/Hits zeigen die echte Entscheidung?

Schritt: DNS gezielt testen

• IP-Connectivity zu externem Ziel (ohne DNS) prüfen
• DNS-Auflösung separat prüfen (Resolver erreichbar, Antworten plausibel)
• Bei selektiven Problemen: Filter/DoH/Proxy in Betracht ziehen

Schritt: Captive Portal und Walled Garden

• Portal-URL direkt aufrufen, HTTP-Redirect testen
• Walled Garden für Portal/IdP/CDN/Connectivity Checks prüfen
• Zertifikate und HTTPS-Verhalten validieren

Schritt: Fix verifizieren und dokumentieren

• Nach Änderung: DHCP erneuern, Tests wiederholen (Gateway, DNS, Web, Portal)
• Vorher/Nachher festhalten (Screenshots, Logs, Zeitstempel)
• Konfiguration dokumentieren (VLAN, Policies, Resolver, Portal-Domains)

Schnelle Lösungen im Alltag: Häufige Fixes mit hohem Erfolg

• VLAN nicht allowed: Gast-VLAN auf Trunks/Port-Channels ergänzen, SVI prüfen
• DHCP-Pool leer: Pool erweitern, Lease-Time sinnvoll setzen, Rogue DHCP ausschließen
• NAT-Regel fehlt: Source NAT fürs Gastnetz korrekt platzieren
• DNS blockiert: UDP/TCP 53 zum Resolver erlauben, richtige DNS-Optionen verteilen
• Walled Garden zu eng: Portal/IdP/CDN/Connectivity Checks freischalten
• Asymmetrie: Pfade vereinheitlichen oder stateful HA korrekt konfigurieren
• MTU: PMTUD ermöglichen, MSS-Clamping prüfen, Tunnel-Overhead berücksichtigen

Outbound-Links zur Vertiefung

• RFC 2131: DHCP (IP-Vergabe und typische Fehler)
• RFC 1035: DNS (Namensauflösung im Gastnetz)
• RFC 1918: Private IPv4-Adressräume (NAT-Design im Gastnetz)
• RFC 9110: HTTP Semantics (Redirects, Portal-Mechanismen)
• RFC 8446: TLS 1.3 (HTTPS- und Zertifikatsthemen)

Checkliste: Gast-WLAN Probleme – VLAN/Firewall/DNS Checks für schnelle Lösung

• Client-Config prüfen: gültige IP, korrektes Gateway, DNS-Server per DHCP.
• Gateway-Test: Gateway pingbar? ARP/Neighbor stabil? Kein Flapping/Duplicate IP?
• VLAN-Kette prüfen: SSID→VLAN Mapping, VLAN allowed auf Trunks, SVI up, DHCP im VLAN erreichbar.
• Firewall-Policy prüfen: Gast→Internet erlaubt? Reihenfolge korrekt? Logging/Hits auswerten.
• NAT prüfen: Source NAT/PAT fürs Gastnetz aktiv und auf richtigem egress.
• DNS prüfen: Resolver erreichbar, UDP/TCP 53 erlaubt, Filter/DoH berücksichtigt.
• Portal prüfen (falls vorhanden): Walled Garden für Portal/IdP/CDN/Connectivity Checks, HTTPS-Zertifikat gültig.
• Selektive Probleme: Proxy/Category Filter/CDN/MTU/PMTUD in Betracht ziehen.
• Verifikation: Vorher/Nachher identisch testen (Gateway, externe IP, DNS, Web/Portal), dokumentieren.
• Prävention: Standard-Templates für Gast-VLAN, Firewall-Regeln, NAT und DNS-Policy; Monitoring auf DHCP-Pool und Deny-Logs.

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.