Beiträge von ::1

Zitat von jokergermany

So richtig verstanden habe ich noch nicht wann man PVLans verwendet und wann Port based Vlans.

Verstehe ja das Problem an Tag based Vlans, aber nicht so wirklich den Unterschied zwischen PVLans und Port based Vlans...

Ich erkläre jetzt nicht PVLAN, weil du das nicht brauchst. Setze deinen Switch bitte wieder auf den Ausgangszustand.

Lösung mit Standard-VLAN: Ich gehe davon aus, dass es in deinem Switch ein Default-VLAN gibt (häufig VLAN 1 - schau mal in Manual, ob es dazu Infos gibt), und dass alle Ports Access-Ports für das Default-VLAN darstellen. Dann kann jeder Port mit jedem anderen kommunizieren.

Denke dir jetzt ein VLAN aus, das nicht dem Default-VLAN entspricht. Ich nehme jetzt bspw. mal VLAN 100. Jetzt konfiguriere den Uplink-Port für das SFP-Modul und den gewünschten Port für den Router-Anschluss als Access-Ports für VLAN 100. Fertig. Die Bezeichnung "Access-Port" kommt aus der Cisco-Welt, bei deinem Switch heißt das vermutlich anders, schau im Manual: Soweit ich es (kurz überflogen) sehe, ist bei deinem Switch das Default-VLAN=1. Füge also ein VLAN 100 (oder etwas ungleich 1) hinzu und deklariere die beiden Ports als "untagged members" von VLAN 100. Die PVID für diese beiden Ports muss auch auf VLAN 100 gesetzt werden.

Zitat von jokergermany

Doch ist sehr relevant, sollte ich wirklich das ONT durch ein SFP Modul ersetzen.
Weil der Switch ja switchen soll, bloß eben nicht die Glasfaser, die darf nur zu nem anderen RJ45 Port gehen und von da aus zum Wan Port des Routers.

Ja, das machst du mit Standard-VLANs, wie oben schon von Anderen kommentiert. Dazu brauchst du keine "PVLANs".

"Isolation cannot be set for all SFP ports"
Generally, it is necessary to ensure that the uplink port is in the allowed forwarding"

Zitat von jokergermany

Da muss ich mir nochmal genau anschauen was damit genau gemeint ist und was der unterschied zwischen vlan und isolate ist...

Laut Manual gehe ich davon aus, dass es sich hier um "isolated private VLAN (PVLAN)" handelt. Die allgemeine Theorie dazu findest du in RFC5517, wobei der Switch keine Community-Ports unterstützt. Die Aussage in dem Manual besagt m.E., dass mindestens einer der Uplink-Ports ein Promiscuous-Port (im RFC-Sprech) sein muss ("is in the allowed forwarding" im Manual-Sprech).

Ich gehe aber davon aus, dass isolated PVLAN für dich nicht relevant ist. Da lt. Manual "By default, all ports are not isolated" gilt, kannst du das Thema somit ignorieren.

Was mich stutzig macht: Die Fritzbox 7590AX am DG-Anschluss hat kein aktiviertes IPv6 (laut einem der Screenshots). Wenn du nun an deinem Windows-PC, wie gezeigt, NSLOOKUP aufrufst, meldet sich als DNS-Resolver allerdings eine "fritz.box" mit einer IPv6-ULA-Adresse fd98:...

Das kann nicht die 7590AX sein (denn die hat IPv6 nicht aktiviert), es ist dann wohl die 7590 am Telekom-Anschluss.

Wie ist dein Windows-PC denn angeschlossen, nur über WLAN? Und wenn ja, welches WLAN? Die Fritzbox 7590AX hat wohl ein WLAN mit der SSID "FRITZ!Box 7590 HE" - ich hoffe, das WLAN deiner Fritzbox 7590 am Telekom-Anschluss hat eine andere SSID?

Vorschlag: Sorge für einen Test erst Mal für eine sauber getrennte Netzumgebung für den DG-Anschluss: Wähle in der Fritzbox 7590AX vorerst eine WLAN-SSID, die sich von der WLAN-SSID der Fritzbox 7590 am Telekom-Anschluss unterscheidet. Stelle sicher, dass keine LAN-Ports der beiden Fritzboxen miteinander (direkt, oder über einen Switch) verbunden sind. Schließe einen Windows-PC zum Testen entweder über WLAN (WLAN-SSID der Fritzbox 7590AX!) oder per Ethernet-Kabel (in diesem Fall bitte den WLAN-Adapter des Windows-PC deaktivieren) an die Fritzbox 7590AX an.

Und dann nochmal testen. Es wäre auch gut, in der Fritzbox 7590AX IPv6 zu aktivieren. Und wenn man wirklich wissen will, was auf der DG-Verbindung passiert, wäre eine Paketmitschnitt am WAN-Port der Fritzbox 7590AX nicht schlecht.

Ich möchte nochmal auf meinen Kommentar oben hinweisen:

Zitat von ::1

Aus der Info für das FRITZ!OS-Update 8.02:

Code

# Weitere Verbesserungen im FRITZ!OS 8.02

## Telefonie:
...

## Internet:
...
- **Behoben** keine Internetverbindung nach Update auf FRITZ!OS 8.00 bei fehlendem Kennwort in den Zugangsdaten

Ein Update auf Version 8.02 könnte das Problem also beseitigen. Müsste man sich jetzt halt über einen anderen Internetzugang von https://ftp.avm.de/fritzbox/ herunterladen und in der FRITZ!Box als Datei einspielen.

Aus der Info für das FRITZ!OS-Update 8.02:

# Weitere Verbesserungen im FRITZ!OS 8.02

## Telefonie:
...

## Internet:
...
- **Behoben** keine Internetverbindung nach Update auf FRITZ!OS 8.00 bei fehlendem Kennwort in den Zugangsdaten

Ein Update auf Version 8.02 könnte das Problem also beseitigen. Müsste man sich jetzt halt über einen anderen Internetzugang von https://ftp.avm.de/fritzbox/ herunterladen und in der FRITZ!Box als Datei einspielen.

Zitat von geckoespresso

9.|-- 2a00:6020:0:1d::2

Na, immerhin kommt man ja schon mal in das DG-Netz (2a00:6020::/32), erst danach wird's "dunkel". Es kann allerdings auch sein, dass alle folgenden Hops/Router in der DG-Infrastruktur dahingehend konfiguriert sind, nach dem Droppen der Traceroute-Pakete keine ICMPv6-time-exceeded Messages zurückzuschicken.

Bei mehreren Fällen der letzten Zeit mit IPv6-Problemen am DG-Anschluss ist mir folgende Gemeinsamkeit aufgefallen:

• Alle PD-LAN-Präfixe liegen im Bereich 2a00:6020:7000::/36.
• Etwas genauer: 2 Fälle im Bereich 2a00:6020:7380::/41, der aktuelle Fall des OP im Bereich 2a00:6020:7680::/41
• Örtlich ist das (zumindest für den Bereich 2a00:6020:7380::/41) wohl im Umfeld Tübingen/Stuttgart.

Ich habe generelle Analysen im DG-Range 2a00:6020::/32 durchgeführt und bin dabei für die Sub-Ranges

• 2a00:6020:4000::/36
• 2a00:6020:5000::/36
• 2a00:6020:8000::/36
• 2a00:6020:a000::/36
• 2a00:6020:b000::/36
• 2a00:6020:d000::/36

zu folgender Systematik gekommen:

1. Jeder /36-Range wird in 2^5=32 /41-Ranges unterteilt.
2. Jeder /41-Range umfasst bis zu 2^15=32768 Kundenanschlüsse mit jeweils einem PD-LAN-Präfix der Größe /56. Die Kundenanschlüsse in einem /41-Range liegen hinter demselben BNG, dessen interne IPv6-Adresse in 2a00:6020:ffff:ffff::/112 liegt. Beispielweise hat man die folgenden Zuordnungen von /41-Ranges zu BNG-Adressen:
   2a00:6020:4000::/41 - 2a00:6020:ffff:ffff::19
   2a00:6020:4080::/41 - 2a00:6020:ffff:ffff::1a
   2a00:6020:4100::/41 - 2a00:6020:ffff:ffff::1b
   2a00:6020:4180::/41 - 2a00:6020:ffff:ffff::1c
   :
   2a00:6020:d280::/41 - 2a00:6020:ffff:ffff::6
3. Die WAN-IP-Adressen am Kunden-Router liegen für die oben gelisteten /36-Blöcke stets in 2a00:6020:1000::/48. Auch hier gibt es genauer Sub-Ranges für jeden /41- Block:
   2a00:6020:4000::/41 - 2a00:6020:1000:30::/112
   2a00:6020:4080::/41 - 2a00:6020:1000:31::/112
   2a00:6020:4100::/41 - 2a00:6020:1000:32::/112
   2a00:6020:4180::/41 - 2a00:6020:1000:33::/112
   :
   2a00:6020:d280::/41 - 2a00:6020:1000:1d::/112
   
   Es ist meistens sogar möglich, die vollständige WAN-Port-Adresse aus dem jeweiligen /112-Block algorithmisch aus dem /56-PD-LAN-Präfix zu bestimmen (ich habe allerdings auch Abweichungen von der folgenden Regel gefunden) - die letzten 4 Hexziffern der WAN-Port-Adresse ergeben sich aus den Hexziffern WXYZ im /56-PD-LAN-Präfix 2a00:6020:PQWX:YZ00::/56 (ggf. führende "0" ergänzen) durch Addition von 0x10, nachdem man zuvor, falls =0xWXYZ > 0x8000, noch 0x8000 abgezogen hat.
4. Der Block 2a00:6020:7000::/36 in den Problemfällen ist nun offenbar neu. Er wird vermutlich zwar auch in /41-Blöcke mit je bis zu 32768 Kundenanschlüssen eingeteilt, jedoch liegen die WAN-Port-Adressen hier nicht mehr in 2a00:6020:1000::/48, sondern nun im ersten /112-Subrange des jeweiligen /41-Blockes:
   2a00:6020:7380::/41 - 2a00:6020:7380::/112
   2a00:6020:7680::/41 - 2a00:6020:7680::/112
   
   Hier führt DG offenbar ein modifiziertes IPv6-Adress-Konzept ein. In sämtlichen Traceroutes zu Zielen in 2a00:6020:7000::/36, die ich durchgeführt habe, ist mir aufgefallen, dass ich keinen last hop im AS60294 oder AS8899 der DG sehe. Irgendwas scheint dort also noch schief zu laufen.

Zitat von DrFroeschle

vielen Dank für Ihre Nachricht. Ihnen steht bei Deutsche Glasfaser ein CGN Dualstack Lite Anschluss zur Verfügung.

Wäre mir neu, dass es sich bei DG um einen DS-Lite-Anschluss handelt. Aber könnte ja sein, dass das jetzt bei neueren Anschlüssen so ist? Dann müsste man in der FRITZ!Box mal eine DS-Lite-Konfiguration probieren.

Zitat von Dave

Noch als Nachtrag: es scheint am Browser zu liegen. Safari scheint auf die offizielle AVM Seite zu gehen.

Firefox geht auf die Oberfläche der Fritzbox.

Ja, die Browser dieser Welt bieten inzwischen fast alle Einstellungen zur Verwendung von DoH an. Allerdings wundert mich dein Safari-Ergebnis, denn lt. Google-Suche (https://www.google.com/search?q=DNS+over+HTTPS+Safari) sollte Safari DoH gar nicht unterstützen.

Eine FRITZ!Box hat immer 2 LAN-IPv6-Adressen:

1. Eine aus dem delegierten LAN-Präfix des ISP, bei DG also eine, die mit 2a00:6020: beginnt.
2. Eine ULA-Adresse fd... für den DNS-Forwarder - und zwar auch dann, wenn man den Clients im LAN keine ULA zuweist.

Diese beiden Adressen bekommt man auch angezeigt, wenn man "fritz.box" unter Verwendung eben dieses DNS-Forwarders (z.B. dessen IPv4, in meinem Fall 192.168.178.1) auflöst:

Hier mit nslookup unter Windows:

C:\>nslookup fritz.box. 192.168.178.1
Server:  UnKnown
Address:  192.168.178.1

Name:    fritz.box
Addresses:  fdXX:XXXX:XXXX:0:9a9b:cbff:feZZ:ZZZZ
          2a00:6020:PQWX:YZ00:9a9b:cbff:feZZ:ZZZZ
          192.168.178.1

Die hier verwendete Traceroute-Software scheint das zu erkennen (wie auch in dem Google-Beispiel) und zeigt das an, schließlich muss sie ja eine Auswahl treffen, welche der aufgelösten IPv6-Adressen sie für den Traceroute verwenden will.

Es muss nichts bedeuten, aber auffällig ist, dass in allen hier aktuell diskutierten Fällen mit IPv6-Problemen von gordrin , webwe und DrFroeschle die PD-Blöcke in 2a00:6020:7300::/40 bzw. sogar genauer in 2a00:6020:73d0::/44 liegen und die zugehörigen WAN-Port-Adressen in 2a00:6020:7380::/112. Ist evtl. ein neuer Block, den DG aktuell für Neuanschlüsse verwendet. Neu ist hier auch die Zuordnung der WAN-Port-Adresse zum PD-Block: An älteren Anschlüssen, z.B. denen mit PD-Blöcken aus 2a00:6020:4000::/36 liegen die zugeordneten WAN-Port-Adressen in 2a00:6020:1000::/48. In Traceroutes zu Zielen an diesen älteren Anschlüssen sieht man als letzte Etappe vor dem Kunden-Router Adressen aus 2a00:6020:ffff:ffff::/64 (lt. RIPE-DB als "BNG-Cluster-DHCPv6-Link-Address" benannt), diese habe ich in Traceroutes zu Zielen an den oben genannten Adressblöcken der neueren Anschlüsse noch nie gesehen.

DG hat hier offenbar ein anderes Nummerierungs-Schema eingeführt, und man könnte vermuten, dass damit evtl. auch eine geänderte Access-Infrastruktur einher geht.

Liegen die Anschlüsse im selben Ausbaugebiet oder zumindest in benachbarten PLZ-Bereichen?

Zitat von mbo77

Andererseits bleibt es bei der Beobachtung, dass das Paket die Fritzbox wieder verlässt.

Zitat von ::1

Insofern halte ich die These des "droppenden DG-Routers" für nicht plausibel und sehe die Ursache des Problems eher doch lokal auf Kundenseite.

Ja, auf der Suche nach möglichen lokalen Ursachen hat sich meine These der zwei unterschiedlichen MAC-Adressen am WAN-Port (einfach spekulativ aus der Angabe, dass es ein aus LAN1 umkonfigurierter WAN-Port ist) als nicht haltbar ergeben.

Bleibt noch:

Zitat von frank_m

Hier besteht ein gewisses Restrisiko, dass die Annahme falsch ist. Das hast du bislang nur von deinem merkwürdigen Bridgekonstrukt überprüft, von dem wir nicht wissen, wie es den Verkehr beeinflusst.

Vielleicht sollte man dieses Bridgekonstrukt tatsächlich mal entfernen, um es als Fehlerursache auszuschließen.

Zitat von DrFroeschle

Was allerdings hilft, ist ein nslookup auf fritz.box von einem der Clients im Heimnetz. Da bekomme ich dann von dem FB dnsmasq die Adresse ausgehändigt. Mit dieser habe ich dann vom VPS Server im Internet aus einen traceroute6 gemacht:

Und diese Adresse ist dann:

Zitat von DrFroeschle

root@vmdabcdef:/etc# traceroute6 2a00:6020:73d7:xxxx:3ea6:2fff:fe44:zzzz

Es ist also eine Adresse aus dem PD-Block 2a00:6020:73d7:5900::/56, die zur Fritzbox gehört.

Andererseits lautet die IPv6-Adresse deines Test-Webservers im LAN 2a00:6020:73d7:5900:223:55ff:fe:fc:5155, liegt also auch im PD-Block 2a00:6020:73d7:5900::/56, nur eben nicht auf der Fritzbox.

Jetzt haben wir die Beobachtung:

Werden die beiden Adressen von außen angesprochen, dann ...

1. ... kommt von 2a00:6020:73d7:5900:3ea6:2fff:fe44:zzzz (Adresse auf Fritzbox) keine Antwort zurück-
2. ... kommt von 2a00:6020:73d7:5900:223:55ff:fe:fc:5155 (Adresse auf Webserver im LAN) eine Antwort zurück.

Wenn nun die These ist, dass im DG-Netz irgendein Router im ersten Fall das Antwort-Paket droppt, frage ich mich anhand welchem Kriteriums er das tun sollte. Die These war ja: Immer wenn die Adresse zu Fritzbox gehört, wird gedroppt, sonst nicht. Woran soll aber die droppende Instanz im DG-Netz erkennen, dass 2a00:6020:73d7:5900:3ea6:2fff:fe44:zzzz zur Fritzbox, 2a00:6020:73d7:5900:223:55ff:fe:fc:5155 aber zu einem Webserver im LAN gehört? Es sind einfach zwei Adressen aus dem PD-Block 2a00:6020:73d7:5900::/56.

Insofern halte ich die These des "droppenden DG-Routers" für nicht plausibel und sehe die Ursache des Problems eher doch lokal auf Kundenseite.

Zitat von mbo77

Wie und warum sollte ein Router ein Paket droppen? Das kann nur die Firewall machen. Oder worauf willst du hinaus?

Exakt!

Ich gehe aber nicht davon aus, dass ein ISP, der ja im Wesentlichen nur Traffic zwischen dem Internet und seinen Kunden routen soll, Firewalls im Datenstrom platziert. Jedenfalls nichts, was "State" und "Sessions" halten muss (außer bei CGNAT, da sind NAT-Sessions halt ein notwendiges Übel). Wenn überhaupt, dann sind vielleicht Paketfilter im Spiel, die stateless arbeiten, und in einem Router vielleicht Pakete droppen, die z.B. als Ergebnis eines Reverse-Path-Forwarding-Checks "zum falschen Interface" herein kommen.

Aber gut, ich habe keine Einblicke in das Innenleben eines ISPs - falls du oder sonst jemand da Erfahrungswerte liefern kann, gerne mehr.

Ich meine schon: Es würde deine Vermutung entkräften, weil es dann keinen zu haltenden "State für diese IP" gibt. Bitte Worte wie "Haarspalterei" vermeiden, kommt nicht gut.

Zitat von mbo77

OK, dann wird der DG-Router den State für diese IP nicht halten und das Paket verwerfen, da es zu keiner initiierten Session passt.

Ein Router ist keine Firewall ...

Und wenn du von einem IPv6-fähigen LAN-Client einen IPv6-Ping auf ein beliebiges Internet-Ziel absetzt (und dabei einen Trace am WAN-Port laufen lässt), wird dieses ICMPv6-echo auch mit der Source-MAC-Adresse 3c:a6:2f:44:18:37 weitergeleitet (damit wollte ich es vergleichen)?

DG akzeptiert am DG-Anschluss ja nur eine einzige MAC-Adresse.

Blöde Idee:

Falls deine Fritzbox in Antwortpaketen zu Requests aus dem Internet (zu Diensadressen auf der Fritzbox selbst) eine andere MAC-Adresse als für Weiterleitungspakete von Clients/Servern in deinem LAN verwendet, würden diese vom "DG-Router" gedropt. Das würde zumindest das beobachtete Verhalten erklären.

Man könnte das durch Paketmitschnitte am WAN-Port der Fritzbox herausfinden (vergleiche den Trace mit den gedropten SYN/ACKs mit dem ausgehenden Traffic von Clients).

Nachtrag:

Und falls dem so ist, könnte es evtl. daran liegen, dass LAN1 hier als Ersatz für einen echten WAN-Port herhalten muss - das mag dann zu solchen Effekten führen.

Zitat von DrFroeschle

Alle diese Pakete gehen mit der 2a00:6020:7380::1735 als Source IP ab.

Also, wenn ich für diese WAN-Port-Adresse deiner Fritzbox dieselben Traceroute-Tests durchführe, die ich hier bezogen auf das Problem von gordrin durchgeführt habe, dann erhalte ich auch dieselben (negativen) Ergebnisse, wie dort beschrieben:

• Ein heise online-Traceroute endet in Position 5 bei 2a00:6020:0:d::2, kommt also über den Übergangspunkt zur DG im DE-CIX Frankfurt nicht hinaus.
• Ein Traceroute von meinem Desktop-PC am DG-Kundenanschluss endet in Position 3 bei der ominösen ULA-Adresse fc00::1 (bzw. kommen danach nur noch Timeouts).

Mit fällt auf, dass deine WAN-Port-Adresse "ungewöhnlich ist": In allen Fällen, die ich bisher gesehen habe, liegen die WAN-Port-Adressen von DG-Anschlüssen im Range 2a00:6020:1000::/48

Ergänzung:

Zitat

Tscha, und was soll ich sagen, hängt am gleichen Hop wie wenn ich die dedizierte FB IPv6 Adresse verwende. Und wie ich in meinem eigenen Forumsthread schon geschrieben hatte: Wenn ich einen Webserver im "Heimnetz" einrichte und diesen per IPv6 an der Fritzbox freischalte, dann kann ich auf diesen zugreifen. Nur die Rückrouten direkt für die Fritzbox-Services werden am DG Router geblockt (meine Vermutung).

Aus deinen Angaben reime ich mir trotz "Obfuskierung" zusammen:

Dein PD-Block ist 2a00:6020:73d7:5900::/56. Und egal, ob es in diesem Block einen nach außen freigeschalteten Webservice gibt oder nicht, sollte ein Traceroute von außen für jede beliebige Adresse von 2a00:6020:73d7:5900:0:0:0:0 bis 2a00:6020:73d7:59ff:ffff:ffff:ffff:ffff als letzte Etappe vor deinem Router eine Adresse aus 2a00:6020:ffff:ffff::/48 aufweisen, so zumindest das Ergebnis meiner Traceroute-Analysen zu vielen anderen DG-Kundenanschlüssen. Das sehe ich für den PD-Block deines Anschlusses allerdings nie: Egal, welche beliebige Adresse aus dem Block ich wähle, das Traceroute-Ergebnis ist stets so, wie für deine WAN-Port-Adresse 2a00:6020:7380::1735 oben beschrieben.

Aber gut, vielleicht ist es unzulässig, meine Beobachtungen zu verallgemeinern, und für neuere Anschlüsse mögen sie nicht mehr zutreffen.

Nur noch eine Idee:

Ist in deiner Fritzbox der "Stealth Mode" (Diagnose | Sicherheit | Filter) aktiv? Falls ja, könnte es helfen, den mal zu deaktivieren. Dann könnte man evtl. auch die WAN-Port-Adresse deiner Fritzbox in Traceroutes sehen.