OPNSense blockiert SSH-Verbindungen, wenn zwei Interfaces aktiv

[MPGxxxLegend]

Vielleicht hat hier jemand noch einen Input.
Ich versuche folgendes umzusetzen bin aber auf ein Problem gestoßen, was ich mir selbst nicht genau erklären kann. Will einen WatchyourLan Container installieren der auf all meinen VLAN/LANs lauscht, jedoch nur von spezifischen Geräten Zugiff darauf gewähren. Also ufw installieren und routing vom docker selbst übernehmen, somit iptables für docker ausschalten. Dies hat soweit funktioniert, bis ich das Interface hinzufüge, von welchem Subnet aus ich die VM manage per SSH.

Somit VM zurückgesetzt und nur die Interfaces mal hinzugefügt und siehe da Problem gefunden, die OPNSense blockiert nach einer gewissen Zeit den SSH Traffic.
[Bild1]

Überblick.:
VM - 10.20.20.16/24 - VLAN ID 20 Homelab
[Bild2]
PC - 10.20.10.2/24 - VLAN ID 10 User

VM als auch OPNSense läuft auf Proxmox als VM
Sobald ich mit dem PC im gleichen Subnetz befinde kein Problem, klar wird auch nicht geroutet
Erstellen einer Firewallregel die den Traffic erlaubt, wird die Verbindung nach 30 sec geblockt von OPNSense
MAC Adressen gecheckt ob irgendwo ident, nein nur die des VLANs mit dem parent Interface

[Bild3]
Des Weiteren sind im ARP Table unter OPNSense die für die VM hinterlgeten fixen IPs jener VLAN/LANs nicht ersichtlich bzw. kurz und verschwinden wieder.

Proxmox Hardware
[Bild4]
Warum ich bis jetzt noch nicht auf das Problem gestoßen bin, weil ich keine VM habe welche ein gleiches Interface hat in welchem sich mein Management-PC befindet.

[viragomann]

Dein Problem, durch die unterschiedlichen Interfaces ergibt sich asymetrisches Routing, wenn du auf eine IP aus einem anderen Subnetz zugreifst.

Der einfachste Weg, das in den Griff zu bekommen, ist wohl, den Traffic auf OPNsense mit einer ausgehenden Regel auf die Interface IP zu natten.
Die Ziel-Maschine sieht dann allerdings die OPNsense als Quelle.

[MPGxxxLegend]

Somit habe ich aber das Problem, dass quasi die Gateway IP bei der VM aufscheint und ich nicht die ufw Regeln so einfach setzen kann.
Lösung wäre das Management der VM über das Interface laufen zulassen in welchem mein PC läuft?
Sprich SSH über 10.20.10.70 und per ufw Regel 10.20.10.2 drauf zugreifen lassen, statt über 10.20.20.16.

[viragomann]

Somit habe ich aber das Problem, dass quasi die Gateway IP bei der VM aufscheint

Ja, hab ich ja geschrieben.

Lösung wäre das Management der VM über das Interface laufen zulassen in welchem mein PC läuft?
Sprich SSH über 10.20.10.70 und per ufw Regel 10.20.10.2 drauf zugreifen lassen, statt über 10.20.20.16.

Als PC hast du oben 10.20.10.2/24 genannt.
Ansonsten verstehe ich das leider auch nicht.

Aber egal. Sache ist, wenn der Zugriff von einer Quelle außerhalb des eigenen Subnetzes kommt (auf das angesprochene Interface bezogen), also über die OPNsense, denn das zugreifende Gerät kennt keine andere Route, geht das Antwortpaket jedoch den direkten Weg, also auf dem Interface des zugreifenden Subnetzes raus, weil die Maschine da ja ohnehin eine IP hat. Damit ergibt sich ein asymmetrisches Routing.
Ob die ganzen Interface-IPs wirklich für die Erfüllung der Aufgabe nötig sind, weiß ich nicht.

Eine Möglichkeit wäre, das Gerät nur auf demselben Subnetz anzusprechen.
Ansonsten mit all den IPs in jedem Subnetz, ist die saubere Möglichkeit, asymmetrisches Routing zu vermeiden, eine Outbound NAT Regel dafür anzulegen und die Quell-IP durch die Interface IP der Firewall zu ersetzen. Die Filterung kannst du ja dann auf der OPNsense machen.
Die unschöne Lösung ist, auf allen betroffenen Interfaces eine "Sloppy State" Regel zu erstellen (Floating od. Interface Gruppe), die die Antwortpakete durchlässt, ohne deren Zustand zu prüfen.
Das findest du in der Firewall Regel in den Advanced features > State Type > sloppy state.

[MPGxxxLegend]

Eine Möglichkeit wäre, das Gerät nur auf demselben Subnetz anzusprechen.

Dies war mein Workaround bisher.

Ansonsten mit all den IPs in jedem Subnetz, ist die saubere Möglichkeit, asymmetrisches Routing zu vermeiden, eine Outbound NAT Regel dafür anzulegen und die Quell-IP durch die Interface IP der Firewall zu ersetzen. Die Filterung kannst du ja dann auf der OPNsense machen.

Muss mich hierzu mal weiter einlesen.

Die unschöne Lösung ist, auf allen betroffenen Interfaces eine "Sloppy State" Regel zu erstellen (Floating od. Interface Gruppe), die die Antwortpakete durchlässt, ohne deren Zustand zu prüfen.
Das findest du in der Firewall Regel in den Advanced features > State Type > sloppy state.

Was wäre hier der Nachteil? Hat es Sicherheitsnachteile?
Also die Umsetzung funktioniert, erhalte somit keinen block von OPNSense und die Verbindung bleibt bestehen.

Danke für die Hilfe hierher

[viragomann]

Ansonsten mit all den IPs in jedem Subnetz, ist die saubere Möglichkeit, asymmetrisches Routing zu vermeiden, eine Outbound NAT Regel dafür anzulegen und die Quell-IP durch die Interface IP der Firewall zu ersetzen. Die Filterung kannst du ja dann auf der OPNsense machen.

Muss mich hierzu mal weiter einlesen.

Ist keine große Sache.
Firewall: NAT: Outbound
Den Hybrid Mode aktivieren und eine Regel hinzufügen.
Bei Interface jenes im Subnetz der Ziel-IP auswählen.
Potocol: TCP
Source auf die internen Netze beschränken. (Wie du geschrieben hast, das setzt die Firewall des Zielgerätes außer Kraft. Daher die Quelle möglichst weit einschränken)
Destination: die IP des Zielgeräts
Dest Port: 22, oder was du immer für SSH nutzt
Translation / target: Interface address

Was wäre hier der Nachteil? Hat es Sicherheitsnachteile?

TCP Pakete haben Folgenummern und die Firewall überprüft diese normalerweise auf Plausibilität. Das wird damit ausgesetzt.
Damit wäre es möglich, dass eine Bösewicht ein gefaktes Paket einschleust.

Wenn du die Sloppy State Regel aber auf die Quell-IP des WatchyourLan Containers beschränkt und auf Quell-Port 22 (SSH) sehe ich damit kein nennenswertes Risiko.

[MPGxxxLegend]

TCP Pakete haben Folgenummern und die Firewall überprüft diese normalerweise auf Plausibilität. Das wird damit ausgesetzt.
Damit wäre es möglich, dass eine Bösewicht ein gefaktes Paket einschleust.

Wenn du die Sloppy State Regel aber auf die Quell-IP des WatchyourLan Containers beschränkt und auf Quell-Port 22 (SSH) sehe ich damit kein nennenswertes Risiko.

Hab es per "Sloppy State" Regel umgesetzt, und per Source/Destination IP und Destination Port beschränkt, somit sollte die Angriffsfläche sehr verkleinert werden.
Action: Pass
Interface: User
Direction: In
TCP/IP Version: IPv4
Protocol: TCP/UDP
Source: 10.20.10.2/32
Destination: 10.20.20.16/32
Destination Port: 22 (und 8840 für watchyourlan)
advanced: checked
State Type: sloppy state

als auch im LXC container per ufw den Zugriff definiert/beschränkt.

Danke nochmals.