IPv6 und DHCP Server richtig konfigurieren

[bimbar]

Hallo zusammen,
sehe ich es richtig, dass es nun mit der Version 21.7 funktionieren sollte?
Hat es schon einer ausprobiert?

Issue #2544 ist bis jetzt nicht integriert und die Diskussion darüber ist so ein bißchen eingeschlafen, scheint mir.

https://github.com/opnsense/core/issues/2544
https://github.com/opnsense/docs/pull/330

Selbst habe ich ähnliche Probleme dann auf die oben genannte Steinzeit Art gelöst: Intern statisch, NAT nach außen. Funktioniert ausgezeichnet.
Scheint auch die einzige funktionierende Lösung im Cluster Betrieb zu sein. Hätte ich kein Cluster, dann wäre es denke ich mit "Track Interface" und "Unmanaged" auch gelaufen.
Natürlich funktioniert bei "Unmanaged" der DNS nicht, aber das wird bei IPv6 nur schwer zu verhindern sein.

Bei der Cluster Problematik sagte übrigens auch ein echter Experte (https://www.hznet.de/pub.html), das ginge mit dynamischen Präfixen einfach nicht, da wäre der Standard noch nicht so weit.

[psychofaktory]

In den Diskussionen auf Github kommt es teilweise so rüber als wären IPv6-Präfix-Aliase nur eine Anforderung für sehr spezielle Konstellationen.

Wenn es eine Upvote-Funktion für Features gäbe wäre das aber wahrscheinlich einer der gefragtesten Neuerungen.

Allein dieser Thread hier wurde bereits mehr als 7000x aufgerufen. Und es gibt ja noch weitere Threads mit ähnlichen Anfragen.

Die Möglichkeiten die sich mit IPv6-Präfixen ergäben wäre vielfältig und würden viele Probleme lösen, bzw. vieles ermöglichen was bisher nicht oder nur mit Umwegen geht.


Ich hoffe sehr, dass eine Implementierung sehr zeitnah erfolgt.
Zumal hier ja bereits eine funktionsfähige Lösung programmiert wurde, wenn ich den Diskussionsverlauf auf Github richtig verfolgt habe.

[bimbar]

Vielleicht ist die Sache mit den dynamischen Präfixen hauptsächlich ein Problem von deutschen Privatkunden.

[tiermutter]

Das glaube ich leider auch... 
Deshalb scheint wohl auch nur AVM sowas ähnliches in seine Fritten einzubauen.

[JeGr]

Problem existiert definitiv nicht NUR in DE, aber hier ist man eben sehr aufgeschmissen, weil man klassisch IPs nur an Geschäftskunden rausgerückt hatte. Gibt die Problemstellung aber auch bei US Providern und auch in Canada habe ich schon ein paar Provider gesehen, die das machen. Beschwerden auch bei RIPE, ARIN etc. in den Foren o.ä. gibt es reichlich, geraten wird meist "über den Geldbeutel" abzustimmen und solche Provider einfach zu meiden und ihnen auch zu schreiben bei Kündigung etc. warum.

Bringt uns in DE aber leider nichts, denn hier muss man schon mit der Lupe suchen um einen Provider zu finden, der einem statische Adressen liefert. Frei nach dem Motto "haben wir doch schon immer so gemacht, das funktioniert". Wird auch immer wieder vorgeblich der Datenschutz vorgeschoben, das wäre wegen Privacy und Co. Kompletter BS, denn gleichzeitig wird sieht u.a. der EuGH bei Telkos die IP Adresse trotz Dynamik als eindeutig zuordnbares Merkmal im Sinne des Datenschutzes oder DSGVO, da sie bspw. nach entsprechenden Beschlüssen wieder "eindeutig zugewiesen werden kann" und somit klar ist, wann welcher Kunde mit welcher IP mit dem Anschluß online war. Dass Telkos heute immer noch mit Privacy und Datenschutz argumentieren zeigt nur, wie stupid man an falschen Aussagen festhält.

Es bleibt leider dabei, dass man sinnvoll mit v6 nur arbeiten kann, wenn das Prefix statisch ist. Entweder nutzt man intern ULA und NATtet dann dreckig nach außen auf die Router IP6 (kompletter Nonsense und jeglicher Vorteil von v6 verbrannt) oder man bastelt sich auf dem WAN eine Erkennung, ob sich das zugewiesene Prefix geändert hat und lässt via Automatismus dann ggf. die NPt Tabelle ändern und macht eine Prefix Translation der internen ULA Netze auf externe GUAs. Aber an der Stelle fehlt der "Automatismus" um NPt mit dynamischen Prefixen zu verheiraten. Und solangs noch Hardcore DSL Anbieter gibt, die selbst noch "Zwangstrennung" bzw. neue IP alle 24h hart durchsetzen ist alles außer automatisch nicht sinnvoll funktionabel. Leider

Alternativen:

* GIF Tunnel zu HE.net und fixes IP6 getunnelt
* OVPN Tunnel zu kleiner Miet-VM mit echter IP4/IP6 Netz(en) die das weiterleitet.

Dann hat man allerdings eben immer den Tunneloverhead noch mit dabei und verliert den eigentlichen Vorteil von IPv6: weniger Overhead, ggf. schneller und direkter.

Fatal.

[Patrick M. Hausen]

Es bleibt leider dabei, dass man sinnvoll mit v6 nur arbeiten kann, wenn das Prefix statisch ist. Entweder nutzt man intern ULA und NATtet dann dreckig nach außen auf die Router IP6 (kompletter Nonsense und jeglicher Vorteil von v6 verbrannt) [...]

Bei meinen WireGuard-Experimenten mit Ziel Droplet in den USA oder in GB hatte ich festgestellt, dass die Happy Eyeballs auf Apple-Geräten wenn nur ULA vorhanden ist, gar kein IPv6 benutzen.

Ob das aktuell immer noch so ist, kann ich grad nicht sagen.

Ich hab daher für diese Tunnel auch /64 aus meinem fixen /56 von der DTAG benutzt - wird bei Digital Ocean "raus-zus" (wie der Badner sagt) ja dann wieder geNATet.

Gruß
Patrick

[BusinessTux]

Wahrscheinlich werde ich gleich gesteinigt, aber ich muss noch einmal nachfragen, weil ich noch nicht so weit bin mit IPv6 wie ihr.

Laut dem Threadthema geht es um die Konfiguration von DHCPv6 auf der OPNsense. Nach meinem Verständnis bedeutet das,

• Annahme des Präfixes vom Provider
• Verteilung von IPv6-Adressen in den lokalen Netzen mit Subnetzen aus dem Provider-Präfix
• Eintragen der lokal vergebenen IPv6-Adressen im DNS-Server OPNsense

Das was jetzt in den letzten Posts beschrieben wurde, dreht sich aber um (in meinen Augen) IPv6 Natting von internen IPv6-Adressen auf externe IPv6-Adressen, oder?

Laut der Release-Beschreibung auf https://opnsense.org/about/road-map/ sollte OPNsense die IPv6-Adressen jetzt in Unbound eintragen.

Ich kann mit den dynamischen IPv6-Adressen leben. Wenn ich sie extern bräuchte, würde ich diese über DynDNS veröffentlichen. Leider trägt der DHCPv6-Server aber die vergebenen Leases nicht in Unbound ein (bei mir), wie es in der Roadmap beschrieben wurde. Mein Setup ist einem der vorangegangenen Post beschrieben. Dadurch habe ich keine Möglichkeit interne DNS-Namen auf IPv6-Adressen aufzulösen. Als Übergangslösung nutze ich aktuell MAC-Adressen in den Firewall-Aliassen, um die Freigaben nicht nach jedem DSL-Neustart ändern zu müssen.

Habt ihr noch einen Tipp für mich, was ich in der OPNsense untersuchen/debuggen kann, warum die DHCPv6-Releases nicht in Unbound eingetragen werden? Oder habe ich die Ankündigung falsch verstanden?

Danke
Ulf

[bimbar]

Wahrscheinlich werde ich gleich gesteinigt, aber ich muss noch einmal nachfragen, weil ich noch nicht so weit bin mit IPv6 wie ihr.

Laut dem Threadthema geht es um die Konfiguration von DHCPv6 auf der OPNsense. Nach meinem Verständnis bedeutet das,

• Annahme des Präfixes vom Provider
• Verteilung von IPv6-Adressen in den lokalen Netzen mit Subnetzen aus dem Provider-Präfix
• Eintragen der lokal vergebenen IPv6-Adressen im DNS-Server OPNsense

Das was jetzt in den letzten Posts beschrieben wurde, dreht sich aber um (in meinen Augen) IPv6 Natting von internen IPv6-Adressen auf externe IPv6-Adressen, oder?

Laut der Release-Beschreibung auf https://opnsense.org/about/road-map/ sollte OPNsense die IPv6-Adressen jetzt in Unbound eintragen.

Ich kann mit den dynamischen IPv6-Adressen leben. Wenn ich sie extern bräuchte, würde ich diese über DynDNS veröffentlichen. Leider trägt der DHCPv6-Server aber die vergebenen Leases nicht in Unbound ein (bei mir), wie es in der Roadmap beschrieben wurde. Mein Setup ist einem der vorangegangenen Post beschrieben. Dadurch habe ich keine Möglichkeit interne DNS-Namen auf IPv6-Adressen aufzulösen. Als Übergangslösung nutze ich aktuell MAC-Adressen in den Firewall-Aliassen, um die Freigaben nicht nach jedem DSL-Neustart ändern zu müssen.

Habt ihr noch einen Tipp für mich, was ich in der OPNsense untersuchen/debuggen kann, warum die DHCPv6-Releases nicht in Unbound eingetragen werden? Oder habe ich die Ankündigung falsch verstanden?

Danke
Ulf

Ja, nur, wie baust du deine Firewallregeln, wenn dein Präfix dynamisch ist?
Und wie sieht das aus, wenn du ein HA Cluster benutzt, als gateway aber immer nur die lokalen Adressen der jeweiligen Firewalls und nicht die Clusteradresse rausgegeben wird?

Zu deiner Frage habe ich keine sinnvolle Antwort, außer daß es vielleicht Sinn macht, intern IPv4 zu benutzen, oder ansonsten statische IPv6 ULA Adressen.

[JeGr]

> Ja, nur, wie baust du deine Firewallregeln, wenn dein Präfix dynamisch ist?

Das ist eine hypothetische Frage aber wofür brauche ich Regeln von genau einem Client? Durch Privacy Extensions haben die eh immer andere Adressen. Man kanns abschalten und den Client fix per DHCP6 zuweisen aber selbst dann ist die Frage, warum ich genau einen Client einfangen möchte? Ansonsten kann ich ja problemlos mit dem <Interface>_network Alias arbeiten was sich dann auch an dynamic prefixes anpasst

> Und wie sieht das aus, wenn du ein HA Cluster benutzt, als gateway aber immer nur die lokalen Adressen der jeweiligen Firewalls und nicht die Clusteradresse rausgegeben wird?

HA ist mit dynamischem Kram nicht sinnvoll machbar, ja. Einzige Möglichkeit wäre da nach draußen zu NATten und intern ein fixes Netz aus ULA fdXY:: Segment zu nutzen. Aber das ist schon ziemlich hacky.

>  Habt ihr noch einen Tipp für mich, was ich in der OPNsense untersuchen/debuggen kann, warum die DHCPv6-Releases nicht in Unbound eingetragen werden? Oder habe ich die Ankündigung falsch verstanden?

Sind in Unbound denn die Haken für DHCP Reservation drin? Sind in DHCPv6 die DNS Registrationen auch eingeschaltet? Mal das DynDNS ausklappen und Testweise Registration in DNS anhaken aber keines der anderen Felder (DynDNS) ausfüllen.

Cheers

[Patrick M. Hausen]

Mag gerade bei Jens nochmal einhaken.

Wenn Du bei internen Netzen auf "festen IP Adressen" bestehst und Regeln per Adresse baust, machst Du oft was falsch. Alle Geräte mit gleicher Policy in dieselbe Brodcast Domain und Regeln per Interface, scheißegal mit welcher Adresse der Client ankommt. Ja, ein Netz für die Familie, eines für Internet of Sh^H^HThings, eines für die öffentlich erreichbaren Server ... VLANs existieren.

Ausnahmen, die ich natürlich bereitwillig akzeptiere: z.B. eine ausgehende NAT-Regel mit "same ports" nur für die Telefonanlage.

Aber in der DMZ @work geht zu allen Servern genau HTTP, HTTPS, SMTP, ICMP ... fertig. Alle gleich. Brauche ich für ein Projekt was grundlegend Anderes, gibts eine weitere DMZ.

Gruß
Patrick

[BusinessTux]

Ja, nur, wie baust du deine Firewallregeln, wenn dein Präfix dynamisch ist?

Die Firewallregel(n) habe ich mit MAC-Aliasen gebaut. In den pfTables kann ich dann sehen, dass er damit die IPv4- und die IPv6-Adresse für die Freischaltung nutzt.

Das ist eine hypothetische Frage aber wofür brauche ich Regeln von genau einem Client? Durch Privacy Extensions haben die eh immer andere Adressen. Man kanns abschalten und den Client fix per DHCP6 zuweisen aber selbst dann ist die Frage, warum ich genau einen Client einfangen möchte? Ansonsten kann ich ja problemlos mit dem <Interface>_network Alias arbeiten was sich dann auch an dynamic prefixes anpasst

Ich möchte bestimmen, welcher Host welche ausgehende Verbindung aufbauen darf.

Sind in Unbound denn die Haken für DHCP Reservation drin? Sind in DHCPv6 die DNS Registrationen auch eingeschaltet? Mal das DynDNS ausklappen und Testweise Registration in DNS anhaken aber keines der anderen Felder (DynDNS) ausfüllen.

Haken in Unbound ist drin (2021-10-16 04_50_51-Services_Unbound_DNS_General.png). Lt. Doku gilt der aber nur für IPv4  . Ich habe den DynDNS-Haken im DHCPv6-Server jetzt mal reingesetzt (2021-10-16 04_57_33-Servcices_DHCPv6.png). Aus der Beschreibung verstehe ich das so, dass die Einträge mit Authentifizierung an einen DNS-Server gemeldet werden. Aber mal schauen.

Was mich nur wundert, dass die Leases noch nicht einmal beim DHCP-Server angezeigt werden (2021-10-16 05_24_58-Leases_DHCPv6_Services.png). Oder liegt hier der Fehler.

Ich bekomme jedenfalls auf meinen Debian-Servern IPv6-Adressen mit dem Provider-Präfix vergeben.

Danke
Ulf

[JeGr]

Wenn Du bei internen Netzen auf "festen IP Adressen" bestehst und Regeln per Adresse baust, machst Du oft was falsch. Alle Geräte mit gleicher Policy in dieselbe Brodcast Domain und Regeln per Interface, scheißegal mit welcher Adresse der Client ankommt. Ja, ein Netz für die Familie, eines für Internet of Sh^H^HThings, eines für die öffentlich erreichbaren Server ... VLANs existieren.

Das

Und weil ich das Beispiel bekommen habe mit dem Rechner von KindX, das im Familiennetz mit den anderen Rechnern bleiben soll/muss (sonst kann man nicht mehr gut zusammen spielen) und trotzdem aber ab 23h nicht mehr ins Internet soll:

Es gibt viele andere/sinnvolle Lösungsansätze dafür. Primär Kommunikation mit dem Nachwuchs (Stichwort Medienerziehung), aber wenns nicht anders geht, kann man immer noch anders reingrätschen. Captive Portal (mit MAC Freigabe der anderen PCs damit diese immer gehen) wäre einer. Wenn man semi-intelligente Switche oder WiFi APs hat kann man Radius-Anmeldung am Netz machen (radius based VLANs) und im Radius dann Zeitlimits beim User hinterlegen, die dann auch für alle Geräte gilt statt nur dem Rechner (Handy von Kind X ist dann auch offline). Man kann nen Proxy eintragen. Möglichkeiten sind dan.

Aber hauptsächlich geht es darum, nicht IP4/IP6 mit der Identität bzw. Person zu verknüpfen und das dann als stehendes Filterkriterium einzusetzen. Ja, haben wir sicher alle schon aus Faulheit mal gemacht/versucht. Sinnvoll ist es aber wenn man drüber nachdenkt und gerade mit Blick auf IP6 eben durch mehrere (wechselnde) Adressen nicht. Und selbst unser Jüngster war schon schlau genug nach zwei Runden Google sich einfach ne andere Adresse oder DNSe im System einzutragen. Klar, jetzt kann man anfangen warum er überhaupt Rechte dafür am Rechner hat... Aber das Endresultat ist, dass eine (dynamische) Adresse als Merkmal eben keine saubere/eindeutige Identifikation ist und man das daher auch nicht so gut filtern kann wie mit anderen Methoden (wenns um persönlichen Zugriff ins Netz geht). Andere Fälle haben da natürlich andere Anforderungen. Aber das Kind-Beispiel bekomme ich eben oft als Argumentation warum es doch möglich sein muss, eine IP4/IP6 "einfach zu blocken" (oder ne scheduled rule damit zu machen).

Es kommt einfach auf die Anforderung an, und dann schaut man, wie diese am besten lösbar sind

[JeGr]

> Ich möchte bestimmen, welcher Host welche ausgehende Verbindung aufbauen darf.

Und genau das ist die Frage. Warum? Macht das Sinn mit dieser Art und Weise? Kann/sollte man das ggf. anders lösen? Etc.
Aber da kommt auch Patricks Aussage ins Spiel: das ist Micromanagement auf IMHO zu tiefer Ebene. Gruppieren nach gleichem Bedarf und kapseln/in gleiche Subnetze packen ist da wesentlich effizienter und macht weniger Ärger als mehrere/dutzender einzelner Regeln die alle spezifisch auf einen Client aufbauen.

[tryhard]

>> Ich möchte bestimmen, welcher Host welche ausgehende Verbindung aufbauen darf.

>Und genau das ist die Frage. Warum? Macht das Sinn mit dieser Art und Weise?

Klar kann das Sinn machen - Ich will ein Geräte im LAN haben aber es soll keine Verbindung ins Internet aufbauen (fehlerhafte Update, blöde Smart TV Funktionen, "Ich will es einfach nicht" )
Gehört auch mit IPv6 für mich zu den Basics einer Firewall.

Ich teste mal was gerade so geht - wird aber bissl dauern

[tiermutter]

Ich will ein Geräte im LAN haben aber es soll keine Verbindung ins Internet aufbauen (fehlerhafte Update, blöde Smart TV Funktionen, "Ich will es einfach nicht" )

So ein Gerät habe ich auch... genauer gesagt habe ich zwei solcher Geräte. Die bekommen einfach ein nicht vorhandenes Gateway und einen nicht vorhandenen DNS und schon ist Ruhe im Karton, ohne dass die Sense mit den ständigen Verbindungsversuchen belästigt wird.
Alle Jubeljahre bekommen die dann mal kurz eine korrekte Konfiguruation sodass sie sich Updates saugen können, ansonsten können die Geräte nur im LAN kommunizieren.