Hallo zusammen!
Ich zermarter mir seit Wochen den Grips an einem HA-Konstrukt, welches ich gerne irgendwann produktiv nehmen möchte.
Ich beschreibe zunächst mal die Umgebung. Folgende Hardware wurde für die beiden FW's angeschafft:
https://www.servershop-bayern.de/de/supermicro-1u-up-xeon-d-server-vmware-ready
Ausgewählt wurde der Prozessor Intel Xeon D-1518 6MB / 4x 2.2GHz / 8 Threads / 35W und 32GB RAM im Konfigurator.
Dazu wurden noch identische Intel SSDs verbaut, welche noch im Büro rum flogen.
Die Hardware ist also 1:1 die Gleiche.
Die Firewalls haben 2 1G und 2 10G RJ-45 Schnittstellen - igb0 & 1 und ix0 & 1.
EDIT: igb0 ist auf beiden FWs das HA-Interface für pfsync und XMLRPC - die FWs sind hier direkt durch ein Kabel verbunden.
Angeschlossen sind die Firewalls an 2 baugleiche Netgear M4300 8X8F mit jeweils identischer Config.
ix0 ist an dem einem Switch angeschlossen und ix1 an dem Anderen.
Die Switche haben eine zusätzliche Verbindung untereinander für Spanning Tree (Variante RSTP).
Einer der beiden 10G Switche wurde als Root-Bridge konfiguriert.
Die Ports an denen die ix0/1 Schnittstellen hängen sind jeweils als VLAN Trunks konfiguriert.
Dann gibt es noch 2 weitere Switche: Netgear GC752X 52-Port Switche (50x 1G, 2x 10G).
Die 10G Ports der GC752er sind an beiden M4300ern angeschlossen und es wurde ebenfalls RSTP erfolgreich konfiguriert.
An 3 Ports auf den GC752ern sind die WAN Ports konfiguriert als Access Ports mit VLAN 666 (untagged) und entsprechender PVID 666. Dort hängen die WAN Schnittstellen der FWs (jeweils igb1) dran, sowie der Uplink vom Rechenzentrum.
Soviel zur Hardware. Ich hänge auch ein Diagramm an um das etwas zu veranschaulichen.
Software-seitig ist auf beiden Maschinen OPNsense installiert und aktualisiert worden auf folgende Version:
OPNsense 20.1.9-amd64
FreeBSD 11.2-RELEASE-p20-HBSD
OpenSSL 1.1.1g 21 Apr 2020
(Auszug aus dem OPNsense Dashboard - auf beiden FW's identisch.)
Die folgenden Schritte sind auf beiden FWs identisch ausgeführt worden, abgesehen von ggfs. IPs:
Ich habe dann erstmal ein LAGG Interface aus ix0 und ix1 gebildet im Round-Robin Modus.
Auf dem resultierenden lagg0 Interface habe ich meine VLANs angelegt, auszugsweise 10,12 und 15.
Ich habe die WAN Schnittstelle und das Upstream Gateway konfiguriert auf Schnittstelle igb1 und erfolgreich eine Internet-Verbindung herstellen können. Hinweis: die WAN Ports liegen am Switch untagged auf, daher keine extra Konfiguration bzgl. VLANs notwendig hier.
Auf den einzelnen lagg0_vlanXY Interfaces habe ich die entsprechenden Subnetze hinterlegt.
FW 1 hat stets die .2 als IP und FW 2 die .3 - bspw. 10.254.10.2 / 10.254.10.3.
Nachdem das erledigt war habe ich nach dieser Anleitung versucht das HA-Konstrukt aufzubauen:
https://www.thomas-krenn.com/de/wiki/OPNsense_HA_Cluster_einrichten
Die CARP Virtual IPs habe ich für WAN, VLAN 10,12 und 15 angelegt, jeweils auf die .1 des entsprechenden Subnetzes. (Mit Ausnahme WAN, da wurde es .6, da .1 des Public Subnets vom Rechenzentrums Provider als Upstream Gateway zur Verfügung gestellt wurde.)
Ich habe ebenfalls darauf geachtet auf allen Switchen Multicast / IGMP Snooping zu aktivieren, soweit ich konnte.
Nun zur Problematik... die FW1 ist MASTER für die WAN VIP und die FW2 BACKUP - perfekt.
Ich kann auch zwischen den beiden umschalten soweit. Hin und zurück, ohne Probleme.
Allerdings versagt das Konstrukt bei den VLAN Interfaces vollständig. Beide Firewalls sind permanent MASTER.
Wenn ich die VIPs anspreche, lande ich stets beim Master und wenn ich diesen bspw. herunterfahre oder sonst irgendwie einen Failover provoziere, ist die VIP nicht länger erreichbar.
Ich habe massig Lesestoff zu Problemen mit CARP im Zusammenspiel mit LAGGs und VLANs gefunden.
Die Hardware-Anordnung der Interfaces (OPTx) ist auf beiden Kisten identisch, das habe ich mehrfach überprüft.
Auch habe ich mal die komplette Config gezogen, bearbeitet und drüben eingespielt um ganz sicher zu gehen. Kein Erfolg.
Ich habe auf beiden Kisten die Tunables "net.inet.carp.senderr_demotion_factor = 0" und "net.inet.carp.ifdown_demotion_factor = 0" konfiguriert und mit sysctl überprüft. Auch mit Reboots etc. um sicher zu gehen. Ebenfalls kein Erfolg.
Ich kann sogar in den CARP Maintenance Mode gehen oder CARP abschalten - außer der WAN VHID rührt sich gefühlt nichts. Natürlich steht da dann "disabled" wenn ich CARP abschalte, aber beim Enablen sofort wieder MASTER. Beim Maintenance Mode tut sich gar nichts.
Aktuell habe ich die LAGG Interfaces komplett aufgelöst und die VLANs auf ix1 umzogen auf beiden FWs.
Wieder mit Config Import/Export um Probleme bei der Anordnung etc. zu vermeiden. Die Tunables noch immer gesetzt. Leider noch immer kein Erfolg.
Mein nächster Schritt wird sein aus den Trunks an den Switchen untagged Ports in einem Test-VLAN zu machen und die FWs daran zu hängen um auch VLANs aus der Gleichung zu entfernen.
Wenn das klappt, super! Problem ist, ich kann und will auf die VLANs nicht verzichten.
Drum bitte ich euch um Hilfe bei diesem Problem - was kann ich tun um das Konstrukt mit den VLAN Interfaces (und falls möglich, mit dem LAGG Interface) ans Laufen zu bekommen?
Aus den Posts die ich gelesen habe geht hervor, dass es wohl technisch möglichst ist bzw. ein paar Leute das funktional im Betrieb haben, ich habe also noch Hoffnung!
Wenn ich noch irgendwelche Infos bereitstellen kann die zur Lösung des Problems beitragen, sagt es bitte. :)
Ansonsten danke ich euch schon mal für eure Zeit und freue mich auf die Antworten! :D
Viele Grüße
Felix
Erster Schritt muss sein beide Firewalls mit LAGG und VLANs auf einem Switch zu betreiben. Wenn das geht ist OPN fein raus, wenns nicht geht liegts an OPN.
Eigentlich muss man ja igmp snooping deaktivieren und nicht aktivieren ;)
Quote from: mimugmail on July 27, 2020, 03:47:25 PM
Erster Schritt muss sein beide Firewalls mit LAGG und VLANs auf einem Switch zu betreiben.
Hm. Im Rechenzentrum wäre ich erst gegen Ende der Woche, da kann ich das hart so verkabeln, aber aktuell sollte es sogar so aufgebaut sein - theoretisch.
Auf ix1 hängen aktuell alle VLANs und ix1 hängt bei beiden FWs am gleichen Switch dran.
Quote from: mimugmail on July 27, 2020, 03:47:25 PM
Eigentlich muss man ja igmp snooping deaktivieren und nicht aktivieren ;)
Oh, dann habe ich das falsch verstanden.
Ich watschel nochmal durch die Switche und deaktiviere es überall. Gilt das auch für MLD Snooping?
Ich habe jetzt auf allen 4 Switchen IGMP Snooping (inkl. Querier) deaktiviert, aber die MLD Snooping Settings noch unangetastet gelassen.
Großartige Ergebnisse bis jetzt! Die FW2 ist auf BACKUP gesprungen überall.
Ich teste jetzt noch ein wenig umher, ob das bloß "Glück" ist oder wirklich was positives passiert ist.
Auf jeden Fall schon mal ein großes Dankeschön, mimugmail!
Nach Tagen(!) ist das endlich wieder ein Hoffnungsschimmer. ;D
igmp snooping leitet die Pakete nur auf den ports weiter die sich dafür abonniert haben (grob gesagt) .. die Firewall macht das nicht, also deaktivieren und der multicast geht auf allen ports raus.
Für CARP ist das OK, bei IPTV wäre das der Killer .. also kein IPTV auf dem VLAN :)
Gut zu wissen, hab mir IGMP Snooping nie angeschaut - selten mit konfrontiert worden. ;D
Als nächsten Schritt probiere ich wieder das LAGG Interface aufzubauen, mal sehen wie es wird. :)
Firewall 1 hat nun wieder LAGG konfiguriert.
Wenn FW1 im CARP Maintenance Mode ist, springt FW2 wie gedacht ein.
Wenn FW1 aber wieder aktiv geschalten wird, switched nur WAN zu MASTER um - die VLAN Interfaces bleiben im Zustand BACKUP auf der FW1 UND schalten sich in den Zustand BACKUP auf FW2.
Mal schauen wie das aussieht, wenn ich auf FW2 auch wieder das LAGG Interface aufbaue...
Nun haben beide FWs wieder lagg0 als Interface konfiguriert (Round-Robin über ix0 und ix1).
Die FW1 bleibt noch immer WAN MASTER und BACKUP in allen anderen VHIDs.
Die FW2 ist überall im BACKUP Zustand.
Wo kann denn da der Hase im Pfeffer liegen wieder? :o
Screenshots HA und VIP von beiden
Guten Morgen!
Anbei die Bilder :)
Ich habe auch grade probiert die zuvor eingefügten Tunables wieder zu entfernen, da sich diese zuvor scheinbar auch nicht ausgewirkt haben. Leider ohne Veränderung. Reboot wurde gemacht.
"net.inet.carp.ifdown_demotion_factor = 0" und "net.inet.carp.senderr_demotion_factor = 0" waren die Tunables.
Beide sind wieder 240 - geprüft durch sysctl.
Oh und noch weitere evtl. hilfreiche Bilder.
Nochmal die Frage, LaGg und VLAN mit beiden Firewalls an einem Switch, geht das?
Mit beiden LAGG Interfaces an einem Switch kann ich erst Ende der Woche testen, wenn ich vor Ort bin.
Ich kann aber versuchen nur ix1 (hängen jeweils am gleichen Switch) im LAGG zu behalten, also ix0 rauszuwerfen.
Sollte* ja den gleichen Effekt haben.
Also jetzt sind jeweils nur ix1 im LAGG Interface, welche beide auf dem gleichen Switch aufliegen... und voila!
Der Master hat sich die MASTER Rollen alle geholt, die 2. FW sitzt überall als BACKUP rum.
Failover und Failback (CARP Maintenance Mode & Reboot FW-1) funktioniert sauber und flott.
Ich würde LAGG nur mit LACP machen und auch nur auf EINEN Switch und die Backup Unit auf den ZWEITEN Switch, nicht kreuzen und kein Failover.
Das einzige LAGG was wirklich stabil läuft ist LACP, alles andere ist Müll. Das macht VMware vielleicht ganz gut, aber bitte nicht bei der Firewall. Und Überkreuzt stecken sollte man nur bei MLAG oder proprietäre Varianten
Hmm, das kann ich so verkabeln, wäre kein Problem, da die Ausfallsicherheit ja nicht leidet.
Ob jetzt eine Firewall oder einer der Switche ausfällt wäre in dem Fall Wurst, da die 2. FW einspringen kann und der Rest durch die Verkabelung der Switche und Spanning Tree abgefedert wird.
Ich hab mal ein kleines Diagramm erstellt - das sollte doch so hinhauen, hm? :)
Korrekt, leider sinds halt Netgear Switche :D
FreeBSD hat das Problem dass der LAGG kurz flappt wenn ein Member down geht.
D.h. wenn du z.B. auf Switch1 ein Update einspielt flappen beide Firewalls, das ist natürlich ungünstig.
Dann lieber eine Firewall komplett auf einen Switch, dann kannst du bei Switch Update einfach die Master Funktion schieben 8)
Quote from: mimugmail on July 28, 2020, 11:35:07 AM
Korrekt, leider sinds halt Netgear Switche :D
So-called Budget-Lösung ;D
Aber an und für sich benehmen sich die Teile sehr anständig - die M4300er haben in den letzten 5+ Jahren kaum Faxen gemacht. Wie gut die GC752er auf Dauer sind wird sich zeigen...
Quote from: mimugmail on July 28, 2020, 11:35:07 AM
FreeBSD hat das Problem dass der LAGG kurz flappt wenn ein Member down geht.
D.h. wenn du z.B. auf Switch1 ein Update einspielt flappen beide Firewalls, das ist natürlich ungünstig.
Dann lieber eine Firewall komplett auf einen Switch, dann kannst du bei Switch Update einfach die Master Funktion schieben 8)
Uh, das ist wirklich gut zu wissen! :o
Vielen lieben Dank erstmal für deine großartige Hilfe!! ;D
Ich verkabel das die nächsten Tage so und dann schreib ich wieder wies gelaufen ist... vermutlich gleich vor Ort, dann kann ich im Zweifelsfall noch reagieren.
Gibt ja in der Zwischenzeit noch genug andere Kleinigkeiten an dem Konstrukt die es zu lösen gilt... *hust* DHCP Failover, aber dazu mach ich einen separaten Thread auf. ;)
Hi!
Leider konnte ich Freitag nicht direkt schreiben, da noch unerwartet weitere Arbeiten vor Ort angefallen sind.
Ich habe die Verkabelung wie besprochen angepasst und auch an den Switchen und FWs für die jeweiligen 2 Ports eine LAG konfiguriert und LACP aktiviert.
Ein paar kleine Tests lieferten gemischte Ergebnisse.
Zunächst mal, nachdem das Ganze verkabelt und konfiguriert war und auch in der Zwischenzeit, also während an FW1 die Kabel und Konfiguration geändert wurden, hat FW2 ganz brav und sofort die MASTER Rollen übernommen.
Das Failback zu FW1 lief ebenfalls gut.
Also nachdem die "Umbauten" fertig waren war erstmal alles gut. Sicherheitshalber haben auch beide Geräte einen Neustart gemacht.
Dann habe ich mal testweise einen der LAN Links gezogen, da ich hier schon Posts gelesen habe bzgl. LAGG und CARP und wie beschrieben kam es zum Failover, *obwohl* das LAGG Interface noch intakt hätte sein müssen.
Quote from: mimugmail on July 28, 2020, 11:35:07 AM
FreeBSD hat das Problem dass der LAGG kurz flappt wenn ein Member down geht.
Ich dachte mir, dass das vielleicht der Auslöser für diesen Failover sein könnte.
Problem ist, weder der Failover geschweige denn der Failback funktionieren.
WAN machte einen sauberen Failover - alle auf den LAGGs liegenden VHIDs blieben dann auf *beiden* FWs im MASTER Zustand. Ich musste auf dem Master den Maintenance Mode aktivieren, damit die Backup Firewall komplett und korrekt übernahm.
Zurückswitchen konnte ich erst als das gezogene Kabel wieder steckte und ich am Master den Maintenance Mode deaktivierte.
Zwar laufen beide Firewalls so ganz anständig, aber ganz kugelsicher wirkt das Konstrukt noch nicht.
Ich könnte mir auch vorstellen auf das LAGG Interface zu verzichten - das war ja primär für die gekreuzte Verbindung zu den Switchen gedacht.
Durch das flappen der LAGG Interfaces wird ein Failover ja sowieso ausgelöst bzw. provoziert, ob nun ein oder beide Links ausfallen.
Und ich meine... naja, wofür hat man denn ein Failover-Peer? Dann hat man eben eine 0,0x% höhere Chance, dass die Backup-Firewall einspringen muss, aber was solls? Das soll sie ja.
Da lohnt sich der "Ärger" mit der Link Aggregation ja eigentlich gar nicht, da im Falle eines Falles ohnehin volle Redundanz besteht durch die Backup-Firewall.
Bin offen für Meinungen... :D
Hi Felix,
genau dem Pfad bin ich auch schon entlang gelaufen...
Meine Lösung sah dann so aus:
- 2 Huawei Switche gestackt
- 2 OPNsense mit je 4 interfaces active-passive
- Kein lagg und kein LACP
Siehe hier
https://forum.opnsense.org/index.php?topic=14130
und dann als Lösung hier
https://forum.opnsense.org/index.php?topic=14374
Gerade beim der Installation nervt das Aus-/Anschalten des LACP.
Weiterhin verwende ich das LAN (1G) interface als Admin Port - da gibt es dann auch Automatische Regeln, die das unabsichtliche Selberausperren verhindern.
Und das WAN (10G) als Uplink Port, dann hat man da auch automatische Regeln und das Outbound NAT schon mal fertig. Und Suricata mag eh kein VLAN auf dem Uplink port.
Bleiben noch zwei Interfaces übrig:
- Ein 1G für pfSync
- Ein 10G für alle anderen VLANs...
Wenn nun ein Switch ausfällt wegen Firmwarepatch oder so, dann gibt es halt einen failover auf den anderen Switch und eben auch die andere OPNsense.
Und bei mir gehen WAN Strecken immer erst in einen Switchport und da in ein VLAN rein. Und dann von da aus auf die Firewall. Dann kann man auch mal am Switch probieren, ob ein Netz geht und muss beim Ausfall einer WAN Strecke nicht gleich einen Failover der Firewall machen.
Felix: dein letzter Nachsatz/Absatz ist der entscheidende.
HA zu haben ist gut und wichtig! Aber es muss Sinn machen. LAGG mit LACP kann(!) Sinn machen, gerade wenn man mehr Dampf als 1/10G braucht und dazu 2-4 Strecken bündelt und entsprechende Client Anzahlen hat. Gerade wenn dann auf dem LAGG mehrere VLANs liegen, macht sich 2x oder 4x LAGG bemerkbar (bei 1G). Bei 10G wirds schon nicht mehr so griffig, aber selbst da - kann Sinn machen.
Was keinen Sinn macht und ich aus der Praxis egal welcher Sense, BSD o.ä. sagen kann ist genau das was @mimugmail auch schon schreibt. Keine Kreuzverkabelung. Erstens MUSS das der Switch selbst unterstützen und Netgear ist da kein Freund von. Wir hatten es auf Juniper EX Kisten, das geht, weil die einzelnen Switche quasi als Backplanes eines einzigen Switches gesehen werden. ABER: Fällt Switch 1 aus, hast du vielleicht den Failover verhindert (ignorieren wir mal kurzes Chaos weil alle LAGGs flackern) aber nur noch die halbe Bandbreite! Das macht keinen Sinn. Man verkabelt ja dafür, dass man nicht nur Failover hat, sondern ggf. auch wegen Bandbreite. Wenn die aber keine Rolle spielt, dann erkauft man sich mit LACP kaum einen Zugewinn an Sicherheit, den man nicht eh schon durch CARP/Failover der Firewalls und 2 Switche hätte PLUS man bringt noch eine Kontrollschicht und Komplexität in die Architektur mit rein, bei der man am Fehlersuchen ist.
Ergo:
* wenn du die Bandbreite nicht brauchst - löse das LAGG auf und machs ganz ohne LACP. Viel entspannter und einfacher zu debuggen.
* wenns Bandbreite sein soll mach LACP über den gleichen Switch. FWL1 via SWT1 und FWL2 über SWT2.
Also eine H - keine Doppel-X Verkabelung.
* (nur zur Doku wenns jemand anders liest) LACP verdoppelt nicht einfach die Bandbreite. Das macht sich erst mit mehreren Quellen und Zielen bemerkbar!
* LACP über Kabel zu unterschiedlichen Switchen/Backplanes MUSS der Switch unterstützten, normal ist das nicht!
HTH
Grüße
\jens
Hallo zusammen,
Sorry für die späte Antwort. :-\
Das HA-Konstrukt läuft jetzt seit knapp 4 Wochen und bislang bin ich ziemlich happy damit.
Die Firewalls hängen auch je an einem Switch dran, anstatt über Kreuz.
Demnächst lasse ich mal das 2. Update drüber laufen (20.7.2) - auch der Vorgang lief das 1. Mail vor Ort prima, da bin ich mal optimistisch.
Es gibt ein paar kleinere Wehwehchen sind mir noch aufgefallen, die ich auch zeitnah in weiteren Threads behandeln möchte. Aber nichts Tragisches.
Generell bin ich aber sehr glücklich mit dem jetzigen Setup.
LG
Felix
Fein, Danke für dein Feedback