Messages

Danke, das erklärt einiges.
Ich hatte Allowed Addresses tatsächlich als erlaubte Zieladressen verstanden.
Wenn das eher Quelladressen meint, passt das zu meinem Log mit der Default Captive Portal block rule.
Ich schaue mir als Nächstes über Inspect die automatisch generierten Regeln an und prüfe DHCP Option 114.
Produktiv werde ich ,,Disable firewall rules" erst einmal nicht setzen, sondern höchstens in einer Testumgebung nachbauen.

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.

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.

Nutzt denn hier keiner das Captive Portal Template und hat seit dem letzten Update das gleiche Probleme?
Anbei zwei Screenshots.
Einmal wie es aussehen sollte und einmal wie es bei mir aussieht.

Hallo,
wie so viele auch, habe ich seit dem Upgrade von 24 auf 25 ein Problem mit dem Captive Portal.
Zuerst gab es immer die Fehlermeldung, dass die Authentifizierung fehlgeschlagen ist.
Testet man Name und Passwort direkt auf der OPNSense werden sie erkannt.

Nun habe ich mich bis zur Versionen
OPNsense 25.7.3_7-amd64
FreeBSD 14.3-RELEASE-p2
OpenSSL 3.0.17

durch geupdatet.
Aber ich kann das Captive Portal mit der Anmeldeseite nicht mehr testen, da mir die Felder für Login und Passwort auf der Anmeldeseite nicht mehr angezeigt werden.
Auch wenn ich das unbearbeitete Template von der OPNSense oder von dieser Seite https://t4skforce.github.io/OPNsense-Captive-Portal/ nehme, erscheinen die Felder für den Login nicht mehr.
Irgendjemand anderes das gleiche Problem oder Lösungsvorschläge?
Was ich bisher bei der Suche gefunden hatte, waren lediglich die Hinweise, dass die Authentifizierung fehlgeschlagen ist und das im Bereich von Sitzungen nichts mehr angezeigt wird.

Ich bräuchte Hilfe, da ich mein Gäste-WLAN ungern völlig offen lassen will.

Danke.

So,
nach dem ich nun die TLS Fehlermeldung mit dem Hello on ClearPort mit einem öffentlichen Zertifikat von LE beseitigen konnte,  haut mir die OPNSense auf der Captive Portal Schnittstelle nun neue, bzw. weitere Fehlermeldungen raus.
Vielleicht kann mir hier ja jemand sagen was es damit aufsich hat und wie damit umzugehen ist:

alles mit dem Vermerk: lighttpd 62619
- SSL: 1 error:0A000076:SSL routines::not suitable signature algorithm
- uri /images/default-logo.png in=8530 smaller than out=8553
- SSL: 1 error:=0A00010B:SSL routines::wrong version number

Vielen Dank im Voraus.

Ich würde das hier gerne, Zwecks Ermangelung von Vorschlägen schließen wollen.
Die TLS Fehlermeldung habe ich durch ein hinterlegtes, öffentliches Zertifikat von LE beseitigt.

Da es hier keine Antwort gibt, würde ich das gerne schließen wollen.
Ich habe statt der Weiterleitung ein öffentliches Zertifikat von LE hinterlegt und damit zumindest diese Fehlermeldung beseitigt.

Moin,

ich habe ja dieses Problem mit dem "Hello on ClearPort" auf meiner WLAN Schnittstelle.
Das hängt wohl damit zusammen, dass manche Clients versuchen auf einem unverschlüsselten Port eine verschlüsselte Verbindung zur Anmeldeseite des CP herzustellen.
Was aber auch irgendwie kein Sinn macht, da das CP eigentlich eine verschlüsselte Verbindung für die Anmeldung voraussetzt und diese wohl auch von den Clients fordert.
Ein Zertifikat, um die Fehlermeldung des unbekannten Zertifikates zu vermeiden, habe ich nicht aktiviert.
Ist es möglich alle Anfragen die über Port 80 an die Anmeldeseite des CP gehen auf Port 443 umzuleiten?
Wie ist die Adresse der Anmeldeseite?
Subnetz ist 10.0.1.1.
Wäre http dann 10.0.1.1:80 und https 10.0.1.1:443, so dass ich einfach nur eine Umleitung an die Adresse 10.0.1.1 von 80 auf 443 einrichten muss?

Hallo in die Runde.
Ich habe eine OPNSense auf einem
Intel Core i5-10210U 1,6 GHz Comet Lake-U Quad Core
mit Hyperthreading und Turbo bis zu 4,2 GHz, 6 MByte L3
Cache, Intel UHD Graphics 620, 8xIntel i225-V (B3) 2,5
Gigabit LAN, DDR4-2666 SO-DIMM / Seriennr.
mit 8GB RAM und 32GB SSD laufen

Versionen
OPNsense 24.7.6-amd64
FreeBSD 14.1-RELEASE-p5
OpenSSL 3.0.15

Darin sind drei Netzwerke
32.72.... als WAN (Verbindung über LWLcom mit 1Gb synchron.
192.168.X.X als Heimnetzwerk
10.0.X.X als Gästenetz mit dem CaptivePortal
10.0.1X.X als Versuchnetz mit einem CaptivePortal über den TP-LINK OMADA Controller

Ich versuche hier mit TrafficShaping den einzlnen Gästenetzen unterschiedliche Geschwindigkeiten zuzordnen.
Das funktioniert leider nur Suboptimal, ist aber im Moment auch nicht das Thema.

Ich habe festgestellt, dass mir im 10.0.1.1 Netz manche Geräte mit irgendwelchen:
"Unexpected TLS ClientHello on Clear Port" die OPNSense vollspammen.
Und je mehr die Spammen, desto langsamer wird anscheinend die Internetgeschwindigket.
Vor einem Reboot war ich bei 20Mb/s im Download und 1Mb/s im Upload.
Nachdem Reboot hatte ich 26Mb/s im Download und 24Mb/s.
(Das TrafficShaping soll diese Leitung auf 30Mbit UP/DOWN begrenzen)

Die Geräte im LAN sind von der Leistungsreduzierung nur zum Teil betroffen.
Aber alle Geräte im WLAN, egal über welches Netzwerk sie die Verbindung herstellen...

Bis jetzt habe ich im Forum nichts hilfreiches dazu finden können.
Hat sonst jemand schon einmal diese Meldungen bekommen?
Kann mir jemand sagen was es damit aussich hat?
Kann mir jemand dabei helfen das Problem zu lösen?

Schon einmal vielen Dank.
Anbei zwei Bilder der Fehlermeldung.

Danke und Grüße
Nils

Moin,
folgende Frage in der Hoffnung, dass hier jemand schon ähnliches probiert hat:
Ist es möglich mit der OPNSense einen Speedtest auf die einzelnen Schnittstellen durchzuführen?

OPNsense 23.7.12_5-amd64
FreeBSD 13.2-RELEASE-p7
OpenSSL 1.1.1w

Läuft auf einem AMD GX-210UA SOC (2 cores, 2 threads) von OPNSense.

3 Schnittstellen:
WAN auf em1 angeschlossen an Glasfaser von LWL mit 250Mbit/s Synchron als Gateway
LAN als internes Netzwerk an em0
Gästenetz (opt1) hinter Capitve Portal an em2 mit eigenem Adressbereich
zweites Gästenetz (opt2)  als vlan hinter Captive Portal des OMADA Controllers von TP-LINK, an em2 mit eigenem Adressbereich

per Traffic Shaper hatte ich den beiden Gästenetzen unterschiedliche Bandbreiten zugeordnet (von den 250max gehen 50 an opt1 und 150 an opt2).
Dabei habe ich mich an das Howto aus der Dokumentation gehalten und habe entsprechend der Vorgaben folgendes eingerichtet:
-Multi Interface shaping for a GuestNet
(um den beiden Gästenetzen die entsprechende maximale Bandbreite zu zuordnen)
-Share internet bandwidth amongst users evenly
(damit jeder angemeldete Nutzer die gleiche Bandbreite zur Verfügung gestellt bekommt)

Anfangs funktionierte das auch ohne Probleme.
Speedtests aus den einzelnen Netzen heraus zeigten Geschwindigkeit die im Maximum der eingestellten maximalen Bandbreite entsprachen.
Mittlerweile ist das aber aus unerklärlichen Gründen nicht mehr.
Auch die Schnittstelle opt2, die eine höhere Bandbreite hat, ist limitiert auf die Bandbreite von opt1.

Nun wollte ich wissen ob es am Netzwerk selbst liegt (mehrere TP-Link Switches und Accesspoints verwaltet über Omada) oder ob das Problem eventuell in einer mittlerweile überlasteten OPNsense liegt.
Dafür habe ich das Speedtest Plugin installiert.
Das scheint aber nur die Geschwindigkeit zu messen, die über die WAN Schnittstelle geht.
Interessant wäre es, einzustellen den Test über eine der anderen Schnittstellen umzuleiten und dann zu testen wie die Geschwindigkeit an em1 und opt1 und opt2 ist.
Ob vielleicht irgendeine Einstellung in der OPNSense den Traffic begrenzt und ich daher diese Geschwindigkeiten bekomme.
Denn auch an der em1, dem ja theoretisch die restliche Bandbreite zur Verfügung steht, bekomme ich weniger.

Hat jemand ähnliche Erfahrungen oder eine Idee warum das Traffic Shaping auf einmal nicht mehr richtig funktioniert?

Ich habe mir bereits eine neue OPNSense basierenden auf einen intel i5 mit ausreichend RAM und Festplatte zugelegt. Aber dort waren die Geschwindigkeiten teilweise noch langsamer als auf meinem alten System.
Bin daher wieder zurück zum alten gewechselt solange ich nicht weiß, wie ich den Fehler beheben soll...

Grüße aus Bremen

Der Thread kann gerne geschlossen werden.
Ich habe mich dazu entschieden besagten PC für die Zeit der Konfiguration einfach an nen anderen Port im Switch zu stecken.
Alles andere scheint mir zu umständlich.
Trotzdem Danke für die Hilfe

Ich ging davon aus es sei ausreichend beschrieben.

OPNSense mit DREI LAN-Anschlüssen.
1x WAN (statische IP vom Provider)
1x LAN für das Firmennetzwerk (IP 192.168.0.1/24)
1x LAN für GUESTNET (IP 10.0.1.1) und an der Schnittstelle noch ein virtuelle IP (IP 10.0.10.1) zugeordnet.
GUESTNET ist Captive Portal für Hotelgäste, daran hängen mehrere APs.
Das VIP ist für 2 Gäste PCs und ein paar LAN-Buchsen, die Gäste im Aufenthaltsraum nutzen können ohne sich am CP anmelden zu müssen.

Hinter der OPNSense hängt ein 24 Port Managed Switch von TP-Link mit drei VLAN IDs
IP 192.168.0.1 ist VLAN ID 2 zugewiesene Ports: 1 + 13-24
IP 10.0.1.1 ist VLAN ID 1 zugewiesene Ports: 1-8 + 24
IP 10.0.10.1 ist VLAN ID 10 zugewiesene Ports: 1 + 9-12

Verbindung an die OPNSense
LAN Anschluss für 192.168.0.1 ist verbunden mit Port 13
LAN Anschluss für 10.0.1.1 ist verbunden mit Port 1

Komischerweise kam die Verbindung an die 10.0.1.1 und damit auch der Zugriff auf die OPNSense erst zustande nachdem ich auch den Port 1 mit ID2 verbunden habe. (oder ich hab nicht lange genug gewartet)

Aber ein Scan listet mir halt keinen der APs auf.

Also meine VLAN Verkabelung passt, das funktioniert ja soweit.
Die Geräte an ID2 können mit einander kommunzieren und werden alle gefunden
Die Geräte an ID1 kommen alle an die LogIn Seite vom Captive Portal, melden sich an und ab ins Internet
Die Geräte an ID10 haben Internet ohne sich vorher einloggen zu müssen
Das Problem ist doch eher, dass die Erreichbarkeit der Captive Portal Schnittstelle ins LAN (und vermutlich auch in die andere Richtung) unterbunden ist.
Ich möchte aber nun einmal gerne mit dem PC, der an Port 24 hängt auf die APs zugreifen die im VLAN 1 sind.
Irgendwie muss man die Teile ja auch mal neustarten oder Einstellungen ändern ohne das mit die APs ständig abbauen muss um sie mit nem Rechner zu verbinden an dem man vorher ne entsprechende IP eingetragen hat.
Ich ging davon aus, dass würde gehen, wenn ich diesem PC ebenfalls eine statische IP im 10.0.1.X Bereich gebe und über das Managed Switch auch mit dem Netzwerk verbinde.

Man kann übrigens einem PC beliebig viele IP Adressen auf einer Netzwerkkarte zuweisen.

Und was meinst du mit:

Verstehe auch nicht ganz, warum du überhaupt den einen PC mit 2 IPs ausstatten willst? Warum nicht den Zugriff auf den anderen PC freigeben? Was soll damit erreicht werden, außer dass du die Firewall komplett unterläufst?

Ne Portweiterleitung oder Routing von dem PC am Port 24 an die entsprechenden APs?
Das ist ja am Ende das was ich hinbekommen möchte.
Hab nur keinen Plan wie diese Regel aussehen sollte.

OPNsense 20.7-amd64
FreeBSD 12.1-RELEASE-p7-HBSD
OpenSSL 1.1.1g 21 Apr 2020

Ich habe eine opnsense mit 3 Lan Anschlüssen
WAN (statische IP vom Provider)
LAN 192.168.0.1 /24
GUESTNET 10.0.1.1 /24
und einem VLAN
USERPC 10.0.10.1 /24

Am LAN hängen alle internen Rechner, Drucker, etc....
Im GUESTNET ist CaptivePortal aktiviert und dient Hotelgästen als Internetzugang.
Daran hängen mehrere Access Points
USERPC ist ein VLAN an der GUESTNET-Schnittstelle, daran hängen zwei PCs für Gäste


Aufbau im Prinzip wie folgt:

                           |-LAN (192.168.0.1)
                           |
WAN (statische IP)---------|-GUESTNET (10.0.1.1)
                               |
                               |-USERPC (10.0.10.1)

funktioniert so weit auch ganz gut.
Nun würde ich gerne mit einem Managed-Switch vom LAN auf die APs im GUESTNET zugreifen.

VLAN-IDs usw. sind zugeteilt, funktioniert auch soweit so gut.
Allerdings kann ich mit dem PC im LAN, der in der IP Konfiguration zwei statische IP4 Adressen zugewiesen bekommen hat, lediglich auf den opnSense zugreifen.

IP4 vom PC im LAN ist: 192.168.0.55 und im GUESTNET 10.0.1.2

Mit dem Tool "Portscan" werden im LAN alle vergebenen Adressen angezeigt,
Im GUESTNET ist nur die 10.0.1.1 aufzufinden.

Ich vermute mal, dass es irgendeine Firewall-Regel sein wird.
Komme jetzt aber auf anhieb nicht darauf, wie diese aussehen sollte.
Nach Möglichkeit sollten die APs, die im GUESTNET außerhalb des DHCP liegen NUR vom LAN aus erreichbar sein und vom GUESTNET ein Zugriff weiterhin gesperrt bleiben.

Anbei mal meine Firewall Regeln für die beiden Schnittstellen und meine NATs.

Bitte um Hilfe.

Danke

[Allgemeinen Einstellungen]

Um das einmal kurz zum Abschluss zu bringen.
Es war von jeder Hilfe so ein bißchen und dann ganz wichtig:

In den Allgemeinen Einstellungen die DNS Adressen eintragen!

Kurzum: Es läuft