2 x pfSense in HA als exposed Host hinter Fritz!Box 7590 mit shared IP



  • Hallo, ich bin pfSense Neuling und versuche zu ermitteln ob mit pfSense geht, was ich gerne hätte:

    100 Mbit Anschluss an Fritzbox 7590 daran angeschlossen 2 pfSense mit HA Syncronisation.
    Die pfSense sollen als VM auf jeweils einem VMWare ESXi Host laufen.
    Ich möchte, die pfSense(n) als Exposed Host hinter der Fritzbox betreiben um kein doppeltes NAT zu machen. Die Fritzbox soll weiterhin die Telefonnummern gebunden haben, die per SIP von einer Asterisk Anlage genutzt werden.
    Bei einem Ausfall eines der beiden ESXi Hosts soll die jeweils andere pfSense alle Dienste weiter bereit stellen.

    Ich habe mich ein wenig eingelesen, jedoch kann ich keine Informationen dazu finden ob die beiden pfSense eine IP sharen können und somit gegenüber der Fritzbox bei einem Failover die gleiche IP nutzen und somit keine Konfigurationsänderung an der Fritzbox nötig ist falls die aktive pfSense ausfällt.

    Ist eine solche Konfiguration möglich bzw. gibt es vielleicht eine bessere Herangehensweise?

    Vielen Dank für Eure Anregungen

    Norbert Schmidt


  • Rebel Alliance Moderator

    @codec said in 2 x pfSense in HA als exposed Host hinter Fritz!Box 7590 mit shared IP:

    Die pfSense sollen als VM auf jeweils einem VMWare ESXi Host laufen.

    Würde ich lassen, aber wenns unbedingt sein soll, geht das. Ist nur gruselig den ESXen dann das FB Netz auflegen zu müssen. Verstehe aber bei sinnvollem ESXi Cluster den Wunsch nach HA nicht - Snapshot der VM ist doch hier einfacher als HA und HA sollten die ESXe ja machen wenn einer ausfällt? Cluster im Cluster also?

    @codec said in 2 x pfSense in HA als exposed Host hinter Fritz!Box 7590 mit shared IP:

    Ich möchte, die pfSense(n) als Exposed Host hinter der Fritzbox betreiben um kein doppeltes NAT zu machen.

    Das macht nicht so wirklich Sinn. Exposed Host sagt nichts über NAT aus, im Gegenteil, Exposed Host wird meist gesetzt weil man genau das hat. Und Doppel-NAT ist - zum x-ten Mal - nichts dramatisches was man immer wie die Pest vermeiden muss.

    @codec said in 2 x pfSense in HA als exposed Host hinter Fritz!Box 7590 mit shared IP:

    Die Fritzbox soll weiterhin die Telefonnummern gebunden haben, die per SIP von einer Asterisk Anlage genutzt werden.

    Inwiefern ist das zu verstehen? Die FB vorne hat also die Telefonnummern eingeloggt? Und hinter dem pfSense Cluster steht dann nochmal eine Asterisk Anlage die sich in die FB einloggt für die Nummern? Warum loggt die sich nicht direkt beim Provider ein und holt sich selbst die Nummern (just curious)?

    Bei einem Ausfall eines der beiden ESXi Hosts soll die jeweils andere pfSense alle Dienste weiter bereit stellen.

    Also laufen die ESXe nicht im Cluster oder wie stellt sich der Wunsch hier sonst dar? Welche Dienste sind das - bislang war keinerlei Beschreibung des Einsatzes der pfSense zu erkennen?

    Ich habe mich ein wenig eingelesen, jedoch kann ich keine Informationen dazu finden ob die beiden pfSense eine IP sharen können

    Inwiefern eine IP "sharen"? Hast du dich sicher eingelesen? Stichwort CARP/Hochverfügbarkeit/HA? Das ist doch dort quasi gleich das erste was erklärt wird?

    somit keine Konfigurationsänderung an der Fritzbox nötig ist falls die aktive pfSense ausfällt.

    Bei der Überschrift ging ich davon aus, dass das Kapitel pfSense in HA Konfigurationen/CARP Cluster bekannt ist?

    Somit in kurz: Ja, pfSense im CARP Cluster ist ein active-standby Cluster der solches Failover beherrscht.

    Ist eine solche Konfiguration möglich bzw. gibt es vielleicht eine bessere Herangehensweise?

    Wie man aus obigen Anmerkungen vielleicht herauslesen kann :) verstehe ich die Herangehensweise nicht aus mehreren Gründen:

    1. die FritzBox bleibt - das kann man teils nachvollziehen je nach Provider und Bindung.
    2. Warum aber bspw. VoIP auf der FB belassen wenn man dahinter noch mit einer Anlage arbeitet, die dann auf die Box angewiesen ist, die wieder auf den Provider SIP angewiesen ist. Legt den Ausfallfokus stärker auf die FB.
    3. CARP Cluster ist für Ausfallsicherheit sicherlich bei pfSense top, keine Frage. Aber auch hier ist der schwache Punkt der Router/Modem davor. Bei einem Update und für Tests sehr gut und empfohlen, trotzdem bleibt der SPoF der FB davor. Ohne zweite Leitung ist dann bei einem Ausfall der FB trotzdem alles weg.
    4. CARP Cluster sind für HW Boxen gerade in einem Firmenumfeld großartig und wichtig. Mich irritiert aber die Virtualisierung. Generell bin ich persönlich da kein Freund davon, Security VMs in einen gemischten Hypervisor zu hauen. Dank Spectre und Meltdown und Co. haben wir heute in solchen (private) Cloud Szenarien genug nicht nur hypothetische Angriffspunkte. Daher bin ich ein Freund davon - wenn überhaupt die FW zu virtualisieren - dann auf extra HV Knoten oder welche mit so gut wie keiner Fremdbeteiligung.
    5. Virtualisierung: Habe ich einfach persönlich nicht so tolle Erfahrung mit gemacht. Cluster macht Sinn, doch wenn jemand die HV Server (ESXi) vergeigt, verkonfiguriert etc. nutzt das alles nichts - das Internet ist tot. Dann steckt man doch wieder schnell irgendwas hinter die FB damit man Internet hat. Oder ESX wird durchgestartet oder purple-screened. Noch dazu scheint das kein Cluster zu sein, also einzelne Knoten, eine VM pro Node. Was ist mit Storage Backend? Geteilt? Jeder sein eigenes? Generell merkt man vielleicht: bei der VM spielt außer pfSense in der VM plötzlich zur Funktion noch jede Menge Zusatzkram mit, der mit der Firewall nach Möglichkeit gar nichts zu tun haben sollte. Storage geht kaputt weil eine Platte o.ä. ausfällt, der andere Node bootet gerade neu, plötzlich gar kein Internet mehr.
      Insgesamt habe ich mit VMs außer in Labs, Test- oder Dev-Umgebungen oder in sehr speziellen Einsätzen und Gebieten eher negative denn positive Erfahrungen gemacht und meistens war es hinterher so, dass am Ende spätestens in der nächsten Interation dann eigene Hardware kam.

    Insgesamt:

    • VM würde ich persönlich vermeiden weil es unnötige Abhängigkeiten und Risiken ins Spiel bringt
    • CARP/HA Cluster ist sinnvoll, bei VMs aber sehr abhängig von der HV Lösung ob und wie es Sinn macht
    • Ggf. über Ausfall der Leitung nachdenken: wie schnell bekomme ich Ersatz für die FB und bekomme die Leitung dann (mit SIP etc.) wieder hoch?
    • Evtl. nachdenken ob eine zweite (kleine) Leitung und pfSense auf Hardware in Kombination nicht wesentlich mehr Ausfallsicherheit bringen.

    Beste Grüße
    Jens



  • Hallo JeGr vielen Dank für Deine ausführliche Antwort, die mich in mehrfacher Hinsicht ins Grübeln gebracht hat.
    Ich habe aber noch die folgenden Fragen:

    1. Wenn ich die FritzBox weg haben möchte, was habe ich dann als Modem?
    2. In unserem Fall würde eine zweite Leitung nicht viel bringen, da das Gebäude per Glasfaser angebunden ist, das dann in einer Box des Providers terminiert aus der dann ADSL raus kommt. Wenn ich eine zweite Leitung bestellen würde, dann hätte ich den SPoF nur zu dieser Box verschoben. Oder denke ich da falsch?
    3. Unsere ESXi Hosts laufen nicht im Cluster also bringt der Ausfall eines Hosts immer größere Probleme, da die Kapazitäten des jeweils anderen Hosts nicht reichen alle VM's zu betreiben. Das ist aber bekannt und akzeptiert. Bei einem Ausfall des einen Hosts, der z.B. auch die Windows VM mit dem DHCP Server hat, gibt es dann aber schon bald Probleme bei neu startenden PC's. Deshalb wäre z.B. ein redundanter DHCP und DNS Server schon wichtig.
    4. Wenn ich nun das Risiko eines FB Ausfalls eingehe (eine Ersatz-FritzBox ist hier in der Stadt schnell besorgt, die Konfig wird nach jeder Änderung gesichert), sollte ich dann einen CARP Cluster aufbauen in Hardware oder als VM, das muss ich noch überlegen, und dessen virtuelle IP dann als Exposed Host in der FB eintragen oder gibt es eine bessere Technik?
    5. Wenn ich die pfSense in Hardware betreiben möchte, dann brauche ich dafür Hardware mit redundanter Stromversorgung, denn wir haben 2 USVen und schon erlebt, dass eine davon den Geist aufgegeben hat. Oder ich muss einen CARP Cluster in HW aufbauen, was dann schon gleich teuer wird. Dies war auch ein Grund für den Gedanken die pfSense als VM's zu betreiben. Oder kann man vielleicht einen CARP Cluster so aufbauen, dass normalerweise die HW pfSense aktiv ist und eine passive pfSense VM einspringt, falls die HW stirbt?

    Gruß
    Norbert


  • Rebel Alliance Moderator

    @codec said in 2 x pfSense in HA als exposed Host hinter Fritz!Box 7590 mit shared IP:

    Hallo JeGr vielen Dank für Deine ausführliche Antwort, die mich in mehrfacher Hinsicht ins Grübeln gebracht hat.

    Nachdenken ist immer gut, selbst wenn das hinterher dazu führt, dass man trotzdem wie gewünscht verfährt und die anderen Punkte verwirft - man hat evaluiert und entschieden. :)

    Wenn ich die FritzBox weg haben möchte, was habe ich dann als Modem?

    Was auch immer dein Provider benötigt. DSL-Modem, Kabel-Modem, whatever. Durch Gerätefreiheit müssten dir die meisten Provider auf Wunsch die Möglichkeit geben, eigene Geräte einzusetzen, allerdings mal mehr oder weniger gut unterstützt. Es irritierte mich da eher, dass VoIP auf der FB genutzt werden soll aber trotzdem dahinter noch eine PBX die sich dann mit der FB verbindet und die nutzt - den Case verstehe ich nicht ganz. Dann könnte die PBX ja direkt die Nummern vom Provider verbinden und managen, anstatt das über 2-Ecken zu machen? Dann würde sich auch das Setup der FB vereinfachen und im Falle eines Austauschs muss man lediglich exposed Host und Routing kurz einstellen, fertig, läuft wieder :)

    Wenn ich eine zweite Leitung bestellen würde, dann hätte ich den SPoF nur zu dieser Box verschoben. Oder denke ich da falsch?

    Wenn ihr nur ADSL über diesen Provider und die Box bekommt, dann ja. Auf der anderen Seite ist der SPoF dann im Spielfeld des Providers - gegenüber dem man normalerweise ja diverse Verträge hat mit Vertragsstrafen und Regressmöglichkeit. Wenn einem die einzige Fritzbox stirbt oder die Mucken macht, dann bekommt man erstmal (vielleicht auf Verdacht) eine Neue. Je nachdem wie der Provider das aber dreht, hängt man bis dahin auf dem Trockenen und er leugnet erstmal Probleme bei sich (und schiebt es auf Mißkonfiguration der Box). Ist nur ein Gedankenanstoß.

    Sinnvoller wäre natürlich eine zweite Leitung über ein anderes Medium. Sei es Kabel, anderes DSL etc. Das war die eigentliche Intention. Wenn das nicht möglich ist, kann das auch einfach so sein, dann ist einfach die Frage, wie gut kann ich den Provider in die Finger kriegen, wenn was mit der Box oder dem Anschluß nicht geht und mein eigenes Netz so gut es geht ausfallsicher ist.

    Unsere ESXi Hosts laufen nicht im Cluster also bringt der Ausfall eines Hosts immer größere Probleme, da die Kapazitäten des jeweils anderen Hosts nicht reichen alle VM's zu betreiben.

    Das hatte ich aus dem Text vermutet, aber es war nicht klar, daher die Frage. Gut, dann ist der CARP Cluster auf pfSense Ebene durchaus berechtigt, wenn es unbedingt virtuell laufen soll :)

    Das ist aber bekannt und akzeptiert. Bei einem Ausfall des einen Hosts, der z.B. auch die Windows VM mit dem DHCP Server hat, gibt es dann aber schon bald Probleme bei neu startenden PC's. Deshalb wäre z.B. ein redundanter DHCP und DNS Server schon wichtig.

    Sollte die pfSense dann (zumindest für Clients) DHCP und DNS übernehmen? Würde sich in diesem Szenario empfehlen. Mit Domain Override für die AD Domain (sofern vorhanden) auf den Windows DNS.

    Wenn ich nun das Risiko eines FB Ausfalls eingehe (eine Ersatz-FritzBox ist hier in der Stadt schnell besorgt, die Konfig wird nach jeder Änderung gesichert),

    Das meinte ich mit Gefahrenabwägung, so gehen wir das mit unseren Kunden auch immer Schrittweise durch. Es nutzt der schönste Cluster nichts wenn vorne alles durch einen 5€ Router durch muss der durchschmort ;) Aber dann ist das soweit sinnvoll abgedeckt, richtig.

    sollte ich dann einen CARP Cluster aufbauen in Hardware oder als VM, das muss ich noch überlegen, und dessen virtuelle IP dann als Exposed Host in der FB eintragen oder gibt es eine bessere Technik?

    Meine Empfehlung wäre bei der Firewall eigentlich schon dedizierte Hardware um die Problempunkte zu minimieren. Wenn du schon beschreibst, dass die beiden VM Hosts overcomitted sind (zumindest aus Clustersicht), würde mir das zu denken geben und ich würde an der Stelle eher dazu neigen, die Firewalls dann als Cluster in (angepasster) Hardware abzubilden, um bei Ausfall oder Fehlverhalten oder auch Fehlkonfiguration des Hypervisors nicht plötzlich ganz ohne Netz dazustehen (leider schon bei einigen Kunden in virtuellen Umgebungen erlebt).

    Wenn euer Hausanbieter euch intern (A)DSL via FB zur Verfügung stellt (PPPoE vermutlich?), dann käme es drauf an, ob die FB noch was anderes als Verbindungsaufbau macht. Wenn man bspw. auf der FB keinerlei WLAN, NAS oder sonstiges braucht und das VoIP Thema komplett auf die Asterisk verlagert, macht die Box eigentlich nur noch Einwahl. Sofern der Anbieter da nichts geblockt hat an der Box (oder das eure ist?) könntet ihr die auch in Modem-only schalten (oder ein anderes ADSL Modem nutzen) und die pfSense selbst die Einwahl machen lassen. Das geht seit 2.4.4, dass man auf dem CARP Interface nun PPPoE konfigurieren kann um die Einwahl nur auf dem aktiven Knoten zu machen.

    Ich würde tatsächlich aber die Box als Router mit Exposed Host vorne stehen lassen, ihr default 192.168.178.x Netz nutzen und die .2 als CARP IP und die .251 und .252 als Adressen der beiden pfSensen des Clusters nutzen. Exposed Host Target wäre dann die CARP IP .2 und die aktive bekäme dann auch alles eingehend was reinkommt.
    Vorteil davon: Beide Knoten kommen jederzeit über das Routing der Box ins Internet, nicht nur der aktive der die PPPoE Verbindung aufbaut. Daher wird es bei Cluster Setups auch so empfohlen :)

    Wenn ich die pfSense in Hardware betreiben möchte, dann brauche ich dafür Hardware mit redundanter Stromversorgung, denn wir haben 2 USVen und schon erlebt, dass eine davon den Geist aufgegeben hat.

    Jein, das würde der Cluster ja problemlos abfangen. Je einen Cluster Node an eine USV hängen und gut. Schön wäre natürlich zwei Netzteile, aber das findet man in kleinen bis mittleren Appliances eher selten und nur dafür würde ich keine großen Mehrkosten in Angriff nehmen!

    Oder ich muss einen CARP Cluster in HW aufbauen

    Richtig, ist aber der korrekte Weg. Bei VMs wolltet ihr auch Redundanz, warum dann bei extra Hardware sparen - auch wenn sie gut läuft kann sie immer mal ausfallen und einmal völlig(!) unabhängig von der Hardware: was passiert bei Updates? Es kommt immer mal wieder obgleich selten vor, dass ein Update schief geht. Dann ist schonmal 30-60min das Internet weg - kein Telefon, keine Cloud Anwendungen etc. - ist das in eurem Fall OK? Wir haben Kunden, da ist ein Tag offline ein Schulterzucken. Und andere, da sind 10min bereits kritisch. Im ersten Fall reicht eine Appliance mit ordentlichem HW-Support-Vertrag dicke. Im zweiten Fall muss da ein Cluster hin und ebenfalls entsprechender HW-Support damit auch das Ersatzgerät für das ausgefallene nicht erst nach ner Woche wieder zur Verfügung steht.

    Daher: Abwägungssache und Business-Entscheidung. Wie kritisch ist ordentliche Funktion vom Internet?

    Oder kann man vielleicht einen CARP Cluster so aufbauen, dass normalerweise die HW pfSense aktiv ist und eine passive pfSense VM einspringt, falls die HW stirbt?

    Man könnte es sich so "hinbasteln". Empfohlen und sehr supportet ist die Konfiguration nicht, zudem massiv fehleranfällig und benötigt unterschiedliche Konfigurationen an vielen Ecken. Das würde ich so nie supporten wollen ;)

    Aber nochmals kurz zu dem Satz:

    Oder ich muss einen CARP Cluster in HW aufbauen, was dann schon gleich teuer wird. Dies war auch ein Grund für den Gedanken die pfSense als VM's zu betreiben.

    Gut ausgewählte Hardware ist für Firmen normalerweise für 3 oder ggf. auch mal 5 Jahre im Voraus angedacht. Je nach Bandbreite, Pakete, Use Cases etc. kann man sich da die richtige Appliance/Hardware für den Job aussuchen. Mal zwei. Plus Garantie oder next-business-day replacement o.ä. Wird bei den VM Hardware Knoten oder sonstigen Servern meist ähnlich sein. Warum also für die Firewalls nicht? Selbst wenn wir (ohne dass ich deine Anforderungen an Hardware gerade kenne) davon ausgehen, dass jede Kiste ~1000€ kosten (der Einfachheit halber). Dann sinds mit zwei 2k. Und mit Supportverträgen wahrscheinlich knapp 3k. Auf 3 oder gar 5 Jahre. Also grob 1k pro Jahr. ~83€ im Monat. Viele Firmen machen das ja ggf. als Leasing oder sonstwas. Aber ~83€ im Monat für 2 saubere Hardware Firewalls im active standby Cluster um sauber durchgehende Erreichbarkeit zu haben (zumindest was euren Teil angeht, am Provider seid ihr ja nicht schuld). Die meisten Firmen, die sich die Rechnung so stellen und die ich frage: "Was kostet es euch, einen Tag ohne Internet? Zwei Tage? Eine Woche?" geben da wesentlich größere Zahlen an (gerade weil inzwischen auch Telefonie etc. mit dranhängt), was sie an Einbußen, Verluste oder Ausfälle haben. Und plötzlich rechnet sich das dann doch ganz schnell 😉

    Grüße
    Jens


Log in to reply