I’m not sure if it belongs here, but ipfire as VM, with IPS on, is horribly slow AND CPU usage is killing it.
our tunnel into datacenter (ipsec site2site) got the latency of 1000-2000ms → after disabling IPS, everything is smooth again: <20ms. I reproduced it with a new VM and a new site 2 site connection with ipsec. same hardware, new installation.
Linux perf Examples is your friend to trouble shoot CPU performance issue 
You need to be very careful using this function on a production system. Hardening restrictions have been added to its use in IPOFire to deal with CVE vulnerabilities. It is not recommended to use on a production system.
See post
https://community.ipfire.org/t/ipfire-performances-drops-then-crashes/13060/17
these kernel perf knobs can be adjusted during perf data collection, and turned back to security setting after perf data collection, so it is fine in my opinion, perf is used in enterprise servers in production system for enterprise customers.
is Suricata on the WAN? If it is so, then its wrong and should only be applied to the networks only and not the WAN interface.
Otherwise, its going to get bogged down with side traffic not associated with the network and open itself up to an attack vector.
You can enable or disable suricata on the red interface on the IPS WUI page.
I’ll have to go disable this even though you should never have it on in the first place unless the ipfire machine is a switch in the network and is used for data collection. But all of these modules like Suricata should be able to be turned off as they are not needed all the time.
You can also disable suricata on the IPS WUI page. Just uncheck the enable suricata checkbox and press save.
You must have enabled it in the first place.
The default starting point for the IPS WUI page is for suricata to be disabled and all interfaces disabled.
must have turned it on to see what it does: nothing really on a quiet residential connection. So I imagine its a use case.
Its always subjective if NIDS systems are really needed on low traffic consumer connections.
Yes indeed its enabled. But only 3 servers in the LAN, they do not generate traffic itself, just our other side of VPN tunnel generating traffic into this side. Anyway, configuration exists since 2020, so was working for four years. No with core 189 we got this issue. Sorry was unable to dig into it. Maybe sunday morning I have a free hour for it. Busy days 
I have had no issues with my CU189 running on a physical machine.
I can’t test out the situation with a vm system right now.
If I am able to remember I will test it out in two weeks time.
Hi Dave,
I understand your concern because I initially thought the same.
However, Suricata (IPS) was recently moved to the mangle table as part of the last two IPFire updates. You can see the patch details here. This shift means that Suricata now tags packets early in the networking stack, on the interfaces you’ve selected, before any firewall rules are applied. It processes traffic as soon as it enters or leaves the system, which makes it far more efficient and less likely to be bogged down by irrelevant side traffic.
Suricata is a passive inspector—it doesn’t open ports or expose services to the outside world. This means there’s no additional attack surface created. Its role is to tag packets in the mangle table, and then the firewall handles blocking or forwarding them based on the tags. So, Suricata does not open up any attack vectors but rather strengthens security by inspecting packets before they reach critical systems.
The recent updates also added a bypass feature, which allows Suricata to skip low-risk or unnecessary traffic, significantly reducing resource usage. You can see this in action in the IPS section, which includes a graph showing which traffic is being bypassed.
In short, Suricata now operates more efficiently by inspecting traffic early and bypassing unnecessary traffic, which makes it lighter on system resources, even on the WAN interface.
Hope this helps clarify the situation!
Thanks,
A G
There has been a bypass capability for some time. I can’t remember which CU it was added in, it was mentioned in the release announcement, and it improved the throughput significantly back then.
Right you are! Thank you for clarifying. It’s the graph which is new.
I think the bypass feature was originally added CU161, as mentioned in this blog post.
Yes, that was the one i was thinking of. Just couldn’t easily find it while on my phone.
until someone or something crashes the instance of Suricata and everything starts bypassing the firewall.
The only reason I installed ipfire is so that I didn’t have to sit there and edit iptables manually. The rest of the fancy charts and all that can be removed. Another way I could have done this was rip the cgi pages and install it on Ubuntu Server because to me this is just another Perl program like Webmin which it looks like this system has just enough for most of Webmin to be installed. The file manager and web SSH shell would be nice.
This used to be a concern before bug 13764 was addressed, but not anymore.
Instead of using the NFQUEUE setup, Suricata has now been moved to the mangle table, which allows it to tag packets earlier in the networking stack and without risking security issues if it crashes.
Here’s what’s happening under the hood:
Early Inspection, No Hands-on: By placing Suricata in the mangle table, it inspects packets as soon as they enter or leave, without handling any routing decisions. This keeps it out of the way of firewall rules, so even if it crashes, the firewall continues to operate as expected.
Added Safety Net: A new “watcher” process also monitors Suricata and restarts it automatically if killed (e.g., by the OOM killer), further minimising risk of unexpected crashes.
Since Suricata is strictly passive in this setup, it doesn’t open ports or expose any services to the outside world. Its role is purely to tag packets in the mangle table, while the firewall still controls whether to block or pass traffic based on those tags. This setup effectively closes any gaps from Suricata going down, keeping the firewall locked down.
Hope this helps to clarify!
Cheers,
A G
