Messages

Also ich hatte noch kein solches Konstrukt, aber:

Wenn das SIP-WAN auf 172.x.x.x/y liegt, müsstest Du zunächst mal eine Route dorthin haben, was automatisch der Fall sein wird, wenn das SIP-WAN-Interface eine IP in diesem Subnetz zugewiesen bekommt. Ich würde jetzt mal davon ausgehen, dass ngn.enviatel.net auch auf eine IP in diesem Netz ausgelöst wird, so dass Du diesen Namen in Deinem SNOM als SIP-Gateway eintragen kannst, um das SIP-Gateway zu erreichen. Das sollest Du aber checken. Falls das Gateway nämlich nicht im Subnetz liegt, musst Du ohnehin eine zusätzliche Route für das SIP-Netz anlegen, sonst würde ja das Default (WAN) Gateway genutzt, was kaum gehen dürfte.

Nur: Die Route zurück vom Gateway in Dein SIP-LAN würde nicht funktionieren, weil Dein ISP ja keine Route zu 192.168.20.0/24 kennt. Deshalb musst Du outbound NAT für das Interface einrichten, so dass sich alle Geräte hinter der SIP-WAN-Interface-IP der OpnSense "verstecken".

Am Rande bemerkt klingt 172.x.x.x/y verdächtig nach RFC1918, so dass das auf dem betroffenen Interface nicht geblockt werden darf (Checkbox nicht gesetzt).

Depending on your local keyboard layout, you may even see problems with special characters or switched Y and Z when you change between console and web interface.

Das wird bei der Verschleierung der IPv6 kaum helfen, wenn die ersten 64 Bits der nach außen sichtbaren IPv6 immer die selben sind.

Trotzdem kaufe ich das Privacy-Argument nicht wirklich, weil die IP schon länger nicht mehr das entscheidende Kriterium ist, beispielsweise eine spezifische Browser-Instanz zu identifizieren, siehe hier (Mobile Device ID) oder hier (Browser fingerprinting), von Cookies mal ganz zu schweigen. Schließlich ist die IPv4 ja auch meist volatil.

Ich stimme @Maurice zu, ich hätte trotz Privacy-Erwägungen lieber feste IPs - insbesondere bei IPv6.

[Andere]

Andere Lösungen heißt zumindest bei mir: zusätzliche Lösungen. Ich habe kein Problem damit, die Mechanismen von IPv4 auf IPv6 umzustellen, wenn das aber bedeutet, für alle möglichen Features zusätzliche Mechanismen oder spezifische Geräte-Konfigurationen (Umstellung von DHCP-Verhalten am Server, Registry-Edits auf Windows-Clients, Umstellungen an Android und/oder IOS-Geräten, separate IPv4- / IPv6-Netze) einsetzen zu müssen, bin ich aus Aufwandsgründen raus - für mich persönlich besteht der Ansatz dann den Lackmustest nicht. Mal ganz abgesehen davon, dass zumindest Ubuntu 24.04.3 und Windows 11 Professional die DHCP Option 108 einfach ignorieren.

Das mag in Business-Umgebungen anders sein, wo AD, LDAP, Windows-Domänen, 802.1x oder IPAM sowieso schon am Start sind. Bei mir ist das mit "IPv4 im LAN" und "IPv6 outbound only" aber anders: Da brauche ich - und zwar nur auf der OpnSense - eine einfache Zuordnung MAC -> IPv4 -> DNS-Einträg(e) und kann damit alles erschlagen.

Es wäre wahrscheinlich auch anders, wenn sich die ISPs nicht auf diese blöde dynamische IPv6-Zuweisung eingeschossen hätten oder langfristiger, wenn IPv6-only eine echte Option darstellt.

@n3: Im RADVD (falls Du den nutzt) kannst Du die Option "Do not send any DNS configuration to clients" setzen - wie gesagt, ich nehme nur SLAAC, keinen DHCPv6. Damit kommt dann kein DNSv6-Server mehr an. So auch das oben verlinkte HOWTO. Das funktioniert - alles, was wir hier diskutieren, ist offenbar komplexer als man sich das so zuerst vorstellt. Mir fehlt bislang jedenfalls das HOWTO, das das lückenlos beschreibt.

Und: Die ULA wird bei DS-Betrieb nie verwendet, solange der Name auch auf eine IPv4 auflöst... das würde m.E. nur mit IPv6-only funktionieren, nicht mit IPv6 mostly. Solange Du dynamische IPv6-Präfixe und IPv4-only Clients hast, wird das nix.

@Patrick: Ich nutze weder Windows-Domänen noch DHCPv6. M.W. unterstützen Android-Clients (und manche andere) auch nur SLAAC für die IPv6-Zuweisung - ich weiß allerdings nicht, ob das aktuell immer noch so ist. D.h., aktuell arbeite ich mit einer festen Reservierung MAC -> IPv4. IPv6 wird eigentlich nur für Outbound genutzt, inbound nehme ich sowieso meist einen Reverse Proxy, deshalb brauche ich da die IPv6 selten.

Oha. Da kommt aber (theoretisch) viel Arbeit auf einen zu, wenn man dem internen DNS die IPv6 (und zwar aus den genannten pragmatischen Gründen ULAs) hinzufügen will:

a. Wie ich gerade feststelle, wird die IPv6 bei Windows aus einer (zufälligen) DUID abgeleitet. Das bedeutet, ich kann die ULA nicht einmal aus den vorhandenen MAC-Daten für die DHCPv4-Reservierungen ableiten. Es sei denn, ich ändere auf den Windows-Clients per Registry-Setting die Einstellungen so, dass die Ableitung aus der MAC erfolgt, so dass man zumindest die EUI-64 vorab zentral kennt. Das könnte im Extremfall bedeuten, dass ich die DNSv6-Einträge alle nochmal händisch erfassen muss, nachdem ich auf jedem Client die tatsächliche ULA ausgelesen habe. Keine Ahnung, wie Android das macht, aber IOS nimmt m.W. auch eine zufällige EUI-64, wenn man es nicht abschaltet (und das nicht nur für ausgehende Verbindungen mit privacy extensions).

b. Automatisiert kann man die Einträge sowieso nicht so einfach erzeugen, weil man für Nicht-IPv6-fähige Geräte und Services keine DNSv6-Einträge machen will - sonst würden die IPv6-only Clients auf Fehler laufen, weil sie ja dann bevorzugt IPv6 versuchen würden. Wobei: das gälte nur für GUAs, siehe nächster Punkt.

c. Bei ULAs ist es so, dass die ja überraschenderweise niedriger priorisiert werden als IPv4. Wenn also beide Einträge existieren, bringt das rein gar nichts, denn die IPv4 wird der ULA IPv6 immer vorgezogen. IPv4-only Clients nehmen sowieso nur IPv4, und solange diese noch existieren, werden die IPv4-DNS-Einträge auch noch gebraucht - es wäre nicht einmal eine Option, die Einträge exklusiv nur für IPv4 oder IPv6 zu machen.

d. Differenzieren müsste man für echte Services sowieso, denn wenn die per DHCP-Option 108 IPv6-only gesetzt werden, sind sie für IPv4-only Clients nicht mehr erreichbar. M.W. unterstützt Kea DHCP auf OpnSense eine Client-spezifische Steuerung der Option 108 nicht - solche Services müssten also statisch auf Dual-Stack konfiguriert werden.

Ergo: Alle Clients nutzen sowieso nur den IPv4-Teil des DNS-Eintrags. Dann kann ich mir die lokalen IPv6-Einträge im DNS also gleich sparen.

Offenbar wird das also nix bei mir mit "IPv6-mostly" - m.E. klappt das erst gut mit "IPv6 only".

Sorry für Off-Topic, aber wie gesagt, ich versuche nur gerade, das Big Picture zu erfassen (die klassische Version mit internem IPv4 kenne ich).

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) mit Kea zumindest bei Windows 11 (noch) und bei Ubuntu 24.04.3 nicht funktioniert. Die Client-PCs holen 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.

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).

Did you follow the bridge documentation to the very end, including the tuneables? https://docs.opnsense.org/manual/how-tos/lan_bridge.html

If you did, you would end up with a single LAN interface that is configured as a bridge of igc1-3 with a single IPv4 range only. Anything else is probably a misconfiguration.

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.

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...

Did you try RSS?

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.

1. Did you specify "force" in the option?
2. Did you wait for the client to renew its lease?

If at all, why not create a setting that is stored in config.xml and can be switched between bash, sh, tcsh and others?