Messages

Ich lege unter Firewall: Groups eine Interface Gruppe an, die alle lokalen VLAN-Interfaces enthält und nenne sie LOCAL. Die verwende ich dann als Interface in "Firewall: Rules: Floating". Wenn ich später weitere VLANs anlege, muss ich die nur der Gruppe hinzufügen und nicht jeder einzelnen Regel.

Es gibt eine "Abarbeitungsreihenfolge" der Regeln, siehe: https://docs.opnsense.org/manual/firewall.html#processing-order

Die greift noch vor der Reihenfolge innerhalb der dort dargestellten Regeltypen. Somit würde eine "Allow" quick-Regel in den Floating Regeln immer vor jeder eventuellen "Block"-Regel im Interface ziehen, mithin kannst Du in den Interface-Regeln nichts mehr verbieten, was in den Floating-Regeln erlaubt wird. Die Floating-Regel feuert und dann ist der Rest egal. Deswegen beschränke ich Floating-Regeln meist auf eine Interface-Gruppe "LOCAL".

Dazu auf dem WG interface ein Block, sodass, auch wenn auf der einen seite eine falsche flaoting regel vorhanden wäre, es nicht auf der remote Seite, das wg interface passieren würde!

Kritisch wäre, wenn auf "Deiner" Seite eine Floating-Regel etwas erlaubt, weil die vor den Interface-Regeln greifen. Wie gesagt, um das zu verhindern, nutze ich immer eine Interface-Gruppe für die "Nicht-WG" Interfaces (=VLANs) und nutze die in den Floating Regeln.

Ansonsten immer am lokalen Ende des WG-Tunnels filtern, der "andere" kann ja erlauben, was er will.

ICMP is a low-priority service that is not guaranteed to work. Some gateways do not reliably answer to those requests, especially when they are under high load.

Na klar. Du musst bei site-2-site das Wireguard-Interface praktisch genau so behandeln wie ein WAN. Wenn der Tunnel steht, bestimmst Du, was drüber hereinkommt.

Ich mache das immer explizit, indem ich in den WG-Interface-Regeln am Ende ein block auf Ziel any mache und ggf. davor spezifische Regeln. Du musst aber bedenken, dass Floating Rules eventuell früher ziehen als Interface-Regeln. Deswegen muss man dort genau darauf achten, für welche Quell-Interfaces diese Regeln gelten. Ich habe dafür zwei Typen: 1. "alle" - das sind dann beispielsweise DNS und NTP auf der Firewall und 2. Gruppe "lokal", das sind meine eigenen VLANs, die die WG-Interfaces nicht einschließen. Darin wäre dann z.B. Zugriff auf einen Log- oder Mailserver.

I already wondered how this was possible - for me, DoT works as expected as verified by a tcpdump. So it is only the column in the grid that display the wrong value, mainly a cosmetic problem.

Forget those TDP numbers.

First off, for the Intel N series, these are most often "TDP down" values which no manufacturer uses for sake of higher performance ratings. Even the N100 is often configured at 25 Watts TDP and for some BIOSes, you need special tricks to bring these down, which you will need when you have a passively cooled system.

Second, with normal load on the system, the numbers are often lower - take the Minisforum. 100W TDP is only for the CPU, but at max load. In reality, the CPU will likely use 8-10 Watts and the rest of the system ~15W, so the real power draw will likely be more like 35 Watts.

An N1x0 will be more like 20-25 Watts, the N355 (estimated) ~30-35 Watts.

Many IoT devices only support SLAAC, if they support IPv6 at all.

Other than that, you have to select the correct RA mode to instruct devices to use DHCPv6 for all interfaces where you want it.

To me, it does not make much sense to use DHCPv6, even if you want to identify devices, because with IPv6 privacy extensions and randomized MACs these days, you cannot effectively do that anyway. Therefore, I prefer to use SLAAC only: https://forum.opnsense.org/index.php?topic=45822.0

Nein, Du brauchst zusätzlich für die Regeln, um den Wireguard-Port zu erreichen auch noch Regeln für den Traffic, der den Tunnel verlässt.

Das ist Schritt 5 hier: https://docs.opnsense.org/manual/how-tos/wireguard-client.html

Saw that only after it started advertising... damn AI slop.

I've looked and couldn't find any microcode updates AMD only deliver these for this CPU via bios updates and the bios update for this model is only delivered by HP.

That is only partially correct. AMD may deliver what they want. The updates contained in BIOSes are being extracted and put into separate packages, such as os-cpu-microcode-amd for OpnSense, to be applied apart from BIOS updates. BTW: There are similar packages for Linux / Proxmox as well using the same extracted firmwares.

I repeatedly tried to tell you. Had you looked at https://forum.opnsense.org/index.php?topic=42985.0, point 23 and followed the link to the official docs there, you should have noticed.

The only question is if there is actually an update available in that package for you specific CPU and if it fixes your problem. You will find out only if you try, not by discussing if this is possible at all, so please do as Patrick said.

Microcode updates are applied via a BIOS update, there aren't any separate updates. It's running the lasted BIOS L43 1.16.

Some things to clear up here:

1. I am not saying that there is a newer microcode update - what I do say is that IMHO, manufacturers are slow to adapt the newest microcode updates.

2. The BIOS you are using is at least 3 years old: https://h30434.www3.hp.com/t5/Desktop-Operating-Systems-and-Recovery/HP-T730-Bios-update-failed/td-p/8453495

3. Yes, the microcode updates delivered as OS packages are separate updates, which can be significantly newer than those delivered in your BIOS. And they are needed for some platforms, like the N1x0 and other 12th gen Intel chips with OpnSense from 25.7. upwards, see: https://forum.opnsense.org/index.php?topic=42985.0, point 23.

That being said, IDK if there actually are any updates available or if they change anything for your symptoms. I just would not shrug this off if I were you.

RealTek NICs are known to work badly with FreeBSD / OpnSense. If at all, you can try the os-realtek-re plugin.

I also do not know if the latest BIOS is up to par w/r to microcode updates (or if there are still updates from AMD for this old platform).

And, yes of course it can be a compatibility issue. FreeBSD does not support as many hardware types as Linux and some of the FreeBSD drivers are abysmal.

Hast Du Firewall-Regeln definiert, die den Zugriff erlauben? Die Eintragungen im Wireguard selbst reichen dafür nicht.

Damit kommst Du nur bis zur Tunnel-IP - damit kannst Du übrigens auch checken, ob die WG-Verbindung wirklich funktioniert.

IDK if zenarmor has finally made the jump to being multithreaded, there was a long ongoing discussion about that. If not, then an N355 will probably do nothing at all over an N150, because it only has more cores.

Any type of IDS/IPS will stress the CPU way more than pure routing. With an N150 and without IDS, you should get 10G routing throughput (or close to it, because most 82559-based devices cannot really reach full 10G speed.