Das Problem ist hier beschreiben:
Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! 
Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
If the CPE knows that the delegated prefix has changed, it should send out RA packets with a prefix valid lifetime of 0 to tell all devices that the old addresses are no longer valid.
Der Router (Zyxel USG 110) sendet entsprechende Pakete, aber das 419P II scheint diese zu ignorieren 
Mittlerweile hat sich die Entwicklungsabteilung von Zyxel damit beschäftigt... Es ist tatsächlich ein Problem des Clients (4919-P II)...
...nach einer Präfixänderung (z.B. durch einen Verbindungsabbruch) versucht das NAS mit der alten, nicht mehr gültigen IPV6 Adresse zu kommunizieren.
Der Router gibt das neue Präfix per RA weiter, und dieses kommt auch beim NAS an... es lässt sich jedoch vom Router her nicht steuern, welche Adresse der Client dann tatsächlich dann nutzt...
Der Präfix ändert sich bei jedem Verbindungsaufbau und zwangsweise nach 180 Tagen bei der Telekom.
Mittlerweile wurde das Problem in einer Testumgebung nachgestellt...
Ich gebe die Information von der Entwicklungsabteilung von Zyxel mal weiter:
Mod: Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Zitat von Zyxel SupportAlles anzeigenWe simulated PD changes from ISP prefix delegation in HQ lab, the issue also can be seen at local lab test.
But this is not USG gateway issue. Here is our lab test procedure. Topology:
ISP router <----------------> USG-110 <------------------> switch ----------PC1 windows 10 | ----------------PC2 Linux Ubuntu
ISP router: it's lab ISP router. we simulate prefix delegation changed from 2001:b030:7036:5::/64 to 2001:b030:7036:9::/64(from 5 to 9) Those PD are real prefix and can be routed to Internet V6.
USG-110 : 465AAPH1ITS-WK32-2021-03-210900175.bin
PC1 : Windows 10 version 1803
PC2 : Ubuntu 16.04.7 LTS Test procedure:
1) In the first time, USG110 get PD 2001:b030:7036:5::/64 from ISP router, and delegated to lan sides hosts. PC1 IP address PD is 2001:b030:7036:5::, it can access to IPv6 Internet. PC2 IP address PD is 2001:b030:7036:5::, it can access to IPv6 Internet. 2) We adjust ISP router PD setting, Now it have new prefix 2001:b030:7036:6::/64 delegated to USG-110. We check that USG already get latest PD 2001:b030:7036:6::/64 from ISP router, and it indeed send to clients by RA. PC1 IP have multiple IPv6 address 2001:b030:7036:5::/64 and 2001:b030:7036:6::/64, it cannot access to IPv6 Internet. because it access Internet with OLD PD ip address 2001:b030:7036:5:: PC2 IP have multiple IPv6 address, 2001:b030:7036:5::/64 and 2001:b030:7036:6::/64, it can access to IPv6 Internet with new PD 2001:b030:7036:6::/64 IP address . We repeated same test procedure to change PD from ISP router from time to time, we found out that the PC1 clients always send out V6 traffic with old PD IP address.
The only way to make it work is to disable/enable windows IPv6 interface. in this way, PC1 can access Internet with new PD ip address.
At the beginning, we thought it was gateway IOP issue, but we replace USG110 to another Router > , it is still have same issue on windows clients. This issue most likely on clients OS behavior when PD changes; which IP address need to be used when it have multiple IP address binding to NIC>
This is not USG110 gateway issue.
... in der Hoffnung das es jemand liest, der damit was anfangen kann...
Wenn ich jetzt 20mal das Kabel ziehe und wieder reinstecke, dann auch 20!
...also vom DSL Modem...
Hier nach einem weiteren Disconnect:
Bildschirmfoto 2021-09-14 um 21.41.00.png
(Prinzip: Jäger und Sammler?!)
ich verwende SLAAC im LAN nicht... sondern die DHCPv6 Prefix Delegation...
Ich habe jetzt mal einen DSL Abbruch provoziert (Kabel gezogen)
... und siehe da;
~] # netstat -rt
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 10.0.1.1 0.0.0.0 UG 0 0 0 bond0
10.0.1.0 * 255.255.255.0 U 0 0 0 bond0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
[~] # ifconfig
bond0 Link encap:Ethernet HWaddr 00:08:9B:CB:FE:56
inet addr:10.0.1.5 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: 2003:d0:2718:1700:208:9bff:fecb:fe56/64 Scope:Global
inet6 addr: 2003:d0:2715:3f00:208:9bff:fecb:fe56/64 Scope:Global
inet6 addr: fe80::208:9bff:fecb:fe56/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:1098325 errors:0 dropped:11 overruns:0 frame:0
TX packets:2364296 errors:0 dropped:1 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:249976709 (238.3 MiB) TX bytes:2092632940 (1.9 GiB)
eth0 Link encap:Ethernet HWaddr 00:08:9B:CB:FE:56
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1028264 errors:0 dropped:0 overruns:0 frame:0
TX packets:1296540 errors:0 dropped:1 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:223917342 (213.5 MiB) TX bytes:1941572892 (1.8 GiB)
Interrupt:11
eth1 Link encap:Ethernet HWaddr 00:08:9B:CB:FE:56
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:70061 errors:0 dropped:11 overruns:0 frame:0
TX packets:1067756 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:26059367 (24.8 MiB) TX bytes:151060048 (144.0 MiB)
Interrupt:15
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:95595 errors:0 dropped:0 overruns:0 frame:0
TX packets:95595 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:28934564 (27.5 MiB) TX bytes:28934564 (27.5 MiB)... die Hütte hat zwei Globale IPv6 (sch***e!)
... alles gut... ich glaube die mDNS Namensänderung, ist auch nur aufgrund dessen, das der ursprüngliche Name bereits für eine der "alten" Adressen vergeben ist...
Ich verstehe nicht, warum die nicht rausfliegen... sie tun es bei den anderen Geräten ja auch...
...bei einem Anschluss kann auch nicht sein, das zwei unterschiedliche Präfixe gleichzeitig vorhanden sind. Der Router schnallt es auch immer direkt, und das Präfix Objekt wird sofort aktualisiert... Beim QNAP NAS wird die Neue Adresse einfach nur hinzugefügt... somit hat das Gerät irgendwann einen ganzen Arsch voll Adresse (wie auf dem Bild zu sehen)... Alle anderen haben max. zwei, die Link Lokale + die "aktuelle" IPv6 welche aus dem "aktuellen" Präfix erzeugt wird...
Aber sowas wie Lease-Times kann man für IPv6 (zumindest da nicht) einstellen...
IPv4 vergebe ich mit MAC Binding immer die selben aus einer DHCP Tabelle... bei IPv6 geht das ja nicht, da sich die Adressen, dank der Deutschen Telekom ständig ändern...
... der mDNS Name ändert sich, mit jeder neuen IPv6... und zwar wird ein Index z.B. (1) hinzugefügt.
Der Screenshoot stammt von iNet (ein Netzwerkscanner)
Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiertt! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Zustandslose Adresse
Eine solche Adresse wird automatisch anhand der MAC-Adresse des Geräts und des Netzwerkpräfixes generiert, das vom Router bekannt gemacht wird. Zustandslose Adressen werden beim Neustart (oder Einschalten) des Geräts verworfen.
(Quelle: Handbuch Canon MFC645Cx)
Muss ich das jetzt so verstehen, dass ich nach einer Präfixänderung immer alle Geräte neu starten muss? - Weil nach einem Neustart ist alles wieder O.K., bis zur nächsten Trennung vom DSL Modem...
Ich habe auch ein Problem mit IPV6, mein TS-419P II sammelt IPV6 Adressen!
Ich habe einen DSL Anschluss, und bei jeder unerwarteten Trennung der bekomme ich ein neues Präfix. Das delegierte Präfix wird dann per Router Advertisement im LAN verteilt, und die Geräte erhalten globale (zustandslose) Adressen... soweit so gut...
...bis auf das NAS... hier bleiben "alten" IPv6 Adressen aus irgendwelchen Gründen erhalten.
Andere Geräte im Netzwerk haben dieses Phänomen nicht, dort wird innerhalb von Sekunden die "alte" IPV6 verworfen, und es ist nur noch die "neue" gültig...
(z.B. Macbook, Homepod, iPhone...)
Über iPV6 / UPnP (mDNS) ist das NAS dann nicht mehr zuverlässig erreichbar, da die IPV6 Adressen (bis auf die eine aktuelle) ja ins leere führen...
Kennt die Problematik jemand?
Hmm.. ich habe gar keinen windows Client im Netzwerk... sicher das es sich nur im internen "LAN" abspielt? Die 10.0.1.1 Adresse ist das Standardgateway...
Kann es vielleicht doch der "custom" DNS sein?!
Jedenfalls glaube ich nicht, dass tatsächlich mehr als 1000 Sessions "offen" bleiben... aber der "Counter" läuft tatsächlich über, wenn man das Limit deaktiviert... dann wird irgendwann alles geblockt, wegen "out of memory" :o
Wenn es nicht nur bei der IP vom NAS auftreten würde hätte ich eher auf die USG getippt... %-:(
Okay, dann fange ich mal an..
Firmware 4.3.3.1624, IPV4 und V6 sind per DHCP zugewiesen, Anbindung über 2xGBE (IEEE 802.3ad)
Telekom VDSL Anschluss mit alternativem DNS (Quad9)
Auf dem NAS läuft "nichts (wildes) "... itunes Server, Netzwerkfreigaben über AFP, FTP
... allerdings verwende ich "myqnapcloud" (DDNS) und das Let's Encrypt Zertifikat...
UPnP ist im Netzwerk aktiv!
Von außen ist das NAS nur per FTP zu erreichen... (NAT Port 21->21 + IPV4 Policy)
Die Portweiterleitung auf das "sichere NAS WEB" ist zwar eingerichtet (8080 -> 443) aber i.d.R. nicht aktiv. Dafür nutze ich eine L2TP/IPSec- VPN Verbindung (nicht über das NAS) um ggf. auf die Weboberfläche (... oder auch andere Geräte) zuzugreifen.
... per USB ist angeschlossen eine USV und ein RDX Laufwerk (Datensicherung (das sollte aber "egal" sein)).
An Sitzungen sind aktuell scheinbar nur diese offen, die das NAS (10.0.1.5) betreffen aktiv:
| DNS_UDP | 10.0.1.5:57598 | Private IP | 9.9.9.11:53 | United States | 304 Bytes | 70 Bytes | 41 |
| Remote-Assistance_HTTPS | 10.0.1.5:36402 | Private IP | 139.162.145.160:443 | Germany | 4.203 MBytes | 10.481 MBytes | 93468 |
| Any_UDP | 10.0.1.5:54582 | Private IP | 211.149.233.35:20001 | China | 0 Bytes | 2.005 MBytes | 93834 |
| DNS_UDP | 10.0.1.5:60146 | Private IP | 9.9.9.11:53 | United States | 304 Bytes | 70 Bytes | 41 |
| Any_UDP | 10.0.1.5:54582 | Private IP | 123.57.105.118:20001 | China | 107.440 KBytes | 2.005 MBytes | 93834 |
| DNS_UDP | 10.0.1.5:38871 | Private IP | 9.9.9.11:53 | United States | 232 Bytes | 70 Bytes | 41 |
| Any_UDP | 10.0.1.5:54582 | Private IP | 139.162.72.65:20001 | Japan | 1.284 MBytes | 2.005 MBytes | 93834 |
| Any_UDP | 10.0.1.5:54582 | Private IP | 74.207.241.132:20001 | United States | 1.388 MBytes | 2.005 MBytes | 93834 |
| Any_UDP | 10.0.1.5:54582 | Private IP | 176.58.96.231:20001 | United Kingdom | 1.338 MBytes | 2.005 MBytes | 93834 |
Davon sind 3 für DNS Anfragen... die mit dem 20001er Port würde ich der QNAP Cloud zurechnen...
Warum die Warnung kommt 
- gerade sind auf dem ganzen Netzwerk nur 67 von 150000 möglichen Session aktiv.
Vielleicht logge ich auch nicht alles mit... aber Session ist doch Session... oder nicht?
Mit Wireshark kenne ich mich leider nicht aus... könnte ich das auch auf einem Laptop im WLAN installieren? Der müsste bei ausgeschalteter Layer2 Isolation alles sehen können, oder?
... und das hier ist doch der "ganz normale"- Wahnsinn, oder?
Nein?
Möglicherweise funktioniert ja etwas nicht mehr? Oder es handelt sich um ein Konfigurationsproblem?
Ich würde schon gerne die Ursache mit euch zusammen herausfinden...
... den "Stecker" hat ja schon die Firewall gezogen!
Malwarescan auch ohne Ergebnis.
Hallo,
ich habe von meiner TS-419P II (10.0.1.5) ständig einen merkwürdigen Eintrag im Protokoll der Firewall:
4 2021-04-22 14:07:35 warn Sessions Limit Maximum sessions per host (1000) was exceeded. [count=85] 10.0.1.5 10.0.1.1 ACCESS BLOCK Weiß jemand was das zu bedeuten hat?
Ich könnte jetzt das Session Limit für den host erhöhen, oder den Eintrag ignorieren, beides ist ggf. nicht so optimal... denn ich weiss nicht was da blockiert wird, und auch nicht warum es so viele Sessions braucht 
Ich würde am ehesten auf DNS Anfragen tippen... da das Gateway angefragt wird... aber
Hallo,
mein Grund ist relativ simpel; Erfahrungen bei der Implementierung des IPV6 Protokolls. Es geht zur Zeit sicherlich auch noch ohne... Die Firewall verhindert bei mir die meisten Dienste... (ich habe höchstens zum Testen mal das Echo an)...
Ist aber schon interessant, danke eines Users habe ich die 4.2.5 bekommen, und das Downgrade hat geklappt... :o - IPV6 läuft wieder wie soll, der Speed passt auch wieder...
Schade allerdings, das ich Let's Encrypt dann nicht nutzen kann... (das war der Hauptgrund auf 4.3.x "aufzusteigen...)
Hallo,
weiß jemand wo ich für das QNAP TS-419P II noch die QTS version 4.2.3 oder 4.2.5 herbekomme?
Ich habe von 4.2.3 auf 4.3.3.1624 aktualisiert... das NAS bekommt jetzt nur noch eine Link-Local Adresse und keine mehr vom DHCPv6 und der Durchsatz ist von 75MB/s (lesend) auf 8-21MB/s gedroppt...