Messages

Dann hast Du aber sowieso ein Problem in Deiner Topologie, weil Dein PC offenbar gar nicht über das LAN, wie Du schriebst, sondern über das WAN reinkommt. Das hört sich nämlich danach an, dass der PC im "Transfernetz" zwischen der Fritzbox und der OpnSense sitzt - eventuell solltest Du zu dem Thema mal dies lesen:

https://forum.opnsense.org/index.php?topic=39556

Any specific reason not to leave handling of the physical NIC to PVE via virtio, as described here?

That would also take the igc/iflib driver path inside OPNsense out of the equation.

Also virtio an einer Bridge, was Treiberprobleme weitgehend ausschließt. Wie ich ja schon schrieb: dass "pfctl -d" es zum Fliegen bringt, legt nahe, dass es ein Firewallproblem ist.

Dann würde ich in den Einstellungen das Logging für die Default-Block-Regeln einschalten und mir bei eingeschalteter Firewall im Live Log ansehen, welche Pakete geblockt werden. Dann musst Du feststellen, wieso. Offenbar ziehen dann ja Regeln nicht, die die per Default geblockten Pakete durchlassen sollten. Diese Regeln musst Du finden und schauen, weshalb sie nicht (mehr) greifen.

Da Du mit eingeschalteter Firewall keinen Zugriff mehr auf die OpnSense haben dürftest, musst Du das Vorgehen wahrscheinlich anpassen:

Zuerst ganz vorne eine Allow-All-Regel für Deine Workstation anlegen, von der aus Du die Analyse durchführst. Und dann die Zugriffe von einem anderen PC aus versuchen und ins Live Log sehen.

[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.