OPNsense - keine automatische Umleitung beim Captive Portal
Hallochen Gemeinde,
ein neues Problemchen mit der OPNsense. Im Zuge der Restrukturierung des Netzwerkes sind nunmehr ein VLAN-separiertes Gast-WLAN und das Captive Portal auf der OPNsense eingerichtet worden. Das Captive Portel wurde nach der offiziellen Anleitung erstellt und enthält noch keine individuellen Anpassungen (z.B. SSL oder eigenes Template).
Ist das Captive Portal deaktiviert bzw. nicht auf der VLAN-Schnittstelle des Gast-WLAN's gebunden, können eingeloggte Gäste problemfrei gemäß den Firewallregeln im Internet surfen. Damit steht zur Fehlerkontrolle fest, dass das keine Problemquelle ist.
Eigentlich soll das Captive Portal so funktionieren, dass der Gast in seinem Browser eine gewünschte Webseite ansteuert und zunächst auf das Captive Portal umgeleitet wird, dort den "Sign in"-Button drückt und dann zu seinem eigentlichen Ziel weitergeleitet wird. Schon die erste Umleitung unterbleibt. Irgendwann zeigt der Browser an, dass die gewünschte Webseite nicht zu erreichen sei.
Wird hingegen in einem zweiten Tab die Captive-Portal-Seite mit http://OPNsense-IP:8000 direkt angewählt, so baut sich diese Seite auf und der Anmelde-Button kann gedrückt werden. Die Beschriftung des Buttons wechselt dann zu "Logout". In dem ersten Tab kann jetzt problemfrei die gewünste Webseite angesteuert werden. Erfolgt ein Logout, so ist der Zugang zur gewünschten Webseite (bei einem Reload etc.) auch wieder gesperrt.
An dieser Situation ändert sich auch dann nichts, wenn in der Konfiguration für das Captive Portal ein SSL-Zertifikat angegeben wird. Dann muss anstelle von http eben https angegeben werden. Alles andere bleibt gleich.
Das bedeutet aus meiner Sicht, dass das Captive Portal grundsätzlich als Anmeldeschranke funktioniert. Nur die eigentlich "gesollte" Anmeldeautomatik mit der beschriebenen Umleitung funktioniert nicht.
Augenscheinlich ist das ein schon seit geraumer Zeit bestehendes Problem, wie eine Vielzahl von Anfragen im Internet belegen. Bemerkenswert dabei ist, dass in einem Fall die "gesollte" Automatik vorerst lange Zeit funktionierte und seit einem regulären Update auf die Version 22 der OPNsense die vorstehende Symptomatik zeigt. Das unterstreicht, dass das Problem jedenfalls nicht an der Konfiguration an sich liegen kann, sondern irgendwo "unter der Haube" versteckt sein muss. So auch das Credo in den vielfältigen Internetanfragen. Unverständlich ist, dass dieses Problem - immerhin sind wir aktuell bei Version 23.7.5_6 - sei längerer Zeit fortzubestehen scheint. Das ist sehr unbefriedigend.
Bei meinen Recherchen habe ich bisher keinen Lösungsansatz finden können. Wie habt ihr das gelöst? Muss unter der Haube ein Parameter gesetzt / angepasst / beseitigt / ... werden? Muss vielleicht ein fehlendes Paket nachinstalliert werden, was in der oben genannten Anleitung nicht mitgeteilt wird?
Vielen Dank für Euren Support und einen schönen Sonntag
HansDampf06
ein neues Problemchen mit der OPNsense. Im Zuge der Restrukturierung des Netzwerkes sind nunmehr ein VLAN-separiertes Gast-WLAN und das Captive Portal auf der OPNsense eingerichtet worden. Das Captive Portel wurde nach der offiziellen Anleitung erstellt und enthält noch keine individuellen Anpassungen (z.B. SSL oder eigenes Template).
Ist das Captive Portal deaktiviert bzw. nicht auf der VLAN-Schnittstelle des Gast-WLAN's gebunden, können eingeloggte Gäste problemfrei gemäß den Firewallregeln im Internet surfen. Damit steht zur Fehlerkontrolle fest, dass das keine Problemquelle ist.
Eigentlich soll das Captive Portal so funktionieren, dass der Gast in seinem Browser eine gewünschte Webseite ansteuert und zunächst auf das Captive Portal umgeleitet wird, dort den "Sign in"-Button drückt und dann zu seinem eigentlichen Ziel weitergeleitet wird. Schon die erste Umleitung unterbleibt. Irgendwann zeigt der Browser an, dass die gewünschte Webseite nicht zu erreichen sei.
Wird hingegen in einem zweiten Tab die Captive-Portal-Seite mit http://OPNsense-IP:8000 direkt angewählt, so baut sich diese Seite auf und der Anmelde-Button kann gedrückt werden. Die Beschriftung des Buttons wechselt dann zu "Logout". In dem ersten Tab kann jetzt problemfrei die gewünste Webseite angesteuert werden. Erfolgt ein Logout, so ist der Zugang zur gewünschten Webseite (bei einem Reload etc.) auch wieder gesperrt.
An dieser Situation ändert sich auch dann nichts, wenn in der Konfiguration für das Captive Portal ein SSL-Zertifikat angegeben wird. Dann muss anstelle von http eben https angegeben werden. Alles andere bleibt gleich.
Das bedeutet aus meiner Sicht, dass das Captive Portal grundsätzlich als Anmeldeschranke funktioniert. Nur die eigentlich "gesollte" Anmeldeautomatik mit der beschriebenen Umleitung funktioniert nicht.
Augenscheinlich ist das ein schon seit geraumer Zeit bestehendes Problem, wie eine Vielzahl von Anfragen im Internet belegen. Bemerkenswert dabei ist, dass in einem Fall die "gesollte" Automatik vorerst lange Zeit funktionierte und seit einem regulären Update auf die Version 22 der OPNsense die vorstehende Symptomatik zeigt. Das unterstreicht, dass das Problem jedenfalls nicht an der Konfiguration an sich liegen kann, sondern irgendwo "unter der Haube" versteckt sein muss. So auch das Credo in den vielfältigen Internetanfragen. Unverständlich ist, dass dieses Problem - immerhin sind wir aktuell bei Version 23.7.5_6 - sei längerer Zeit fortzubestehen scheint. Das ist sehr unbefriedigend.
Bei meinen Recherchen habe ich bisher keinen Lösungsansatz finden können. Wie habt ihr das gelöst? Muss unter der Haube ein Parameter gesetzt / angepasst / beseitigt / ... werden? Muss vielleicht ein fehlendes Paket nachinstalliert werden, was in der oben genannten Anleitung nicht mitgeteilt wird?
Vielen Dank für Euren Support und einen schönen Sonntag
HansDampf06
Please also mark the comments that contributed to the solution of the article
Content-ID: 668737
Url: https://administrator.de/contentid/668737
Printed on: November 13, 2024 at 12:11 o'clock
15 Comments
Latest comment
Rufst du zum Auslösen der Umleitung eine HTTP oder eine HTTPS-Seite auf? Manche CP-Lösungen können HTTPS-Seiten nicht umleiten und dann bekommt man nichts. Leider werden nutzbare HTTP-Seiten immer seltener, da sich Browser eigenständig, aber auch per HSTS, merken, ob eine Seite per HTTPS nutzbar ist und bevorzugen dieses dann.
Um dieses Problem zu umgehen, gibt es seit einiger Zeit eine Lösung, die in RFC 8910 beschrieben ist und eine DHCP-Option nutzt, um dass Endgerät auf das Captive Portal samt Login-URL zu informieren.
Um dieses Problem zu umgehen, gibt es seit einiger Zeit eine Lösung, die in RFC 8910 beschrieben ist und eine DHCP-Option nutzt, um dass Endgerät auf das Captive Portal samt Login-URL zu informieren.
Nein, die API muss schon speziell aufgebaut sein, der Client erwartet eine Antwort im json-Format. Du hast einfach nur die Anmeldeseite verlinkt, mit der der Client nichts anfangen kann. Für dein Ausweichmanöver ist keine API nötig, sondern du rufst einfach manuell die Anmeldung auf.
https://help.mikrotik.com/docs/display/ROS/HotSpot+-+Captive+portal
Ist zwar Mikrotik, aber ganz unten siehst du den Aufbau der Datei.
Wie bereits geschrieben, nutze ich selbst kein OPNsense, aber mit genau der Realisierung der 8910 bespaße ich am Tag 3000 Clients. Mit dem WLAN verbunden und der Client meldet sofort ein vorhandenes Captive Portal, ohne dass man die Konnektivitätserkennung abwarten muss.
Alternativ kann es sein, dass auf deinen Clients die Konnektivitätserkennung deaktiviert ist oder auf deiner OPNsense überbrückt wurde. Diese dürfen nicht im Walled Garden gelistet sein. Jede Plattform hat ihre eigenen URLs und diese müssen vom CP abgefangen werden. Wenn du diese durchwinkst, dann wird ein CP nicht erkannt.
https://help.mikrotik.com/docs/display/ROS/HotSpot+-+Captive+portal
Ist zwar Mikrotik, aber ganz unten siehst du den Aufbau der Datei.
Wie bereits geschrieben, nutze ich selbst kein OPNsense, aber mit genau der Realisierung der 8910 bespaße ich am Tag 3000 Clients. Mit dem WLAN verbunden und der Client meldet sofort ein vorhandenes Captive Portal, ohne dass man die Konnektivitätserkennung abwarten muss.
Alternativ kann es sein, dass auf deinen Clients die Konnektivitätserkennung deaktiviert ist oder auf deiner OPNsense überbrückt wurde. Diese dürfen nicht im Walled Garden gelistet sein. Jede Plattform hat ihre eigenen URLs und diese müssen vom CP abgefangen werden. Wenn du diese durchwinkst, dann wird ein CP nicht erkannt.
Selbstverfreilichdoch!
Auch die Range TCP 8000 bis 8002? Nur TCP 8000 freizugeben reicht zumindestens bei der pfSense nicht mehr.Wichtig: Nur reiner HTTP Traffic triggert das CP. Du musst also darauf achten das DNS sauber vorab rennt. Wenn DNS zu IP Auflösung schon scheitert kommt es gar nicht erst zur Triggerung des CP. Es ist also essentiell das DNS sauber rennt.