3
Pfsense HA Cluster paket loss seit 2.4.4
Wir betreiben seit einigen Jahren pfsense in HA Cluster mit diversen Netzen.
Seit dem Update von 2.4.3 auf das aktuelle 2.4.4 haben wir zwei Probleme.
Das Erste ist, dass Konfigurationsänderungen nur jedes zweite Mal an der sekundären FW angewendet werden. D.h. schaltet man zum Testen eine Firewall-Regel (auf der Primären) inaktiv, dann funktioniert das beim ersten Mal (wird also auf der Sekundären auch ausgeführt), das Aktivieren dann nicht mehr. Wenn man über das Menü 'System'->'HA Sync' über den Button 'Save' manuell synchronisiert, ist dann alles wieder synchron.
Das zweite und schwerwiegender Probleme besteht darin, dass wir nun zeitweise Paketverluste haben, was sind spezielle bei VoIP-Calls durch Aussetzer und Abbrüche äußert. Bei TCP-Verbindungen fällt das eher später auf, da diese Pakete neu angefordert/verschickt werden. Die Problematik baut sich offensichtlich mit der Laufzeit der Firewall erst auf, d.h. wenn beide Firewalls frisch gestartet sind, ist alles OK. Nach spätestens einigen Tagen melden die Anwender erst vereinzelt dann vermehrt Gesprächsabbrüche. Die Firewall(s) als Veranwortliche dafür ausfindig zu machen hat uns schon viel Zeit gekostet. Das Verhalten verschwindet sofort, nachdem Beide neu gestartet wurden.
Problem 3, fällt dabei gerade noch auf, ist: Die sekundäre FW muss immer vor der primären FW neu gestartet werden, sonst ist ein dahinterliegendes (öffentlich routbares) Netz bei der HA-Übernahme (wenn die Erste für den Zeitraum des Neustarts ausfällt) nicht mehr von Außen erreichbar. Die States/Verbindungen bleiben dann trotzdem erhalten, was noch obskurer ist. Hier ist vermutlich auch der Fehler in der Geschichte zu suchen, aber wir finden ihn nicht. In diesem Fall blockt die sekundäre FW dann alle TCP-PA und TCP-FPA, aus welchem Grund auch immer.
Soweit, das mal für's Logbuch...
Vielleicht findet sind ja noch mehr Leute. Das Setup in HA betreibt ja nicht jeder, daher erwarten wir kaum Rückmeldungen.
PS.: Das Port-Flapping Problem unter 2.4.1 hatten wir auch. Sporadisch schaltete die Firewall entweder das LAN oder WAN-IF ab, kam etwa 6, 7 oder 8 mal vor insgesamt. Genug, den Switch zu verdächtigen, die Telekom zu mobiliseren und definitiv permanent mit einem ganz schlechten Gefühl nach Hause zu fahren.
Seit dem Update von 2.4.3 auf das aktuelle 2.4.4 haben wir zwei Probleme.
Das Erste ist, dass Konfigurationsänderungen nur jedes zweite Mal an der sekundären FW angewendet werden. D.h. schaltet man zum Testen eine Firewall-Regel (auf der Primären) inaktiv, dann funktioniert das beim ersten Mal (wird also auf der Sekundären auch ausgeführt), das Aktivieren dann nicht mehr. Wenn man über das Menü 'System'->'HA Sync' über den Button 'Save' manuell synchronisiert, ist dann alles wieder synchron.
Das zweite und schwerwiegender Probleme besteht darin, dass wir nun zeitweise Paketverluste haben, was sind spezielle bei VoIP-Calls durch Aussetzer und Abbrüche äußert. Bei TCP-Verbindungen fällt das eher später auf, da diese Pakete neu angefordert/verschickt werden. Die Problematik baut sich offensichtlich mit der Laufzeit der Firewall erst auf, d.h. wenn beide Firewalls frisch gestartet sind, ist alles OK. Nach spätestens einigen Tagen melden die Anwender erst vereinzelt dann vermehrt Gesprächsabbrüche. Die Firewall(s) als Veranwortliche dafür ausfindig zu machen hat uns schon viel Zeit gekostet. Das Verhalten verschwindet sofort, nachdem Beide neu gestartet wurden.
Problem 3, fällt dabei gerade noch auf, ist: Die sekundäre FW muss immer vor der primären FW neu gestartet werden, sonst ist ein dahinterliegendes (öffentlich routbares) Netz bei der HA-Übernahme (wenn die Erste für den Zeitraum des Neustarts ausfällt) nicht mehr von Außen erreichbar. Die States/Verbindungen bleiben dann trotzdem erhalten, was noch obskurer ist. Hier ist vermutlich auch der Fehler in der Geschichte zu suchen, aber wir finden ihn nicht. In diesem Fall blockt die sekundäre FW dann alle TCP-PA und TCP-FPA, aus welchem Grund auch immer.
Soweit, das mal für's Logbuch...
Vielleicht findet sind ja noch mehr Leute. Das Setup in HA betreibt ja nicht jeder, daher erwarten wir kaum Rückmeldungen.
PS.: Das Port-Flapping Problem unter 2.4.1 hatten wir auch. Sporadisch schaltete die Firewall entweder das LAN oder WAN-IF ab, kam etwa 6, 7 oder 8 mal vor insgesamt. Genug, den Switch zu verdächtigen, die Telekom zu mobiliseren und definitiv permanent mit einem ganz schlechten Gefühl nach Hause zu fahren.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 394420
Url: https://administrator.de/forum/pfsense-ha-cluster-paket-loss-seit-2-4-4-394420.html
Ausgedruckt am: 22.12.2024 um 22:12 Uhr
3 Kommentare
Neuester Kommentar
Moin,
wurde schon eine Neuinstallation durchgeführt?
Durch einspielen des Backups lässt sich der Zustand wieder vollständig herstellen.
Mir ist gerade eine Installation (kein Cluster) um die Ohren geflogen.
Tatsächlich lief das System aber erst noch gut ein Monat nach dem Update funktionsfähig.
Auch waren die Fehler über die GUI nicht ersichtlich.
Bsp. DNS-Resolver funktionierte nicht mehr, Packages war nur in der GUI funktionsfähig.
Durch die Neuinstallation ist alles wieder behoben.
Gruß
Spirit
wurde schon eine Neuinstallation durchgeführt?
Durch einspielen des Backups lässt sich der Zustand wieder vollständig herstellen.
Mir ist gerade eine Installation (kein Cluster) um die Ohren geflogen.
Tatsächlich lief das System aber erst noch gut ein Monat nach dem Update funktionsfähig.
Auch waren die Fehler über die GUI nicht ersichtlich.
Bsp. DNS-Resolver funktionierte nicht mehr, Packages war nur in der GUI funktionsfähig.
Durch die Neuinstallation ist alles wieder behoben.
Gruß
Spirit
1
Hallo,
eine Lösung kann ich nicht anbieten, nur eine Empfehlung geben:
Mach kein HA-Cluster (CARP'), das taugt nichts (mehr).
HA-Cluster (CARP) hat bei uns mehr Ausfälle und Fehler produziert als einfache Installationen.
Ein imho großer Vorteil der HA-Cluster Lösung war die Möglichkeit fast unterbrechungsfrei pfSense Upgrades durchführen zu können.
Imho sind aber auch Uprades seit Netgates Zeiten mit Vorsicht zu genießen und eine Neuinstallation mit Import des Backups ist immer die bessere Lösung ( siehe auch Kommentar von @Spirit-of-Eli).
Hast du schon im offiziellen Forum um Hilfe angefragt ?
Gruß
CH
eine Lösung kann ich nicht anbieten, nur eine Empfehlung geben:
Mach kein HA-Cluster (CARP'), das taugt nichts (mehr).
HA-Cluster (CARP) hat bei uns mehr Ausfälle und Fehler produziert als einfache Installationen.
Ein imho großer Vorteil der HA-Cluster Lösung war die Möglichkeit fast unterbrechungsfrei pfSense Upgrades durchführen zu können.
Imho sind aber auch Uprades seit Netgates Zeiten mit Vorsicht zu genießen und eine Neuinstallation mit Import des Backups ist immer die bessere Lösung ( siehe auch Kommentar von @Spirit-of-Eli).
Hast du schon im offiziellen Forum um Hilfe angefragt ?
Gruß
CH
1
Danke,
bei Gelegenheit werde ich vielleicht eine Neuinstallation vornehmen. Ein Versuch ist es wert. Derzeit reboote ich die FW's nächtlich per Cronjob einmal neu.
Im Januar wird sowieso umgestiegen auf Sophos, und dann gibt's sicherlich neue Probleme zu debuggen
Auf pfsense habe ich jedenfalls keine Lust mehr, aus etwa den selben Gründen, die ihr auch schildert. Nach Updates funktionieren regelmäßig irgend welche Funktionen nicht mehr und das ist zunehmend ein Problem für uns. Das Fehler eingrenzen und -finden ist zeitaufwendig und damit teuer. HA muss sein, denn es hängen mehrere Firmen dran und wenn die Hardware die Grätsche macht, muss es trotzem weiter laufen.
bei Gelegenheit werde ich vielleicht eine Neuinstallation vornehmen. Ein Versuch ist es wert. Derzeit reboote ich die FW's nächtlich per Cronjob einmal neu.
Im Januar wird sowieso umgestiegen auf Sophos, und dann gibt's sicherlich neue Probleme zu debuggen
Auf pfsense habe ich jedenfalls keine Lust mehr, aus etwa den selben Gründen, die ihr auch schildert. Nach Updates funktionieren regelmäßig irgend welche Funktionen nicht mehr und das ist zunehmend ein Problem für uns. Das Fehler eingrenzen und -finden ist zeitaufwendig und damit teuer. HA muss sein, denn es hängen mehrere Firmen dran und wenn die Hardware die Grätsche macht, muss es trotzem weiter laufen.
