Captive Portal: Diverse Fragen

[michael.seidel]

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?

[Monviech (Cedrik)]

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

[michael.seidel]

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."

[Monviech (Cedrik)]

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.

[viragomann]

Hallo,

n 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.

Fü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?

[michael.seidel]

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 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.

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?

- 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.

[viragomann]

- 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.

[michael.seidel]

- 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

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.

Das Port forwarding legt das CP eigentlich an. Was es für die .2 auch tut, für die .1 eben noch nicht.

[Monviech (Cedrik)]

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

[michael.seidel]

Die legt er ja auch automatisch an:

Ich hoffe das Bild wird korrekt Eingebunden... Target ist default eben (self) was WAHRSCHEINLICH VIP ignoriert.

[Monviech (Cedrik)]

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.