Messages

The pt-open plugin was removed from OPNsense a while ago since the ruleset itself has been discontinued since September 22, 2022.
See: https://github.com/ptresearch/AttackDetection

Best to remove it from OPNsense if you have it installed, ruleset is no longer maintained and can even give a false feeling of security.

Yes, there is.
It is even mentioned in the OPNsense documentation:
https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html

Step 9 is what you're looking for.
As soon as you implement such a rule and configure Unbound to use the WireGuard Interface the outgoing DNS request will go through the WireGuard Interface. Make sure you configure manual NAT rules first. With the Automatic and Hybrid rules, the WireGuard network itself gets NAT'ed as well, which is something you do not want and breaks your config.

see also: https://github.com/opnsense/core/issues/5329

Hi Franco,

according to my understanding of ZFS it won't make much of a difference if you flush transaction groups every 5 or every 90 seconds. What needs to be flushed to disk will be flushed to disk. And ZFS never does in-place overwrites. So if you write every 5 seconds or 18 times the transaction groups every 90 seconds ...

If @tverweij running virtualised instances is indeed using ZFS that specifically is a bad idea. Due to its copy on write nature you cannot thin provision virtual disks (well you can, but it doesn't make sense) because ZFS will eventually write every single disk block and so blow up the disk to its configured maximum size.

For virtual disks it's much better to use UFS and manage snapshots and backups at the hypervisor host level.

HTH,
Patrick

When running a virtualized OPNsense on ZFS, the issue of blowing up disks can be solved by turning on "discard" in the Proxmox VM settings and setting up a daily ZFS trim cron job within OPNsense.

Please read:

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

On the corresponding github page there are also people mentioning this issue on clean installations.

https://github.com/opnsense/core/issues/6959

It seems the issue has been identified and hotfixed now.

Looking at your mentioned tunables I can see you already applied them from most likely
https://binaryimpulse.com/2022/11/opnsense-performance-tuning-for-multi-gigabit-internet
so it seems you already did some research  :)

Did you also take a look at the Performance tuning for IPS maximum performance thread on the Intrusion Detection and Prevention section of this forum?
Some useful information is being mentioned there as well. I personally have seen big improvements with the Flow Control tunable, but your mileage may vary of course.

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

An MTU of 9000 does reduce overhead, which can increase network efficiency. The packets which are being sent are larger. However, like I wrote earlier, your would need to configure your entire network to support Jumbo Frames. Not only OPNsense, but also your switches, AP's etc.

You would also need to configure all of your endpoint devices to make use of Jumbo Frames, if they even support it... Otherwise it will lead to fragmentation and can cause issues.

In your case I would leave it to the default, unless you are certain all devices on your network support it and you need the extra overhead. The real benefit of Jumbo Frames would be visible in high speed networks where large amounts of data are being transferred. For example data centers or storage networks.

If the PPPoE screen says the MTU is 1942 I wouldn't touch it anymore. This is the correct setting.

As for MTU 9000, you really only want to use that on your internal network (OPNsense LAN interface). But, MTU 9000, also called Jumbo Frames, is mostly beneficial if your network is 10 Gbps. Yes, you can enable it on 1 Gbps networks, but your equipment needs to support it. For the time being I would leave it alone, unless you really have a reason to use it.

If you want to know a bit more about Jumbo Frames:
https://en.wikipedia.org/wiki/Jumbo_frame

I don't see an issue here, this behavior is completely normal and as expected. Same "issue" happens on my install. And besides of that, I think the answer has already been given in the proxmox thread.

AFAIK You don't need to have the AES flag enabled when using the host option as CPU within Proxmox. The VM will have exactly the same CPU flags as your host system.

Furthermore, set the CPU to 1 core and 4 sockets. Make sure you use VirtIO nics and set Multiqueue to 4 or 8. There is some debate going on if it should be 4 or 8. By my understanding, setting it to 4 will force the amount of queues to 4, which in this case matches your amount of CPU cores. Setting it to 8 will make OPNsense/FreeBSD select the correct amount.

Also, make sure (as you're using PPPoE) to set the correct MTU setting on the OPNsense WAN interface. PPPoE needs additional 8 bytes and truncates the Ethernet MTU to 1492.

Did you also take a look at some performance improvements for OPNsense? Especially the Spectre and Meltdown mitigations? I've seen some major improvement on some systems when disabling these mitigations.

https://docs.opnsense.org/troubleshooting/hardening.html

Also, don't forget to install the os-qemu-guest-agent plugin.

Seems to be working again.

Code Select Expand

Updating SunnyValley repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: .. done
Processing entries: .... done
SunnyValley repository update completed. 31 packages processed.

Can confirm that, only 3235 entries at this time of writing.

Gave it an other shot with using:

# fetch https://pkg.freebsd.org/FreeBSD:13:amd64/latest/All/crowdsec-1.4.3.pkg

# pkg install crowdsec-1.4.3.pkg

Installation went ok, crowdsec console does see the new version: 1.4.3

However, the ip blocklist stays at a low number (274 atm) and the alert section of the plugin is awfully empty. From the looks of it, it doesn't seem to update the blacklist at all. At least during the period for half an hour after installation, that seems to me no updated list is available, hence version 1.4.1. and 1.4.3 use the same (trimmed down) list. Also the history of the ip blocklist updates can't be seen anymore.

Anyway, rolled back to version 1.4.1 and the history can be seen again. Is this a history setting per plugin version and do I need to wait longer before the updates get downloaded?

Running the command

# pkg add https://pkg.freebsd.org/FreeBSD:13:amd64/latest/All/crowdsec-1.4.3.pkg

gives the following output:

Fetching crowdsec-1.4.3.pkg: 100%   29 MiB   6.1MB/s    00:05
Installing crowdsec-1.4.3...
the most recent version of crowdsec-1.4.1_3 is already installed

I'm noticing the same behavior, atm only 208 IP's in the blocklist. Looking at possible causes I can only think of two:

1: The plugin got updated last patch round, but I'm not entirely sure if the drop in blocked IP's started after the patch. If so, perhaps a problem with the plugin.
2: The blacklist itself got trimmed, but in my opinion a drop from 20k to 208 seems a bit too harsh of a drop.

Anyway, I also dropped the question in the crowdsec support channel. Perhaps some more insight can be found there. Will keep this thread updated if any info comes my way.