LogIn-Seite vor Captive Portal LogIn Seite

[NausB]

Versionen
OPNsense 26.1.2-amd64
FreeBSD 14.3-RELEASE-p8
OpenSSL 3.0.19

Moin.
Ich hoffe jemand hier kann mir weiterhelfen:
Ich versuche gerade vor der CaptivePoral Login Seite eine "Komfort-Login" Seite zu schalten.
Diese Seite greift auf die api Schnittstelle zu und soll Gästen einen einfach Login per QR-Code Scan und Eingabe von Zimmernummer und Nachnamen ermöglichen.
Das Prinzip ist so:
Gast scannt QR-Code
QR Code öffnet eine Seite, deren IP Adresse durch Unbound-DNS "unsichtbar" gemacht wird
Der Gast sieht also weder IP Adresse noch Port auf den ersten Blick in seiner Adresszeile
Hier erscheint dann eine Anmeldeseite, wo der Gast seine Zimmernummer und den Nachnamen eingibt.
Diese Daten werden dann anhand einer aktuellen Liste gegen geprüft und wenn es Übereinstimmungen gibt, erfolgt der LOGIN.
Bei keinen Übereinstimmungen, zu häufigen Falscheingaben oder der nicht vorhandener Möglichkeit einen QR Code zu scannen ist es weiterhin möglich per Button auf die "normale" Login Seite zu kommen und dort wie gewohnt User und Passwort einzugeben.

Nun habe ich das Problem, dass bei neueren Geräten die Weiterleitung auf den entsprechenden Port blockiert wird.
Das dann auch ohne Meldung im Logfile der Firewall.
Bei einem alten Samsung A40 oder einem aktuellen PEAQ PET10182 hingegen klappt es ohne Probleme.
Also in der Sache funktioniert das ganze.
Nur halt nicht zuverlässig.

Firewall Regel ist hier
Protokoll: IPv4 TCP
Quelle: Gästenetzwerk (IP 10.0.1.X)
Ziel: Server-Netzwerk (IP 100.10.0.X)
Port: 18060

Irgendjemand eine Idee, wie man das sauber hinbekommt?
Es scheint mehr oder weniger eine Firewall Regel zu sein, da der Traffic an einer Stelle noch geblockt wird.

100.10.0.5/32 und 10.0.1.1/32 sind zugelassene Adressen im CaptivePortal

Funktionieren tut das zum Teil, allerdings nicht immer zuverlässig.

[viragomann]

Nun habe ich das Problem, dass bei neueren Geräten die Weiterleitung auf den entsprechenden Port blockiert wird.

Welche Weiterleitung?
Du hast doch geschrieben, dass die Seite per QR-Code-Scan geöffnet wird. Wo wird dann weitergeleitet?

Vielleicht mögen die Geräte den verdeckten speziellen Port nicht?
Ich verstehe aber auch nicht, wie der verschleiert sein soll, wenn er im QR-Code steckt. Ist die Funktionsbeschreibung wirklich vollständig?

Um den Port speziellen Port loszuwerden, könntest du jedenfalls einen Reverse-Proxy in Betracht ziehen.

[NausB]

Kernfrage aus meinen ersten Punkten wäre wohl eher:

**Wie bekommt man unter OPNsense 26.1.2 einen internen Webserver zuverlässig als Walled-Garden-/Pre-Auth-Ziel vor dem Captive-Portal-Login erreichbar?**

Daher danke für die Rückfrage, meine Beschreibung war vermutlich nicht präzise genug.

Sind die **Allowed Addresses** im Captive Portal dafür der richtige Weg, oder braucht es zusätzlich eine andere Konfiguration?
Und gibt es bekannte Besonderheiten, wenn das Ziel in einem anderen internen Netz liegt, also z. B.:

`GUESTNET → Servernetz 100.10.0.0/24`

Mit ,,Weiterleitung" meinte ich nicht den QR-Code selbst, sondern das Verhalten des Captive Portals:
Wenn ein nicht angemeldeter Client den QR-Code scannt und `http://zimmerservice.hotel/` aufruft, wird der Aufruf normalerweise vom Captive Portal abgefangen und auf die Captive-Portal-Loginseite umgeleitet.

Der QR-Code soll idealerweise nur enthalten:

`http://zimmerservice.hotel/`

Der Hostname wird intern per Unbound Host Override auf `100.10.0.5` aufgelöst. Der eigentliche Flask-/Zimmerservice läuft aktuell auf einem Sonderport, im Test zuletzt auf `18060` statt ursprünglich `8060`.

Port `18060` wurde gewählt, weil `8060` im Bereich des Captive-Portal-Logins `8000–10000` liegt und ich diesen möglichen Fehler ausschließen wollte.

Der Port ist also nicht wirklich ,,sicher verschleiert", das war von mir ungenau formuliert. Gemeint war eher: Der Gast soll im Normalfall keine IP-Adresse und keinen Port sehen, sondern nur den lokalen Namen `zimmerservice.hotel`.

Der Hinweis mit dem Reverse Proxy ist vermutlich genau der richtige Punkt. Sauberer wäre wahrscheinlich:

`http://zimmerservice.hotel/`
→ Port 80 auf dem Server / Reverse Proxy
→ intern weiter auf Flask `127.0.0.1:18060` oder `127.0.0.1:8060`

Dann müsste im Captive Portal / in der Firewall vor Login nur noch

`GUESTNET → 100.10.0.5 TCP 80`

erlaubt werden und nicht der Sonderport.

Mein eigentliches Problem ist aktuell:

Der Zugriff auf `100.10.0.5:18060` vor dem Captive-Portal-Login funktioniert geräteabhängig. Bei manchen Geräten klappt es, bei anderen sehe ich im Log `Default Captive Portal block rule (zone 0)` oder teilweise gar keinen passenden Eintrag.

Beispiele:

* Ein altes Samsung A40 öffnet die gewünschte Seite mal ja, mal nein.
* Ein aktuelles PEAQ PET10182 Tablet hat die Seite bei jedem Versuch sauber geöffnet.
* Ein Xiaomi 14 Ultra zeigte im Firewall-Log teilweise gar keine Reaktion, leitete teilweise auf die Standard-Captive-Portal-Loginseite um oder öffnete die gewünschte Seite erst beim dritten oder vierten Versuch.

Daher die Frage, ob der Weg über Sonderport/Walled Garden grundsätzlich ungünstig ist und ob ein Reverse Proxy auf Port 80 die sauberere Lösung wäre.

@viragomann:
Ergänzung zur Klarstellung:

Für die letzten Tests mit Port `18060` habe ich den QR-Code nicht verwendet, weil der gedruckte QR-Code noch auf `http://zimmerservice.hotel/` zeigt.

Ich habe deshalb manuell getestet mit:

`http://zimmerservice.hotel:18060/`

und alternativ direkt mit:

`http://100.10.0.5:18060/`

Der Sonderport war bei diesen Tests also bewusst Teil des Aufrufs. Das Ziel war nur zu prüfen, ob der Zugriff vor Captive-Portal-Login auf einen internen Webserver außerhalb des ursprünglichen Ports `8060` zuverlässiger funktioniert.

Langfristig wäre der gewünschte Zustand weiterhin:

`http://zimmerservice.hotel/`

ohne sichtbaren Port für den Gast, vermutlich dann über Port 80 / Reverse Proxy auf dem Server.

[viragomann]

Kernfrage aus meinen ersten Punkten wäre wohl eher:
**Wie bekommt man unter OPNsense 26.1.2 einen internen Webserver zuverlässig als Walled-Garden-/Pre-Auth-Ziel vor dem Captive-Portal-Login erreichbar?**

Das habe ich auch noch nicht umgesetzt.
Aber ich könnte mir vorstellen, dass du den Zugriff für nicht angemeldete erst mal erlauben müsstest.

Sind die **Allowed Addresses** im Captive Portal dafür der richtige Weg, oder braucht es zusätzlich eine andere Konfiguration?

Ich denke nicht. Ich hätte die Option so verstanden, dass die genannten Quell-IPs /-Subnetze nicht blockiert würden. Dasselbe wie "Allowed MAC addresses" für MAC-Adressen.

Und gibt es bekannte Besonderheiten, wenn das Ziel in einem anderen internen Netz liegt, also z. B.:

Ich vermute es.
Jedenfalls musst du den Zugriff erlauben, ehe er durch die Captive Portal-Regel blockiert wird. Und das ist eine automatisch generierte Regel, die im Regelset oberhalb der Nutzerregeln steht.

Sieh dir die Regeln an. Wähle das CP-Interface und aktiviere "Inspect", um die autom. generierten  Regeln anzuzeigen.

Damit deine Seite nicht blockiert wird, musst du die Regeln wahrscheinlich manuell erstellen. Dazu musst du in Captive Portal "Disable firewall rules" anhaken (advanced mode).
Sieh dir aber vorher die originale Regel genau an, damit du die nachher nachbauen kannst. Der Alias __captiveportal_zone_x steht dir dabei dennoch zur Verfügung.
Die Regel, die den Zugriff auf deine Seite erlaubt, musst du dann vor die Block-Regel setzen, also auf die 1. Position. Die Block-Regel auf die 2.

Bei deinem speziellen Port könnte es aber auch sein, dass manche Geräte diesen nicht aufrufen mögen. Das kenne ich jedenfalls von Webbrowsern.

Außerdem solltest du die DHCP Option 114 konfigurieren.
Nachdem du es nicht erwähnt hast, vermute ich, dass es noch nicht gemacht wurde. Einige moderne Geräte erfordern das aber, um die CP-Seite anzuzeigen.