Unitymedia MTU IPv6

[addicted]

Wie es scheint versucht die pfSense Link Local Adressen mit dem dahinterliegenden Interface (%igb0) zu routen, was dann natürlich durch Bogon geblockt wird.

Wieso "natürlich"?
1. Link Local-Adressen sind keine Bogons.
2. Link Local-Adressen werden nicht geroutet. Daher der Name.
3. Die Angabe des Interfaces ist bei Link Local-Adressen vorgesehen, wenn es mehr als ein Interface gibt. Also quasi immer.

 

[rv112]

Wieso meine pfSense das versucht weiß ich nicht. Es ist absolut nicht erklärbar, doch es ist so. Mit einem frischen Setup auf anderer Hardware kann ich das Probleme nachstellen. Vielleicht kommen bei mir mehrere Dinge zusammen dass sowas passiert.

 

[rv112]

So, nach einigen Tagen wo es problemlos lief, fing es heute wieder an teilweise gar nicht mehr zu gehen, trotz dass die Bogons erlaubt sind. Ich bin am verzweifeln was das Problem ist.

Ich habe der Einfachheit halber Google Maps und Youtube getestet indem ich auf meiner Netzwerkkarte in Windows abwechselnd IPv4 und IPv6 only aktiviert habe. Ergebnis: mit IPv6 läuft alles deutlich schlechter. Maps braucht teilweise ewig bis die Karten laden, Youtube Videos stocken usw. Mit IPv4 flutscht es. Dabei trat jedoch kein Packetloss auf, obwohl das Problem teilweise auch wieder zurück ist.

Ich bin inzwischen auf dem Stand IPv6 bei Unitymedia nicht nutzen zu können, da es einfach nur Probleme macht. Die Telekomleitung läuft dabei anstandslos mit IPv6. Ich würde mir ja wünschen dass es an meiner Hardware liegt, aber das scheint nicht der Fall.

Nachtrag:

Ich bin nun sogar so weit gegangen und habe das Modem direkt an den PC angeschlossen um die pfSense komplett auszuschließen. Das Ergebnis blieb gleich. IPv6 läuft mehr schlecht als Recht, schade.

 

[tux1337]

Ich hatte heute ebenfalls wieder Probleme mit IPv6 Verbindungen. Hauptsächlich Bilder in Facebook laden nicht.
Konnte herausfinden, das der ping auf meine IPv6 Adressen deutlich höher ist (ca. Doppelt so hoch) wie bei IPv4.
Hatte dann nochmal in diesem Thread nachgelesen und festgestellt, das du auf WAN Bogon deaktiviert hast. Das hatte ich noch an. Lediglich in den LAN Netzen hatte ich es aus.
Hab dann Bogon deaktiviert (hatte blocked States drauf) und eigentlich gehofft es damit gelöst zu haben.

Wenn du jetzt allerdings heute trotz deaktivierten Bogon Probleme hattest und das zur gleichen Zeit. (Bei mir ca. 11-12Uhr),
Vermute ich dass das Problem eher im Netz von Unitymedia zu suchen ist. Ich habe leider keine Traceroutes erstellt um zu sehen wo die Latenzher kommt bzw. Worüber ich geroutet werde.

Wir kommen auch beide aus Baden-Württemberg und dürften damit ein ähnliches Routing haben.


Meine pfsense hat leider auch sehr hohe load Werte (>4.0) wenn ich IPv6 Tracking am WAN Interface aktiviere. Mehrere Php-fpm Prozesse sind dann auf 100% CPU. Das lässt sich nur dur h ein Reboot lösen. Ist dann aber auch nur weg, wenn die ConnectBox gleichzeitig Neustartet.
Hatte das früher schon mal mit FritzBox und Ipv4 only.
Da aber nur wenn die Fritzbox neugestartet ist und die pfsense weiter lief.


Hatte testweise mal einen he.net ipv6 Tunnel in Betrieb. Da der aber auf 10Mbit mittlerweile limitiert ist, ist das für mich keine Option.

 

[rv112]

Aktuell läuft v6 wieder! Geändert habe ich nix...

 

[tux1337]

Aktuell läuft v6 wieder! Geändert habe ich nix...

Nachdem du das direkt am Modem auch hättest, kann man die pfsense als Ursache ausschließen.
Wir haben unterschiedliche Modems, ebenfalls ein Ausschlusskriterium.
Zwei Anschlüsse zur gleichen Zeit deuten da doch auf ein Thema bei Unitymedia hin.

Ich fürchte eine Nachfrage bei Unitymedia ob es sporadisch IPv6 Probleme in deren Netz gibt wird wohl nichts bringen.

Vielleicht setze ich mal ein Rolling Netzwerktrace auf, dann wäre es mal aufgezeichnet wenn es wieder passiert.

 

[rv112]

Jop das wäre klasse! Was mir auffällt: die pfSense kann von sich aus immer Pings absetzen, auch wenn es die Clients nicht können. Die pfSense hat jedoch auch eine eigene /128 IP während die Clients sich aus dem /56 Pool bedienen müssen. Vielleicht spielt das auch eine Rolle. Ich habe den Verdacht dass die UM Router teilweise den Rückweg zum Client nicht mehr finden.

 

[rv112]

Ich hab nun mal test weise etwas an der MTU gespielt und mittels Ping ein paar Werte ermittelt. Pings gehen durch für IPv4 bist 1472 byte und IPv6 1452. Danach bekomme ich keine Antwort mehr, oder den Hinweis "Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt."

Doch was nun? In der pfSense steht die MTU auf Auto und somit 1500. Wenn ich diese manuell ändere, ändert sie sich sowohl für IPv4 als auch IPv6.

 

[Wechseler]

Ich hab nun mal test weise etwas an der MTU gespielt und mittels Ping ein paar Werte ermittelt. Pings gehen durch für IPv4 bist 1472 byte und IPv6 1452. Danach bekomme ich keine Antwort mehr, oder den Hinweis "Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt."

Das paßt schon: 1472 (Payload) + 8 (ICMP header) + 20 (IPv4 header) = 1500.

Bei IPv6 ist der IP-Header statt dessen 40 Octets lang, bleibt entsprechend weniger für den Payload.

 

[rv112]

OK, nun steht die MTU aber auf 1500 für IPv4 und IPv6. ICMPv6 Type 2 Packet too big bekomme ich keine. Heißt es funktioniert alles wie es soll? Normal sollte die MTU für v6 doch automatisch ausgehandelt werden?

 

[Andreas1969]

OK, nun steht die MTU aber auf 1500 für IPv4 und IPv6.

Ist doch korrekt :winken:

 

[rv112]

OK, war nur ne Überlegung. Man hält sich ja an allem fest

 

[tux1337]

MTU Probleme (auf deiner Seite) kannst du aus meiner Sicht ausschliessen. Andernfalls müsste das Problem dauerhaft bestehen und reproduzierbar mit allen Routen auftreten.

 

[tq1199]

Wenn ich diese manuell ändere, ändert sie sich sowohl für IPv4 als auch IPv6.

Bist Du sicher? Denn z. B. in Linux kann man unterschiedliche MTUs (für IPv4 bzw. IPv6) konfigurieren.

<i>
</i>net.ipv6.conf.wlan0.mtu = 1280

Warum soll das mit pFsense nicht möglich sein?

 

[rv112]

Ok via Script eventuell. Im Web GUI kann man es nicht.

 

[rv112]

Und es geht wieder los!

C:\Users\rv112>ping -t heise.de
Ping wird ausgeführt für heise.de [2a02:2e0:3fe:1001:302::] mit 32 Bytes Daten:
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=8ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=8ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=8ms

 

[lupus]

Verwendest du zufällig DNSSEC? Wenn das aktiv ist, habe ich auch manchmal Probleme. Ist das abgeschaltet, läuft alles prima. Bin mir da jetzt nicht sicher ob das am pihole liegt oder doch an UM.

 

[rv112]

Habe ich mit beidem getestet. Tritt sowohl als auch auf. Ich habe auch mit Resolver und mit Forwarder getestet, ebenfalls mit Google DNS, Quad9 DNS und Cloudflare DNS. Es macht leider keinen Unterschied.

 

[rv112]

Ich fahre nun zweigleisig um einfach weiter zu testen indem IPv4 über Unitymedia läuft und IPv6 über die Telekomleitung. Bisher läuft IPv6 damit einfach wunderbar sauber und auch Google Maps ist ultra schnell und das obwohl es nur 25 MBit/s sind. Kein Vergleich zu Unitymedia. Was kann denn nun das Problem sein? Ich behaupte es liegt an Unitymedia die es nicht gebacken bekommen mir sauber laufendes IPv6 zur Verfügung zu stellen. Es ist zum Haare raufen...

Unitymedia hat jetzt völlig den IPv6 Betrieb bei mir eingestellt, ich bekomme nicht mal mehr ein Prefix geschweige denn eine IP zu gewiesen :hirnbump:

 

[tux1337]

Ich habe das Problem heute Abend leider auch schon wieder. Hab nun mal nen Ping mit laufen lassen und sehe normale latenzen mit einzelnen Packet loss.

Habe IPv6 nun in meinen Client Netzen deaktiviert und werde es in meinem Server Netz weiter analysieren.
Ich setze nachher mal ein Test auf.

@rv122
Habe gesehen du hast das Problem auch in der Unitymedia Community gepostet.
Habe daraufhin dort mal gesucht und einen unbeantworteten Beitrag gefunden, der letztlich ein ähnliches Problem beschreibt:
https://community.unitymedia.de/categories/internet/question/ipv6-connectivity-gestoert

 

[rv112]

Schön dass ich nicht allein bin! Nun läuft es wieder...

 

[tux1337]

Ich hab mittlerweile Smokeping aufgesetzt und überwache jeweils die IPs (v4 und v6) von
Cloudflare
Facebook
Google

Bisher hatte ich keine Probleme mehr und das bestätigt auch der Graph. Keine Verluste oder Latenzausreiser.

 

[rv112]

Ich lasse nun auch mal Pingplotter mitlaufen auf google.de in 1s Takt.

Momentan läuft es zwar ganz gut, doch ganz Packetlossbefreit bin ich noch nicht. Interessant ist das Muster dahinter:


So sieht es mit der VDSL Leitung aus. Die WAN Einstellungen sind dabei identisch, bei beiden fordere ich ein /56 Prefix an:

 

[rv112]

Es gibt Neuigkeiten! Ich nutze ja eine Gatewaygruppe als Failover. Lösche ich diese Gruppe und definiere in den IPv6 Firewallregeln kein Gateway, tritt kein Packetloss mehr auf! Zumindest seit einer halben Stunde nun...

Doch wieso nur bei UM? Bei der Telekom läuft es auch mit der Gatewaygruppe.

 

[JurgenS]

Hallo,
habe den Thread soeben entdeckt, da ich nach einer Lösung für mein identisches Problem googelte.
Ich habe ebenfalls 2 Play FLY 400/40 DS, TC4400 und pfSense 2.4.3-RELEASE-p1
Dahinter habe ich noch eine FritzBox im AcessPoint Modus und sitze per WLAN an meinen Ubuntu Laptop. Auch hier war IPv6 soeben schlecht bis zur Unerreichbarkeit.

Ich konnte es scheinbar lösen, indem ich in der pfSense das WAN Interface deaktiviert und kurz danach wieder aktiviert hatte. Vielleicht hat das Entfernen des Bogus-Hakens etc. bei Euch auch nur dadurch geholfen, da das WAN Interface dadurch neu gestartet wurde?

Naja, da es bei mir erstmalig auftrat und scheinbar gelöst ist habe ich noch keine weiteren Lösungsansätze, wollte mich aber wenigstens mal gemeldet haben.

LG Jürgen