Topics

I last tried OPNsense seriously around the time of 19.1 and was amazed that the installer had multiple lockups.

A couple of years on from that with 21.1 I am trying again, and am gobsmacked that the same installer bugs still exist:- once when choosing "guided install" and again at the swap partition size.   Each time I have to go "CTRL-C" and log back in again as installer/opnsense. Incredible.

I am on standard ESXI 6.5 with latest patches.  UEFI.  Nothing unusual. Sure you can get around it searching around the Internet and eventually stumbing on the multiple CTRL-C re-login workaround (if you dig deep), but this is just not good enough for any software which wants to be taken seriously. I can imagine thousands of techs trying out OPNsense for the first time and abandoning it right there, being scared off from the very start at the quality of the software, or lack thereof.... which is exactly my experience now on multiple ocassions!

Will "Migrate bsdinstaller to bsdinstall" fix this long-standing and very important issue? If it does, then it can't come soon enough? Also will that include install on ZFS? I am OK with UFS installs for my virtualised environments, but there's no way I'm putting UFS on my stand-alone firewall boxes, when others offer ZFS as root install options.

OPNsense is super horrible when it comes to changing interface types! SIMPLY. HORRIBLE.

I have a lab setup where I am using VMware Paravirtualsed Ethernet v3 NICS (vmxnet3) and then I found out that tagged Ethernet frames weren't working in the lab environment (GNS3 VM on ESXi 6.7) so changed to Paravirtualised Network I/O (virtio-net-pci) NICs and then rebooted. FYI the VMware NICs are vmx* in OPNsense and Virtio NICs  are vtnet* in OPNsense .... and the vtnet* type did work with tagged frames but here's the thing...

Upon reboot, instead of OPNsense going "err.. all your old NICs are gone.... help me match up the previous NICs to new ones",  it just says "yeah screw you buddy and your previous config that you worked so hard at and for so long - it's all gone now!! HA HA HAAAAAAA!!!!"

OPNsense devs - this is terrible. You need a cleaner separation of logical interface to physical interface mappings. Then if/when the physicals change, you prompt for this and do an **assisted remap**, and then the customer can get up and running again with **NO LOSS OF CONFIGURATION**.  You don't just blow their config away!!!!!grrrrrr >:(

And no the "prevent inteface removal" doesn't help. That just stores the old interface data (with old interface types ... but does only a partial job at that) - it doesn't help with remapping to new interfaces / interface types.  I don't know if you guys do much testing in virtualised environments but if you do - you can't really be pushing the boundaries of what you can do in them. Otherwise you'd have sorted this out well before now.

pfSense actually can and does do interface remappings. i.e. it handles this sanely. Here's a tip.... when you fork software... you are supposed to *improve* it.

Why does this matter? It matters because I have a full lab environment modelling two firewalls, three routers and three internet connections plus LAN switches and hosts. I have firewalls on pfSense right now and I could take the production configs with minimal massaging, and easily adapt them to the lab setup with minimal fuss.  I want to be able to rebuild the pfSense lab firewalls with OPNsense as a Proof Of Concept (P.O.C.) with full production-ready pre-built configs and test everything. The idea is to work up the OPNsense configs in the lab until they are production-ready, and then rip the configs off the lab and take them into production. But with OPNsense being completely unable to handle interface type changes - I can't for the life of me see how this is going to work! I'll probably mean I will abandon any attempts to go to OPNsense - which means no support contract money for them. This stupidity has most likely cost them a customer.

Now you can fire back with all the ad hominems that you like but I couldn't care less. If there are massive problems with software I'll point it out - every single time. Constructive criticism is helpful - you should appreciate that I've taken the time to test the software, find the issue, compare and contrast to competitors (e.g. pfSense), and effectively communicate the issue to you and offer suggestions on how to fix it.

But yeah - it stinks.

Hi peoples.  Is this sawtooth CPU pattern going to be an issue if I put this into production?

It's the latest OPNsense 19.7 as a VM on a dual CPU hex-core Intel x5650 on ESXI 6.5U3 / Dell R710 (lightly loaded).

The first image is a new build where it's not passing traffic but listening in with promiscuous mode, which I seem to need to get CARP to work properly.

The second image is where I cloned the VM to another host configured exactly the same with same hardware specs, except it's a non-production box running ESXi 6.7U3, and there's absolutely zero external traffic going to the Opensense VM as the uplink is unplugged - so doesn't seem to be triggered by network traffic. In both cases interrupt CPU % doesn't get over a few percent anyways.

Other details - setup as 4 vCPU, 8GB RAM, 120GB HDD (4x 15k RPM RAID10 SCSI 3.5") and vNICs are VMXNET 3  (9 of those), and a LSI SAS SCSI controller.  BIOS is EFI, so I could up the resolution of the console.

Not identical but similar patterns of spiking shy of 30%. Is this normal?
Thanks. Gcon

Hi peoples.

I am super desperate and will pay someone to help me out here. I have had a high number of interface interrupts causing high CPU and I thought I'd try putting the following in /boot/loader.conf.local  (as recommended elsewhere):

hw.pci.enable_msix=1
hw.pci.enable_msi=0

Unforunately I cannot now boot as all my PCI devices "fail to allocate an interrupt"!

"Safe mode" is no help to me (yeah not very safe after all)
#3 loader prompt - have tried setting loads of things to no avail.

You'd think this would be easy but it's an absolute nightmare! A shame the website I got this from failed to mention the dangers of this. I have had days of building a new firewall config... now am left feeling absolutely shattered by this small yet devestating issue as I fear it might all be lost. I'm absolutely gutted.

Please help....I beg of you... please! :-[