Suricata blocking crashes OPNsense 1.19.4 and some earlier versions

[erioshi]

I am having a problem that consists of a full OPNsense crash and kernel panic when I enable the blocking feature within Suricata.  This crash is severe enough that normal reboots end up with OPNsense going straight back into a crashed and locked state.

I am currently running OPNsense 19.1.4, but this also happened with some earlier versions of OPNsense for me.  I do not have a list of the specific versions that have failed, my OPNsense experience has been off-and-on as I keep flipping between OPNsense and pfSense.

I am running OPNsense in CARP/HA failover on two different Proxmox nodes using OpenVswitch to provide the LAN and sever other interfaces to OPNsense.  The OPNsense VMs have plenty of resources.  The only interface currently set within is the LAN interface.

Every time I enable the block option, the OPNsense VM will crash and fully lock up within about 30 seconds.  Once it reaches the crach state it becomes completely unresponsive.  The only remedy is to shut the VN off externally.  If allowed to reboot it will follow the normal boot process until it again crashes and hard-locks.

If left in just reporting mode, Suricata appears to function and generate alerts.

I'm new to Suricata so the correct rule sets, etc. are something I'm just getting to know.  I have a lot of experience with Snort (any chance of bringing that to OPNsense?  I really miss Snort.) so an not a total newb to IDS/IPS.

How do I get this working?

I could roll back to pfSense, but that product has an issue with OpenVswitch as LAN.  I work with Nutanix by day which does use OpenVswitch so I would prefer to keep OPNsense part of my home lab.

[AdSchellevis]

Have you tried https://forum.opnsense.org/index.php?topic=11477 ?

We only support real inline mode, which requires netmap driver support, which is known to be broken in some (virtual) setups. The call for testing contains the patches which will eventually be included in OPNsense.

Snort is something we most definitely don't consider adding to OPNsense, better investigate the options available in Suricata.

Also keep in mind that pfSense likely doesn't have inline mode enabled and uses some kind of ip block list for "compromised" ip's, which isn't very fine grained when blocking possible threats, but obviously doesn't have the same hardware support constraints as well.

[erioshi]

Thank you for your quick response, I will dig into the linked thread when I have a bit of time.

I can snapshot and test, so  I don't mind trying out the new nmap driver and reporting back.

As an aside, I do understand there are significant differences between Snort and Suricata, but I would think having both options available would only grow the appeal of OPNsense within the potential community.  Just my thoughts, I'm done now.

[erioshi]

Just revisiting this after some time away.

I ended up moving back to pfSense for quite a while because of Snort and just lived with needing to bring down pfSense on the Proxmox host for the primary router when I wanted up date that Proxmox host.  Everything else works fine.

So why is Snort such a big deal with me?

There are a coupe of reasons.

1) Snort's AppID functionality is incredibly useful and easy to support and use from an IDS/IPS perspective.
2) Suricata only allows me turn a rule on or off.  Snort allows me to except rules by IP address.  This lets me do things like allow my repository mirror to pull repository updates from the outside world, but alert me if other servers are trying to do the same thing.

It is a simple example, but that kind of functionality is really important if I want to be able to bring OPNsense from my home lab into the company test lab.  As it is, OPNsense wouldn't meet the operational requirements for my work environment, even for our test lab, and I need to use another product.

This also means that I cannot look to purchase OPNsense products or support offerings at work.  This literally means I cannot give you corporate money even though I would like to.

Overall I find I much prefer working with OPNsense over pfSense.  I also strongly dislike the anti-community sentiments being given off by the parent organization of pfSense.  Unfortunately Snort, Cisco Firepower, or an equivalent become a requirement once you reach a certain size.  Suricata doesn't really hold up when compared to those tools.

[AdSchellevis]

Some people prefer Sort, I don't think there's much we can do about that, we're not considering adding it to OPNsense for multiple reasons (such as a good relationship with Suricata, progress within the project, ease of support). Adding multiple options has the downside of efforts being divided between modules, which eventually would not benefit both in this case.

Some features should be possible in the future, with proper network segmentation it might be an option to add https://suricata.readthedocs.io/en/suricata-4.1.4/configuration/multi-tenant.html at some point in time, to support different policies for different network types (for vlans this should already be possible, per device unfortunately not, when using IPS).

AppID would probably be challenging, we do support some rules ourselves (https://github.com/opnsense/rules), some commercial sets probably have rules too, but implementation would likely be different.

We really try to keep IDPS accessible for less experienced users, which is also a reason to be careful with adding a lot of knobs and handles in the interface, advanced users can add custom options in a custom.yaml by the way (which is a method we often provide in our modules).

Best regards,

Ad