Delegated IPv6 Präfix wird sehr zeitverzögert aktualisiert

[franco]

Prevent release aus, auf die 23.1.9 rauf und Reboot. Wenn es immer noch nicht klappt prevent release wieder rein.


Grüsse
Franco

[Cyberturtle]

Bislang ist das Problem nicht wieder aufgetaucht, wenngleich es auch keinen Reconnect gab. Insgesamt scheint die Version 23.1.9 hervorragend zu laufen. In den Logs stehen auch regelmäßige Einträge mit "RENEW on pppoe0 executing" und das ganze scheint erfolgreich zu laufen.
Ich glaube, die Version 23.1.8 und .9 waren ein wichtiger Schritt in Sachen IPv6.

Ein kleiner (wohl aber doch eher großer) Schritt für die Devs und ein großer Schritt für die IPv6-User.  :)

[franco]

Ok, prima. Die eine Änderung mit der falschen WAN Adresse im rc.newwanipv6 Skript ist noch nicht drin. Noch nicht ganz durch die QA wegen weiteren Problemchen hier, aber kommt noch.


Danke
Franco

[Cyberturtle]

Hallo zusammen,

vergangene Nacht war es mal wieder soweit. Die Vermittlungsstelle hat Updates eingespielt und es kam zu einem Reconnect. Heute morgen hatte ich mich schon gefreut, dass sämtliche Interfaces eine neue IPv6-Adresse bekommen haben, also die Präfix-Aktualisierung hat geklappt. Allerdings bekommt keiner meiner Clients mehr eine IPv6-Adresse zugewiesen. Selbstverständlich ist die 23.1.11 installiert. In den Logs ist mir nur aufgefallen, dass der von Dir erwähnte Fix wegen QA noch nicht drin ist. Ich vermute dort allerdings nicht die Lösung. Nach dem Verbindungsverlust wurde SIGHUP am dhcp6c 2x ausgeführt und es sind auch die RENEWs dabei. Via UI und CLI sind auf dem igc0, igc2 und pppoe0 IPv6-Adressen zugewiesen. Kann sich der RA evtl. aufgehängt haben? Und wie kann ich das prüfen?

Viele Grüße
Cyberturtle

Edit: In den Logs ist mir noch was aufgefallen:

Code Select Expand


<12>1 2023-07-18T02:19:11+02:00 OPNsense.localdomain opnsense 50995 - [meta sequenceId="28"] /usr/local/etc/rc.newwanipv6: dhcpd_radvd_configure(manual) found no suitable IPv6 address on igc0
<12>1 2023-07-18T02:19:11+02:00 OPNsense.localdomain opnsense 50995 - [meta sequenceId="31"] /usr/local/etc/rc.newwanipv6: dhcpd_radvd_configure(manual) found no suitable IPv6 address on igc2
<13>1 2023-07-18T02:19:10+02:00 OPNsense.localdomain dhcp6c 53757 - [meta sequenceId="23"] dhcp6c_script: REQUEST on pppoe0 executing
<13>1 2023-07-18T02:19:10+02:00 OPNsense.localdomain dhcp6c 54765 - [meta sequenceId="24"] dhcp6c_script: REQUEST on pppoe0 renewal


Edit2: RADVD scheint sich aufgehängt zu haben. Ich habe ihn gerade neugestartet und der vergangene Nacht zugewiesene Präfix wird nun auch verteilt. Wäre es evtl. sinnvoll noch einen RADVD Restart einzubauen, wenn es zum RENEW mit Change kommt? Vielleicht könnte man ja zur Sicherheit ja neustarten, dann ca. 10 Minuten noch die alten Präfixe mit Deprecate verteilen und gleichzeitig auch den neuen?

[august]

Hallo zusammen,

ich weiß, dass es zu keinem Guten Ton in den Foren gehört, die "alten Leichen" wieder aus der Vergessenheit zu holen, dennoch frage ich trotzdem:

Ist das Problem inzwischen gelöst oder besteht es immer noch? Die Diskussion hier ruht leider seit Mitte letzten Jahres. Allerdings gab es auch keine abschließende Meldung "Ja, es läuft und ist bereits im Release drin", oder "Nein, es hat nichts gebracht, alles im Sande verlaufen".

Beim verlinkten Issue auf Github ist auch Ruhe seit Mitte letzten Jahres mit dem einzigen WorkArround, OPNsense doch jede Nacht per cron zu rebooten.

Ist es denn wirklich die einzig funktionierende Lösung derzeit?

Ich frage hier, da ich derzeit solche Probleme bei mir beobachte. Bevor ich aber hier lange Romane schreibe und meine komplette Konfiguration und Screenshots poste, wollte ich zunächst algemein fragen, ob das Problem denn generell immer noch besteht oder ob es vielleicht an mir liegt.

Danke!

[Cyberturtle]

Hallo august,

ich kann dir leider nicht sagen, ob das Problem abschließend behoben ist. Am Ende wurde es bei mir durch die neueren Versionen zwar besser, ich hatte allerdings keine Zeit das weiter zu beobachten und ggf. zu fixen, da ich aus beruflichen Gründen eine verlässliche Lösung akut benötigt hatte. Ich habe meine alte Fritzbox als Übergangslösung genommen - diese läuft unauffällig. In einigen Punkten fehlt mir OPNsense schon, gleichzeitig hatte ich einfach nicht mehr die Zeit fürs Troubleshooting.
Vielleicht haben andere ja noch neue Erkenntnisse dazugewonnen?

Viele Grüße

[tiermutter]

Ich habe bei mir (DG, Sense direkt am ONT) seit geraumer Zeit keine Probleme mehr.
Anfangs hatte es nach einem Reboot, etc. mal einige Minuten gedauert, bis ich wieder v6 Adressen hatte, mittlerweile (seit etwa 2022?) ist sofort alles da. Mein Präfix ändert sich allerdings auch nie (ist aber auch nicht statisch)...

[august]

Nun melde ich mich heute wieder, weil dieses Scheiß-Problem nun wieder aufgetreten ist und ich nach mehr als einem Monat schon vergessen habe, welche von den vielen Handlungen mich damals doch dazu gebracht hat, dass es nun wieder lief.
Was war nun heute passiert. Ich habe heute ein größeres msata-SSD-Speicher in mein APU4D4 (das ist die Hardware von OPNsense) installiert. Denn die empfohlenen 16GB (wer auch immer diese Empfehlungen immer macht) natürlich relativ knapp bemessen waren. Update erfolgte so, dass ich alle Einstellungen von OPNsense gesichert habe und dann mein APU4D4 auf dem neuen msata-SSD-Speicher neu aufgesetzt habe. Anschließend zurückspielen aller Einstellungen und da war es wieder "No available address range for configured interface subnet size." unter allen Services->ISC DHCPv6->LAN (und anderen) zu vermelden.
Alles Erdenkliche danach ausprobiert: De Fritz!Box, die als DSL-Gateway dient neu gestartet, OPNSense neu gestartet. Netzwerkkabel am WAN getrennt und nach einer Weile wieder eingesteckt (müsste normalerweise zur Deaktivierung des WAN-Interfaces und dann wieder zum Hochfahren dessen führen) usw. Und? Nichts da! Fehler bleibt bestehen!
Ich denke langsam, dass OPNsense immer noch einen Wurm in der Logik der Detetkierungs-Skripten für Tracking hat! Auch wie letztes Mal, wo ich die Fritz!Box an DSL getauscht hatte war diesmal keine Handlung, die jeden Tag auftritt. Bloß, das Umstellen aller Interfaces wieder auf was anderes als Tracking und dann wieder alles von vorne manuell Einrichten, was überall als einzig mögliche "Heilung" berichtet wird ist doch auch keine Lösung!
Ich wäre bereit es zu debuggen, bloß was und wo genau soll ich nachschauen. Damals hatte es mich auch schon einen halben Tag gekostet, in den Tiefen den Einstellungen rumzufummeln. Heute läuft es auf das Gleiche aus!
Meine Persönliche Vermutung: Die Logik in den Detektierungsskripten zur Erneuerung der deligierten IPV6-Adresse bei OPNsense ist buggy. In bestimmten Fällen, die ich leider nicht näher eingrenzen kann, führt dies dazu, dass die Adresse nicht erneuert wird. Ich hatte da in irgendwelchen Logs schon letztes Mal gesehen, dass da eine lokale "fe80"-Adresse entweder als "alte" oder als "neue" oder als beides auftauchte. Dass eine lokale "fe80"-Adresse sich nicht ändert ist ja logisch und führt meines Erachtens dazu, dass dort keine Änderung detektiert wird. Vermutlich gerät die Detektierung außer tritt und verfällt in diesem "fe80"-Modus, wenn man beim bereits vollständig eingerichteten OPNsense was ändert, wie beispielweise die Fritz!Box am DSL-Anschluss oder neu aufsetzen vom System. In dem Falle werden irgendwelche Initialisierungsoperationen vermutlich weg gelassen (durch die fehlerhafte Logik), die normalerweise beim Neueinrichten der Tracking-Interfaces durchgeführt werden. Und schon hat man den Salat, von dem sehr viele berichten. Das würde die "Heilung" durch das Reseten all der getrackten Interfaces auf was anderes als Tracking und dann das manuelle Neueinrichten erklären.
Wie gesagt, ich würde es gerne debuggen, bloß wo sind all diese Skripte, dass man die zunächst mal zumindest reviewen kann?

Edit: Eine neue Erkenntnis nach mehreren Stunden des Rumprobierens: Bei mir wird einer der deligierten Präfixen im /58-Subnetz von der Fritz!Box angezeigt, die als DSL-Gateway dient. Bis jetzt habe ich dann bei OPNsense die "Prefix delegation size" auf 57 (also n-1) eingestellt, weil es in allen möglichen Anleitungen so beschrieben war, damit man diese "Delegation" per Tracking auf mehrere lokalen SubNetze aufteilen kann. Als 0x1, 0x2 usw. Nun habe ich aus lauter Verzweiflung (weil es mir schon wirklich nichts mehr blieb) 58 anstelle von 57 eingestellt (also nicht n-1, sondern n) und siehe da: alles hat sich wieder "repariert".
Ich glaube aber nicht, dass es wirklich die Lösung ist, sondern tippe auf irgendwelche Nebeneffekte. Denn mit "n-1" hat für mich in all den Anleitungen als logisch angehört. Warum es jetzt mit "n" als dieselbe Präfixlänge, wie bei der Fritz!Box funktioniert, ist mir ein Rätsel. Ich beobachte es weiter.

[JeGr]

> Edit: Eine neue Erkenntnis nach mehreren Stunden des Rumprobierens: Bei mir wird einer der deligierten Präfixen im /58-Subnetz von der Fritz!Box angezeigt, die als DSL-Gateway dient. Bis jetzt habe ich dann bei OPNsense die "Prefix delegation size" auf 57 (also n-1) eingestellt,

Könntest du das ggf. nochmals erläutern was da wo stand? Für mich liest sich das nach "in der Fritzbox steht ich habe ein /58er Prefix" und du hast dann ein /57 delegiert - was dann natürlich Unfug ist, denn du kannst kein größeres Netz delegieren als dir zugeteilt wurde. Vielleicht verstehe ich dich falsch herum. Oder dein Provider hat die Delegation von /56 (was eigentlich normal für Endkunden sein sollte) auf /58 verkleinert um Adressen zu sparen (was kompletter BS ist) und deshalb hat die Zuweisung nicht mehr hingehauen?

Wie gesagt eine Vermutung weil ich den Absatz nicht 100%ig verstehe, aber wenn es so sein sollte wie ich es lese, ist es völlig klar, warum es kaputt gegangen ist, da du ein zu großes Netzsegment angefordert hast (/57) und die Fritte dir nur ein /58 zur Verfügung stellen konnte und daher die Anfrage abgelehnt hat. Normalerweise war es bei AVM meistens so, dass die Fritte nicht mehr als /58 /59 oder /60 delegieren konnte, evtl. ging auch mal /57. Das komplette /56er ging oftmals nicht, deshalb ist es meistens n+1 oder n+2 gewesen. Aber n-1 wäre mir neu.

Cheers :)

[august]

Ich bin z.B. nach der Anleitung https://docs.opnsense.org/manual/how-tos/ipv6_fb.html vorgegangen. Ich glaube, es gab noch 2-3 weitere die ich gelesen hatte und die in eine ähnliche Richtung gehen. "n-1" meine ich in einer diesen Anleitungen so gesehen zu haben, aber definitiv nicht in der zitierten hier. Und wenn ich jetzt die zitierte Anleitung zum fünften Mal durchlese und genau auf diese "n+1" vs "n-1" Thematik achte, dann gebe ich dir Recht, dass dort "n+1" und nicht "n-1" gemeint ist. Aber eindeutig beschrieben und sofort zu verstehen ist es da in der Anleitung auf jeden Fall für mich nicht und daher sehr verwirrend. Insbesondere der Satz "In this example the FB gave us aaaa:bbbb:cccc:9410::/60", also "die Box gab uns /60" gab mir die falsche Botschaft: "wenn in der Box /60 steht, stell in der OPNsense /59", weil ja in der Anleitung IMMER und IMMER wieder zwischen diesem 59 und 60 gekaut wird, ohne eindeutig zu sagen "n+1" oder "n-1". Zweites Beispiel aus der Anleitung: "the requested prefix differs by one bit compared to what the ISP delegated the FB (60 vs. 59)". Liest für mich auch beim durchfliegen in DER REIHENFOLGE IN DEM SATZ so: "Der Provider gibt dir 60, dann stell 59 ein". Ja, ich gebe es zu, man muss es genau und vermutlich 5 Mal lesen. Ist vermutlich so was Ähnliches wie doppelte Verneinung im Deutschen. Aber sei es rum. Lass uns mal in den konkreten Beispielen reden:
Der Provider gibt mir /58. Das sehe ich in der Fritz!Box unter "Heimnetz->Netzwerk->IPv6-Adressen" als deligierte Adresse:

Code Select Expand

Verwendete IPv6 Präfixe:
Heimnetz 2a01:XXX:YYYY:1::/64
Gastnetz 2a01:XXX:YYYY:2::/64
WAN 2a01:XXX:YYYY::/64
Delegiert 2a01:XXX:YYYY:c0::/58
Delegiert 2a01:XXX:YYYY:bc::/62
Es gibt dort noch eine weitere /62-Delegation, ich nutze aber die /58
Da ich es falsch mit n-1 verstanden hatte, stand bei mir unter OPNsense WAN als "Prefix delegation size" bis vor kurzem /57 eingestellt. Die Frage ist: Warum hat es dann trotzdem sporadisch funktioniert?
Nun steht bei mir jetzt unter OPNsense /58 und nicht mehr /57 und es scheint (warum auch immer) so zu gehen. Also n_OPNsense = n_FB.
Soll ich jetzt doch auf "n+1" umstellen, dass n_OPNsense = n_FB +1 ist? Also auf 59 in OPNsense, wenn mein Provider mir 58 (gesehen in der Fritz!Box) gibt?
Danke!

[citydweller]

Hi zusammen, mit der aktuellen Version OPNsense 24.1.6-amd64 besteht das ursprünglich beschriebene Problem nach wie vor. Gibt es derzeit irgendwelche Workarounds?

[Cyberturtle]

An Workarounds wäre ich ebenfalls interessiert. Ich verwende aus diesem Grund seit vergangenen Sommer OPNsense nicht mehr, da meine Leitung halt gerne mal von ASSIA optimiert wird und es dann nachts zu einem Reconnect kommt. Für mich war da die Verlässlichkeit für mein VPN nicht mehr gegeben und ich hatte leider keine Zeit mehr für weitere Tests, wenngleich hier ja so einige Versionen mit Verbesserungen im Bereich IPv6 veröffentlicht wurden.
Ich frage mich wirklich, wie AVM das bspw. löst. Soweit ich mich erinnere, ging es auch mit pfSense Plus, allerdings gibt es das nicht mehr für den privaten Gebrauch und ich mag auch eher OPNsense unterstützen.  :)
Könnte man nicht einfach nach einem PPPoE-Reconnect das Neustarten des IPv6-Interfaces triggern?

[august]

Meine oben gemeldeten Probleme lagen tatsächlich an der Missverständnis bzgl. Präfix-Delegation zwischen der Fritz!Box und der Opnsense bzw. besser gesagt dieser n+1 vs. n-1, je nachdem, wie man die Doku ließt und sie versteht. Seit März habe ich keine Probleme mehr. Die äußere IPV6-Adresse hat sich seither bereits ein Paar geändert, auch einige Updates von Opnsense mit entsprechenden Reboots von Opnsense habe ich auch bereits getätigt. Scheint alles stabil zu laufen.