Messages

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.

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!

[Edit:]

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.

Naja, AVM ist da selbst schuld, wenn sie sich so eine "box" TLD ausdenken und nicht dafür sorgen, dass die irgendwann mal reell in der Welt existieren könnte. Wobei zu den Zeiten, als sie es ausgedacht hatten (so um 2005, würde ich mal grob schätzen, seit 2006 bin ich selbst dabei), war das Internet noch ganz klein und nicht so böse.

Aber Scherz beiseite. Mir fallen da spontan mehrere Tipps und Lösungen ein, die ich bei mir intensiv und seit Jahren nutze:

1. Wer bei sich 8.8.8.8 als ersten DNS einträgt ist selbst schuld. Vor allem, wenn er das bei den Clients tut. Man sollte hier bitte nicht an der Hierarchie vorbei gehen: OPNsense -> FritzBox -> InternetProvider -> 8.8.8.8. Genau so tut es auch AVM. Sprich, so ein 0815-User wird dieses Problem nicht haben, weil der lokale DNS-Server der FritzBox die Adresse "fritz.box" sauber zu 192.168.178.1 auflöst (ich spreche hier von einem 0815-Fall) und gar nicht draußen danach fragt. So muss man es auch immer implementieren.

2. AVM hat in den Boxen schon seit Jahren eine Möglichkeit geschaffen, den Namen der Box zu ändern. Das würde ich echt immer empfehlen zu tun und "fritz.box" ganz vergessen. Spätestens wenn man mehrere Boxen im lokalen Netz hat, funktioniert es mit der "fritz.box" nicht mehr. Achtung! Unglücklicherweise ändern sich nach der Umbenennung der Box sämtliche WLAN-Namen und sonstige Sachen. Das hat AVM sehr unglücklich gemacht, aber wiederum vermutlich für so einen 0815-User, der es als logisch empfinden würde. Ich nicht. Das ist aber eine andere Geschichte.

3. Man kann ja auch FREETZ-NG mit dnsmasq nutzen. Da verlassen wir zwar die besagte bequeme 0815-Zone, aber ist für Fortgeschrittene unter uns ja grundsätzlich möglich. Oder von mir aus "den fremden DNS-Server" nutzen, was viele mit so einem PiHole sowieso tun, vermutlich ohne es zu wissen. Quasi DNS-Anfragen nicht von der Box auflösen lassen, sondern zum RPI weiterleiten und dort durch PiHole filtern lassen. Und was hat PiHole als Grundgerüst? Richtig! dnsmasq. Bei dnsmasq gibt es Tausende Möglichkeiten, "fritz.box" im lokalen Netz zu belassen oder z.B. mehrere Aliase der gleichen IP der beliebten Box von Anfang an per "hosts" zu verleien. Und, und, und.

4. Nun landen wir bei OPNsense. Und was sehen wir? Auch OPNsense bietet sehr viele Möglichkeiten, das besagte Problem zu lösen. Zu einem dnsmasq (s. Punkt 3). Wer dnsmasq als DNS-Server nutzt, kann sich darin austoben. Aber auch Unbound DNS bietet solche Möglichkeiten. Alleine "Overrides" fallen mir spontan ein: fritz.box auf die (von mir aus) 192.168.178.1 matchen und fertig ist es. Schon löst OPNsense es auch richtig auf.

Die Punkte 3 und 4 gehen natürlich von einer entsprechend richtig hierarchisch konfigurierter DNS-Kette aus. Wenn jemand wieder mal in den Clients 8.8.8.8 als DNS-Server an dem Router und dem Provider vorbei einträgt, dem ist sowieso nicht zu helfen. Der ist selbst schuld (s. Punkt 1).

Gruß

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!