IPFire Crashed but reboot fixed the issue

Hi Everyone! Im running ipfire on a bare metal intel H610 motherboard and i3 12100 processor. Occasionally, IPfire will fail to pass packets and will crash. I can’t access 192.168.1.1:444 but there are lights on my NIC and my network connections is ok. Restarting the firewall fixes the issue. I dont see any errors coming from the Kernel but I believe (and Im speculating here) that Suracata may be the issue. Check out the logs below. I think one of the rule sets are causing the issue. Can I provide any other logs?

IPFire diagnostics
Section: suricata
Date: January 23, 2025

07:57:06 suricata: rule reload starting
07:57:06 suricata: Including configuration file /var/ipfire/suricata/suricata-homenet.yaml.
07:57:06 suricata: Including configuration file /var/ipfire/suricata/suricata-dns-servers.yaml.
07:57:06 suricata: Including configuration file /var/ipfire/suricata/suricata-http-ports.yaml.
07:57:06 suricata: Including configuration file /var/ipfire/suricata/suricata-used-rulesfiles.yaml.
07:57:06 suricata: 1 rule files specified, but no rules were loaded!
07:57:06 suricata: Threshold config parsed: 0 rule(s) found
07:57:06 suricata: 0 signatures processed. 0 are IP-only rules, 0 are inspecting packet payload, 0 inspect application layer, 0 are decoder event only
07:57:07 suricata: rule reload complete
19:57:10 suricata: rule reload starting
19:57:10 suricata: Including configuration file /var/ipfire/suricata/suricata-homenet.yaml.
19:57:10 suricata: Including configuration file /var/ipfire/suricata/suricata-dns-servers.yaml.
19:57:10 suricata: Including configuration file /var/ipfire/suricata/suricata-http-ports.yaml.
19:57:10 suricata: Including configuration file /var/ipfire/suricata/suricata-used-rulesfiles.yaml.
19:57:10 suricata: 1 rule files specified, but no rules were loaded!
19:57:10 suricata: Threshold config parsed: 0 rule(s) found
19:57:10 suricata: 0 signatures processed. 0 are IP-only rules, 0 are inspecting packet payload, 0 inspect application layer, 0 are decoder event only
19:57:11 suricata: rule reload complete
20:51:09 suricata: This is Suricata version 7.0.8 RELEASE running in SYSTEM mode
20:51:09 suricata: CPUs/cores online: 8
20:51:09 suricata: master exception-policy set to: pass-packet
20:51:09 suricata: HTTP memcap: 268435456
20:51:09 suricata: NFQ running in REPEAT mode with mark 2147483648/2147483648
20:51:09 suricata: dropped the caps for main thread
20:51:09 suricata: fast output device (regular) initialized: fast.log
20:51:09 suricata: Packets will start being processed before signatures are active.
20:51:09 suricata: binding this thread 0 to queue ‘0’
20:51:09 suricata: setting queue length to 4096
20:51:09 suricata: setting nfnl bufsize to 6144000
20:51:09 suricata: binding this thread 1 to queue ‘1’
20:51:09 suricata: setting queue length to 4096
20:51:09 suricata: setting nfnl bufsize to 6144000
20:51:09 suricata: binding this thread 2 to queue ‘2’
20:51:09 suricata: setting queue length to 4096
20:51:09 suricata: setting nfnl bufsize to 6144000
20:51:09 suricata: binding this thread 3 to queue ‘3’
20:51:09 suricata: setting queue length to 4096
20:51:09 suricata: setting nfnl bufsize to 6144000
20:51:09 suricata: binding this thread 4 to queue ‘4’
20:51:09 suricata: setting queue length to 4096
20:51:09 suricata: setting nfnl bufsize to 6144000
20:51:09 suricata: binding this thread 5 to queue ‘5’
20:51:09 suricata: setting queue length to 4096
20:51:09 suricata: setting nfnl bufsize to 6144000
20:51:09 suricata: binding this thread 6 to queue ‘6’
20:51:09 suricata: setting queue length to 4096
20:51:09 suricata: setting nfnl bufsize to 6144000
20:51:09 suricata: binding this thread 7 to queue ‘7’
20:51:09 suricata: setting queue length to 4096
20:51:09 suricata: setting nfnl bufsize to 6144000
20:51:09 suricata: Threads created → W: 8 FM: 1 FR: 1 Engine started.
20:51:09 suricata: rule reload starting
20:51:09 suricata: Including configuration file /var/ipfire/suricata/suricata-homenet.yaml.
20:51:09 suricata: Including configuration file /var/ipfire/suricata/suricata-dns-servers.yaml.
20:51:09 suricata: Including configuration file /var/ipfire/suricata/suricata-http-ports.yaml.
20:51:09 suricata: Including configuration file /var/ipfire/suricata/suricata-used-rulesfiles.yaml.
20:51:09 suricata: 1 rule files specified, but no rules were loaded!
20:51:09 suricata: Threshold config parsed: 0 rule(s) found
20:51:09 suricata: 0 signatures processed. 0 are IP-only rules, 0 are inspecting packet payload, 0 inspect application layer, 0 are decoder event only
20:51:11 suricata: rule reload complete
20:51:11 suricata: Signature(s) loaded, Detect

This indicates that you have chosen one ruleset provider but you have not selected any of the rules within that providers ruleset. This why the following message indicating that no rules of any available types have been selected.

20:51:09 suricata: 0 signatures processed. 0 are IP-only rules, 0 are inspecting packet payload, 0 inspect application layer, 0 are decoder event only

From that log Suricata looks to be working fine but with no rules to load.
I don’t think that your crash system is anything related to suricata based on that log.

When you can’t access the WUI via the 192.168.1.1:444 are you still able to login to the console with the root password?

Hello!

Thank you for the help! I didn’t try to console into the system as it was late in the day. I’m using the following rulesets:

Talos VRT rules for registered users 2025-01-23 09
Snort/VRT GPLv2 Community Rules 2025-01-23 09
Emergingthreats.net Community Rules 2025-01-23 1
Abuse.ch SSLBL Blacklist Rules 2025-01-2
OISF Traffic ID Rules 2019-04-26 15:18:07

Ive had this issue before where during a rule update, the firewall will not pass traffic and services like DHCP stop working. I just couldnt figure which one if any was causing the issue.

Okay, if you have that many ruleset providers and presuming that you do have some of the rules listed for each of those providers checked via the Customise Ruleset button then something peculiar is occurring.

The suricata log you showed is indicating that there are no rules that have been selected.

If you go to the Intrusion Prevention System WUI page and press the Customize Ruleset button and then at the bottom of the page that is opened you press the Apply button, suricata will update the rules that it finds. In the IPS system logs you should then see something like the following but with different numbers.

20:51:09 suricata: 1 rule files specified, but no rules were loaded!
20:51:09 suricata: Threshold config parsed: 0 rule(s) found
12:28:22 	suricata: 	26537 signatures processed. 91 are IP-only rules, 2205 are inspecting packet payload, 24216 inspect application layer, 0 are decoder event only

If you see something like that (but with different numbers) can you confirm that the log messages with the following info

20:51:09 suricata: 0 signatures processed. 0 are IP-only rules, 0 are inspecting packet payload, 0 inspect application layer, 0 are decoder event only

is occurring at a time just after your problem of accessing the WUI has occurred. ie whatever is occurring is causing suricata to lose all information on selected rules but also to only think that you have one of those ruleset providers enabled.

If you believe that the problem is related to one of the rules that you have selected then the simplest approach is to disable one of the ruleset providers on the main IPS page and then see if the problem re-occurs.

Of course that is only easily viable if the problem occurs relatively frequently. If it is related to when the rulesets are updated then that occurs every 12 hours from the start time of your IPFire system after a reboot.

Thank you! I had to look a little deeper and one of the rule sets failed to install an update correctly. I believe this is what happened before. I removed the offending rule for now and will figure why it happened later. Other than that, the Firewall has been wonderful. Thanks again and always appreciate the help!

Glad you figured it out.

It would be good if you could find some messages in the IPS system logs for when the update went wrong. They might give a clue to us as to what went wrong.

The system should be able to deal with any errors and provide some sort of message rather than actually stopping the system from working at all.

Knowing what problem was flagged up and with which ruleset provider might give us enough clues to figure out how to detect it without breaking things.

1 Like