Messages

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.

You can try to edit /usr/local/opnsense/scripts/wireguard/reresolve-dns.py like described here and try if this works for you:

https://github.com/opnsense/plugins/issues/3565#issuecomment-4841782276

You are correct, see: https://github.com/opnsense/plugins/issues/3565#issuecomment-4834448169

There is a cron job called "Restart Wireguard on stale connections" - try enabling that.

Did you use the Realtek vendor or the FreeBSD native driver on OpnSense?

O.K., I never had the need to look at those logs. I do adblocking using browser plugins.

If you normally use OpnSense for all things network-centric, you may be better off to have everything pertaining to logging and things there. Also, if you have DNS problems because of excessive blocking, you can switch centrally on OpnSense only this way, because otherwise you would have to wait for your clients to pick up the alternative DNS server IP.

Who wants to look at a DNS query log and for what purpose? And even if you do, why not look at OpnSense's DNS logs, if you care about who asks for what?

[Only use if you know what you are doing.]

Du hast vermutlich "Strict QNAME Minimisation" angehakt. Einfach mal den Hilfetext lesen:
   
"Send minimum amount of information to upstream servers to enhance privacy. Do not fall-back to sending full QNAME to potentially broken nameservers. A lot of domains will not be resolvable when this option in enabled. Only use if you know what you are doing."
   

Some IPv6 clients act in an unexpected way w/r to DHCPv6 and its options. For example, Android devices cannot use DHCPv6 at all but use router advertisements (RA) instead. Some can use the RDNSS option.

That being said, I use RA in "unmanaged" mode for many reasons, but mainly because that is guaranteed to work, but I do not use IPv6 DNS servers - those are not strictly needed if your clients can also do IPv4, because the IPv4 DNS server will also serve IPv6 adresses. This is all described here.

I would rather instruct OpnSense itself to make use of your PiHole as upstream server and not instruct clients to use that directly.

Alas, I cannot give much info about how to do it with DNSmasq, because I use Kea and Unbound. All I know is that DNSmasq has restrictions on its builtin RA mechanism, however, you can disable that and use RADVD instead.

1. The reason why iperf probably shows a higher performance is that it is able to use multiple TCP streams, which you may have selected by using -Px (see https://forum.opnsense.org/index.php?topic=42985.0, point 10).

2. wget, curl rsync and scp use a signle TCP stream, where problems induced that can be induced by double NAT and the Proxmox virtualisation layer come into play. The fact that the rsync starts out fast and then drops speaks for buffer overruns.

I would try to further reduce the MTU size to 1360 on both sides first, regardless of if the pings work with your current settings.

Did you use virtio networking on the OpnSense VM with the settings depicted here, including RSS in OpnSense and on the VM NIC settings? In this specific case, multiqueue on the VM's NIC might be harmful, as it can cause out-of-order packets.

If you passthru the NIC, the VM might not get all interrupts in due time.

If you have to option, try to use a bare metal OpnSense in site B to isolate virtualisation issues.

Wireguard uses UDP and does not benefit from TCP buffer algorithms, so you might also try to use traffic shaping to ensure that buffers are not overrun.

The physical interface is limited to 1 Gbps, I doubt that the driver itself does anything w/r to timing. However, virtio on the vistualisation border should work just fine. IDK how SR-IOV comes into play here, because you do not / should not pass thru the NICs.

Just to make this clear: There are two basic ways you can do this:

1. By passing thru the physical NIC hardware to the VM guest. This absolutely needs a working FreeBSD for the hardware. I do not recommend it. This is where technologies like SR-IOV comes into play.

2. By attaching a virtual network card to the PVE host bridge. In the VM, you can then select which emulated hardware you want to present to the guest, so either E1000 or virtio or whatever hardware your guest supports. For OpnSense, I recommend this way and also, using the virtio drivers.
Virtio would show up as virtioX as network device names under OpnSense.

You MTU looks O.K., so this should work fine. Maybe the physical NIC has some optimisations to coalesce interrupts. This is often the case for high-speed NICs in order to handle traffic more efficiently. It may well be that this interferes and makes low-volume traffic look "choppy".

I would try to use another NIC type to rule out a hardware/driver problem on the PVE side of things, especially, because there are many problem reports for those adapters over on the Proxmox forum: https://forum.proxmox.com/search/19853344/?q=I40e+nic

I suppose there are no FreeBSD drivers for i40e, so you can only use virtio networking. The virtio drivers are pretty good in that there is no additional overhead to emulate any "real" hardware, so there should be no slowness, provided you do everything that is mentioned in the guide.

What I do not get: Even if virtio emulation does not work as expected and E1000 does, this is but a matter of performance, not functionality per se. So what is the problem with using E1000? AFAIK, there is no specific limit with either virtio nor E1000, modulo that any emulation layer through virtualisation limits performance with speeds way higher than 1 Gbps.

Without any specific details, it is hard to say more. Partial loading and general network slowness can be caused by many things that could also be occur if Proxmox was not involved, like wrong MTU settings (did you try to use jumbo packets?). By using OpnSense under Proxmox, you certainly make the setup more complex, that's for sure.

Probably this helps: https://forum.opnsense.org/index.php?topic=44159.0