Messages

I first set up my OPNsense install in August 2022, which means 22.7, and it made a 260MB EFI partition at the time. I'm assuming that was done by the OPNsense installer, as I don't remember having the ability to change partition sizes.

When you pasted the private key into the GUI window while setting it up, did you make sure there were no line breaks? Remember, you paste the key into the backups page, just having the id_rsa in ~/.ssh isn't enough.

To be clear, does this need to be done if OPNsense is running on UFS, or is this a ZFS exclusive issue?

My first thought is are you using a vNIC, or did you passthrough the NICs to OPNsense? If they're passed through, did you install the Realtek driver plugin? The stock BSD drivers for Realtek are questionable at best.

Personally I've found a budget NVMe SSD with a HMB cache to work just fine for OPNsense. I bought a Team MP33 512GB (solely for higher endurance rating) and it's been working fine for 3 years so far with its endurance used according to SMART data at only 16%. Granted I set it up with UFS and not ZFS, but I imagine it won't be much different than a ZFS setup.
Just remember if you try to "right size" the SSD to something like a 128 GB (or even smaller) you're going to run into laughably small endurance ratings, since they're typically rated based on drive writes per day. 512 GB drives aren't very expensive while also offering good endurance ratings, such as the 600 TBW for the one I bought.

You'll need to buy an X550-T2 if you want to stick with Intel and have a NIC that supports 2.5 gig. 2.5 is a much newer standard than 10 gig, despite what the speeds may suggest, and as such isn't supported on older NICs like the X540-T2, which launched in early 2012.

For those stumbling across this thread via Google, or reading the forums: A pull request has been submitted to the Github at this elegant and finely crafted link. It fixes the issue and so it'll be fixed soon. Still waiting on widget.

With 24.7, the os-smart plugin wrongly detects which dev file to query for SMART data for nvme devices, showing the only option as /dev/nda0, instead of /dev/nvme0, resulting in a failure to query the SSD correctly for SMART data.

Of course if you connect via ssh and run smartctl directly against /dev/nvme0, it will correctly return SMART data, but with /dev/nda0 you of course just get this:

Code Select Expand

Smartctl open device: /dev/nda0 failed: INQUIRY failed


So here's my feedback on the new widgets:
1. The CPU usage graph has too much information. The old widgets just showing the 1, 5, and 15 minute load averages in System Information, and a real time overall usage was perfectly fine. Frankly I don't even know the difference between the graphs on the new CPU usage widget, which seem to be mostly of usefulness to a software developer, and not necessarily a network administrator.
2. There should be more configurability to the widgets. Having to add multiple graph only widgets simply to restore what was previously text line items under System Information feels... clunky? As a result I've got a cluttered screen full of half circle widgets with tiny text underneath each one
3. The disk widget doesn't even show actual space, just a percentage used.
4. The thermal sensors widget, which previously detected thermal sensor names correctly, appears to have buggered up slightly with this update. My PCH temp now detects as a 2nd "Core 0".
5. Overall it feels like a heavy focus on fancy graphs and less of a focus on text, which is fine, but there needs to be an option for people who preferred the old text heavy interface.
EDIT:
6. Just noticed the Services widget doesn't seem to remember its size. If I expand it so all services are visible and click save, when I navigate away and return to the dashboard, it's shrunken in size again so that you have to scroll to view all services.

So here's the thing about WiFi cards: They're designed to be clients, not Access Points. You will have a very bad, but memorable experience if you try to use them as Access Points. Buy a purpose built AP, like an Omada 620.
A router and a NAS should be 2 completely separate appliances, and shouldn't be combined. You don't haul lumber in a Prius, don't store data on your router.

As a temporary measure, if you're really that worried about security, simply remove ChaCha20-Poly1305 from the list of allowed ciphers in System -> Settings -> Administration, by changing the Ciphers list to be the CTR and GCM ciphers only, specifically these ones:
aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm@openssh.com, aes256-gcm@openssh.com
Since it's the end of the year right now, it might not be until the new year that updates get issued for FreeBSD, that workaround was advised by Fabian Bäumer, one of the authors of the paper on that attack, so I'd go with that for now.

As OPNsense uses ports from software ports (not harware or physical ports) from both freebsd as well as openbsd. Which repository in OPNsense or which part of the build process is responsible for assigning physical ports and mapping them with respective physical ports number.

It's the order they're presented on the PCI bus, nothing else. You'd have to contact the hardware manufacturer and have them rearrange the ports on the bus to change this behaviour.

You can't. It's based on the order FreeBSD detects the devices during boot.

From the looks of it, there's some sort of problem with Zenarmor. Have you tried turning it off?

Let's start with the basics. Under System->Diagnostics->Activity what is the top CPU consumption processes? Under normal circumstances this should be unbound with maybe 2% and l want to say php-cgi with another 1-3%.