Messages

Hallo.
Der Dienst "ISC DHCP" auf der OPNSense ist bekanntlich abgekündigt -- stattdessen wird "Kea DHCP" übernehmen.
Meine Frage ist: Wird es eine automatische Übernahme der Daten geben oder muss man selbst migieren bzw sind zwischendurch irgendwelche eigenen Handgriffe notwendig?
Danke.

[automatisch]

Leider noch nicht ganz gelöst, da das Portal auch weiterhin nicht automatisch geladen wird, sobald man sich mit dem entsprechenden WiFi verbindet ...

Ich habe nochmal nachgelegt:
https://github.com/opnsense/core/issues/8695

Das ging ja schnell ... der neue Patch ist jetzt da!

Ok ... mal sehen, was daraus wird:
https://github.com/opnsense/core/issues/8689

[Source]

Hallo, die dritte.
Mich wundert, dass das Problem scheinbar sonst niemand hat? Hier ist es definitiv so, dass die Regeln, die laut neuer Doku
https://docs.opnsense.org/manual/captiveportal.html#redirect-traffic-to-the-zone-webserver
im Portforwarding entweder auftauchen oder aber neu selbst erstellt werden sollen, nicht vorhanden sind und auch nachträglich nicht angelegt werden können. Es bleibt leider dabei, dass unter Source das automatisch erzeugte Alias

Code Select Expand

__captiveportal_zone_0 gar nicht erscheint und demnach auch nicht ausgewählt werden kann.
Kann das Problem jemand bestätigen? Danke!

Mittlerweile ist die neue Doku da:
https://docs.opnsense.org/manual/captiveportal.html#redirect-traffic-to-the-zone-webserver

Die automatischen Regeln sind bei uns vorhanden und

Code Select Expand

__captiveportal_zone_0 ist ebenfalls da.
You cannot view this attachment.
Diese Regeln sollen laut Anleitung neu angelegt werden. Wenn man das macht (Firewall -> Regeln -> + ) erscheint unter Quelle das Alias für die Captive-Portal-Zone leider nicht. Das gilt aber auch für alle anderen automatisch angelegten Aliase.

Daher nochmal die Frage, wie man hier weiter vorgehen soll oder ob das weiterhin ein kleiner Fehler ist?
(Auf einem 2. Testsytem haben wir das ebenfalls genauso beobachtet.)

[nicht]

Hallo.
Wir haben hier seit dem Update von 25.1.5_4 auf _5 das bekannte Problem mit dem Captive Portal: Es war bei uns so wie hier beschrieben:
https://forum.opnsense.org/index.php?topic=46796.0

Mittlerweile ist Version 25.1.5_6 erschienen mit einem Fix für das Problem. Wir haben diese Version heute installiert und die Option

Code Select Expand

[x] Disable firewall rules

If this option is set, no automatic firewall rules for portal redirection
and traffic blocking will be generated. This option allows you to override
the default portal behavior for advanced use cases, such as redirections
for DNS.
See the documentation to see which rules you should implement in this scenario.
ist nun auch vorhanden. Leider funktioniert das Captive Portal bei uns aber weiterhin nicht.
Es ist so: Wenn man den Haken setzt

Code Select Expand

[x] Disable firewall rules ist man sofort online -- allerdings erscheint das Captive Portal nicht!

Wenn man den Haken allerdings nicht setzt

Code Select Expand

[ ] Disable firewall rules
ist man nicht online, aber das Portal erscheint auch hier nicht automatisch.

Wenn man das Captive Portal manuell über Port : 8000 aufruft, kann man sich anmelden und ist anschließend online. Nur das automatische Einblenden funktioniert nicht mehr.

Wir haben auch diese Seite gefunden:
https://github.com/opnsense/core/issues/8585
Dort schreibt AndyX90:

Update: The issue seems to be related to the NAT Rule, which redirects DNS traffic on cp-interface to the BIND DNS.
Disabling was somehow not enough, i had to delete it.
For the moment i will use unbound on the portal interface.

Was genau ist hier zu tun?

Übrigens: Bei uns läuft AdGuard mit auf der OPNSense. Kann es da einen Zusammenhang geben, dass das Portal nicht mehr erscheint?

Hat jemand von Euch das Problem bereits gelöst?
Danke für einen guten Tipp.

Hi.
We installed the patch 09324af (https://github.com/opnsense/core/commit/09324af15d14d58c0937d74d26d451db673c3468) to fix the problem.
Now there ist the option under "Captive Portal -> Settings"

Code Select Expand

[x] Disable firewall rules

If this option is set, no automatic firewall rules for portal redirection
and traffic blocking will be generated. This option allows you to override
the default portal behavior for advanced use cases, such as redirections
for DNS.
See the documentation to see which rules you should implement in this scenario.

But it still does not work: If activated everyone is online and the captive portal does not appear
If not activated: Not online

So: What else to do in this case?
Thanks.

... we have the same issue here with OPNsense 25.1.5_5-amd64

Hallo.
Wir haben hier ein merkwürdiges Problem mit Crowdsec, das ich nicht verstehe.
Es geht um die Domain *.webuntis.com, die innerhalb unseres Netzes neuerdings sehr häufig aufgerufen wird. Diese Domain wird neuerdings von Crowdsec intern gesperrt (nicht permanent sondern mittlerweile zum zweiten Mal) -- mir ist aber nicht klar warum: Eigentlich sollte das Tool doch nicht bei Aufrufen von innen die Domain blockieren, oder?
Ich habe den Dienst im Moment deaktiviert, doch unter

Code Select Expand

/usr/local/etc/crowdsec/parsers/s02-enrich
existiert bereits eine Datei

Code Select Expand

mywhitelists.yaml.
 Wie müsste dort ein entsprechender Eintrag für die Domain aussehen? Und: Warum reagiert Crowdsec so, obwohl es doch eigentlich Angriffe von außen abwehren soll??
Zudem: Ich sehe im OPNSense-WebUI nichts davon. Sollten die gesperrten Domains dort nicht auch aufgelistet werden?
Vielen Dank.

Das meinte ich nicht. Wenn deine Domain "meine.domain" ist, dann benutz die für extern erreichbare Services und das sowohl von innen als auch von außen. Aber benutz sie nicht als Domain für DHCP und schlimmstenfalls Active Directory (falls du eine Firma bist und sowas hast).

Dann bin ich beruhigt, denn das haben wir so.

Ich habe es nochmal so versucht wie Ihr es vorgeschlagen habt aber es hat leider nicht funktioniert. Die OPNSense lauscht jetzt auf Port :8443 und auch sonst sind die Optionen so gesetzt wie oben genannt. Allerdings konnte ich den (internen) Server (docker-Container) leider nicht mit gültigem LE-Cert erreichen. Es wurde immer das Cert des Containers verwendet.
Ich habe zwischendurch sogar mit einem A-Record auf die WAN-Adresse versucht um zu schauen, ob es daran liegt ... aber das hat nichts geändert.

Am Ende habe ich es dann so gemacht wie sonst: Das LE-Cert von der OPNSense auf den docker-Container kopiert und direkt dort eingebunden. Zusätzlich die Domain-Überschreibung auf der OPNSense auf die lokale IP wieder aktiviert. Immerhin läuft es jetzt; auch wenn das erneut der umständliche (und schlechtere) Weg ist. Aber wie auch immer: Besten Dank für's Mitdenken. Ich schaue mir in Kürze os-caddy an...

Ja, das kann sein -- bei der Ersteinrichtung des Servers stand damals genau diese Frage im Raum: Intern und extern den gleichen FQDN verwenden oder nicht. Leider waren wir da schlecht beraten und haben uns dafür entschieden.

Die Sache mit dem "transparent" schaue ich mir aber nochmal an -- vielleicht klappt's ja trotzdem noch

Du benutzt intern und extern dieselbe Domain? Mach das halt nicht ;-)

Dann ist *das* das Problem ... das kann ich leider nicht so einfach ändern.
Den Port der OPNSense werde ich aber noch auf :8443 oder sowas legen.

[nochmal]

Ja, das machte ich ja auch. Aber wie gesagt: wenn ich den Eintrag im Unbound deaktiviere, erhalte ich seltsamerweise das Zertifikat der Firewall. Wenn ich ihn aktiviere, wird natürlich auf die interne IP des Servers umgeleitet. Dann benötigt der Server aber leider nochmal zusätlich das richtige Zertfikat -- und genau auf diesen Schritt würde ich gerne verzichten. Vermutlich fehlt da nur eine Kleinigkeit...

Wenn du gleichzeitig über einen DynDNS-Anbieter dafür sorgst, dass der A-Record immer stimmt, dann natürlich.

Ok, vermutlich habe ich an dieser Stelle ein Brett vor dem Kopf. Bei uns ist es so, dass unser ISP keine feste IP anbieten kann und wir daher auf dyn-DNS-Anbieter angewiesen sind. Die Aktualisierung übernimmt die OPNSense über "Dienste: Dynamisches DNS: Einstellungen".
Und unter "Dienste: Unbound DNS: Überschreibungen"  kann ich dann doch keinen A-Record auf die WAN-Adresse einrichten, oder? Der ändert sich ja "ständig"...

Es ist ja eher im Gegenteil so, dass wir bei uns im Moment intern den "falschen Weg" gehen und im Unbound die Domain-Überschreibung für die Server nutzen, die auch intern von den Clients erreichbar sein sollen (daher auch das Problem mit dem zu kopierenden LE-Cert auf den Server).
Wenn ich das ändere, bekommt ein Client beim Zugriff auf eine interne Adresse aber nicht das richtige Zertifikat.
Irgendwie sehe ich den Wald vor lauter Bäumen nicht, fürchte ich!?