Die gute Nachricht: In vielen Fällen lässt sich das mit ein paar gezielten Prüfungen eingrenzen. Wer systematisch vorgeht, findet meist schnell heraus, ob der Gastzugang, der DNS-Server, eine VLAN-Zuordnung oder eine Sperre für Weiterleitungen das Portal blockiert.
Warum das Portal gar nicht erst erscheint
Ein Captive Portal lebt davon, dass der Client nach dem Verbinden eine unverschlüsselte oder umleitbare Anfrage auslöst, die vom Gateway abgefangen wird. Genau an dieser Stelle kann es schiefgehen, wenn der Browser sofort auf HTTPS besteht, wenn DNS bereits auf einen externen Resolver zeigt oder wenn das Endgerät durch vorab gespeicherte Netzwerkeinstellungen versucht, am Portal vorbei ins Internet zu gehen.
Bei UniFi kommt hinzu, dass mehrere Bausteine zusammenspielen: WLAN-SSID, Gäste-Policy, Firewall, DHCP-Adressierung, DNS-Weiterleitung und gegebenenfalls VLANs. Sobald einer dieser Bausteine nicht zum Rest passt, sieht der Nutzer nur ein verbundenes WLAN ohne Login-Seite.
Ein typischer Denkfehler ist, das Ganze als reines WLAN-Problem zu behandeln. In Wahrheit ist es häufig ein Zusammenspiel aus Netzwerk- und Namensauflösung, also aus der Frage, wie das Gerät eine Adresse bekommt, wohin seine DNS-Anfragen gehen und welche Verbindungen vor dem Login erlaubt sind.
Die wichtigsten Ursachen im Überblick
Die häufigsten Blockierer lassen sich in wenige Gruppen einteilen. Wer diese Reihenfolge im Kopf behält, spart sich viel Rätselraten.
- Der Client bekommt keine saubere IP-Adresse oder kein passendes Gateway.
- DNS zeigt auf einen Server, der im Gäste-Netz nicht erreichbar ist.
- Der Browser oder das Betriebssystem springt direkt auf HTTPS und umgeht den Portal-Check.
- Die Gäste-Regeln erlauben zu viel oder zu wenig, etwa durch falsche Firewall-Ausnahmen.
- VLAN, SSID und Gateway passen nicht zusammen.
- Eine feste DNS-Konfiguration am Gerät überschreibt die Gäste-Logik.
- Ein gespeichertes WLAN-Profil verhindert den Captive-Portal-Dialog.
Wenn du diese Punkte nacheinander prüfst, wird aus einem scheinbar mysteriösen Verhalten ein gut eingrenzbares Netzproblem. Das ist meist deutlich schneller, als blind an mehreren Einstellungen gleichzeitig zu drehen.
Erst das Verhalten beobachten, dann an der Ursache drehen
Der schnellste Einstieg ist die Beobachtung auf dem Endgerät. Verbindet sich das Gerät mit dem Gäste-WLAN, bekommt aber keinen Hinweis auf eine Anmeldung, dann lohnt sich ein Blick auf DNS, DNS-Sperren und die erste Seitenanfrage. Erscheint die Portal-Seite nur auf einem Gerät, auf anderen aber nicht, spricht das eher für ein Problem am Client oder im Browser.
Es hilft, die Symptome sauber zu trennen. Ein Gerät ohne IP-Adresse braucht eine andere Behandlung als ein Gerät mit IP, aber ohne Portal. Ein Gerät mit Portal, das nach dem Login keinen Internetzugang hat, deutet wiederum eher auf Firewall, Routing oder VLAN hin.
Genau diese Unterscheidung macht den Unterschied zwischen Stochern im Nebel und gezielter Fehlersuche.
Die erste Prüfung in UniFi
Beginne am Controller beziehungsweise in der UniFi-Oberfläche beim betroffenen WLAN. Prüfe dort, ob es wirklich als Gäste-Netz eingerichtet ist und ob der Zugriff auf den lokalen Bereich oder das Internet passend begrenzt ist. Eine falsch gesetzte Gästeoption kann das Portalverhalten verändern, ohne dass es auf den ersten Blick auffällt.
Wichtige Stellen sind die SSID-Einstellungen, die Gastzugangsregeln und die Netzwerkkonfiguration des zugehörigen VLANs. Wenn dort ein Spezialprofil aktiv ist, sollte es zur restlichen Infrastruktur passen. Ein Gäste-WLAN auf einem eigenen Netz, aber mit DNS auf einen internen Server, der nicht erreichbar ist, ist ein klassischer Stolperstein.
Falls du mehrere Uplinks, mehrere Gateways oder ein separates Security-Gateway nutzt, muss auch die Weiterleitung zum Portal an der richtigen Stelle landen. Sonst verbindet der Client zwar sauber, aber der Umleitungsmechanismus greift ins Leere.
DNS als heimlicher Störer
DNS ist oft der unsichtbare Auslöser. Das Gäste-Gerät muss Namensauflösung bekommen, bevor das Portal erscheinen kann, und zwar über einen Server, den es im Gäste-Netz wirklich erreicht. Wird am Client ein externer DNS-Server manuell gesetzt, kann das Portal je nach Aufbau umgangen oder blockiert werden.
Besonders tückisch sind Systeme, die eigene DNS-over-HTTPS- oder Private-DNS-Funktionen aktiv haben. Dann geht die Namensauflösung verschlüsselt direkt an einen externen Resolver, während das lokale Portal auf die erste Webanfrage wartet. Für das Endgerät sieht alles normal aus, für das Netzwerk aber eben nicht.
Wer den Fehler eingrenzen will, sollte testweise die DNS-Konfiguration am Client auf automatisch stellen und am Gäste-Netz nur die vorgesehenen Server zulassen. Häufig reicht das schon, damit die Portal-Seite wieder sauber aufpoppt.
Praktisch ist dabei folgende Reihenfolge: Gerät trennen, gespeichertes WLAN-Profil vergessen, DNS auf automatisch setzen, erneut verbinden und dann erst den Browser öffnen. Wenn das Portal dann erscheint, war die Ursache sehr wahrscheinlich die alte Client-Konfiguration oder ein externer DNS-Weg.
Browser, HTTPS und der erste Seitenaufruf
Viele Captive Portals reagieren nur zuverlässig, wenn zuerst eine einfache HTTP-Anfrage ausgelöst wird. Moderne Browser und Betriebssysteme versuchen aber oft sofort auf HTTPS zu gehen. Dann landet der Verbindungsversuch nicht beim Portal, sondern bei einer verschlüsselten Zieladresse, die nicht umleitbar ist.
Auch gespeicherte Tabs, automatische Startseiten oder der Versuch, eine HTTPS-only-Website aufzurufen, können den Login ausbremsen. Am zuverlässigsten ist meist ein frischer Browser-Start mit einer unverschlüsselten Adresse oder die automatische Portal-Erkennung des Betriebssystems.
Wenn auf dem Telefon oder Laptop gar kein Hinweisfenster erscheint, hilft oft ein kurzer Wechsel des Browser-Tabs oder das Öffnen einer einfachen Seite nach dem erneuten Verbinden. Gerade bei iPhone, Android, Windows und macOS ist das Verhalten je nach Version leicht unterschiedlich.
Typische Einstellungen, die du prüfen solltest
In der Praxis bewährt sich ein klarer Ablauf. Prüfe zuerst die Netzwerkverbindung, dann die DNS-Seite und danach die Portal-Weiterleitung. So vermeidest du, dass du an mehreren Stellen gleichzeitig änderst und am Ende nicht mehr weißt, was wirklich geholfen hat.
- Gäste-WLAN am Endgerät löschen und neu verbinden.
- Automatische IP- und DNS-Vergabe aktivieren.
- Portal mit einem frischen Browserfenster anstoßen.
- Im UniFi-Controller die Gäste- und Portalregeln kontrollieren.
- Bei Bedarf das betroffene Gerät kurz neu starten.
Diese Reihenfolge ist bewusst unspektakulär. Genau das macht sie so brauchbar, weil sie die häufigsten Ursachen ohne unnötige Nebenwirkungen abklappert.
Wenn VLANs im Spiel sind
Sobald Gäste-WLAN auf ein eigenes VLAN gelegt wird, steigt die Wahrscheinlichkeit für Fehlkonfigurationen. Dann muss das VLAN am Access Point, am Switch und am Gateway korrekt durchgereicht werden, und die Firewall muss die Portal-Kommunikation zulassen. Schon ein kleiner Abweichler reicht, damit der Client zwar im Funknetz hängt, aber kein Portal bekommt.
Ein häufiger Fall ist ein VLAN, das zwar an der SSID hängt, aber am Trunk-Port des Switches nicht sauber freigegeben ist. Dann kommen DHCP oder DNS nicht dort an, wo sie ankommen sollen. Das Ergebnis wirkt wie ein Portalfehler, ist aber eigentlich ein Transportproblem im Netz.
Ein zweites Muster ist ein Gastnetz, das per VLAN richtig getrennt ist, aber auf ein Gateway zeigt, das die captive-spezifischen Umleitungen nicht kennt. Dann wird die Anmeldung intern vorbereitet, aber nie sauber ausgeliefert.
Firewall und Freigaben ohne Nebenwirkungen
Die Firewall ist ein weiterer Bereich, der gern unterschätzt wird. Zu strenge Regeln blockieren die Portal-Umleitung, zu lockere Regeln geben dem Gäste-Netz mehr Zugriff als gewollt. Beides ist ungünstig, nur auf unterschiedliche Weise.
Für den Fehlerfall ist besonders wichtig, ob DNS, DHCP und die Portaladresse selbst zwischen Client und Gateway erreichbar sind. Wenn du hier pauschal alles sperrst, kann die Anmeldung gar nicht erst zustande kommen. Wenn du dagegen zu viele Ausnahmen setzt, umgehen Gäste möglicherweise die eigentliche Schutzlogik.
Darum lohnt sich ein sauberer Blick auf die Reihenfolge der Regeln. In Netzwerken gilt oft: Die erste passende Regel gewinnt. Eine kleine Ausnahme an der falschen Stelle kann also den ganzen Gästezugang verändern.
Geräteseitig eingegrenzt denken
Manchmal liegt der Fehler gar nicht am Netzwerk, sondern am Endgerät. Ein altes WLAN-Profil mit statischer DNS-Vorgabe, ein VPN, ein Filter-App-Profil oder eine Sicherheitssoftware kann das Captive Portal blockieren. Dann verbindet sich das Gerät zwar, verhält sich im Browser aber so, als gäbe es keinen Login.
Besonders bei Firmengeräten, verwalteten Smartphones oder Geräten mit Kindersicherung kommt das vor. Dort greifen oft Richtlinien, die automatische Portalöffnungen unterdrücken oder Umleitungen einschränken. In so einem Fall hilft es, testweise ein anderes, privates Gerät zu verwenden.
Wenn nur ein bestimmtes Telefon Probleme macht, die anderen aber problemlos ins Portal kommen, ist die Netzwerkkonfiguration nicht der einzige Verdächtige. Dann gehört auch das Gerät selbst auf den Prüfstand.
Ein sauberer Weg zur Eingrenzung
Wer das Ganze ordentlich auseinanderziehen will, geht am besten so vor: Erst den Gastzugang an einem zweiten Gerät testen, dann DNS automatisieren, dann gespeicherte Profile entfernen und zuletzt die UniFi-Regeln prüfen. Auf diese Weise trennst du Client-Fehler von Netzfehlern und Netzfehler von Portalproblemen.
Wenn nach dem Entfernen des WLAN-Profils sofort alles funktioniert, ist die Ursache meist lokal auf dem Gerät zu suchen. Wenn dagegen kein Gerät das Portal sieht, liegt das Problem eher im Netz, im Gateway oder in der Regelbasis.
Diese Trennung klingt simpel, spart aber oft eine Menge Zeit. Viele vermeintliche Portalprobleme sind in Wahrheit Konfigurationsreste aus älteren Netzwerken.
Ein paar typische Alltagssituationen
Im Büro passiert es oft, dass ein Gäste-WLAN nach einer Umstellung auf neue DNS-Server plötzlich still bleibt. Das Portal ist vorhanden, aber das erste Gerät, das sich anmeldet, landet wegen einer alten Cache- oder DNS-Konfiguration nie dort. Nach dem Wechsel auf automatische DNS-Vergabe funktioniert alles wieder.
Zu Hause sieht man das häufig nach einem Wechsel auf ein neues Gateway oder nach dem Aktivieren von Sicherheitsfunktionen am Router. Das Tablet verbindet sich zwar sofort, aber der Browser springt auf eine HTTPS-Seite und zeigt kein Portal. Erst ein gespeichertes Profil wird gelöscht, dann taucht die Login-Seite wieder auf.
In kleineren Ferienwohnungen oder in einem Praxis-Wartebereich ist der Klassiker ein Gäste-WLAN auf separatem VLAN, das am Switch zwar anliegt, aber an einer Portgruppe fehlt. Die Geräte bekommen eine Verbindung, aber der Portalaufruf bleibt aus, weil die Weiterleitung nicht bis zum Gateway durchkommt.
Was du bei Tests besser nicht überspringst
Gerade bei Captive Portals ist es verlockend, nach dem ersten Fehlschlag sofort an der großen Stellschraube zu drehen. Besser ist es, die kleineren, reversiblen Schritte zuerst zu testen. Dazu gehören das Vergessen des WLANs, das Umschalten auf automatische DNS-Vergabe und ein Neustart des betroffenen Geräts.
Wenn diese Schritte nichts bringen, folgt erst der Blick in die UniFi-Gästeeinstellungen, die Firewall und gegebenenfalls das VLAN. So bleibt die Fehlersuche übersichtlich und du vermeidest unnötige Änderungen an einem funktionierenden Netz.
Auch ein kurzer Test mit einem zweiten Browser oder einem zweiten Endgerät ist oft hilfreich. Unterschiedliche Betriebssysteme verhalten sich bei Portal-Erkennung nämlich spürbar anders.
Sichere Reihenfolge bei der Behebung
Am besten gehst du in einer Reihenfolge vor, die nichts kaputt macht und schnell aussagekräftige Ergebnisse liefert. Zuerst das Endgerät prüfen, dann den DNS-Weg kontrollieren, danach die Gäste- und Portalregeln im Controller ansehen und zuletzt das VLAN beziehungsweise die Gateway-Anbindung untersuchen. So lässt sich die Ursache Schritt für Schritt eingrenzen, ohne die gesamte WLAN-Struktur umzubauen.
Wenn danach noch immer kein Portal erscheint, lohnt sich der Blick auf Sonderfälle wie VPN-Profile, private DNS-Funktionen oder Geräte mit striktem Sicherheitsprofil. Genau dort verstecken sich oft die letzten Prozent der Probleme.
Am Ende zählt nicht die längste Liste an Änderungen, sondern die richtige Reihenfolge. Wer sauber prüft, bekommt das Portal meist wieder zum Laufen, ohne das Gäste-Netz unnötig aufzureißen.
Portalaufruf sauber von der Namensauflösung trennen
Bevor du an der Oberfläche nach einem einzelnen Fehler suchst, lohnt sich die Trennung in zwei Ebenen: Erreicht das Endgerät das Gäste-Netz überhaupt, und wird der Aufruf der Startseite durch DNS oder Weiterleitungen unterbrochen? In einem UniFi Gäste-WLAN laufen diese Schritte oft nacheinander ab. Das Gerät verbindet sich, erhält eine IP-Adresse, versucht einen ersten Webaufruf und wird dann erst auf das Anmeldeportal umgelenkt. Bleibt einer dieser Schritte hängen, wirkt es so, als würde das Portal gar nicht existieren.
Besonders wichtig ist dabei die erste DNS-Anfrage. Viele Systeme öffnen das Portal erst nach einem HTTP-Aufruf an eine unverschlüsselte Adresse. Wird dieser Aufruf zu schnell per HTTPS umgeleitet, landen manche Geräte direkt auf der verschlüsselten Zielseite, ohne dass die Umleitung auf das Portal greifen kann. Deshalb solltest du die Prüfung nicht nur auf das WLAN selbst beschränken, sondern auch auf DNS, Browserverhalten und die Art des ersten Seitenaufrufs.
Den Gästezugang in UniFi an den entscheidenden Stellen prüfen
In der UniFi-Oberfläche liegen die wichtigsten Schalter nicht an einer einzigen Stelle. Der Weg führt je nach Version über das Netzwerkprofil, das Gastnetz und die Freigabeoptionen des Portals. Prüfe zuerst, ob das SSID-Profil tatsächlich als Gastnetz eingerichtet ist und ob die Portal- oder Gästeisolation aktiv ist. Zusätzlich muss das Netz einem passenden VLAN oder einer passenden Netzklasse zugeordnet sein, damit Firewall-Regeln und DHCP zusammenarbeiten.
- SSID in den WLAN-Einstellungen prüfen und das Gästeprofil bestätigen.
- Im Netzwerkbereich kontrollieren, ob das Gäste-VLAN oder Subnetz korrekt konfiguriert ist.
- Die Portalart ansehen: einfache Bestätigung, Voucher, Passwort oder externer Redirect.
- Prüfen, ob die Geräte mit einer gültigen Lease eine Adresse, Gateway und DNS erhalten.
- Die Gastfreigaben kontrollieren, damit Portal- und DNS-Ziele nicht blockiert werden.
Hilfreich ist außerdem der Blick auf den Controller-Status. Läuft das Portal lokal, muss der Controller erreichbar sein, solange der Client noch nicht freigeschaltet ist. Ist der Controller in einem anderen Netzsegment oder hinter einer restriktiven Firewall, scheitert der Aufruf bereits am internen Pfad zum Portal. Das gilt besonders dann, wenn nur ein Teil der Gäste im Netz landet, andere Geräte aber sofort wieder getrennt werden.
DNS so prüfen, dass die Fehlerquelle sichtbar wird
DNS ist oft die unscheinbare Ursache, weil ein Gerät zwar verbunden wirkt, aber keine verwertbare Antwort für den Portalaufruf erhält. Kontrolliere zunächst, welche DNS-Server per DHCP verteilt werden. Stehen dort feste interne Resolver, sollten diese aus dem Gäste-Netz erreichbar sein. Wird ein externer DNS-Server verwendet, müssen Firewall und Routing diesen Verkehr zulassen, sonst kann das Endgerät zwar die WLAN-Verbindung halten, aber keine Zieladresse auflösen.
Ein häufiger Stolperstein sind alternative DNS-Einstellungen am Gerät. Viele Smartphones und Laptops nutzen private DNS-Profile, DNS-over-HTTPS oder manuell gesetzte Resolver. Solche Einstellungen umgehen die Vorgaben des Gastnetzes. Dann bleibt die Umleitung ins Leere, weil die Namensauflösung nicht mehr über den erwarteten Weg läuft. Für die Prüfung empfiehlt es sich, private DNS-Funktionen am Endgerät testweise zu deaktivieren und den Netzwerkcache zu erneuern.
- Im UniFi-Netzwerk die per DHCP verteilten DNS-Server notieren.
- Mit einem Testgerät prüfen, ob ein Name wie eine bekannte Webseite aufgelöst wird.
- Zusätzlich eine interne Portaladresse oder das Gateway testen, falls bekannt.
- Im Zweifel einen anderen DNS-Server im Gästeprofil eintragen und die Verbindung neu aufbauen.
- Nach jeder Änderung das Gerät trennen, die Lease erneuern und den Browser neu starten.
Wenn die DNS-Anfrage in Ordnung ist, das Portal aber dennoch ausbleibt, liegt der Fokus auf dem eigentlichen Captive-Mechanismus. Dann geht es um HTTP-Umleitung, zugelassene Zieladressen und um die Frage, ob der Browser die Weiterleitung akzeptiert. Genau hier trennt sich ein sauber konfiguriertes Gäste-WLAN von einem Netz, das zwar funktioniert, aber den Anmeldeweg blockiert.
Weiterleitungen, Browser und die erste Anfrage im Griff behalten
Das Portal wird meist nicht durch jede beliebige Seite ausgelöst, sondern durch einen sehr bestimmten Erstkontakt. Manche Browser versuchen sofort eine HTTPS-Seite oder den zuletzt geöffneten Tab zu laden. Andere Systeme setzen auf einen unverschlüsselten Testaufruf an eine speziell bekannte Adresse. Wird dieser Aufruf von HSTS, DNS-Cache oder einer Sicherheitsfunktion des Browsers übersteuert, erscheint statt der Portalmaske nur eine Fehlseite oder gar nichts.
Für die Eingrenzung ist ein einfacher Ablauf sinnvoll: neues Browserfenster, kein gespeicherter Ablauf, kein VPN, keine Proxy-Konfiguration, keine privaten DNS-Funktionen. Danach zuerst eine unverschlüsselte HTTP-Adresse aufrufen, nicht direkt eine verschlüsselte Zielseite. Viele Installationen reagieren nur dann zuverlässig. Falls ein Gerät ständig auf HTTPS umspringt, hilft oft der Test mit einem zweiten Browser oder mit einem völlig anderen Endgerät, um browserseitige Besonderheiten auszuschließen.
- Privates Fenster oder frisches Profil nutzen.
- VPN und Proxy am Testgerät ausschalten.
- WLAN-Verbindung vergessen und neu verbinden.
- Die Startseite über eine einfache HTTP-Adresse anfordern.
- Falls nötig den Netzwerk- oder DNS-Cache des Geräts leeren.
Auch Zertifikatswarnungen verdienen Beachtung, obwohl sie nicht immer die Hauptursache sind. Sobald ein Gerät eine verschlüsselte Zielseite erzwingen will, aber das Portal nur unverschlüsselt bereitsteht, entsteht ein Umweg, der die Anmeldung verzögern oder verhindern kann. In solchen Fällen hilft es, den Portaltyp in UniFi zu prüfen und sicherzustellen, dass die Freigabe für die Erstverbindung passend gewählt ist.
FAQ
Woran erkenne ich, dass DNS die Portalanzeige verhindert?
Ein typisches Zeichen ist, dass Clients zwar eine Verbindung zum Gästenetz haben, aber keine Weiterleitung auf die Anmeldeseite erhalten. Häufig helfen dann nur einfache Tests wie das Aufrufen einer unverschlüsselten Seite oder das Wechseln auf einen anderen DNS-Server, um das Verhalten einzugrenzen.
Warum ist der erste Seitenaufruf im Browser so wichtig?
Captive Portals werden oft erst über einen unverschlüsselten HTTP-Aufruf ausgelöst. Startet der Browser direkt mit HTTPS oder nutzt er aus dem Cache gespeicherte Weiterleitungen, bleibt die Weiterleitung auf das Portal manchmal aus.
Welche Rolle spielt die DNS-Konfiguration im Gästeprofil?
Der im Profil eingetragene DNS-Server entscheidet, wohin Anfragen der Gäste laufen. Zeigt er auf einen internen Resolver mit blockierenden Regeln, auf einen nicht erreichbaren Dienst oder auf eine fehlerhafte Weiterleitung, kann das Portal nicht sauber erscheinen.
Kann ein VLAN das Portalverhalten beeinflussen?
Ja, denn das Gäste-VLAN muss bis zum Controller, zur Gateway-Komponente und zu den nötigen Freigaben durchgereicht werden. Fehlt an einer Stelle die passende Zuordnung oder ist ein Tagging fehlerhaft, kommen Clients zwar ins Funknetz, erreichen den Anmeldefluss aber nicht.
Welche Firewall-Regeln sind besonders oft beteiligt?
Blockierte Verbindungen zu DNS, DHCP, dem Captive-Portal-Endpunkt oder zum Controller gehören zu den häufigsten Ursachen. Wichtig ist eine Freigabe mit Augenmaß, damit nur die benötigten Ziele offen sind und das Gästenetz trotzdem isoliert bleibt.
Warum klappt es auf dem Handy manchmal und auf dem Laptop nicht?
Unterschiedliche Betriebssysteme und Browser prüfen Netzwerke auf eigene Weise. Manche Geräte rufen automatisch eine Prüfseite auf, andere warten länger oder setzen auf verschlüsselte Verbindungen, weshalb sich das Portal je nach Endgerät unterschiedlich verhält.
Hilft es, private DNS-Funktionen am Gerät zu deaktivieren?
Ja, besonders bei Android, iOS oder modernen Browsern können private DNS- oder DoH-Einstellungen die Umleitung stören. Für die Prüfung lohnt es sich, diese Funktionen zeitweise zu deaktivieren und danach den Portalaufruf erneut zu testen.
Wo finde ich die wichtigsten Einstellungen in UniFi?
Die relevanten Optionen liegen meist im Netzwerkprofil für das Gäste-WLAN, in den Einstellungen des WLANs selbst, im Gateway-Bereich und in den Firewall-Regeln. Zusätzlich solltest du den DNS-Bereich, die Zuordnung zum VLAN und die Portal-Optionen im Blick behalten, weil dort oft der eigentliche Fehler sitzt.
Welche Prüfung bringt am schnellsten Klarheit?
Am schnellsten ist eine gestufte Prüfung mit einem einfachen Testclient, festem DNS und einem HTTP-Aufruf auf eine beliebige unverschlüsselte Adresse. Kommt dann die Weiterleitung, liegt das Problem meist nicht beim Portal selbst, sondern bei DNS, Browserverhalten oder einer Freigaberegel dazwischen.
Wann ist der Controller selbst die Ursache?
Wenn das Portal für keinen Client erscheint, obwohl Netzwerk, DNS und Firewall sauber wirken, lohnt sich der Blick auf den Status von Controller, Gateway und Portal-Dienst. Ein nicht erreichbarer Dienst, ein falsch gebundener Port oder eine geänderte Zertifikatskonfiguration kann die Anmeldung ebenfalls blockieren.
Fazit
Damit der Portalaufruf im Gäste-WLAN zuverlässig erscheint, müssen DNS, Browserverhalten, VLAN-Zuordnung und Freigaben zusammenpassen. Wer die Prüfung systematisch aufbaut und die Einstellungen in UniFi schrittweise gegenprüft, findet die Ursache meist ohne Umwege. So lässt sich das Netzwerk sauber absichern, ohne die Anmeldung für Gäste zu verhindern.
