Messages

The point is that in the route section of the web UI, you can define a route to an existing gateway or to a predefined "Null4" or "Null6" gateway.

The way the route is created seems to be bound by using these specific entries and they use the B (blackhole) flag, you can see this results in "USB" flags for the route.

Since you cannot set the "Reject" flag for a self-defined gateway either, I do not see any way to to this via the web UI. So your are left with either a feature request on Github or by creating a specific pf entry by other means than the web UI.

Ich kann dazu nur sagen, dass ich grundsätzlich nicht mit "Emulationen" wie ATA oder E1000 arbeite, da bei dieser Übersetzungsschicht immer Probleme auftreten können - insbesondere, wenn sich wie hier mit dem Update auch der FreeBSD-Kernelstand ändert, obwohl FreeBSD 15.1 bereits mit 26.7.2 aktiv war. Virtio ist da meist die bessere Wahl, da dies eine für Virtualisierung optimierte Schicht ist.

Bitte entferne erst einmal die Legacy-Emulation aus dem Versuchsaufbau. Der ATA-Fehler ist vermutlich nur Dein emuliertes CD-ROM.

Das vorausgeschickt funktionieren meine so eingerichteten OpnSensen unter PVE jeweils in der aktuellsten Variante einwandfrei.

Siehe dazu insbesondere: https://forum.opnsense.org/index.php?topic=44159.0

[bevor]

Nein. Zwei Geräte im selben IP-Subnetz/VLAN kommunizieren normalerweise direkt auf Layer 2 miteinander. Bei IPv4 wird die MAC-Adresse des Zielsystems per ARP ermittelt, bei IPv6 übernimmt das NDP. Das konfigurierte Default-Gateway spielt dabei keine Rolle.

Der Traffic geht deshalb vollständig an der Firewall vorbei. Sie kann ihn weder filtern noch überhaupt sehen.

Wenn Du den Verkehr zwischen Geräten filtern willst, musst Du sie in unterschiedliche Layer-3-Netze/VLANs legen, so dass der Verkehr tatsächlich geroutet werden muss. Alternativ braucht es entsprechende Layer-2-Mechanismen auf dem Switch.

Das ist Netzwerk-Basiswissen, das Du Dir aneignen solltest, bevor Du mit einem Werkzeug wie OPNsense arbeitest. Das klingt vielleicht herablassend, ist aber bierernst gemeint: Anders als bei Consumer-Produkten wie einer Fritzbox ist es sehr schwierig, sein Netzwerk mit einem komplexen Werkzeug wie OPNsense tatsächlich "irgendwie sicherer" zu machen, wenn die zugrunde liegenden Netzwerkmechanismen nicht verstanden sind.
Darauf weise ich auch hier in Punkt 1 hin.

Das Risiko, dabei etwas grundsätzlich falsch zu konfigurieren und sich nur in Sicherheit zu wiegen, ist ziemlich hoch – wie diese Diskussion ganz gut illustriert.

Before trying anything else, you would have to solve that boot issue.

Did you install on ZFS, because UFS can get corrupted on power outages? That is the reason why ZFS is recommended. That may already be the explanation and the remedy is clear.

Darin, dass es sich dabei um Layer-2-Traffic handelt, den Deine Firewall nicht sieht?

You cannot compare the former Mono price of $600 to today. It was set in early 2025, which where different times in terms of component prices.

The web site does not have a price for the shipping product and YT videos have become spare, the last one was this: https://www.youtube.com/watch?v=7f2BjPPJEWg, stating that the first batch of 1000 machines have been delivered and that Tomaž had a burnout.

I reckon that the price of the real product - if it ever arrives - will be much higher.

Kea sagt damit:

Multi-Threading ist aktiv. Deshalb werden Host-Reservations immer vor dem Lease-Lookup geprüft.

Normalerweise gibt es dafür die Option reservations-lookup-first. Wenn Multi-Threading aus ist, bestimmt diese Option, ob Kea zuerst nach einer statischen Reservation oder zuerst in der Lease-Datenbank sucht. Bei aktiviertem Multi-Threading ignoriert Kea diese Einstellung und erzwingt ersteres. Dadurch soll Locking auf der Lease-Datenbank vermieden werden.

Bei Multi-Threading würde eine etwaige Einstellung "reservations-lookup-first": false einfach ignoriert. Die Warnung ist etwas unglücklich, weil auf OpnSense eben Multi-Threading an ist, die Option wird aber per Default m.W. gar nicht gesetzt.

Ich bin mir nicht sicher, ob Kea "fremdvergebene" Leases bei bloßer Verlängerung anzeigt. Abgesehen davon kann es ja sein, dass Dein Client noch gar nicht wieder gefragt hat, weil die alte Lease noch nicht abgelaufen ist?

Entscheidend ist eigentlich nur, dass Kea läuft und die Option "Firewall rules" aktiv ist, um den Zugriff zu ermöglichen.

Woher glaubst Du zu wissen, dass der Client seine IP nicht vom Kea bekommt? Läuft Kea?

Es kann gut sein, dass Kea von Deinem Client einen Renew-Request für dessen alte IP bekommt, den er eventuell gewährt, obwohl er eine feste Reservierung für eine andere IP hat (oder hatte). So etwas passiert auch gern, wenn der Client zuerst einen Lease bekommt und man den dann in eine feste Reservierung mit einer anderen IP umwandelt - dann muss man erst die alte IP/MAC-Zuordnung aus Kea löschen.

Außerdem kann es so sein, dass "Match client-id" eingeschaltet isr, woraufhin die Reservierungen anhand von Client-IDs und nicht von MACs vorgenommen werden. Dann würde Dein Client eventuell in den Leases auftauchen.

[not]

"drill" without any options explicitly randomizes the nameserver list. For the test you want, you must use "drill -z".

But that probably does not solve your actual issue. When OPNsense itself resolves a name using the servers from resolv.conf, they are normally tried in order, so you already have a kind of fallback there. The same is not guaranteed for DHCP clients to which you hand out a list of DNS servers.

The clients decide for themselves how to deal with a list of DNS servers, and that behavior differs between operating systems. Therefore, handing out AdGuard as DNS1 and Cloudflare as DNS2 does not reliably mean "use AdGuard unless it is unavailable".

If you want a real fallback for your clients, hand out only the address of a local resolver and implement the fallback within that local resolver. For example, OPNsense's Dnsmasq has the option "Query DNS servers sequentially", which queries upstream DNS servers in the configured order.

Unbound with multiple forwarders would not provide strict primary/fallback ordering, as Unbound selects forwarders based on its own server-selection and RTT logic.

Als mSata gibt es einiges von Transcend. Die Suchkriterien (DRAM-Cache und hohe TBW) sind die selben.

Ja, Power Limits runter, wenn Dein BIOS das erlaubt. N1x0 haben nominell eine TDP von 6 Watt, können aber je nach PL auch mal 20 Watt aufnehmen. Leider wollen die BIOS-Hersteller immer die maximale Performance und stellen manchmal das PL auf 25 Watt. Bei 10 Watt verlierst Du nur minimal Leistung, sparst aber Strom.

Was die SSD angeht: die ab Werk verbauten sind in dreierlei Hinsicht mies:

1. Sie haben eine hohe Stromaufnahme.
2. Sie verwenden Billigchips (QLC) und haben damit eine geringe TBW.
3. Sie sind billig und haben meist keinen DRAM-Puffer, was mehr Schreiboperationen zur Folge hat.

Alle drei Parameter wirken auf die Lebensdauer, aber vor allem 2 und drei kann man sogar mit smartctl auslesen. Besonders bitter wird es, wenn man dann noch RRD auf die SSD und nicht im RAM laufen lässt. Billig-NVMEe sind dann oft schon nach einem Jahr hinüber.

Also:

1. RRD ins RAM verlagern (System: Settings: Miscellaneous "/tmp RAM Disk"
2. Nächste NVME mit DRAM-Cache und hohem TBW kaufen. Siehe Geizhals.de. Ich empfehle die Kingston KC3000.
 

https://github.com/meyergru/iscdhcp_to_kea

(wenn da nicht bereits ein CSV-Export für ISC DHCP existieren sollte)

It depends solely on your ISP if your actual IP changes upon reconnect - there is no way to force this from the client side. You should be able to see that the connection is coming down an up again in the logs, though.

In your first linked thread, Patrick even showed the screen shot and explained where to find it.