OPNSense Update (Erfahrungen)

Hi.
Das Upgrade auf die 24.1 haben wir auch hinter uns.

Eine Sache ist uns aber dann doch aufgefallen: wenn man die OPNSense dazu verwendet, LE Zertifikate erstellen zu lassen, hat sich mit dem 24er Update der Pfad geändert, wo die Certs abgelegt werden! Muss man bedenken, wenn man (so wie wir) die Zertifikate vom v7-Server per scp von der Opnsense holen will…

Viele Grüße
Michael

Hallo,
beim Update von 23.7.12 auf 24.1 gab es bei mir zunächst eine Fehlermeldung.

…Error in upgrade script ‚20-unbound-duckdb.py‘ …

Die Lösung war recht schnell zu finden: https://forum.opnsense.org/index.php?topic=38430.0
Einfach vorher unter Berichterstattung → Einstellungen → "Unbound DNS reporting „Reset DNS data“ anklicken. Danach läuft das Update durch.

Viele Grüße
Michael

1 „Gefällt mir“

Ich habe gerade das Update auf OPNsense 24.1.6 durchgeführt – bisher alles ohne Probleme.

Eine sehr sinnvolle Neuerung ist jetzt an Bord:
→ VPN → WireGuard → Peer Generator
Damit kann man VPN-Zugänge über Wireguard sehr schnell erzeugen :+1:

2 „Gefällt mir“

Hallo.
Falls jemand auf der OPNSense den Dienst „Dynamisches DNS“
os-ddclient (installiert) 1.21_2 OPNsense Dynamic DNS client
zusammen mit freeDNS/afraid verwendet und sich wundert, dass der Dienst in den letzten Tagen nicht mehr richtig lief:

Die Einstellungen für den ddclient haben sich seit einem Update geändert.
Neue Einstellungen hier: I can't find instructions for freedns.afraid.org

Viele Grüße,
Michael

1 „Gefällt mir“

Moin,
Michael hat in diesem Beitrag schon darauf hingewiesen - im Update auf 24.1 haben sich die Pfade für die Zertifikate geändert, die man mit dem ACME-client automatisch aktualisieren lassen kann.
Wir nutzen ein Automation plugin, dass die Zertifikate danach automatisch auf den Server kopiert – das hat jetzt natürlich nicht mehr getan. Wir mussten in

/usr/local/opnsense/service/conf/actions.d/actions_ldapserver.conf

die Zeile

command:scp -i /root/.ssh/id_rsa_samba /var/etc/acme-client/home/example.server.de/* root@10.16.1.1:/etc/samba/tls

ändern in

command:scp -i /root/.ssh/id_rsa_samba /var/etc/acme-client/cert-home/*/example.server.de/* root@10.16.1.1:/etc/samba/tls

Gruß
Sascha

1 „Gefällt mir“

Ja – das ist genau das „Problem“: Jetzt liegen die Zertifiakte in irgendwelchen „kryptischen Unterverzeichnissen“ (vielleicht IDs?). Zum Glück kann man das aber trotzdem schnell zuordnen und wiederfinden, indem man auf der OPNSense unter
root@firewall:/var/etc/acme-client/cert-home/ in die einzelnen Unterverzeichnisse schaut, denn darin sieht man wieder die Namen, für die die Zertifkate ausgestellt wurden. Am schnellsten so:
find . -type d -maxdepth 2 -mindepth 2

Wir kopieren von dort ebenfalls die LE-Zertifikate auf diverse andere VMs … funktioniert.

In der Zwischenzeit hat sich übrigens noch ein anderes Problem gezeigt, das meiner Meinung nach erst seit dem letzten Upgrade vorhanden ist:

Wir nutzen das Captive Portal der OPNSense. Dort haben wir ein paar „Allowed MACs“ eingetragen, die ohne Portal online sein sollen. Das funktioniert aber nicht mehr. Die Adressen werden ignoriert und stattdessen wird auch auf diesen Clients das Portal gezeigt. Kann das jemand bestätigen oder sind nur wir davon betroffen?
In den OPNSense-Logs habe ich das hier gefunden:

tail /var/log/configd/latest.log

#Script action failed with Command '/usr/local/opnsense/scripts/OPNsense/CaptivePortal/
listClients.py /zoneid '0' /output_type 'json'' returned non-zero exit status 1. at Traceback (most 
recent call last):   File "/usr/local/opnsense/service/modules/actions/script_output.py", line 44, in 
execute subprocess.check_call(script_command, env=self.config_environment, shell=True,   File "/
usr/local/lib/python3.9/subprocess.py", line 373, in check_call     raise CalledProcessError(retcode, 
cmd) subprocess.CalledProcessError: Command '/usr/local/opnsense/scripts/OPNsense/
CaptivePortal/listClients.py /zoneid '0' /output_type 'json'' returned non-zero exit status 1.
Versionen 	
OPNsense 24.1.6-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13

vorübergehende Lösung:

1 „Gefällt mir“

Das Update auf OPNsense 24.1.8 lief hier gerade durch.
Bisher ohne erkennbare Probleme…

Ich berichte auch mal von meiner erneut kurzen Erfahrung mit OPNsense!
Nachdem ich die Sense installiert hatte, wollte ich natürlich erstmal per LAN ins Internet das per WAN an der FritzBox hängt. Egal was ich versucht hatte, alles auf durchzug (* * *) liefs nicht. Auch Leute die mir zu helfen versucht haben waren überfragt.

Nutze un Sophos, loift Problemlos!

Das kannst Du aber kaum einem OPNSense-Update anhängen, würde ich meinen!??

Hätte ich auch gemeint, nach dem Zurückrollen auf die alte Version ging es wieder. :slight_smile:

So etwas gravierendes müsste aber im OPNSense-Forum diskutiert werden, denke ich :thinking: :interrobang:

Könnte türlich auch an mir liegen, aber soviel ich sehe sind es 1:1 die selben Einstellungen. :slight_smile:

Hallo!
24.1.8 läuft bei mir auch stabil.
LG
Max

2 „Gefällt mir“

Hallo @t.sever ,

ist natürlich jetzt müssig, darüber zu spekulieren. Oben hatte ich auch so eine Situation erwähnt, die ich nicht vollständig debuggen konnte in der Zeit.
War ein Gatewayproblem…
Als ich es dann Monate später identisch probierte, gab es kein Problem mehr.
Auch bei mir ist müßig, darüber zu spekulieren, an was es genau lag.
Dafür gibt es ja diesen Thread, damit man oben schauen kann: oh, da könnte es ein Problem geben.

Nicht jeder kann mal schnell auf eine externe Lösung zugreifen (oder will auf eine closed-source Lösung umsteigen).

Langfristig hat die opnsense bisher bei mir weniger Probleme bereitet als andere Bausteine (bsp: Nextcloud-Erweiterungen, Matrix, docker-rebuilds)

2 „Gefällt mir“

Hallo,

Hast du mal die NAT-Regeln auf Fritzbox und OpnSense kontrolliert? Die braucht es ggf. auch zusätzlich zu den Allow-Regeln, die den Interfaces zugeordnet sind.

VG
Buster

Ja, hatte ich. Wirklich alles versucht.

Hallo,
heutiges Update auf 24.7 hat problemlos funktioniert.
LG
Michael

Danke, @michael_kohls ,
bei mir heute auch, aber ich nutze außer eine wireguard-verbindung nur die typischen Firewall-Features.

Hinweise aus dem Changelog, die vielleicht den ein oder anderen in den Hintern beißen:

system: remove obsolete SSH DSA key handling

interessant für unsere Doku, die vielleicht neue screenshots braucht:

The dashboard has been replaced. 

und am schönsten die netten Hinweise auf den Codename „Thriving Tiger“:
grafik

3 „Gefällt mir“