Messages

Danke fürs Kümmern.

Die neuen Zertifikate SIND tatäschlich in den angegebenen Verzeichnissen, aber anscheinnd können sie nicht von dort ins Zielverzeichnis kopiert werden. Was könnte sich denn da "verschoben" haben? Irgendwelche Rechte vielleicht? Ein kurzer Blick mit "ls -l" zeigt allerdings die gleichen Rechte wie auf den Verzeichnissen, auf denen es nach wie vor funktioniert. Und die Konfigurationen der funktionierenden und nicht funktionierenden Zertifikate sind meines Erachtens auch gleich. Seltsam, oder?

Oh, hat da niemand eine Idee zu? :-(

Ich habe ein Problem mit zwei Let's-Encrypt-Zertifikaten für Websites: Sie werden erneuert, können aber nicht "importiert" werden.
Bei anderen Zertifikitan mit exakt den gleichen Einstellungen (bis auf den Namen natürlich) funktioniert es tadellos.
Im Protokoll steht dann:

Code Select Expand

2025-05-20T00:00:17 opnsense AcmeClient: failed to import certificate: www.my-failing-url.de
2025-05-20T00:00:17 opnsense AcmeClient: unable to import certificate www.my-failing-url.de, file not found: /var/etc/acme-client/certs/5aa7b9d1a23c91.56093114/cert.pem
2025-05-20T00:00:17 opnsense AcmeClient: successfully issued/renewed certificate: www.my-failing-url.de
2025-05-20T00:00:15 opnsense AcmeClient: AcmeClient: The shell command returned exit code '0': '/usr/local/sbin/acme.sh --renew --syslog 6 --log-level 1 --server 'letsencrypt' --webroot /var/etc/acme-client/challenges --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/5aa7b9d1a23c91.56093114' --certpath '/var/etc/acme-client/certs/5aa7b9d1a23c91.56093114/cert.pem' --keypath '/var/etc/acme-client/keys/5aa7b9d1a23c91.56093114/private.key' --capath '/var/etc/acme-client/certs/5aa7b9d1a23c91.56093114/chain.pem' --fullchainpath '/var/etc/acme-client/certs/5aa7b9d1a23c91.56093114/fullchain.pem' --domain 'www.my-failing-url.de' --days '1' --keylength '4096' --accountconf '/var/etc/acme-client/accounts/5aa7b7170e8c73.36911464_prod/account.conf''
2025-05-20T00:00:03 opnsense AcmeClient: using challenge type: <my working validation>
2025-05-20T00:00:03 opnsense AcmeClient: using IPv4 address: <my external IP>
2025-05-20T00:00:02 opnsense AcmeClient: account is registered: <my account>
2025-05-20T00:00:02 opnsense AcmeClient: using CA: letsencrypt
2025-05-20T00:00:02 opnsense AcmeClient: renew certificate: www.my-failing-url.de
2025-05-20T00:00:02 opnsense AcmeClient: certificate must be issued/renewed: www.my-failing-url.de

Was geht da schief? Ich finde nicht, wo ich etwas falsch gemacht habe... zumal es ja mit anderen URLs problemlos funktioniert.
In /var/etc/acme-client/cert-home/<subdir> stehen auch die neu erstellten Zertifikate drin, sie werden also "nur" nicht importiert.

ZFS Snapshots FTW :-)

Das ist ja ein ganz anderes Thema, das mich aber auch interessiert: Bisher hatte ich die OPNsense als VirtualBox-VM laufen und habe da vor Updates, zumindest vor den größeren, immer einen Snapshot erstellt. Auf meinem Mint habe ich Timeshift. Sind "ZFS-Snapshots" das Pendant dazu?

Muss ich das manuell machen? Oder kann oder sollte ich das automatisieren? Konfigurationen werden ja, ist mir aufgefallen, automatisch gesichert.

Edit: Ja, ja, wer lesen kann, ist klar im Vorteil... hab's schon gefunden.
https://docs.opnsense.org/manual/snapshots.html

Interessanter ist dann doch eher meine Frage 2:

Es kommt ja manchmal vor (und zwar häufiger als Tod meiner eigenen Hardware), dass die Telekomiker ein Problem haben und die DSL-Leitung nicht aufzubauen ist. Dafür haben die mir extra eine SIM geschickt, die in meinem Vertrag enthalten ist...

Für diesen Fall will/müsste ich also ein LTE-Modem kaufen. Aber wie binde ich das dann ein? (Oder ist das ein neuer Thread?)
Wie sorge ich dafür, dass die OPNsense bei erfolglosem Verbindungsversuch auf der PPPoe-Leitung sich über das LTE-Modem einwählt?

Mir geht es wohl auch eher nicht um HA, sondern darum, dass ich online bin, falls aus irgend einem Grund die OPNsense-Hardware abstinken sollte.

(Ok, ich gebe zu, dass das jetzt nicht zu sehr wahrscheinlich ist, aber da ich die bisher genutzte VM ja noch habe, könnte ich die dafür doch weiternutzen... aber wenn das so viele Schwierigkeiten macht, dann verzichte ich eher...)

- Frage 1 also "gelöst". Danke

Schon blöd (von mir), wenn man zwei Fragen auf einmal stellt... :-(

War das jetzt die Antwort auf Frage 1 (Zwei OPNsenses an einem PPPoe) oder auf Frage 2 (PPPoe und dazu LTE als Fallback)?

Ich habe nun meine DEC697 laufen, habe aber auch noch die VirtualBox-VM.
Kann ich diese als "Fallback" nutzen, indem ich beide OPNsense-Instanzen als Cluster zusammenbaue?

Der Doku nach scheint das ja gar nicht so sehr schwierig zu sein, aber an einer Stelle sehe ich dann doch Schwierigkeiten:
Ich gehe per Zyxel-DSL-Modem ins Netz der Telekom (PPPoe), und natürlich kann nur eine der beiden OPNsense diese Verbindung nutzen.
Hardwaremäßig wäre es kein Problem, beide per Switch ans Zyxel zu klemmen, aber:

Kann ich erreichen, dass nur der MASTER die Verbindung aufzubauen versucht und das BACKUP dies erst tut, sobald der MASTER nicht mehr läuft?

Kann ich das umgekehrt auch mit zwei Netz-Zugängen machen, dass also die aktive (MASTER) OPNsense sich über ein LTE-Modem einwählt, falls das Zyxel mal nicht verfügbar ist. (Die Telekom bietet hierfür eigens eine Fallback-SIM an. Kann ich die also nutzen?)

Auf alle Fälle danke ich Euch!

Sorry, aber ich habe sowohl die OPNsense als auch meine eigenen Konfigurierungskünste unterschätzt, indem ich dachte, dass irgendwo noch eine falsche IP eingetragen wäre. (Zur Erläuterung: Die OPNsense-Appliance trägt die Konfiguration ihrer VM-Vorgängerin, lediglich mit angepassten Schnittstellenzuordnungen (natürlich) und mit geänderter interner IP (erschien mir besser).)

Mein Problem liegt jedenfalls nicht an der OPNsense, denn wenn ich einen echten Rechner per Switch in die DMZ hänge, hat er die volle Geschwindigkeit im Down- und auch im Upload. Das Problem tritt also nur bei den Rechnern auf, die als VM auf dem VB-Host laufen.

Das Problem muss also ein anderes sein, aber weil das Problem dann eher nicht hierhergehört, werde ich es im Ubuntu-Forum posten.

Betrifft das nur die Webseite / den Webserver, oder ist die Performance hinter deiner OPNsense generell so miserabel?

Tatsächlich scheint das aller ausgehender Verkehr zu sein (zumindest mit Windows-Kisten), aber das Problem ist wohk doch ein anderes (s.u.)

Wenn dann müsste da gewaltig was schief laufen. Ich würde mir erwarten, diesbezüglich  Log Einträge im System Log zu finden. Ist da nichts?
Falls nicht, mach mal ein Packet Capture am jeweiligen Interface, um zu sehen, ob mit den Paketen was unrund läuft.

Grundsätzlich wüsste ich aber gern

• Wo finde ich die Logs?
• Wie kann ich eine Packet Capture machen?

(Erläuterung: Ich arbeite bisher nur mit der GUI der OPNsense.)

Hast du schon mal unter Reporting > Traffic geschaut? https://docs.opnsense.org/manual/reporting_traffic.html

Ja, das habe ich getan, und tatsächlich ist der eingehende Verkehr auf der DMZ-NIC sehr gering.
Allerdings verlagert sich das Problem gerade weg von der OPNsense, Danke dennoch für den Tipp!

[210 kbit/s]

Das ist wirklich ganz katastrophal... ich habe auf diesem Subnetz gerade einen Geschwindikeitstest laufen lassen, und ich komme dort auf die erwartete Downloadgeschwindigkeit von 250 kbit/s, aber der Upload liegt nur bei 210 kbit/s! Woran kann das den bloß liegen?

Hat hierzu wirklich niemand eine Idee?
Ich lade gerade etwas von meiner eigenen Website herunter und komme dabei auf gut 25 KB/s. Da stimmt doch etwas nicht.

Vorher, als die OPNsense noch als VM lief, hatte ich dieses Problem nicht.

Ich habe nun endlich meine Virtualbox-VM gegen eine DEC697-Appliance getauscht und konnte die auch "überschaubar schwierig" einrichten.

Jetzt scheine ich aber das Problem zu haben, dass meine Website nur noch sehr langsam ausgeliefert wird. Kann ich irgendwo die "Durchflussgeschwindigkeit" nachsehen?

Meine Konfiguration bisher: OPNsense als VM mit drei NICs (WAN, LAN und DMZ), Webserver auf dem selben VB-Host
Meine Konfiguration jetzt: OPNsense als Appliance, Host-NIC der DMZ steckt direkt in der Appliance