Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - TheExpert

#1
So, nun funktioniert auch die Zertifikatserstellung mit dem Wildcard-Zertifikat auf beiden Knoten. Durch Copy & Paste hatte sich ein Leerzeichen am Anfang des TXT-Records eingeschlichen.
#2
Vielen Dank für die Information. Ich werde versuchen, ein Wildcard-Zertifikat zu bekommen. Leider klappt das aber noch nicht, weil die DNS-Verifikation nicht möglich ist: Der TXT-Record scheint nicht veröffentlicht zu werden. Wenn ich mit der MXToolbox den TXT-Record abfrage, erfolgt direkt die Abfrage beim Nameserver der Domain, aber der Record wird nicht angezeigt. Ich habe daher beim DNS-Anbieter (Selfhost) nachgefragt.
#3
So, jetzt bin ich einen Schritt weiter, aber noch nicht am Ziel. Der TXT für die DNS-Challenge wird eingetragen: The TXT record has been successfully added. Aber dann kann der ACME-Client bisher nicht den TXT-Eintrag verifizieren und somit das Zertifikat nicht anfordern oder erneuern.

Dieser TXT-Eintrag dient ja nur zur Verifizierung der DNS-Challenge, richtig? D. h. der Backup-Firewall-Knoten kann die Challenge auf den gleichen TXT-Record machen, oder? Ich hatte nämlich ursprünglich 2 TXT-Records hinterlegt (_acme1, _acme2), aber der ACME-Client will immer den Record mit dem Namen "_acme-challenge" verwenden. Daher habe ich nun nur noch den TXT-Record "_acme-challenge" angelegt.
#4
OK, danke. Ich teste das mal. Wie sehe ich denn, ob die eingerichtete Challenge funktioniert?
#5
Ich nutze DynDNS, da ich keine feste öffentliche IP-Adresse habe (privater DSL-Anschluss). Der Anschluss terminiert an einer FritzBox, hinter der dann die Firewall als exposed Host steht. Die Firewall hat feste IP-Adressen im Transfernetzwerk zwischen Firewall und FritzBox.

Für einen Zugriff von außen benötige ich nur einen öffentlich erreichbaren FQDN und das Let's Encrypt Zertifikat, die ich auf die CARP-VIP binde.

Und mir ist immer noch nicht klar, wie ich das nun im Cluster konfiguriere: Auf beiden oder nur auf dem primären Knoten?
#6
Vielen Dank. Dann benötige ich für jede WAN-Adresse der OPNsense einen öffentlichen FQDN, richtig? Ich habe derzeit nur eine DynDNS-Domain, für die ich über die Sophos UTM ein Let's Encrypt Zertifikat verwalten lasse.
#7
Hallo zusammen,

ich baue gerade einen OPNsense Cluster auf, auf dem ich auch ein Let's Encrypt Zertifikat einbinden möchte. Grundsätzlich weiß ich, wie das umgesetzt wird. Aber ich frage mich, wie man das auf einem Cluster umsetzt?

Die Zertifikate können im Rahmen der Synchronisation auf den Backup-Knoten kopiert werden, so dass die Einrichtung des ACME Clients nur auf dem primären Knoten ausreichend sein müsste, richtig? Was aber ist, wenn der primäre Knoten für längere Zeit nicht verfügbar ist und das Let's Encrypt Zertifikat genau in dieser Zeit abläuft und dann nicht automatisch erneuert wird? Es ist eine sehr theoretische Frage, weil das Zertifikat vermutlich sehr rechtzeitig erneuert wird - zumindest war das bei der Sophos UTM so. Der Fall des abgelaufenen Zertifikates sollte eigentlich nicht auftreten, aber wir wissen alle, dass es immer zu dummen Umständen kommt, die dann doch genau solche eigentlich unwahrscheinlichen Fälle hervorbringen.

Oder muss ich auf dem Backup-Knoten den ACME Client konfigurieren, um dort das Zertifikat auch automatisch regelmäßig zu erneuern? Dann aber stellt sich die Frage, ob man überhaupt 2 Zertifikate für den gleichen Domainnamen anfordern kann? Letztere Frage stellt sich mir außerdem, weil meine Sophos UTM noch läuft und ich in der Migrationsphase zu OPNsense bin.

Im Internet finde ich immer nur die grundsätzliche Beschreibung zur Einrichtung von Let's Encrypt in der OPNsense, aber nirgendwo wird auf die Einrichtung auf einem Cluster eingegangen - zumindest habe ich dazu bisher nichts gefunden.

Vielen Dank und viele Grüße

TheExpert
#8
Quote from: viragomann on February 08, 2026, 05:06:34 PM
Quote from: TheExpert on February 08, 2026, 01:09:58 PMIch sehe nicht viel Mehrwert, für jedes VLAN eine eigene virtuelle Netzwerkkarte anzulegen, denn letztlich wird der Datenverkehr für die LANs immer über ein und die selbe Netzwerkverbindung geleitet.
Wenn der Hypervisor die auch ohne ordentlich durchschleift, sollte das auch nicht nötig sein. Aber eventuell muss ihm das erst beigebracht werden.

Ich habe meine OPNsense hier auf KVM virtualisiert und auf dem Netzwerkport zum WLAN AP mit 5 VLANs auch nichts davon am Host eingerichtet, nachdem der nicht mehr damit tun soll, als die Hardware-Schnittstelle mit der VM zu verbinden. Das läuft seit Jahren so ohne Probleme.

Wenn du aber den kompletten Trunk an OPNsense anbindest, musst du auf jeder OPN jedes VLAN samt einer IP einrichten und sicherstellen, dass beide über diese eine Layer 2 Verbindung haben, damit CARP funktioniert.
Ja, genau so habe ich es jetzt auch gemacht und das CARP funktioniert sofort für die weiteren VLANs :-).
#9
OK, danke.

Ich kann jetzt schon mal sagen, dass nun auch die CARP-VIP für LAN korrekt funktioniert, nachdem ich die redundanten physikalischen Netzwerkkarten aus dem Trunk für die Sophos entnommen, auf dem Switch die entsprechenden Ports auf "Tag all" gesetzt und in den ESXi-Hosts einen neuen vSwitch mit 2 Portgruppen erstellt habe:

1. Trunk-Portgruppe mit VLAN-ID 4.095
2. LAN-Portgruppe mit der VLAN meines LANs

Die virtuelle Netzwerkkarte für LAN der beiden OPNsense VMs habe ich dann mit jeweils mit der Trunk-Portgruppe verbunden und in OPNsense habe ich für das LAN ein VLAN eingerichtet und der LAN-Schnittstelle der OPNsense zugewiesen.

Den Failover und Faultback habe ich bereits erfolgreich testen können.

Nun werde ich in der OPNsense die weiteren VLANs einrichten und dafür die CARP-VIPs anlegen. Da es sich auch hier um LAN-Netzwerke handelt, packe ich diese ebenfalls auf die LAN-Schnittstelle der OPNsense. Dann gehen alle LAN-VLANs über eine Netzwerkkarte. Ich sehe nicht viel Mehrwert, für jedes VLAN eine eigene virtuelle Netzwerkkarte anzulegen, denn letztlich wird der Datenverkehr für die LANs immer über ein und die selbe Netzwerkverbindung geleitet.
#10
Vielen Dank. Ich habe mir schon fast gedacht, dass alle VLANs getagged sein müssen.

Die derzeitige beschriebene Konfiguration habe ich von der Sophos UTM übernommen, bei der das interne LAN nicht getagged sein darf.

Ich werde heute einen neuen Trunk in den ESXi-Hosts anlegen, in dem alle LANs getagged sind. Dazu nehme ich dann einfach die redundanten physikalischen Netzwerk-Verbindungen zu einem der beiden Switche aus den bisherigen vSwitches heraus und ordne diese den neuen vSwitches zu.

Die Konfiguration von je einer virtuellen Netzwerkkarte pro VLAN halte ich für sehr komplex. Klar, in OPNsense muss pro VLAN ein Gerät eingerichtet werden. Hast Du vielleicht das mit virtueller Netzwerkkarte gemeint?
#11
Hallo zusammen,

ich habe mich entschlossen, meinen seit vielen Jahren zuverlässig laufenden Sophos UTM HA-Cluster in meinem IT-Homelab nun auf OPNsense umzustellen. Daher habe ich heute die beiden OPNsense Firewall Knoten mit der ISO von OPNsense installiert und auch HA eingerichtet. Ich bin dazu nach der Anleitung von Thomas Krenn vorgegangen (https://www.thomas-krenn.com/en/wiki/OPNsense_HA_Cluster_configuration). Für das WAN- und DMZ-Interface funktioniert das auch richtig, aber mit dem LAN-Interface nicht - beide Firewall-Knoten zeigen die CARP-VIP für LAN im Modus BACKUP an.

Die beiden Knoten befinden sich als VMs jeweils auf einem separaten ESXi 8.0 Host. Cluster, LAN, WAN und DMZ sind separate VMXNET3 Netzwerkkarten in der VM und sind an separaten vSwitches angeschlossen, an denen wiederum jeweils eigene physikalische Netzwerkkarten des Hosts angebunden sind - für LAN sogar 2 physikalische Netzwerkkarten. Für LAN habe ich auf den ESXi-Hosts einen vSwitch mit mehreren VLANs eingerichtet. Die VLAN-ID der Portgruppe ist 4.095 (Trunk). Das Standard-LAN ist untagged, die weiteren LANs sind tagged. Die beiden physikalischen Netzwerkkarten für LAN sind jeweils an zwei unterschiedlichen physikalischen Switchen angebunden.

Mit dieser Konfiguration erreiche ich ohne Probleme die Management-IPs der beiden Firewall-Knoten. Die Management-IPs befinden sich im untagged LAN. Dementsprechend komme ich auch auf die Admin-Oberfläche der beiden Systeme.

Auf den beiden Knoten habe ich die VLANs noch nicht angelegt. Hier weiß ich noch nicht, ob ich hier auch jedes Mal eine CARP-Konfiguration vornehmen muss oder ob dafür auch ein IP-Alias ausreichen würde. Ich habe derzeit lediglich eine CARP-VIP für das untagged LAN eingerichtet. Die weiteren LANs würde ich erst einrichten, wenn das HA für das Standard-LAN funktional habe.

Nun frage ich mich, warum die beiden Firewall-Knoten die CARP-VIP für das LAN im Modus Backup anzeigen? Aus einem mir nicht ersichtlichen Grund können die beiden Firewall-Knoten nicht über die LAN-Interfaces miteinander kommunizieren.

Was kann ich tun, um den Fehler zu beheben?

Vielen Dank und viele Grüße

TheExpert