OPNsense Forum
International Forums => German - Deutsch => Topic started by: Emma2 on August 14, 2023, 02:32:51 pm
-
Ich habe gerade remote die opnSense von 23.1 auf 23.7 aktualisiert, sie startet dort einwandfrei, und ich kann den IPSEC-Tunnel aufbauen. Sobald ich jedoch versuche, das Webinterface aufzurufen, startet die opnSense neu! (Ich kann das sehen, weil ich parallel per xfreerdp /v:meinHost /port:meinPort auf die entfernte Konsole komme.)
Ist dieses Verhalten bekannt? Oder mache ich etwas falsch? Hat jemand vielleicht eine Idee?
-
Ohje... dieses Verhalten ist reproduzierbar. Ich habe die opnSense gerade zurückgesetzt, nach dem ersten Update (ich meine, das war 23.1.1 auf 23.1.11) klappt noch alles, aber nach dem Update auf 23.7.1_3 bringt der Aufruf (!) der WebGUO das System zum Neustart. Das kann doch wohl kaum richtig sein... (Per Konsole, d.h. xfreerdp auf dem Host, aber auch per SSH komme ich gang prima auf das System.)
-
Gibts dazu nen crash dump?
Grüsse
Franco
-
Ich weiß gar nicht, ob das ein Crash ist oder der "einfach rebootet".
Ich kenne mich allerdings mit BSD auch nicht so richtig aus: Wo finde ich den Crashdump?
-
Was passiert beim Aufruf des Web UI gleichzeitig auf der Konsole?
-
Also... :
- Ich habe zwei Standorte, verbunden durch IPSEC-Tunnel, am jeden Ende eine OPNsense.
- Hier fahre ich noch 23.1.1, in der Filiale (dort ist das Problem) ist schon das Update auf 23.1.11 erfolgreich.
- Den Host in der Filiale kann ich (auf sichere Art und Weise) auch direkt remote erreichen.
- Ich öffne eine SSH-Shell auf der entfernten opnSense - dort sehe ich später aber nichts.
- Ich öffne per xfreerdp eine "echte" Konsole auf der entferneten OPNsense.
- Ich baue den VPN-Tunnel auf
- Ich rufe von hier die WebGUI der entfernten OPNsense auf
- In diesem Moment "rattert" die Konsole schneller durch, als das ich das lesen könnte.
- (Da ich direkt auf dem Host bin, ist das unabhängig vom Tunnel, und die Konsole bleibt sichtbar.)
- Aber auf alle Fälle "passiert" da etwas, es ist nicht so, dass der Bildschirm (so wie bei Windows) einfach schwarz wird und die OPNsense neu startet.
- Es könnte also durchaus sein, dass sie rebootet, aber das geht zu schnell für mich zum Lesen.
Gibt es da nicht entsprechende Systemprotokolle?
-
In diesem Moment "rattert" die Konsole schneller durch, als das ich das lesen könnte.
1. Wir wäre es mit einem Film mit dem Smartphone?
2. Schau mal in /var/log/system/*
Wenn - was mein Verdacht ist - der Aufruf des UI eine Kernel-Panic auslöst, kann es allerdings sein, dass das System das nirgends mehr weggeloggt bekommt. Daher der Film ;)
-
Tatsächlich steht da etwas mit "panic":
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 80
fault virtual address = 0x0
fault code = supervisor read data, page not present
istruction pointer = 0x20:0xffffffff8115282a
(...)
panic: page fault
(...)
p.s.: Grundsätzlich würde ich ein Festplattenproblem des Hosts nicht ausschließen, aber dessen SMART-Info is "passed", und das Verhalten ist reproduzierbar, d.h. bei 23.1.7 und 23.1.11 läuft alles rund, bei 23.7 knallt es - aber nur beim Aufrufen der WebGUI, der Tunnel selbst steht ganz prächtig.
p.p.s.: Ich weiß weder, wie ich hier ein Bild noch den ganzen Film posten könnte...
-
Oh, noch ein vermutlich wichtiges Update:
Die "panic" tritt nur ein, wenn ich die WebGUI über den Tunnel öffnen will!
Ich habe mich gerade auf einem anderen remote Guest (Win7) angemeldet, um remote eine GUI zu haben.
Wenn ich von dort aus die WebGUI der entferneten OPNsense aufrufe (also relativ gesehen lokal), läuft alles normal!
Hat sich eventuell von 23.1.11 auf 23.7 etwas geändert, so dass meine Tunnel-Konfiguration "Panikmache" betreibt?
-
Noch ein Nachtrag: RDP durch den Tunnel funktioniert auch, es scheint also "alles" zu funktionieren, und die OPNsense "panicked" beim Aufruf der WebGUI durch den Tunnel. Kann es an meiner Firewall-Konfiguration liegen?
(... die allerdings bisher immer und unter 23.1.11 auch noch "ok" war...)
-
Bild der Panic auch gern via franco@opnsense.org
Da wird wohl was mit IPsec und FreeBSD 13.2 im Argen sein.
Danke,
Franco
-
Moin zusammen,
ich beobachte das Problem auch seit einiger Zeit. Die Weboberfläche "stirbt" sobald man am IPsec aktiv konfiguriert oder z.B. einige Tunnel kurz nacheinander neuaufbaut etc...
Das äußert sich so, dass die Status Page dann leer bleibt, die VPNs gehen nach und nach offline und am Ende ist auch die Oberfläche tot.
Workaround ist aktuell folgender: charon Dienst über CLI killen, WebGUI Restart, IPsec deaktivieren, IPsec aktivieren und IPsec restart. Danach langsam die VPNs nach und nach wieder aufbauen. Dabei empfiehlt es sich Geduld mitzubringen. Ist man zu schnell, muss die ganze Prozedur erneut durchgeführt werden.
Aktuell befinden sich rund 40 aktive Tunnel auf meiner OPNsense Installation.
-
@Emma2 setz mal diese Tunable:
Name: kern.ipc.mb_use_ext_pgs
Wert: 0
und boote dann neu.
Wenn das hilft, dann sollte @franco diesen pr und alle verlinkten im Auge behalten:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271393
-
Workaround ist aktuell folgender (...)
Bin nicht sicher, ob ich das anwenden kann, denn das Problem tritt ja gerade auf der entfernten OPNsense auf. wenn ich IPSEC beende, dann bin ich runter...
Außerdem habe ich ja so lange kein Problem (zumindest noch keines bemerkt), so lange ich nicht die WebGUI über den Tunnel starte.
Mein Workaround sieht deshalb so aus:
Starte eine RDP-Verbindung zu einem GUI-fähigen Rechner im entfernten Netz und rufe von diesem aus die WebGUI auf.
-
@Emma2 setz mal diese Tunable:
Name: kern.ipc.mb_use_ext_pgs
Wert: 0
und boote dann neu.
Wenn das hilft, dann sollte @franco diesen pr und alle verlinkten im Auge behalten:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271393
Das will ich gern probieren, aber da ich - wenn überhaupt - immer nur über die WebGUI konfiguriere, brauche ich Hilfe, wie und wo ich das einstellen kann.
-
System > Settings > Tunables - oben rechts auf das kleine "+" klicken, "Tunable" und "Value" ausfüllen wie beschrieben, speichern und "Apply". Dann Reboot.
-
Jau, hat funktioniert! Dicken Dank!
... und ich nehme an, ich sollte auf der hiesigen OPNsense diese "Optimierung" auch einstellen, falls ich nächste Woche aus der Filiale hier zu Hause zugreifen will...?
Dem FreeBSD-Thread nach, den Du verlinkt hast, ist das ein Bug im FreeBSD? Kann man davon ausgehen, dass der repariert wird? Und wenn ja, soll ich dann das Tunable wieder rausnehmen, oder "schadet das nicht"?
-
Bug Tickets mit Patches sind immer gut :)
https://github.com/opnsense/src/commit/b2137fe25a
# opnsense-update -zkr 23.7.1-ipsec
# opnsense-shell reboot
(dauert vielleicht bis es auf dem anderen Mirrors zu sehen ist)
Grüsse
Franco
-
Sorry für mein Unverständnis: Heißt das, es ist schon repariert? Und ich kannin Ruhe auf das nächste Update warten?
Oder kann ich das mit diesen beiden Aufrufen manuell holen und einspielen?
Dann bliebe immer noch die Frage, ob man danach das "Tunable" drin lässt oder es besser wieder löscht?
-
Da du der geeignetste Tester bist wäre es super wenn du es verifizieren könntest. Ich denke aber schon der Workaround und der Patch gehören zusammen. Nur nicht vergessen den Workaround wieder rückgängig zu machen. :)
Grüsse
Franco
-
Will ich gern tun, aber dann bitte step-by-step für einen einfachen Menschen wie mich:
- Der Wokraround mit dem Tunable scheint zu helfen.
- Soll ich nun in einer Shell die beiden Befehle ausführen?
- Und danach das Tunable "probehalber" wieder entfernen?
-
1. Tunable löschen.
2. Kommandos ausführen um den neuen Kernel zu laden und neu zu starten wenn es past (geht leider nicht ohne).
3. Noch einmal versuchen zu verifizieren.
Danke,
Franco
-
Ja, das passt schon - ist ja nur die "Filiale" (und die ist unbemannt ;-).
Das scheint funktioniert zu haben, und im Dashboard steht nun
OPNsense 23.7.1_3-amd64
FreeBSD 13.2-RELEASE-p2
OpenSSL 1.1.1v 1 Aug 2023
Nachtrag:
Ich habe nach dem entfernten Reboot von hier aus den Tunnel aufgebaut und mich dann direkt mit dem Firefox auf die WebGUI verbunden. Und die entfernte OPNsense läuft immer noch.
-
... aber jetzt habe ich ein anderes "Problem" (oder nicht?):
Ich habe in der GUI nach Aktualisierungen gesucht, und dann steht dort "Es sind 1 Aktualisierungen verfügbar, gesamte Download-Größe beträgt 31.3MiB. Diese Aktualisierung erfordert einen Neustart." sowie "Aktuelle Version 23.7.1-ipsec" und "Neue Version 23.7.1". Ich gehe davon aus, dass das eher ein Downgrade auf die Bugversion wäre als ein Update?
Ich muss also in Zukunft aufpassen, was dort steht und darf erst updaten, wenn da eine höhere Nummer steht?
-
Oder du baust den Würgaround ein.
-
Dein Tunable meinst Du? Sind die gleichwertig?
(Ich gebe zu, dass ich die OPNsense ziemlich ohne tieferes Verständnis "einfach nur anwende"...)
-
Es gibt einen Fehler im FreeBSD-Code, der zu dem Crash führt. Der Tunable, den ich dir gegeben habe, schaltet diese Funktion (sog. "unmapped mbufs") einfach kategorisch ab.
Der Patch, der sicher in FreeBSD und auch in OPNsense landen wird, schaltet die Funktion nur für IPsec ab - was natürlich die korrekte Lösung ist. Bzw. die erste korrekte Lösung, denn langfristig wird man dann wohl IPsec beibringen, ebenfalls mit unmapped mbufs umzugehen.
Letztendlich geht es darum, ob Pufferspeicher für Netzwerk-Traffic mehrere Speicherseiten enthalten dürfen oder ob es ein 1:1 "Mapping" gibt. Nötig ist das, also das "unmapped", für Netflix Kernel-TLS und generell für den maximalen Durchsatz in deren Edge-Boxen.
-
Ok, danke, das "verstehe ich ein bisschen" ;-)
Um nicht zu viel am (zum Glück wieder) funktionierenden System herumzubasteln, kann ich also folgendes tun:
- Ich lasse die entfernte OPNsense mit dem Kernelpatch
- Ich mahce das Gleiche (Update bis 23.7, dann Kernelpatch) auf der hiesigen OPNsense
- ... ich warte ab ...
- Sobald ein Update mit einer höheren Nummer als 23.7. auftaucht, kann ich das installieren
- Falls der Fehler dann wieder auftritt (weil er noch nicht offiziell gefixt ist), baue ich den Würger wieder ein
Könnte das ein sinnvolles Handling sein?
-
Ich würde es mir so einfach wie möglich machen und die Tunable auf beiden Systemen setzen. Mit dem nächsten Update dann die Release-Notes checken und dann ggf. wieder raus.
Aber jeder wie er mag.
-
Ohje, das überfordert mich 8)...
Dann muss ich ja zuerst einmal den Kernelpatch rückgängig machen? Oder soll ich den drin lassen? Oder soll ich ds "Update auf 23.7" machen?
-
Wenn du die Tunable drin hast, kannst du jederzeit wieder auf den Update-Knopf drücken, musst aber nicht. Deshalb finde ich die Variante einfacher.
Es macht überhaupt nichts, den Patch von Franco drin zu haben und die Tunable.
-
Ok, nochmals lieben Dank, dann mache ich das so.
-
Unabhängig noch mal: wenn der Kernel Patch hilft ohne dass der Workaround (Tunable) im System ist, dann können wir auch sicher gehen, dass der Patch funktioniert und diesen direkt in 23.7.2 freigeben.
Wird der Workaround verwendet (mit oder ohne Kernel) bekommen wir diese Information nicht und der Workaround ist wahrscheinlich auch weniger performant aus den von Patrick genannten gründen.
Der Kernel will beim Update auf den "korrekten" Kernel zurück, aber wenn wir die o.g. Bestätigung hätten ist das ab 23.7.2 ja schon kein Problem mehr weil dann 1:1 getauscht wird und alles so bleibt wie bisher (ausser dass sich der Kernel Name ändert).
Grüsse
Franco
-
Verstanden, Franco - ja, mangels anderer Testumgebungen ist das vielleicht wirklich das Beste, wenn @Emma2 nur den Patch verwendet.
Aber über die Performance mache ich mir da keine Sorgen. Das betrifft sendfile() und Zeug, das auf dem Host läuft, nicht das Packet-Forwarding (so weit ich verstanden habe). Das ist ähnlich wie mit TCP txcsum, rxcsum - das ist bei Paketen, die *durch* die Firewall laufen alles völlig schnurz, deshalb kann man das problemlos deaktivieren.
-
Oh, Menno, Ihr zwei macht mich ganz wuschig... :o
Ich bin zwar auch Softwareentwickler, aber eher in Anwendungssoftware zu Hause, daher verstehe ich maximal die Hälfte von dem, was Ihr Euch gerade um die Ohren haut.
Im Sinne der Sache werde ich also nun auf der entfernten OPNsense das "Tunable" von Patrick wieder rausnehmen, die Version auf "23.7.1-ipsec" stehen lassen und beobachten, ob alles ohne Probleme weiterläuft. (Hoer lokal läuft allerdings nur das Tunable, und ich will nicht direkt wieder neu starten... wenn Euch das recht ist...)
-
Danke, keine Sorge :)
Grüsse
Franco
-
Mache ich gerne - bei der vielen Unterstützung, die ich hier schon genossen habe, trage ich wirklich gern auch mal selbst ein bisschen bei...
Nach Entfernen des Tunable startet die entfernte OPNsense einwandfrei, ich kann von hier den IPSEC-Tunnel aufbauen, und ein Start der WebGUI durch den Tunnel löst keine Kernel-Panic aus.
Kann oder sollte ich aktiv noch etwas anderes testen?
-
Das reicht schon. Vielen Dank. Sollte es die Tage dennoch wieder Probleme geben bitte Bescheid geben. Ich bereite dann schon mal alles vor für die 23.7.2 (nächste Woche).
Grüsse
Franco
-
Hi.
Ich weiß nicht, ob ich dafür einen neuen Thread aufmachen soll, aber es gibt ein "Folgeproblem":
Nachdem ich gerade die entfernte OPNsense in Ruhe heruntergefahren und deren Snapshots (VirtualBox) bereinigt hatte, habe ich sie neu gestartet. Die Downtime war lang genug, dass sie eine neue dynamische IP bekam. Das habe ich daran gemerkt, dass ich den Tunnel nicht mehr aufbauen und mich auch per SSH/Hostname nicht mehr einloggen konnte, sehr wohl aber per SSH/IP. Nachdem ich nun bei Dyn.com manuell die korrekte IP eingetragen habe, läuft wieder alles. Es scheint also eindeutig am DynDNS-Client zu liegen.
Bei mir ist das "Dynamic DNS (legacy)", und bei dem steht folgerichtig auch: "Please make sure to upgrade to os-ddclient before 23.7 is released as this plugin will be removed from our repository" Heißt das, dass dieser alte Client nun nicht mehr läuft? Mir scheint das so, denn in ihm steht auch immer noch die alte "Dyn IP".
Wie gehe ich am besten vor? Ich habe nun unter "System-Firmware-Erweiterungen" nach "os-ddclient" gesucht und diesen installiert, unter "Dienste" taucht er dennoch nicht auf. Ich sollte ihn doch aber konfigurieren, ehe ich die OPNsense neu starte?
Weiterhin fällt mir auf, dass in der Liste der Erweiterungen ein paar Dienste als "misconfigured" stehen, sie scheinen aber korrekt zu laufen - doch das sollte wohl ein neue Thread sein, denke ich.
-
Achso, alles zurück. Offenbar heißt der Dienst in der deutschen WebGUI "Dynamisches DNS". Werde ich mal konfigurieren und dann weitersehen...
-
Ich mache besser mal einen neuen Thread auf für den ddclient.
-
Info: Nach dem Einspielen des neuen Updates gibt es diesbezüglich keine Probleme.
-
Danke noch mal für die Hilfe hier :)