pfSense 2.4.5 hohe Last + IPv6
-
Hallo zusammen,
seit dem Update auf pfSense Version 2.4.5 und dem Umstellen meines Anschlusses auf Dual Stack, erlebe ich des öfteren Verbindungsabbrüche und hohe Latenzen.
Ich kann das Ganze leider nicht genau eingrenzen, es scheint aber so (geht aus den logs hervor), dass ein Filter Reload alles zum zusammenkrachen bringt. Nach ein paar Minuten erholt sich dann alles wieder.Erlebt jemand anderes hier auch diese Probleme?
Mit 2.4.4p3 und nur IPv4 hatte ich solche Probleme nicht.Ich beziehe ein /56 IPv6 Prefix von meinem Provider und verteile diesen in Form von /64 Prefixe auf meine lokalen Subnetze (Track interface und SLAAC auf Client Seite).
-
-
Danke für deine Rückmeldung.
Ich konnte das Ganze mittlerweile weiter eingrenzen und es kommt wohl nicht vom Filter Reload sondern passiert wenn ich irgendetwas am Routing verändere.
So ziehen z. B. Änderungen an den dynamischen IPs mehrerer OpenVPN Endpunkte, Routing Änderungen auf der pfSense nach sich, was dieses Phänomen natürlich triggert.
Dies betrifft nicht nur meine pfSense sondern auch die andere Seite. Mit anderen Worten: Setze ich den OpenVPN Tunnel auf Disabled geht bei mir UND auf der anderen Seite (ebenfalls pfSense Version 2.4.5) die CPU Last durch die Decke - da jetzt ja die entsprechenden Routen aus der Routing Tabelle gestrichen werden.
Ich habe jetzt mal einen Tunnelpartner auf IPSec umgestellt (da werden ja keine Routen gesetzt sondern diese Kernel SAs benutzt), und siehe da, das Problem tritt hier nicht mehr auf.
Hast du das Issue Ticket erstellt? Falls ja auf jeden Fall danke schonmal :)
-
Ja das Ticket ist von mir. Und ja, wann es auftritt, ist irgendwie noch sehr diffus. Bei mir tritt es leider sehr "random" auf. Manchmal läuft die Kiste viele Stunden ohne Probleme, meist kommt das Problem aber schon während des bootens. Bei mir hilft es auch, den "dpinger" Dienst zu stoppen, dann läuft es erstmal wieder. Bei mir ist neben pfctl aber auch dpinger so hoch in der Last. Bei anderen ist es dagegen wohl ntpd, unbound, oder noch anderes. Wenn das Problem erst einmal auftritt, geht es auch nicht wieder (außer bei Deaktivierung von dpinger) und kommt sofort wieder, wenn ich dpinger wieder aktiviere.
Aber probier' mal den Workaround aus. Dann zeigt sich, ob es bei dir wirklich das gleiche Problem ist.
-
Ich konnte mein Problem per Neuinstallation und zurückspielen eines Backups beheben.
Irgendwas muss der Update Prozess kaputt gemacht haben, IPv6 ist somit auch nicht das Problem gewesen.
-
Dann beobachte mal... bei mir hat es das Problem auch erst gelöst, habe ich nämlich auch probiert, nach weniger als einem Tag kam es aber zurück...
-
Hatte das Problem glaube ich gerade schon wieder. Ich glaub ich dreh durch.
Last und Latenz + Paketverluste. Das kann doch wohl nicht wahr sein.
Habe mal die betreffenden Log Zeilen anghängt:
-
Ich kann das Ganze jetzt auch wieder jederzeit triggern, indem z. B. einen OpenVPN Tunnel neu starte. Oder etwas am Routing verändere.
-
Danke, ich hab den Workaround jetzt getestet und er scheint zu funktionieren (Max Firewall Entries = 65000 und Block Bogons aus). Aber das kanns doch jetzt echt nicht sein.
Hat sich Netgate dazu schon geäußert?
-
Nur mit ein paar Vermutungen und der Aussage, dass sie das Problem bisher nicht nachvollziehen können:
https://redmine.pfsense.org/issues/10414 -
Kann ich momentan auf meinem Testsystem ebenfalls nicht nachvollziehen und somit die Aussage im Ticket verstehen. Wenn es einfacher wäre das Problem konkret nachzustellen, wäre da auch sicherlich jemand im Debugging weiter. Aber momentan sehe ich das ebenfalls nicht. Trotz DualStack. Und die Max Entries halte ich für unsinnig, 65k sind für viele Anwendungen definitiv zu wenig. Zumal ich hier weder mit den alten Defaults (200k, 500k) oder dem aktuellen Wert 2Mio Probleme hatte. Ich würde hier wirklich testweise mal nur die Bogons abschalten und den Tabellenwert auf dem Default lassen, ich denke nicht, dass dieser irgendwo reinspielt. Zumal man mit 65k pfBlocker o.ä. vergessen kann da die Tabellen wesentlich größer werden.
-
Also hier waren drei der vier Installationen definitiv betroffen. Bei der vierten Installation habe ich den Workaround noch vor dem Update ausgeführt und kann daher nicht sagen, ob sie auch betroffen gewesen wäre. Auch nach einer Neuinstallation mit anschließendem Rückspielen der Config tritt das Problem auf, dann aber ggf. erst nach einigen Stunden.
Bei zwei Installationen ist IPv6 auch abgeschaltet. An IPv6 scheint es also nicht zu liegen. Die gleichen Installationen haben auch nur ein Gateway, Multi-WAN/Gateway-Failover/Load-Balancing scheint es also auch nicht zu sein - wobei es bei mir hilft, den dpinger-Service zu stoppen und somit eventuelles Gateway-Failover/... übergangsweise lahmzulegen. Zumindest, bis man den Workaround ausgeführt hat, danach darf dpinger wieder laufen.
Ich habe aber schon fast 3 komplette Tage von morgens bis abends ins Debugging und in die Suche gesteckt, ich finde aber nur Symptome, keine Ursache und hab' daher leider keine weiteren Informationen was das Debugging angeht :( Derzeit habe ich die Suche erst einmal aufgegeben. Mir fehlen Ansätze, wo ich noch Dinge ausprobieren kann - außerdem werden die Instanzen für den Produktivbetrieb benötigt, da sind die ständigen Ausfälle unpraktisch.
-
Äußert merkwürdig, ich habe hier mit Dualstack und aktivem v6 plus v6 Tunnel rumgespielt und - ohne Bogon Liste auf dem WAN - keinerlei Probleme egal was andersweitig eingestellt ist. Mit Bogons hatte ich leider nur kurz Zeit aber in der ist keinerlei Ping Problem aufgetreten. Ich hätte daher eher geschätzt, dass - sollte es ein Problem geben - wohl das Bogon abschalten auf dem WAN wohl genügt, aber da ich den Fehler leider bislang nicht reproduzieren kann, habe ich leider keinen wirklichen Beweis oder Ansatz dafür :/
-
Eventuell ist es noch wichtig zu erwähnen, dass ich meine pfSense hinter einer FritzBox in einem Transit Netz betreibe. Da ich keinen festen IPv6 Prefix kriege nutze ich die Prefix Delegierung der Fritzbox und Track Interface auf der pfSense für meine lokalen Interfaces.
-
Ach guck... da hatte ich selbst mit 2.4.4 Probleme - nicht mit hoher Last oder großem Paketverlust, aber mit dubiosem Verhalten was das Pingen über die FB angeht. Die hatte ich die ganze Zeit in Verdacht, da das Problem früher mit älteren FBs nicht auftrat. Ich habe aber seit der letzten Umstellungauf Vodafone jetzt mal testweise in der Box auf einem LAN Port den Bridge Modus aktiviert und siehe da, die pfSense hinter der FB bekommt dann eine eigene/andere public IP4 und kann sich ein v6 Netz holen, obwohl die FB trotzdem weiter rumroutet (getestet am FB WLAN, FB hat andere IP4 und anderes IP6).
Mit der Einstellung sind dann auch plötzlich die ominösen Ping Probleme mit dem dpinger verschwunden und auch andere seltsame Aussetzer... Wenn du die Option hast - ein Test ist es wert :)
