HA Cluster Probleme mit Internet Access

[Spitzbube]

Guten Morgen,

seit einigen Tagen versuche ich nun meinen alten HA Cluster auf neuer Hardware erneut einzurichten.

Hatte ursprünglich ein APU Dual Board in einem 1U Case von Varia. Da die APUs aber nicht mehr weiterentwickelt werden und ich virtualisieren möchte und IDS IPS etc. betreiben möchte waren die APU Boards etwas schwach, daher habe ich mir ein Supermicro SuperServer 5019D-FN8TP gekauft. Diese hat noch zusätzlich über die Riser Card eine Intel X710-DA4 10GBe SFP+ mit SR-IOV Quad Port für die VLANs verbaut. Auf dem System läuft aktuell mal ein ESXi 8 U2 als Test.

Bisherige Konfiguration:

Auf jedem der APU Boards war OPNsens installiert. Die Boards waren über CARP mit einander verbunden und haben eine Ausfallsicherheit zur Verfügung gestellt. Auf jeder OPNsense war noch Adguard Home als DNS 1 und DNS 2 konfiguriert. Das funktionierte bis dato echt gut.

Zielsetzung:

2 OPNsense VMs die eine Hochverfügbarkeit bieten und den Weiterbetrieb bei Ausfall der ersten Master auf der Backup VM weiter führt. Später dann noch ein WAN Failover, wenn das Internet mal über die Fritzbox läuft.

Also habe ich zunächst 2 VMs mit OPNsense aufgesetzt, dabei unbewusst die gefälschten Übertragungen und die MAC Adress Änderungen unter den Einstellungen des vSwitches und der Portgruppe zugelassen und die MAC Adresse auf automatisch in den Einstellungen der Netzwerkkarte der VM gestellt. Als Lan Adapter wurde der Intel E1000 verwendet. So habe ich zunächst eine VM installiert und dann die Zweite. Interfaces, IP Adressen, VLANs und Firewall-Rules auf beiden hinzugefügt und die Virtuellen IP-Adressen + die Hochverfügbarkeit + Outbound NAT konfiguriert.

Später habe ich dann beim ersten Test der Hochverfügbarkeit bemerkt, dass die Interface Zuweisungen der VMs sich total verschoben haben. Was beim Setup der VMs der OPNsense noch em1 -> WAN em0 -> LAN und -> em2 für CARP waren, wurde wohl bei der Zuweisung der VLANs komplett durcheinander geworfen. Sprich: VLAN 50 für MGNT hatte bei der Prüfung dann das Interface em2 was beim Config noch für CARP gedacht war. Sprich  die MAC Adressen und Interfaces waren auf der 2. VM anders als bei der ersten. Also nochmals alles gelöscht.

Habe dann versucht, die Netzwerkkarten einzeln hinzuzufügen. Erst die LAN, WAN, CARP welche über die Onboard Schnittstellen der Firewall gestellt werden, dass hat dann endlich funktioniert, bis diese Intel Quad Nic mit den VLANs ins Spiel kam. Hab dann versucht, die MAC Adressen manuell in den Einstellungen der VM zuzuordnen aber dann starten die virtuellen Maschinen nicht. Nun habe ich für die Interfaces LAN, WAN, CARP zunächst die E1000 genommen und die Intel Quad Nic für die VLANs mal nicht konfiguriert. Die beide VMs die gleichen haben nun Interfaces. em1 -> WAN, em0 -> LAN und em2 -> CARP und die MAC Adressen passen soweit auch.

Nach einigen Tutorials und Artikel im Internet habe ich beide Firewalls nun für die Hochverfügbarkeit konfiguriert. Das CARP funktioniert und synct die Config von der Master auf die Backup FW. Was nun nicht geht ist der Ping auf die virtuelle WAN und LAN IP sowie der Internet Zugriff. Hab dann im Firewall Log geprüft, der Ping auf die Virtual WAN wird vom WAN-IF geblockt, da Haken bei Block private Networks im Interface gesetzt ist. Der Ping auf die virtuelle LAN IP, welcher nicht geht ist mir ein Rätsel.

Config Fritzbox:

Exposed Host auf die CARP MAC Adresse des virtuellen WAN Interfaces mit der IP 192.168.0.15/24 der OPN Sense.

OPN-Sense 1:
GW-WAN 192.168.0.10/24
Interface WAN: 192.168.0.10/24
Interface LAN: 192.168.10.10/24
CARP Interface: 10.0.0.1/24
Virtuelle IP:
WAN: 192.168.0.15/24
LAN: 192.168.10.1/24

OPN-Sense 2:
Interface WAN: 192.168.0.20/24
Interface LAN: 192.168.10.20/24
CARP Interface: 10.0.0.2/24
Virtuelle IP:
WAN: 192.168.0.15/24
LAN: 192.168.10.1/24


Firewallrules - Auf beiden Seiten:

LAN IN OUT any any
WAN IN CARP
CARP: IN OUT any any

LAN DHCP auf beiden Firewalls:

Pool 192.168.10.21 - 192.168.10.249
GW: 192.168.10.1
DNS: 192.168.10.1

Als DNS habe ich mal den DNS Masq konfiguriert
Port 53
-> Enable DNSSEC Support
-> Register DHCP leases
-> Query DNS servers sequentially

Unter System-Settings-General

DNS Server 9.9.9.9
-> Do not use the local DNS service as a nameserver for this system

Irgendwo ist eine Setting nicht richtig aber ich komm echt nicht dahinter. Er meldet zwar ein DNS_PROBE_FINISHED_NO_INTERNET im Browser aber wenn die virtuelle LAN IP schon nicht erreichbar ist, bleibt der DNS Server erst mal 2. Prio. Möglich, dass Freebsd / OPNsense mit dem VMware Netzwerkadaptern nicht klar kommt? Meine, mich erinnern zu können dass mit den Intel E1000 zumindest der Ping auf die virtuelle WAN IP funktioniert hat.

[trixter]

wie sehen denn VHID / advbase und advskew bei Dir aus ?
welche physikalischen Interfaces stecken hinter den Carp-VIPs ?
Für mich sieht das aus, als hingen die in der Luft.

[Spitzbube]

Hallo,

sorry für die verspätete Nachricht. An sich geht der Cluster jetzt. Hab da noch etwas in den VMware Einstellungen der Port Gruppe getestet. Eine der LAN Ports hatte die MAC-Adress Änderung nicht aktiv. Habe dann noch den Promiscuous-Mode auf allen Nics aktiviert und dann hats auch mit dem Internet funktioniert.

Stimmt die VIPS hatte ich nicht ausführlich beschrieben:

VHDI Group natürlich von 1 beginnend auf jeder FW fortlaufend.

Virtual LAN -> LAN Interface
Virtual WAN -> WAN Interface

Auf der Master FW advskew 0 & Backup FW dann advskew 100, zwecks Gewichtung.

Allerdings habe ich jetzt noch ne Problematik mit einem Switch vor dem ganzen Cluster zu lösen: Die Fritzbox hat ja 4 Lan Ports. 2 davon gehen bereits in meinen 2 Node Firewall Cluster. Dieser Cluster ist nur für die Home Seite sprich private Clients und IoT. Habe nun mal einen TP-Link TL-SG2218 als Core Switch davor gehängt, um meine Möglichkeiten zu erweitern.

Ziel soll es sein 2 weitere 2 Node Firewall Cluster zu integrieren. Dabei soll meine alte APU Dual Board Lösung als LAB Cluster und eine andere Supermicro Firewall als DMZ Firewall dienen. Der Switch soll lediglich den Zugang zum WAN verbessern, damit ich alle Firewalls WAN-Seitig von 4 auf 6 Anschlüsse erhöhen kann.

Nun ist es aber so, dass der Switch im WAN Netz der Fritzbox mit der 192.168.0.5/24 hängt und zwar ansprechbar ist, den WAN Traffic für die Firewall aber nicht durchlässt.

Fritzbox (192.168.0.1/24) -> Switch (192.168.0.5/24) -> Firewall (VIP WAN 192.168.0.15/24) was muss ich am Switch bzw. an den Firewalls den einstellen? Hab schon am WAN Interface -> das Block private Netzworks deaktiviert und in den Firewall Rules mal pass any any aktiviert. Aber damit hat es auch nicht geklappt. hat jemand ne Idee oder anders gefragt nen Vorschlag wie man das vllt. besser umsetzen kann mit der WAN Anbindung?

[viragomann]

Hast du die Tipps in https://docs.opnsense.org/manual/virtuals.html#virtual-cloud-based-installation berücksichtigt?

Mit der HA OPNsense verbundene Geräte müssen den Wechsel der MAC Adresse erlauben. Die Funktion wird oft MAC Spoofing genannt. Das müsste zumindest am Switch aktiviert werden.

[bimbar]

Warum 3 Firewall Cluster? (Ich bin neugierig ;) )

[Spitzbube]

Hast du die Tipps in https://docs.opnsense.org/manual/virtuals.html#virtual-cloud-based-installation berücksichtigt?

Ja habe ich. Das war auch eins der Probleme bei dem HA Cluster, warum kein Internet funktionierte bevor der Switch ins Spiel kam. Das funktioniert nun aber problemlos.

Mit der HA OPNsense verbundene Geräte müssen den Wechsel der MAC Adresse erlauben. Die Funktion wird oft MAC Spoofing genannt. Das müsste zumindest am Switch aktiviert werden.

Also bei dem Switch handelt es sich um einen TP-Link TL-SG2218. Im Handbuch steht zu MAC-Adress Spoofing nichts.

The MAC address table contains address information that the switch uses to forward
packets. As shown below, the table lists map entries of MAC addresses, VLAN IDs and
ports. These entries can be manually added or automatically learned by the switch. Based
on the MAC-address-to-port mapping in the table, the switch can forward packets only to
the associated port.


Wenn ich da richtig liege, bin ich aber vom Spoofing der MAC Adresse nicht begeistert und sehe es eher als Sicherheitsgefahr.

Drei Sachen will ich nochmals genau anschauen

1. Welche MAC Adressen lernt der Switch -> auch diese des CARP Interfaces WAN: 192.168.0.15/24
2. Ist VLAN Security standardmäßig global aktiviert und was passiert wenn man es deaktiviert.
3. Was passiert bei einem statischen MAC Adress Eintrag.

[viragomann]

Der Text beschreibt lediglich standardmäßiges Switch-Verhalten.
MAC Spoofing sollte bei einem L2 Switch gar kein Thema sein, fällt mir ein. Ist eher was für Geräte, die mit IPs (L3) arbeiten.

Bei CARP gibt es für die VIP eine eigene MAC Adresse. Die hat eben der Master inne und wechselt natürlich mit der Rolle zur anderen Node.
Dieser Punkt würde sich nur bei einem Failover auswirken.

Die andere Sache ist aber, dass die OPNsense Pakete immer von ihrer primären Interface-MAC aussendet.
Wenn also ein Request auf die CARP-MAC geht, kommt der Response dennoch von der Interface-MAC. Das gefällt einigen Geräten eben nicht und wird MAC-Spoofing genannt.

Ein Sicherheitsrisiko wäre das nur insofern, dass auch ein anderes Gerät mit einer gespooften MAC antworten könnte.
Die MAC ist aber ebenso wie die Interface MAC bekannt und die Kommunikation könnte darauf beschränkt werden.

Der Switch lernt, welche MAC an welchem seiner Ports angeschlossen ist. Da die CARP-MAC aber von mehreren Geräten verwendet wird, muss auch der Switch hier umschalten. Ob das manuell so eingetragen werden kann, weiß ich nicht.
Es sollte aber nicht erforderlich sein. Manuelle Einträge wären eine Absicherung, um nur bestimmte MACs zuzulassen.

[Spitzbube]

Geb ich dir in allen Punkten vollkommen recht. Was kann ich nun tun? Hab mal eben auf die Schnelle gegooglet, habe keinen Switch gefunden der das können soll. Die Einträge die ich gefunden habe gehen nur gegen gefälschte Mac-Adressen vor in vom von Port-Security oder ähnlichem. Zielsetzung ist es ja nur aus den 4 Ports der Fritzbox die momentan an die beiden virtualisierten OPNsensen von der Fritzbox Port 1 und Port 2 anliegen (jede hat Ihr eigenes WAN Interface) mehr Geräte anzusteuern zu können. Den TP-Link Switch hatte ich noch hier für Tests.

Hab hier noch ne ältere Supermicro Firewall und ein aktuelles Apu Dual Board Case von Varia rumliegen. Da läuft vllt. kein IDS / IPS ala Scuricarta / Zenamor performant drauf aber das APU Board welches der Vorgänger meiner momentanen Working Config war, packt auch dieses 2 Node Cluster Setup mit CARP. Warum also nicht die verbleibenden 2 LAN Anschlüsse der Fritzbox für ein Lab Firewall Setting nutzen? Gleiches mit der älteren Supermicro FW. Zwei RAM Riegel rein und ne DMZ aufbauen. Damit hab ich alles was zum Ausfall meines Heimnetzwerk führen kann in einem eigenen Bereich und muss mein Heimnetz nicht für Webserver und NAS Systeme öffnen.

[viragomann]

Geb ich dir in allen Punkten vollkommen recht. Was kann ich nun tun? Hab mal eben auf die Schnelle gegooglet, habe keinen Switch gefunden der das können soll.

Ich wollte eigentlich sagen, dass das vermutlich gar nicht das Problem ist, weil Layer 2 Switche das üblicherweise gar nicht unterbinden, schon gar nicht, wenn sie dafür keine Einstellung haben.

Es könnte auch am ESXi liegen. Früher gab es die Anforderungen, den 'Promiscuous Mode' auf den virtuellen Switchen zu aktivieren. Das ist aber mittlerweile aus den Anleitungen verschwunden.
Die letzte CARP habe ich auf Version 6 aufgesetzt. Das war das zwingend erforderlich.

[Spitzbube]

Also was ich bereits zu Beginn geschrieben hatte: Als das Internet noch nicht ging hab ich in der Tat auf einem der WAN Anschlüsse die gefälschten Übertragungen der MAC Adresse vergessen anzuhaken. Der Promiscuous Mode ist auf allen NICs aktiv.

VMware schreibt dazu dies:

Der Promiscuous-Modus deaktiviert jegliche Empfangsfilterung, die der Adapter der virtuellen Maschine ausführt, sodass das Gastbetriebssystem den gesamten Datenverkehr aus dem Netzwerk empfängt. Standardmäßig kann der Adapter der virtuellen Maschine nicht im Promiscuous-Modus betrieben werden.

Der Promiscuous-Modus kann zwar für die Nachverfolgung von Netzwerkaktivitäten nützlich sein, aber er ist ein unsicherer Betriebsmodus, da jeder Adapter im Promiscuous-Modus Zugriff auf alle Pakete hat, selbst wenn manche Pakete nur für einen spezifischen Netzwerkadapter bestimmt sind. Das bedeutet, dass ein Administrator oder Root-Benutzer in einer virtuellen Maschine rein theoretisch den Datenverkehr, der für andere Gast- oder Hostbetriebssysteme bestimmt ist, einsehen kann.

Ließt dich für mich zunächst mal zumindest nicht danach, dass etwas restriktiv geblockt wird. Konnte gestern noch die MAC Address Table des Switches anschauen. Zumindest hier werden alle WAN Interfaces von beiden OPNsense Maschinen aufgeführt inklusive der CARP und der Fritzbox. Werde den Promiscuous-Modus im nächsten Schritt mal auf allen Interfaces ausschalten.

Gibts den Seitens der OPNsense noch Settings die ich testen kann?

Mir fällt da spontan ein:

- WAN Interface -> Block private Networks 192.168.0.5/24 = Switch
- Firewall Rules -> WAN: Hier ist nur eingehend das Protokoll CARP zugelassen.

Hab nun den Client hinter den Switch und den Switch direkt an der Fritzbox angeschlossen. Der Switch hat die 192.18.0.5/24 lässt Internet durch aber ist selbst nicht im Internet, warum auch immer.

Den Promiscuous-Modus habe ich mit und ohne den Switch zwischen Fritzbox und Firewall getestet und deaktiviert. Kein Internet.

Ist echt schwierig zu sagen. Also entweder dem Switch gefällt das CARP Geraffel dahinter nicht oder die Firewalls blocken noch irgendwas. Bin echt etwas ratlos an der Stelle. Was für Fakten kann ich noch schaffen?

Auf den OPNsensen lauf noch ein Outboud DNS auf Port 5353 und auf jeder VM Adguard Home. Hab das nach dem HowTo konfiguriert: https://windgate.net/setup-adguard-home-opnsense-adblocker/ statt dem Cloudflare habe ich dann bei DNS over TLS habe ich den DNS Forge quic://dnsforge.de:853 benutzt. Das ging seither problemlos.

Wo ich nicht ganz durchsteige sind die Automatic Generated Rules / Default deny / state violation rules. Kann man die nicht kurzfristig deaktivieren?

[viragomann]

Hab nun den Client hinter den Switch und den Switch direkt an der Fritzbox angeschlossen. Der Switch hat die 192.18.0.5/24 lässt Internet durch aber ist selbst nicht im Internet, warum auch immer.

Vermutlich, weil er kein Gateway hat. Nicht untypisch für solche Geräte.

Ist echt schwierig zu sagen. Also entweder dem Switch gefällt das CARP Geraffel dahinter nicht oder die Firewalls blocken noch irgendwas. Bin echt etwas ratlos an der Stelle. Was für Fakten kann ich noch schaffen?

Das Problem ist nun nach wie vor, dass die CARP VIP nicht ansprechbar ist? Aber Internet geht hinter der OPNsense?
Für Internet wäre ja die CARP VIP als Gateway zu nutzen. (?)

Untersuchungen kannst du mit Packet Capture anstellen. Damit kannst du prüfen, ob die an die CARP VIP adressierten Pakete am Interface ankommen.

[Spitzbube]

Der Switch hat in der Tat kein Gateway. Bei Default VLAN 1 kann ich die IP Modes: None, Static, DHCP, BOOTP. Wobei ich nicht verstehe was mit None gemeint ist.

- Das Problem ist nun nach wie vor, dass die CARP VIP nicht ansprechbar ist?

-> Du meinst die Virtual WAN IP? Doch klar ich kann die 192.168.0.15 pingen. Die ist auch Online unter Heimnetz -> Netzwerk.

Das Problem ist: Sobald der Switch eingeschaltet zwischen Fritzbox und der Opnsense hängt bekomme ich am Client hinter der Opnsense kein Internet. Selbst wenn der Switch noch keine Verbindung mehr zur Firewall hat und nur eingeschaltet mit der Fritzbox an den WAN Ports verbunden ist, geht kein Internet. An der Fritzbox ist aber weder ein Exposed Host noch ne Prio für den Switch eingestellt.