RDNNS Problem

[patient0]

Das ist doch so lange irrelevant, wie die UI Einstellungen für RADVD nicht in /var/etc/radvd.conf ankommen, denn das müssten sie zuerst.

Grundsätzlich hast Du recht, aber wir wissen noch nichts. Vielleicht ist RADVD gar nicht aktiviert auf dem Interface, oder er schaut auf dem falschen Interface, oder oder oder.

[mik_schreiber]

Das ist doch so lange irrelevant, wie die UI Einstellungen für RADVD nicht in /var/etc/radvd.conf ankommen,

Ich verstehe schon nicht, was Du mit "hook" meinst.

Genau das ist irrelevant, wenn es nicht in der conf steht. Die radvd.conf wird allerdings dynamisch konfiguriert - also jede Änderung überschreibt sie, jeder Neustart überschreibt sie.


was ich mit Hook meine? Es gibt /usr/local/etc/rc.syshook.d/
Dort habe ich ein script welches die radvd ändern soll. Leider funktioniert das auch nicht zuverlässig, weil ich nicht weiss unter welchen Bedingungen  das script dort aufgerufen wird.

du bist sicher, dass bei dir die ULA und nicht die GUA als RDNSS steht? Das Problem der GUA ist ja, dass sich das Präfix vom Provider ändert. Das ist der Grund wieso ich die ULA möchte, die ja auch basis der Mac adr erzeugt wird und unique bleibt.

[mik_schreiber]

Vielleicht ist RADVD gar nicht aktiviert auf dem Interface, oder er schaut auf dem falschen Interface, oder oder oder.

Ist doch eigentlich von meiner Beschreibung klar. Ich möchte AdGuard Server als IPv6 DNS verteilen. Also muss es LAN sein.
Da ich geschrieben hatte, dass die Verteilung funktioniert wenn ich die ULA manuell in die config schreibe, funktioniert es prinzipiell.
Es gäbe rein theoretisch zwei mögliche Fehler
1.) man drückt speichern und dann kein Anwenden (habe ich natürlich gemacht)
2.) das checkmark aktiv ist nicht gesetzt (ist aber gesetzt)

habe es gerade mit Safari, Chrome und Apple OS und Edge mit Windows versucht (Browser habe keine besonderen Extensions - Browser fällt somit auch flach.)

Es wird nicht wie in der UI angegeben die ULA reingeschrieben sondern es steht die GUA drinnen.

[meyergru]

Hast Du mal den Hook weggenommen? Wenn der fehlschlägt, könnte es sein, dass nichts weiter passiert.

Ja, ich habe es mit einer ULA getestet. Ich habe sowieso dynamische GUAs, weshalb das nicht funktionieren würde. Wenn überhaupt, schreibe ich dort eine LL Adresse rein, normalerweise nutze ich dazu fe80::1, was ich als VIP auf jedem (V)LAN Interface eintrage.

Tatsächlich nutze ich das Feature normalerweise aber nicht, weil ein DNSv6-Server komplett überflüssig ist - außer, man nutzt IPv6-only. Siehe hier.

Dann würde ich an Deiner Stelle nochmal einen Health Audit machen.

[Monviech (Cedrik)]

Die docs beschreiben dass die RDNSS option automatisch von der primary IP addresse des sendenden interfaces generiert wird. Das ist völlig dynamisch. Es ist also egal wenn der Provider die manchmal ändert, weil es dynamisch generiert wird.

https://docs.opnsense.org/manual/radvd.html#configuration-examples

(Zur info ich hab die docs geschrieben und bei radvd bei der mvc migration mitgemacht. Bitte auf github issue öffnen wenn etwas reproduzierbar nicht funktioniert, wie schon früher aufgezeigt)

[meyergru]

Wie gesagt, ich hatte definitiv eine ULA (fd00::1) verwendet und das ging.

Mir ist klar, dass der Default ist, dass die Interface-Adresse verwendet wird. Hier ging es ja darum, dort explizit etwas hinzuschreiben, was dann so in der /var/etc/radvd.conf auftaucht - und das tut es bei mir. Es hätte keinen Sinn, eine ULA dort direkt einzutragen, wenn diese dynamisch ist. Man sollte das Feld dann leer lassen oder - wenn man keine ULA verwenden möchte, den fe80::1 Trick verwenden (den nutze ich auch für die Default-Route, wenn ich statisch konfigurieren will).

Wobei mich Dein Hinweis ins Grübeln gebracht hat, Cedrik. Eine kleine Schwäche gibt es dort auf jeden Fall:

Man kann dort z.B. "::88:99" eintragen - erwarten würde ich dann den Interface-Präfix plus diesen Suffix, ähnlich wie beim Default. Tatsächlich wird allerdings diese partielle IPv6 1:1 in /var/etc/radvd.conf eingetragen.

[mik_schreiber]

Die docs beschreiben dass die RDNSS option automatisch von der primary IP addresse des sendenden interfaces generiert wird. Das ist völlig dynamisch. Es ist also egal wenn der Provider die manchmal ändert, weil es dynamisch generiert wird.

Klar Github

in der doc steht:
The default is to use this interface IP address with an enabled DNS service or the configured global DNS servers. You may specify up to three explicit servers here instead.

ich will eigenen expliziten DNS Server angeben. Die ULA adr weil der AdGuard nur beim Start die IP liest. Wenn sich die im laufenden Betrieb ändert, würde das AdGuard das nicht mitbekommen. Aber genau die angegebene ULA steht im UI (einer der drei explicite servers) wird aber in der radvd.conf nicht generiert. Da bei unbound ähnliches Problem auftritt - also auch Weiterleitung auf ULA die nicht in der config landet, sehe ich da Analogie.
Ich merkte es weil AdGuard schlecht filterte und habe dann die configs angeschaut. Sonst wäre das nicht aufgefallen.

jetzt habe ich es mit dem hook gelöst - und wenn ich es mit nohup start funktioniert es auch

sed -i '' 's/RDNSS [^{]*/RDNSS fd5b:xxxx:xxxx:0:xxxx:xxxx:xxxx:xxxx /' /var/etc/radvd.conf" >> /usr/local/etc/rc.syshook.d/50-radvd-ula.sh
killall radvd 2>/dev/null; sleep 1; rm -f /var/run/radvd.pid' >> /usr/local/etc/rc.syshook.d/50-radvd-ula.sh
nohup radvd -n -d1 -p /var/run/radvd.pid -C /var/etc/radvd.conf > /var/log/radvd.log 2>&1 &' >> /usr/local/etc/rc.syshook.d/50-radvd-ula.sh


@Meyergru den hook hatte "versehentlich weggelassen" weil MacBook in Standby ging und die terminal session und somit der hook beendet wurde weil es als daemin nicht läuft. Funktionierte kurz darauf wieder nicht. Hätte es direkt in der Konsole machen können oder eben mit nohup. Health bei "Berichterstattung" habe ich mir angesehen oder was meintest du mit health überprüfen?

/Edit - habe gerade von 26.1.3 auf 26.1.4 upgedated. und das Problem das unbound Weiterleitungen nicht schreibt ist weg. Beim update wurde meine manuelle include indie dot.cfg übernommen. Habe gleich getestet und jetzt werden die unbound Weiterleitungen ganz sauber übernommen. Das Problem iunbound ist nach dem Update weg

[Monviech (Cedrik)]

@Meyergru

Könnte man validieren um die eingabe zu verhindern, if string starts with ::. Mach ich bei dnsmasq ein paar mal. Bitte issue oder PR damit man das diskutieren kann.

@mik_schreiber

Es fühlt sich so an als ob hier zuviel in der shell rumgespielt wurde, und die genauen Schritte zur reproduzierung fehlen immer noch. Ich halte mich hier jetzt raus bis es wirklich actionable info gibt.

EDIT: Okay gibt eine issue, danke. https://github.com/opnsense/core/issues/9967

[meyergru]

Für die Validierung: https://github.com/opnsense/core/issues/9971

[mik_schreiber]

@mik_schreiber

Es fühlt sich so an als ob hier zuviel in der shell rumgespielt wurde, und die genauen Schritte zur reproduzierung fehlen immer noch. Ich halte mich hier jetzt raus bis es wirklich actionable info gibt.

EDIT: Okay gibt eine issue, danke. https://github.com/opnsense/core/issues/9967

In der shell wir nur der RDNSS Eintrag auf die ULA geändert. Da die radvd.conf dynamisch erstellt wird, geht es nicht mit einer einmaligen Änderung. Aber wenn man das script umbenennt, ist man wieder auf original Zustand (Github neue Meldung ist original Zustand)

In Github das ganze mit deaktivierten hook. ULA in der UI eingetragen --> ULA steht richtig in der XML --> in der radvd.conf steht aber GUA --> Fehlerlog zeigte (meiner Meinung nach) "OPNsense denkt ... alles richtig gemacht"

/edit Danke für die Hilfe in Github. Aber wie soll man da drauf kommen, dass Eingaben im RDNSS Feld im Modus  Track Interface ignoriert werden?
Wenn man Quellcode kennt, dann sieht man es - aber für einen Anwender ist das schwierig. Aber es war nicht "rumspielen" :-)

[mik_schreiber]

Wie gesagt, ich hatte definitiv eine ULA (fd00::1) verwendet und das ging.

Hier ging es ja darum, dort explizit etwas hinzuschreiben, was dann so in der /var/etc/radvd.conf auftaucht - und das tut es bei mir. Man sollte das Feld dann leer lassen oder - wenn man keine ULA verwenden möchte, den fe80::1 Trick verwenden (den nutze ich auch für die Default-Route, wenn ich statisch konfigurieren will).

Hat sich inzwischen geklärt - wenn Track Interface eingestellt ist, dann wird anscheinend eine Eingabe bei RDNSS ignoriert.
Aber mal ehrlich, wenn man seit ein paar Tagen bei OPNsense ist - wie soll man das wissen? Logisch ist es auch nicht, wenn die Eingabe erlaub aber dann nicht ausgeführt wird. So wie es aussieht wussten das selbst die Profis nicht auf Anhieb.

Da gibt es noch mehr Stellen - z.B MSS Eingabe die dann einen Wert berechnet der anders als die Eingabe ist.

[Patrick M. Hausen]

Hattest du denn die RAs auf "manuell" gestellt - da ist auch irgendwo noch so ein Schalter.

Ich gebe dir prinzipiell recht, ich mag die ganze "Magie", wie ich das normalerweise nenne, überhaupt nicht. Aber was will man machen, mit Providern, die 2026 "dynamische Prefixe" raus geben? Laut RIPE sollte jede "residential line" also vom Privatkunden bis zum kleinen Büro einfach ein statisches /48 bekommen und aus.

Deshalb habe ich überall Business-Anschlüsse, sonst fasse ich den Mist nicht an. Dann kann man alle internen Interfaces statisch konfigurieren und es funktioniert einfach immer.

Im Grunde ist IPv6 ja *einfacher* zu konfigurieren als IPv4. Wie Clemens Schrimpe immer sagte:

"Wie macht man IPv6?"

"An!"


Nur so 'n paar Gedanken. Tickets zur Verbesserung der Doku sind sicher willkommen, aus den Providern kriegt man den Kram nur mit dem Geldbeutel rausgeprügelt. Alles außer Telekom Business kommt hier üblicherweise nicht uns Büro.