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.
(https://i.postimg.cc/gw8TRq6V/Screenshot-2026-07-25-171129.png) (https://postimg.cc/gw8TRq6V)
Die Info zu dem Block sieht so aus:
(https://i.postimg.cc/HJXh5472/Screenshot-2026-07-25-171527.png)
(https://i.postimg.cc/nsBP7YQ2/Screenshot-2026-07-25-171617.png)
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:
(https://i.postimg.cc/PLYRZz8M/Screenshot-2026-07-25-171719.png)
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.
Bitte die Bilder hier im Forum anhängen, nicht mit externen Links...
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.):
Hier die nächsten Bilder
Und das letzte Bild
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.
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.
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?
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?
Quote from: AlexanderB on July 27, 2026, 04:21:33 PMIch 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.
Quote from: AlexanderB on July 25, 2026, 07:08:23 PMAn 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.
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
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.
Quote from: AlexanderB on July 30, 2026, 10:14:10 PMDas 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.
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.
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?
Ja ich bin von den alten Regeln auf die neuen Migriert. Ja die Regeln sollten von vor der Migration stammen, aber nicht alle.
Ach, die Migration hat das wohl alles durcheinander gebracht?
Hast du vor dem Update den Migrationsassistenten durchgearbeitet und die alten Regeln gelöscht oder einfach nur das Update eingespielt?
Wenn du zwar den Assistenten benutzt, aber die alten Regeln nicht gelöscht hast, dann tauchen die jetzt genau so read-only im neuen UI auf wie du es gerade siehst.
Wenn du den Assistenten gar nicht benutzt sondern nur das Update gemacht hast, dann sind halt alle Regeln in diesem Zustand.
Installier das os-firewall-legacy Plugin, und hol nach, was du noch nicht gemacht hast. War alles vor dem Update klar und dokumentiert.
Was hat Dich davon abgehalten meine Fragen exakt zu beantworten, hier diese nochmals:
"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?"
Also, ja ich habe den Migrationsassistenten durchgearbeitet. Aber ich schätze da hat was nicht funktioniert, denn bei der Hälfte war alles weg und auch die Beschreibung. Da dachte ich, huch, das ging aber schnell, ich war noch gar nicht fertig mit lesen.
Jetzt mit dem os-firewall-legacy, führt mich der Migrations Assistent zu einem schwarzen Bildschirm. Schick. Naja, dann geh ich mal auf die Suche was ich noch alles da machen muss. oh mei oh mei.
@patient0
Sorry. Nein nein, das sind zwei unterschiedliche Schnittstellen/VLANs. Eine funktioniert, die andere nicht. Fehler ist höchstwahrscheinlich wegen dem Migrationsassitenten passiert, da einfach die automatischen Regeln fehlen. DNSmasq DNS & DHCP nutze ich und die neuste Version von OPNsense und ja der Haken ist dort gesetzt, dass der DHCP automatisch Firewallregeln zu der entsprechenden Schnittstelle erstellen soll (Was aber nicht funktioniert, so wie ich festgestellt habe).
Quote from: AlexanderB on July 31, 2026, 09:35:49 AMAlso, ja ich habe den Migrationsassistenten durchgearbeitet. Aber ich schätze da hat was nicht funktioniert, denn bei der Hälfte war alles weg und auch die Beschreibung. Da dachte ich, huch, das ging aber schnell, ich war noch gar nicht fertig mit lesen.
Du musst aus dem Assistenten die Regeln als CSV exportieren und dann in "Rules [new]" (26.1) oder jetzt "Rules" (26.7) explizit importieren über das kleine Upload-Symbol rechts unten. Das steht alles beim Migrationsassistenten direkt am Schirm.
Danach musst du die Regeln manuell aus dem "alten" UI löschen.
Automatische Regeln werden vom Migrationsassistenten nicht angefasst, daran liegen deine Probleme nicht.
Du scheinst aber als erstes mal den Assistenten überhaupt nicht komplett und nach Doku durchgeführt zu haben.
- Assistenten aufrufen
- Regeln überprüfen
- Regeln als CSV exportieren und lokal auf deinem Rechner speichern
- Regeln im neuen UI importieren
- Regeln im alten UI löschen
Das steht wie gesagt alles klipp und klar auf der Seite vom Migrationsassistenten.
Wie wärs mit:
- Neuinstallation mit 26.1
- Backup der Config von vor dem mißglückten Update einspielen
- Migrationsassisten diesmal richtig durchspielen
- Update
?
Es gibt nichts zu exportieren, nur "Regeln aus der Automatisierung" und "automatisch generierte Regeln". Der Migrationsassitent ist auch einfach ein schwarzer Bildschirm.
Es sind gar keine Regeln mehr vorhanden, die ich exportieren könnte. Vor der Migration gab es keine "Regeln aus der Automatisierung".
Ja ich sehe, bei mir ist wieder alles schief gegangen und nun ist die Kiste so verbuggt.
komplett neu aufsetzen, na prima. Und wenn ich dann meine Konfiguration von jetzt mitnehme, dann nehme ich hoffentlich nicht die ganzen Bugs mit.
Ich weiß nicht warum du dir so sicher bist, dass dieses Problem, dass die Clients auf der 2ten Schnittstelle keine IP bekommen, nicht an den automatischen Regeln liegt. Obwohl die Schnittstelle wo alles funktioniert, die automatischen Regeln vom "DNSmasq DNS & DHCP", wie auf dem Bild gezeigt, drin hat, und die 2te Schnittstelle, die exakt gleich mit "DNSmasq DNS & DHCP" konfiguriert ist, eben diese Regeln für den Zugang zum DHCP NICHT drin hat.
Im Grunde würde ein Neuaufsetzen genau dieses Problem nicht lösen.
Das ist echt ne mittelschwere Katastrophe. Na mal schauen wie ich da wieder raus komme.
Dann erstmal Danke an alle die hier mir geholfen haben :)
Ich merke auch gerade, die Hälfte meiner Schnittstellen hat die automatischen Regeln des DHCP und die andere Hälfte nicht.
Ich bräuchte doch im Grunde nur die Möglichkeit, dass "DNSmasq DNS & DHCP" alle Regeln einmal neu erstellt. Und falls es schon so eine Regel auf der Schnittstelle gibt, soll "DNSmasq DNS & DHCP" diese Regeln nicht erzeugen, sodass keine Duplikate entstehen.
Aber die Frage die sich mir dann stellt ist, wie viele versteckte Bugs mich mit OPNsense in Zukunft noch quälen werden und ob ich alle Konfigurationsänderungen handschriftlich mir notieren muss, falls ich mal ein 1 Jahr altes Backup einspielen muss.
Es gibt keine "versteckten Bugs", die an deiner Situation schuld sind. Du hast die Konfiguration vergurkt.
Hast du den DHCP-Server auf den Schnittstellen, auf denen keine Regeln liegen, auch eingeschaltet?
Gut das man Fehler der Technik immer auf die DAUs schieben kann. Sehe ich komplett anders. Wenn der Programmierer es dem DAU ermöglicht, etwas zu konfigurieren, was nicht im Scope liegt, dann liegt das Problem an schlechter Programmierung. So habe ich es jedenfalls gelernt.
Also ich hab Testweise mit "DNSmasq DNS & DHCP" rumgespielt.
Alle Schnittstellen entfernt und das Häkchen bei "DHCP-Firewall-Regeln registrieren" entfernt.
Siehe da, "DNSmasq DNS & DHCP" hat die automatischen Regeln in der Firewall entfernt.
Jetzt hab ich wieder alle Schnittstellen aktiviert und das Häkchen bei "DHCP-Firewall-Regeln registrieren" wieder gesetzt.
Siehe da, "DNSmasq DNS & DHCP" hat wieder automatische Regeln in der Firewall hinzugefügt.
Was mich jetzt aber wundert ist, dass "DNSmasq DNS & DHCP" wieder nur bei der Hälfte der Schnittstellen in der Firewall die automatischen Regeln hinzugefügt hat und bei der anderen Hälfte nicht.
Wie meinst du eingeschaltet? Also unter "DNSmasq DNS & DHCP" in den Einstellungen die Häkchen auf den Schnittstellen, ja.
Quote from: AlexanderB on July 31, 2026, 10:30:42 AMWie meinst du eingeschaltet? Also unter "DNSmasq DNS & DHCP" in den Einstellungen die Häkchen auf den Schnittstellen, ja.
Ja, das meinte ich. Und du hast auch Bereiche/Netze definiert für diese Schnittstellen/VLANs? Vielleicht braucht DNSmasq ja beides. Ich benutze selbst Kea.
Ich würde aber wirklich erst mal das Legacy-Plugin installieren und die Firewall-Regeln aufräumen bzw. die Migration nochmal richtig machen. Evtl. stolpert der DNSmasq ja darüber. So wie Du es im Moment hast, kann es ja offensichtlich nicht bleiben.
Ich hab das os-firwall-legacy plugin wieder deinstalliert, weil nichts zum export vorhanden ist und der Migrationsassistent nur ein schwarzer Bildschirm ist.
Ja die Schnittstellen haben ihren DHCP Bereich.
Soweit ich gelesen habe ist "DNSmasq DNS & DHCP" das Leichtgewicht und der Rest für sehr viele Clients.
Ich habe aber keine tausende Teilnehmer, daher benötige ich nichts großes.
Ich weiß ehrlich gesagt nicht genau was ich jetzt mache. Das nervt mich übelst, denn ohne DHCP auf der Schnittstelle komme ich mit meinen anderen Aufgaben auch nicht weiter.
Ich weiß jetzt jedenfalls, dass das Teil "DNSmasq DNS & DHCP" eine Macke hat und da muss ich mir was überlegen.
Danke
Geh zurück auf 26.1 (Snapshot vorhanden oder wenigstens Backup?) und mach die Migration nochmal. Die nicht editierbaren Regeln gehören so nicht.
So, jetzt hab ich die Kiste auf Werkseinstellungen zurückgesetzt und meine Konfiguration eingespielt.
Leider immer noch der Bug drin.
Kann ich also auch die Sicherungen der Konfigurationen wegschmeißen.
Toll, lol
Es scheint mir so, als wenn man wirklich viel Hand anlegen muss bei OPNsense.
Die Backup-Strategie muss dann also jede kleinste Konfigurationsänderung plotten, denn bei Bedarf muss man wer weiß wie weit zurück und dann muss man natürlich wieder alle Änderungen durchführen die durch den Rollback verloren gegangen sind.
Nicht zu unterschätzen das Risiko, dass es nach dem Rollback und der erneuten Konfiguration trotzdem nicht funktioniert.
Ein simpler DHCPv4, nicht produktionsreif. Traurig
Was ich jetzt schreibe, klingt vielleicht überheblich oder wie ein persönlicher Angriff, ist aber ganz sachlich gemeint:
Ich empfehle eine Fritzbox (https://forum.opnsense.org/index.php?topic=39556.0), wenn Dich die Komplexität der OpnSense überfordert.
Es ist schlicht unmöglich, ein Werkzeug wie OpnSense mit derart vielen Freiheitsgraden auszustatten und gleichzeitig einem "Laien"-Anspruch zu genügen, dass das auch alles ganz einfach und quasi "idiotensicher" gemacht wird. Ich schrieb hier schon mehrfach, dass Leute, die ein Youtube-Video ansehen und sich dann denken: "Ich mache mein Heimnetzwerk jetzt irgendwie sicherer!" zumeist in einem Irrtum behaftet sind. Deswegen sind meine Artikel nicht nur Hilfestellung, sondern - wenn man sie richtig versteht - gleichzeitig auch Warnung, worauf man sich einlässt, z.B.: https://forum.opnsense.org/index.php?topic=42985.0
Einem Gegenargument sei vorweg begegnet: eine vorgeschaltete KI wäre auch keine Lösung für dieses Dilemma, dazu führe ich im Proxmox-Forum (Komplexität ähnlich hoch) gerade eine Diskussion.
Hi meyergru,
ja kein Ding, verstehe schon was du meinst und ich bin mir diesbezüglich vollständig im Klaren.
Wie ich auch schon Herrn Hausen erklären musste wie SW-Entwicklung geht, kann ich dir hier auch versichern, dass es nicht die Komplexität der OPNsense ist, die mich überfordert. Das aktuelle Problem ist einfach schlechte Programmierung. Und das ist das was mich überfordert, weil ich neben den vielen anderen Projekten, sicher nicht noch hier einsteige und den Leute erkläre wie man es richtig macht.
Ach hör mir mit KI auf, das ist das letzte was die Menschheit gerade noch gebraucht hat.
Ich setze jetzt einfach alles neu auf und muss eben bei OPNsense doch mit so einigen kleinen Softwarefehlern rechnen. Thats life.
P.S. Schön auf jeden Fall, dass der Bug im Installer der neusten Version bezüglich UFS behoben ist. Das ist doch schon ein Lichtblick :)
Schade, selbst mit der neuen Version und meiner Konfiguration ist der Bug nicht behoben.
Das heißt, kein sequenzielles Update, sondern ein statisches.
Klasse, nun darf ich dann doch meine gesamte Konfiguration komplett neu per Hand aufsetzen. Oder ich bearbeite das Backup, aber auf ein korrektes Einspielen der Konfiguration ist ja leider kein Verlass, somit ist das eher die schlechtere Idee.