OPNsense Forum

International Forums => German - Deutsch => Topic started by: mik_schreiber on March 14, 2026, 01:15:00 PM

Title: RDNNS Problem
Post by: mik_schreiber on March 14, 2026, 01:15:00 PM
Wieso übernimmt OPNsense den RDNSS nicht aus der GUI?

Wenn ich als RDNNS eine ULA eintrage, dann steht die zwar in der config, würd aber nicht in das automatisch konfigurierte file übernommen.

Habe dann über hook den RDNNS manuell reingeschrieben und das funktioniert auch solange man den Service manuell startet. Starte ich das als daemon, ist RDNNS wieder weg

Irgendeine Idee wie man das lösen kann? Ist das ein BUG weil die GUI übernimmt es aber schreibt es nicht in config?
Title: Re: RDNNS Problem
Post by: Patrick M. Hausen on March 14, 2026, 01:53:19 PM
Was ist RDNNS?
Title: Re: RDNNS Problem
Post by: Maurice on March 14, 2026, 01:53:31 PM
Geht es um RDNSS in radvd?

Grüße
Maurice
Title: Re: RDNNS Problem
Post by: mik_schreiber on March 14, 2026, 05:31:52 PM
Ja es geht um radvd

habe gerade noch so ein ähnliches Problem - wollte bei unbound dns an einen adgurd Rechner weiterschicken. Im UI eingetragen aber der forwarder wurde nicht in die config geschrieben. Da in der config ein include drinnen steht, habe ich eine include Datei erstellt und es funktioniert. Aber wieso wird die Einstellung aus der UI nicht übernommen? -- PS: ich habe anwenden gedrückt und service neu gestartet
Title: Re: RDNNS Problem
Post by: mik_schreiber on March 14, 2026, 05:48:53 PM
Quote from: Patrick M. Hausen on March 14, 2026, 01:53:19 PMWas ist RDNNS?

RDNSS ist DNS Server über IPv6 verteilen.
Wenn bei IPv6 Router Advertisements geschickt werden, dann soll der IPv6 DNS vom AdGuard mitgeschickt werden damit auch bei IPv6 gefiltert wird.

Technisch habe ich es zum laufen bekommen, aber die config nach jeder UI Änderung oder Neustart per hook zu ändern ist nicht schön.
Bug in der UI übernahme?
Title: Re: RDNNS Problem
Post by: Monviech (Cedrik) on March 14, 2026, 05:56:47 PM
Das war falsch geschrieben, das wurde angemerkt.

https://datatracker.ietf.org/doc/html/rfc8106#section-3

RDNSS nach RFC8106

Wenn was in der GUI nicht bitte auf github eine issue mit genauen anweisungen zum reproduzieren:
https://github.com/opnsense/core/issues

Title: Re: RDNNS Problem
Post by: Patrick M. Hausen on March 14, 2026, 05:58:16 PM
Das heißt RDNSS. RDNNS hat auch die Suchmschine nicht gefunden, deshalb hatte ich gefragt, was du meinst.
Title: Re: RDNNS Problem
Post by: Maurice on March 14, 2026, 06:36:17 PM
Das ist bei mir genau so konfiguriert. Bei Services: Router Advertisements unter Recursive DNS Servers (RDNSS) steht eine ULA. Funktioniert einwandfrei.

Da bei dir zudem mehrere Dienste betroffen sind scheint das eher ein individuelles und übergreifendes Problem zu sein. Eher nichts was spezifisch etwas mit radvd zu tun hat.

Grüße
Maurice
Title: Re: RDNNS Problem
Post by: patient0 on March 14, 2026, 07:16:43 PM
Quote from: mik_schreiber on March 14, 2026, 05:48:53 PMTechnisch habe ich es zum laufen bekommen, aber die config nach jeder UI Änderung oder Neustart per hook zu ändern ist nicht schön.
Bug in der UI übernahme?
Welche Version von OPNsense setzt Du ein? Und ist Dnsmasq deaktivert? Für welches Interface konfigurierst Du RA/RDNSS? In welchem Mode benutzt Du RA, unmanaged, assisted, ...?
Title: Re: RDNSS Problem
Post by: mik_schreiber on March 14, 2026, 07:21:30 PM
Quote from: Maurice on March 14, 2026, 06:36:17 PMDas ist bei mir genau so konfiguriert.

eher ein individuelles und übergreifendes Problem zu sein


Der Hinweis "übergreifend" hat mich auf anderen Gedanken gebracht. Euere OPNsense laufen schon länger, haben updates bekommen.

Evtl tritt es nur bei neu installierten Systemen auf? Der Fehler ist ja, dass Änderungen aus dem UI nicht übernommen werden.
Wenn man es auf andere Weise konfiguriert (mit mehr oder weniger Aufwand), dann funktioniert es technisch.

Nur wo könnte ich suchen?
Title: Re: RDNNS Problem
Post by: meyergru on March 14, 2026, 07:40:20 PM
Das ist sehr unwahrscheinlich, da die Pakete die ursprünglichen Dateien komplett überschreiben. Bei mir funktioniert das übrigens auch einwandfrei, wenn ich an der UI etwas ändere, landet es auch in /var/etc/radvd.conf.

Ich kann mir nur zwei Ursachen vorstellen:

1. Deine Installation ist nicht komplett beendet worden - Du kannst ja mal ein Health Audit machen.
2. Dein Browser oder eine Erweiterung blockieren irgendwas - Erweiterungen auf der OpnSense-Seite deaktivieren oder anderen Browser nehmen.
Title: Re: RDNSS Problem
Post by: mik_schreiber on March 14, 2026, 07:51:07 PM
Quote from: patient0 on March 14, 2026, 07:16:43 PMIn welchem Mode benutzt Du RA, unmanaged, assisted, ...?

Habe unmanged und assisted versucht. Das Problem ist, dass die Änderung vom UI nicht in die radvd geschrieben wird.
schreibt man es manuell in die config, dann funktioniert es. Die radvd wird aber dynamisch erzeugt und kann deshalb nur über book manuell geändert werden. Dann kommt noch dazu, dass ich es dann nur im Vordergrund und nicht als daemon starten kann.

Aber wenn ich patche, dann bekommt z.B iPhone oder MacBook brav die IPv6 DNS

Versionen
OPNsense 26.1.3-amd64
FreeBSD 14.3-RELEASE-p9
OpenSSL 3.0.19

Title: Re: RDNNS Problem
Post by: meyergru on March 14, 2026, 07:58:12 PM
Ich verstehe schon nicht, was Du mit "hook" meinst.

Die einzige Variante, wie ich es hinbekomme, dass die Einträge NICHT in die /var/etc/radvd.conf geschrieben werden, ist, dass ich die "Enable DNS" checkbox nicht anhake...
Title: Re: RDNNS Problem
Post by: patient0 on March 14, 2026, 08:08:35 PM
Quote from: mik_schreiber on March 14, 2026, 07:51:07 PM... Das Problem ist, dass die Änderung vom UI nicht in die radvd geschrieben wird.
schreibt man es manuell in die config, dann funktioniert es.
Ja klar, das hast Du ja schon geschrieben. Dnsmasq kann auch RA: ist also Dnsmasq ausgeschaltet?

Ich bin auch auf der Version 26.1.3 und es funktioniert, es geht also darum festzustellen wo in der Deiner Konfiguration der Wurm drin ist. Zeig doch etwas wie es konfiguriert ist, welches Interface, wissen wir alles nicht bisher. Funkitioniert SLAAC, bekommen die Clients IPs, kannst Du IPv6 Ziele pingen von den Clients aus?
Title: Re: RDNNS Problem
Post by: meyergru on March 14, 2026, 08:11:01 PM
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.
Title: Re: RDNNS Problem
Post by: patient0 on March 14, 2026, 08:32:33 PM
Quote from: meyergru on March 14, 2026, 08:11:01 PMDas 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.
Title: Re: RDNSS Problem
Post by: mik_schreiber on March 14, 2026, 08:34:10 PM
Quote from: meyergru on March 14, 2026, 07:58:12 PMDas 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.
Title: Re: RDNNS Problem
Post by: mik_schreiber on March 14, 2026, 08:53:56 PM
Quote from: patient0 on March 14, 2026, 08:32:33 PMVielleicht 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.
Title: Re: RDNNS Problem
Post by: meyergru on March 14, 2026, 09:26:19 PM
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 (https://forum.opnsense.org/index.php?topic=45822.0).

Dann würde ich an Deiner Stelle nochmal einen Health Audit machen.
Title: Re: RDNNS Problem
Post by: Monviech (Cedrik) on March 14, 2026, 09:35:55 PM
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)
Title: Re: RDNNS Problem
Post by: meyergru on March 14, 2026, 10:25:15 PM
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.
Title: Re: RDNNS Problem
Post by: mik_schreiber on March 14, 2026, 10:59:56 PM
Quote from: Monviech (Cedrik) on March 14, 2026, 09:35:55 PMDie 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
Title: Re: RDNNS Problem
Post by: Monviech (Cedrik) on March 15, 2026, 06:33:43 AM
@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
Title: Re: RDNNS Problem
Post by: meyergru on March 15, 2026, 09:44:01 AM
Für die Validierung: https://github.com/opnsense/core/issues/9971
Title: Re: RDNNS Problem
Post by: mik_schreiber on March 15, 2026, 11:51:34 AM
Quote from: Monviech (Cedrik) on March 15, 2026, 06:33:43 AM@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" :-)
Title: Re: RDNNS Problem
Post by: mik_schreiber on March 15, 2026, 10:34:33 PM
Quote from: meyergru on March 14, 2026, 10:25:15 PMWie 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.
Title: Re: RDNNS Problem
Post by: Patrick M. Hausen on March 15, 2026, 10:52:10 PM
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.
Title: Re: RDNNS Problem
Post by: Maurice on March 15, 2026, 11:07:44 PM
"Track Interface" ist legacy. Stattdessen sollte "Identity Association" verwendet werden.

Grüße
Maurice


@Patrick Telekom Business = viel Geld für schlechtes Peering, oder?
Title: Re: RDNNS Problem
Post by: Patrick M. Hausen on March 15, 2026, 11:17:07 PM
Quote from: Maurice on March 15, 2026, 11:07:44 PM@Patrick Telekom Business = viel Geld für schlechtes Peering, oder?

Berechtigte Frage angesichts der Historie aber ich habe mit

- 100 Mbit/s DSL zuhause nie
- 1 Gbit/s Glas im Büro während der üblichen Bürozeiten

irgendwelche Probleme. Also beide Uplink-Geschwindigkeiten scheitern dann nicht irgendwo weiter oben am Peering.

Und die Leitungen sind alle einfach 99% und mehr stabil. Nicht ein Ausfall in Monaten. Plus feste Adressen (/32 plus /56), damit die Möglichkeit, VPNs
einfach ordentlich einzurichten, Monitoring, Remote-Access ... you name it.

Hatte einen kleinen Kunden, Ingenieurbüro der altmodischen Sorte, die hatten mal eine 2 Mbit/s "Standleitung" von uns mit unseren IP-Adressen. Irgendwann dann Telekom-DSL, aber IP weiter von uns über L2TP/ISP-Gate. Dann haben sie den Laden abgesperrt, ganz regulär, Rente ohne Nachfolger und so, wollten aber Kunden noch ein paar Jahre weiter betreuen. Haken daran: das /29 von uns, das brauchten sie unbedingt.

Also hab ich gesagt "kauft euch dieses Device von Deciso, kauft euch bei dem Kollegen, in dessen Keller das Geraffel weiter läuft, eine Telekom Business Leitung, den Rest mach ich dann". WireGuard Tunnel in unser AS, IP von uns, Thema durch.

Man kann ja meckern, aber bei der DTAG funktioniert tatsächlich für mich immer alles.