Unerklärlicher Packetloss nur bei IPv6
-
Hallo!
Ich habe einen Unitymedia Anschluss mit Dualstack und reinem Modem. WAN ist mit DHCP konfiguriert und LAN als Track Interface. Beide Interface bekommen eine IPv6 und auch die Clients im LAN erhalten eine IPv6. Startet man die pfSense neu läuft der Anschluss gut, doch plötzlich und völlig willkürlich wird IPv6 merklich langsamer und es kommt zu Packetloss:
Ping wird ausgeführt für heise.de [2a02:2e0:3fe:1001:302::] mit 32 Bytes Daten: Zeitüberschreitung der Anforderung. Zeitüberschreitung der Anforderung. Antwort von 2a02:2e0:3fe:1001:302::: Zeit=10ms Zeitüberschreitung der Anforderung. Zeitüberschreitung der Anforderung. Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms Zeitüberschreitung der Anforderung. Zeitüberschreitung der Anforderung. Antwort von 2a02:2e0:3fe:1001:302::: Zeit=11ms Antwort von 2a02:2e0:3fe:1001:302::: Zeit=8ms Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9ms Antwort von 2a02:2e0:3fe:1001:302::: Zeit=8ms 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=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=8ms Antwort von 2a02:2e0:3fe:1001:302::: Zeit=10ms Zeitüberschreitung der Anforderung. Zeitüberschreitung der Anforderung. Ping-Statistik für 2a02:2e0:3fe:1001:302::: Pakete: Gesendet = 27, Empfangen = 9, Verloren = 18 (66% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 8ms, Maximum = 11ms, Mittelwert = 9ms```IPv4 läuft dabei sauber und völlig problemlos. Wenn ich von der pfSense aus einen Ping starte mit WAN Interface, läuft es ohne Probleme und ohne Packetloss. Setze ich LAN als Quelle des Pings, erhalte ich den gleichen Packetloss wie die Clients. Firewallregeln ist ICMPv6 komplett offen und auch der Test bei ipv6-test.com gibt mir 19/20 Punkten.
Was kann hier das Problem sein? Ich weiß nicht weiter.
-
Hallo,
Unitymedia Dualstack doch nur in BaWü? Bist du sicher, dass du das hast?
Ich hab einen IPV6 Tunnel via Tunnelbroker. Allerdings löst bei mir heise.de anders auf und ich bekomme pings von :
Ping wird ausgeführt für www.heise.de [2a02:2e0:3fe:1001:7777:772e:2:85] mit 32 Bytes Daten:
Antwort von 2a02:2e0:3fe:1001:7777:772e:2:85: Zeit=35ms
Antwort von 2a02:2e0:3fe:1001:7777:772e:2:85: Zeit=34ms
Antwort von 2a02:2e0:3fe:1001:7777:772e:2:85: Zeit=33ms
Antwort von 2a02:2e0:3fe:1001:7777:772e:2:85: Zeit=35msBist du auf der letzten Pfsense Version? Welche HW verwendest du denn ? Eventuell ein lokales Problem mit HW/Buffer/Memory?
MfG
-
DS kann man inzwischen immer beantragen wenn man den Power Upload bucht. Da ich aus BW komme, bekomme ich ein /56 zugeteilt, das passt soweit auch. Eigentlich passt alles und die pfSense mit aktuellster Version wirft keine Fehler aus. Momentan läuft es auch einwandfrei, doch urplötzlich geht es dann los und der Packetloss bei IPv6 beginnt.
Wenn ich statt heise.de wie Du www.heise.de anpinge, komme ich zu selbem Ergebnis:
Ping wird ausgeführt für www.heise.de [2a02:2e0:3fe:1001:7777:772e:2:85] mit 32 Bytes Daten:
Antwort von 2a02:2e0:3fe:1001:7777:772e:2:85: Zeit=8ms
Antwort von 2a02:2e0:3fe:1001:7777:772e:2:85: Zeit=8ms
Antwort von 2a02:2e0:3fe:1001:7777:772e:2:85: Zeit=8ms
Antwort von 2a02:2e0:3fe:1001:7777:772e:2:85: Zeit=9msPing-Statistik für 2a02:2e0:3fe:1001:7777:772e:2:85:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 8ms, Maximum = 9ms, Mittelwert = 8msIch verwende einen Qotom i5 Mini PC mit 4x Intel NIC's.
https://www.amazon.com/Qotom-Q355G4-Firewall-Ethernet-Barebone-Computer/dp/B06XJV9R8X -
Also wenn das die meiste Zeit funktioniert, dann könnte es auch sein, dass ein HW Problem vorliegt. Eventuell mal eine Pfsense mit einer virtualisierten Umgebung auf einem PC aufsetzen (VMware oder VirtualBox), die Konfig dort einspielen und testen. Wenn der Fehler mitwandert liegt es an der Pfsense SW. Ist es in der VM gut, dann könnte ein HW Problem am Qotom vorliegen. IPv6 Support ist noch immer ein Problem, da bleibt oft nur probieren. Ansonsten bleibt noch ein Kabel/Switch/Modem Problem, das unabhängig von Pfsense und Qotom auftritt. Ist der Fehler mit einem Pfsense reboot behebbar? Oder musst du die HW resetten?
Aber es gibt da noch andere mit dem Problem: https://forum.netgate.com/topic/122179/lan-clients-cannot-use-ipv6-after-some-time
-
Ich habe das Problem nun relativ gut eingedämmt indem ich am WAN die Bogons nicht mehr blockiere. Ich kann es mir nicht erklären wieso das einen Unterschied macht, aber den macht es. IPv6 läuft nun deutlich besser.
Das Modem kann ich ausschließen, ein zweites hat das gleiche Problem. Die pfSense habe ich ebenfalls auf einer APU aufgesetzt und getestet, selbes Ergebnis. Reboote ich die pfSense, lief es wieder gut und wurde dann mit zunehmender IPv6 Aktivität, besonders bei Google Maps, stetig schlimmer.
-
@mrsunfire OK das klingt sehr schräg. Könnte die Kiste ggf. mit der Bogon Liste nicht klarkommen (zu groß)? Schade, dass man da nicht wirklich gut mitloggen kann, was in der Fehlerzeit auf dem Interface passiert. Evtl. gibt es von Adressen aus dem Bogon Bereich vielleicht ICMP6 Nachrichten mit Redirects o.ä.?
-
Ich bin überfragt. Das mit den Bogonslisten glaube ich nicht. An Hardwarepower mangelt es nicht. Auch ein Packetcapture bringt nur wenig Aufschluss. Einzig was mir auffällt dass einige Packete im Störfall ein SYN flag haben und sehr viele RA auflaufen. Ob das normal ist kann ich nicht beurteilen.
-
Ich habe hier noch etwas interessantes gelesen, was es evtl. auch bei mir erklären könnte:
"Since link-local addresses are used by DHCPv6 client and server, the incoming DHCPv6 traffic is blocked by the IPv6 bogon rule.
When I disable "Block bogon networks" under "Interfaces" -> "WAN" and reboot the firewall, PD works."Quelle: https://github.com/opnsense/core/issues/1331
-
@mrsunfire Das klingt insgesamt ja sehr vielversprechend, wobei ich mir dann die Frage stelle, warum die Verbindung über Zeit so schlecht wird und nicht gleich zu Beginn schon. grübel
-
Leider tritt das Problem seit heute wieder auf! Trotz dass Bogons erlaubt sind...
Ich bin am verzweifeln.
-
Hallo,
was mir dazu noch einfällt, wäre die mtu am wan probehalber mal runter zu setzen. Zweitens die pings mit langer load 1000 Bytes oder so zu versuchen. Wenn sich was ändert, kann das doch auf Probleme im WAN hindeuten.
-
Also bei IPv6 komme ich bis 1452 byte:
C:\Users\rv112>ping heise.de -6 -l 1452
Ping wird ausgeführt für heise.de [2a02:2e0:3fe:1001:302::] mit 1452 Bytes Daten:
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=11ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=11ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=10ms
Antwort von 2a02:2e0:3fe:1001:302::: Zeit=9msPing-Statistik für 2a02:2e0:3fe:1001:302:::
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 9ms, Maximum = 11ms, Mittelwert = 10msBei IPv4 1472:
C:\Users\rv112>ping heise.de -4 -f -l 1473
Ping wird ausgeführt für heise.de [193.99.144.80] mit 1473 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.Ping-Statistik für 193.99.144.80:
Pakete: Gesendet = 2, Empfangen = 0, Verloren = 2
(100% Verlust),Was sagt mir das nun? An der MTU habe ich in der pfSense nichts gemacht. Laut der Statusseite sind alle Interfaces auf MTU 1500.
-
Du könntest die mtu am Interface auf 1450 setzen und beobachten, ob sich der packetloss in den nächsten Stunden verbessert. Wenn das passt, kannst du es ja lassen.
-
Problem ist dass es momentan wieder gut ist und ich keinen Packetloss habe. Das ist es ja, es ist kein System dahinter erkennbar, daher vermute ich dass das Problem bei Unitymedia liegt. Aber ich teste das mit der MTU sobald es wieder Packetloss gibt.
-
So aktuell geht es wieder los. Ich habe nun WAN auf 1450 und LAN auf 1280 gesetzt, bringt jedoch auch nicht wirklich was.
-
Hallo,
gibt es eine Maßnahme, die hilft, in Zeiten des Paketloss, die Situation zu verbessern? Also Reboot der Pfsense oder Modem Reboot?
Manche WAN Router verwerfen schon mal ICMP Pakete, wenn unter Stress, da kann auch Qos im WAN Bereich mitspielen, deswegen der ping test mit langer payload, wenn Paketloss auftritt. Wenn die langen Pakete nicht verworfen werden und die kurzen schon, wäre es ein möglicherweise ein normales Verhalten.Wenn das alles nix hilft, würde ich einen Thread im englischen Teil aufmachen und versuchen, damit Aufmerksamkeit zu erregen. Vielleicht weiß noch jemand was. Nachdem das Verhalten aber nicht allgemein auffällt, dürfte der Fehler wohl individuell sein, also ISP-Modem-Pfsense. Ob man die Pfense da rausnehmen kann, ist schwer zu beurteilen. Wenn es wirklich stört, müsstest du halt auf IPv4 bleiben.
-
@pete35 daran habe ich auch schon gedacht. Ich habe seit einiger Zeit auch meine vorgeschaltete Kabel-Fritte in Verdacht ab und an die Grätsche zu machen. UM will da aber kein Problem sehen. Mein Problem ist aber, dass plötzlich die Verbindung abgrundtief schlecht wird (Packet loss >75%) und irgendwann gar kein GW mehr erreichbar ist. Neustart der FB behebt das Problem meistens, manchmal ein zweiter aber dann ist meist das Problem wieder weg. Darum habe ich da sehr stark die FB in Verdacht, aber da hadere ich noch mit UM herum ob die das irgendwann einsehen.
-
Es hilft die pfSense neuzustarten. Das Modem schließe ich aus, da es ein reines dummes Modem ist welches nichts macht als eine IP durchzureichen.
Kann es sein dass ich keine ICMPv6 Type 2 (Packet too big) Pakete erhalte? Ich habe explizit diese Regel auf dem WAN und LAN erstellt, sehe aber keinerlei Daten durch die Regel laufen. Manchmal schlägt auch der Test bei https://test-ipv6.com/ fehl weil keine großen Pakete empfangen werden konnten. Auch Netalyzr meldet hier einen Fehler:
-
Warum nicht alles ICMP6 rein lassen? Und seis nur testhalber?
-
Weil ich explizit sehen wollte ob die Type 2 überhaupt rein kommen. Ich lasse jetzt ICMP komplett durch auf WAN und LAN sowie Floating. Damit sollte ich wohl alles erschlagen haben, oder?
