Show Posts
1
German - Deutsch / Re: OPNsense nach Herunterfahren und Starten erreichbar, aber nicht bei Neustart
« on: December 02, 2024, 04:43:37 am »
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:
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:
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:
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
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]
***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]
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]
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 deviceAlles 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