Messages

Es lag an der SSD selbst. Ich habe meine Konfiguration auf einer anderen SSD importiert und danach funktionierte alles problemlos.
Auf meiner bisherigen SSD tritt die Neustartproblematik selbst nach einer kompletten Neuinstallation mit der Initialkonfiguration auf.

Grüße

OffeneSense

Vielen Dank für Deine Antwort. :)

LAN Deiner OpnSense keine IP zugewiesen bekommt

Sehe ich auch so, allerdings scheint das für mich nur ein Symptom der eigentlichen Ursache zu sein.

Ich kann mir nicht vorstellen, dass das mit der Erkennungsreihenfolge von USB und SSD zu tun hat

Ich mir auch nicht mehr, nachdem ich es auf einer anderen OPNsense gegengetestet habe, wie in meinem vorherigen Beitrag erwähnt.

Was für eine Hardware ist das denn?

Lenovo M720q mit einer Intel I219-V auf der Hauptplatine und einer Intel I-350-T4 im PCIe-Steckplatz.
Die Hardwarekomponenten haben sich zwischenzeitlich auch nicht verändert.
FreeBSD und Realtek sind ja leider noch nicht beste Freunde.

Könnten noch irgendwelche Protokolle aufschlussreich sein, die ich mir ansehen kann?

Grüße

OffeneSense

Ich habe nun einen Weg gefunden, um auf die Weboberfläche meiner OPNsense zu kommen, wenn sie im fehlerhaften Modus nach einem Neustart ist.
Die einzige Möglichkeit dafür ist über die ULA der OPNsense-Schnittstelle, wenn die Netzwerkverbindung über den Neustart hinaus zwischen Klient und OPNsense erhalten bleibt und sich so anscheinend die Netzwerkkonfiguration des Klienten via SLAAC nicht ändert.

Auf der Startseite wurden alle Dienste als laufend angezeigt.
Der zehnminütige Audit, der sonst wesentlich schneller geht, ergab auch keine Probleme:

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 24.7.9_1 (amd64) at Sun Dec  1 20:51:32 CET 2024
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 24.7.8 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 24.7.8 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
>>> Check installed plugins
os-caddy 1.7.4
os-theme-cicada 1.38
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 24.7.9_1 has 69 dependencies to check.
Checking packages: ...................................................................... done
***DONE***

Von den Klienten aus konnte ich die OPNsense nicht anpingen und umgekehrt auch nicht.
Ein Blick in die ARP-Tabelle der OPNsense ergab, dass dort nur die Adressen der Schnittstellen der OPNsense und die vom vorgeschalteten Router drin standen,
keine Adressen von dynamisch oder klientseitig statisch konfigurierten Klienten.
In der NDP-Tabelle standen nur die GUA, ULA und LLA der Schnittstellen der OPNsense und des vorgeschalteten Routers sowie die ULA und LLA der Klienten drin,
keine GUA der Klienten.
Die Klienten erhalten über den DHCPv4-Server eine Konfiguration, welche die korrekten Standardrouten, DNS-Server und IP-Adresse erhalten.
Dennoch erreiche ich vom Klienten aus über Pings nur Geräte aus dem eigenen Subnetz.
Verfolge ich die Route, geht diese nicht mal bis zur OPNsense.
Die Leases vom DHCPv4-Server werden über die Weboberfläche als gültig angezeigt, allerdings das zugehörige Gerät als inaktiv.
Im Protokoll von diesem wiederholen sich nach Neustart des DHCPv4-Dienstes die folgenden Meldungen für jeden DHCPv4-Klienten alle paar Minuten oder sogar Sekunden im Falle meines Smartphones:

Code Select Expand

Informational dhcpd DHCPACK on <private_IPv4-Adresse> to <MAC-Adresse> (<Hostname>) via <Schnittstelle>
Informational dhcpd DHCPREQUEST for <private_IPv4-Adresse> from <MAC-Adresse> (<Hostname>) via <Schnittstelle>
Debug         dhcpd reuse_lease: lease age 58 (secs) under 25% threshold, reply with unaltered, existing lease for <private_IPv4-Adresse>

Wenn ich von einem Klienten eine öffentliche Domäne über IPv6 auflösen kann, dann dauert es ca. acht Sekunden, bis das erste Antwortpaket über dessen Konsole angezeigt wird, obwohl die Antwort selbst laut Ausgabe nur ein paar Millisekunden dauerte. Führe ich den gleichen Ping nur ein paar Minuten später aus, kann es vorkommen, dass dann nur Temporary failure in name resolution erscheint.

Mit den Startoptionen habe ich auch noch herumprobiert.
Beim erweiterten Protokollieren wurden zwar nicht die grauen Bildschirmausgaben protokolliert, aber doch noch viele Zusatzinformationen.
Ich habe davon das fehlerfreie mit dem -behafteten Kernelprotokoll verglichen und konnte keine Unterschiede, abgesehen von der Reihenfolge des Einbindes vom Dateisystem, feststellen.
Dies habe ich nochmal auf einer zweiten OPNsense gegengetestet und dort war die Reihenfolge nach einem Neustart auch so und dennoch fuhr sie fehlerfrei hoch.
Das Starten mit einem älteren Kernel brachte keine Veränderung.
Der sichere Modus startet zwar schneller, aber brachte ebenfalls keine Besserung und zusätzlich gab es nur dabei Probleme mit meiner am Front-USB-Anschluss angeschlossenen Tastatur:

Code Select Expand

usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT
ugen0.2: <Unknown> at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device

Alles ist nach einem Neustart spürbar langsamer -- von den Ausgaben bei der Bildschirmkonsole bis hin zu Aufrufen auf der Weboberfläche.
Die Auslastung von CPU und RAM ist dennoch sehr gering.
Datum und Uhrzeit der OPNsense stimmen.
Test mit gekappter Verbindung zum vorgeschalteten Router änderte nichts.
Von der OPNsense aus selbst funktioniert das Auflösen von öffentlichen Domänen, sei es über IPv4 oder IPv6.
VPN-Verbindung von einem Klient zu meiner OPNsense und Aufrufen öffentlicher IP-Adressen vom Klienten über den Full-Tunnel funktionierte bei einem Test ebenfalls.

Falls keiner von euch noch einen Lösungsansatz hat, breche ich an dieser Stelle ab.

Grüße

OffeneSense

[heruntergefahren]

Ich habe mir nochmal die Ausgabe der Kernelmeldungen angesehen und dabei fiel mir hauptsächlich Folgendes auf:
Wenn sie fehlerfrei hochfährt, dann wird laut Protokoll meine SSD erkannt, ehe sie versucht, das Dateisystem einzubinden.
Wenn sie neugestartet wird und somit nicht fehlerfrei hochfährt, versucht sie das Dateisystem einzubinden und entdeckt dann erst die SSD.

Fehlerfrei (zuvor heruntergefahren):

Code Select Expand

ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
ugen0.1: <Intel XHCI root HUB> at usbus0
uhub0 on usbus0
uhub0: <Intel XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
nda0 at nvme0 bus 0 scbus0 target 0 lun 1
nda0: <SK hynix [zensiert]>
nda0: Serial Number [zensiert]
nda0: nvme version 1.2
nda0: 244198MB (500118192 512 byte sectors)
Trying to mount root from zfs:zroot/ROOT/default []...
Root mount waiting for: usbus0
uhub0: 22 ports with 22 removable, self powered
ugen0.2: <vendor 0x04d9 USB Keyboard> at usbus0
ukbd0 on uhub0
ukbd0: <vendor 0x04d9 USB Keyboard, class 0/0, rev 2.00/2.07, addr 1> on usbus0
kbd2 at ukbd0
ukbd1 on uhub0
ukbd1: <vendor 0x04d9 USB Keyboard, class 0/0, rev 2.00/2.07, addr 1> on usbus0
kbd3 at ukbd1
pid 31 (zpool) is attempting to use unsafe AIO requests - not logging anymore

Nicht fehlerfrei (zuvor neugestartet):

Code Select Expand

ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
ugen0.1: <Intel XHCI root HUB> at usbus0
uhub0 on usbus0
uhub0: <Intel XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
uhub0: 22 ports with 22 removable, self powered
ugen0.2: <vendor 0x04d9 USB Keyboard> at usbus0
ukbd0 on uhub0
ukbd0: <vendor 0x04d9 USB Keyboard, class 0/0, rev 2.00/2.07, addr 1> on usbus0
kbd2 at ukbd0
ukbd1 on uhub0
ukbd1: <vendor 0x04d9 USB Keyboard, class 0/0, rev 2.00/2.07, addr 1> on usbus0
kbd3 at ukbd1
Trying to mount root from zfs:zroot/ROOT/default []...
Root mount waiting for: CAM
nda0 at nvme0 bus 0 scbus0 target 0 lun 1
nda0: <SK hynix [zensiert]>
nda0: Serial Number [zensiert]
nda0: nvme version 1.2
nda0: 244198MB (500118192 512 byte sectors)
pid 31 (zpool) is attempting to use unsafe AIO requests - not logging anymore

Sonst unterscheidet es sich noch darin, dass einmal auf CAM und einmal auf usbus0 gewartet wird.
Der letzte Unterschied war die Reihenfolge bei Launching APs: 3 1 2 bzw. Launching APs: 2 1 3.

Über dmesg wurden aber nur die Bildschirmausgaben in weißer Schrift protokolliert, die in grau konnte ich daher leider nicht vergleichen. Kann man dafür den Protokollierungsgrad erhöhen?

Vielleicht bin ich auch einfach auf der falschen Fährte.

Grüße

OffeneSense

Nach einem solchen fehlerhaften Neustart ist mir noch Folgendes aufgefallen:
Direkt von der OPNsense aus erreiche ich öffentliche Webseiten per IP-Adresse und Namen, jedoch bekomme ich von meinen internen IP-Adressen nicht mal eine Antwort auf die Pings.
Die Klienten (Laptop, Handy) erhalten über IPv4-DHCP eine gültige Konfiguration und RA werden ausgesandt.
Über einen Laptop konnte ich nach einiger Zeit und mehrmaligen Aktualisieren der Internetseite eine sogar aufrufen -- bei der nächsten klappte es dann aber schon wieder nicht mehr. Die ausgelösten Firewall-Regeln konnte ich auch in der Bildschirmkonsole verfolgen.
Anpingen von öffentlichen IP-Adressen, abgesehen von der gerade aufgelösten, funktionierte vom Laptop aus unmittelbar danach trotzdem nicht.
Das Handy meldet immer gleich, dass es keine Internetverbindung hat.

Was ich sonst noch probiert habe:
Einen Audit der Firmware über die Weboberfläche, nachdem die OPNsense zuvor fehlerfrei heruntergefahren und neugestartet wurde, welcher keine Fehler feststellte.
Neustarten aller Dienste über die Bildschirmkonsole, als die OPNsense mit fehlerhaft neugestartet wurde, was aber keine Besserung brachte.
Neustarten der OPNsense über shutdown -r -- ebenfalls erfolglos.

Jemand eine Idee, was dieses Verhalten auslösen kann?
Wenn ich die OPNsense normal herunterfahre und dann starte funktioniert ja alles.

Grüße

OffeneSense

Guten Abend,

wenn ich meine OPNsense über die Weboberfläche, SSH oder eine angeschlossene Tastatur neustarte,
startet sie innerhalb von sieben Minuten und ich kann mich mit Tastatur an der Konsole anmelden.
Anschließend ist sie aber aus dem Netzwerk nicht mehr erreichbar und erreicht auch selbst keine Geräte mehr via Pings in der Bildschirmkonsole.
Das Problem bleibt bestehen, bis ich sie komplett herunterfahre.
Ein Herunterfahren über die Weboberfläche und dann das Betätigen der Einschalttaste fährt sie fehlerfrei in weniger als einer Minute hoch.

Erstmalig aufgetreten ist das bei einer der letzten größeren Aktualisierungen, also der 24.7 oder 24.1, als die OPNsense nach einer Stunde nach dem Aktualisierungsprozess immer noch nicht aus dem Netzwerk erreichbar war und ich sie schließlich manuell neustarten musste.

Beim Startprozess wird es spürsam langsamer ab den Schritten:

Code Select Expand

ZFS storage pool version: features support (5000)
ugen0.1: <Intel XHCI root HUB> at usbus0
Und bis

Code Select Expand

Mounting filesystems... erscheint, dauert besonders lange.
Alle anschließenden Schritte sind ebenfalls deutlich langsamer.

Sämtliche Plugins hatte ich zu Testzwecken bereits deinstalliert.
In den BIOS-Einstellungen habe ich in der Zwischenzeit nichts umgestellt und es ist aktuell.
Es ist als UEFI ohne CSM konfiguriert und OPNsense auf ein ZFS einer NVMe installiert.

Wird sie wirklich wegen dem Einhängen des Dateisystems langsamer und benötigt wegen dem Dateisystem einen sauberen Neustart oder ist es nur Zufall,
dass es ab diesem Punkt langsamer wird?

Falls noch Protokolle benötigt werden, stelle ich diese gerne zur Verfügung.

Grüße

OffeneSense