Komisches Verhalten bei neuen Firewall-Regeln - scheinen nichtmehr zu greifen

[thej0nix]

Hallo zusammen,

ich stehe vor einem merkwürdigenProblem mit meiner OPNsense-Firewall und hoffe, dass jemand von euch einen Rat hat. Hier mein Setup und das Problem im Detail:

Setup:

Code: [Select]

Interfaces:

WAN: Internetverbindung
LAN: Lokales Netzwerk
Proxmox: Netzwerk für meinen Proxmox-Server
AP: Netzwerk für den Access Point mit den VLANs (AP, Guest, IoT)

Zugehörige Geräte:

NGINX Proxy Manager: IP 10.10.0.2 (im Proxmox-Netzwerk)
Home Assistant: IP 10.10.0.4 (ebenfalls im Proxmox-Netzwerk)
Firewall-Regeln:

Code: [Select]

Interface: PROXMOX
Direction: IN
Protocol: TCP
TCP/IP-Version: IPv4/IPv6
Source: nginx-proxy-manager (Alias)
Destination: homeassistant (Alias)
Port: 8123
Ich habe auch einige Gruppen angelegt (z.B. LOCAL, TRUSTED), damit ich einfacher NAT Regeln für verschiedene Interfaces bauen kann.
Zudem ist anzumerken das ich ein ipv4 & ipv6 Setup habe inklusive Tayga.


Das Problem:

Der NGINX Proxy Manager (IP 10.10.0.2) kann nicht auf den Home Assistant (IP 10.10.0.4) zugreifen, obwohl ich eine entsprechende Firewall-Regel eingerichtet habe. Die Regel sollte den Zugriff erlauben, aber ich sehe immer wieder, dass die Verbindung auf die "Default deny / state violation rule" fällt.

Was ich bisher festgestellt habe:

- Das Problem ist scheinbar aber auch bei anderen neuen Regeln, die wollten nach dem Anlegen auch nicht so richtig funktionieren. Aber bei den konnte ich es noch nicht zu 100% validieren.
- Die Regel war vor etwa einem halben Jahr funktionsfähig und hat ohne Probleme gearbeitet.
- Das Problem trat möglicherweise nach mehreren Systemupdates auf.
- Ich kann Home Assistant nur über OpenVPN oder die direkte IP-Adresse erreichen.


Im Firewall Live Log erscheint ein Block Record mit folgendem Eintrag:

Code: [Select]

__timestamp__ 2024-09-03T02:38:45
ack 1632969807
action [block]
anchorname
datalen 0
dir [in]
dst 10.10.0.2
dstport 49172
ecn
id 0
interface vtnet0
interface_name PROXMOX
ipflags DF
ipversion 4
label Default deny / state violation rule
length 60
offset 0
protoname tcp
protonum 6
reason match
rid 02f4bab031b57d1e30553ce08e0ec131
rulenr 29
seq 82592289
src 10.10.0.4
srcport 8123
subrulenr
tcpflags SA
tcpopts
tos 0x0
ttl 64
urp 65160
Meine Vermutungen:

Möglicherweise hat ein Systemupdate die Funktionsweise der Firewall-Regeln beeinflusst.
Eventuell greifen die Regeln nicht korrekt wegen einer Überschneidung oder einem Konfigurationsfehler.
Es könnte ein Problem mit den Stateful-Regeln und IPv6 sein, da ich ein Dual-Stack-Setup habe.

Fragen:
Hat jemand ähnliche Erfahrungen gemacht oder kennt bekannte Probleme, die durch Updates verursacht werden könnten?
Gibt es eine Möglichkeit, die Regeln gezielt zu debuggen, um zu sehen, warum sie nicht wie erwartet greifen?
Ich freue mich über jede Hilfe und jeden Hinweis, den ihr geben könnt!

Vielen Dank im Voraus!

Grüße, Jonas.

[chemlud]

Clients im selben Subnetz können nicht über FW-Regeln reguliert werden. Der Traffic geht nicht durch die Sense, sondern über den Switch direkt zum Ziel.

[thej0nix]

Ah verstehe, allerdings ist das Subnetz komplett Virtuell auf Proxmox. Was ist dann aber der Grund weshalb das Request trotzdem geblockt wird, bzw. im FW Log aufschlägt? Was müsste ich unternehmen, damit der Traffic wieder funktioniert?
CT VMs selbst haben keine Firewall und in Proxmox ist diese auch deaktiviert.

[chemlud]

...über den Switch direkt zum Ziel.

 

[thej0nix]

Die Antwort ist nicht hilfreich und auch nicht fachkundig, wie die Firewall sich im gleichen Interface verhält ist eine Einstellungssache: "Static route filtering" - Bypass firewall rules for traffic on the same interface.
Leider ist es egal ob der Harken gesetzt ist oder nicht, es wird weiterhin von der Default Rule geblockt.

Hat jemand sonst noch eine Idee woran es liegen könnte?

[meyergru]

Du scheinst nicht zu verstehen, wie Netzwerke funktionieren. Was chemlud Dir - durchaus "fachkundig" - mitzuteilen versucht, ist, dass Pakete, die sich im selben Subnetz befinden, direkt über den Switch gehen - an Deiner OpnSense vorbei.

Da die beiden beteiligten Geräte in der selben Broadcast Domain liegen, verständigen sich per ARP darüber welche MAC welcher IP zugeordnet ist und reden einfach direkt miteinander.

Das geblockte Paket, dass Du gesehen hast, ist vermutlich ein Artefakt der ARP Broadcasts und wird auf der OpnSense zwar geblockt, erreicht aber trotzdem sein Ziel. Die OpnSense kann nur Traffic regulieren, der sie auch passiert, nicht "berührt".

Zurück ans Zeichenbrett, ein bisschen IP lernen und dann von vorne beginnen.


P.S.: Die von Dir genannte Einstellung ist ziemlich exotisch und ist per Default eben gerade nicht gesetzt, weil sie in den meisten Fällen nicht zum Tragen kommt - aus den genannten Gründen. In keinem Fall kann sie ein Abweichen vom genannten Verhalten der beiden Clients bewirken - die reden nun mal direkt miteinander.

[chemlud]

Grundregel: Willst du den traffic zwischen zwei clients mit FW-Regeln steuern, gehören sie an unterschiedliche Interfaces (den VLAN-Kram lassen wir mal weg, für den Anfang). :-)