Captive Portal ohne Redirect

Started by Dankau, July 13, 2022, 10:38:52 AM

Previous topic - Next topic
Hallo,

unser Captive Portal leitet bei der Verbindung mit den WLAN  nicht auf die Login-Page vom Captive Portal, die Clients werden ohne Login direkt in das Internet gelassen.

Es wirkt irgendwie so, als wenn auf dem Interface kein CP aktiviert ist.
Gebe ich allerdings die IP-Adresse des Interfaces auf der OPNsense mit dem Port 8000 an, dann lädt die Login-Page von CP ganz normal und ich kann mich dort anmelden. Auch dann ist in der OPNsense eine Session zu sehen.

Das Problem ist bei uns aufgefallen, als wir von Version 21.7 auf 22 geupdatet haben. Auch eine reine Neuinstallation mit der Überspielung der alten Konfiguration funktioniert leider nicht.

Auch hilft eine Löschung und Neuanlegung der ganzen Konfiguration in der Captive Portal Administration nicht.
Bei den Firewall-Regeln haben wir schon eine "Allow any any"-Regel getestet und auch direkt die Ports 8000-10000 für die Captive Portal Page eingetragen.

Aufgrund der Größe und der Komplexität unserer derzeit bestehenden Maschinen möchten wir es gerne vermeiden, die Maschinen von Grund auf wieder neu zu konfigurieren -> Haben ca. 70 verschiedene Interfaces aktiv am laufen mit recht großen Regelwerk.

Leider sind wir da mit unserem Latein ein bisschen am Ende.

Quote from: Dankau on July 13, 2022, 10:38:52 AM
Hallo,

unser Captive Portal leitet bei der Verbindung mit den WLAN  nicht auf die Login-Page vom Captive Portal, die Clients werden ohne Login direkt in das Internet gelassen.

Es wirkt irgendwie so, als wenn auf dem Interface kein CP aktiviert ist.
Gebe ich allerdings die IP-Adresse des Interfaces auf der OPNsense mit dem Port 8000 an, dann lädt die Login-Page von CP ganz normal und ich kann mich dort anmelden. Auch dann ist in der OPNsense eine Session zu sehen.

Das Problem ist bei uns aufgefallen, als wir von Version 21.7 auf 22 geupdatet haben. Auch eine reine Neuinstallation mit der Überspielung der alten Konfiguration funktioniert leider nicht.

Auch hilft eine Löschung und Neuanlegung der ganzen Konfiguration in der Captive Portal Administration nicht.
Bei den Firewall-Regeln haben wir schon eine "Allow any any"-Regel getestet und auch direkt die Ports 8000-10000 für die Captive Portal Page eingetragen.

Aufgrund der Größe und der Komplexität unserer derzeit bestehenden Maschinen möchten wir es gerne vermeiden, die Maschinen von Grund auf wieder neu zu konfigurieren -> Haben ca. 70 verschiedene Interfaces aktiv am laufen mit recht großen Regelwerk.

Leider sind wir da mit unserem Latein ein bisschen am Ende.

Hm, blöde Frage aber wurde das CP auch aktiviert und am ende "angewendet"?
Ansonsten zeig mal bitte die Config vom CP, nur um sicher zu gehen.

Hallo,

ja, die Captive Portal Einstellungen sind aktiviert. Es funktioniert ja, wenn ich im Browser die Interface-Adresse mit dem Port angebe.
Die Settings habe ich mal als Bild angehangen.

Quote from: Dankau on July 13, 2022, 12:27:46 PM
Hallo,

ja, die Captive Portal Einstellungen sind aktiviert. Es funktioniert ja, wenn ich im Browser die Interface-Adresse mit dem Port angebe.
Die Settings habe ich mal als Bild angehangen.

Ja Einstellungen schauen korrekt aus.
Also das Problem hatte ich beim iPhone auch bei mir im Netzwerk, dieser wollte die Seite nicht anzeigen (so wie es immer in den Kaufhäusern ist, kommt es ja direkt wenn man sich mit dem Netzwerk verbindet)
Aber nach mehrmaligen Anwenden klappte es.

Wie schaut die Log aus bei "Dienste -> CP -> Protokolldatei"?

Ansonsten würde mir noch einfallen das die Schnittstelle vielleicht nicht korrekt ist.
An der Firewall habe ich nichts freigegeben, das ging von automatisch. Deswegen kannst du es auch da löschen.

Oder

Der AP ist nicht im korrekten VLAN/Schnittstelle. Ist das korrekt initialisiert?

Ansonsten, den "Anwenden"-Button habe ich ja schon angesprochen. (Dieser ist enorm wichtig! Deswegen widerhole ich das gerne nochmal)

Guten Morgen,

das einzige, was ich derzeit in der Log finden kann, ist dann der Dienst gestartet wurde: "starting captiveportal background process"

Die Schnittstelle sollte nicht das Problem sein, nach gefühlt 1000 mal überprüfen der ganzen Einstellungen kann ich mir zu 10000% sicher sein, dass die Schnittstelle die richtige ist. Das CP "antwortet" ja über die IP-Adresse der angegebenen Schnittstelle.

Das Problem ist auch wie gesagt durch das Update von 21.7 auf 22.1 aufgefallen. Wir haben das HA-Cluster (2 Maschinen mit CARP) komplett neu aufgesetzt, geupdatet und dann die alte Konfiguration wieder aufgespielt. Es sind für eine Neukonfiguration leider zu viele aktive Interfaces.

Die Firewall-Einstellungen haben wir so gemacht, damit die Clients keinen Zugriff auf die Interface-Adresse über Port 80 und 443 haben, deswegen haben wir CP-Ports freigegeben und blockieren danach den ganzen Zugriff auf das Interface. Allerdings funktioniert es auch nicht, wenn wir eine "Allow any any" Regel nach ganz oben stellen und die anderen deaktivieren.

Die APs sind hier in dem Fall nicht das Problem, es hat wie gesagt vor Version 22 so funktioniert.

Quote from: Dankau on July 14, 2022, 08:37:36 AM
Guten Morgen,

das einzige, was ich derzeit in der Log finden kann, ist dann der Dienst gestartet wurde: "starting captiveportal background process"

Die Schnittstelle sollte nicht das Problem sein, nach gefühlt 1000 mal überprüfen der ganzen Einstellungen kann ich mir zu 10000% sicher sein, dass die Schnittstelle die richtige ist. Das CP "antwortet" ja über die IP-Adresse der angegebenen Schnittstelle.

Das Problem ist auch wie gesagt durch das Update von 21.7 auf 22.1 aufgefallen. Wir haben das HA-Cluster (2 Maschinen mit CARP) komplett neu aufgesetzt, geupdatet und dann die alte Konfiguration wieder aufgespielt. Es sind für eine Neukonfiguration leider zu viele aktive Interfaces.

Die Firewall-Einstellungen haben wir so gemacht, damit die Clients keinen Zugriff auf die Interface-Adresse über Port 80 und 443 haben, deswegen haben wir CP-Ports freigegeben und blockieren danach den ganzen Zugriff auf das Interface. Allerdings funktioniert es auch nicht, wenn wir eine "Allow any any" Regel nach ganz oben stellen und die anderen deaktivieren.

Die APs sind hier in dem Fall nicht das Problem, es hat wie gesagt vor Version 22 so funktioniert.

Also langsam gehen mir dann auch die Ideen aus.
Eigentlich von 21.7 -> 22.1 sollte es nicht so einen großen Unterschied machen. Was mir noch einfallen würde, wäre das CP komplett zu löschen und wieder zu erstellen.

Ansonsten muss sich hier einer melden der ein ähnliches Problem hatte.

Leider lässt sich Captive Portal ja nicht wirklich neu installieren, bzw. wüsste ich derzeit auch nicht, wie es gehen soll. Das Captive Portal ist bei der OPNsense ja standardmäßig mit drauf, sobald eine Konfig erstellt wird, wird CP aktiviert.
Und auch schon eine Neuanlegung der ganzen Templates und Einstellungen haben wir getestet, leider auch hier ohne Erfolg.
Ich kenne wohl die Problematik, dass man kein Internet hat, wenn es z. B. DNS-Probleme gibt.
Der Fall, dass man ohne ein Login ins Internet gelassen wird ist, ist mir bis vor Kurzem noch unbekannt gewesen. Leider habe ich auch keine vergleichbaren Threads dazu im Forum gefunden.

Was mich an dem Thema aber am meisten irritiert, ist die Tatsache, dass auf dem Netz das CP aktiv ist, aber anscheinend nicht angewandt wird.
Da es mit einer Neuinstallation auch nicht funktioniert, muss es eigentlich etwas konfigurationstechnisches sein.

Zeig uns mal bitte die FW Regeln auf dem Interface
(Unoffial Community) OPNsense Telegram Group: https://t.me/joinchat/0o9JuLUXRFpiNmJk

PM for paid support

Die Firewall-Regeln habe ich mal als Bild hinzugefügt. Gehe aber nicht davon aus, dass das Problem bei den Firewall-Rules liegt.


Ne ich kann mir nicht vorstellen das es an der Firewall liegt weil sofort der Client verbunden wird ohne zu bestätigen.

Außer natürlich, in der Firewall ist der Port bzw. die OPNsense geblockt dann geht das nicht. Aber ob er sich dann automatisch einwählt, weiß ich nicht.

Ich habe mir jetzt auch mal die Konfigurationen der alten und der neuen OPNsense-Version angeschaut. Bei 21.7 wird vom Captive Portal noch die Version 1.0.0 verwendet, ab der Version 22.1 ist schon die Version 1.0.1 aktiv. Ich weiß leider nicht, was sich bei dem Update von CP getan hat, leider habe ich da keinen Change-Log oder ähnliches gefunden.

July 19, 2022, 12:52:37 PM #11 Last Edit: July 19, 2022, 12:54:56 PM by Kawachiller
Quote from: Dankau on July 19, 2022, 07:47:26 AM
Ich habe mir jetzt auch mal die Konfigurationen der alten und der neuen OPNsense-Version angeschaut. Bei 21.7 wird vom Captive Portal noch die Version 1.0.0 verwendet, ab der Version 22.1 ist schon die Version 1.0.1 aktiv. Ich weiß leider nicht, was sich bei dem Update von CP getan hat, leider habe ich da keinen Change-Log oder ähnliches gefunden.

CP wurde öfters verändert, siehe Announcement.
Ich tippe einfach auf eine defekte Konfiguration von CP die irgendwo rumdümpelt. Bei mir funktioniert's ja ohne Probleme.

Dir bleibt nichts anderes übrig als neu aufzusetzen und nur bestimmte Sachen wie Schnittstelle, Firewall etc. wiederherzustellen, halt nicht alles. Oder auf dem Backup den Part CP einfach zu entfernen. Zur Not kannst du ja n zweites System daneben installieren und es da probieren ob eine frische Installation funktioniert. Dann kannst du zu 100% davon ausgehen das es an OPNsense liegt.

Ich habe das ganze mal durchgetestet.

Wir haben ja 2 Maschinen im HA-Cluster. Habe auf der neuen Maschine die Werkseinstellungen wiederhergestellt und nach und nach die Sachen aus der Config hochgeladen. Das Interface für den Test des Captive Portals habe ich so umgelegt, dass die 2. Maschine (Backup-Maschine) und nicht die Master-Maschine. Ich hatte nur die Interfaces und die VLANs aus der Config übertragen, Firewall-Regeln hatte ich selbst eine Floating-Regel für alle Interfaces erstellt mit allow any any.

Routing usw. wurde alles manuell angelegt, sodass halt die Grundfunktionen der Firewall gegeben waren.

Sobald ich aber auch da ein Captive Portal angelegt habe und mit dem Interface verbunden hatte, das gleiche Thema.
DHCP für das VLAN + das Interface selbst hatte ich auf der Master-Maschine deaktiviert, die DCHP-Adresse habe ich also definitiv von der Backup-Maschine bekommen.
Es ist also entweder ein Problem mit dem HA-Cluster oder die Interfaces spinnen total. Ein Versuch könnte ich allerdings noch machen, indem ich das Interface nicht mit einem VLAN anlege sondern mit einer eigenen Schnittstelle in Proxmox.

Leider klappt die Änderung auch nicht. Es liegt somit entweder an den Interfaces oder an CARP (HA-Cluster).

Eine neu aufgesetzte Maschine nur mit dem VLAN und Captive Portal funktioniert.

Mal schauen. Sobald bei uns die RADIUS-Authentifizierung im WLAN auch mit dem Android 12 Thema und den Zertifikaten einwandfrei funktioniert, ist bei uns das CP obsolet.