pfSync - best practice

[almo]

Hallo Zusammen,

aktuell habe ich es so das mein Firewall Cluster die beiden Maschinen direkt über LWL 10G miteinander Verbunden sind ohne ative Komponennte dazwischen (direkte passive LWL Verbindung). Von einem RZ Teil zum anderen RZ Teil.

Aktuell überlege ich mir den pfSync auf einen 1G LAN Port um zu stellen und per VLAN über die Rackswitche von Firewall A zu Firewall B zu bewegen.

Bei der aktuellen Lösung ist es egal was ausfällt die Firewalls können sich immer sehen solang sie selbst Strom haben.

Was wäre Practice?

Hintergund wäre das ich so ein 10G Modull frei bekommen würde und eine direkte Faser. Damit könnte ich die Anbindung der Firewall im LAGG mit LACP intern von 20G um weitere 10G erhöhen. Und meine beiden Core Switche nochmals mit 100g Verbinden zwischen den beiden RZ hälften. Was ein reines Luxsus Upgrade wäre.

Ich stelle mur nur die Frage was halt ist wenn der pfSync nicht arbeitet weil z.b ein Rackswitch nicht geht. Aber der Rest voll da ist. Hab ich dann Split Brain auf meiner FW mit den CARPS oder ist Ihr das egal so lange sich die CARP Member gengeseitig sehen können?

[hbc]

Es ist doch kein aktiv-aktiv Cluster. Du hättest nur dann ein Problem, wenn just in dem Moment, wo deine primäre Firewall ausfällt, auch dein pfSync ausfällt. Dann hätte die nun aktive Backup-Firewall keine aktuellen States und die bestehenden TCP-Verbindungen würden geblockt werden
Solange deine primäre FW läuft, kannste ohne Probleme auch mal einen der Switche mit pfSync-VLAN booten, etc. Sollten dann nur keine VLANs wegfallen worüber auch CARP läuft, weil dann kriegst Du Failover oder Split-Brain. Wobei das dann mit pfSync eigentlich auch kein Problem sein sollte, da ja bis zum Zeitpunkt des Split-Brains die States gesynced waren und danach dann die Clients über den für sie aktiven CARP Master laufen und dort dann die States generieren, die ab da dann nicht mehr synchronisiert werden. Würde dann erst beim Fallback Probleme geben.

Und Du bekommst 20G Bandbreite im Lagg? Wow. Ich such noch meinen Flaschenhals. Wäre schon mit 10G zufrieden.

[JeGr]

> Dann hätte die nun aktive Backup-Firewall keine aktuellen States und die bestehenden TCP-Verbindungen würden geblockt werden

Nicht ganz. Die States werden ja dauernd über den Sync ausgetauscht. Fällt Gerät A aus und sowohl auf dem WAN/LAN als auch auf dem Sync, würde einfach ein Failover passieren. Es wird ja nicht erst gesynct wenn was ausfällt - ein Power Outage von Gerät A wäre dann immer ein kompletter Totalausfall, das wäre ja kein HA!

Beim Fallback gibt es nur dann ein Problem, wenn das Sync Interface nicht läuft, da dann weder States noch die Konfig übertragen werden kann (Konfig nur von Master->Standby natürlich, aber würde trotzdem einen Fehler werfen). Daher gibts ja aber auch auf dem designated Master den Carp Standby bei dem man erst wieder aktiv schaltet, wenn alle Leitungen wieder sauber sind

> Was wäre Practice?

Soweit ich weiß bzw. gesagt wurde, ist bei PFsync eigentlich direct connect "Standard". Das heißt aber nicht, dass du das nicht über VLAN und Switche ordentlich auf die andere Firewall schubsen kannst wenn es einfach technisch nicht anders möglich ist. Bei direkter Verbindung ist eben bei der anderen FW sofort klar, dass was im Argen liegt weil der Link weg ist. Bei Switchen dazwischen sieht es erstmal von Layer 1 her gut aus, erst beim Sprechen und prüfen merkt dann der eine Node, dass der andere tot ist. Heißt es gibt potentiell ein klein wenig mehr Delay bis einer der beiden merkt, dass der andere weg ist. Sollte in der Praxis aber IMHO keine wahnsinnig große Nummer sein. Daher würde ich aber auch nie hergehen und den Sync bspw. auf ein LACP Bündel von 2x1G oder 2x10G legen damit es "redundant" ist (hatten wir schon bei Kunden , das wäre einfach Ressourcenverschwendung