Neuling bei Pfsense , Projekt high availability

franky64

Hallo zusammen,

zuerst will ich mich mal als "pfsense Neuling outen".
Ich möchte in einem RZ unsere Server mit einer Firewall schützen, wir haben unsere Netze segmentiert mit Dot1q Vlans
Mein erster PFsense testaufbau sieht also derzeit 4 Schnittstellen vor, einmal WAN, einmal DMZ (mehrere VLANS) einmal LAN, einmal geplantes HA

Lan wird nur genutzt für Wartungszwecke mit einem Wlan Router wenn man vorort ist. (Notebook) bzw als Jump ip wenn man über einen alternativen Weg remote hinter die Firewall muss.

Das hat bisher auch alles geklappt, sogar Openvpn rennt wie gewünscht. einige Testvlans laufen ebenfalls. Sehr schön.

Jetzt kommt HA ins Spiel und da nützen mir Google oder Hotos/Docs nichts mehr, denn ich viele zu viel verschiedenes hierzu um den Ablauf zu verstehen.

. Ich setze eine 2te Kiste mit ebenfalls 4 Schittstellen auf, WAN bekommt eine weitere IP aus dem Wan Subnetz. Aber wie geht es jetzt weiter? Wenn ich die DMZ Schnittstelle auf den Switch
packe, dort entweder über sync oder von Hand die gleichen VLAN´s/Ip´s confe würde doch spanning Tree zuschlagen oder? Oder hab ich hier einen denkfehler?

Kann mir hier vielleicht jemand das Licht anmachen, es ist nämlich dunkel und ich hab Fragezeichen im Kopp….ich hatte mit HA noch nicht wirklich viel am Hut. Was ist da genau zu tun, was wo einzutragen, auch bei der LAN Schnittstelle, die würden dann beide auch zu einem Switch gehen...(wo dann ein Vlan Access Point dran ist)

flix87

Bei der PfSense arbeitet man mit virtuellen IP's diese werden dann hin und her gegeben falls eine pfsense ausfällt.
Sprich pro Interface brauch man 3 IP's eine für die Master PfSense eine für die Slave und eben eine virtuelle

Basiert auf CARP also brauchst du CARP Adressen.

Dann kann man den PfSensen auch bei bringen das Änderungen immer synchronisiert werden.
Will man auch ins WAN HA haben muss man mit Manual Outbound NAT arbeiten so das ins WAN immer die Virtuelle gegeben wird und nicht die der aktive PfSense.

ist alles nicht so einfach und in zwei Sätzen erklärt.
Ich hoffe trotzdem etwas geholfen zu haben.

JeGr

Kollege flix hat es im Groben schonmal richtig angerissen, wenngleich ein paar kleine Details nicht stimmen.

Pfsense arbeitet mit CARP, völlig richtig. Im Moment (noch) heißt das, dass in jedem Netz, in welchem geroutet wird (sprich bei dir: WAN, DMZ1,2,3,4, LAN) jede pfSense mit einer eigenen Adresse vertreten ist (Host-IP) und es eine dritte Adresse gibt, welche via CARP (das Pendant wenn man so möchte zu Ciscos VRRP) gesteuert wird. Meistens wird diese Adresse auf dem CARP Master zu finden sein. Fällt dieser aus, übernimmt der Knoten mit dem nächstkleineren Timing den Master-Posten und erbt somit alle CARP-IPs.

Rein technisch wird das (zumindest in mir bekannten Umgebungen) so eingesetzt, dass man meist den pfSensen z.B. in den Netzen die .251 (#1) und .252 (#2) gibt (somit noch 2 IPs für größere Cluster frei) und als CARP-IP die .1 definiert. Somit ist für alle anderen Geräte des Netzes das Default-GW die .1 (CARP IP), die dann auf dem jeweils aktiven Knoten gehalten wird.
Was nicht ganz stimmt hierbei ist, dass pfSense mit virtuellen Adressen arbeitet. CARP IPs sind keine "klassischen" VIPs, da bei CARP auch eine eigene MAC Adresse für die VIP erstellt wird. Diese virtuelle MAC zieht ebenfalls auf den Knoten um. Der Unterschied zur klassischen VIP Methode: Manche Geräte - wie alte Windows Server - hatten mitunter Probleme bei einer schnellen Umschaltung einer VIP bei der sich gleichzeitig die MAC geändert hat. Die IP blieb mit der alten MAC in der ARP Table und die Pakete gingen an die defekte Firewall statt an den Fallback Knoten. Erst nach 5-10min wurde die ARP Table aktualisiert. Das entfällt bei CARP Style IPs da sich hier die MAC nicht ändert. Kurz gesagt: funktioniert einfach meist zuverlässiger, schneller und besser ;)

Ein anderes Problem: In kleinen IP Bereichen (/29 bspw.) kann es ungünstig sein, wenn man 3 IPs aufgeben muss für einen Failover Cluster.
Ein weiteres: Da VLANs (noch?) nicht synchronisiert werden, muss man neue VLANs immer auf beiden Knoten erst manuell einrichten, dann kann man auf dem Master die CARP VIP einrichten (die dann synchronisiert wird) :)

Weitere Fragen fragen :)

Grüße

franky64

erstmal vielen Dank an euch beiden, wir haben das Carp auf einer Kundenumgebung unter Centos laufen daher ist es mir nicht unbekannt. Wie jegr schon schrieb ist es ja ein Pedant zu HSRP bzw VRRP.

Was ich nicht wusste bzw was ich nicht hoffte ist das ich es faktisch für jedes Interface, auch bei den Vlans einsetzen müste um das redundant hinzubekommen, ich hatte mir als Testumgebung mal eine Sophos UTM angeschaut, die haben da einen anderen HA Ansatz.

Durch das Sync hatte ich den Verdacht das Pfsense das auch kann. Aber mir ist ja schon klar das man hier Äpfel mit Birnen vergleicht.

Wenn ich PFsense richtig verstanden habe kann ich , wenn die Hardwaregrundausstattung stimmt (gleiche Anzahl der Netzwerkkarten etc pp.) , die Config auf andere Hardware einspielen und das läuft dann!?

Da es mir reichen würde recht schnell (RSA Adapter in der Masschine) eine Ersatzmaschine an den Start zu bekommen im Falle eines Ausfalls….könnte es ein Ansatz sein die aktuelle oder vorletzte Config in eine ersatzmaschine einzuspielen und dann wieder "online" zu sein.

Da kommt die Frage auf gibt es eine Möglichkeit bzw Plugin die aktuelle Config automatisiert in einen FTP Space oder per mail täglich zu verschicken

JeGr

Was du da ansprichst nennt man gerne auch "cold standby" oder Kaltredundanz. Würde ich auf keinen Fall einem CARP Cluster vorziehen. Deine Probleme fangen schon an sobald du bspw. ein Update machen möchtest. Dafür wird die pfSense kurz neu starten um die ganzen Änderungen zu übernehmen. Willst du dafür das Netz abklemmen? Das Ersatzgerät kannst du nicht nehmen, sonst gäbe es IP-technische Probleme, weil beide ja mit der gleichen Konfiguration laufen und sich somit um die IPs streiten. Und für Updates immer physikalischen Zugriff auf die Maschinen zu brauchen (zum Umstecken der Kabel) ist auch nicht fein, damit klemmst du mind. für alle Netze 2min den Saft ab. Das ist einfach unpraktisch.

Es ist völlig einfach möglich, die Konfiguration zu sichern (pfSense macht das eh selbst, wenn es größere Konfigurationsänderungen gibt), bspw. als Gold-Supporter (99$ im Jahr) hast du Zugriff auf den verschlüsselten Bereich beim Hersteller/Supporter von pfSense selbst und kannst dort deine Konfig ablegen lassen und auf dem Backup Gerät restoren.

Wie gesagt würde ich es nicht empfehlen. Man kann viele Gründe für Kaltredundanz anführen - eine davon ist gerne, dass es keine 100% sichere USVs gibt und ein Backup Gerät im Schrank nicht geröstet werden kann - aber nur wegen IP Adressen und einem Interface hie und da, ist das wirklich Sparsamkeit am falschen Ende.

Ich kenne zwar dein Netz nicht, aber kann dir sagen, dass ich gerade einen 2-Knoten CARP Cluster baue, der sowohl IPlegacy als auch IPv6 Adressen (public) haben wird (und nicht zu knapp), für DC-Einsatz gedacht ist und man dort momentan um VLAN Zahlen um die 100-200 VLANs diskutiert. Das ist einmalig eben heftig einzurichten. Aber danach ist es nur noch "neues Netz auf #1, #2, Netz auflegen, fertig".

Und selbst für kleine Public-IP Netze gibt es alternative Lösungen (bspw. das ganze per 1:1 NAT abzudecken).

Zudem: die nächste Version von pfSense wird (wahrscheinlich 2.2) auf FreeBSD 10 aufsetzen. Dort wurden einige große Änderungen von OpenBSD und PF übernommen, mit welchem zukünftig ein CARP Interface auf ein physikalisches Interface aufgesetzt werden kann und keines selbst mehr darstellen muss. Vereinfacht ausgedrückt: Die Kisten haben bspw. WAN IPs und LAN IPs (legacy/v4) im privaten Bereich, damit sie sich untereinander verständigen können, CARP wird obenauf aber ohne eigene IP/Interface aufgesetzt, sondern eher so wie man es bei Juniper und Co. kennt, nur noch als CARP virtual IP, die einfach vom Master auf den Slave wandert. Somit ist dann nur noch eine statt drei IPs für ein Netz notwendig. Wie das dann aber vom Interface her in pfSense konfigurierbar sein wird, kann ich jetzt natürlich noch nicht sagen.

Grüße
Jens

franky64

Hallo Jens,

erstmal danke das du dich einem Neuling überhaupt annimmst….

rein theoretisch hätte ich in jedem Vlan sicherlich noch 2 Ips frei um das zu "carpen"....
Aber ich weiss nicht ob ich mir das antun soll, ein Cold Standby würde mr sicherlich reichen.

Es gibt natürlich x für und wider die zu abzuwägen sind. "cold standby" ist für mich natürlich nicht das ich mir
die second Kiste "in den Schrank stelle".

Ich dachte eher daran auf der Backup Kiste ein Interface offen zulassen, den Rest switchtechnisch zu closen, und im Desasterfall die
switchports des primary zu closen, und die Ports des Backups zu öffnen, theortisch wäre man dann innerhalb 10/15 Min max wieder online...zumal ich die letzten Konfigs dann nutzen kann....

Alternativ wäre dein Szenario natürlich auch nicht zu verachten, nur es ist ne Menge mehr Arbeit. Und Zeit ist ein Faktor der mir momentan fehlt bzw sehr wertvoll ist. wir reden dabei ja nicht über 1-2 Std....

JeGr

Nunja, ich weiß nicht wie viele VLANs du auflegen musst, aber wenn es tatsächlich nur 3-4 sind, dann reden wir genau über 1-2h und nicht mehr. Insofern verstehe ich da ein wenig die Aufregung nicht ;)
Hängt natürlich am Wachstum und wie viele VLANs wie oft dazukommen. Aber wenn die IPs nicht das Problem sind, wüsste ich nicht was dagegen sprich, das ordentlich und sauber umzusetzen. In der Situation halte ich den cold standby Weg für falsch. Schon alleine weil er an jeder Ecke sehr fehleranfällig ist. Alleine das eine Interface offen zu lassen (welches und auf welcher IP? Wie offen? Sicher dass daraus kein Problem wird?) und alles andere dem Switch zu überlassen ist hakelig. Wenn ich im Desasterfall auch noch an meinen Switch Configs schrauben muss, nur damit ich meine Standby Firewall online bekomme, dann noch die neueste Konfiguration brauche, das ganze nochmal durchbooten muss, dann rennt man ggf. noch in gracious ARP Probleme, hat noch alte stale ARP handles oder die IP vom alten Master wird vllt. am Switchport nicht freigegeben…

Wenn ich mir die Desasterfälle alle vorstelle und im Geiste aufzähle, wiegt das "gute Gefühl" in einem Problemfall, dass der Slave einfach übernimmt, einfach den ganzen Problemkatalog und Zeitaufwand locker auf. Zumal nach einmaliger Einrichtung wirklich nur noch minimale Einstellungen zu machen sind. Da geht mehr Zeit für drauf, den zweiten "inaktiven" Knoten wirklich sauber überall inaktiv zu schalten/trennen/konfigurieren und dann im Fehlerfall das Prozedere um den Standby fitt zu machen. Das alles zu planen, zu konfigurieren (die Switche müssen ja auch jedes Mal umkonfiguriert werden) etc. nur weil du in der gleichen Zeit den Cluster nicht aufsetzen möchtest ;) da muss ich etwas verwirrt den Kopf schütteln :)

Grüßend

franky64

Hallo Jens,

ich bin mir über das künftige Setup noch nicht wirklich im klaren, ich muss die verschiedenen für uns wider mal abwägen, mich auch mal mit einem Kollegen besprechen. Trotzdem danke ich Dir für deine Ratschläge. Wenn es gewünscht ist schreibe ich hier die Fortschritte runter.

Ich habe eh vor mal einen kleinen Blog aufzumachen, da ich üer Google im deutschsprachigen Raum meiner Meinung nach zuwenig finde.

JeGr

Hi,

natürlich wäre es schön wenn du uns hier auf dem Laufenden halten kannst - sofern es natürlich keine zu detaillierten Infos sind, die ggf. vitale Daten enthalten. Die natürlich weglassen ;)
Ich bin gerade im Zuge einer Neustrukturierung/Umstellung und löse damit ein 2-Knoten Juniper-Firewall-Cluster ab. Das ist momentan auch viel Arbeit, da nach der Re-strukturierung relativ viele kleine VLANs vorhanden sein werden. Und die müssen eben alle als eigenes Interface aufgelegt und konfiguriert werden. Zweifach. Das ist lästig, aber damit kann man die einzelnen VLANs auch wesentlich besser separieren und gegeneinander absichern. Da ich (hoffentlich) wenig Intra-VLAN Kommunikation habe, sondern das meiste nur von Projekt-VLANs zu einem Infrastruktur VLAN (DNS, Mail etc.) und der Rest Traffic ins Internet ist, hoffe ich, dass die Last der FW hier gering genug ist. Ansonsten steht immer noch die Möglichkeit offen, die VLANs auf Switche hinter die Firewall zu verlagern und die Switche mit einem großen Transfernetz anzubinden. Das bringt dann aber wieder Komplexität ins Setup, denn dann muss ggf. nicht nur die Firewall gecheckt werden (bei Problemen), sondern auch die Switche, dort ggf. noch Regeln etc. etc. deshalb ist unser Plan bislang, das meiste auf den Firewalls zu terminieren und einige High-Traffic VLANs, die eh kein Internet brauchen (Backend, Management, Backup-Netze) direkt über die Switche abzubilden und damit den Traffic von der Firewall fern zu halten. Ob das klappt - weiß ich in einigen Wochen ;)

Grüße