Mir ist aktuell völlig unklar, woher das kommen soll 🤔
Ich habe auf meiner Synology einige Docker laufen, ggf. rührt das daher? Wobei mich die Anzahl der IP-Adressen doch erstaunt. Ich begebe mich mal auf die Suche.
Das scheint (überwiegend) von einer uralten IO-Broker-VM zu kommen. Habe diese mal gestoppt.
Zur Info: Aktuell funktioniert alles ohne Fehler, obwohl ich keine Änderungen vorgenommen habe. Mal sehen, wie lange.
Alles anzeigenkostolany25 : Noch ein Nachtrag zu #159:
Du scheinst im LAN eine falsch konfigurierte IP-Route für das Zielnetz 192.168.178.0/24 (Standard LAN-Adresse einer AVM-Fritzbox) zu haben, die dazu führt, dass Pakete zu Zieladressen in diesem Netzbereich über die DS-Lite-Verbindung zum Internet (also getunnelt zum AFTR) gesendet werden.
Man sieht (wiederholt) TCP-SYN-Pakete zum Aufbau von TCP-Verbindungen zu folgenden Adressen:Ports ...
192.168.178.1:49000
192.168.178.39:5001
192.168.178.39:8443
192.168.178.64:80
192.168.178.61:80
192.168.178.55:80
192.168.178.76:2001
192.168.178.76:8701
192.168.178.193:8000... und zahlreiche Retransmits dieser SYN-Pakete, auf die natürlich niemand antworten kann:
Mir ist aktuell völlig unklar, woher das kommen soll 🤔
Ich habe auf meiner Synology einige Docker laufen, ggf. rührt das daher? Wobei mich die Anzahl der IP-Adressen doch erstaunt. Ich begebe mich mal auf die Suche.
So habe ich es erwartet.
Kannst du nach einem Ping für IPv4 bzw. IPv6 auch mal in den IPv4- bzw. IPv6-Destination-Cache des pingenden Rechners nach den Einträgen für die jeweils aufgelöste IPv4- bzw. IPv6-Adresse des Ping-Ziels (google.com?) schauen, ob für diese als Path-MTU (PMTU) jeweils 1452 bzw. 1492 eingetragen ist?
If so: Dann ist alles gut, und wir brauchen nicht weiter das MTU-Thema zu reiten.
Nachtrag:
Bedeutet somit auch, dass purtel.com keine Jumbo-Frames für die WAN-Strecke verwendet.
Ich werde verrückt! Im Destination-Cache tauchen beide IP-Adressen nicht auf 🤬
Test-Vorschläge für den DS-Lite over PPPoE-Anschluss:
Interessant wäre nun mal, diese Tests an einem LAN-Rechner hinter dem DS-Lite-Router für folgende "sizes" auszuprobieren:
IPv6:
- size=1444 (Gesamt-Paketlänge = 1444+48=1492): ping -6 -n 4 -l 1444 google.com
- size=1445 (Gesamt-Paketlänge = 1444+48=1493): ping -6 -n 4 -l 1445 google.com
IPv4:
- size=1424 (Gesamt-Paketlänge = 1424+28=1452): ping -4 -n 4 -f -l 1424 google.com
- size=1425 (Gesamt-Paketlänge = 1425+28=1453): ping -4 -n 4 -f -l 1425 google.com
- size=1472 (Gesamt-Paketlänge = 1472+28=1500): ping -4 -n 4 -f -l 1472 google.com
Bei IPv4 funktioniert es nur mit 1424, bei allen anderen Größen kommt der Hinweis auf die Fragmentierung.
bei IPv6 funktioniert es nur mit 1444, bei den anderen Größen kommt die Meldung „Allgemeiner Fehler“.
Ok, das kann ich machen. Jedoch nur über WLAN, da mein Notebook keinen LAN-Anschluss hat und ich keinen Adapter LAN/USB-C habe. Alternativ könnte ich es über einen MAC machen, welcher über LAN verbunden ist, da funktionieren jedoch die Befehle nicht.
Ich schicke Dir dann die Protokolle!
Ok, das kann ich heute nachmittag machen. Schicke es Dir dann wieder per PN
Was ist mit diesem Punkt?
NAT habe ich nun komplett ausgeschaltet, ohne dass dies nachvollziehbar Auswirkungen hat. D. h., nach wie vor sind viele Internetseiten nicht erreichbar. Auch die Seite U. a. auch die Seite dieses Forums oder z. B. test-ipv6.com. DNS habe ich dabei schon auf die Cloudfare-DNS umgestellt.
Kannst du in deinem Router für das WAN-Interface (eth4) eine MTU von 1452 konfigurieren?
Nein, die einstellbaren Parameter sind in folgendem Bild zu sehen:
Zur Info: Im TP-Link-Router ist bei MTU ein Wert von 1480 (vor-)eingestellt. Zudem ist dort bei „MLD-Proxy“ noch ein Haken gesetzt. Vielleicht ist das noch relevant?
Erst einmal vielen Dank für die ausführliche Analyse!
Überprüfe bitte an deinen Clients, ...
- ... ob sie jeweils (mindestens) über eine globale IPv6-Adresse verfügen, die mit "2a01:41e" beginnt, und ...
- ... ob sie jeweils über ein IPv6-Standardgateway verfügen, das der linklokalen (fe80...) IPv6-Adresse des LAN-Interface deines Routers entspricht.
Diese beiden Punkte habe ich jetzt gelöst, die einzelnen VLANs zeigen jetzt die externe IPv6-Adresse an:
Bei den VLANs kann ich folgende Einstellungen bezgl. IPv6 vornehmen. Da kann ich nicht herausfinden, was richtig ist oder ob das wie eingestellt passt:
Und bei der WAN-Verbindung gibt es folgende IPv6-Einstellungen:
Da ich meine VLANs erst noch umorganisieren muss, konnte ich die Konfiguration nur rudimentär testen. So wie es aussieht, läuft es jedoch noch immer nicht ohne Probleme.
Das sind die beiden Protokolle, welche über die Funktion "Packet Capure" aufgezeichnet wurden:
eth4:
1 0.000000 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP LCP 60 Configuration Request
2 0.001786 Ubiquiti_8d:71:1b ba:c2:53:34:00:61 PPP LCP 45 Configuration Ack
3 0.002799 Ubiquiti_8d:71:1b ba:c2:53:34:00:61 PPP LCP 34 Echo Request
4 0.004428 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP CHAP 60 Challenge (NAME='JUNOS', VALUE=0x0a18113ee909911383932dd441a1b1327e64f954380a)
5 0.004644 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP LCP 60 Echo Reply
6 0.005703 Ubiquiti_8d:71:1b ba:c2:53:34:00:61 PPP CHAP 67 Response (NAME='xxxxxxxx@dgn.digital', VALUE=xxxxxxxx)
7 0.160342 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP CHAP 60 Success (MESSAGE='')
8 0.162323 Ubiquiti_8d:71:1b ba:c2:53:34:00:61 PPP IPCP 48 Configuration Request
9 0.162841 Ubiquiti_8d:71:1b ba:c2:53:34:00:61 PPP IPV6CP 40 Configuration Request
1
0 0.164866 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP LCP 60 Protocol Reject
11 0.165332 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP IPV6CP 60 Configuration Request
12 0.166122 Ubiquiti_8d:71:1b ba:c2:53:34:00:61 PPP IPV6CP 40 Configuration Ack
13 0.299615 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP IPV6CP 60 Configuration Ack
14 0.302973 fe80::2821:e850:e4da:304a ff02::16 ICMPv6 102 Multicast Listener Report Message v2
15 0.313006 fe80::2821:e850:e4da:304a ff02::2 ICMPv6 74 Router Solicitation
16 0.330198 fe80::2821:e850:e4da:304a ff02::16 ICMPv6 102 Multicast Listener Report Message v2
17 0.724223 fe80::2821:e850:e4da:304a ff02::1:2 DHCPv6 185 Solicit XID: 0x7c5a68 CID: 000300012a704e8d7117 [Packet size limited during capture]
18 0.800218 fe80::2821:e850:e4da:304a ff02::16 ICMPv6 102 Multicast Listener Report Message v2
19 0.973240 fe80::bac2:53ff:fe34:61 fe80::2821:e850:e4da:304a DHCPv6 228 Advertise XID: 0x7c5a68 CID: 000300012a704e8d7117 [Packet size limited during capture]
20 1.190204 fe80::2821:e850:e4da:304a ff02::16 ICMPv6 102 Multicast Listener Report Message v2
21 1.366148 fe80::2821:e850:e4da:304a ff02::2 ICMPv6 74 Router Solicitation
22 2.212667 fe80::2821:e850:e4da:304a ff02::1:2 DHCPv6 213 Request XID: 0xfaa94b CID: 000300012a704e8d7117 [Packet size limited during capture]
23 2.366481 fe80::bac2:53ff:fe34:61 fe80::2821:e850:e4da:304a DHCPv6 228 Reply XID: 0xfaa94b CID: 000300012a704e8d7117 [Packet size limited during capture]
24 2.427327 fe80::2821:e850:e4da:304a ff02::2 ICMPv6 74 Router Solicitation
25 4.519650 fe80::2821:e850:e4da:304a ff02::2 ICMPv6 74 Router Solicitation
26 8.002486 fe80::2821:e850:e4da:304a ff02::2 ICMPv6 74 Router Solicitation
27 9.848174 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP LCP 60 Echo Request
28 9.848443 Ubiquiti_8d:71:1b ba:c2:53:34:00:61 PPP LCP 34 Echo Reply
29 10.003187 Ubiquiti_8d:71:1b ba:c2:53:34:00:61 PPP LCP 34 Echo Request
30 10.004485 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP LCP 60 Echo Reply
31 13.480511 fe80::2821:e850:e4da:304a ff02::2 ICMPv6 74 Router Solicitation
32 19.855156 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP LCP 60 Echo Request
33 19.855304 Ubiquiti_8d:71:1b ba:c2:53:34:00:61 PPP LCP 34 Echo Reply
34 20.004347 Ubiquiti_8d:71:1b ba:c2:53:34:00:61 PPP LCP 34 Echo Request
35 20.006155 ba:c2:53:34:00:61 Ubiquiti_8d:71:1b PPP LCP 60 Echo Reply
36 21.493585 fe80::2821:e850:e4da:304a ff02::2 ICMPv6 74 Router Solicitationip6tnl1:
1 0.000000 192.0.0.2 3.174.46.127 TCP 76 32998 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=2861564977 TSecr=0 WS=1024
2 0.347459 192.0.0.2 3.174.46.104 TCP 76 47460 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1049316850 TSecr=0 WS=1024
3 1.359994 192.0.0.2 3.174.46.104 TCP 76 [TCP Retransmission] 47460 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1049317863 TSecr=0 WS=1024
4 2.580763 192.0.0.2 1.1.1.1 DNS 73 Standard query 0xd22b A ping.ui.com
5 2.581460 192.0.0.2 1.1.1.1 DNS 73 Standard query 0xe576 A ping.ui.com
6 2.582106 192.0.0.2 1.1.1.1 DNS 79 Standard query 0x9778 A www.microsoft.com
7 2.582737 192.0.0.2 1.1.1.1 DNS 72 Standard query 0x5434 A google.com
8 2.785242 192.0.0.2 1.1.1.1 ICMP 45 Echo (ping) request id=0x380a, seq=80/20480, ttl=64 (no response found!)
9 5.588048 192.0.0.2 1.1.1.1 DNS 73 Standard query 0x3d86 A ping.ui.com
10 5.588589 192.0.0.2 1.1.1.1 DNS 73 Standard query 0x23a0 A ping.ui.com
11 5.589057 192.0.0.2 1.1.1.1 DNS 79 Standard query 0x452e A www.microsoft.com
12 5.589695 192.0.0.2 1.1.1.1 DNS 72 Standard query 0x7c3d A google.com
13 5.974239 192.0.0.2 1.1.1.1 DNS 68 Standard query 0x228f A ui.com
14 5.975250 192.0.0.2 8.8.8.8 DNS 68 Standard query 0xd38c A ui.com
15 9.359966 192.0.0.2 233.89.188.1 UDP 48 41625 → 10001 Len=4
16 9.360151 192.0.0.2 255.255.255.255 UDP 48 41625 → 10001 Len=4
17 11.902534 192.0.0.2 3.174.46.97 TCP 76 44176 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1447096690 TSecr=0 WS=1024
18 12.411273 192.0.0.2 1.1.1.1 DNS 73 Standard query 0xd22b A ping.ui.com
19 12.411437 192.0.0.2 1.1.1.1 DNS 73 Standard query 0x3d86 A ping.ui.com
20 12.413018 192.0.0.2 1.1.1.1 DNS 73 Standard query 0xe576 A ping.ui.com
21 12.413138 192.0.0.2 1.1.1.1 DNS 73 Standard query 0x23a0 A ping.ui.com
22 12.413591 192.0.0.2 1.1.1.1 DNS 79 Standard query 0x9778 A www.microsoft.com
23 12.413693 192.0.0.2 1.1.1.1 DNS 79 Standard query 0x452e A www.microsoft.com
24 12.414263 192.0.0.2 1.1.1.1 DNS 72 Standard query 0x5434 A google.com
25 12.414368 192.0.0.2 1.1.1.1 DNS 72 Standard query 0x7c3d A google.com
26 12.785503 192.0.0.2 1.1.1.1 ICMP 45 Echo (ping) request id=0x380a, seq=81/20736, ttl=64 (no response found!)
27 12.959964 192.0.0.2 3.174.46.97 TCP 76 [TCP Retransmission] 44176 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1447097748 TSecr=0 WS=1024
28 12.960373 192.0.0.2 3.174.46.90 TCP 76 46808 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=959653794 TSecr=0 WS=1024
29 14.010051 192.0.0.2 3.174.46.90 TCP 76 [TCP Retransmission] 46808 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=959654844 TSecr=0 WS=1024
30 14.010634 192.0.0.2 3.174.46.127 TCP 76 52616 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=2861578987 TSecr=0 WS=1024
31 15.039952 192.0.0.2 3.174.46.127 TCP 76 [TCP Retransmission] 52616 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=2861580017 TSecr=0 WS=1024
32 15.237013 192.0.0.2 3.174.46.104 TCP 76 46002 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1049331740 TSecr=0 WS=1024
33 15.975354 192.0.0.2 1.1.1.1 DNS 68 Standard query 0x6842 A ui.com
34 15.976172 192.0.0.2 8.8.8.8 DNS 68 Standard query 0xa3a3 A ui.com
35 16.239944 192.0.0.2 3.174.46.104 TCP 76 [TCP Retransmission] 46002 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1049332743 TSecr=0 WS=1024
36 19.859935 192.0.0.2 233.89.188.1 UDP 48 41625 → 10001 Len=4
37 19.860067 192.0.0.2 255.255.255.255 UDP 48 41625 → 10001 Len=4
38 22.414653 192.0.0.2 1.1.1.1 DNS 73 Standard query 0xd22b A ping.ui.com
39 22.414885 192.0.0.2 1.1.1.1 DNS 73 Standard query 0x3d86 A ping.ui.com
40 22.420581 192.0.0.2 1.1.1.1 DNS 73 Standard query 0xe576 A ping.ui.com
41 22.420825 192.0.0.2 1.1.1.1 DNS 73 Standard query 0x23a0 A ping.ui.com
42 22.422426 192.0.0.2 1.1.1.1 DNS 79 Standard query 0x9778 A www.microsoft.com
43 22.422727 192.0.0.2 1.1.1.1 DNS 79 Standard query 0x452e A www.microsoft.com
44 22.426584 192.0.0.2 1.1.1.1 DNS 72 Standard query 0x5434 A google.com
45 22.426961 192.0.0.2 1.1.1.1 DNS 72 Standard query 0x7c3d A google.com
46 22.785813 192.0.0.2 1.1.1.1 ICMP 45 Echo (ping) request id=0x380a, seq=82/20992, ttl=64 (no response found!)
47 25.976244 192.0.0.2 1.1.1.1 DNS 68 Standard query 0x6599 A ui.com
48 25.977075 192.0.0.2 8.8.8.8 DNS 68 Standard query 0xb322 A ui.com
49 26.416107 192.0.0.2 3.174.46.104 TCP 76 33200 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1049342919 TSecr=0 WS=1024
50 27.439993 192.0.0.2 3.174.46.104 TCP 76 [TCP Retransmission] 33200 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1049343943 TSecr=0 WS=1024
51 27.440640 192.0.0.2 3.174.46.97 TCP 76 40450 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1447112228 TSecr=0 WS=1024
52 28.480037 192.0.0.2 3.174.46.97 TCP 76 [TCP Retransmission] 40450 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1447113268 TSecr=0 WS=1024
53 28.480682 192.0.0.2 3.174.46.90 TCP 76 44722 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=959669314 TSecr=0 WS=1024UniFi Network Application 10.0.162 enthält den unten aufgeführten Bugfix.
Die 10.0.162 gibt es schon ein paar Tage, weshalb meine ganzen Versuche sich auch auf diese Versione beziehen.
Noch folgendes zur Info, wenn auch wieder off Topic:
Ich habe mir jetzt sowohl die UCG als auch die Switche resetet (also Werksreset) und alles komplett neu eingestellt. Ergebnis beim Betrieb der UCG hinter dem TP-Link: IPv4-Seiten sind sowohl im Unifi-Netz (192.168.1.x) als auch im TP-Link-Netz (192.168.0.x) nur sehr sporadisch zu erreichen. IPv6 funktioniert augenscheinlich problemlos.
Kannst du oder kostolany25 für das Szenario "DS-Lite an UniFi Router mit PPPoE" Logdaten des Routers oder gar einen Paket-Mitschnitt am WAN-Port des Routers für den Verbindungsaufbau zum ISP beisteuern?
D. h. vor dem Einstecken des Kabel auf „Packet Capture“ gehen? Reichen 30 Sekunden?
Der Router müsste bzw. sollte aber in der Lage sein, DNS-Namensauflösung per Kontaktierung der ISP-Resolver via IPv6 durchzuführen (z.B. um IPv4-Ziele aufzulösen). Der Router sollte hier als DNS-Proxy/Forwarder arbeiten, der DNS-Requests per IPv4 aus dem LAN entgegen nimmt und diese per IPv6 weiterleitet.
Was muss ich da wo einstellen?
Ich weiß immer noch nicht, ob dein Ziel-Szenario diese Router-Kaskade sein soll, oder ob der TP-Link 'raus fliegen und durch den UCG-Ultra ersetzt werden soll. Nur letzteres passt übrigens zu diesem Thread "Unifi sucht Tester für DS-Lite i. V. m. PPPoE" - deine Kombi UCG-Ultra hinter TP-Link ist hier insofern deplatziert.
Sorry, das hat sich leider so entwickelt.
Wie meinem zweiten Thread (#100) zu entnehmen kst, bin ich mit der UCG direkt an dem ONT gestartet, da das schon immer mein Plan war. Dies resultierte leider in dem Fehler, welchen ist seitdem immer wieder habe: Internetseiten sind teilweise nur sporadisch erreichbar, augenscheinlich IPv4-Seiten. Deshalb habe ich versucht, als der TP-Link-Router keine Probleme mehr gemacht hat, diesen als Router zu verwenden mit der UCG als Management-Konsole dahinter für mein restliches Netzwerk. Auch hier treten die Problem jedoch wie zuvor auf.
Mein Netzwerk besteht neben der UCG aus insgesamt 3 Switchen und 4 APs von Unifi. Im Netzwerk selbst hängen die übliche Anzahl an Handys, Tablets, Notebooks, etc. einer 4-köpfigen Familie sowie ca. 40 Shelly-Komponenten und eine NAS.
Also ich habe nach wie vor keinen einzigen funktionsfähigen DS-Lite an UniFi Router mit PPPoE gesehen. Entweder funktionierte der Tunnel oder IPv6, nicht Beides. Konnte jemand was Anderes feststellen?
Das würde mich auch interessieren. Ich habe nach meinen unzähligen Versuchen auch den Verdacht, dass diese Funktion bislang noch nicht sauber implementiert ist.
Aber ich vermute, dass seine Kombi mit TP-Link und dahinter die UCG-Ultra irgendwie verkonfiguriert ist.
Das was mich irritiert ist, dass wenn ich die UCG außen vor lasse und den TP-Link an meinen ersten Unifi-Switch anschließe, zu den beschriebenen Problemen kommt. Als ob die dann nicht „gemanagten“ Unifi-Geräte das Problem verursachen. Wenn der TP-Link standalone über sein WLAN genutzt wird, ist alles in Ordnung.
Ja, das sind Screenshot aus der Unifi-Oberfläche.
Das Problem ist, dass kostolany25 immer wieder eine neue Baustelle aufmacht. Er setzt 2 Router ein in seinem Netz, ohne hinreichendes Verständnis für Netzwerke.
Der UCG-Ultra erwartet ein Eingangssignal auf dem WAN-Port, ansonsten funktioniert er nicht. Diesen WAN-Zugang kann man (meinem Verständnis nach im Ergebnis vergleichbar mit der Einstellung in Deinem Thread #139) so konfigurieren (mittels Static IP), dass der vom TP-Link hergestellte Internetzugang auch an der UCG ansteht. Das ist ja auch auf dem Bild IMG_1752 zu sehen. Hier wurde selbstverständlich nicht die WAN-Konfiguration mittels DS-lite over PPPoE vorgenommen.
Ich habe im Einstellungsbereich meines Netzwerks bei IPv6 „Prefix Delegation“ eingestellt und dann den entsprechenden Zugang zum TP-Link ausgewählt (siehe Screenshot).
Dort, wo der rote Kringel ist, Stand später dann auch dieselbe IPv6-Adresse, welche in der Übersicht der WAN-Verbindung ausgewiesen war (ebenfalls Screenshot).
So, ich habe jetzt versucht, meinen UCG-Ultra anstelle des TP-Link anzuschließen, jedoch weiterhin ohne Erfolg. Ich gehe deshalb aktuell davon aus, dass die DS-liste-over-PPPoe-Funktionalität, welche erst ganz neu implementiert wurde, noch fehlerhaft ist. Anders‘ kann ich mir das nicht erklären.
Da die Verbindung über den TP-Link mehrere Tage problemlos lief, habe ich diesen dann an mein Unifi-Equipment angeschlossen und die UCG-Ultra dabei außen vor gelassen. Das Ergebnis war, dass der Internetzugriff wieder ziemlich gestört war. Auch wenn ich mich per WLAN direkt auf den TP-Link aufgeschaltet habe, gab es Probleme. Irgendwie scheint das Problem innerhalb meines Unifi-Netzwerks zu liegen, weshalb ich mit meinem Latein nun echt am Ende bin.
Ich habe danach noch die UCG-Ultra hinter dem TP-Link eingebunden (entsprechend dem angehängten Schaubild). auf der UCG-Ultra hatte ich den Internet-Zugang über den TP-Link verfügbar, jedoch waren die Probleme dieselben, wie ohne die UCG-Ultra?
Weiß da noch jemand Rat?
Ok, jetzt scheint es zu funktionieren:
Ich würde es dann in einem nächsten Schritt dann wiedr mit der UCG-Ultra versuchen da jetzt ja davon auszugehen ist, dass es nicht am Anschluss liegt. Ich werde berichten.
Vielen Dank für Eure Unterstützung! 
Nein, die Clients erhalten keine IPv6-Adresse aus deinem 56er Subnetz!
Liegt das daran, dass hier IPv6 nicht aktiviert ist?
Wenn ich das aktiviere, kommen weitere Einstellmöglichkeiten:
Am IPhone gibt es keine Möglichkeit IPv6 separat ein- oder auszuschalten.
Auch mit dem iPhone ist das Ergebnis dasselbe wie mit dem PC. Es wird keine IPv6-Adresse erkannt:
