Messages

My remarks were not really meant to be questions, but purely rhetorical, which is to say:

If you only have two sides (or interfaces), doing a routed setup is no more complex than a transparent bridge - if you have more than two, a transparent bridge cannot be used at all (or at least I fail to see how). So, why use a transparent bridge in the first place?

X470 chips in general and the consumer platform based Asrock Mainboards are notorious for failing early, too.

What I always wondered about that transparent bridge setup: If you have only two sides between to filter traffic, then what would be so difficult as to use different subnets (aka routing)? And if you don't, like if you have separate VLANs, then how to you even get the traffic to pass your firewall?

Once you get to understand routing, it seems natural to choose that, which is possibly why < 1% of people here would be able to help if you don't.

All I know is that ASPM can be disabled globally or on a per-device basis. The latter normally needs BIOS or driver support, the former, AFAIK, does not.

I had freezing issues on my I226-V NICs on a Minisforum MS-01, the bug was fixed via a BIOS update. Also, there was this discussion of possible remedies: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245

ASPM is causing this for I226 devices and I am not aware that updating the NIC firmware fixes that.

If there is an updated BIOS for the Protectl, try that first. You can actually make that go away with ASPM off, but AFAIK, you can only disable this for the whole machine under OpnSense if the BIOS does not set it selectively for your NICs.

The global setting is by done setting the tuneable hw.pci.enable_aspm=0. You should probably also set dev.igc.X.eee_control=0 with X=0,1.

There is now a proposed fix which can be tested via "opnsense-patch 67ea4ad". Applying the same patch again reverts it, whould the need arise.

Die Wahrscheinlichkeit ist hoch, dass die statische vergebene IPv6 noch im gecachten Lease-File für eine andere DUID (Frage: nutzt Du wirklich die MAC die Zuordnung?) steht, dann klappt die statische Nutzung nicht mehr. Das ist einer der Gründe, wieso man die statischen und dynamischen Bereiche bei DHCP strikt trennen sollte.

Ich nutze für IPv6 ohnehin kein DHCP. und adressiere Clients im Netz nur per IPv4 (IPv6 wird nur outbound verwendet), siehe: https://forum.opnsense.org/index.php?topic=45822.0

My clients are now only receiving the IPv4 addresses for my PiHole and OPNsense Unbound, in that order, and will fallback to the OPNsense server if the PiHole goes away for whatever reason.

AFAIK, this is a common misconception: There is no guaranteed order if you specify multiple DNS servers. A client may choose to send out the DNS queries in parallel and take the first answer. Thus, the order is arbitrary, so this is not a "fallback" in its strict sense. This exact behaviour can be detrimental for DNS blocking.

Why do you prefer the null routes solution?

That has been discussed in this thread: https://forum.opnsense.org/index.php?topic=50678 - essentially, with "out" rules, you may forget that you actually have RFC1918 IPs you want to reach on WAN, whereas with null routes, that works out of the box. Also, note the "disable reply-to" problem here: https://forum.opnsense.org/index.php?msg=258978

On the other hand, you are correct in that you will see nothing the logs, for this is routing, not a firewall rule.

By RSS, I meant: https://docs.opnsense.org/troubleshooting/performance.html, which is also referenced in the READ ME FIRST article. In order to make it work under Proxmox, you nee to enable it on both OpnSense and Proxmox (aka "multiqueue").

However, as said, with Wireguard, out-of-order packets may result that could also give lower performance.

That they would block this kind of traffic but apparently do not ?!?!

Not going out the interface, only in...
 

The RFC1918 leakage caused by clients that try to access something not in your own networks (like probing for anything on 192.168.1.1) can have adverse side-effects: Some ISPs take it as a hint to a misconfiguration. In Germany, Deutsche Glasfaser takes down the connection for a few minutes when this occurs excessively.

It is not my idea to do any mods that will get undone in the future.

However, I am only speculating that the fix I propose will heal your problem - I do not experience it, so I cannot try. If the fix indeed helps, Deciso might be compelled to include it in future releases. I filed a bug report for this: https://github.com/opnsense/core/issues/10475

Les navigateurs modernes ne résolvent souvent plus les noms de domaine via le résolveur DNS du système, reçu par DHCP, mais utilisent plutôt DoT (DNS over TLS) ou DoH (DNS over HTTPS). Cela contourne effectivement OPNsense.

Malheureusement, bloquer DoH reviendrait à jeter le bébé avec l'eau du bain, car cela ne serait possible qu'en bloquant entièrement le port 443, ce qui empêcherait pratiquement tout le trafic Web de fonctionner.

Ce que l'on peut faire, en revanche, c'est utiliser des listes de blocage DNS contenant les services DoH connus. Je recommande notamment la liste HaGeZi DoH, qui couvre un grand nombre de fournisseurs DoH connus. Il faut ensuite désactiver DoH dans le navigateur afin qu'il utilise à nouveau le DNS classique. Dans ce cas, les autres règles de blocage DNS que tu as configurées fonctionneront également.

Bien entendu, tout cela ne sert à rien si l'on utilise un VPN.

P.S.: En règle générale, tu obtiendras davantage de réponses en publiant sur les forums anglophones. S'il existe une solution, davantage de personnes seront également en mesure de la comprendre et de t'aider.

I once had "out" rules blocking RFC1918 IPs on WAN (which shows one of the very few appropriate uses for "out" rules), but then somebody pointed me to this way better approach:

You cannot view this attachment.

Why this works? Because your local RFC1918 interface routes are more specific than these and make your real routes work.