Messages

The script is quite clever. I tested it on all my different installations, SATA, NVME and virtio, but all UEFI and it worked flawlessly.

Besides: loaders-update is neither installed nor available on OpnSense, is it?

I hardly ever use the source port field in a source NAT rule - after all, that usually is on Outbound NAT rule that applies to an interface and most probably to all addresses that can originate from it. Thus, I do not find it unusual to hide that setting under "advanced".

The only thing I find strange with the blocks is that "Destination (advanced)" seems reverted wrt all other settings: Wenn the arrow points down, the subordinate settings should be visible, like with all other items. If it bothers you, you should open a bug on Github.

You did use multiple threads if you tried this via iperf?

Also look at:

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

And be sure to use "host" CPU type and disable Spectre and Meltdown mitigations.

Port 113 is often blocked by ISPs - there is good reason to do that. Try if you see any packets on that port by creating a logging rule for the port and see if it fires at all.

You can check by creating rules as well for the "open" ports in order to see if something in front of your connection catches these packets, be it the ISP or the bridge modem.

Other than that, you may have a PNP daemon installed which allows LAN devices to dynamically open ports to the outside and some VoIP or other device does this (And yes, port 5060 is for SIP).

See this for a start. Use RSS under OpnSense (it's documented) and set the VM NICs to multiqueue.

A few observations:

1. The new late loading scheme does not leave any traces in dmesg, even if it did update the CPU microcode. You can check with cpucontrol instead.
2. dmesg can show multiple boot logs, so if you only grep in its output, you cannot be sure which previous boot it was in. You would need something like this to grep only the last boot:

Code Select Expand

dmesg | awk '/---<<BOOT>>---/{boot=""} {boot=boot $0 "\n"} END{print boot}' | fgrep microcode

3. After having upgraded your boot files, you may use early loading again by adding these tuneables via System:Settings:Tunables (for Intel CPUs):

Code Select Expand

cpu_microcode_load = YES
cpu_microcode_name = /boot/firmware/intel-ucode.bin


You can also try to create a manual outbound NAT rule and use "Hybrid" NAT mode.

It is almost sure that you need NAT on OpnSense for this to work because your front router does not know the route to 192.168.10.1/24.

[pac]

It is the package manager for Arch Linux.

It does work. Unless you have conflicting dynamic leases because you changed the IP for a client and made it static (aka "migrating from dynamic to static"). In that case, there can still be "active" leases that prevent your clients from ever obtaining those blocked IPs.

Also, static leases need to be outside of dynamic pools. This is mandatory.

Check that first and then look at /var/db/kea/kea-leases4.csv where you may find that the IPs you reserved are still taken up by other MACs (provided that you disabled "Match client-id").

You can stop Kea, clear out the mess in the configuration and the lease file and then start Kea again and it wil magically work.

See this for a more throrough explanation.

If it is really 25.7 and not 25.7.x, then I would say yes. You can do a snapshot first if you want to switch back.

Das schrieb viragomann doch... es geht darum, den Rückweg, der sonst über das Default-Gateway liefe (Dein Router), zu ermöglichen, indem vorgegaukelt wird, alle Pakete von 192.168.99.0/24 kämen von 10.170.60.254, damit sie lokal beantwortet werden können und nicht über den Router laufen.

S-NAT:

Interface: LAN
TCP/IP Version: IPv4
Protocol: any
Source: WireGuard net (oder besser das spezifische WireGuard-Subnetz, z. B. 10.170.61.0/24)
Destination: LAN net (oder any)
Translation / Target: Interface address


Bei der Source kommt es darauf an, mit welcher IP die Clients oder der Host ankommen: Wenn der Host selbst ein Wireguard-Client ist, nutzt er die Tunneladresse 10.170.61.1. Geht er über ein anderes WG-Gateway, nimmt er eher 192.168.99.39/24 - die Source muss das so reflektieren.

Ich gehe oben davon aus, dass der Quell-Host ein WG-Client ist, der die Route zu 10.170.60.254 aufgrund der "AllowedIPs" kennt und dort mit der 10.170.61.1 aufschlägt. In der OpnSense würde die S-NAT-Regel dann diese Pakete aufgrund der Source auf die LAN-Interface-Adresse (10.170.60.254) umschreiben. Der Ziel-Host sieht dann diese Adresse und redet direkt im LAN damit.

Das ist richtig. Effektiv ist der Transferspeed für Daten der bestimmende Faktor dafür, wie lange man auf das Ende einer Operation wartet.

Wobei 10G Switches noch zu haben sind (wenn's auch kostet), aber alles abseits von DAC-Kabeln auch ziemlich Strom frisst. Ich nutze 10G ausschließlich mit DAC-Kabeln im Backbone, also zwischen OpnSense, Switch und Servern und nur für einen Haupt-Client per 10 GbE.

Alles andere maximal mit 2.5G, weil die Hardware günstig zu haben ist, wenig Strom verbraucht und vor allem, weil in der Realität selbst mehr großen Plattenarrays der Transferspeed meist auf ca. 300 MByte/s begrenzt ist, da zumindest beim Schreiben die Paritätsplatte(n) den maximalen Speed limitieren.

Und wenn man dann noch auf IDS verzichtet, reicht in der OpnSense ein N1x0 (allerdings mit 2x SFP+), der Switch kostet einen Tausender (z.B. USW-Pro-HD-24-PoE, weil man idealerweise 4xSFP+ braucht, denn 2 reichen nicht, wenn man noch einen Backup-Server braucht).

No, if you pass the NICs through, OpnSense has full control over the NICs.

However, there is something off with the two GUAs your WAN receives. If x:908:c21a:df00::/56 is the IA_PD prefix, as it seems, then x:908:f000:83f::9d5/128 is the IA_NA, which is not from the same range, so that's O.K.

But what is: x:8101:3ff:fc7c:2a5:69ff:fe87:c47a/64 ? It looks like the suffix ::2a5:69ff:fe87:c47a is the EUI-64 from the MAC of your WAN, but the prefix x:8101:3ff:fc7c::/64 is neither the IA_NA nor one of the IA_PD prefixes. While it is technically possible to get multiple IA_NA options, I have never seen that, so maybe it can cause problems. I would use "Request prefix only" and set a unique optional prefix ID (say, 99) to rule this out. You should see only one GUA after this, namely x:908:c21a:df99:2a5:69ff:fe87:c47a/64.

If that does not work: I know @Franco has changed some things in the IVp6 code with 26.1, but IDK exactly what.

The /128 on the WAN must be the IA_NA IPv6. But if you use a /56 prefix, there must be the least significant 8 bits that are used for any other interface - I understand the prefixes 0, 1 and 2 for your internal interfaces. But what is the /64 on the WAN made up from?

Let's leave out the fe80::/64, because those are link-local and of no special interest apart from that the WAN uses a link-local gateway as well.

I wonder what the /64 GUA on the WAN is? What is the 8-bit prefix of that? Are the first 56 bits shared with the IA_PD from your LAN interfaces?

And now I see: You are using OpnSense virtualized under some kind of KVM (i.e. TrueNAS Scale). That complicates things A LOT.

What do I mean by this? See: https://forum.opnsense.org/index.php?topic=44159.0, especially the part about "bridge-mcsnoop 0", which could well explain what you are seeing, because the known bug manifests in IPv6 connectivity breaking after a short while.

That being said, I have no experience with TrueNAS Scale at all.