Messages

[welche?]

Ohne Details der Topologie und ggf. eingesetzter Hardware ist dazu keine belastbare Aussage möglich. AKA: Zu wenig Information!

Wenn ich raten sollte, könnte es beispielsweise folgendes sein:

Du hast die OPNsense nicht wie empfohlen mit virtio, sondern mit Pass-Trough (1) und außerdem obendrein mit nicht empfohlener Realtek-Hardware unter Proxmox am laufen (2). Mit neueren OPNsense-Versionen gibt es bekannte Probleme mit den Realtek-Treibern, gerade wenn die früher notfalls empfohlenen Hersteller-Treiber (os-realtek-re) eingesetzt werden (3).

Außerdem: https://forum.opnsense.org/index.php?topic=42985.0, Punkt 16.

Andererseits spricht die Tatsache, dass pfctl -d, also das Abschalten der Firewall, das Problem löst, eher dafür, dass Du beispielsweise bei einem größeren Sprung von der alten Version (welche?) die neuen Firewall-Regeln subtile Änderungen zur Folge haben. Dann führt nichts daran vorbei, Deine Regeln zu zeigen oder noch besser, das Logging einzuschalten und dann festzustellen, welche Regel jetzt blockiert bzw. welche Pass-Regel jetzt nicht mehr trifft.


(1) Siehe https://forum.opnsense.org/index.php?topic=44159.0
(2) Siehe https://forum.opnsense.org/index.php?topic=42985.0, Punkt 6
(3) Siehe z.B.: https://forum.opnsense.org/index.php?topic=53004


 

I suppose you could ask @Monviech (Cedrik) about that - AFAIK he writes most of the documentation.

It is approximately every 24h, with the expression "if (time.time() - fstat.st_mtime) < (86400 - 90)" refering to the timestamp of the last update (see geoip.py).

But why does that bother you, when you can even update the alias on the spot via Firewall: Aliases -> Actions -> Update GeoIP?

Nur kurz gelesen, klingt nach Standardproblemen:

1. Ist das Kabel-Modem wirklich ein Modem oder ein Router mit 192.168.0.x als Transfernetz dahinter? Hint: Reply-To und "Wann ist ein WAN ein WAN"?
2. Erfolgt der Zugriff auf den Port von hinter der OpnSense aus und auf die externe IP via DNS? Ist das die vermeintliche oder die richtige WAN-IP? Ist NAT Reflection an?

Je nach Antwort auf diese Fragen ist Bobs Frage eventuell sehr naheliegend. Ich empfehle ggf: https://forum.opnsense.org/index.php?topic=42985.0

You could try to hide the "physical" link-state changes from OPNsense by assigning LAN to a bridge interface, with hn1 as a bridge member and an additional virtual interface that stays permanently up.

A bridge containing only hn1 probably won't help, as the bridge itself will go down when its last active member goes down.

A LAGG might be another option, although the same caveat probably applies if it only has a single active member.

You may need to create the "dummy" interface on Hyper-V, though, as I do not see any valid interface type on OpnSense (modulo epair, which you cannot create with the web UI).

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.