Enabling Talos IPS rules cause trouble after upgrading to Core Update 164

The only way to figure this out is to turn off Rulesets and click Apply until you figure out which ruleset is interfering with DNS

What rulesets are currently enabled? (a screenshot is fine)

1 Like

Even after disabling intrusion prevention I was still having problems. Ended up wiping the system and downgrading to 163.


Same here after the upgrade.
DNS down, IPsec not working anymore and I wait now since 15 minutes for the firewall to come up after a reboot command …


The only way I was able to get working was to bypass the DNS Service of IPFire. I can confirm that the DNS Forwarding is not working correctly. First I went from DNS over TLS to DNS over UDP. It helped first but after a few seconds the DNS Queries weren’t able to be answered. Then I looked at this Forum and disabled the IPS but also this wont help (also after a few seconds the DNS Queries haven’t been responded). So I had to bypass the DNS by setting a fixed IP Address and setting the DNS Servers on my Client to Google ( and I also allowed the Traffic for this Client through the Firewall (because before I went through the Squid-Proxy). But it seems that not all services are working correctly on my client. but most of them.

Hi all,
same on my machine here. After Update von 164 everything looked okay initially. But after a few seconds tue web-gui stopped working. Now I am lost at the serial console of my ipfire- Box.
After stopping suricata from the console the web-gui ist accessible again.
Hopefully I can find which rules caused the trouble.
From the suricata log good candidates might be:
Because all of these are generated from 3 different computers in my local Network running 3 different OS.

1 Like


for all those who run into the same problems:

SSH (or via Serial Console as in my case) into the IPFire.

Call elinks (just enter it as command, function see here: Configure firewall rules / NAT from console (no more access to WUI after firewall rule created in WUI))). A kind of GUI appears. Call the firewall options and deactivate the option “Dropping any hostile traffic” (blog.ipfire.org - IPFire 2.27 - Core Update 164 released) which is recommended for release 164 and save it.

In addition, the IPS must be switched off completely (also via elinks). Please also uncheck Red, Green, Blue if necessary and save everything.

Then perform a reboot. Access to the WebGUI will work again, as well as the name resolution.

I have also tried after removing the option “Dropping” to enable the IPS again. Again, no name resolution occurs and the WebGUI is again inaccessible.

Apparently some rule is applied in the background that blocks access (GUI and name resolution).

I also have the following error message at boot time with IPS enabled. This does not appear with IPS disabled. Perhaps this will help narrow down the error:

Bildschirmaufnahme vom 2022-03-11 10:13:41

However, another error at boot always appears regardless if with or without IPS:

Greetings, Mike

The easiest way to turn off the IPS (until the next reboot) is:

/etc/init.d/suricata stop

Could those who are affected provide logs about what specifically is being blocked?

1 Like

I would like to help. Which logs to you need and where to find?


Thanks for the elinks hint.
With my Installation it was enough to disable the registered-malware-cnc.rules in the IDS settings to make the system fully operational again.

Please send /var/log/suricata/fast.log. This file will contain anything the IPS decided to drop.

So instead of a bug, this looks rather that someone pushed a bad ruleset which is now firing around.


That a huge one. more than 32mb.

Can I upload this or should I send it you in another way.

I tried that but disabling the mentioned rule and start IPS again resulted in the same problem (no access to WebGui and no names resolution).


Just gzip it and upload it here. It should be small enough then.

Here we go:

fast.log.tar.gz (1.2 MB)

1 Like

I had the best idea in the morning to update during work, UI died quite soon during the update, checked from terminal that reboot was required, reboots did not help.

Recovered from fresh backup ISO (finally got disaster recovery tested).

I have IPS in use also.

Meanwhile i wiped and reinstalled core update 163. thank’s to the team that there will be made a backup of the system just before any upgrade. that really helps.

Interesting that disabling the “registered-malware-cnc.ruled” did not help for all. Maybe there are multiple simultaneous errors with IPFire DNS handling and IDS rule set?

Meanwhile I dug a bit deeper into disabling individual rules. By unchecking only these rules in the “registered-malware-cnc.rules” set my system is still running:

“MALWARE-CNC FF-RAT outbound connection attempt” (there are 4 rules with exactly this name)
“MALWARE-CNC TRUFFLEHUNTER SFVRT-1045 attack attempt” (there are 3 rules with exactly this name)

As far as I found these are the only rules wich have multiple identical names. Maybe that causes the trouble?

EDIT: Sorry, I was a bit fast. After running several minutes, my web-GUI stopped again when only these few rules were disabled. Will continue to check…

I also ran into similar problems after updating to ver. 164.

However, I still had access to the webgui with some issues:

  • System->Home took took 4-5 minutes to load
  • Network->Domain Name System took 10 minutes+ (using UDP protocol) - and “Check DNS Server” never completed. *)

I still had internet access - but very slow. Some sites worked - others timed out.

The new Firewall function “Drop packets from and to hostile networks (listed at Spamhaus DROP, etc.)” not activated.

I was just about to restore to my 163 backup, but opening a SSH session to my IPFire I noticed that speedtest would time out.

I then looked at this community stream and first tried disabling all IPS rulesets.
But that made no difference.
I then disabled IPS and now speedtest worked and internet access were back to normal and the IPFire webgui had not delays.

I’ve had a look at my /var/log/suricata/fast.log file.
And it up until to point where I disabled IPS it looked “the same” as the file already uploaded here by Mike 175de

“Use ISP-assigned DNS servers” unchecked
ISP DNS servers added manually along with DNS’ at Google Public Free DNS, Lightning Wire Labs Germany and Censurfridns.dk

Perhaps the storm of IPS events could be related to: Bug 12794

Just to help finding the problem: I upgraded to 164 12 hours ago and I have no problems. I have activated Intrusion Prevention on RED and GREEN and set the ruleset to “Snort/VRT GPLv2 community ruleset”. Web GUI works fine, speed is very good.