Probleme mit Miniserver Rev 1 in Verbindung HA Firewall - virtual Gateway

[cybernik]

Hallo!

Ich habe 2 OpnSense Firewalls im High Availability betrieb und nutze dazu die virtuelle CARP IP Adresse für den Gateway. Es soll also beim Ausfall einer der beiden Firewalls alles weiter funktionieren. Das klappt auch wie geplant mit allen Geräten nur mit dem Miniserver nicht.
Hat da jemand eine Idee?

[svethi]

Zu solchen Konstrukten wirst Du hier nicht viel finden. Vielleicht solltest Du mal genau beschreiben was Du da vor hast. Soll die HA Firewall den MS schützen? Ist der MS hinter der HA -Firewall im lokalen Netz und da geht alles? Der MS kommt nicht ins Internet durch die HA Firewall? Du kommst nicht von außen durch die HA Firewall zum MS? Für letzteren Fall frage ich mich aber stark nach dem Sinn. Da gibts ne hoch verfügbare Firewall und dann willst Du auf den MS vom Internet aus zugreifen können? Sowas macht man über ein VPN.

Wie gesagt. Beschreibe mal genauer was Du brauchst und was geht und was nicht geht.

[cybernik]

Hallo svethi!
Deine Annahmen sind alle falsch! Der MS ist nicht vom Internet aus direkt erreichbar.
Ich habe ein mehrfachsgentiertes Netz um auch kiritsche komponenten wie Zutrittssystem und Alarmsystem von den anderen Services durch die Firewall trennen zu können.
Die Firewall ist hoch verfügbar ausgeführt. Die Umscahltung erfolgt via CARP! Es wird also wie bei HA Firewalls üblich die Gateway Adresse von einer FW auf die andere transferiert.
Das klappt auch mit allen Geräten nur eben mit den MS nicht.
Somit ist der MS nur aus dem layer 2 Netz in welchem sich dieser befindet erreichbar bzw kann selbst auch nur Verbindungen in seinem Netz aufbauen.
Und nein es liegt nicht an der Firewall Rule!

In einem Einfamilienhaus wirst du so eine Lösung selten finden. In größeren Netzen aber schon.

[svethi]

Und Deine Aussagen sind noch immer keine Aussagen! Du solltest beschreiben von wo zu wo es nicht etc. pp. Deine Konfiguration des MS, Deines Netzes, sowie Deiner HA-Firewall ist falsch wenn es nicht funktioniert. Diese Annahme mag ja auch wieder komplett falsch sein, aber Du wirst das früher oder später schon selbst rausfinden.

[orli]

Kenne CARP zwar nur in Verbindung mit der pfsense, aber da opnsense ein Fork derer ist, wirds da ähnlich sein.
Eine entsprechende Outgoing Rule für dein CARP Device hast du gesetzt? VHID ist nicht doppelt vergeben, Passwort passt auch?

Wenn das alles passt und du der Meinung bist das alles korrekt konfiguriert ist, mach ein Ticket bei Loxone auf. Der Miniserver Compact als auch der Audioserver arbeiten mit Linux-Bridges und internen VLANs... kein Plan wie diese Konstellationen auf CARP reagieren. Und der Miniserver Gen1 ist kein natives Linux wie die neueren Geräte.... der Netzwerk Stack daher vermutlich uralt.

[EdiB]

Ich habe auch einen MS in einem anderen Subnet als der Client resp. der App. Ich musste ein SNAT(MASQUERADE) machen damit die Anfrage an den MS vom GW im Netz des MS kommt damit die App nicht meint sie müsse eine Verbindung über die externe Adresse machen. So ganz habe ich noch nicht verstanden, wie die App entscheidet ob sie über die interne oder externe Adresse die Verbindung zum MS machen soll. Jedenfalls reicht es nicht, wenn die interne Adresse, z.B über ein Routing erreichbar ist, dass er dann die Verbindung auch über die interne IP macht.

[Jan W.]

Ich denke, dass CARP weniger das Problem ist. Dem MS ist es völlig egal, welche IPv4-Adresse und welche zugehörige MAC-Adresse das Default Gateway hat, solange diese sich nicht ändert. CARP ist ein Protokoll, bei dem die (virtuellen) MAC-Adressen von der jeweils aktiven Firewall übernommen werden. Die Endgeräte müssen das Protokoll weder kennen, noch irgendwie unterstützen.

cybernik: leider hast Du nicht erwähnt, wie das Problem aufgetreten ist, also z.B. es hat alles funktioniert, bis die OpenSense Firewall redundant als Cluster aufgebaut wurde oder es hat alles funktioniert, solange der MS lokal im gleichen IP-Subnetz wie die mobilen Geräte und PC's waren. Oder es hatte noch nie funktioniert und ist eine neue Installation. Ebenso hast Du nicht erwähnt, ob der MS generell nicht auf andere IP-Subnetze zugreifen kann, es nur mit LoxoneConfig oder/und mit dem Zugriff per App Probleme gibt.

Für LoxoneConfig gibt es den expliziten Haken, eine Konfiguration über das "Internet" zuzulassen (ganz unten), siehe https://www.loxone.com/dede/kb/remote-connect/ . Hierbei gilt ein anderes IP-Subnetz im LAN aber schon als "Internet" und daher ist die von Loxone verwendete Bezeichnung nur dann passend, wenn es außer dem einen lokalen IP-Netz nur das Internet gibt. In einem segmentierten IP-Netz muss daher diese Option angekreuzt sein. Der Workaround von EdiB ist zwar auch möglich, um dem MS einen lokalen Zugriff vorzugaukeln, aber nach meiner Ansicht sollte SNAT im eigenen Netz möglichst vermieden werden.

Der andere Punkt ist der Zugriff per App. Die App versucht immer zuerst die interne Adresse des MS zu erreichen. Wenn das fehlschlägt (keine Erreichbarkeit der IP-Adresse, Zugriff per FW-Policies nicht erlaubt), dann versucht es die App über die externe Adresse. Als "Adresse" kann statt einer IP-Adresse auch ein Name (FQDN) konfiguriert sein und der muss natürlich per DNS auch auflösbar sein. Manchmal liegen die Probleme aber auch an einer falschen Subnetz Maske, daher sollten die IP-Adressen, Default Gateways und Subnetz Masken auf allen Geräten überprüft werden, am besten mit einem Subnet Calculator.

[Christian Fenzl]

Nicht zu vergessen, dass Weninterface und App Websocket nutzt, die Verbindung also nicht nach irgendeinem Timeout abgebrochen werden darf.

Du musst beschreiben, was konkret nicht funktioniert.