Unerklärlicher Packetloss nur bei IPv6
-
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?
-
WAN und LAN reicht, Floating wäre ja nur für beide Interfaces zusammen. Nutze das ungern, weil Floating VOR Gruppen und Einzelinterfaces abgearbeitet wird und dadurch gern die Reihenfolgen durcheinander bringt ;) Aber ja, wenn überall offen, dann sollte das kein Thema sein.
-
OK dann werde ich das nun mal so austesten und berichten. Es irritiert mich nur dass es mit der VDSL Leitung sauber läuft und nur mit der Unitymedia Leitung die Probleme gibt. Weiterhin kann ich selbst wenn vom LAN nur noch Packetloss ist, von der pfSense selbst wenn ich WAN Interface wähle pingen. Wähle ich das LAN Interface, habe ich den exakt gleichen Paketloss.
-
-
Danke! Was genau bewirkt das und kann das Nachteile haben?
Wie es scheint entsteht mein Problem sobald ich mein Failover Gateway bei IPv6 nutze. Lösche ich das Gateway und setze es nicht in den IPv6 Firewallregeln, habe ich seither keinen Packetloss mehr. Doch warum ist das nur bei der Unitymedia Leitung ein Problem und bei der Telekom nicht?
-
Nachdem die Dokumentation der Pfsense sehr ausführlich und genau ist (Sarkasmus aus) …. steht eh alles da. Kann mir schon Nebenwirkungen vorstellen, z.B. bei schrägen Angriffen. Aber einen Versuch ist es wert. Warum die zwei unterschiedlich sind, können dir nur die ISP beantworten. Allerdings müsste man langsam wirklich die gesamte FW Konfig durchschauen, ob da noch andere Punkte sind.
-
Also das hat leider keinen Unterschied gebracht. Ich kann es jedoch reproduzieren wenn ich das Failovergateway in die Rules setze oder nicht. Mit default läuft es! Doch wieso, wo ist der Haken?
Falls Du Teamviewer hast, könnte ich anbieten dass Du mal drüber schaust.
