Unitymedia MTU IPv6

[rv112]

Hallo!

Ich habe seit ich IPv6 nutze gelegentlich Probleme dass IPv6 langsam bzw. schlecht läuft. Genauer kommt es zu Packetloss, wobei IPv4 funktioniert.
Kann es sein dass UM bei IPv6 eine andere MTU als 1500 nutzt?

 

[Wechseler]

IPv6 ist auf PMTUD angewiesen, da das Netzwerk bei IPv6 nicht mehr fragmentiert. Damit PMTUD einwandfrei funktioniert, ist es erforderlich, daß ICMPv6 einwandfrei durchkommt.

 

[rv112]

ICMPv6 ist komplett offen und geht ja auch, nur eben nicht immer. Vielleicht ist es auch ein Bug der pfSense. Von der pfSense aus läuft es gut, nur die Clients haben Probleme und zwar alle gleichermaßen. Pinge ich von WAN aus läuft es, pinge ich von LAN aus kann es manchmal nicht laufen. Ich erkenne jedoch kein Schema dahinter. Das ganze passiert völlig willkürlich.

 

[Andreas1969]

Vielleicht ist es auch ein Bug der pfSense.

Ja, vermutlich.
Ich konnte da bisher nichts feststellen, läuft soweit alles Rund (IPV4, sowie IPV6) :smile:
Bei Packetloss hätte ich sonst sofort Probleme bei der Telefonie, da ich mir per V6 2 Telefonnummern eines anderen Anschlusses rüberschaufle, die bei uns als Hauptnummern genutzt werden. Seitdem ich DS Stack habe, läuft das sowas von perfekt. :super:
Vorher mit IPV4 only gab´s da immer leichte Probleme, da alles über den HE Tunnel lief (Sprachqualität hat durch die erhöhte Laufzeit der Pakete gelitten). Nun ist´s aber perfekt.

 

[chris_86]

Komisch. Ich habe zwei UM-Anschlüsse.
Bei dem mit DSLite ist ICMPv6 offen, bei dem mit DS ist ICMPv6 "filtered" (laut ipv6-test.com, am selben Endgerät).
Wofür genau ist das wichtig? Und woran kann es liegen, dass es bei mir mit DS nicht geht?

 

[Menano]

Ich habe genau die gleichen Probleme wie rv112. Wird nicht an der pfSense liegen. Mittlerweile hat es sich wieder etwas gebessert aber läuft immer noch nicht top. :winken:

 

[rv112]

Kommst Du auch aus BW?

 

[Menano]

Ja. Hatte schon lang Dualstack. Die Probleme mit Ipv6 habe ich seit Anfang 2018. :winken:

 

[Andreas1969]

Also lässt sich das Problem auf BW einschränken :kratz:
Liegt vielleicht am 56er Prefix

Wir in NRW und Hessen haben ja nen 59er :winken:

 

[rv112]

Scheint so. Wenn ich ein 59 anfordere zickt jedoch UM

 

[tq1199]

..., nur die Clients haben Probleme und zwar alle gleichermaßen.

Teste mal ob die Clients evtl. per icmpv6 type 2, die Nachricht "packet too big" bekommen, mit Z. B.:

<i>
</i>tcpdump -vvveni <Interface> icmp6 and '(ip6[40] == 2)'

(oder gleichwertig).

 

[why_]

Ich hab meinen Anschluss ebenfalls in BW und keinen packet loss, per v6. Scheint also kein generelles Problem im BW Netz zu sein.

 

[rv112]

Ich hab das jetzt noch mal nachgestellt. Ich lasse einen IPv6 Ping laufen der sauber durchläuft. Sobald ich dann auf der Seite test-ipv6.com einen Test starte, bricht der Ping ab und der Test bringt auch Fehler. In Wireshark sieht es dann zu dem Zeitpunkt wie folgt aus:

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=10ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=5ms
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.
Zeitüberschreitung der Anforderung.
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=5ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=10ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms
Zeitüberschreitung der Anforderung.
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=8ms
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
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms
Ping-Statistik für 2a02:2e0:3fe:1001:302::: Pakete: Gesendet = 19, Empfangen = 12, Verloren = 7 (36% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 5ms, Maximum = 10ms, Mittelwert = 8ms

 

[rv112]

Hmm der Test bei http://n2.netalyzr.icsi.berkeley.edu bringt mir u.A. das Ergebnis:

"Pfad-MTU für IPv6 (?): Warnung –


Ihr Rechner kann fragmentierten IPv6-Verkehr senden, aber nicht empfangen. Der Pfad zwischen unserem Server und Ihrem Netzwerk scheint fragmentierten IPv6-Verkehr nicht korrekt zu handhaben. "

Doch was tun? ICMP ist für IPv6 komplett offen auf WAN und LAN :kratz:

 

[Edding]

Sieht mir nach nem problem mit deiner pfsense aus ..
Würds mit nem Thread im dortigen Forum probieren

 

[carknue]

Komisch. Ich habe zwei UM-Anschlüsse.
Bei dem mit DSLite ist ICMPv6 offen, bei dem mit DS ist ICMPv6 "filtered" (laut ipv6-test.com, am selben Endgerät).
Wofür genau ist das wichtig? Und woran kann es liegen, dass es bei mir mit DS nicht geht?

Bei mir (DS in Hessen) steht da auch "filtered". Bei dem Ping Test auf der Seite läuft nur die IPv4 Test, der IPv6 Test liefert 100% loss.

Allerdings kann ich die zwei Terminal Fenster aufmachen und parallel einen Pingv4 und PingV6 ohne Probleme laufen lassen.

 

[rv112]

Bei mir geht der Test durch, bis auf Hostname. ICMP ist reachable. Was habt ihr bei Hostname eingetragen dass der mitgeschickt wird?

 

[carknue]

Hostname habe ich nur bei IPv4. IPv6 ist "None". Score ist 17/20.

 

[rv112]

Achso ok. Ich komme auf 19/20 weil mir der Hostname fehlt. Dennoch immer wieder random Packetloss.

 

[rv112]

@tq1199 hast Du noch eine Idee? Ich musste nun IPv6 deaktivieren da fast gar nichts mehr ging. Gefühlt wird es schlimmer wenn man IPv6 Dienste nutzt. Ist die Leitung "frisch" läuft es gut, sobald man aber dann z.B. Google Maps intensiv nutzt wird es immer schlimmer bis man die pfSense neu startet.

 

[tux1337]

Ich hatte das selbe Problem mit ähnlichem Setup.
Bei mir läuft pfSense 2.4.3-RELEASE-p1 hinter einer ConnectBox mit Prefix Delegation über Tracking Interface.

Komme ebenfalls aus Baden-Württemberg.


Meine Connectbox hat letzten Montag auf einmal keinen 60er Prefix mehr delegiert. Ich habe dann auf /61 umgestellt, da ich das noch delegiert bekommen habe.
Ich vermute, dass Unitymedia etwas an der config geändert hat oder es am Update auf p1 der pfsense liegt. (Wobei ich nach Update noch nen /60 bekommen habe)

Seit dem habe ich jedoch keine Probleme mehr.

Zusätzlich habe ich zwei Firewall Regeln aufs WAN Interface gelegt:
Allow IPv6 ICMP echoreq und toobig: Source *; Destination LAN Netze


Siehst du auf deiner Regel für ICMPv6 das dort Firewall States/Bytes auflaufen wenn du die Tests durchführst?

 

[rv112]

Ich habe eine Floating Rule mit IPv6 ICMP Source any und destination any. Eine IP bekomme ich sauber zugewiesen und auch ein /56 Netz wird mir zugeteilt welches sich die pfSense dann in /64er Netze zerlegt. Ich teste mal Deine Regeln. Wie hast Du unter Services/DHCPv6 Server Deine Router advertisements eingestellt? Ich habe auf Assisted. Und forderst Du auf WAN ein Prefix an? Ich fordere ein /56 an.

EDIT: macht leider keinen Unterschied. Auf den beiden Firewallrules läuft allerdings auch kein Traffic auf :kratz:

EDIT2: wenn ich von extern einen Ping laufen lasse, läuft auf der echoreq Traffic auf.

 

[tq1199]

... dann z.B. Google Maps intensiv nutzt wird es immer schlimmer ...

Teste mal welche Auswirkungen/Folgen ein größerer Download per IPv6 hat, mit z. B.:

<i>
</i>wget -6 -c -O /dev/null http://mirror.de.leaseweb.net/speedtest/10000mb.bin

 

[rv112]

--2018-05-27 07:17:49-- http://mirror.de.leaseweb.net/speedtest/10000mb.bin
Resolving mirror.de.leaseweb.net (mirror.de.leaseweb.net)... 2a00:c98:2030:a034::21
Connecting to mirror.de.leaseweb.net (mirror.de.leaseweb.net)|2a00:c98:2030:a034::21|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10000000000 (9,3G) [application/octet-stream]
Saving to: '10000mb.bin.1'
10000mb.bin.1 8%[===> ] 810000mb.bin.1 8%[===> 10000mb.bin.1 8%[===> 10000mb.bin.1 8%[===> 10000mb.bin.1 8%[===> 10000mb.bin.1 8%[===> ] 10000mb.bin.1 8%[===> ] 8010000mb.bin.1 8%[===> 10000mb.bin.1 8%[===> 10000mb.bin.1 8%[===> 10000mb.bin.1 8%[===> 10000mb.bin.1 8%[===> 10000mb.bin.1 9%[===> 10000mb.bin.1 9%[===> 10000mb.bin.1 9%[===> 10000mb.bin.1 9%[===> 10000mb.bin.1 9%[===> 10000mb.bin.1 9%[===> ] 911,60M 16,9MB/s eta 3m 36s
10000mb.bin.1 19%[========> ] 1,82G 50,4MB/s eta 3m 12s ^C

Der Download läuft soweit einwandfrei wie es keinen Packetloss gibt. Es wird dadurch aber auch nicht schlimmer. Ich vermute eher dass es die vielen Anfragen sind von Google Maps. Wenn ich mich ganz langsam durch Maps bewege, geht es. Je schneller ich das mache oder dabei noch Streetview nutze, bricht IPv6 teils komplett zusammen.

Hier noch der Pinggraph während des Downloads. Den Abbruch bei 8% des Downloads sieht man hier recht deutlich.

 

[rv112]

Ich habe nun mal 24 abgewartet bevor ich hier wohl des Rätsels Lösung poste, welche ich mir jedoch nicht erklären kann. IPv6 läuft nun (bisher) ebenfalls sauber, das einzige was ich verändert habe war den Haken bei Block Bogons im WAN nicht zu setzen. Eventuell nur ein Bug der pfSense, oder irgendetwas passiert bei meinem Routing dass es hier zu Adressen die nicht spezifiziert sind kommt. In den Logs kann ich dazu jedenfalls nichts finden, habe aber eine Vermutung. Wie es scheint versucht die pfSense Link Local Adressen mit dem dahinterliegenden Interface (%igb0) zu routen, was dann natürlich durch Bogon geblockt wird. Warum sie das jedoch nur manchmal und unwillkürlich tut weiß ich nicht.

Ich bin erstmal zufrieden und verfolge das Problem im offiziellen Forum weiter, vielleicht liegt es jedoch auch nur bei mir bzw. meinem Setup.