Welche der Regeln blockiert den Traffic zwischen meine V-Lans?

[2U1C1D3]

Hallo zusammen!

Ich versuche gerade eben von pfsense auf OPNsense umzusteigen und stoße da auf ein für mich nicht erklärbares Problem.
Schnittstellen/Netze:
ix0: LAN - darauf liegen vlan0.2, 0.5 und 0.9
ix1: WAN
opt1: DMZ
opt2: WAN2 (derzeit offline)

Mein Ziel ist es bestimmte Clients aus dem Client-VLan in das IoT-VLan zu lassen. Dies funktioniert aber nicht und ich habe keine Ahnung wo in meinem Regelwerk der Fehler ist...
Womit ich bei der OPNsense gar nicht klar komme ist, dass die automatisch generierten Regeln oben stehen, verschachtelt in einer Kategorie, und sich hier anscheinend nicht an first-hit-wins gehalten wird. Wie auf dem Scrennshot ersichtlich, steht im automatischen Regelwerk gleich mal ganz oben eine deny-all mit dem Vermerk "Letzte Zuordnung". Und sämtliche darauffolgende Regeln, die bei der Abarbeitung eigentlich drüber kommen, stehen drunter. Bei mir gefühlt 15x mit dem Vermerk "Erste Zuordnung".

Kann mir jemand sagen welche Regel meinen Traffic von "desktop -> emlog" blockiert und den Traffic von "Handys -> IoT..."? Den Eintrag "IoT-Adresse" habe ich auf dem Screenshot nur drinnen, da ich mit "IoT Netzwerk" nicht weiter gekommen bin..
Im Screenshot ist auch erkennbar, dass der Desktop auf den Server "ourminecraft" in der DMZ zugreifen können darf/soll. Kann er auch nicht.

Bei meinem Regelwerk, so wie ich es nun verstanden habe, geschieht bei einem Zugriff über die Schnittstelle Client in Richtung V-Lan IoT folgendes:
Zugriff "desktop -> emlog" -> Auflösen von "emlog" in IP
-> Check von oben nach unten:
1. Gehört nicht in die Gruppe "handys" -> weiter
2. Ist nicht der Host "cloud" -> weiter
3. Ist der Host "desktop" - > trifft zu, Regel auflösen
4. Hat als Ziel den Host "emlog" -> trifft zu, Regel auflösen
5. Regel ist "erlaubt" -> lass die Quelle auf das Ziel zugreifen.
Zu der Regel "deny LAN Netzwerk, ADMIN Netzwerk, IOT Netzwerk" kommts gar nicht mehr, da alle Regeln auf "quick" gesetzt sind.
Ebenso dürfte es auch nicht mehr zu einer Prüfung der automatisch generierten Regeln kommen.

Im Übrigen war das so grob (ohne die automatisch generierten Regeln) auch das Regelwerk der pfsense. Hier jedoch hatte ich hinter den Aliasen der Firewall die IP-Adressen versteckt. Hier bei der OPNsense habe ich im Alias den Hostnamen aus dem KeaDHCP. Die Auflösung der Hostnamen funktioniert übrigens bei einer allow all:)

Wo habe ich meinen Denkfehler?

Danke schon mal,
Stefan

[patient0]

Womit ich bei der OPNsense gar nicht klar komme ist, dass die automatisch generierten Regeln oben stehen, verschachtelt in einer Kategorie, und sich hier anscheinend nicht an first-hit-wins gehalten wird.

Bei den Regeln hat es verschiedene Icons, der Blitz steht für fist-match (wenn er gelb ist) oder last-match (ausgegraut).

Die reste Regel 'block all' ist last-match (zieht also nur wenn es keine anderen Regeln danach gibt), die restlichen - mit Ausnahme der letzten beiden - sind first-match. Und eben die beiden letzten sind wieder last-match.

Bei pfSense gibt es diese oder ähnliche Regeln auch, nur siehst Du diese in der GUI nicht, sie sind im /tmp/rules.debug zu finden.

Betreffend dem Zugriff des 'desktop-redacted' auf den 'emlog' bin ich keine grosse Hilfe. Persönlich würde ich mal versuchen bei den Alias die IPs einzutragen anstelle der FQDN und sehen ob das so klappt. Die Regel als solches sieht gut aus, sofern 'desktop-redacted' im Netz ist wo der Screenshot die Regeln zeigt. Gilt auch für die 'handys' auf IOT.

Weiter ist es auf OPNsense nicht empfohlen tagged und untagged VLANs auf einem (trunk) Port zu betreiben (https://docs.opnsense.org/manual/how-tos/vlan_and_lagg.html#id2).

[2U1C1D3]

Hallo patient0,
vielen Dank für die Infos! Ich frage mich warum man das mit dem first- und last-match macht und die Regeln nicht einfach der Reihenfolge nach listed. Aber na gut, dann ist dem so.

Den Vermerk aus deinem Link der Dokumentation kenne ich, verstehe ich aber so, dass eher der Switch ein Problem damit hat und nicht die OPNsense (bis auf die Anzeige des Traffic). Die Separierung der Geräte in die jeweiligen V-Lans funktioniert einwandfrei, incl. DHCP und DNS. Ich benutze als Hardware eine ausrangierte Sophos XG125, hätte also genügend physikalische Ports zur Verfügung. Würde aber mit anderen Worten heißen, wenn ich es 100%-ig machen möchte, ich müsste jedes V-Lan auf einen eigenen Port legen und diese dann am Switch jeweils tagged wieder im System zusammenführen?

Dein Hinweis die IP zu verwenden statt dem FQDN: Werd ich jetzt mal mit ein paar Geräten ausprobieren und dann Feedback geben!

Dankeschön
Stefan

[2U1C1D3]

So, das mit der Änderung von FQDN auf IP hat gar nichts gebracht.
Allerdings habe ich inzwischen festgestellt, dass die OPNsense das MAC-binding beim KeaDHCP nicht sauber umsetzt, was eine Ursache des Problems sein könnte.

Beispiel (geschieht nur bei zwei Clients, einer davon ist der Desktop):
Es ist für die physikalische MAC des Clients "Desktop" die IP 10.10.50.100 vorgegeben. KeaDHCP weist dem Client aber die IP 10.10.50.50 zu (obwohl diese IP gar nicht in der DHCP-Range liegt) und zeigt mir bei den Leases die tatsächliche MAC an, die falsch vergebene IP und den Host "desktop.". Dieser Client und der zweite Client sind die einzigen Beiden, die den"." dahinter bekommen. Ich finde jedoch keine Erklärung zu dem dot...