Unifi: Portalseite wird von vielen Apple-Geräten nicht mehr geladen

Hi.
Wir nutzen Unifi-APs und einen Controller mit Gastzugang + Portalseite zum Anmelden. Das lief bisher reibungslos doch nun häufen sich die Beschwerden, dass hauptsächlich auf Apple-Geräten die Portalseite nicht mehr geladen wird und man sich somit auch nicht am Netzwerk anmelden kann. Unter Android hingegen gibt es das Problem nicht. Hat jemand ähnliches beobachtet und eine gute Idee, woran das liegen kann? Ist das evtl ein SSL-Cert-Problem, das Apple voraussetzt o.ä.?
Viele Grüße,
Michael

Hi Michael,

kann dir keine Lösung nennen, nur deine Beobachtung bestätigen und vielleicht einen Tipp geben. Ich habe viel Zeit investiert die Sache zu debuggen und viel versucht aber das Problem bleibt bestehen und ist ein absoluter show stopper. Weil wir (leider!!) wirklich viele IPad’s zu versorgen haben, habe ich in meiner Not vom Unifi zum Captive Portal auf der OpnSense gewechselt (https://docs.opnsense.org/manual/captiveportal.html). Hier gibt es diese Probleme nicht und zudem ist das Teil einfach absolut genial! Super einfache Anbindung an die AD, API für Voucher und in Zusammenhang mit dem AcmeClient auch eine https-Portalseite mit Letsencrypt. Die Portalseite ist auch sehr einfach anpassbar. Es melden sich bei mir täglich im Moment im Schnitt zwischen ca. 7:15 und 7:45Uhr etwa 350-400 User an und es gibt keine Performanceprobleme, so wie ich sie mit Unifi häufig hatte.
VG
Dominik

Hallo Dominik,
Ja, das hatte ich schon mal so — allerdings bietet das UniFi Portal bei uns im Moment die Möglichkeit, das man sich entweder per Login oder per Voucher anmelden kann. Das kann das Portal der opnsense leider nicht, fürchte ich?!?
Viele Grüße
Michael

Hi alle :slight_smile:
ich fürchte, es liegt daran, dass ordentliche SSL-Zertifikate häufiger Voraussetzung für ordentliche Transportsicherung werden, was ja für sich gesehen eine gute Sache ist. Kann also sein, dass ein korrektes Zertifikat im unifi-Controller das Problem löst. (Welches bei falschen Zertifikaten in der OPNsense auch auftreten würde).
Das jetzt den iPads anzulasten finde ich nicht fair :slight_smile: Letztendlich ist das wohl das gewünschte Verhalten, wenn Passworteingaben auf unsicheren Verbindungen nicht akzeptiert werden.
Wahrscheinlich ziehen da die Androiden früher oder später nach…

Und der Vollständigkeit halber:

OPNsense ist genial: ACK
API für Voucher hat Unifi auch und
Korrekte Zertifikate kann man auch mit Unifi verwenden, muss sich allerdings um die Beschaffung selbst kümmern.

Liebe Grüße Jesko

Hallo Michael,

doch, dass klappt…auch beides gleichzeitig auf einer Portalseite.

VG

Dominik

Lieber Jesko,

nee, dass war leider nicht das Problem. Ich hatte da ein korrektes Zertifikat! Ich konnte wie gesagt keine Lösung dafür finden, dass v.a. IPads und IPhones einfach nicht auf die Portalseite geleitet wurden…bei allen anderen Betriebssystemen und Geräten gab es das Problem auch nicht…im Übrigen auch nicht bei Mac’s…

LG
Dominik

Hi.
Das was Dominik schreibt, ist hier ganz genauso. Die Portalseite wird auf :apple:-Geräten nicht zuverlässig geladen … und wenn sie doch erscheint und man sich angemeldet hat, verschwindet die Seite auch nicht automatisch wieder. Dann muss man irgendwie „erraten“, dass die Anmeldung erfolgreich war und kann sie wegklicken. Das läuft also im Moment mit :apple:-Geräten nicht zuverlässig. (Android hat das Problem wie oben schon gesagt im Moment (noch?) nicht).

Ich hatte vor einiger Zeit ja schon mal ein Script gebastelt, mit dem man dem Unifi-Controller ein gültiges LE-Zertifikat verpassen kann:

Das funktioniert hier auch, doch so wie ich das sehe, läuft das Gastportal gar nicht über SSL sondern bei uns lediglich auf Port 80 mit der Adresse http://<NAME-DES-UNIFI-CONTROLLERS>/guest/s/default/
Es kann also schon sein, dass das bereits die Ursache ist und man das Portal nur auf SSL / Port 443 mit gültigem LE-Zertifikat legen muss!? Da weiß ich aber leider nicht, wie/wo man das umstellen kann!? Es reicht jedenfalls nicht, dass man in den Unifi-Einstellungen unter „Gaststeuerung“ lediglich [x] Sicheres Portal verwenden anklickt.

Ein anderer Gedanke dazu: Ein Schüler meinte, dass Apple immer über die URL „captive.apple.com“ prüft, ob das Gerät online ist. Wenn dort „Success“ gemeldet wird, ist es offensichtlich online. Die Prüfung kann ja erst nach erfolgreicher Anmeldung am Captive-Portal positiv ausfallen. Angeblich wird man bei nicht erfolgreicher Prüfung auf das eigene Captive-Portal umgeleitet, doch auch das funktionierte hier nicht zuverlässig. Kann das von Euch jemand so bestätigen?

Gestern Abend habe ich den Unifi-Controller (bei uns zZ noch Version 6.5.55_16678) sowie das „zugehörige“ Pi-Hole neu gestartet. Außerdem hatte ich dem Unifi-Controller nochmal manuell mit o.g. Script ein Zertifikat verpasst. Heute lief es dann wieder – bis auf die Tatsache, dass das Captive-Portal trotzdem nicht automatisch verschwindet.

Die Möglichkeiten des OPNSense-Captive-Portals hatte ich vor einiger Zeit ausprobiert. Es funktionierte hier auch auf Anhieb damit aber leider ist die Verwaltung der Voucher nicht so elegant geregelt wie unter Unifi. Zudem haben wir ja den sagenhaften Voucher-Drucker, der einem direkt ein passendes Ticket ausdrucken kann. Auf den würden wir im Moment nur ungern verzichten. Daher würde ich unter’m Strich eigentlich gerne bei Unifi bleiben.

Vielleicht finden wir ja doch noch heraus, wo es klemmt.
Viele Grüße,
Michael

Hi.
Ich pushe den Thread nochmal nach oben … leider nehmen die Probleme mit dem Captive-Portal und den WLAN-Geräten eher zu als ab.

Ich habe die Schüler der Oberstufe auf dem Server mit
sophomorix-managementgroup --set-wifi oberstufe
ins WLAN gebracht. Das wird auch richtig angezeigt, wie mir
sophomorix-managementgroup -i -m wifi -v bestätigt.

Leider bekommen viele (nicht alle?) Schüler beim Anmelden am Captive-Portal die Meldung:
LDAP bind successful
LDAP login failed
Das verstehe ich nicht … ich habe es auch nochmal mit meinem Lehrer-Login ausprobiert und da funktioniert’s.

Zu Testzwecken habe ich dann nochmal ein WPA2-Enterprise-WLAN auf den Unifi-Accesspoints mit aktiviert. Das fordert auf :apple:-Geräten ganz wie es sein soll sofort den Usernamen und das Passwort, stolpert dann aber über ein ungültiges Zertifikat. Daher nochmal die Frage in die Runde: Hat jemand seinen Freeradius-Server um ein gültiges LE-Cert ergänzt, so dass die Zertifikatswarnung nicht mehr erscheint?

Viele Grüße,
Michael

Hallo Michael,

einen Radiusserver kann man prinzipbedingt nicht so absichern, dass
Zertifikate automatisch akzeptiert werden.

Bei Webseiten geht das: Der User ruft eine URL auf, und wenn das
Zertifikat für den darin enthaltenen Hostnamen ausgestellt ist und die
Zertifizierungskette passt, dann wird das Zertifikat akzeptiert.

Bei WLAN mit Radius verbindet man sich mit einem WLAN. Das hat als Namen
eine SSID, und für eine SSID kann man kein Zertifikat bekommen, denn die
sind frei wählbar. Und auch der Radiusserver - der ja einen FQDN hat,
für den man durchaus ein Zertifikat bekommen kann - ist ja nicht
eindeutig mit dem WLAN verknüpft.

Man muss also immer die Zertifikate auf die Geräte übertragen, wenn man
auf den Geräten die Zertifikatsprüfung nicht abschalten kann.

Denkbar wäre zwar eine Abfrage wie „Das WLAN namens Blabla möchte Dich
auf dem Server server.example.com anmelden - ist das OK?“ - aber das ist
meines Wissens nicht vorgesehen.

Beste Grüße

Jörg

Hallo Michael,

Leider bekommen viele (nicht alle?) Schüler beim Anmelden am
Captive-Portal die Meldung:

LDAP bind successful|
LDAP login failed|

… na da hat wohl jemand sein Passwort falsch eingegeben … oder den
Benutzernamen groß geschrieben …

Zu Testzwecken habe ich dann nochmal ein WPA2-Enterprise-WLAN auf den
Unifi-Accesspoints mit aktiviert. Das fordert auf :apple:-Geräten ganz
wie es sein soll sofort den Usernamen und das Passwort, stolpert dann
aber über ein ungültiges Zertifikat. Daher nochmal die Frage in die
Runde: Hat jemand seinen Freeradius-Server um ein gültiges LE-Cert
ergänzt, so dass die Zertifikatswarnung nicht mehr erscheint?

ich habe ein Zertifikat selber erstellt für das WLAN: neuere Androiden
müssen eine Datei auf ihrem GErät einmal doppelklicken, dann klappt das
auch mit dem WLAN …
Bei Apfel wird es nciht anders sein.
Wie ich vorgegangen bin steht in einem Tread hier in ask.

LG

Holger

Hallo Holger.

Vermutlich meinst Du diesen Thread:

Ich schaue mir das nochmal an …
Viele Grüße,
Michael

Hi.
Es ist nur eine kleine Beobachtung aber vielleicht wird jemand daraus schlau:
Wenn man auf :apple: -Geräten die WLAN-Option „Private WLAN-Adresse“ (also die zufällige MAC-Adresse, die ständig neu erzeugt wird, um tracking zu erschweren) deaktiviert, läuft es offenbar besser!?
Zumindest wurde ohne diese Option dann auch auf Apple-Geräten sofort die Captive-Seite geladen (auch wenn sie auch weiterhin nicht wieder automatisch verschwunden ist). Vielleicht ist das ein Anhaltspunkt … ??

Hat von Euch schon jemand die Unifi-Controller-Software in Version 7 installiert? Wäre ja mal interessant, ob das Portal damit überhaupt noch läuft…

Viele Grüße,
Michael

Hi,
der Hinweis von @Michael („Private-WLAN-Adresse“ deaktiviert) hat bei uns schon einen Teilerfolg gebracht.
Zusätzlich habe ich die Erfahrung gemacht, dass ein _ („Unterstrich“) im Benutzernamen das ebenfalls verhindert: Am selben Gerät konnte sich ein Lehrer mit _ nicht anmelden, ein Schüler sowei ich (ohne _) dagegen schon.
Hilft das weiter?
LG Ralf