15
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668737
Url: https://administrator.de/forum/opnsense-keine-automatische-umleitung-beim-captive-portal-668737.html
Ausgedruckt am: 22.12.2024 um 03:12 Uhr
15 Kommentare
Neuester Kommentar
Hast du im Regelwerk des CP Interfaces auch die Redirect Ports geöffnet wie hier bei der pfSense
Ist das nicht geschehen scheitert natürlich der Redirect.
Zu mindestens bei der pfSense funktioniert das CP mit oder ohne Zertifikat absolut problemlos.
Zu mindestens bei der pfSense funktioniert das CP mit oder ohne Zertifikat absolut problemlos.
1
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.
Zitat von @aqui:
Hast du im Regelwerk des CP Interfaces auch die Redirect Ports geöffnet wie hier bei der pfSense
Selbstverfreilichdoch!Hast du im Regelwerk des CP Interfaces auch die Redirect Ports geöffnet wie hier bei der pfSense
Diese Regel ist sogar bei den auf die VLAN-Schnittstelle bezogenen Regeln die oberste. Dem gehen - ähnlich wie in der genannten Anleitung - die Regeln für DNS und DHCP vor, die bei mir aber in einer übergreifenden Gruppe eingestellt sind. Sofern das bei der pfSense nicht so sein sollte: Unter Firewall können Schnittstellengruppen angelegt werden, um für diese Gruppen Regeln etablieren zu können, die für die betreffenden Gruppenschnittstellen gemeinsam / übergreifend gelten. Das funktioniert sehr gut und schafft strukturierte Ordnung bei den Regeln. So muss auch nicht jedes Fahrrad mehrmals erfunden werden. Beispielsweise beim DNS dürfen Anfragen nur an die internen DNS-Server gerichtet werden. Die Ansprache an andere DNS-Server wird geblockt.
Angeregt durch Deinen Kommentar habe ich probeweise die Regel für die CP-Ports dahingehend abgewandelt, dass als Ziel nicht die OPNsense-IP-Adresse für das VLAN, sondern jeglich ausgewählt ist. Spielt keine Rolle - alles beim Alten. Es geht nur wie beschrieben mit dem zweiten Tab.
Für etwaige Nachfragen:
Die zweite Regel blockt den Zugriff auf die anderen internen Netze.
Die dritte Regel blockt den Zugriff auf die VLAN-OPNsense-IP zur Verhinderung eines GUI-Zugriffs.
Die vierte Regel erlaubt den Web-Access.
Was ich zunächst bei der Fehlersuche, also vor dem Verfassen des hiesigen Beitrags, ebenfalls probiert hatte, war eine Gastnetz-any-any-Regel an oberster Stelle, um jedweden Zugriff zu erlauben, falls so die Problematik sichtbar werden sollte. Ein anderer problemgeplagter User hatte das ebenso erfolglos probiert. Deswegen ja auch meine Vermutung, dass unter der Haube irgendetwas nicht stimmt, das jedenfalls nicht über die GUI korrigiert werden kann.
Viele Grüße
HansDampf06
Zitat von @tikayevent:
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.
Ja, dass wird in verschiedenen Problemdiskussionen erörtert. Deswegen hatte ich es sowohl so als auch so ausprobiert. Spielt keinerlei Rolle. Es hilft nur der zweite Tab, und zwar egal, ob er per http oder https angelaufen wird.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.
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.
Es wäre ein Ansatz, im ISC-DHCP-Server eine solche Option für das Gastnetz zu setzen, wenn das eine Linderung bringen sollte.Dennoch sollte es eigentlich die OPNsense auch von sich aus schaffen. Oder mag es die OPNsense im Falle des Captive Portal nicht, wenn die DHCP-Leases per DHCP-Relay von einem zentralen DHCP-Server vergeben werden? Baut der OPNsense-eigene DHCP-Server etwa diese Option in die Lease-Vergabe ein?
Viele Grüße
HansDampf06
Ich kenn das CP von OPNsense nicht, aber etliche CP-Umsetzungen sprechen direkt mit dem DHCP-Server und erhalten darüber Infos über neue Clients. Für eine korrekte Funktion muss der DHCP-Server dann unmittelbar mit dem CP kommunizieren können.
Zitat von @tikayevent:
Ich kenn das CP von OPNsense nicht, aber etliche CP-Umsetzungen sprechen direkt mit dem DHCP-Server und erhalten darüber Infos über neue Clients. Für eine korrekte Funktion muss der DHCP-Server dann unmittelbar mit dem CP kommunizieren können.
Eine solche Notwendigkeit ist bei OPNsense nicht erwähnt oder gar beschrieben (jedenfalls habe ich es nicht wahrgenommen), so dass ich davon ausgehe, dass das Captive Portal von OPNsense nicht zu dieser Art CP-Umsetzungen gehört.Ich kenn das CP von OPNsense nicht, aber etliche CP-Umsetzungen sprechen direkt mit dem DHCP-Server und erhalten darüber Infos über neue Clients. Für eine korrekte Funktion muss der DHCP-Server dann unmittelbar mit dem CP kommunizieren können.
Viele Grüße
HansDampf06
PS: Kann mir jemand sagen, wie ich die Option 160 (= älteres RFC 7710) oder die Option 114 (= RFC 8910) richtig definiere? Beide Optionen werden vom ISC DHCP unterstützt laut Optionsliste. Aber ums Verrecken kann ich nichts finden, insbesondere nicht in den offiziellen Dokumenten, wo eine Definition dieser Optionen in der dhcpd.conf beschrieben ist.
Mit der Option 114 ist es nicht getan, das Captive Portal muss auch die entsprechende API bereitstellen und auf die API wird nur per HTTPS zugegriffen.
Effektiv wird über 114 nur ein String mit der URL zur API übertragen.
Effektiv wird über 114 nur ein String mit der URL zur API übertragen.
Zitat von @tikayevent:
Mit der Option 114 ist es nicht getan, das Captive Portal muss auch die entsprechende API bereitstellen und auf die API wird nur per HTTPS zugegriffen.
Effektiv wird über 114 nur ein String mit der URL zur API übertragen.
Mit der Option 114 ist es nicht getan, das Captive Portal muss auch die entsprechende API bereitstellen und auf die API wird nur per HTTPS zugegriffen.
Effektiv wird über 114 nur ein String mit der URL zur API übertragen.
Das habe ich hinsichtlich der Optionen 114 und 160 auch so verstanden. Mittlerweile habe ich die richtige Optionsbezeichnung herausgefunden und in der dhcpd.conf eingetragen:
#Option 160:
option default-url "https://OPNsense-IP:8000";
#Option 114:
option v4-captive-portal "https://OPNsense-IP:8000"; Hilft nur alles leider nichts. Jedenfalls zeigt sich das zum Testen verwendete Samsung-Tablet unbeeindruckt. Ein vorsorglich zum Testen hinzugezogenes Lenovo-Notebook mit Windows 10 ist ebenfalls unbeeindruckt. Es bleibt vorerst beim zweiten Tab für ein Freischalten.
Im Übrigen gehe ich davon aus, dass OPNsense die notwendige API bereitstellt, sonst würde ja das Ausweichmanöver mit dem zweiten Tab nicht funktionieren, oder?
Viele Grüße
HansDampf06
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.
Zitat von @tikayevent:
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.
Das Captive Portal wird einzig und allein über den betreffenden Punkt Verwaltung erzeugt und konfiguriert. Es kann mehrere konfigurierte Captive Portal geben.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.
Das heißt, dass alles, was ich für ein funktionierendes Captive Portal benötige, dort abzufrühstücken ist. Irgendwelche JSON-Einstellungen sind dort weder ersichtlich noch von den Machern von OPNsense beschrieben. Auch ist nicht erkennbar, dass noch irgendwo eine JSON-Konstruktion zu definieren sei. Mithin sollte OPNsense alles an den Client liefern, was er benötigt, damit das mit dem Captive Portal klappt.
Ist zwar Mikrotik, aber ganz unten siehst du den Aufbau der Datei.
Somit dürfte mir das bei der OPNsense nicht weiterhelfen, so lange ich nicht weiß, ob und wenn ja wo derartiges auf der OPNsense einzurichten wäre. Nach meinem Verständnis ist das mit dem Verwaltung-Punkt nicht notwendig.Ich habe noch einmal nachgeschaut und die unter dem Verwaltung-Punkt zur Verfügung stehenden Konfigurationsmöglichkeiten bieten nichts weiter an, was für ein grundsätzlich funktionierendes einfaches Captive Portal noch zusätzlich erforderlich wäre.
Alternativ kann es sein, dass auf deinen Clients die Konnektivitätserkennung deaktiviert ist
Das glaube ich eher nicht, weil dies bei Fremd-CP's anstandslos funktioniert und auf einem Android-Handy wohl auch nicht deaktiviert werden kann.Deswegen habe ich das soeben mit meinem Handy getestet. Es gibt keine automatische Weiterleitung zur CP-Seite bzw. die von Fremd-CP gewohnte Anmeldeaufforderung. OPNsense scheint nichts mitzuteilen.
oder auf deiner OPNsense überbrückt wurde.
Ich wüsste nicht, bei welcher Gelegenheit das erfolgt sein könnte.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.
Deswegen habe ich soeben probeweise die Gast-VLAN-Schnittstelle aus der Gruppenzuordnung genommen, so dass sie jetzt absolut isoliert konfiguriert werden muss. Vorsorglich ist eine Regel für DNS und DHCP zunächst vor die CP-Port-Regel gesetzt und im zweiten Test dahinter verschoben worden.Es bleibt auf allen Geräten so, wie es ist: ein zweiter Tab.
Gibt es denn niemanden, der OPNsense mit einem Captive Portal im Einsatz hat und bei dem es mit einer Version ab 23.7(.5) funktioniert?
Viele Grüße
HansDampf06
Hab eben mein OPNsense-Kistchen ausgebuddelt, voll durchaktualisiert und ein CP gemäß Anleitung angelegt.
Wird sofort umgeleitet, wenn ich eine HTTP-Seite (in meinem Fall webfail.at) aufrufe. DNS und DHCP liegen auf der Kiste.
Wird sofort umgeleitet, wenn ich eine HTTP-Seite (in meinem Fall webfail.at) aufrufe. DNS und DHCP liegen auf der Kiste.
Zitat von @tikayevent:
Wird sofort umgeleitet, wenn ich eine HTTP-Seite (in meinem Fall webfail.at) aufrufe. DNS und DHCP liegen auf der Kiste.
Ich befürchte, dass sich meine bereits in eine Frage gekleidete Vermutung bestätigen könnte und OPNsense beim Captive Portal keine anderen DHCP- und DNS-Server mag als die direkt auf der OPNsense.Wird sofort umgeleitet, wenn ich eine HTTP-Seite (in meinem Fall webfail.at) aufrufe. DNS und DHCP liegen auf der Kiste.
Dennoch:
Mit welcher Version von OPNsense hast Du es probiert?
Könntest Du es auch einmal mit einem DHCP-Relay probieren? Und / oder mit einem DNS-Server im Netz?
Viele Grüße
HansDampf06
Zitat von @HansDampf06:
Ich befürchte, dass sich meine bereits in eine Frage gekleidete Vermutung bestätigen könnte und OPNsense beim Captive Portal keine anderen DHCP- und DNS-Server mag als die direkt auf der OPNsense.
Das scheint sich zu bestätigen. Ich hatte jetzt alle DHCP-Relays deaktiviert, den isc-dhcp-server-service auf dem (zentralen) DHCP-Server beendet und für die Gast-VLAN-Schnittstelle einen ISC-DHCPv4 auf der OPNsense eingerichtet. Die Firewall-Regeln für die Schnittstelle sind isoliert. Nach der CP-Port-Regel kommt eine Gast-any-any-Regel, so dass alles erlaubt ist.Ich befürchte, dass sich meine bereits in eine Frage gekleidete Vermutung bestätigen könnte und OPNsense beim Captive Portal keine anderen DHCP- und DNS-Server mag als die direkt auf der OPNsense.
Wenn ich jetzt mit dem Tablet eine DHCP-Lease ziehe, dann funktioniert beim Aufruf einer http-Seite die Umleitung über die CP-Seite und nach dem Betätigen des dortigen Buttons öffnet sich die http-Seite. Rufe ich im zweiten Tab die CP-Seite auf und logge mich aus, so läuft der erneute Aufruf der http-Seite wieder über die CP-Seite.
Das Gleiche mit dem Handy funktioniert nicht so sicher.
Baue ich das Ganze wieder auf das DHCP-Relay um, hilft nur wieder der Login über den zweiten Tab.
Das deute ich dahin, dass OPNsense nur dann die erstmalige Umleitung ausführt, wenn die DHCP-Leases von der OPNsense generiert wurden. Insgesamt scheint die CP-Implementation von OPNsense fragil zu sein, weil auch bei Nutzung des eigenen DHCP-Servers (also ohne DHCP-Relay) die Umleitung nicht sicher funktioniert. Das ist enttäuschend und in Bezug auf ein benötigtes / gewolltes / gesolltes / ... DHCP-Relay sogar völlig unbefriedigend. Warum geht das bei der OPNsense nicht in einer Art transperentem Modus?
Kann jemand diese sich abzeichnende Erkenntnis bestätigen?
Eine weitere Feststellung:
Sobald ich mich einmal über den zweiten Tab eingeloggt und die http-Seite dann aufgerufen habe, funktioniert nach einem Logout im zweiten Tab das Umleiten auch direkt bei der http-Seite. Gleichwohl ist und bleibt die erstmalige Umleitung das Entscheidende, weil sich ein Gast nach dem (erstmaligen) Login wohl nicht aktiv ausloggen (wollen) wird.
Zumindest nährt diese Feststellung den Gedanken, dass OPNsense dann, wenn die DHCP-Lease nicht von der OPNsense vergeben wird, den Gast-Client erst "kennenlernen" muss, damit das mit der Umleitung klappt. Offen ist zudem, ob hier die VLAN-Bindung des Gastnetzes eine Rolle spielen könnte.
Viele Grüße
HansDampf06
PS: Die zwei https-Testseiten (geizhals.de und ebay.de) wollten die Umleitung im Fennec (Firefox ESR über f-droid) nicht mitmachen und gaben als Begründung für die Ablehnung von erweiterten Möglichkeiten den HSTS-Mechanismus an. Für die Tests hatte ich nämlich kurzhand nur ein selbstgeneriertes Zertifikat. Mit einem passenden Zertifikat würde es vermuttlich wie bei der http-Seite funktionieren.
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.
Abermals selbstverfreilichdoch. Denn laut OPNsense-Anleitung soll 8000 bis 10000 freigegeben werden, so dass ich das vorerst auch so umgesetzt habe. (Gleichwohl habe ich Zweifel, dass es eines solch großen Portbereichs bedürfen würde, aber was soll's.) Nicht umsonst habe ich diese Anleitung gleich zu Beginn verlinkt und mitgeteilt, dass ich mich daran gehalten habe!
Hinsichtlich des DNS hatte ich ja außerdem beschrieben, dass die erforderliche Regel in einer vorrangigen und übergreifenden Gruppenregel definiert ist, wobei die Gast-VLAN-Schnittstelle selbstredend ein Mitglied ist. Und ja, die lokale DNS-Auflösung "rennt sauber". Das gilt in jedem Fall für die Testseiten geizhals.de und ebay.de.
Ferner beschrieb ich am Ende meines Kommentars, dass ich die Regeln für die Schnittstelle auch probeweise isoliert gesetzt habe und dass das keinen Unterschied machte für das Problem.
Weiters wies ich in meinem Eingangspost ausdrücklich darauf hin, dass der Internetzugriff einschränkungslos funktioniert, wenn das Captive Portal nicht auf die Gast-VLAN-Schnittstelle gebunden ist. Das schließt selbstredend die "sauber rennende" DNS-Auflösung mit ein.
Im Übrigen habe ich ja gestern bis tief in die Nacht dem Problem "herumgemacht". In meinem anschließenden Kommentar teilte ich meine Feststellungen. Es käme jetzt darauf an, dass jemand, vielleicht @tikayevent, in (s)einer Teststellung nachvollzieht, ob ebenfalls bei einer DHCP-Lease-Vergabe direkt durch die OPNsense das Captive Portal klappt, während eine Vergabe per DHCPRelay nur über den beschriebenenn zweiten Tab zu einem freigegebenen Internetzugriff führt.
Rund wäre eine solche Überprüfung, wenn dann noch über den zweiten Tab ein Logout erfolgt und anschließend probiert wird, ob eine Erneuerung der Webseite nunmehr über die Umleitung des Captive Portal läuft. Hier habe ich ein gemischtes Verhaltensbild. So oder so stünde damit fest, wo das Problem liegt: Bei einer Fremd-DHCP-Lease-Vergabe lernt die OPNsense das DHCP-anfragende Gerät nicht vorher kennen und benötigt dafür einen einmaligen Login. Gegebenenfalls vergißt es das Gerät wieder, wenn ein Logout erfolgt.
Die Lösung des Problems müsste im Falle einer Bestätigung darin liegen, die OPNsense dergestalt an der Lease-Vergabe teilhaben zu lassen, als ob sie selbst die Lease vergeben hätte - jedenfalls im Sinne des "Kennenlernens" des anfragenden Geräts und des "Behaltens" dieser Information für die Dauer der Lease. Bei einer Lease-Erneuerung müsste das "Behalten" gleichsam aufgefrischt werden.
Alternative: OPNsense müsste bei aktiviertem Captive Portal immer als eine Art Web-Proxy (transparenter Modus) laufen und dabei auf ein vorhandenes Login für das betreffende Gerät prüfen.
Viele Grüße
HansDampf06
PS: Zu meiner Problembeschreibung/-erkenntnis bin ich gekommen, weil ich per Wireshark die DHCP-Pakete bei den beiden Varianten der Lease-Vergabe verglichen habe. Dort gab es keine Unterschiede. Insbesondere wurden keine Optionen 114 oder 160 mitgeteilt. Wenn aber nichts mitgeteilt wird, das das anfragende Gerät besonders informieren würde, muss der Prozess, der OPNsense befähigt, auf den anschließenden Webseitenzugriff mit der Umleitung zum Captive Portal zu reagieren, intern laufen. Und das Ergebnis dieses internen Prozess muss die interne Information sein, dass das anfragende Gerät mit dem Captive Portal zu bespaßen ist. Nur mal so als Interpretationsansatz.
Hinsichtlich des DNS hatte ich ja außerdem beschrieben, dass die erforderliche Regel in einer vorrangigen und übergreifenden Gruppenregel definiert ist, wobei die Gast-VLAN-Schnittstelle selbstredend ein Mitglied ist. Und ja, die lokale DNS-Auflösung "rennt sauber". Das gilt in jedem Fall für die Testseiten geizhals.de und ebay.de.
Ferner beschrieb ich am Ende meines Kommentars, dass ich die Regeln für die Schnittstelle auch probeweise isoliert gesetzt habe und dass das keinen Unterschied machte für das Problem.
Weiters wies ich in meinem Eingangspost ausdrücklich darauf hin, dass der Internetzugriff einschränkungslos funktioniert, wenn das Captive Portal nicht auf die Gast-VLAN-Schnittstelle gebunden ist. Das schließt selbstredend die "sauber rennende" DNS-Auflösung mit ein.
Im Übrigen habe ich ja gestern bis tief in die Nacht dem Problem "herumgemacht". In meinem anschließenden Kommentar teilte ich meine Feststellungen. Es käme jetzt darauf an, dass jemand, vielleicht @tikayevent, in (s)einer Teststellung nachvollzieht, ob ebenfalls bei einer DHCP-Lease-Vergabe direkt durch die OPNsense das Captive Portal klappt, während eine Vergabe per DHCPRelay nur über den beschriebenenn zweiten Tab zu einem freigegebenen Internetzugriff führt.
Rund wäre eine solche Überprüfung, wenn dann noch über den zweiten Tab ein Logout erfolgt und anschließend probiert wird, ob eine Erneuerung der Webseite nunmehr über die Umleitung des Captive Portal läuft. Hier habe ich ein gemischtes Verhaltensbild. So oder so stünde damit fest, wo das Problem liegt: Bei einer Fremd-DHCP-Lease-Vergabe lernt die OPNsense das DHCP-anfragende Gerät nicht vorher kennen und benötigt dafür einen einmaligen Login. Gegebenenfalls vergißt es das Gerät wieder, wenn ein Logout erfolgt.
Die Lösung des Problems müsste im Falle einer Bestätigung darin liegen, die OPNsense dergestalt an der Lease-Vergabe teilhaben zu lassen, als ob sie selbst die Lease vergeben hätte - jedenfalls im Sinne des "Kennenlernens" des anfragenden Geräts und des "Behaltens" dieser Information für die Dauer der Lease. Bei einer Lease-Erneuerung müsste das "Behalten" gleichsam aufgefrischt werden.
Alternative: OPNsense müsste bei aktiviertem Captive Portal immer als eine Art Web-Proxy (transparenter Modus) laufen und dabei auf ein vorhandenes Login für das betreffende Gerät prüfen.
Viele Grüße
HansDampf06
PS: Zu meiner Problembeschreibung/-erkenntnis bin ich gekommen, weil ich per Wireshark die DHCP-Pakete bei den beiden Varianten der Lease-Vergabe verglichen habe. Dort gab es keine Unterschiede. Insbesondere wurden keine Optionen 114 oder 160 mitgeteilt. Wenn aber nichts mitgeteilt wird, das das anfragende Gerät besonders informieren würde, muss der Prozess, der OPNsense befähigt, auf den anschließenden Webseitenzugriff mit der Umleitung zum Captive Portal zu reagieren, intern laufen. Und das Ergebnis dieses internen Prozess muss die interne Information sein, dass das anfragende Gerät mit dem Captive Portal zu bespaßen ist. Nur mal so als Interpretationsansatz.
