IPv6 mit FritzBox?
-
Hallo zusammen,
ganz, ganz gefährliches Thema für mich da ich recht wenig (an sich kaum was über IPv6 weiß). Von zwingend brauchen kann ja absolut keine Rede sein. Eher - schauen was wie womit usw.
Dazu habe ich 2 Blogs gefunden
https://blog.veloc1ty.de/2015/08/22/pfsense-ipv6-delegation-hinter-fritzbox/
https://moerbst.wordpress.com/2016/07/31/ipv6mit-pfsense-an-dsl-der-telekom/Also theoretisch zum einrichten (ohne großes Verständnis dafür aufbringen zu müssen) sollte es recht einfach sein. Das Problem was ich habe, ist in beiden Anleitungen steht u.a
LAN
"– IPv6 prefix ID: 0"und dann "HINWEIS: solltet ihr beispielsweise eine zusätzliche Netzwerkschnittstelle als DMZ einsetzen, übernehmt ihr bis auf die IPv6 prefix ID alle Einstellungen für OPT1 genauso, nur bei der IPv6 Prefix ID zählt ihr hoch: OPT1 ist dann IPv6 Prefix ID 1 etc.."
Und genau das funktioniert hier nicht. Spricht ich kann bei der erster Schnittelle unter "IPv6 Interface" - WAN wählen und dann die Track-ID 0, wenn ich jetzt eine weitere Schnittelle wähle und wieder als IPv6 Interface WAN, und dazu versuche ich bei der Track-ID 1 zu wählen, kommt die Meldung "The specified IPv6 Prefix ID is out of range. (wan) - (0) - (0)", versuche ich ID 0 kommt die Meldung, dass diese schon in Verwendung ist.
Ich habe hier die Beta 2.4 - womöglich hängt das damit zusammen.
-
Wenn ich an anderer Stelle keine Fehler gemacht habe, dann wird es ein Problem mit der BETA sein, denn bei mir taucht unter Track-ID immer der Hinweis "(hexadecimal from 0 to 0)" und in beiden Anleitungen steht an der Stelle "0-ff"
-
Dann hast du auf dem WAN im DHCP6 kein größeres Segment als ein /64 in der Delegation, denn dann kein dein Tracking auch nicht mehr wie ein Netz zuweisen. Wenn du auf dem WAN den Request erhöhst auf ein /60 oder /56er, dann bekommst du auch automatisch einen größeren Range, der beim Tracking des Interfaces per ID vergeben werden kann.
-
Dann hast du auf dem WAN im DHCP6 kein größeres Segment als ein /64 in der Delegation
jupp da hatte ich in der Tat bei allen Interfaces /64 drin.
Aber so ganz funktioniert es nicht oder ich habe es nicht verstanden (die verlinkte Anleitungen).
-
Auf der Fritz ist DHCP6 und DNS6 aktiv
-
Es wird nur DNS6 und Netzpräfix verschickt
-
Auf der pfSense wird WAN Interface bei IPv6 auf DHCP6 gestellt
-
Alle anderen Interfaces auf "Track Interface" und zwar auf WAN
So jetzt wird mir auf pfSense bei Interfaces gezeigt:
WAN - fe80::20d:b9ff:fe44:6098%igb0
Alle anderen Interfaces haben nichts von IPv6, ergo die Klients haben nichts von dem bisherigen Konstrukt. -
-
Hmm, keiner der so etwas gemacht hat?
-
Das WAN hat keine Adresse bekommen. fe80 ist eine reine interne Verbindung (local link) und keine echte IPv6.
-
Das WAN hat keine Adresse bekommen. fe80 ist eine reine interne Verbindung (local link) und keine echte IPv6.
Nach dem was ich so verstanden habe, soll ja WAN keine Adresse bekommen sondern irgendwie nur den Netzpräfix. Das scheint aber nicht so zu funktionieren wie in dem ersten verlinkten BLOG beschrieben.
So sehen meine Einstellungen an der Fritze und Sense aus
-
Nach dem was ich so verstanden habe, soll ja WAN keine Adresse bekommen sondern irgendwie nur den Netzpräfix. Das scheint aber nicht so zu funktionieren wie in dem ersten verlinkten BLOG beschrieben.
Das WAN soll kein eigenes Prefix bzw. eine eigene Adresse bekommen, sollte aber evtl. eine IP6 aus dem Prefix der Fritzbox/des Routers bekommen. Die hat ja für ihr "LAN" ein Prefix bezogen und in Verwendung. Aus diesem kann sie die pfSense dann auch bedienen. Aber ja, es sollte auch mit der link-lokal Adresse mit fe80 theoretisch funktionieren. Bei meinem Labor-Unitymedia Anschluß war es aber so, dass trotzdem das /64er Prefix der FB auf WAN gesetzt wurde, trotz "keine Adresse beziehen" Schalter.
Je nachdem was auf WAN konfiguriert ist, was als Prefix bezogen werden soll, kann dann im Tracking die ID entsprechend gesetzt werden. Es könnte aber auch durchaus noch ein V2.4 Problem mit v6 sein.
Ich muss jedoch gestehen, dass ich das v6 Setup im Labor teils aufgegeben habe :/ Der Grund ist einfach, dass das Zusammenspiel zwischen Provider (wechselnde Prefixe nach Zeit X), Weitergabe von v6 Prefix an weitere Router (aka pfSense) und dort Vergabe an die Interfaces einfach extrem unhandlich ist. Der Sinn von v6 war an dieser Stelle ja, dass man überall mit public IPs hantieren kann und nur noch routen muss. Soweit OK. Aber dass man sich dank den Providern wieder mit dynamischen Adressprefixen herumschlagen muss, weil diese sich einfach mal ändern, war eigentlich nicht geplant.
Bislang habe ich deshalb einen HE.net Tunnel noch benutzt, der dann auch sauber statisch konfiguriert werden kann. Tunnel haben aber eben das Problem, dass dann wieder Payload Problemchen mit ins Spiel kommen (#1) und dann wiederum unnötiges Geofencing von Anwendungen einem den Tag vermiesen (#2 - bspw. Netflix). -
Moin,
Nach dem viele rumprobieren will die pfS überhaupt nichts mehr davon wissen egal mit welchen Einstellungen. Vermutlich ist da etwas abgekackt. Irgendwann im April oder so werde ich dann die aktuelle Beta installieren und vielleicht wieder probieren.
Interessant wäre es irgendwie schon auch wenn ich im Moment kaum was von IPv6 verstehe. Da werde ich wohl zumindest grob darüber lesen müssen. -
Vor dem Problem mit den dynamischen IPv6 Adressen hab ich auch schon gestanden. Weiß der Geier was sich die Provider dabei gedacht haben.
Der HE Tunnel war auch meine Lösung, mit genau den gleichen Problemen (Netflix :/ )Mal was Anderes, hat sich schon jemand gendanken über das IPv6 Regewerk gemacht, besonders wenn Clients kein DHCPv6 unterstützen (Android).
Ich bin kurz davor ipv6 wieder von Board zu werfen oder nur statisch zu vergeben.
Als ich mich in das Thema eingelesen habe, wurde mir bereits Angst und Bange wegen der Stateless IP Adressvergabe von IPv6, nach dem Motto "Magie, tu was du willst, Hauptsache es geht"
Ich kann momentan meine Android Clients nicht dazu bewegen immer die gleiche IP Adresse zu nehmen oder IPv6 zu deaktivieren (Es sei denn ich roote das Gerät).
Also kann ich auch keine Regeln dafür machen, ausser ich lass nur die DHCP-Range durch und alles andere wird generell geblockt.Wie soll das später in Unternehmen funktionieren ?
-
Mal was Anderes, hat sich schon jemand gendanken über das IPv6 Regewerk gemacht, besonders wenn Clients kein DHCPv6 unterstützen (Android).
Warum? Also mein Android unterstützt das schon, aber mit RA und SLAAC bekamen die problemlos auch eine IP6 zugewiesen bzw. haben sich einfach welche ausgewürfelt.
Ich kann momentan meine Android Clients nicht dazu bewegen immer die gleiche IP Adresse zu nehmen oder IPv6 zu deaktivieren (Es sei denn ich roote das Gerät).
Das ist in der Tat ein Problem, aber zumindest bei der "gleichen Adresse" teils gewollt. Entweder du konfigurierst statisch (Server) oder den Client am Besten via SLAAC was auch Android problemlos beherrscht. DHCP6 mit statischer Vorgabe ist eigentlich nicht für Clients gedacht. Da die meisten Clients Privacy Extension per default aktiviert haben und somit ihren Client Part rotieren, wäre DHCP6 hier eher kontraproduktiv. Aber auch ohne PE würde sich SLAAC Vergabe nach dem Standard richten und so auf Grund der MAC eine vorhersehbare Adresse erzeugen.
Das andere Problem - dass IPv6 nicht einzeln deaktivierbar ist bei Android - wiegt schwerer, da man eben bspw. dann bei Netflix auf Tablets wortwörtlich in die Röhre schaut. Ohne Root ist man hier leider dumm dran, es sei denn der Hersteller hat ggf. einen entsprechenden Schalter in der Firmware, der v4 präferieren oder v6 deaktivieren kann (OnePlus bringt das bspw. mit der nächsten Firmware).
Also kann ich auch keine Regeln dafür machen, ausser ich lass nur die DHCP-Range durch und alles andere wird generell geblockt.
Das allerdings ist eh die völlig falsche herangehensweise. Man blockt bei v6 nicht mehr ein Gerät (Client) gezielt per IP Adresse. Diese wäre eh sinnfrei, da sich das Gerät problemlos eine neue geben könnte (oder der User) und bei v6 hätte er da genug Adressen frei ;) Für den Einsatz im Unternehmen wird daher klar empfohlen:
- Server mit statischer Konfiguration oder in Ausnahmen DHCP6 mit Reservierung
- Clients mit SLAAC + DHCP6 für DNS/NTP Vergabe.
Zudem wird generell bei v6 empfohlen die Broadcast Domains nicht zu groß zu gestalten, sprich nicht Myriaden viele Geräte in ein Netz zu packen, sondern hier zu segmentieren und dann an den Gateways zu Filtern und Routen. In Unternehmen ist das auch kein großes Problem: Server in ein VLAN, Clients je nach interner Größe und Wunsch aufgesplittet nach Teams, Abteilungen, Gebäuden oder sonstigem in kleinere VLANs, Filtern an den Grenzen der Netze. Fertig.
-
Wenn man im v6 Umfeld nicht mehr per IP Adresse blockt, wie dann ?
-
Na du willst ja nicht bei 64bit Adressen pro Prefix ernsthaft anfangen einzelne Adressen zu blocken? Das ist ja zum Beginn schon zum Scheitern verurteilt. Wie gesagt sind durch PE - privacy Extensions - und SLAAC und Co. eh schon problemlos mehrere v6 Adressen pro Rechner am Start, die du nicht beeinflussen kannst. Was willst du also blocken? :)
Ich verstehe deine Anforderung da nicht, was du bei v6 überhaupt spezifisch per Adresse blocken willst?! Vielleicht hast du ein Beispiel dass es klarer macht?
-
Na du willst ja nicht bei 64bit Adressen pro Prefix ernsthaft anfangen einzelne Adressen zu blocken?
Also nein, da wir ja IPv6 nicht gebändigt bekommen bekommen, was die IP Adressvergabe angeht, kann ich das vergessen.
Mein Ansatz war, dass ich generell den kompletten IPv6 Bereich blocke und nur die Clients, die dhcpv6 unterstützen oder Statisch vergeben sind, dürfen raus bzw. kommen restriktiert raus.Das ist ja zum Beginn schon zum Scheitern verurteilt. Wie gesagt sind durch PE - privacy Extensions - und SLAAC und Co.
Meine Rede, diese Stateless IP Vergabe ist nur misst. Ich habe keine Kontrolle mehr darüber, wer welche IP bekommt.
Ich verstehe deine Anforderung da nicht, was du bei v6 überhaupt spezifisch per Adresse blocken willst?! Vielleicht hast du ein Beispiel dass es klarer macht?
Ganz einfach, ich will verhindern, dass meine Kinder rund um die Uhr ins Internet kommen können, ohne das Smartphone jedesmal einsacken zu müssen.
Und da Android und seit neuster Kenntnis Windows 10 (Anniversary Update Version) kein DHCPv6 können, ist es momentan nicht möglich.
Deswegen die Frage, wie kann IPv6 Devices restriktieren, wenn nicht über die IP.
–Update, das mit Windows 10 scheint nicht generell zu sein, der eine Rechner hat ne DHCP IP, der andere nicht. Muss mal schauen an was das liegt.
-
Meine Rede, diese Stateless IP Vergabe ist nur misst. Ich habe keine Kontrolle mehr darüber, wer welche IP bekommt.
OK dann hast du aber auch v6 nicht wirklich verstanden. Das ist kein Mist, das ist eine sinnvolle Methode das ganze überhaupt sinnvoll bekommen. Bei einem Client ist die Adresse völlig egal. Warum ist die wichtig? Bei einem Server ist es OK, aber da wird die Adresse auch meist statisch vergeben. Ich verstehe das Problem nicht. Du scheinst einfach Mechanismen oder eingefahrenen Workflow von v4 Zeiten einfach auf v6 zu übertragen und das klappt nicht. Es sind nicht einfach längere IP Adressen, es ist ein komplett eigenständiges (anderes) Protokoll. :)
Ganz einfach, ich will verhindern, dass meine Kinder rund um die Uhr ins Internet kommen können, ohne das Smartphone jedesmal einsacken zu müssen.
Und wo ist das Problem? Dann werden die Kids in ein eigenes Prefix gesteckt und das Prefix entsprechend behandelt und mit einer time-based Rule bspw. geblockt. Problem gelöst :)
Es hat schon seinen Grund, warum gesagt wird, dass man bei v6 entsprechend genug Prefixe zur Verfügung stellen soll und dass die Broadcast Domains nicht zu groß werden sollen. Zudem versuchst du ein Problem auf eine Art zu erschlagen (IP Blocken) die vorher schon nicht wirklich sinnvoll war (bei v4 vergibt man sich einfach ne andere IP - done - das geht auch auf dem Handy und "dank" YT Videos kann das jeder). Wenn du da ordentlich blocken willst (bsp Handys), dann löse das doch über bspw. ein Captive Portal - das ist auch dafür gedacht :)
Grüße
-
OK dann hast du aber auch v6 nicht wirklich verstanden.
Ich glaube schon dass ich IPv6 im Groben verstanden habe, nur bin ich mit dieser Philosophie nicht einverstanden. Das ist ein Unterschied.
Und wo ist das Problem? Dann werden die Kids in ein eigenes Prefix gesteckt und das Prefix entsprechend behandelt und mit einer time-based Rule bspw. geblockt. Problem gelöst :)
Eigenes Prefix bedeutet anderes (V)LAN, oder irre ich mich ? Das ist ja wie durch die Brust ins Auge.
Mal davon abgesehen, muss ich meiner Fritzbox Mullti-SSID und VLAN beibringen. Das wäre zwar mittels Freetz sogar noch möglich aber der Aufwand wäre mir zu hoch. Oder ich nehme einen zusätzlichen AP in Betrieb. ::)Es hat schon seinen Grund, warum gesagt wird, dass man bei v6 entsprechend genug Prefixe zur Verfügung stellen soll
Das ist z.b. eins von den Dingen, die ich an dieser Philosophie nicht mag, nur weil durch ipv6 quasi unmengen an Adressen zu Verfügung stehen, verschleudern wir Diese jetzt als wären sie unendlich verfügbar.
Alleine für ein Tranfernetz wird bereits ein /64er Prefix verballert ???und dass die Broadcast Domains nicht zu groß werden sollen.
Das ist das 1 mal 1 des Netzwerkdesigns, diese Regel gabs schon unter IPv4.
Nur zur Info, ich hab die kleinstmögliche Größe (/64) für jedes Vlan genommen.Zudem versuchst du ein Problem auf eine Art zu erschlagen (IP Blocken) die vorher schon nicht wirklich sinnvoll war (bei v4 vergibt man sich einfach ne andere IP - done
Dafür müsste er eine IP wissen, die nicht beblockt ist. Das ist ihnen bis jetzt nicht gelungen. Dank YT werden immer nur 192.168.x.x/24 Beispiele gezeigt und da ich ein Class B Netz habe und meine Kidds IP Subnet nicht verstanden haben, hat es bereits einige unterhaltsame Momente gegeben.
Fazit:
Also wenn ich dich jetzt richtig verstanden habe, ist dein Vorschlag, IP Generell zu blocken und über Captive Portal freizuschalten. :-
Nunja, Sicherheit und Komfort beissen sich halt, aber das wusste ich bereits vorher.Trotzdem Danke
-
verschleudern wir Diese jetzt als wären sie unendlich verfügbar.
Alleine für ein Tranfernetz wird bereits ein /64er Prefix verballert ???Es wird nichts "verballert", deshalb auch meine Aussage - die nicht böse gemeint war - du mögest dich ggf. erstmal mehr mit IPv6 beschäftigen. Dass hier auch für Transfernetze etc. /64 gesetzt werden ist zum einen im RFC und von den Agenturen wie RIPE etc. vorgegeben, zum anderen hat es was damit zu tun, dass /64 die kleinste Größe ist, bei der alle v6 Mechanismen entsprechend sauber automatisch funktionieren wie bspw. SLAAC und Co. Zudem kann und wird bei einigen Geräten zur weiteren Beschleunigung und Vereinfachung einiges in Hardware abgebildet und berechnet (ASICs) und auch hier ist das der restliche 64bit Teil. Kleinere Größen würden hier nur noch manuell funktionieren und könnten dann auch wieder nur umständlich in Hardware abgebildet werden. Zudem brauchen IPv6 Routen entsprechend wesentlich mehr RAM als die v4 Pendants, mit entsprechend viel mehr kleineren Subnetzen würde also auch der Speicherbedarf für Routing Tabellen und Co enorm ansteigen.
Eigenes Prefix bedeutet anderes (V)LAN, oder irre ich mich ? Das ist ja wie durch die Brust ins Auge.
Warum ist das durch die Brust ins Auge? :o Es ist die sinnvollste Möglichkeit das sauber zu lösen und nicht mit künstlichen IP Sperren zu hantieren, die dann manuell durch Vergabe von anderer IP ausgehebelt werden können.
Ich glaube schon dass ich IPv6 im Groben verstanden habe, nur bin ich mit dieser Philosophie nicht einverstanden. Das ist ein Unterschied.
Es ist keine Philosophie. Es ist ein Protokoll das komplett und komplex durchgestaltet und geplant wurde und immer weiter auch aktuell angepasst wird. Genau wie v4 sich auch mehrfach entwickelt hat :)
Das hat nichts mit theoretischer Philosophie zu tun. Das wurde durchaus sinnvoll durchgerechnet und mit entsprechender Luft nach oben auch begonnen um eben genau nicht wieder dumm dazustehen und keine Adressen mehr zu haben. Nur weil es im ersten Moment jetzt so aussieht, dass zu viele Adressen ausgegeben werden, heißt das nicht, dass die uns wieder ausgehen werden oder die Vergabe zu großzügig ist. Vor allem wenn man überlegt, dass momentan ja sowieso nur 2001:: vergeben wird. Da kratzen wir die anderen /3 oder /4 Netze ja noch nicht mal an…Das ist das 1 mal 1 des Netzwerkdesigns, diese Regel gabs schon unter IPv4.
Mag sein, bei v6 aber wird explizit auch in Bezug auf Security und Co darauf hingewiesen, dass hier die BC Domains so klein als sinnvoll möglich gestaltet werden sollen. Gerade da eben viel automatisch und automatisiert ablaufen kann (und darf oder auch soll), will man hier die Angriffsfläche bzw. den Impact minimieren, wenn jemand Mist baut und bspw. das ND oder RA versaut.
Nur zur Info, ich hab die kleinstmögliche Größe (/64) für jedes Vlan genommen.
Das doch gut :) So solls ja auch gemacht werden.
und meine Kidds IP Subnet nicht verstanden haben, hat es bereits einige unterhaltsame Momente gegeben.
:) auch nicht schlecht. Aber trotzdem geht das schneller als du denkst, dass das kein Problem mehr ist. Und warum überhaupt dann erst eine Methode nutzen, die per se schon eher ungeeignet ist, anstatt etwas zu verwenden, was besser auf deinen Fall passt? Portal oder Mac Auth wäre da doch einfacher weil nicht so leicht umgehbar. Es gibt ja auch (hörensagen) schon recht günstig Switche die 802.1x können.
EDIT:
Weils mir gerade noch zugeflogen kam:
http://etherealmind.com/allocating-64-wasteful-ipv6-not/Ein Zitat und eine gute kurze Zusammenfassung warum /64:
Using a subnet prefix length other than a /64 will break many features of IPv6, amongst other things Neighbor Discovery (ND), Secure Neighborship Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], PIM-SM with Embedded-RP [RFC3956], and SHIM6 [SHIM6]. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes. -
Eigenes Prefix bedeutet anderes (V)LAN, oder irre ich mich ? Das ist ja wie durch die Brust ins Auge.
Warum ist das durch die Brust ins Auge? :o Es ist die sinnvollste Möglichkeit das sauber zu lösen und nicht mit künstlichen IP Sperren zu hantieren, die dann manuell durch Vergabe von anderer IP ausgehebelt werden können.
Da ich für 4 Geräte ein eigenes Vlan bzw. L3 Instanz bauen muss. Etwas oversized in meinen Augen, wohl aber notwending, so wie es aussieht :/
Ich muss mich jetzt erstmal entscheiden ob ich IPv6 abschalte, oder mir einen Multi-SSID AP bestelle.
Achso, noch ne Sache zum Captive Portal.
Das können wir in Verbindung mit ipv6 wohl vergessen, da es ipv6 nicht unterstützt…
https://forum.pfsense.org/index.php?topic=125146.0
Gruß
Rubinho -
Autsch! OK danke, war mir in diesem Zusammenhang nicht bekannt (dazu benutze ich CP viel zu wenig), aber das macht es natürlich unbrauchbar :/
BTW MultiSSID AP -> Die UniFy Teile kosten ja jetzt nicht soo viel und können das (und noch mehr). Alternativ wie gesagt vielleicht ein Switch mit 802.1x Auth - wäre auch spannend :)
-
BTW MultiSSID AP -> Die UniFy Teile kosten ja jetzt nicht soo viel und können das (und noch mehr). Alternativ wie gesagt vielleicht ein Switch mit 802.1x Auth - wäre auch spannend :)
Meinst du die Ubiquiti Unifi APs ?
Wenn ja, die Dinger sind wirklich preiswert, habe von Ubiquiti 3 Richtfunkstrecken in Betrieb und die laufen völlig problemlos.Bei dem Thema 802.1x ist der Aufwand wieder recht hoch. Ich müsste jedem Client erstmal ein Zertifikat zuweisen. Spannend ja, aber wie gesagt, recht aufwendig.
Ich hab da noch einen alten TP-Link AP rumfliegen, der mit einer OpenWRT Firmware bespaßt ist. Mit dem werde ich mal eine Multi-SSID Testumgebung aufbauen.
