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?
-
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.
-
@mrsunfire Naja das Default Gateway ist das (einzelne), was gerade im System aktiv ist. Ggf. also das VDSL, nicht UM Gateway? Ansonsten ist das alles ziemlich verworren, wo das Problem herrühren könnte...
-
So, nachdem es nun seit gestern Abend mit dem default Gateway lief, fing plötzlich um 14:10 Uhr wieder der Paketloss an. An der Config habe ich nichts geändert.
Zudem erscheint in den Systemlogs seit heute Morgen 8 Uhr regelmäßig die Meldung:
"cannot forward src fe80:3::3138:bc66:96d5:ad08, dst 2a02:26f0:ef::5f65:4d21, nxt 6, rcvif igb2, outif igb0"Wieso? Was sagt mir das?
EDIT:
Ich habe nun explizit die pfSense als DNS Server in den Firewallregeln freigegeben, doch plötzlich kommt mein Ping nicht mehr ganz durch zu heise.de. Google.de läuft. Wie kann das sein?
EDIT2:
Es wird immer wilder. Jetzt kommt der Ping wieder durch, ist dafür jedoch durchweg 10ms höher?!
EDIT3:
OK, ich werde nun anders geroutet als zuvor, daher der höhere Ping. Doch wieso? Ich nutze noch immer die pfSense als DNS Resolver, nur diese Regel habe ich hinzugefügt:
-
@mrsunfire
Hör halt einfach auf mit dem halbgaren Unsinn. Schalte IPv6 entweder ganz ab oder hol dir einen He.net Tunnel, der kann dann auch zwischen den Gateways geswitched werden. -
Was ist daran halbgarer Unsinn? Ich habe natives IPv6 vom Provider mit /56 Prefix. Was will ich da mit einem Tunnelbroker hantieren?
-
@mrsunfire
Das hier: https://forum.netgate.com/topic/131644/mark-gateway-as-down-and-don-t-use-it
Das gleiche Problem mit unterschiedlichen Informationen in verschiedenen Threads zu diskutieren ist übrigends nicht zu empfehlen. -
Es geht dort nicht um das gleiche Problem. Das dort besprochene Problem bezieht sich auf Paketloss welcher durch Ingress im Kabelnetz entsteht und somit IPv4 sowie IPv6 sehr träge macht. Daher lasse ich auf die Telekomleitung umschalten. Diese kann ebenfalls Dualstack! Aber pfSense kann kein Failover mit dynamischen Prefixen, von daher nutze ich dort nur IPv4.
Mein Problem hier, betrifft rein IPv6 und dort nur der Traffic der aus dem LAN Interface kommt. Anderer IPv6 Traffic läuft sauber.
Siehe:
Von WAN
Von LAN
-
Interessant, wenn ich mich via IPsec auf die pfSense verbinde, ist der Paketloss weg!
Was bewirkt das also dass es dann geht?!
-
Kann hier nochmal jemand drüber schauen bitte? Vielleicht ist hier einfach der Wurm drin bei der Adressvergabe:
WAN:
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=6400bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6> ether 40:62:31:00:xx:xx hwaddr 40:62:31:00:xx:xx inet6 fe80::4262:31ff:fe00:3a5%igb0 prefixlen 64 scopeid 0x1 inet6 2a02:8071:800:0:xxxx:xxxx:9945:6ffe prefixlen 128 inet 46.223.xxx.xxx netmask 0xfffffc00 broadcast 255.255.255.255 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> media: Ethernet 1000baseT <full-duplex> status: active
LAN:
igb2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=6500bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6> ether 40:62:31:00:xx:xx hwaddr 40:62:31:00:xx:xx inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 2a02:8071:886:5200:4262:xxxx:xxxx:3a7 prefixlen 64 inet6 fe80::1:1%igb2 prefixlen 64 scopeid 0x3 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet 1000baseT <full-duplex> status: active
Von Extern kann ich auf die WAN IPv6 pingen ( 2a02:8071:800:0:xxxx:xxxx:9945:6ffe ). Die LAN IPv6 jedoch nicht, bzw. nur mit viel Paketloss ( 2a02:8071:886:5200:4262:xxxx:xxxx:3a7 ). Genauso verhält es sich mit den Clients, diese erreiche ich auch kaum. Die Clients jedoch können auch die WAN IP sauber pingen. Sprich auf dem WAN Interface wird nicht sauber geroutet, oder?
Regeln sind eigentlich alle offen. (ICMPv6 any any)
-
Ich hab das Problem gelöst! Musste jedoch das komplette Setup ändern. Nun fordere ich nur noch ein /56 Prefix an, keine IP mehr und nutze zum verteilen den DHCPv6 Server im LAN. Dadurch làuft es nun sauber.
Wieso Unitymedia hier komplett anders ist weiß ich jedoch nicht.