pfSense CARP auf zwei ESX Servern über Hetzner vSwitch

Da ich jetzt bei Hetzner einen zweiten ESX Rootserver in einem anderen Datacenter gemietet habe, schreit das natürlich danach auch das Gateway für die VMs hochverfügbar zu machen. 😉

Dafür kommt auf jedem ESX Server je eine pfSense VM zum Zug die mit CARP je eine IP im privaten, wie auch im öffentlichen Netz teilen.

Ich hatte jetzt gerade über viele Wochen an dem Problem herumgegrübelt, weil die zweite pfSense die Public VIP partout immer als MASTER übernehmen wollte. Und es lag tatsächlich an der hetzner firewall (bzw. deren Konfiguration), aber dazu im Anschluss mehr.

Setup

  • Zwei ESX Server über zwei Datacenter (FSN und HEL) verteilt
  • Drei hetzner v-switche: 1x Public Network, 1x Private Network, 1x HA Network (CARP) traffic
  • Auf jedem ESX Server eine pfSense VM (pfsense1 und pfsense2)
  • MTU auf allen NICs auf 1400
  • Alle drei vNICS:
    Promiscuous mode: Accept
    MAC address changes: Accept
    Forged transmits: Accept
  • Hetzner Firewall: ON, aber mit gewissen ANY Regeln:
any to public ip subnet0.0.0.0/0<PublicIP-Subnet>/280-655350-65535*anyaccept
local network to any172.16.0.0/120.0.0.0/00-655350-65535*anyaccept
Firewall Regeln (Auszug) in der Hetzner Firewall

(Die einzelnen VMs haben noch host firewalls; Ich benutze die hetzner firewall im Prinzip nur um den Zugriff auf die Primäre IP an der die ESX Konsole hängt einzuschränken)

Das Problem

Jetzt ergab sich das seltsame Problem, dass egal was ich machte, auf pfsense2 immer kurz nach der Initialisierung die Public-IP von BACKUP zu MASTER wechselte und man diese somit auf beiden Servern hatte (weil pfsense1 auch MASTER war)

Die Meldung im log von pfsense2 war:

Carp backup event
carp: 110@vmx0: BACKUP -> MASTER (master timed out)
  • Die die HA IPs konnten sich beide Gegenseitig erreichen (ICMP)
  • Die beiden Public IPs konnten sich beide Gegenseitig erreichen (ICMP)
  • Die beiden Private IPs konnten sich beide Gegenseitig erreichen (ICMP)

Kurioserweise kam noch hinzu, dass das jeweils NUR bei der Public VIP passierte. Die Private VIP funktionierte einwandfrei!

Wenn ich beide pfSense VMs auf denselben ESX Host verschoben hatte, trat das Problem nicht auf und CARP funktionierte mit beiden VIPs.

Wahrscheinlich hatte ich gerade deshalb die Firewall bis jetzt nicht verdächtigt, weil ja sowohl für private, wie auch publlic Nezte „any rules“ galten.

Die Lösung

Als „letzter Versucht“ hatte ich dann die hetzner Firewall doch Testweise mal auf dem zweiten ESX ausgeschaltet – Und siehe da, prompt wechselte der Status auf pfsense2 für die Punic IP VIP wieder von MASTER auf BACKUP!

Als ich dann die beide any-rules verglich, stellte ich fest, dass die Richtung jeweils anders war.

Der Rest war dann einfach: Ich hatte einfach noch die Regel:

public ip subnet to any<PublicIP-Subnet>/280.0.0.0/00-655350-65535*anyaccept

hinzugefügt und das Problem hat sich in Luft aufgelöst!

Manchmal dauert es echt lange bis man da einen Knopf löst.  :/ ^^

Weitere Quellen

Published by

Steven Varco

Steven ist ein Redhat RHCE-Zertifizierter Linux-Crack und ist seit über 20 Jahren sowohl beruflich wie auch privat auf Linux spezialisiert. In seinem Keller steht ein Server Rack mit diversen ESX und Linux Servern.

9 thoughts on “pfSense CARP auf zwei ESX Servern über Hetzner vSwitch”

  1. Hi Steven, ich bin auch gerade dabei 2 Firewalls in einem HA Verbund zu konfigurieren, Ich benutze dabei OPNsense, aber die Konfiguration sieht ja ähnlich aus. Ich habe dazu einmal eine Frage. Wie hast du es bei Hetzner konfiguriert, dass nur eine IP nach Außen sichtbar ist und diese dann je nachdem, welche Firewall aktiv ist, hin und her wandert?

    Viele Grüße
    Paul

      1. Hi Steven, dem vSwitch ist dabei dann aber eine IP zugeordnet oder? Weil wenn ich beispielsweise auf firewall.test.de zugreife muss dieser Name ja in eine IP auflösen.
        Ich habe zwei dedizierte Maschinen mit jeweils einer öffentlichen WAN IP. Jedoch muss ich es ja irgendwie hinbekommen, dann nur eine gemeinsame existiert.

        1. Der vSwitch ist ein Switch und die IPs darin sind nicht fest einem Server „zugeordnet“, sondern können beliebig auf den an dem vSwitch angeschlossenen Servern konfiguriert werden.

          Du brauchst dazu aber insgesamt mindestens DREI öffentliche IPs: eine die jede Maschine fix hat und eine die zwischen den zwei Servern hin- und her wandert.

          Bzw. für den Hetzner vSwitch ( https://docs.hetzner.com/de/robot/dedicated-server/network/vswitch/ ) brauchst du ohnehin ein IP Subnetz, da man einzelne IPs soweit ich mich erinnere nicht im vSwitch konfigurieren kann.

          Diese dritte „virtuelle IP“ kannst du dann in der Firewall mittels NAT auf eine private IP routen, die dann auf dem Server dahinter konfigurieren kannst.

          Wenn es dir jedoch primär darum geht eine eine IP für z.B. zwei redundante Webserver zu haben und nicht die Firewalls selbst redundant zu haben, ist es wahrscheinlich mit haproxy und keepalived einfacher, wie ich das hier beschrieben hatte. https://www.tech-island.com/tutorials/ha-loadbalancer-mit-keepalived-und-haproxy

          1. Hi Steven,

            vielen Dank für deine Antwort. Das heißt ich bräuchte eine Failover IP? Diese kann ja jedem Server zugeteilt werden. Diese IP würde dann meine „virtuelle IP“ werden, richtig? Warum brauche ich dann noch für den vSwitch ein eigenes Subnetz?

            Es geht darum, dass die IPsec Verbindung nachher immer von einer IP ausgeführt werden kann und falls die Master-Firewall ein Problem hat, diese Verbindung von der Backup-Firewall hergestellt werden kann. Das Firewall Plugin HAProxy verwende ich nachher innerhalb meines privaten Netzes.

          2. Failover IP ist etwas anderes. Diese kannst du zwar auch beliebig auf einen Server zeigen lassen, du musst es aber per API (-Script) triggern (siehe dazu: https://docs.hetzner.com/de/robot/dedicated-server/ip/failover/ ).
            Das ersetzt dann quasi den HAProxy. Im dem Fall wo du tatsächlich Firewall/Gateway redundant haben willst funktioniert das aber so nicht mehr und du brauchst bei Hetzner ein IP Subnetz zusammen mit einem vSwitch (https://docs.hetzner.com/de/robot/dedicated-server/network/vswitch/).
            Damit kannst du in pf-/open sense dann CARP konfigurieren (https://docs.opnsense.org/manual/how-tos/carp.html).

  2. Das heißt ich brauche einen vSwitch mit einem IP Subnetz über den die beiden Server mit einander verbunden sind. Dieser vSwitch braucht dann eine öffentliche IP, welche ich bei meiner Verbindung anspreche und die Anfrage würde dann entweder an die Master-Firewall, oder wenn diese nicht erreichbar ist, an die Backup-Firewall gehen? Momentan sind die beiden Firewalls direkt per LAN Kabel mit einander verbunden. Darüber habe ich CARP bereits eingerichtet.

    1. Sind deine Server überhaupt bei Hetzner?
      Denn „zwei server direkt per LAN Kabel mit einander zu verbinden“ geht bei hetzner eigentlich nicht… Zumindest nicht bei den Miet-Servern; Server housing wo man seine eigenen bringen kann mal ausgeschlossen.

      Das Ding mit den Hetzner vSwitchs funktioniert natürlich nur, wenn die Server auch bei/von hetzner sind.

      Ein vSwitch kannst du dir wie ein normaler switch vorstellen an dem die Server miteinander verbunden sind.
      Weisst man da nun ein IP Subnetz den vSwitchs zu, kann man beliebige IPs daraus auf seinen Servern konfigurieren.
      Was CARP macht ist im wesentlichen in einem Failover-Fall eine IP (vIP) auf dem jeweils anderen Server zu konfigurieren.

      1. Ja, meine Server stehen bei Hetzner. Das sind zwei dedizierte Maschinen von denen. Ich habe bei der Beantragung dieser diese Konfiguration gewünscht. Ich wollte da einen direkten Weg zwischen den Servern haben, anstatt noch über einen vSwitch. Ah okay alles klar, dann weiß ich Bescheid, vielen Dank 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert