ernsthaftes IPv6-Freigabeproblem seit der FW 6.8x

[dg2dra]

Hallo Community, ich stelle hier mal ein Problem dar , das ich seit der FW 6.8x bei der 7490 reproduzierbar erkannt habe. Das IPv6-Netz ist hier für die Darstellung/Erklärung modifiziert.

[FONT=&amp]Ausgangspunkt: WINDOWS SERVER 2012 mit statischer Ipv6, DNS und DHCP (sowohl IPv4 als auch IPv6) durch diesen Server (nicht die Fritzbox), 6in4 Tunnel bei Hurrican mit IPv6-Präfix 2001:472:2f0b:112c::/64, MTU 1280
[/FONT]

[FONT=&amp]Einstellungen der Fritzbox unter „IPv6-Adressen“:[/FONT]
[FONT=&amp]Unique Local Addresses (ULA) zuweisen, solange keine IPv6-Internetverbindung besteht (empfohlen)[/FONT]
[FONT=&amp]Diese FRITZ!Box stellt den Standard-Internetzugang zur Verfügung, Präferenz des Router Advertisement Mittel[/FONT]
[FONT=&amp]DNSv6-Server auch über Router Advertisement bekanntgeben (RFC 5006) ist DEAKTIVIERT[/FONT]
[FONT=&amp]DHCPv6-Server in der FRITZ!Box deaktivieren: Das M- und das O-Flag in den Router Advertisement-Nachrichten der FRITZ!Box aktivieren (SLAAC nicht möglich). (3.Option) – weil „können ihre IPv6-Adresse von einem anderen im Heimnetz vorhandenen DHCPv6-Server beziehen“ wäre genau zutreffend bei mir, weil macht ja alles der 2012er Server. Auch der DHCP-Server der Box ist DEAKTIVIERT.[/FONT]

[FONT=&amp]Hier ein Auszug aus „ipconfig /all“ bei WINDOWS SERVER 2012:[/FONT]

[FONT=&amp]Windows-IP-Konfiguration[/FONT]

[FONT=&amp] Hostname . . . . . . . . . . . . : SRV2012[/FONT]
[FONT=&amp] Primäres DNS-Suffix . . . . . . . : it-svc.local[/FONT]
[FONT=&amp] Knotentyp . . . . . . . . . . . . : Hybrid[/FONT]
[FONT=&amp] IP-Routing aktiviert . . . . . . : Nein[/FONT]
[FONT=&amp] WINS-Proxy aktiviert . . . . . . : Nein[/FONT]
[FONT=&amp] DNS-Suffixsuchliste . . . . . . . : it-svc.local[/FONT]

[FONT=&amp]Ethernet-Adapter VM-Ethernet:[/FONT]

[FONT=&amp] Verbindungsspezifisches DNS-Suffix:[/FONT]
[FONT=&amp] Beschreibung. . . . . . . . . . . : vmxnet3 Ethernet Adapter[/FONT]
[FONT=&amp] Physische Adresse . . . . . . . . : 00-0C-29-B3-C5-99[/FONT]
[FONT=&amp] DHCP aktiviert. . . . . . . . . . : Nein[/FONT]
[FONT=&amp] Autokonfiguration aktiviert . . . : Ja[/FONT]
[FONT=&amp] IPv6-Adresse. . . . . . . . . . . : [/FONT][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT]::8(Bevorzugt)[/FONT]

[FONT=&amp] Verbindungslokale IPv6-Adresse . : fe80::20c:29ff:feb3:c599%12(Bevorzugt)[/FONT]
[FONT=&amp] IPv4-Adresse . . . . . . . . . . : 192.168.253.8(Bevorzugt)[/FONT]
[FONT=&amp] Subnetzmaske . . . . . . . . . . : 255.255.255.0[/FONT]
[FONT=&amp] Standardgateway . . . . . . . . . : [/FONT][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT]:a96:d7ff:fee3:32c8[/FONT]

[FONT=&amp] 192.168.253.1[/FONT]
[FONT=&amp] DNS-Server . . . . . . . . . . . : [/FONT][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT]::8[/FONT]

[FONT=&amp] ::1[/FONT]
[FONT=&amp] 192.168.253.8[/FONT]
[FONT=&amp] 127.0.0.1[/FONT]
[FONT=&amp] Primärer WINS-Server. . . . . . . : 192.168.253.8[/FONT]
[FONT=&amp] Sekundärer WINS-Server. . . . . . : 127.0.0.1[/FONT]
[FONT=&amp] NetBIOS über TCP/IP . . . . . . . : Aktiviert[/FONT]


[FONT=&amp]So, jetzt die IPv6-Adressen, die die 7490 meint an diesem Gerät SRV2012 erkannt zu haben (Heimnetzübersicht>SRV2012>Details unter IPv6-Adressen (4 Stück, ist aber FALSCH):[/FONT]
[FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT]::8 -> richtige Adresse
fe80::20c:29ff:feb3:c599 -> richtige LinkLocal Adresse
fe80::560:4e9b:1a34:ee2d -> [/FONT][FONT=&amp]falsch, gibt’s nicht siehe oben[/FONT][FONT=&amp]
[/FONT][FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT]:20c:29ff:feb3:c599 -> [/FONT][FONT=&amp]falsch, gibt’s auch nicht, wird wohl einfach mal so aus dem Subnetzanteil und der MAC-Adresse gebildet ohne jede Grundlage (MAC-Adresse Server/Netzwerkkarte 00:0C:29:B3:C5:99)[/FONT]




[FONT=&amp]Weiter im Text:[/FONT]
[FONT=&amp]Gerät unter Portfreigaben hinzugefügt, als IPv6 Interface-ID wird immer eine die Interface-ID der LinkLocal-Adresse angezeigt, nun gut, ändere ich auf ::0:0:0:8 und mache die IPv6 Freigaben. Das funktioniert auch für eine gewisse Zeit, dann passiert folgendes im Ereignisprotokoll OHNE ZUTUN:[/FONT]
[FONT=&amp]Freigabe für Ping6 auf [/FONT][FONT=&amp][FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT][/FONT]::8 (SRV2012) entfernt.[/FONT]

[FONT=&amp]Freigabe für Port 443 auf [/FONT][FONT=&amp][FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT][/FONT]::8 (SRV2012) entfernt.[/FONT]


[FONT=&amp]Und weiter:[/FONT]
[FONT=&amp]Freigabe für Ping6 auf [/FONT][FONT=&amp][FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT][/FONT]:20c:29ff:feb3:c599 (SRV2012) hinzugefügt.[/FONT]

[FONT=&amp]Freigabe für Port 443 auf [/FONT][FONT=&amp][FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT][/FONT]:20c:29ff:feb3:c599 (SRV2012) hinzugefügt. [/FONT][FONT=&amp]-> NICHT NACHVOLLZIEHBAR ![/FONT]


[FONT=&amp]EINFACH SO MAL EINE ANDERE FREIGABE auf eine IPv6, [/FONT][FONT=&amp]DIE ES GAR NICHT GIBT[/FONT][FONT=&amp] ABER DEN PORT ÖFFNET ![/FONT]

[FONT=&amp]
[/FONT]
[FONT=&amp]Scanne ich das Netzwerk mittels NDP wird der Server mit der korrekten IPv6 angezeigt, ich frage ich ernsthaft, wie die Box zu den zusätzlichen Adressen kommt.[/FONT]

[FONT=&amp]Das ist definitiv inakzeptabel und auch ein echtes Sicherheitsproblem, wenn ich nicht vorhersehen kann, was die Box so meint öffnen zu müssen. Nach meiner Ansicht hat das schon den Status CRITICAL.[/FONT]
[FONT=&amp]Das Problem IST bei mir REPRODUZIERBAR auf 3 verschiedenen 7490 seit FW 6.8x, bis zur 6.60 TRAT DAS NICHT AUF (gabs ja auch ein anderes Freigabe-Konzept).[/FONT]

[FONT=&amp]
Vielleicht kann das auch mal jemand nachstellen, falls er die entsprechende Infrastuktur zur Verfügung hat.

Gruss Heiko
[/FONT]

 

[PeterPawn]

Da Du vermutlich beim Test mit drei verschiedenen 7490 nicht jedesmal die Konfiguration von Grund auf neu gemacht haben wirst und wahrscheinlich eher eine Sicherungsdatei importiert hast, stelle ich einfach mal die Frage, ob Du das betreffende Gerät mal komplett aus der FRITZ!Box gelöscht hast (dazu darf es keine aktive Portfreigabe haben und auch nicht gerade "sichtbar" sein) und im Anschluß ggf. sogar noch die Liste der Netzwerkgeräte hast aufräumen lassen.

Dann das Gerät noch einmal "sauber" einrichten lassen (es wird der FRITZ!Box am ehesten "bekannt" - solange die keinen DHCP-Server bereitstellt -, wenn man vom Gerät irgendwie auf Layer 3 und darüber auf die FRITZ!Box selbst zugreift; sie also nicht nur als Router benutzt) und abwarten, ob das Problem erneut auftritt.

Gerade so eine ältere (link-lokale) Adresse, die es gar nicht (mehr) gibt, würde ich auf Überreste des Gerätes in der "landevices"-Sektion der "ar7.cfg" zurückführen, die dann munter mit neuen, aktuelleren "Erkenntnissen" vermischt werden, wenn es wieder einmal Zeit für die Erneuerung einer Weiterleitung per PCP ist.

 

[koyaanisqatsi]

:!:

Überreste des Gerätes in der "landevices"-Sektion der "ar7.cfg"

Plattmachen = Fritz!Box separieren und ihr neue IP geben, bei Bedarf dann alte IP vergeben.
(Separieren: Mit nur einem Gerät verbinden, zb: 169.254.1.2)

 

[dg2dra]

Aktiv hatte ich das in den letzen drei Tagen mit 2 verschiedenen 7490, FW 6.83, getestet. Beide Boxen hatte ich mittels recovery auf die 6.83 komplett plattgemacht und von grundauf manuell neu eingerichtet, es wurden KEINE Konfigs hin und hergespielt (um eben Reste durch Übernahme zu vermeiden). Ergänzend muss ich auch anfügen, das die zweite Box zwar ebenfalls einen IPv6-Tunnel bei HE hat, dort auch ein 2012er Server mit fester IPv6 läuft, aber an der zweiten Box DNS und DHCP für IPv6 durch die Box selbst realisiert wird, im Gegensatz zu meinem obigen Beispiel der Box Nr.1. Fakt ist, es treten bei beiden Konstellationen prinzipiell die gleichen Effekte auf hinsichtlich der IPv6-Freigaben, deswegen sagte ich auch es ist reproduzierbar, trotz anderer Netzwerkkonstellation. Das kann ich m.E. nicht auf Zufall schieben, sondern liegt nach meiner Meinung in der FW der Box selbst. Diesen Effekt hatte ich zuerst in den Labors bereits nach der 6.60 bemerkt und war umso mehr erstaunt, dass das in den FINALS 6.80/6.83 immer noch genauso problematisch ist und sich nicht geändert hat. Es kann einfach nicht angehen, das ich eine Freigabe, deren Interface-ID ich manuell vergebe, durch die Box einfach gelöscht und durch eine andere ersetzt wird. Das ist zu 100% inakzeptabel und muss gefixt werden. In einem Fall habe ich das im Übrigen auch bei einer IPv4-Freigabe bemerkt: Es stand ein Gerät in der Netzwerkübersicht mit NAS1 drin. Als ich dieses Gerät in den Freigaben hinzugefügt habe, auch NAS1 als Bezeichnung auswählte, änderte die Box auf einmal den Namen auf PC-192-168-254-4 (obwohl NAS1 angezeigt wurde!). Ok dachte ich, IPv4 Freigaben gemacht, ging. Einige Stunden später auf einmal diese Freigaben auch weg, Protokoll sagte wieder:
[FONT=&amp]Freigabe für Port 443 auf [/FONT][FONT=&amp][FONT=&amp][FONT=&amp][FONT=&amp]192.168.254.4[/FONT][/FONT][/FONT] ([/FONT][FONT=&amp]PC-192-168-254-4) entfernt.

Einfach so. Es tut mir leid, das sind eindeutig zu viele Zufälle, um das auf fehlerhafte oder falsch übernommene Konfigs zu schieben. Ich behaupte, es gibt hier ein grundlegendes Problem, wie die Box seit der 6.8x Freigaben behandelt. Es ist inzwischen zu stark automatisiert und führt an verschiedenen Stellen zu Fehlinterpretationen durch die Box bzw. deren Konzept in der FW. Bleibt das so, muss ich mich von den FBs trennen und andere Router einsetzen. So wie jetzt kanns jedenfalls nicht bleiben. Ich sehe das auch durchaus als ein ernsthaftes und kritisches Sicherheitsproblem, wenn sich ein Router bei Portfreigaben auf einmal "verselbstständigt". Bis inkl. der FW 6.60 war das wirklich ok, es gab keine solchen Effekte.

Gruss Heiko
[/FONT]

 

[PeterPawn]

Dann stelle halt mal die Ausgabe von "showpcpinfo" vor (findet sich auch in den Support-Daten) - einmal die "richtigen" und einmal den fehlerhaften Zustand, aber von derselben Box und aus demselben "Lauf" des Systems -, damit man sehen kann, ob es tatsächlich nur die interne Verwaltung und regelmäßige Erneuerung der PCP-Freigaben ist, die da schiefgeht oder ob nicht doch irgendein Client im LAN sich an der PCP-Steuerung versucht und damit das Chaos auslöst.

Ich kann das hier jedenfalls nicht nachstellen - habe aber auch nur ein älteres iPad als IPv6-Client hergenommen und den dort laufenden SSH-Dienst (somit auch nur einen einzelnen Service) mal testweise per IPv6 (obendrein nur per 6to4 für meine feste IPv4-Adresse) freigegeben. Das läuft seit dem 27.03.2017 stabil, als ich hier gelesen hatte, daß es ein Problem mit der Langzeitstabilität von Freigaben geben würde. Bei der täglichen "Zwangseinwahl" (ich habe noch einen T-DSL-Business mit Zwangstrennung nach 24 Stunden trotz fester IP) wird auch diese Freigabe regelmäßig (automatisch) neu eingerichtet, wie man im PCP-Log sehen kann.

Ich hatte das an anderer Stelle bereits einmal "ausgeführt" ... die PCP-Freigaben haben alle nur eine begrenzte "Lebensdauer" (sieht man auch in der o.a. Ausgabe) und für die Freigaben, die man statisch über das FRITZ!Box-GUI einstellt (und die ein LAN-Client mit PCP-Client eben nicht selbst anfordert und erneuert), sind verschiedene Prozesse im FRITZ!OS dafür verantwortlich (so jedenfalls meine Interpretation der verschiedenen "Abschnitte" mit den entsprechenden Daemons), diese Freigaben (inkl. der auf die Box selbst) zu verwalten und dazu gehört auch deren zyklische Erneuerung.

Nun habe ich selbst nur ein sehr einfaches Szenario nachgestellt ... aber bei mir klappt das eben. Es wäre ja tatsächlich nicht ausgeschlossen, daß irgendwann mal für eine Komponente so ein Trigger zur Erneuerung unter die Räder kommt (erst recht dann, wenn es wg. fehlender Zwangstrennung gar keine "regelmäßigen" Ereignisse gibt) und dann nicht rechtzeitig die Verlängerung "beantragt" wird - in der Folge fällt diese Freigabe weg (das macht der "pcpd" dann autonom) und irgendwann merkt eine Komponente dann beim Zählen der Häupter ihrer Lieben, daß da irgendetwas fehlt und richtet das neu ein.

Es wäre natürlich auch hier wieder denkbar, daß bei diesem (sicherlich eher seltenen) Problem des nachträglichen Neueinrichtens wg. verpaßter Verlängerung tatsächlich noch Fehler enthalten sind (da kann dann z.B. (rein theoretisch, ich kenne den AVM-Code auch nicht) ein "off by one" auch schon mal dazu führen, daß eine "fremde" IPv6-Adresse dem falschen Gerät zugeordnet wird - wobei das freie "Erfinden" so einer Adresse eher unwahrscheinlich ist, da müßte schon sehr viel durcheinandergeraten und daß das dann zufälligerweise auch noch eine link-lokale IPv6-Adresse ergibt, klingt zumindest befremdlich) ... aber die erste Voraussetzung für eine Reproduktion wäre hier dann wohl ein solches "Versäumnis" - schon das tritt bei mir nicht auf (womit dann das beschriebene Problem sicherlich für den Betroffenen belastend ist - es ist aber wohl nicht "allgemeingültig" und von der passenden Konfiguration abhängig).

Ehe man also nur "rät", was da nun passieren mag, sollte man vielleicht wirklich mal einen Blick in die Protokolle des "pcpd" werfen ... auch das Problem mit der zusätzlichen IPv6-Adresse würde ich (zumindest als Test) mal anders angehen. Man sieht ja in der gezeigten Windows-Konfiguration, daß der Windows-Server mit der TLD "local" arbeitet (also wohl auch der DHCP- und DNS-Server) - diese ist aber (mehr oder weniger) für mDNS reserviert und auch ohne DHCP-Server läuft natürlich auf der FRITZ!Box ein "multid" (mindestens als DNS), der sich seine Informationen zu den Geräten im Netzwerk auch aus mDNS-Annoucements zusammensucht. Um hier die verwendete TLD als mögliche Ursache auszuschließen (daß der "multid" (unsaubererweise in meinen Augen und mit weiteren Konsequenzen für die Sicherheit im LAN) die verschiedenen Namensräume von DNS und mDNS zusammenwirft, ist auch bekannt), würde ich mal auf eine andere lokale TLD umstellen. Schließlich zählt der "multid" auch zu den Komponenten im FRITZ!OS, die mit dem PCP-Daemon in Fragen der Freigaben kommunizieren bzw. anderen Komponenten die Informationen zu den Netzwerkadressen von LAN-Clients liefern.

 

[Captain-S]

Probleme mit IPv6 treten nicht nur bei der 7490 auf, sondern auch bei der 7580.
Die Fehler wirken sich hier evtl. anders aus, aber das IPv6 abschalten hilft zumindest bei der 7580.
Da hat AVM gewaltig Mist gebaut.

 

[PeterPawn]

Da hat AVM gewaltig Mist gebaut.

Das ist zwar auch nicht generell auszuschließen, aber "Probleme mit IPv6" sind nun auch keine präzise Beschreibung und auch dieser "generelle Tipp", einfach IPv6 abzuschalten, liest sich bei AVM schon wieder ganz anders: https://avm.de/service/fritzbox/fri...funktionieren-nach-FRITZ-OS-Update-nicht-mehr - da wird tatsächlich ein Fehler "eingestanden", aber eben mit dem genau entgegengesetzten Workaround. Eine aktivierte IPv6-Konfiguration schadet der Funktion jetzt nicht wirklich, wenn der Provider kein IPv6 anbietet ... außerdem soll man ja (lt. AVM-KB) ohnehin auf einen 6to4-Tunnel schalten - was wieder dafür sprechen würde, daß das ganze Thema eben mit nativer IPv6-Unterstützung oder bei bestimmten Tunnel-Lösungen durchaus sauber arbeitet und nur andere Tunnel-Lösungen von einem Problem betroffen sind.

Meines Erachtens funktioniert nun endlich (seit 06.8x) die korrekte "Freigabe" (es geht ja eigentlich nur darum, dort eingehenden Verkehr nicht zu blockieren) für ein Segment mit einem delegierten IPv6-Präfix (u.a. auch für eine FRITZ!Box-Kaskade) - die Konstellation mit einem einzelnen Rechner mit statischer IPv6-Adresse, die obendrein gar nicht von der FRITZ!Box "verwaltet" wird und nur dann sinnvoll zu erreichen ist, wenn die Box den HE-Tunnel erfolgreich installiert hat (wo also der betreffende Server den Tunnel gar nicht selbst betreibt), der dann auch noch eine solche dauerhafte Freigabe kriegt, ist sicherlich schon etwas speziell. Obwohl das ja der Beschreibung nach auch dann nicht funktionieren soll, wenn die FRITZ!Box (allerdings wohl wieder mit HE-Tunnel) den DHCP-Server gibt (auch DHCPv6?) - wobei das bei ebenfalls statischer IPv6-Adresse des LAN-Clients ja auch nicht unbedingt eine Rolle spielt.

Es gibt aber auch so viele andere Konstellationen, die m.W. mit einer FRITZ!Box nicht funktionieren (z.B. die statische Delegierung eines kompletten IPv6-Subnetzes (aka IPv6-Präfix) an so einen Server ist wohl nirgendwo einzustellen, jedenfalls nicht so, daß die Box dann entsprechende Pakete passieren läßt - das klappt wohl nur, wenn die Box den Präfix auch selbst "delegiert" hat) und soviele "Kombinationsmöglichkeiten" (von "SLAAC" bis "Tunnel oder native"), daß man sich schon sehr bemühen muß, da wirklich alle Kombinationen auch zu "erwischen" bei entsprechenden Tests. Manchmal werden ja auch "liebgewordene Macken" als Workaround benutzt und wenn die dann als Problem erkannt und beseitigt werden, geht eben irgendetwas anderes, was bisher auf diese Umgehungslösung setzte, dann nicht mehr.

Der Betrieb eines eigenen Servers (und dafür ist hier sicherlich die statische IPv6-Adresse erforderlich, ggf. in Kombination mit einem passenden (externen) DNS-Server) hinter einem HE-Tunnel, der aber von einem ganz anderen Router bereitgestellt wird, der nun seinerseits noch die Aufgabe der "1st line of defense" übernimmt und eine Firewall anbietet, die für den Betrieb dieses Servers entsprechend konfiguriert werden muß, hat eben mit den "bread&butter"-Problemen eines Consumer-Gerätes nur noch sehr am Rande zu tun.

Ein solches muß eben (damit es auch in einem Haushalt ordnungsgemäß arbeitet, der sich viel stärker auf das "automatische Funktionieren" seines Border-Routers (als IAD) verläßt) auch versuchen, gewisse Anteile der Konfiguration automatisch zu erkennen und vorzunehmen; manchmal läuft das dann auch gegen den Willen des Besitzers. Es ist eben nicht ohne weiteres festzustellen, ob der tatsächlich weiß, was er da gerade konfiguriert und seinerseits die entsprechenden, flankierenden Maßnahmen ergreift (hier z.B. die Konfiguration der statischen IPv6-Adresse, die von der Interface-ID nach "FRITZ!Box-Geschmack" abweicht, auf dem LAN-Client) oder ob das einfach nur ein unbeholfener Benutzer ist, der z.B. auf sein NAS daheim auch vom Smartphone unterwegs per IPv6 zugreifen will - dann greift man dem wohl besser unter die Arme und richtet ihm (mit der richtigen Interface-ID und über den MyFRITZ!-Service) einen solchen Zugang ein.

Man muß auch bei seinen Ansprüchen immer im Auge behalten, an wen sich so ein Gerät (in der Breite) nun richtet ... wer etwas Besseres (auch besser/ausgefeilter zu konfigurieren) haben will, muß dann eben ein anderes Gerät wählen und i.d.R. auch tiefer in die Tasche greifen. Ich weiß aktuell gar nicht, wie weit die Einstellmöglichkeiten bei einem Speedport-Router z.B. gingen ... aber wenn der gar keine IPv6-Freigaben oder gar Tunnel-Benutzungen bieten sollte (trotz genereller IPv6-Unterstützung), wird ja auch niemand aufstehen und sich darüber erregen, daß dort eine ähnliche Konstellation ggf. auch nicht funktioniert.

Wie gesagt, die Permutationsmöglichkeiten bei einer IPv6-Konfiguration sind so groß, daß da schon mal etwas durcheinandergeraten kann und daß AVM hier mit der Einführung von PCP eine Renovierung "von Grund auf" ausgeführt hat (die durchaus im Interesse von Kunden an DS-Lite-Anschlüssen wäre, wenn deren Provider dann auch PCP unterstützt), ist sicherlich auch unstrittig.

Wenn da noch nicht alle denkbaren Kombinationen auf Anhieb funktionieren, ist das in meinen Augen eine "lässliche Sünde" ... solange entsprechende Updates mit einer Fehlerkorrektur nicht zu lange auf sich warten lassen. Wobei ich mir auch hier wieder nicht sicher bin, wieweit die "zugesicherten Eigenschaften" im Hinblick auf IPv6-Unterstützung nun wirklich gehen ... gehört da tatsächlich das reibungslose Funktionieren der Freigabe einer statischen IPv6-Adresse für einen LAN-Client unter Benutzung eines 6in4-Tunnels über HE zu dem Funktionsumfang, den man (normalerweise) von so einem Consumer-Gerät erwarten darf? Die Antwort auf diese Frage ist sicherlich auch wichtig, wenn man die Dringlichkeit eines solchen Updates einschätzen will - ich persönlich (aus meiner eigenen Sicht halt, so wie es wohl jeder andere auch aus seiner Warte beurteilt) hätte da noch ein paar andere Gründe bzw. Stellen, an denen ein (Security-)Update viel dringender wäre.

 

[Pom-Fritz!]

Heute im Laufe des Tages sind meine IPv6 Einträge auch hoch gelaufen:



Heute morgen waren es noch 3 - jetzt sind es 6. Die ersten 3 sind tatsächlich laut ipconfig in meinem PC vergeben. Die anderen 3 sind die alten temporären IPv6-Adressen von heute morgen. Anpingen kann ich nur die ersten 3.

Edit: 2.4.2017

Hier die Life Time der temporären IPv6 Adressen unter Windows 10.



Heute, nach Windows Start, stehen wieder nur die 3 IPv6 Adressen für den PC in der Fritzbox, die auch mit "ipconfig" unter Windows ausgelesen werden können. Der Zeitintervall für das tatsächliche Wechseln der temp. IPv6 muss aber bei 2-3 Std (geschätzt) liegen.

 

[Bonsai Baum]

[FONT=&amp]So, jetzt die IPv6-Adressen, die die 7490 meint an diesem Gerät SRV2012 erkannt zu haben (Heimnetzübersicht>SRV2012>Details unter IPv6-Adressen (4 Stück, ist aber FALSCH):[/FONT]
[FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT]::8 -> richtige Adresse
fe80::20c:29ff:feb3:c599 -> richtige LinkLocal Adresse
fe80::560:4e9b:1a34:ee2d -> [/FONT][FONT=&amp]falsch, gibt’s nicht siehe oben[/FONT][FONT=&amp]
[/FONT][FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT]:20c:29ff:feb3:c599 -> [/FONT][FONT=&amp]falsch, gibt’s auch nicht, wird wohl einfach mal so aus dem Subnetzanteil und der MAC-Adresse gebildet ohne jede Grundlage (MAC-Adresse Server/Netzwerkkarte 00:0C:29:B3:C5:99)[/FONT][FONT=&amp]
[/FONT]

Verstehe Dein Problem in Teilen gar nicht.
Die Adresse [FONT=&amp]fe80::20c:29ff:feb3:c599 generiert sich das Interface als linklokale IPv6 automatisch (die hinteren 64 Bit ist ein sogenannter Interfaceidentifier,[FONT=&amp] und der kann vom Gerät selbst per modifiziertem Extended Unique Identifier (EUI-64) eindeutig festgelegt werden[/FONT]. Grundlage für den automatisch festgelegten Interface-Identifier ist die MAC-Adresse, die allerdings nur 48 Bit lang ist. Sie muss also mit 16 Bit zu dem 64 Bit langen Interfaceidentifier aufgefüllt werden. Dazu wird die MAC in der Mitte geteilt - in den vorderen Hersteller spezifischen Teil (OUI - Organizationally Unique Identifier) und den hinteren Netzwerkkarten (NIC) spezifischen Teil. Zwischen diese 24 Bitt langen Blöcken wird nun 0xFFFE eingefügt und das siebte Bit von links invertiert, um einen Interface Identifier im modified 64-bit EUI Format zu bekommen (also <OUI>FFFE<NIC> ). Hier kann man das nochmals anschaulich sehen.). Im Gegensatz zu händisch selbst gewählten Geräteidentifiern ist die EUI-64 global gültig.
Und wenn das derzeitig global gültige Präfix [FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT]: ist, dann erreichst Du das Interface des Servers - unabhängig von einem händisch konfigurierten Interface-Identifier - immer auch über die IPv6 aus Präfix plus [FONT=&amp]modifiziertem Extended Unique Identifier... - d.h. diese gibt's sehr wohl, und zwar immer.[/FONT][/FONT][/FONT]

 

[dg2dra]

Erst mal danke für die sehr interessanten Antworten, ich antworte morgen im Laufe des Tages ausführlich, auch muss ich die von der FB generierten Log-/Supportdaten noch sichten und für hier etwas aufbereiten.

PeterPawn: "den man (normalerweise) von so einem Consumer-Gerät erwarten darf?"

Aber ohne wenn und aber erwarte ich als Kunde vom Hersteller, eine IPv6-Funktionalität (mit der er auch wirbt) die den Namen auch verdient, egal wie ich meine IPv6-Anbindung so umsetze. DAS WIE entscheide ICH und nicht der Hersteller. Da kann ich diesem nicht einen Millimeter entgegenkommen. Entweder ich kann IPv6 mit meinem Router oder nicht. Dazwischen gibts keinen Spielraum. Und die Einteilung in "Consumer, Prosumer, Professional" ist sowas von daneben und wird nur dazu genutzt, nicht umgesetzte Funktionen als nicht "der Zielgruppe entsprechend erforderlich" zu verschleiern oder eben wegzulassen.

Bonsai Baum: "Und wenn das derzeitig global gültige Präfix 2001:472:2f0b:112c: ist, dann erreichst Du das Interface des Servers - unabhängig von einem händisch konfigurierten Interface-Identifier - immer auch über die IPv6 aus Präfix plus modifiziertem Extended Unique Identifier... - d.h. diese gibt's sehr wohl, und zwar immer." NEIN, meine Server sind unter diesen Adressen nicht erreichbar und diese sind nicht zugewiesen. Mehr dazu morgen...

"fe80::20c:29ff:feb3:c599 generiert sich das Interface als linklokale IPv6 automatisch"
völlig klar und richtige IP, diese wurde ja auch korrekt erkannt und war nicht zu kritisieren/beanstanden, hat die FB ja auch korrekt erkannt. Aber es ging um die "fe80::560:4e9b:1a34:ee2d" und diese gabs und gibts nun mal nicht. Also woher hat die Box diese IP ??!?

Gruss Heiko

 

[PeterPawn]

eine IPv6-Funktionalität (mit der er auch wirbt)

Da ich eine solche Stelle nicht kenne, frage ich einfach einmal, wo man diese Werbung findet ... vielleicht kannst Du mir ja "auf die Sprünge helfen".

Zwar wird im Handbuch (nur dort kenne ich eine einzige Fundstelle) ausdrücklich erwähnt, daß man einen IPv6-Rechner im LAN freigeben kann (sogar, daß man denselben (externen) Port mehrfach freigeben kann, weil eine solche Freigabe bei IPv6 eben mit der "externen Adresse" arbeitet und die ist für jeden Client im LAN eindeutig und muß nicht über NAT geteilt werden wie bei IPv4), aber da steht nichts davon, daß das mit einer beliebigen Adresse, die sich der Client selbst aussucht, funktionieren würde und man die nun nur in der FRITZ!Box angeben müsse.

Ich weiß auch nicht, warum die Box irgendwann auf die EUI-64 "zurückfallen" will ... wenn sie das macht (warum steht vermutlich im bereits erwähnten Protokoll) und im Anschluß diese Adresse korrekt freigegeben ist, dann ist in meinen Augen die Aussage aus dem Handbuch erfüllt (und das ist auch noch nichts, was ich als "beworbene Eigenschaft" sehen würde, aber da mag man geteilter Meinung sein).

Und Deinem Standpunkt "Entweder ich kann IPv6 mit meinem Router oder nicht." mag ich mich auch nicht so richtig anschließen ... es ist eben schon ein gewaltiger Unterschied, wie genau ich ein Gerät mit IPv6-Unterstützung beim Internet-Zugriff tatsächlich "anbiete". Was die Box per IPv6 alles kann bzw. nach dem "Herstellerwillen" können soll, steht im 7490-Handbuch im Punkt 12.9 ab Seite 85 - wenn man den Standpunkt vertritt "IPv6 heißt, daß auch alles per IPv6 genauso geht, wie bei IPv4.", macht die Liste gar keinen wirklichen Sinn und daß es da in der Tat Unterschiede in den nutzbaren Funktionen in Abhängigkeit von der Variante des IP-Protokolls gibt, "weiß" der normale FRITZ!Box-Besitzer spätestens dann, wenn er auf der Basis von IPv6 eine IPSec-Verbindung mit seiner FRITZ!Box aufbauen will.

Auch die Tatsache, daß IPv6-Unterstützung nicht gleich IPv6-Unterstützung ist, ist lange bekannt und wenn ich mich richtig erinnere, hat z.B. die c't dem Thema vor nicht ganz einem Jahr mal einen recht ausführlichen Test gewidmet, wo auch die verschiedenen "Formen" und Feinheiten von IPv6-Unterstützung (link-lokal/ULA/global, Uni-/Any-/Multicast, Router-Kaskadierung, Präfix-Delegation, "Port"-Freigaben/Erreichbarkeit/Firewalls) verschiedener Geräte ausgiebig gewürdigt wurden und lange nicht jedes Gerät auch alles fehlerfrei und in vollem Umfang (wobei hier die Erwartungen ja auch unterschiedlich sind) abbilden konnte.

Da stehe ich also mit meiner Meinung, daß es sehr wohl einen Unterschied macht, in welche "Klasse" sich so ein Gerät nun einreihen will, auch nicht so ganz alleine - das bei Dir als Konsequenz im Raum stehende "jedes Gerät muß alles können" (aus dem letzten an mich gerichteten Satz) ist ja ganz offensichtlich eine ziemlich unmögliche (und eigentlich sogar unsinnige) Forderung. Jede zusätzliche Funktion (zumindest fast jede) erfordert für ihre Benutzung eine zusätzliche Konfigurationsmöglichkeit und daß mit steigender Komplexität der Konfiguration die "usability" und damit die Tauglichkeit als "Consumer-Gerät" abnimmt, ist auch kein großes Geheimnis oder gar eine "Verschleierung" des Unwillens, irgendwelche 1%-Funktionen zu implementieren (die also von max. 1% der Kunden genutzt würden).

Da muß man sich dann so eine Frage, wie ich sie gestellt habe, tatsächlich "gefallen" lassen - ich hätte auch gerne SNMP oder "remote syslog" in den DSL-Modellen und bin trotzdem durchaus in der Lage zu verstehen, daß das nur von sehr, sehr wenigen FRITZ!Box-Besitzern überhaupt genutzt werden könnte und würde. Wenn ich so etwas also brauche und will, muß ich es selbst machen oder eben zu einem anderen Gerät greifen - das gilt (mit kleinen Abstrichen) auch für die Möglichkeit, eine einzelne, fest angegebene IPv6-Adresse statisch freizugeben (wobei ja trotzdem von der Box erwartet wird, daß die den Präfix vor der Interface-ID selbst richtig setzt) ... selbst wenn das bisher vielleicht funktionierte (auch das war ja noch lange nicht immer so).

Ich bleibe also dabei, daß Deine Anforderung der Freigabe mit einer einzigen statisch zugewiesenen IPv6-Adresse (die auch noch eine "bestimmte" sein soll, warum eigentlich genau? Willst Du sie eintippen?) schon recht "speziell" ist. Selbst wenn es für irgendwelche Zwecke vielleicht notwendig sein sollte, daß man eine solche Adresse dem Windows-Server zusätzlich zuweist (weil vielleicht nur von dieser Adresse aus irgendwelche Dienste anderer Server zu nutzen wären - was ja aber auch ausgehend wäre und gar keine Freigabe braucht), gibt es für mich keinen nachvollziehbaren Grund (überrasche mich mit einem, ich bin lernfähig), warum man dann nicht einfach noch die EUI-64 auf dem Server konfiguriert und die Freigabe-Steuerung der FRITZ!Box über diese machen läßt. Erst dann, wenn es auch dabei zu den "Verwürfelungen" von IP-Adressen kommen sollte, dann sehe ich das ggf. auch als Problem. Wenn die FRITZ!Box die Vergabe einer manuell festgelegten "Interface-ID" gar nicht erst anbieten würde (wie es andere Geräte machen, siehe c't-Artikel), dann würde sich die Frage gar nicht erst stellen (zumindest nicht so).

Ob für diese Adressen aus #1 tatsächlich ein Forwarding im PCP eingerichtet wurde, ist ja ohnehin ungeklärt, solange Du das PCP-Log nicht eingesehen hast und für die "vollkommen falsche" link-lokale Adresse stellt sich die Frage der (unerwünschten) Freigabe ohnehin nicht - spätestens da fällt für mich das "CRITICAL" aus #1 dann auch in sich zusammen, denn die einzige "zusätzliche" freigegebene Adresse ist ja die aus #1, die Du mit dem Zusatz "falsch, gibt’s auch nicht" versehen hast. Das ist aber eben die EUI-64 in den hinteren 64 Bit der IPv6-Adresse und keinesfalls das, was Du mit Deinem

Das ist definitiv inakzeptabel und auch ein echtes Sicherheitsproblem, wenn ich nicht vorhersehen kann, was die Box so meint öffnen zu müssen. Nach meiner Ansicht hat das schon den Status CRITICAL.

"befürchtest".

Dann, wenn die Box sich tatsächlich eine andere Adresse "auswürfeln" sollte, müßte man Dir sicherlich zustimmen (mit Einschränkungen, komme ich gleich noch mal drauf zurück) - aber die unbekannte "link-lokale" zählt hier einfach nicht (und ist ohnehin nicht wirklich freigegeben, denn per Definition eben "lokal") und Du kannst mit einiger Wahrscheinlichkeit auch nicht vollkommen ausschließen, daß diese Adresse tatsächlich mal von Deinem Server (und sei es temporär im Rahmen von NDP) in einem Paket verwendet wurde - jedenfalls solange nicht, wie Du keinen vollständigen Mitschnitt des IPv6-Verkehrs angefertigt hast. Wenn die FRITZ!Box ein Paket von Deinem Server mit dieser Absenderadresse gesehen hat, merkt sie sich diese halt (im Neighbor Cache) ... allerdings sollte sie das tatsächlich nicht "unendlich" machen und das macht sie eigentlich auch nicht, wie wieder die Erfahrungen von @Pom-Fritz! belegen.

Ich weiß aktuell gar nicht, ob die "Neighborhood"-Informationen auch noch in den Support-Daten stehen (früher taten sie das mal) ... wenn ja, sollte man da auch einmal nachsehen (da findet man dann ggf. auch die "Quelle" dieser unerwarteten link-lokalen IPv6-Adresse), wenn so eine Adresse erneut auftauchen sollte. Ist es ohnehin immer diese eine wie in #1, dann wird die halt irgendwo stehen ... daß sich das FRITZ!OS jetzt eine zufällige Adresse aus den Fingern saugt und das ist dann auch noch immer ein und dieselbe, ist ja eher unwahrscheinlich.

Es gab und gibt (denn es ist ja wohl reproduzierbar) offenbar einen Grund dafür, warum die Box bei Dir die Freigaben irgendwann mal entfernt und dann neu einrichtet (diesmal halt mit der EUI-64). Den würde ich erst einmal ermitteln ... das kann allerdings tatsächlich bereits ein "Neuverbinden" der DSL-Verbindung sein, auch wenn das eigentlich direkt daneben im Event-Log stehen sollte und da machen die verschiedenen Tunnel-Formen dann eben auch wieder einen Unterschied in der Behandlung solcher Events, weil natürlich ein 6in4-Tunnel erst wieder beim Broker angemeldet werden muß (mit der neuen IPv4-Adresse), während ein 6to4-Tunnel einfach "funktioniert" (da ist die IPv4-Adresse Teil der IPv6-Adresse und kann aus dieser abgeleitet werden, der Client muß sich also nirgendwo "registrieren" und kann sogar einfach per Anycast sein IPv6-Paket auf die Reise schicken, ohne die Adresse eines Relays kennen zu müssen - das nur als Erklärung für weitere Mitleser, die sich vielleicht damit nicht so auskennen).

Genauso gut kann es aber auch sein, daß die (m.W. AVM-eigene) Implementierung des "heartbeats" (zum Broker) oder für TIC nach der Umstellung auf PCP noch nicht richtig arbeitet ... auch das ist ja eine "Besonderheit", die nur bei der Verwendung von IPv6-Tunneln (mit Heartbeat, wobei ich nicht weiß, ob die FRITZ!Box das nur bei SixXS-Tunneln oder auch bei 6in4 unterstützt) überhaupt notwendig wird und die natürlich ebenfalls zu solchen Aktionen führen kann, wenn da die Notwendigkeit einer neuen "Anmeldung" angenommen wird (egal ob das nun stimmen mag in diesem Moment oder nicht). Insofern ist eben IPv6 nicht unbedingt gleich IPv6 und wie so etwas dann konkret arbeitet, kann wieder höchst unterschiedlich aussehen und aus dem Funktionieren des einen Modus kann man nicht automatisch das Funktionieren eines anderen herleiten (gilt umgekehrt auch für das Nichtfunktionieren, vulgo "nichts klappt bei IPv6" - es gibt eben funktionierende Konstellationen).

Wenn die Box diese Freigaben dann wieder einrichtet und dabei die EUI-64 (das ist auch der "voreingestellte" Wert in der Freigabe-Maske) verwendet, weil sie die von Dir fest vorgegebene abweichende Interface-ID für "verfallen" hält und wieder auf den "Normalfall" zurückgreift, dann mag das ein Fehler in der Implementierung sein (wenn es nicht wirklich "geplant" ist), den man irgendwann auch mal fixen sollte ... eine "kritische" Lücke kann ich darin nicht sehen (das würde voraussetzen, daß es einen anderen Client mit dieser IPv6-Adresse im "promiscuous mode" in Deinen LAN gibt, weil natürlich auch die L2-Adresse beim eingehenden Verkehr angepaßt wird und das nicht als BC/MC im LAN landet) und die Tatsache, daß es bisher immer so funktioniert hat, muß in meinen Augen auch nicht heißen, daß man da nichts mehr ändern darf. Dieses Thema (liebgewordene Workarounds, die aber eben auch nur solche sind und keine "offiziellen Funktionen") hatte ich aber auch schon weiter oben angedeutet.

Die Frage ist halt, was einem am Ende wichtiger ist ... eine funktionierende Lösung (wofür man eben die Ursache suchen muß und sich dann überlegen kann, wie man dem Problem aus dem Weg geht oder ob es nicht doch eine andere - vielleicht sogar bessere - Lösung gibt) oder daß es wieder so geht "wie früher".

Daß es in diesem Laborzweig (auch wegen der Umstellung auf PCP und der damit einhergehenden "Komplett-Renovierung" des GUI - und auch unter der Haube) an dieser Stelle Probleme gab, ist keine wirklich neue Nachricht - das wird hier diskutiert, seit es die ersten Änderungen an dieser Stelle (das war nicht gleich am Beginn der 06.69 alles auch umgesetzt, nur bereits teilweise zu sehen in den Eingeweiden) gab. Auch das von Dir nachträglich beschriebene Problem des "Verwürfelns" der IPv4-Adressen von zwei Clients war da schon dabei ... allerdings nicht mehr mit der Release-Version und bei "sauberer" Liste der "landevices" (meines Wissens jedenfalls nicht). Wenn Du also von "in einem Fall" schreibst, wäre die nächste Frage, wann und mit welcher Firmware nach welchen Konfigurationsversuchen "von Grund auf" das dann war.

Die Kombination aus einem "abgesetzten" DHCPv6-Server, der gar kein vom Provider dynamisch zugewiesenes Präfix verteilt, sondern das von HE statisch zugewiesene und wo die ganze IPv6-Funktion eigentlich nur dann benutzt werden kann, wenn die FRITZ!Box den Tunnel erfolgreich angemeldet hat (wo also Tunnel-Betrieb und Adressvergabe voneinander entkoppelt sind), ist genau das, was ich mit "speziell" meine.

Wenn die FRITZ!Box das Präfix tatsächlich selbst verwaltet mit ihrem eigenen IPv6-DHCP-Server, dann kann sich der Windows-Server z.B. ein (kleineres) Präfix delegieren lassen und dieses dann mit seinem DHCP-Server auch selbst verwalten. Kriegt der dann eine höhere Priorität, sollten auch die Clients sich ihre Adressen bei diesem DHCP-Server besorgen und nicht bei der FRITZ!Box - da schadet es auch nicht einmal unbedingt, wenn zwei Server dieselbe "Range" bedienen. Aber die FRITZ!Box "wüßte" wenigstens, daß der Windows-Server (mit seiner L2-Adresse) das potentielle Ziel für alle IPv6-Pakete mit einer Zieladresse innerhalb dieses delegierten Präfixes ist und kann die einfach 1:1 weiterreichen mit einen geänderten L2-Header. Was der Server dann damit macht (ob der seinerseits die Dinger weiterreicht an ein anderes Netz als Router oder sie alle für sich haben will), kann dem Border-Router vollkommen egal sein.

Liegt dann die gewünschte "statische" IPv6 des Servers in dem delegierten Präfix (das ist dann halt mehr als eine Adresse, die sich der Windows-Server da reserviert und davon darf er auch welche weitergeben), kann die FRITZ!Box wieder (als Alternative zur "nativen Freigabe" mit der EUI-64) das komplette delegierte Segment freigeben - die Option "exposed host" gibt m.W. auch nur die eine eingetragene Interface-ID frei (halt ohne die Beschränkung auf einen oder mehrere definierte Ports) und nicht alle "gelernten" IPv6-Adressen für diesen "host" (das wäre vermutlich auch viel zu tun, kommt halt drauf an, wie häufig der Client die Adressen wechselt - außerdem kann der Router ja nicht wissen, welches nun Adressen mit "privacy extension" sind und nur für ausgehenden Verkehr verwendet werden sollen).

Selbst wenn in diesem freigegebenen Präfix jetzt weitere LAN-Clients mit ihren IPv6-Adressen liegen sollten, die sie vom DHCPv6-Server auf dem Windows-Server erhalten haben, kriegen die durchgelassenen Pakete ja trotzdem die L2-Adresse aus der Freigabe verpaßt und erreichen damit (wieder im Normalfall und der wäre eben, daß der Client nicht im "promiscuous mode" arbeitet) nur den Windows-Server.

Eine weitere Alternative wäre es eben, den Windows-Server einfach dazu zu bringen, daß er selbst (und zwar von der "gewünschten" IPv6-Adresse aus) eine dynamische Freigabe in der FRITZ!Box einrichtet. Wenn die Behandlung solcher dynamischer Freigaben dann besser funktioniert (hier wäre der "PCP-Client" eben der Windows-Server und nicht irgendein Daemon auf der Box, der für diese statischen Freigaben zuständig ist - vermutlich ist es der "dsld"), dann wäre das Problem ebenfalls gelöst.

Auch diese Freigaben pro Host und die damit einhergehende Möglichkeit, das so fein zu "granulieren" in der Berechtigung, daß man nicht nur "allen Clients" eine solche Einrichtung gestatten kann (meinetwegen bei Game-Consolen sogar muß), sondern gezielt nur denjenigen, die es brauchen, ist am Ende in der Summe eine Verbesserung der Sicherheit - und wenn im Zuge der Integration solcher neuer Funktionen nicht gleich alles auf Anhieb funktioniert, sehe ich das solange eben nicht als Katastrophe an, solange es nicht wirklich ein Sicherheitsproblem darstellt oder das Gerät/die Funktion damit seinen/ihren Nutzen für größere Teile der Kunden/Benutzer verliert.

PCP ersetzt nun einmal den alten statischen Mechanismus mit einem dynamischen (und bietet viel mehr Möglichkeiten), da kann ich mir auch nur schwer eine (langfristige) "Koexistenz" vorstellen - wohin das hier führt (irgendein Daemon im FRITZ!OS muß die Stelle des PCP-"Clients" einnehmen und sich um die Verwaltung kümmern, wo das doch das eigentliche Ziel der Freigabe viel besser könnte und das weiß dann auch gleich noch, ob es wirklich "empfängnisbereit" ist oder nicht), sieht man (leider) auch.

Ich bin ja ebenfalls der Meinung, daß AVM längst nicht alles auch (richtig) testet, was man so veröffentlicht und ich habe auch genug Stellen gesehen (und aufgezeigt), wo das wirklich simple Probleme waren, die sofort ins Auge springen müßten, wenn man nur ein einziges Mal auch die betreffende Funktion verwenden/aufrufen will. In diese "Schublade" der allzu offensichtlichen Fehler würde ich das hier auftretende Problem nun aber auch nicht einordnen ... egal wie nervig das für den Betroffenen auch sein mag - eben genau wegen dieser "speziellen" Konfiguration, die nun garantiert keine ist, die bei der Mehrzahl der FRITZ!Box-Benutzer eine Rolle spielt.

 

[dg2dra]

Kurz zum HE Tunnel: Der HE benötigt, anders als SIXXS (was defacto tot ist und so wie ich das auf deren Website interpretiere im Juni abgeschalten wird), keinen Heartbeat. Der 6in4 benötigt deine öffentliche IPv4-Adresse, früher ging das bei HE nur mit festen IPv4, inzwischen wurde das um DynDNS-Technologie erweitert und funktioniert auch mit dynamischen IPv4. HE connected quasi deine IPv4 und routet das zugewiesene IPv6-Netz praktisch zu deiner public IPv4. Kann man dort alles nachlesen, und es funktioniert ja auch mit der FB, ich habe ja kein IPv6-Problem, sondern nur ein Problem mit dem Firewall/Freigaben. Desweiteren gibt es einen einfachen Grund für die Delegation der DNS/DHCP-Dinge zum WIN 2012er Server: Er ist DC für eine Active Directory-Domain (Exchange inkl.) und muss daher mit _seinem_ DNS für die korrekte Funktion der AD sorgen, insbesondere den Clients gegenüber. Das kann der FB-DNS nicht übernehmen. DHCPv6 schlägt in die gleiche Kerbe, er sorgt für eine korrekte Anmeldung und Eintragung der AD-Clients samt deren Adressen im AD-DNS. Desweiteren ist der DNS vom 2012 für eine richtige DNS-Zonen-Delegation einer Subdomain ins Internet zuständig, die per IPv4 und IPv6 von aussen abgefragt werden kann und muss. Das alles hat bis zur FW 6.60 ohne Störungen völlig korrekt funktioniert und zwar monatelang ohne Reboot der Box oder Neu-/Änderungskonfiguration. Das sind die Fakten. Das ist jetzt ab 6.8x mit Problemen behaftet, zumindest bei mir und das auch nicht nur auf einer Box. Ich sehe ja auch hier im Thread, dass es bei anderen auch nicht ganz so rund läuft und meine Beobachtungen zumindest teilweise bestätigt. Meine AD läuft seit dem Jahr 2012 praktisch im DualStack IPv4/IPv6 und zwar ohne erkennbare Fehler. Das gedenke ich auch nur wegen der FB nicht abzuändern. Ich werde heute noch die Logs auswerten, mal sehen was da so interessantes zutage kommt. Ich schliesse auch für mein Netzwerk aus, das irgendein Gerät die Berechtigung bekommt, PCP oder UPnP oder was auch immer, selbstständig Freigaben machen darf. Das ist für mich zumindest No-Go.

Es gibt auch inzwischen grundsätzlich neuere Erkenntnisse, ich informiere heute noch hier darüber.

Gruss Heiko

 

[PeterPawn]

Und ich ziehe einen Teil meiner Behauptungen zurück, weil ich tatsächlich nicht berücksichtigt habe, daß einige IPv6-Tunnel gar nicht "in Hardware" funktionieren können (ich kenne zwar die Spezifikationen dort nicht, aber ich kann mir nicht vorstellen, daß solche Network-Prozessoren dann tatsächlich auch im "offloading" ein IPv6-Paket aus einem IPv4-Paket extrahieren) und damit eben bei solchen Freigaben (ich schreibe mal "vermutlich", weil der PCP-Teil ja "closed source" ist) nicht einfach nur eine L2-Adresse in eingehenden Paketen auszutauschen ist.

Das wäre bei Dualstack so (ggf. noch bei 6to4 zumindest "möglich", weil am Inhalt nichts weiter zu ändern wäre, wenn ich das richtig sehe) ... bei den anderen Tunnelformen muß aber der IPv6-Traffic erst "ausgepackt" werden und dann an einer ganz anderen Stelle entweder ebenfalls noch mal einer "Inspektion" seitens der Firewall unterzogen werden oder er wird über irgendeinen Hook ganz weit vorne (aber sicherlich immer noch "hinter" der Hardware-Lösung) wieder injiziert und durchläuft dann den Prozess noch einmal, diesmal halt als IPv6-Paket. Aber egal, wie das auch immer realiisiert sein mag, die notwendigen Prozesse sind eben recht unterschiedlich, wenn man sie mit anderen "flows" vergleicht und damit treten solche Fehler dann immer noch bei spezifischen bzw. einzelnen Konstellationen auf.

Wenn ich das richtig sehe, dann gibt die FRITZ!Box ja auch bei Dir die EUI-64 richtig frei und das ganze AD sollte ja auch dann funktionieren, wenn es von einer IPv6-Adresse mit dieser EUI-64 "serviert" wird - meine Frage zielte ja auch mehr darauf ab, warum es denn nun unbedingt die "::8" sein soll als Interface-ID und auch wenn der Windows-Server das AD verwaltet (samt DNS und DHCP dafür), könnte er das ja mit einem delegierten Präfix "hinter" der FRITZ!Box tun. Wenn es dann irgendwo einen "glue record" für die IPv6-Adresse des DNS-Servers bei einer Registry geben sollte (das ist tatsächlich m.W. eine "Regulierungslücke", weil die NICs i.d.R. da zwar keine "dynamischen Adressen" für NS zulassen in ihren Bestimmungen, aber man einer 6to4-Adresse eben nicht (mehr) ansehen kann, ob sich dahinter ein statischer oder ein dynamischer Tunnel verbirgt), dann kann man den ja auch auf die EUI-64 anstelle der ::8 (unter dem von HE zugewiesenen Präfix) zeigen lassen.

Das sind m.E. schon mal mindestens zwei "Stellschrauben". Die erste wäre für mich die (notfalls zusätzliche) Verwendung der EUI-64 auf dem Server und das Anpassen der DNS-Server-Adresse in der entsprechenden Zonen-Delegierung - allerdings kann ich auch problemlos meine Domains an diesem Punkt selbst verwalten und betreibe den primären DNS (über IPv4 und IPv6) selbst, so daß ich da volle Kontrolle habe ... geht das über langwierige Faxe mit Änderungswünschen und DNS-TTL jenseits einer Stunde, ist das vielleicht nicht die erste Wahl. Die zweite wäre das "saubere" Delegieren eines (Sub-)Präfixes ... ob allerdings der Windows2012-Server das sauber gebacken kriegt (ohne Zusatz-Software), weiß ich nicht.

BTW ... gerade ein 6in4-Tunnel mit einer dynamischen Gegenstelle braucht eigentlich ganz dringend einen Heartbeat und sollte/muß dann auch relativ schnell "zumachen", wenn der ausbleibt. Du fändest es bestimmt auch nicht so lustig, wenn - z.B. bei einer Störung Deines DSL-Anschlusses - die für Dich per IPv6 bestimmten Daten an Deinen "Nachfolger" unter der bisher verwendeten IPv4-Adresse gesendet werden - es wäre mir jedenfalls neu, wenn so ein HE-Tunnel irgendwie die Authentizität der "Gegenstelle" prüft. Jenseits vom TIC, nicht daß wir uns da mißverstehen ... ich meine schon die "normalen Datenpakete" und nicht die Tunnelsteuerung, wobei ich nicht weiß, wie die bei HE für dynamische IPv4-Adressen arbeitet.

Das Beste (aka "die Krönung") sind dann irgendwelche URL-basierten "Tunnel-Anmeldungen", wo der reine Aufruf einer URL mit der richtigen Tunnel-ID dann zur Änderung der Gegenstelle für den Tunnel (auf die Adresse des Absenders so eines Requests) führt. Das mag noch bei Tunneln mit statischen Gegenstellen funktionieren oder wenn man allen anderen Internet-Teilnehmern nur gute Absichten unterstellt, aber ist irgendwie auch nicht mehr zeitgemäß, weil viel zu leicht zu kapern.

Wenn ich das bei Dir alles mißverstanden habe und Du mit statischen IPv4-Adressen arbeiten kannst, dann würde sich ja tatsächlich eher 6to4 anbieten für das Tunneln von IPv6 an einem Anschluß, der das nicht von sich aus als Dualstack bietet. Ich bin im Prinzip in einer solchen Situation ... mein T-DSL-Business bietet mir zwar seit langem eine feste IP-Adresse, aber die Telekom kriegt es nicht auf die Reihe, da auf Dualstack umzustellen und so muß ich (an diesem Anschluß jedenfalls) immer noch auf ein Tunneln von IPv6-Traffic zurückgreifen. Der "zweite Weg" über einen Kabel-Anschluß bietet hingegen schon seit mehreren Jahren "echtes" IPv6 über Dualstack an - ausgehender IPv6-Verkehr nimmt daher bei mir bevorzugt diesen Weg (die MTU ist wegen der fehlenden "Verpackung" einfach größer).

Ich verstehe ja auch Deinen Frust, wenn es so wie bisher bei Dir eben nicht mehr funktioniert ... trotzdem kann ich Dir nur ganz dringend dazu raten, die Aufgabe für Dich auch mit einer 06.8x zu lösen. Die 06.60 mag das zwar noch genauso machen, wie Du es brauchst und bisher verwendest ... aber sie hat eben einige Sicherheitsprobleme und man sollte sie zeitnah durch eine 06.8x ersetzen (ob 06.80, 06.81 oder 06.83, macht - an der Stelle, wo ich um Sicherheitslücken weiß - allerdings nur einen einzigen Unterschied ... aber da können natürlich noch weitere Lücken behoben sein, die ich nicht kenne).

 

[dg2dra]

Wenn ich das bei Dir alles mißverstanden habe und Du mit statischen IPv4-Adressen arbeiten kannst, dann würde sich ja tatsächlich eher 6to4 anbieten für das Tunneln von IPv6 an einem Anschluß, der das nicht von sich aus als Dualstack bietet. Ich bin im Prinzip in einer solchen Situation ... mein T-DSL-Business bietet mir zwar seit langem eine feste IP-Adresse, aber die Telekom kriegt es nicht auf die Reihe, da auf Dualstack umzustellen und so muß ich (an diesem Anschluß jedenfalls) immer noch auf ein Tunneln von IPv6-Traffic zurückgreifen. Der "zweite Weg" über einen Kabel-Anschluß bietet hingegen schon seit mehreren Jahren "echtes" IPv6 über Dualstack an - ausgehender IPv6-Verkehr nimmt daher bei mir bevorzugt diesen Weg (die MTU ist wegen der fehlenden "Verpackung" einfach größer)..

Ja, es ist schon ein 6in4-Tunnel bei HE, leider habe ich keine feste IP und HE bietet (gut oder schlecht, je nachdem...) die Möglichkeit, quasi die IPv4 meines Endpoints mittels DynDNS-Client basierend auf dem DynDNS-Protokoll entsprechend zu aktualisieren/ändern. Das übernimmt eine Linux-VM per cron bei mir, nicht optimal aber funktioniert. Kurzer Aussetzer nur nach Zwangstrennung ca. 2min irgendwann nachts gg. 4.30 Uhr. Damit kann ich leben. Mein Provider macht schon Dualstack, ABER mit dynamischen IPv6-Präfixen (was für ein Quatsch...) die aller 2h wechseln. Das fange ich mit meinem System sicher nicht ein, der Aufwand ist mir zu hoch. Bisher hat das gut funktioniert, wird wohl auch weiterhin so bleiben mit HE, Ziel ist fast direkt das DE-CIX, also Performance per IPv6 ist ordentlich und ich kann mich nicht beschweren.

So, ansonsten gibts einige News Wie von Zauberhand halten die zwei FBs jetzt doch die v6-Freigaben, was sie bis vor kurzem nicht gemacht haben. Frage mich nicht wieso... Das einzige, was ich noch in der FB geändert hatte, war die Option "Statusinformationen über UPnP übertragen" unter Heimnetz>Netzwerkeinstellungen, dort den Haken raus, also deaktiviert. Alles andere habe ich erstmal nicht angefasst und alles so laufen lassen, weil ich wissen wollte, ob sich die FB doch selbst wieder einkriegt. Die zwei "falschen" IPv6 sind zwar nach wie vor angezeigt bei meinem SRV2012, aber die IPv6-Freigaben haben bis jetzt erst mal durchgehalten (auch wenn sie inzwischen einen grauen Punkt haben, sie funktionieren weiterhin > auch so eine lustige Geschichte). Eines kann ich aber nicht machen: Ich kann keine weiteren Änderungen am Gerät hinsichtlich Freigaben machen, weder neu noch modifizierend. Alles quittiert die WebUI mit rotem Fehler ohne Übernahme. Aber: lösche ich das Gerät komplett und richte alles in einem Rutsch neu für das Gerät SRV2012 ein, übernimmt die das wieder korrekt, auch mit geänderten, anderen Freigaben, und zwar ohne Fehlermeldung. Also "rund" ist das alles derzeit definitiv nicht, man hätte die FW als Labor zum testen gerne raushauen können, aber den Status RELEASE hätte man nicht machen sollen, so sehe ich das. Dafür gibts einfach zu viele "Unklarheiten" im Moment.

Achso, also bei Kunden von mir, die bereits auf AllIP bei der Telekom umgestellt wurden mit "Deutschland-LAN" also ehemals Business-DSL hatten, wenn Du den Anschluss auf feste IP umstellst (je nach Tarif im Kundencenter möglich) dann auch ein festes IPv6-Netz oder sogar mehrere, wenn ich mich recht erinnere, also Dualstack macht das Telekoma schon, aber eben fester Ipv6-Präfix nur bei fester IPv4, sonst gibts auch IPv6 wieder dynamisch (also was die Provider sich dabei denken...kopfschüttel...ich dachte wirklich mal mit v6 hört dieser ganze Quatsch auf - wie man sich täuschen kann).

Gruss Heiko

 

[ben8472]

Ich betreibe eine Fritzbox 7490 an einem DS-Lite Anschluss eines örtlichen Anbieters. Nachdem seit 6.80 endlich die Freigabe von delegierten IPv6 Prefixen in der Fritzbox Firewall klappt, konnte ich erfolgreich eine Sophos UTM dahinter betreiben welche ein /62 zugewiesen bekommen hat.

Ich habe regelmäßig (ich würde sagen alle 3-4 Wochen) das Problem das die Fritzbox auf einmal anfängt IPv6 Adressen zu würfeln, ohne das sich auf Providerseite irgendwas getan hat (der /48 Prefix ist derselbe) - Die Sophos bekommt dann auf einmal ein neues /48 Prefix und manchmal auch eine leicht geänderte IPv6 WAN Adresse (z.B. kommt zwischendrin in der IPv6 Adresse noch eine :0: mit rein)

Ich habe vor rund 2 Monaten schon ein Feedback Formulare Richtung AVM geöffnet, werde dies vermutlich auch bald nochmal wiederholen. Was IPv6 angeht muss man der Fritzbox zugestehen das es hier nach dem Lancom (die hat allerdings andere Nachteile) am Besten und zuverlässigsten funktioniert von allen Geräten die ich bisher getestet habe (Lancom, Microtik, Pfsense), auch wenn hier und da noch Macken vorhanden sind.

 

[dg2dra]

Was IPv6 angeht muss man der Fritzbox zugestehen das es hier nach dem Lancom (die hat allerdings andere Nachteile) am Besten und zuverlässigsten funktioniert von allen Geräten die ich bisher getestet habe (Lancom, Microtik, Pfsense), auch wenn hier und da noch Macken vorhanden sind.

Prinzipell stimme ich Dir voll zu. Essentiell ist die IPv6-Implementation der FB weitgehend ok. Was mich noch vom Wechsel (für mich käme alternativ LANCOM infrage, vermutlich der 883 oder der 1783VAW) bisher abgehalten hat, ist die AC-WLAN-Ausstattung der FB, unter dem wollte ich nicht mehr gehen und ich will auch nicht zig Kisten rumstehen haben. N-WLAN, auch wenn 5GHz möglich, ist mir zu wenig, AC muss es schon sein. Das war eigentlich bisher auch der Grund, warum ich noch nicht auf den 883 von LANCOM gewechselt bin (und da LANCOM keine +25-VPN-Option für den 883 anbietet, die derzeit 3 VPN-Tunnel sind mir leider auch zu wenig, gänge natürlich mit dem 1783VAW, ist aber nochmals eine andere Preisklasse). Insofern ist die Hardwarebasis der 7490 weitgehend das, was ich will, aber die FW und deren Funktionen sind leider auch genauso entscheidend. Momentan haben sich meine beiden Boxen erst mal weitgehend "beruhigt", das entscheidende ist, bleibt das so oder geht das Spiel wieder los. Auch ich habe natürlich dem Support von AVM entsprechende Infos geschickt, ich gebe denen noch etwas Zeit und werde sehen, wo der Zug hinfährt.

Gruss Heiko

 

[ben8472]

eine Profibox/Profimodus von AVM auf den Fritzboxen wäre toll wo man die volle Kontrolle hat. Oder von mir aus ein Router der 499,- € kostet und mehr bietet. Der Markt scheint aber wohl nicht interessant zu sein.

@Heiko: Das mag ich jetzt von vielen Faktoren abhängen, ich habe die Erfahrung gemacht dass das AC der Fritzbox 7490 auch nicht grad das gelbe vom Ei ist. Ich hab mit einem nicht-AC Gerät von Cisco Meraki in der gesamten Wohnung rund 100/100Mbit/s Durchsatz, wo die Fritzbox längst auf 10-15Mbit/s absackt. Die Trennung Richtung WLAN verschmerze ich daher gerne, sehe aber natürlich den Charme einer all-in-one Lösung. Vielleicht ja bei der nächsten Box Generation?

zur IPv6 Problematik; Es lassen sich ja manuell IPv6 Routen anlegen, dort könnte man theoretisch selbst aus dem /48 ein Subnetz einrichten. Das scheint aber nicht unbedingt so zuverlässig zu funktionieren. Hat hier jemand schon mit herumgetestet?