Woher bekommt ein Client im Gäste-WLAN die nötigen Infos über den Controller

Servus zusammen,

Kurze Zusammenfassung unserer Konfig: wir wollen ein Gäste WLAN mit Vouchern betreiben, das sich in einem anderen Netz befindet als der Controller (+ APs). Problem: die Web-GUI des Controllers mit dem Captive Portal wird mit dieser Konfig nicht von verbundenen Clients aufgerufen. Sobald man das Gäste WLAN in dasselbe Netz schiebt wie den Controller funktioniert es und ein verbundener Client kontaktiert sofort den Controller, der User kann dann seinen Voucher eingeben usw. Die benötigte Route aus dem Gäste Netz heraus auf den Controller ist freigeschaltet - und zwar sowohl in den controller settings ("pre-authorization access") als auch auf der Firewall (Sophos XGS). Es kann also kein Routing Problem sein - zumindest was Unicast Traffic angeht.

Als ich das Szenario "alles im gleichen Netz" getestet habe (wo der automatische Aufruf des Captive Portals ja wie gesagt funktioniert), habe ich mir die URL des Captive Portals mal genauer angeschaut. Anscheinend braucht der Client genau die folgenden 3 Infos / Parameter:

- die IP bzw. den FQDN des Controllers

- die MAC-Adresse des AccessPoints mit dem er verbunden ist (wird als erster Parameter mitgegeben in der URL)

- irgendeine recht lange ID (wird als zweiter Parameter mitgegeben in der URL)

Die für meine Konstellation entscheidende Frage ist: woher bekommt ein mit dem Gäste-WLAN verbundener Client diese Infos

Ich tippe auf irgendein Protokoll wie mDNS oder SSDP, das per Multicast rumgeschickt wird, das dem Client genau diese Werte und Infos anbietet. Wenn das tatsächlich so ist und ich die IP des entsprechenden (Ubiquiti-proprietären?) Multicast Traffics wüsste, könnte ich auf der FW eine Weiterleitung/ Routing dieses Multicast Traffics vom Controller Netz ins Gästenetz einrichten und dann sollte es funktionieren.

Es könnte natürlich auch an etwas anderem liegen - ich bin dankbar für jeden Tipp und Vorschlag

VG und vielen Dank im Voraus

Gary

Zitat von DoPe

Da werden sicher nicht alle Ports auf sein die gebraucht werden für den Redirect. https://help.ui.com/hc/en-us/a…-Required-Ports-Reference

Die Clients werden offenbar umgeleitet. Der Accesspoint kennt all diese Daten und da das ganze auch nur mit einem Accesspoint für ein Gäste WLAN funktioniert, ist hier ja auch kein Unifi Router nötig ... somit ist der raus. Bau dir doch ein Test Gast WLAN mit Portal und prüfe einfach mal ob die Sache läuft wenn in der Sophos nicht rumreglementiert wird ... kannst das Test Gast WLAN ja verschlüsseln. Wenns geht dann einfach mal die Firewall Regel für Regel füttern ...

pre-authorization access, da braucht der Controller nicht eingetragen werden!

Vielen Dank für den Hinweis die Öffnung der zahlreichen Ports war in meinem Fall nicht das Problem, aber der von dir vorgeschlagene Ansatz erstmal alles zwischen den beiden relevanten VLANs zu erlauben und dann sukzessive einzugrenzen war gold wert

Es hat sich herausgestellt dass die APs DNS nach draußen dürfen müssen damit das Ganze funktioniert. Die machen das scheinbar (zumindest anfänglich vor erfolgter Autorisierung ?) stellvertretend für die verbundenen Clients (z.B. habe ich Anfragen für captive.apple.com gesehen bei iOS Geräten).

Zur Zusammenfassung für die Zukunft falls jemand mit ähnlicher Konfig ähnliche Fragen hat hier nochmal die nötigen 3 FW-Einstellungen bei einer externen FW damit es klappt:

Für die Autorisierung:

- DNS für die APs nach draußen (WAN) erlauben

- Zugriff vom Gäste VLAN auf den WLC auf Port 8880 (für HTTP) bzw. 8843 (HTTPS) erlauben

Für die eigentliche Nutzung nach erfolgter Autorisierung:

- Internetzugang für das Gäste VLAN erlauben (wird dann ja reguliert/ eingeschränkt durch den WLC)

Der Hinweis von DoPe ist außerdem ebenfalls korrekt, dass bei den Einstellungen für das Captive Portal der pre-auth access für den WLC nicht extra eingestellt werden muss. Also einfach leer lassen.

Herzlichen Dank nochmal und ein schönes Wochenende

Gary

Noch weitere Infos und Erklärungen hierzu für Interessierte/ Suchende:

Warum es vorher auch ohne DNS funktioniert hat

Es hatte bei uns als Controller/APs und Gäste-WLAN im gleichen Netz waren (siehe 1. Post) deshalb schon funktioniert, weil wir im Controller/AP Netz die Firewall selbst als DNS-Server eingestellt haben und man daher nicht extra DNS nach draußen freigeben musste. Im Gäste-WLAN haben wir nur öffentliche DNS Server hinterlegt, daher war die Freigabe nötig.

Chronologische Reihenfolge Verbindung mit Gäste-WLAN --> Erscheinen der Captive Portal Seite

Die verbundenen Clients gehen unmittelbar nach Verbindung mit dem Gäste WLAN offenbar so vor:

1.) DNS-Anfrage für eine vom Hersteller festgelegte URL (im Falle von Apple ist das z.B. captive.apple.com). Da die Clients noch nicht selbst raus dürfen, wird diese Anfrage vom verbundenen AP stellvertretend rausgeschickt

2.) Wenn der AP DNS Anfragen nach draußen machen darf, bekommt er eine Antwort (die zugehörige IP der angefragten Adresse) vom DNS Server und leitet diese an den Client weiter

3.) Der Client ruft diese Seite dann auf (im Fall von Apple Geräten: captive.apple.com wird aufgerufen) und versucht von dort eine kleine Datei herunterzuladen. Dies dient dem Prüfen der Konnektivität, also ob der Client bereits ins Internet kann oder geblockt wird

4.) Schritt 3 scheitert dann natürlich (da noch nicht autorisiert), wodurch der Client weiß, dass er ein Captive Portal aufrufen muss. Da er die IP und weitere Parameter des Captive Portals nicht kennt, versucht er eine beliebige Seite im Internet aufzurufen

5.) Der AP hat die in Schritt 4 angegebenen Infos. Er sieht die Anfrage des Clients in Schritt 4 und leitet diese mit den nötigen Infos / Parametern an den Controller um (redirect)

6.) Der Controller antwortet auf die Anfrage und auf dem Client wird die Captive Portal Seite dargestellt, wo er z.B. seinen Voucher eingeben und dann lossurfen kann.

Es kann sein, dass es bei anderen Geräten, anderer Konfig usw. hier und da leicht abweichende Prozesse gibt. Fühlt euch frei hier zu ergänzen oder auch zu korrigieren wenn etwas nicht ganz stimmt.

Vielleicht weiß ja jemand auch, warum der Schritt mit dem Aufrufen der Konnektivitäts-Test-Seite überhaupt nötig ist bzw. warum nicht bereits diese Anfrage schon umgeleitet wird auf den Controller. Also warum nicht gleich schon die Anfrage an z.B. captive.apple.com oder connectivitycheck.gstatic.com auf das Captive Portal weitergeleitet wird. Würde mich auch interessieren

Beste Grüße, Gary