Hallo zusammen,
nachdem ich nun auch das Captive Portal am Laufen habe, stellen sich mir ein paar Fragen:
- Gibt es eine Möglichkeit, dass man statt Benutzernamen und Passwort einfach nur einen Code eingeben muss, den man als Voucher erzeugt hat? Die Eingabe eines kryptischen Benutzernamens und eines kryptischen Passwortes ist schon recht umständlich - für ein Gäste-WLAN zu umständlich. Bei den Grandstream Access Points benötigt man nur einen Zahlencode, den man als Voucher erstellt.
- Ich betreibe die OPNsense als HA-Cluster. Das Portal reagiert aber nur auf die physikalische IP im Gast-Netz und nicht auf die CARP-IP. Ist das normal und ist das sinnvoll? Beim Failover muss man sich ja dann ggf. an der physikalischen IP-Adresse des zweiten Knotens anmelden.
- Und daran schließt sich auch schon die nächste Frage an: Die Einstellungen des Captive Portal werden auf den Backup-Knoten synchronisiert, aber die Voucher nicht. D. h. es kann sich niemand mit den ihm bekannten Vouchern im Gäste-Netz anmelden, wenn ein Failover erfolgt ist. Ist das per Design so gewollt? Das macht doch eigentlich keinen Sinn, oder?
Klar kann man jetzt sagen, dass das Gäste-Netz nicht so wichtig ist und daher keine Ausfallsicherheit erfordert, aber dennoch fände ich es gut, wenn sich die Gäste mit den bekannten Vouchern auch am Backup-Knoten authentifizieren können.
Vielen Dank und viele Grüße
Quote from: TheExpert on March 01, 2026, 02:53:04 PMGibt es eine Möglichkeit, dass man statt Benutzernamen und Passwort einfach nur einen Code eingeben muss, den man als Voucher erzeugt hat?
Hast du versucht, im Authentication Server die Benutzernamenslänge auf 0 zu setzen?
Quote from: TheExpert on March 01, 2026, 02:53:04 PMIch betreibe die OPNsense als HA-Cluster. Das Portal reagiert aber nur auf die physikalische IP im Gast-Netz und nicht auf die CARP-IP.
Was meinst du mit "reagiert auf die physikalische IP?
Die Client-Anfragen werden einfach auf die Interface IP umgeleitet (oder der Client erhält die IP schon vom DHCP). Welche das ist, sollte doch egal sein.
Wenn die Backup-Box Master ist, dann werden die Clients eben auf deren IP umgeleitet.
Quote from: TheExpert on March 01, 2026, 02:53:04 PMDie Einstellungen des Captive Portal werden auf den Backup-Knoten synchronisiert, aber die Voucher nicht.
Hast du die Synchronisation der Authentication Server aktiviert?
Nein, die Länge des Benutzernamens auf 0 zu setzen, habe ich nicht getestet. Ist das nun lediglich ein Vorschlag zum Testen oder ist bekannt, dass das funktioniert?
IP-Adresse: Nein, es ist nicht egal, welche IP-Adresse genommen wird, denn im HA muss die CARP-IP genommen werden. Anderenfalls ist ja kein HA für das Captive-Portal möglich. Mit physikalischer IP meine ich die IP des OPNsense-Knotens im Gäste-VLAN anstelle der virtuellen CARP-IP.
Synchronisation: Ja, die Authentication Server werden in meiner HA-Konfiguration ebenfalls synchronisiert. Das Verhalten, dass die Voucher nicht synchronisiert werden, ist hier im Forum schon mindestens seit 2021 bekannt und offenbar ist das bisher noch nicht gefixt worden (siehe z. B. https://forum.opnsense.org/index.php?topic=24239.0).
Wenn man als Länge für den Benutzernamen "0" eingibt, erscheint folgende Fehlermeldung:
Die folgenden Eingabefehler wurden entdeckt:
- Benutzernamenlänge muss eine Zahl oder leer für den Standardwert sein.
Das funktioniert also schon mal nicht :-(.
Quote from: TheExpert on March 02, 2026, 08:27:16 AMWenn man als Länge für den Benutzernamen "0" eingibt, erscheint folgende Fehlermeldung:
Die folgenden Eingabefehler wurden entdeckt:
- Benutzernamenlänge muss eine Zahl oder leer für den Standardwert sein.
Das war ein Vorschlag, es zu versuchen.
Aber wahrscheinlich hatte ich das selbst schon getan und dieselbe Erfahrung gemacht, jedoch vergessen. Die Fehlermeldung brachte mir ein Déjà-vu.
Okay, nicht synchronisiert werden die offenen Vouchers. Also man kann sich mit dem genutzten Voucher bei einem Wechsel auf die Backkup-Box nicht wieder anmelden.
Das Problem mit der Interface IP verstehe ich aber nicht. Das einzige, was in CP angegeben werden kann ist der Hostname, auf den die Webanfragen umgeleitet werden. Dieser kann per DNS an die CARP-IP gebunden sein, kann aber auch an ein anderes Gerät gebunden oder es kann auch die CARP IP selbst sein.
Aber das CARP Service selbst wird ja nicht an eine IP gebunden.
Ich frag mich daher, was da nicht funktioniert.
Quote from: viragomann on March 02, 2026, 09:18:23 AMAber das CARP Service selbst wird ja nicht an eine IP gebunden.
Du meinst vermutlich das Captive Portal und nicht CARP Service, oder? Denn CARP ist an Schnittstellen und IP-Adressen gebunden. Ich lege lediglich fest, für welche Netzwerke, aber in der Tat nicht, über welche IP-Adresse das Captive Portal erreichbar sein soll.
Quote from: viragomann on March 02, 2026, 09:18:23 AMIch frag mich daher, was da nicht funktioniert.
Wenn man die URL des Captive Portal mit http://<CARP-IP-Adresse>:8000/ aufruft, kommt ein Timeout. Wenn man http://<IP-Adresse des HA-Knotens>:8000/ aufruft, dann erscheint das Captive Portal.
Quote from: TheExpert on March 02, 2026, 06:17:26 PMDu meinst vermutlich das Captive Portal und nicht CARP Service, oder?
Ja, sorry.
Quote from: TheExpert on March 02, 2026, 06:17:26 PMWenn man die URL des Captive Portal mit http://<CARP-IP-Adresse>:8000/ aufruft, kommt ein Timeout. Wenn man http://<IP-Adresse des HA-Knotens>:8000/ aufruft, dann erscheint das Captive Portal.
Eigentlich sollte nichts davon funktionieren. Der Port 8000 ist für https gedacht. Mit http müsste der Aufruf fehlschlagen.
Wenn das aber ein Schreibfehler ist oder der Browser automatisch unbemerkt auf https gewechselt ist, würde das heißen, die Webseite ist nur an die Interface-Adresse gebunden.
Ich verstehe aber immer noch nicht, weswegen es die CARP IP sein muss. Ebenso gut kannst du die IP der Backup-Node in den URL reinsetzen und die Webseite sollte auch aufgehen.
Wie oben geschrieben, wenn CP synchronisiert wird, sollte auf der Backup die Loginseite ebenso auf der Interface IP bereitstehen.
Also wenn diese Master ist, macht sie eben die Umleitung auf ihre Interface IP. Dem Client sollte das egal sein.
Wenn du es aber dennoch auf der CARP VIP haben möchtest, dann leite die Anfragen eben auf die Interface-Adresse weiter.
Also eine Destination NAT Regel am jeweiligen Interface erstellen mit der CARP VIP als Destination und Port 8000 (f. Zone 0) und als Redirect Target die Interface Adresse (die vordefinierte Variable, damit die Regel auch auf der Backup funktioniert) und Port 8000.
Dies ist für https. Für http wäre noch eine Regel mit Zielport 9000 nötig.
Quote from: viragomann on March 02, 2026, 08:59:55 PMWenn das aber ein Schreibfehler ist
Nein, das ist kein Schreibfehler.
Quote from: viragomann on March 02, 2026, 08:59:55 PMIch verstehe aber immer noch nicht, weswegen es die CARP IP sein muss. Ebenso gut kannst du die IP der Backup-Node in den URL reinsetzen und die Webseite sollte auch aufgehen.
Weil ich einen HA-Cluster habe! Und ja, der Aufruf funktioniert auch mit der IP-Adresse des Backup-Knotens - deshalb hatte ja auch allgemein geschrieben: Wenn man http://<IP-Adresse des HA-Knotens>:8000/ aufruft, dann erscheint das Captive Portal.
Quote from: viragomann on March 02, 2026, 08:59:55 PMWenn du es aber dennoch auf der CARP VIP haben möchtest, dann leite die Anfragen eben auf die Interface-Adresse weiter.
Also eine Destination NAT Regel am jeweiligen Interface erstellen mit der CARP VIP als Destination und Port 8000 (f. Zone 0) und als Redirect Target die Interface Adresse (die vordefinierte Variable, damit die Regel auch auf der Backup funktioniert) und Port 8000.
Dies ist für https. Für http wäre noch eine Regel mit Zielport 9000 nötig.
OK. Aber das macht natürlich nur Sinn, wenn auch die Voucher im Cluster synchronisiert würden.
Quote from: viragomann on March 02, 2026, 08:59:55 PMPort 8000.
Dies ist für https. Für http wäre noch eine Regel mit Zielport 9000 nötig.
Ich habe HTTPS für das Captive Portal noch nicht aktiviert. Wenn ich http://<IP-Adresse des HA-Knotens>:9000/ aufrufe, wird auf http://<IP-Adresse des HA-Knotens>:8000/ umgeleitet.
Es ruft aber doch niemand das CP direkt auf. Jemand gibt www.heise.de in den Browser ein und wird auf das CP umgeleitet. Ist der Primary aktiv, auf den Primary, ist der Standby aktiv, auf den Standby. Oder verstehe ich das CP falsch?
Quote from: TheExpert on March 03, 2026, 06:42:31 AMOK. Aber das macht natürlich nur Sinn, wenn auch die Voucher im Cluster synchronisiert würden.
Ich nutze CP und HA nur getrennt. Kann daher nicht sagen, ob Vouchers synchronisiert werden. Ich hätte angenommen, dass es so wäre, vorausgesetzt die Synchronisation dafür ist aktiviert.
Quote from: TheExpert on March 03, 2026, 06:42:31 AMIch habe HTTPS für das Captive Portal noch nicht aktiviert. Wenn ich http://<IP-Adresse des HA-Knotens>:9000/ aufrufe, wird auf http://<IP-Adresse des HA-Knotens>:8000/ umgeleitet.
Ja, richtig. Wenn kein Zertifikat eingerichtet ist, bedient 8000 http und 9000 wird dahin umgeleitet. Hatte ich soweit noch nicht untersucht.
Quote from: Patrick M. Hausen on March 03, 2026, 08:33:17 AMEs ruft aber doch niemand das CP direkt auf. Jemand gibt www.heise.de in den Browser ein und wird auf das CP umgeleitet. Ist der Primary aktiv, auf den Primary, ist der Standby aktiv, auf den Standby. Oder verstehe ich das CP falsch?
Ja, das Captive Portal sollte automatisch erscheinen, wenn man eine URL aufruft und noch nicht authentifiziert ist. Mir ist nur nicht klar wie das im HA-Cluster funktioniert, wenn nicht die CARP-IP des Clusters aus dem VLAN für das Captive Portal verwendet wird.
Ich bin noch im parallelen Aufbau der OPNsense, migriere von der Sophos UTM. Das ist recht zeitaufwendig, so dass ich noch nicht sagen kann, wie das funktioniert, wenn alles mal produktiv ist.
Quote from: viragomann on March 03, 2026, 11:29:03 AMIch nutze CP und HA nur getrennt. Kann daher nicht sagen, ob Vouchers synchronisiert werden. Ich hätte angenommen, dass es so wäre, vorausgesetzt die Synchronisation dafür ist aktiviert.
Interessant. Du hast also ein externes Captive Portal? Was setzt Du ein? Ich wollte ja eigentlich auch beim Captive Portal meiner Grandstream Access Points bleiben, aber die Access Points funktionieren nicht ganz so, wie es sein soll und jetzt muss ich sie wg. einem angeblichen Defekt (gleich zwei Access Points mit dem gleichen Defekt lt. Support?) wieder zurückgeben und wahrscheinlich werde ich mir andere Access Points besorgen. Die haben aber meistens kein Captive Portal mit Voucher. Deshalb habe ich mir das Captive Portal der OPNsense angesehen.
Ich hatte gemeint, ich betreibe zwar HA und CP, jedoch nicht zusammenhängend. Also auf unterschiedlichen Installationen.
Was meinst du, was ich wo einsetze? Beim Hostnamen?
Da verwende ich einen ebensolchen, also einen Domainnamen, der übers Public DNS auf die WAN IP der OpenSense auflöst.
Dafür habe ich auch ein LE Zertifikat. Könnte also auch https nutzen, wenn nötig. Das ist aber auch erst im Aufbau und bislang noch nicht umfangreich getestet.
Ich traue dem CP auf OPNsense eher als einem auf einem AP, so jedenfalls wenn der AP im LAN hängt. Damit würdest du diesem die Kontrolle überlassen, dass die Gast-Nutzer tatsächlich ausschließlich ins Internet verbinden dürfen, nicht lokal, was wahrscheinlich gewünscht ist. Das habe ich lieber auf der Firewall.
Warum bist du so sehr von dem Gedanken besessen, dass die CARP VIP für CP genutzt werden müsste?
Der Service steht auf beiden Nodes zur Verfügung und kann ebenso gut über die Interface IP genutzt werden.
Die CARP VIP soll es für Services sein, die man auf den Clients fest mit einer IP konfiguriert.
Für CP wird nichts am Client eingerichtet. Der Client versucht einfach eine Verbindung ins Internet aufzubauen. Ja, die geht auf die CARP VIP (als Upstream Gateway) und wird auf OPNsense umgeleitet auf die Interface IP. Der Client sollte damit kein Problem haben, denke ich.
Quote from: viragomann on March 03, 2026, 07:36:10 PMWas meinst du, was ich wo einsetze? Beim Hostnamen?
Ich meinte welches Produkt Du verwendest. Das hat Du aber im Satz zuvor beantwortet. Wenn ich Dich richtig verstehe, dann hast Du eine weitere OPNsense für das Captive Portal am laufen.
Nein, die beiden Installationen sind an verschiedenen Standorten. Die haben nichts miteinander zu tun.
Die Hostadresse zeigt auf die eigene WAN IP.
Servus Zusammen,
ich habe genau das gleiche Problem mit CARP/HA und Captive Portal.
Zur angefragten Begründung: Weil es einfach Sinn macht.
Genauer:
In einem Normalen und einem HA Setup kann ein Client ja nur eine Default GW Route haben. In einem Normalen Setup kann sich diese ja nicht ändern, gibt ja nur eine IP. Bei 2+ Nodes und der Implementation von HA von OPNsense (In dem IPs von Interfaces nicht repliziert werden wenn ein Failover passiert) müssen die Nodes also auf eine geteilte IP zurückgreifen um dem Client einen immer verfügbaren Gateway zu stellen. Wenn das nicht so wäre und ein Schwenk passiert, macht ein Client ja nicht einen erneuten DHCP request und bekommt dadurch einen anderen Gateway sondern läuft in eine nicht mehr verfügbare IP und hat dementsprechend keine Verbindung mehr. Kein erneutes CP weil die Session auf dem zweiten Node fehlt (Nächstes Problem!). Aber für den User ist das einfach nur ein Totalausfall der Verbindung. Also das genaue Gegenteil von HA.
Was ich im Source bisher finden konnte, ist, dass im CP Dienst (Template Generierung) und im Unbound beim registrieren der system A/AAAA records ausschließlich die Interface IP genommen wird und nicht alle IPs (CARP/Alias) eines Interfaces.
Für ein funktionierendes CP mit moderner Hardware ist ja ein gültiges Zertifikat gesetzt. Das bekommste auch nicht für IPs. Im OPNsense single Node Normalfall, macht der Dienst das alles selbst (CP+DNS) und funktioniert sehr gut. Im HA/CARP Setup geht aktuell gar nichts.
Please Help anyone?
Die aktiven Sessions und Vouchers werden in einer sqlite Datenbank gespeichert, die wird nicht synchronisiert zwischen den Firewalls. Es gibt bestimmt auch noch andere Einschränkungen, sodass HA damit gerade nicht möglich ist.
Du kannst gerne mal hier fragen: https://github.com/opnsense/core/issues
BTW Let's Encrypt bietet IP Zertifikate an, muss man aber automatisieren da nur 7 Tage gültig: https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate
Mit den Sessions/Vouchern war mit bekannt. Aber das sehe ich weniger schlimm. Bei einem HA Switch, wird dem User dann automatisch einfach nur ein neues CP angezeigt, meist auch mit einem Geräusch am Gerät. Aber im aktuellen Modus im HA Sinne bricht es halt vollständig ab ohne Userbenachrichtigung auf dem Gerät (Bist halt einfach ohne Route offline) bis ein User aktiv die Verbindung trennt und neu aufbaut. (Neue DHCP Lease)
Deswegen wäre das mit dem CARP als erster Schritt sinnig. Roadmap Feature wäre dann ein Session/Voucher Sync um es vollständig rund zu machen.
Zertifikate für RFC1918 LAN IPs geht aber trotzdem nicht: Zitat: "And, probably not surprisingly, you can't use the DNS challenge method to prove your control over an IP address; only the http-01 and tls-alpn-01 methods can be used."
Am besten mal auf github eine issue aufmachen und das Essentielle beschreiben was gerade fehlt.
Vieleicht ist es konfiguration, vielleicht eine andere einschränkung.
Mein Kollege der viel am Captive Portal programmiert kann auf github wahrscheinlich eine qualifizierte Antwort geben als ich hier.
Hallo,
Quote from: michael.seidel on March 19, 2026, 10:39:47 AMn einem Normalen und einem HA Setup kann ein Client ja nur eine Default GW Route haben. In einem Normalen Setup kann sich diese ja nicht ändern, gibt ja nur eine IP. Bei 2+ Nodes und der Implementation von HA von OPNsense (In dem IPs von Interfaces nicht repliziert werden wenn ein Failover passiert) müssen die Nodes also auf eine geteilte IP zurückgreifen um dem Client einen immer verfügbaren Gateway zu stellen. Wenn das nicht so wäre und ein Schwenk passiert, macht ein Client ja nicht einen erneuten DHCP request und bekommt dadurch einen anderen Gateway sondern läuft in eine nicht mehr verfügbare IP und hat dementsprechend keine Verbindung mehr. Kein erneutes CP weil die Session auf dem zweiten Node fehlt (Nächstes Problem!).
was genau hat denn CP mit DHCP zu tun? Abgesehen von der Option 114, mit der der DHCP das CP für "moderne Geräte" bekannt geben sollte.
Verstehe ich hier etwas nicht?
Ich nutze nicht CP zusammen mit HA. Vielleicht fehlt mir hier was. Aber DHCP und CP laufen doch völlig getrennt ab. Erst bekommt der Client vom DCHP Server eine IP, dann bemerkt er erst, dass er sich hinter einem CP befindet und geht auf desen Seite oder wird dahin gezungen.
Der DHCP Server im HA sollte natürlich so konfiguriert werden, dass er den Clients die CARP VIP als Gateway zuweist. Nach einem Failover ist damit das Gateway immmer noch erreichbar.
Einzig die CP Session ist am anderen Node nicht vorhanden und der Client wird bei einem Internetzugriff wieder auf die CP-Seite umgeleitet. Ob der Client das dann aber auch akzeptiert, nachdem sich physisch seine Netzwerkverbindung nicht geändert hat, weiß ich nicht.
Quote from: michael.seidel on March 19, 2026, 10:39:47 AMFür ein funktionierendes CP mit moderner Hardware ist ja ein gültiges Zertifikat gesetzt. Das bekommste auch nicht für IPs.
Wie oben geschrieben, habe ich in CP einen Hostnamen eingetragen, der auf meine öffentliche IP gemappt ist, und SSL aktiviert. Das könnte ebenso die CARP IP sein. DNS Auflösung geht auch ohne CP Session.
Und wie ebenfalls zuvor geschrieben, könnte man die Anfragen auf diese öffentliche (CARP) IP einfach auf die CP-aktive Interface IP weiterleiten. Dann gehen sie immer dahin, wo sie hin sollen.
In meinem Kopf funktioniert das. In der Praxis nicht?
Quotewas genau hat denn CP mit DHCP zu tun? Abgesehen von der Option 114, mit der der DHCP das CP für "moderne Geräte" bekannt geben sollte.
Verstehe ich hier etwas nicht?
Ich nutze nicht CP zusammen mit HA. Vielleicht fehlt mir hier was. Aber DHCP und CP laufen doch völlig getrennt ab. Erst bekommt der Client vom DCHP Server eine IP, dann bemerkt er erst, dass er sich hinter einem CP befindet und geht auf desen Seite oder wird dahin gezungen.
Der Client muss halt per DHCP seine IP und seinen Gateway/DNS bekommen. Wenn dieser die CARP IP ist, gehts nicht. Wenn diese die Interface IP ist, gehts. Das ist der Bug daran.
QuoteWie oben geschrieben, habe ich in CP einen Hostnamen eingetragen, der auf meine öffentliche IP gemappt ist, und SSL aktiviert. Das könnte ebenso die CARP IP sein. DNS Auflösung geht auch ohne CP Session.
Und wie ebenfalls zuvor geschrieben, könnte man die Anfragen auf diese öffentliche (CARP) IP einfach auf die CP-aktive Interface IP weiterleiten. Dann gehen sie immer dahin, wo sie hin sollen.
In meinem Kopf funktioniert das. In der Praxis nicht?
- Zertifikat holen via ACME auf Öffentliche WAN per HTTP-01 oder bei DNS-01 -> Fein.
- Im unbound stellst du Sicher, dass "Do not register system A/AAAA records" = Aus. -> Dann hat der Unbound für seinen Hostname ebenfalls die LAN IPs gebunden. -> Bug 1) Keine Carp/Alias IPs! Nur Interface IPs!
- DHCP konfigurieren -> KEA -> Subnetz A/B/C -> "Auto collect option data" = AN -> Gateway wäre damit die Interface IP -> Alles geht. Bei "Auto collect option data"=Aus -> Gateway eintragen -> Carp/Alias IP -> Client bekommt diese als Gateway. Bis hier hin funktioniert das auch.
- Dieses Zertifikat im CP Dienst auswählen -> Selben Hostname wie im Zertifikat setzen. -> Fein. Für nicht CARP/Alias IPs funktioniert es hier sofort!
- Im CP Dienst entsprechend das Interface auswählen. Und jetzt entscheidet sich das...
Client bekommt DHCP -> Fall A nicht mit CARP): Ist eine Interface IP -> Gateway ist sagen wir mal die .2 -> Captive Portal wird forciert, weil Firewall Regel alles auf CP Interne IP .2 umbiegt -> CP geht auf, macht sein Ding. Läuft. Im HA Fall -> .2 geht aus. Client hat weiterhin sein Gateway auf die .2, ist defakto offline bis der Client sich entscheidet wieder DHCP refresh zu machen, bekommt die .3 als GW von der zweiten Node, bekommt wieder ein CP, kann sich einloggen. -> Client merkt also nur, dass er offline ist, aber bliebt weiterhin mit dem WLAN verbunden, is halt nur offline. Kunden experience fürn ...
Fall B mit CARP): Ist eine CARP IP -> Gateway ist sagen wir mal die .1 -> Captive Portal wird forciert, wird aber auf die .2 umgeleitet (Weil BUG 2), sollte aber trotzdem aufgehen, würde ja trotzdem auf die .2 gebunden sein, tuts aber nicht. (Vielleicht immer noch BUG 2 oder schon BUG 3)
Sagen wir mal das wäre gefixed an dem Punkt und gehen weiter. HA Fall tritt ein, IP .1 wechselt auf Node2 -> Gateway wäre immer noch identisch. Client bekommt wegen fehlendem Sessions Sync (Potentielles Roadmap Feature) nur ein neues CP angezeigt, logged sich ein und alles geht weiter, weil .1 weiterhin Gateway, DHCP muss nix machen.
In meinem akkuten Fall benötige ich ungefähr ein dutzend CARP Interfaces jeweils einem eigenen VLAN, aber das Problem ist schon bei N=1 existent.
Quote from: michael.seidel on March 19, 2026, 03:27:06 PM- Im unbound stellst du Sicher, dass "Do not register system A/AAAA records" = Aus. -> Dann hat der Unbound für seinen Hostname ebenfalls die LAN IPs gebunden. -> Bug 1) Keine Carp/Alias IPs! Nur Interface IPs!
Dem öffentlichen DNS ist es egal, ob es eine CARP VIP ist oder sonst eine virtuelle oder native IP.
Hast du auch ein Port Forwarding eingerichtet. Wenn CP nur auf die Interface IP lauscht, wird es anders nicht funktionieren.
DNS Namensauflösung muss am Client natürlich vor Anmeldung möglich sein.
Quote from: viragomann on March 19, 2026, 03:49:44 PMQuote from: michael.seidel on March 19, 2026, 03:27:06 PM- Im unbound stellst du Sicher, dass "Do not register system A/AAAA records" = Aus. -> Dann hat der Unbound für seinen Hostname ebenfalls die LAN IPs gebunden. -> Bug 1) Keine Carp/Alias IPs! Nur Interface IPs!
Dem öffentlichen DNS ist es egal, ob es eine CARP VIP ist oder sonst eine virtuelle oder native IP.
Ich rede vom internen DNS Resolver, öffentlich ist mir das nur soweit egal, dass ich ein gültiges Zertifikat bekomme, welches ein Laptop/Smartphone verifizieren kann.
unbound macht bei mehreren IPs dann sowas, die interne Logik im CP zieht das dann grade, dass du auf jedem CP Interface den Hostname korrekt bekommst, hab die internen IPs und WAN IP mal randomized:
root@node:~ # drill @127.0.0.1 node.example.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 29498
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; node.example.com. IN A
;; ANSWER SECTION:
node.example.com. 3600 IN A 123.123.123.123
node.example.com. 3600 IN A 10.56.78.2
node.example.com. 3600 IN A 10.90.12.2
node.example.com. 3600 IN A 172.20.10.2
node.example.com. 3600 IN A 192.168.45.2
node.example.com. 3600 IN A 10.200.150.2
node.example.com. 3600 IN A 172.25.60.2
node.example.com. 3600 IN A 192.168.88.2
node.example.com. 3600 IN A 172.18.200.2
node.example.com. 3600 IN A 172.22.33.2
node.example.com. 3600 IN A 172.29.99.2
node.example.com. 3600 IN A 172.30.10.2
node.example.com. 3600 IN A 172.19.140.2
node.example.com. 3600 IN A 172.21.170.2
node.example.com. 3600 IN A 172.23.210.2
node.example.com. 3600 IN A 172.24.240.2
node.example.com. 3600 IN A 10.77.66.2
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Mar 19 16:20:20 2026
;; MSG SIZE rcvd: 301
root@node:~ #
-> Interface hat die .2 und CARP die .1, es fehlt in der Liste also alles nochmal mit .1
Quote from: viragomann on March 19, 2026, 03:49:44 PMHast du auch ein Port Forwarding eingerichtet. Wenn CP nur auf die Interface IP lauscht, wird es anders nicht funktionieren.
DNS Namensauflösung muss am Client natürlich vor Anmeldung möglich sein.
Das Port forwarding legt das CP eigentlich an. Was es für die .2 auch tut, für die .1 eben noch nicht.
Schon mal versucht alle firewall regeln manuell zu machen? Das inkludiert dann auch die NAT Regeln:
(disclaimer habe nicht gesamte Diskussion gelesen)
https://docs.opnsense.org/manual/captiveportal.html#captive-portal-firewall-rules
Die legt er ja auch automatisch an:
Ich hoffe das Bild wird korrekt Eingebunden... Target ist default eben (self) was WAHRSCHEINLICH VIP ignoriert.
(https://image2url.com/r2/default/images/1773936416996-aa803e8d-c9e8-45a4-8867-0868dc485b69.png)
Nein die NAT regeln werden nicht automatisch angelegt wenn man firewall regeln für eine captive portal zone deaktiviert, dann kann man alles selber machen.