Warum wird ein Client geblockt, aber der andere nicht (Sonst alles identisch)

[AlexanderB]

Warum wird ein Client bei der Adressvergabe geblockt, während ein anderer eine Adresse bekommt?
Beide liegen im gleichen VLAN20 an der gleichen Schnittstelle.
Die erste Shell ist das aktuelle debian 13 als LXC template.
Die zweite Shell ist ein über die helper scripte installierte Wordpress, auch mit debian 13 als Unterbau.

Ich checke nicht, warum der eine Client, eine IP erhält aber der andere nicht.


Die Info zu dem Block sieht so aus:


Der Client wird ja sowohl für IPv6 als auch für IPv4 geblockt:

Es ist die allererste Regel der globalen Regeln, die die IPv4 DHCP Anfrage blockt:


Für den IPv6 Block gibts keine rid.

Was soll denn da schon wieder verkehrt sein? Vielleicht kann mir da jemand helfen.

Ich muss sagen, nachdem man gewisse Wissensfortschritte gemacht hat, scheint es noch Dinge zu geben, die einfach unerklärlich sind, bzw. eventuell dem Client und dessen korrekte/inkorrekte Netzwerk-Nachricht zu zuschreiben sind.

[meyergru]

Bitte die Bilder hier im Forum anhängen, nicht mit externen Links...

[AlexanderB]

Das ging leider nicht, da ich über 40000 Zeichen gekommen wäre.
Dann hab ich eine Info hier im Forum gesucht, wie man Bilder korrekt einbindet und da wurde ich auf eben dieses postimg hingewiesen, was verwendet werden soll.

Ich probiers hier nochmal (250 kB darf man hier max.):

[AlexanderB]

Hier die nächsten Bilder

[AlexanderB]

Und das letzte Bild

[viragomann]

Hallo,

das ist eine "last match" Regel. Die kommt nur zur Anwendung, wenn keine weitere Regel zutrifft.

Wenn du DHCP auf dem Interface aktiviert hast, sollte noch eine "first match" Regel folgen, die diese Pakete erlaubt. Hast du?

Das geblockte IPv6 ist ICMP. Dafür wird keine automatische Regel generiert. Eine Regel, die das erlaubt, müsstest du also selbst anlegen.

[AlexanderB]

An den globalen Regeln hab ich nie etwas verstellt.
Meine eigenen Interface Regeln sehen so aus (Ich hab die mittlere Regel eingefügt, um den Verkehr überall hin zu erlauben, während der Fehlersuche):

Mir ist das noch völlig unbegreiflich, dass das so schlecht funktioniert.
Aber ich hatte letztens auch festgestellt, dass sich ein debian-13 bei mir auch keine IPv6 geholt hat. Da musste ich erst mit "dhclient -6 -v" nachhelfen.

Dass ich da mit "dhclient -6 -v" nachhelfen musste, muss mir auch jemand mal erklären. Ich erwarte von Linux nicht solche Fehler. Die nächste Frage wäre, was ist das stabilste, fehlerfreieste Linux, oder Betriebsssytem um zu "Networken", also Netzwerke zu debuggen? Das hat mich schon genervt.

[AlexanderB]

Ich habe hier leider immer noch keine Lösung gefunden, was mich ziemlich nervt, da ich das System ja auch verwenden will.
Hat denn keiner eine Idee?

Warum greift die erste globale Regel im last match Verfahren? Wieso blockt diese mir jeglichen Verkehr, obwohl ich bereits zum testen eine Regel erstellt habe, die sämtlichen Verkehr freigibt?

[patient0]

Zeig doch mal den Logeintrag für den Client der erfolgreich eine IPv4 bekommt im gleichen VLAN, scheint für mich grad unwahrscheinlich.

Welche OPNsense Version setzt Du ein? Welchen DHCP Server setzt Du ein, DNSmasq oder KEA DHCP? Und ist bei dem DHCP Server 'Firewall rules' (KEA) oder 'DHCP register firewall rules' (DNSmasq) gesetzt?

[viragomann]

Ich habe hier leider immer noch keine Lösung gefunden, was mich ziemlich nervt, da ich das System ja auch verwenden will.
Hat denn keiner eine Idee?

Vielleicht kommen wir in dem Fall weiter, wenn du unsere Fragen beantwortest.

An den globalen Regeln hab ich nie etwas verstellt.

Das war jedenfalls keine passende Antwort.

Hast du nun einen DHCP Service auf dem Interface aktiviert?
Wenn ja, ist die entsprechende automatisch generierte Regel vorhanden?
UDP any:68 > 255.255.255.255:67

Du hast uns bislang lediglich eine Regel gezeigt. Und hat niedrigste Priorität. Kommt also nur zur Anwendung, wenn keine andere Regel eher zutrifft. Das ist etwas wenig, um sich ein Bild machen zu können und dem Problem auf den Grund zu gehen.

[AlexanderB]

Also auf der Schnittstelle kann ich folgendes mitschneiden (Paketauzeichnung):
Mein Client sendet die Anfrage an den DHCP:



VLAN50_User
vlan0.1.50   2026-07-30
21:57:30.327945   08:8b:c8:6f:a1:0c   33:33:00:00:00:02   ethertype IPv6 (0x86dd), length 70: (hlim 255, next-header ICMPv6 (58), payload length 16) fe80::100d:9554:1e9c:70ba > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
     source link-address option (1), length 8 (1): 08:8b:c8:6f:a1:0c
       0x0000:  088b c86f a10c
VLAN50_User
vlan0.1.50   2026-07-30
21:57:31.981143   08:8b:c8:6f:a1:0c   ff:ff:ff:ff:ff:ff   ethertype IPv4 (0x0800), length 340: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 326)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 08:8b:c8:6f:a1:0c, length 298, xid 0xb8fafac5, secs 14, Flags [none] (0x0000)
     Client-Ethernet-Address 08:8b:c8:6f:a1:0c
     Vendor-rfc1048 Extensions
       Magic Cookie 0x63825363
       DHCP-Message (53), length 1: Discover
       Client-ID (61), length 7: ether 08:8b:c8:6f:a1:0c
       MSZ (57), length 2: 1500
       Vendor-Class (60), length 15: "android-dhcp-17"
       Hostname (12), length 7: "Pixel-9"
       Parameter-Request (55), length 12:
         Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
         MTU (26), BR (28), Lease-Time (51), RN (58)
         RB (59), Vendor-Option (43), URL (114), Unknown (108)



Aber auf der Firewall, wenn ich mir die LIVE-Ansicht ansehe, dann kommt überhaupt nichts rein. Nix, nada.


Ja jetzt check ich es. Diese neue Firewall-Regelübersicht macht einen echt kirre.
Wieso hab ich auf der einen Schnittstelle nur halb so viele automatische Regeln, als auf der anderen, obwohl der Rest komplett gleich eingestellt ist?

Das bedeutet OPNsense ist so heftig verbuggt, dass es die automatisch erstellen Regeln völlig durcheinander haut?
Muss ich da jetzt überall alle Regeln durchgehen und prüfen ob das korrekt ist oder nicht?
OMG, was ist das denn, kriege ich gleich eine Krise

[AlexanderB]

Wenn ich bei den Regeln, die ich auf der Schnittstelle sind, die korrekt ist, kopieren will, geht das nicht, weil kein Button da.
Da ist nur "Lookup Rule Reference" und die führt mich zu dnsmasp & DHCP, wo ich BEIDE Schnittstellen gleichermaßen, komplett exakt konfiguriert habe.

[Patrick M. Hausen]

Das bedeutet OPNsense ist so heftig verbuggt, dass es die automatisch erstellen Regeln völlig durcheinander haut?

Nein, natürlich nicht. Da draußen sind tausende von OPNsense-Firewalls im Livebetrieb, viele davon in Enterprise-Umgebungen. Bitte geh davon aus, dass nur du das Problem hast und das es spezifisch auf deiner Konfiguration beruht. Das ist bei jedem Problem die sinnvolle erste Annahme.

Ich alleine betreue rund ein Dutzend Systeme.

Mach doch die Paketaufzeichnung mal auf der Firewall statt auf dem Client. tcpdump auf der Shell oder über das UI.

Wenn auf der Firewall tatsächlich keine DHCP-Anfrage reinkommt, auch nicht in einem Packet-Trace, dann liegt die Ursache außerhalb der Firewall - Client oder Switch. Ziemlich einfach, erst mal.

Was meinst du mit "neue Regelübersicht"? Hast du mit 26.1 oder noch früher angefangen und dann auf 26.7 aktualisiert? Wenn ja, hast du denn beim Stand 26.1 die Regeln auch migriert mit dem Migrationsassistenten?

Eine mit dem alten System erstellte Regel, die du dir nun im neuen UI anguckst, würde erklären, weshalb da kein "Clone" Button ist. Editieren von "alten" Regeln geht im neuen UI nicht aus gutem Grund. Man muss einmal durch den Migrationsassistenten.

HTH,
Patrick

P.S. Die Live-Ansicht in der Firewall berücksichtig natürlich nur Regeln, für die auch Logging aktiviert ist. Das ist kein Packet-Trace. Den findest du unter Interfaces > Diagnostics > Packet capture.

[AlexanderB]

Jupp, dann muss ich aber echt noch ranklotzen, was ich da nicht verstanden habe.
Wer erstellt denn diese Firewall-Regeln, wie auf den Bild gezeigt? Diese sind nämlich auf der Schnittstelle IOT vollkommen richtig.
Aber eben auch genau diese fehlen auf der Schnittstelle User.

[Patrick M. Hausen]

Du definierst die Regeln, natürlich.

Aber Du hast schon wieder keine der Fragen beantwortet.

Stammen deine Regeln von einer Version vor 26.7, beispielsweise 26.1?
Hast du den Migrationsassistenten durchgeführt?
Hast du, falls die Regeln von einer älteren Installation stammen, das os-firewall-legacy plugin installiert?