Messages

I may have been lucky to avoid issues with my upgrade to 23.7, as unbound seems to be working fine for me. It looks like there are some workarounds for some of the issues with Suricata 7, but I'm sure stability, in general, will be an adventure once it moves out of -devel.

Just upgraded to 23.7, and the process was buttery smooth. Thank you for all the hard work on this release!

I see a couple of pull requests on GitHub waiting to be merged related to Suricata 7.

Will we see Suricata 7 be included in OPNsense 23.7.1?  ;D

Native mode last anywhere from 4-7 days ish before it crashes only my vlans. I can still access my default Vlan1 to reboot firewall or even vpn in for that matter, anythgin on VLAN1 is fine and dandy, in emulated it all went down.

I'm in the same boat, but mine crashes within hours. I'm glad I found your thread though because I was going crazy thinking I had done something wrong on my end for my new router deployment.

...when I do enable zenarmor in L3 routed mode, my upload bandwidth is significantly reduced.

I am seeing the same on my end. It doesn't matter if bypass mode is enabled or not. I am forced to disable the packet inspection engine to get my upload speeds back.

Could you confirm that this issue occurs in emulated mode?

I still see the issue in emulated mode.

In our experience, intel is still a good choice in terms of driver compatibility. It's just that igc is fairly new.

Unfortunately, I see issues regardless of the Intel NIC/driver combination that I test with (see below for all the NICs in my system. I will test my Chelsio NICs next and hope that they prove to be more reliable for my setup. To be clear I have not tested with the new netmap2 kernel yet, but I'm willing to give it a shot when I find some time.

root@OPNsense:~ # sysctl -a | grep -E 'dev.(igb|ix|em|ice|cxl).*.%desc:'
dev.ice.1.%desc: Intel(R) Ethernet Connection E823-C for SFP - 1.34.2-k
dev.ice.0.%desc: Intel(R) Ethernet Connection E823-C for SFP - 1.34.2-k
dev.cxl.3.%desc: port 3
dev.cxl.2.%desc: port 2
dev.cxl.1.%desc: port 1
dev.cxl.0.%desc: port 0
dev.igb.3.%desc: Intel(R) I350 (Copper)
dev.igb.2.%desc: Intel(R) I350 (Copper)
dev.igb.1.%desc: Intel(R) I350 (Copper)
dev.igb.0.%desc: Intel(R) I350 (Copper)
dev.ix.1.%desc: Intel(R) X550-T2
dev.ix.0.%desc: Intel(R) X550-T2

I've looked into this a lot...and admittedly, it's hard to find up-to-date and reliable information. From everything I have investigated, it is even more challenging to get close to 10Gbps IPS using Suricata on FreeBSD because of Netmap.

Although Sucircata can utilize more than one CPU core, Netmap's implementation on FreeBSD has historically been limited to a single CPU core when using Suricata in IPS mode. Apparently, there is work underway to change this behavior, but I haven't been able to find the current state of progress.

This was previously brought up by a forum admin in the post I've quoted below. It has been almost two years since the post though...so I'm on the hunt for any updates on this.

Hi,

Suricata on FreeBSD uses Netmap to achieve IPS functionality. Judging by your logs, you are indeed using netmap to bypass the host stack and enable Suricata to inspect packets straight off the wire.

Note the way ports are opened:

ix0/R (Receive thread) --> ix0^ (Host stack)
ix0^ (Host stack) --> ix0/T (Transmit thread)

This simply means that on initialization, netmap opens two "ports" - one on which to capture packets, at which point Suricata will be able to do it's thing, and another port that represents the host stack (using the '^' symbol), which is used by Suricata to forward inspected packets back to the host stack. The same principle applies on the transmit side (but reversed) - totalling a thread usage of 4 in a default setup.

The way Netmap is currently implemented does not allow for more than one thread to connect to the host stack on both the receive and transmit side. Manually increasing the amount of threads will not ensure a gain in throughput, and any measured increase in throughput will be wrong, since packets on different threads might not even reach Suricata and thus could potentially even skip by Suricata, due to a lack of synchronization.

In conclusion, Suricata on FreeBSD currently only supports one thread in IPS mode. However, Netmap has recently committed support for multiple threads towards the host stack in FreeBSD, and Suricata is in the process of integrating this into their software - so keep an eye on that.

Cheers,

Stephan

at this moment i disabled Suricata

To my surprise I just ended up here as well.

Unless I have missed something...we are almost two years out from your posts and still dealing with this on FreeBSD with Netmap.

I have opted to roll with Zenarmor alone for now and stop using Suricata due to major stability and latency issues, along with a significant reduction in throughput due to only a single CPU core being utilized by Suricata. With that said Zenarmor still doesn't have multicore support either, although they advertise it on their website.