Fremdes WLAN, hängender Tunnel: Captive Portals in Hotel, ICE und Café eingrenzen

Das Muster ist immer gleich: WLAN verbunden, volle Feldstärke, kein Datenverkehr. Im Hotel, im ICE, im Café oder in der Ferienwohnung liegt zwischen Gerät und Internet ein Captive Portal, also ein Netz, das alles sperrt, bis eine Anmeldeseite bestätigt wurde. Startet der Tunnel automatisch mit, blockieren sich beide gegenseitig.

Dieser Text erklärt die Mechanik solcher Portale, die Reihenfolge, die zuverlässig funktioniert, und wie du die drei Ursachen auseinanderhältst, die praktisch alle Fälle abdecken.

Was ein Captive Portal technisch tut

Beim Verbinden vergibt das Netz per DHCP eine Adresse und einen eigenen DNS-Resolver. Viele Portale lassen diesen Resolver zunächst jede Anfrage mit der Adresse der Anmeldeseite beantworten, andere leiten erst am Gateway um. In beiden Fällen ist nur ein kleiner Kreis freigegebener Ziele erreichbar. Die erste unverschlüsselte HTTP-Anfrage landet auf der Anmeldeseite. Eine HTTPS-Anfrage lässt sich nicht umleiten, ohne dass das Zertifikat nicht mehr zum aufgerufenen Namen passt, deshalb erscheint das Portal nicht, wenn die erste Anfrage verschlüsselt ist.

Betriebssysteme erkennen Portale, indem sie beim Verbinden eine feste, unverschlüsselte Testadresse abrufen und die Antwort prüfen: Apple captive.apple.com, Android connectivitycheck.gstatic.com, Windows msftconnecttest.com. Weicht die Antwort vom Erwarteten ab, meldet das System Anmeldung erforderlich. Genau diese Erkennung scheitert, wenn verschlüsseltes DNS erzwungen wird, ein fester Resolver eingetragen ist oder bereits ein Tunnel samt Kill Switch läuft.

Die Reihenfolge, die funktioniert

1. 1Tunnel und automatische Verbindung ausschalten, bevor du dich mit dem WLAN verbindest. Auch den Kill Switch deaktivieren, sonst blockiert er die Portalseite mit.
2. 2Verschlüsseltes DNS vorübergehend auf automatisch stellen: Android unter Privates DNS, iOS und macOS über das DNS-Profil, Windows pro Adapter, im Browser die Option für sicheres DNS.
3. 3WLAN verbinden und einige Sekunden warten. Oft öffnet das System die Anmeldeseite von selbst.
4. 4Erscheint nichts, im Browser bewusst eine Adresse mit http:// aufrufen, ausdrücklich ohne s. Erst dann kann das Netz umleiten.
5. 5Anmeldeseite selbst bestätigen und die Bedingungen vorher lesen. Danach eine beliebige Seite laden, um zu prüfen, ob der Zugang wirklich offen ist.
6. 6Erst jetzt den Tunnel starten und die DNS-Einstellung zurückstellen. Bleibt der Zugang instabil, für dieses Netz die zufällige WLAN-Adresse abschalten: Wechselt die Geräteadresse, verlangt das Portal eine neue Anmeldung.

Wenn das Portal durch ist und trotzdem nichts läuft

1. 1Gateway prüfen: Standardgateway mit ipconfig oder ip route ermitteln und anpingen. Antwortet es nicht, liegt das Problem im WLAN selbst.
2. 2Namensauflösung prüfen: nslookup auf einen beliebigen Namen. Kommt weiterhin eine Adresse zurück, die zum Portal gehört, bist du nicht angemeldet.
3. 3Ausgehende Ports prüfen: Manche Gästenetze erlauben nur TCP 80 und 443 und verwerfen UDP. Baut ein TCP-basierter Transport auf Port 443 eine Verbindung auf, während ein UDP-Protokoll scheitert, ist der Filter die Ursache.
4. 4Systemzeit prüfen: TLS-Zertifikate sind zeitgebunden. Geht die Uhr mehrere Stunden falsch, scheitert jeder Handshake, oft ohne verständliche Meldung. Automatische Zeitsynchronisierung einschalten.
5. 5MTU prüfen: Gästenetze hängen oft selbst hinter Tunneln oder mehreren NAT-Ebenen. Klappt der Handshake, bleiben aber große Übertragungen hängen, hilft die Rechnung aus DS-Lite, CGNAT und Dual Stack.

Sonderfall Zug: lokale Dienste hinter dem Tunnel

Das Unterhaltungsangebot im ICE liegt auf einem Server im Zug, nicht im Internet. Der Portalname löst im Bordnetz auf eine Adresse innerhalb des Zuges auf. Läuft ein Tunnel, der den gesamten Verkehr übernimmt, verlässt auch diese Anfrage das Gerät durch den Tunnel und erreicht den Server nie. Das ist kein Defekt, sondern die Folge davon, dass das Ziel ausschließlich über die lokale Schnittstelle erreichbar ist.

Dieselbe Klasse von Problem trifft Drucker im Hotelnetz, Abspielgeräte am Fernseher und Geräte im eigenen Heimnetz. Die saubere Lösung ist, lokale Ziele vom Tunnel auszunehmen: die privaten IPv4-Bereiche 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16, den geteilten Bereich 100.64.0.0/10 sowie link-lokale IPv6-Adressen aus fe80::/10. In Clients heißt diese Einstellung meist lokales Netzwerk zulassen oder Split Tunneling.

Was das fremde Netz sehen kann

Ohne Tunnel sieht der Netzbetreiber unverschlüsselte DNS-Anfragen, den Servernamen im TLS-Handshake (SNI), jede Ziel-IP, Zeitpunkte und Datenmengen. Mit Tunnel bleibt ihm die äußere Verbindung: Adresse und Port des Endpunkts, Volumen und zeitlicher Verlauf. Zusätzlich verknüpft der Portalbetreiber die Sitzung mit der Geräteadresse und den Anmeldedaten, etwa Zimmernummer oder Name. Wie stabil dich dagegen dein eigener Anschluss zu Hause identifiziert, steht in IPv6-Präfix als Hausnummer.

Häufige Fragen