Hey Zusammen,
ich habe einen Glasfaseranschluss bei der Telekom und nutze IPv6. Bei den WAN Einstellungen habe ich folgendes: wan.png
Ich habe noch die MTU angepasst etc. und bisher läuft alles. Ich habe noch als Fallback einen IPv4 DHCP und dort ist auch mein AdGuard als DNS Server eingetragen. Leider kriege ich es nicht hin, diesen auch bei den IPv6 zu konfigurieren, sodass meine Clients diese nicht nutzen.
Wie kriege ich das hin?
Danke für die Hilfe :-)
Moin,
schaue mal hier (https://docs.opnsense.org/manual/radvd.html) rein. In IPv6 werden DNS Server entweder auch über dhcpv6 oder bei slaac über routing advertisements verteilt. Die wan Konfiguration ist übrigens relativ egal, wichtig ist wie es auf den internen Schnittstellen konfiguriert ist
Alternativ, solltest Du dnsmasq für dhcpv6 konfiguriert haben, must Du in der Konfiguration von dnsmasq ra einschalten, in den Optionen von dnsmasq eine DHCPv6 Option dns-server mit der IP Adresse des adguard Servers eintragen und in den Services radvd deaktivieren....
Gruß
Danke für den Hinweis. Habe die Einstellung gefunden. Der DNS Server ist in einem anderen Netz/Interface, wo auch meine anderen Server über IPv4 zu erreichen sind. Beim RA muss ich natürlich eine IPv6 Adresse angeben. Jetzt muss ich schauen, was die beste Lösung ist. Aktuell fallen mir drei Optionen ein:
1. AdGuard im ADMIN Netzwerk zur IPv4 auch eine IPv6 vergeben
2. AdGuard ins LAN Netzwerk verschieben
3. ADMIN Netzwerk auf IPv6 umstellen
Die Liste ist priorisiert und ich muss mal schauen, wie ich AdGuard im IPv4 ADMIN Netz eine zusätzliche IPv6 Adresse geben, damit ich diese dann im RA eintragen kann. Meine Annahme ist, dass ich dem Server manuell eine IPv6 konfiguriere, entsprechende Regeln in der FW konfigurieren muss und dann sollte es gehen. Werde mich dem mal morgen annehmen.
Quote from: n3 on January 10, 2026, 11:59:33 PM1. AdGuard im ADMIN Netzwerk zur IPv4 auch eine IPv6 vergeben
Meine Annahme ist, dass ich dem Server manuell eine IPv6 konfiguriere, entsprechende Regeln in der FW konfigurieren muss und dann sollte es gehen. Werde mich dem mal morgen annehmen.
Hängt davon ab wie die IPv6 Adresse des Admin Netz Interfaces der Opnsense vergeben wurde... Manuell oder per Track Interface... eine feste IP kannst Du bei adguard aber nur über das darunter liegende System vergeben
Zwei Hinweise:
1. Nicht alle Geräte akzeptieren die Angabe des DNS-Servers per SLAAC, manche brauchen DHCPv6 dazu. Das ist der Grund, weshalb der RA-Mode "Assisted" existiert - dabei wird die IPv6 per SLAAC und nur der DNS-Server per DHCPv6 übergeben.
2. Eigentlich braucht es bei Dual-Stack den IPv6-DNS-Server nicht - es ist sogar eher schädlich, denn jeder DNS-Server kann auch IPv6 auflösen (also reicht der IPv4-Server) und welcher priorisiert wird, falls beide angegeben wurden, ist nicht definiert.
Ergo: In meinem Guide empfehle ich deshalb, gar keinen DNS-Server per IPv6 zu verteilen, also RA-Mode "Unmanaged" (oder wie auch immer das beim verwendeten RA-Daemon heißt) siehe: https://forum.opnsense.org/index.php?topic=45822.0, Note 6.
Quote from: s.meier68 on Today at 08:59:01 AMHängt davon ab wie die IPv6 Adresse des Admin Netz Interfaces der Opnsense vergeben wurde... Manuell oder per Track Interface... eine feste IP kannst Du bei adguard aber nur über das darunter liegende System vergeben
Das ADMIN Netz hat nur IPv4. Sprich mein gesamtes Netzwerk ist eigentlich IPv4 via DHCP und die Clients aus dem LAN-Netz habe ich auf IPv6 umgestellt. Ich würde entsprechend dem AdGuard Server manuell eine IPv6 Adresse vergeben. Diese könnte ich dann im RA als DNS Server angeben und das ganze als "Assisted", richtig?
Quote from: meyergru on Today at 09:26:18 AM1. Nicht alle Geräte akzeptieren die Angabe des DNS-Servers per SLAAC, manche brauchen DHCPv6 dazu. Das ist der Grund, weshalb der RA-Mode "Assisted" existiert - dabei wird die IPv6 per SLAAC und nur der DNS-Server per DHCPv6 übergeben.
Danke für den Hinweis. Was spricht gegen dieses Vorgehen?
Quote from: meyergru on Today at 09:26:18 AM2. Eigentlich braucht es bei Dual-Stack den IPv6-DNS-Server nicht - es ist sogar eher schädlich, denn jeder DNS-Server kann auch IPv6 auflösen (also reicht der IPv4-Server) und welcher priorisiert wird, falls beide angegeben wurden, ist nicht definiert.
Ergo: In meinem Guide empfehle ich deshalb, gar keinen DNS-Server per IPv6 zu verteilen, also RA-Mode "Unmanaged" (oder wie auch immer das beim verwendeten RA-Daemon heißt) siehe: https://forum.opnsense.org/index.php?topic=45822.0, Note 6.
Gilt das auch für AdGuard? Ich möchte das meine Clients alle über AdGuard laufen und aktuell verteile ich keinen DNS-Server über IPv6 und daher greift mein AdGuard nicht.
Wenn deine Clients dual stack sind, können sie AdGuard über IPv4 nutzen. Sind sie IPv6 only, dann brauchen sie natürlich einen IPv6-DNS-Server.
Patrick liegt richtig...
Zu 1:
Ich schrieb das, weil hier empfohlen wurde, den DNS-Server über SLAAC zu verteilen. Wie gesagt, das wirkt nicht immer, weil manche Clients das nicht übernehmen und DHCPv6 dazu benötigen.
Zu 2.
Ich kenne AdGuard nicht, aber theoretisch kann jeder DNS-Server (ob selbst per IPv6 oder IPv4 betrieben) sowohl IPv4 als auch IPv6 auflösen. Du musst hier streng unterscheiden zwischen dem Protokoll, mit dem Du den DNS-Server ansprichst und den Adressen, die er Dir zurückliefern kann.
Angeblich kann Adguard schon lange IPv6: https://adguard.com/en/blog/dns-ipv6-support.html
Wenn Du also per DHCPv4 bereits den Adguard-Server an die Clients annoncierst, wozu brauchst Du dann einen zweiten Server per IPv6? Vor allem: Wenn das unterschiedliche Server wären, ist undefiniert, welches Ergebnis ggf. genutzt würde.
Zusammengefasst:
Wenn man Dual Stack nutzt und somit sowieso (irgend) einen IPv4-DNS-Server per DHCPv4 anbietet, würde ich überhaupt keinen IPv6-DNS-Server verteilen, weder über SLAAC, noch über DHCPv6. Und dann braucht man auch weder DNSv6 noch DHCPv6, sondern nur SLAAC für IPv6, was garantiert mit jedem Client funktioniert, wenn er denn überhaupt IPv6 kann. So steht es auch im HOWTO.
Einen DNS-Server per IPv6 zu annoncieren, brächte nur etwas, wenn man IPv6-only hätte und dann bräuchte man eben den "Assisted" Mode für komplette Abdeckung. Inwieweit IPv6-only aber überhaupt Sinn macht, soll jeder selbst bewerten - ich halte nichts davon, weil man dann für IPv4-only Services im Internet (und davon gibt es reichlich, beispielsweise github.com) wieder irgendwelche IPv6-to-IPv4 Brückenlösungen benötigt.
Ich bin ein Fan von Ockhams Rasiermesser...
Quote from: Patrick M. Hausen on Today at 02:05:59 PMWenn deine Clients dual stack sind, können sie AdGuard über IPv4 nutzen. Sind sie IPv6 only, dann brauchen sie natürlich einen IPv6-DNS-Server.
Vielleicht liege ich ja falsch. Ich gehe davon aus, dass meine Clients im Dual-Stack, denn im LAN-Netz wo sich die Clients befinden läuft ein IPv4 DHCP und sie kriegen auch eine IPv6. Auf meinem Rechner hier zeigt ipconfig folgendes
ipconfig.png
Der der Client eine IPv6 hat, nutzt er diese und geht damit direkt ins Netz am AdGuard vorbei. Erst wenn IPv6 nicht geht, springt er auf IPv4 und nutzt dann den DNS. Das Problem ist also, dass immer wenn IPv6 geht, der AdGuard nicht genutzt wird. Also fast immer.
Oder verstehe ich etwas falsch?
Ja, so ist es. Du zeigst in Deinen Screendumps ja gar nicht, welchen DNS-Server Du verwendest. Ruf mal "ipconfig /all" auf, dann sieht Du es.
Dort sollte, wenn es nur einen per DHCPv4 verteilten Server gibt, auch nur eine IPv4 dafür geben.
Wenn dein Client nur genau einen IPv4-DNS-Server kennt, benutzt er auch nur den. Dann sorg dafür, dass das dein AGH ist und das Problem ist gelöst. Habe ich hier überall genau so am laufen.
Spätestens wenn man IPv6-Only Preferred aktiviert ist der Ansatz, DNS nur über IPv4 abzuwickeln auch in Dual Stack-Netzen hinfällig. Und ich habe den Eindruck, dass das gerade Fahrt aufnimmt. MikroTik hat es seit ein paar Tagen in der Beta. [Verwechslung] Freifunk rollt es hier in KA gerade großflächig öffentlich aus. Man hat dann immer noch IPv4 für Geräte, die darauf angewiesen sind, viele Clients (z. B. Android) verwenden nun aber ausschließlich IPv6 - auch für DNS.
Bei Anschlüssen mit dynamischem Präfix hat es sich bewährt, auf den LAN-Interfaces zusätzlich Virtual IPs (IP Alias) mit ULAs zu konfigurieren. So bekommt jedes Gerät automatisch auch eine ULA (über SLAAC). Die ULA des DNS-Servers kann man dann über RAs und DHCPv6 verteilen.
@meyergru Der RA-Mode "Assisted" ist für den Fall, dass zusätzlich zu SLAAC auch per DHCPv6 Adressen verteilt werden. Was Du meinst ist "Stateless", dabei werden über DHCPv6 nur Optionen wie DNS verbreitet, aber keine Adressen vergeben.
Grüße
Maurice
Quote from: Maurice on Today at 04:15:38 PMviele Clients (z. B. Android) verwenden nun aber ausschließlich IPv6 - auch für DNS.
Wie denn, wenn es keinen lokalen Server auf IPv6 gibt und man DNS ausgehend sperrt? Was man natürlich tun sollte, wenn man OPNsense, AGH etc. am Start hat, um zu filtern.
Stimmt, ich meinte Stateless.
Wie geht denn "IPv6-only preferred"? Sowie ich DS habe, weil einige Clients es brauchen, muss ich doch zwangsläufig DHCPv4 machen und auch einen DNSv4 haben - das würde aber von allen Clients genutzt, oder? Die IPv4-only Clients können dann aber die IPv6-only Services / Geräte nicht nutzen, richtig?
Anders gesagt: Mal mal ein Bild, wie sich das genau zusammensetzt. Ich verstehe ja noch IPv6-only, wobei mich daran schon stört, dass ich:
a. Eine Bridge-Technologie für den externen IPv4-Zugang (z.B. github) brauche und
b. bei dynamischen IPv6-Präfixen zusätzlich noch ULAs für den internen Netzwerktraffic benötige (wobei die dann niedriger priorisiert sind als GUAs, ich also sehr aufpassen muss, dass NUR die ULAs im internen DNS auftauchen).
Das wäre dann schlicht eine Fehlkonfiguration. Wenn man IPv6-Only Preferred verwendet (also die entsprechende Option im DHCPv4-Server konfiguriert), dann muss sichergestellt sein, dass ein DNS-Server über IPv6 erreichbar ist und über RAs und ggfs. DHCPv6 bekannt gegeben wird. Das ist nicht anders als in einem "echten" IPv6-only-Netz. Ist das nicht der Fall, dann haben Clients, die IPv6-Only Preferred unterstützen kein DNS.
@meyergru Das ist jetzt vielleicht nicht der richtige Ort, um IPv6-Only Preferred im Detail zu erläutern; ist auch umfassend dokumentiert.
Kurzform: Dual Stack-Netz mit zusätzlich DNS64 und NAT64. Der DHCPv4-Server teilt den Clients mit, dass in diesem Netz IPv6-only bevorzugt wird. Clients, die das unterstützen brechen DHCPv4 dann ab und verwenden ausschließlich IPv6. Clients, die das nicht unterstützen verwenden ganz klassisch IPv4.
Quote from: Maurice on Today at 04:32:41 PMWenn man IPv6-Only Preferred verwendet (also die entsprechende Option im DHCPv4-Server konfiguriert
Jetzt verstehe ich was du meinst. Ein designiertes "IPv6 mostly" Netzwerk. [1]
Aber das habe ich halt nicht. Und auch meine Empfehlung dem OP gegenüber basiert auf der Annahme, dass man DHCPv4 und SLAAC im betrachteten Netz vollständig kontrolliert und dann ist dual stack einfach gut nachvollziehbar und bequem.
[1] https://www.ietf.org/archive/id/draft-link-v6ops-6mops-01.html
@Patrick Ja richtig, das meinte ich. Und stimmt, IPv6-Only Preferred ist nur der Name der DHCPv4-Option, was natürlich nur ein Baustein des ganzen ist. Sorry für die Konfusion.
Auch wenn man das jetzt noch nicht hat, dann ist es doch nur eine Frage der Zeit. Falls man nicht direkt auf IPv6-only mit DNS64 / NAT64 geht. Wieso es dann nicht gleich richtig machen und DNS auch über IPv6 ermöglichen?
Wir wollen doch nicht die nächsten 20 Jahre weiterhin klassisches Dual Stack fahren.
Das mit dem klassischen Dual-Stack sehe ich auch noch so wie Patrick.
Darüber hinaus haben meine Experimente mit der DHCP option 108 (RFC 8925 (https://www.rfc-editor.org/rfc/rfc8925.html)) mit Kea zumindest bei Windows 11 (noch) nicht funktioniert. Der Client-PC holt sich immer (auch) eine IPv4.
Wenn das besser unterstützt würde, könnte man drüber nachdenken. Allerdings muss man dann im internen DNS beide Varianten (IPv4/6) pflegen, damit alle Clients die Services finden - also Mehraufwand.
Das zeichnet IPv6-Mostly ja aus (jetzt verwende ich den richtigen Namen): Es funktionieren alle Clients, auch die, die die DHCPv4-Option noch nicht unterstützen oder noch kein CLAT haben (Windows) und sogar die, die gar kein IPv6 unterstützen. Man muss daher mit dem Rollout nicht warten, bis alle Clients IPv6-only unterstützen.
In der internen DNS-Zone benötigt man natürlich A- und AAAA-Records, das ist nicht anders als im öffentlichen DNS.