Blog - IPFire 2.25 - Core Update 142 released

roberto · 26 March 2020 08:01

Hi.

Only have this activate:

 - whitelist.rules
 - emerging-worm.rules
 - emerging-inappropriate.rules
 - emerging-attack_response.rules
 - emerging-current_events.rules
 - tor.rules
 - emerging-misc.rules
 - emerging-mobile_malware.rules
 - botcc.portgrouped.rules
 - drop.rules
 - compromised.rules
 - dshield.rules
 - emerging-dos.rules
 - emerging-p2p.rules
 - emerging-exploit.rules
 - ciarmy.rules
 - emerging-trojan.rules
 - botcc.rules
 - emerging-malware.rules

I have tried to activate Suricata with the Green interface and it works correctly. It only fails when the Red interface is activated.

anon46344254 · 26 March 2020 08:20

i’m in the same situation of @roberto
i don’t think this is the culprit, until two weeks ago never haver had a problem with dns system
and the rules were the same from the beginning of IPS in ipfire.

I noticed that the problem has not appeared again when our IPS gave us form 10 down - 4 up,
20 down - 15 up last week. Maybe when the upload speed is slow IPS is too aggressive?

Let’s hear a comment from the dev.

PS: there is always the problem that i can’t see or login to people.ipfire.org, community.ipfire.org and blog.ipfire.org unless i use brave browser tor inprivate session in the PC, tried with my ISP with two different machine, same thing via VPN. Via cell phone no problem so far.

UT1

arne_f · 26 March 2020 09:20

We have changed the starting order because suricata sometime not got the dns based rules working or block the dns at reconnect.

Unbound does a lot dns request at start to got the rootzones and validate the keys.Im not sure how large the queue must be.

roberto · 26 March 2020 09:26

I have partially solved the problem. I have had to configure the Protocol for DNS queries in TLS and so it does work with Suricata activated.

In UDP mode no works.

Regards.

anon46344254 · 26 March 2020 09:28

@arne_f.
ok thanks for the answer, i was just guessing. Again, if there is some log or whatever we can do to make you and ipfire dev team to understand better the situation, just ask. in my little knoledge of linux and ipfire i will try to give info you may need.

regards

UT1

arne_f · 26 March 2020 09:31

We have not found a way to get logs from the suricata’s dns part yet. This simply doesn’t log anything…

anon46344254 · 26 March 2020 09:38

ok. thanks

UT1

anon46344254 · 26 March 2020 09:39

Hy @roberto, could you explain better how you managed the problem?

roberto · 26 March 2020 09:54

The only way to have Suricata and Unbound working has been to configure it in TLS mode. Putting the DNS of Google and in TLS Hostname, putting “dns.google”.

I also have little knowledge of Linux and I have been looking at forums and all that without getting anything. The only thing, configure it as TLS.

Have you tried it?.

Greetings.

anon46344254 · 26 March 2020 10:06

i’m on tls too, i always been in fact, with or without dns not working.
Thanks for the reply @roberto

guebert · 30 March 2020 11:34

Hallo!

I’m still on 141 and unsure, wether it’s safe to update or not. Can somebody provide a summary of this topic, under which circumstances 142 should not be used?

(BTW, because of such things, I wait some days and search the forum before updating … unfortunately it seems, that even problematic updates are never drawn back …)

Michael

hellfire · 30 March 2020 20:27

That’s the reason why I’m still on core 139.

Reports on that forum talk about broken DNS and some issues with IPS rulesets, hence I’m still waiting for some more days.

What’s more important to me, currently I’m stuck in my home office so I cannot afford a breakdown of the internet connection.

rodneyp · 30 March 2020 20:52

@roberto you might be masking another factor. Changing any parameter on the Domain Name System page causes unbound to restart. It is the latter that gets DNS working for me, whether by changing the parameters or via CLI stop/start.

pike_it · 30 March 2020 21:12

FWIW my opinion… that’s the third time in a row (140, 141, 142) that a lot of problems are appearing into IPFire Community.
So this minus, added to:

Lacking of MultiWAN
Lacking of IPv6
Lacking of configuration management (i can only backup and restore)

Makes me say… Not time for IPFire, today (2020). And i am sorry for that

xperimental · 30 March 2020 21:51

Exspecially Core update 140 was really problematic!!!

But I agree… it’s the first time I’ve encountered multiple bugs in ipfire. Never had problems before.

pike_it · 31 March 2020 10:53

Don’t get me wrong, no anger or disrespect on what the developers are doing.
But facts and experiences are… visible and countable. Therefore for the current year all projects won’t rely on IPFire, but on other products.
I do not want that an update (which is monolithic and i have no chance to cherry pick every single change) can break a starting project/site, which seems to be happening too often in recent months. On the parallel lane, if the infrastructure allows me, i will realize side machines for not-so-cold spare in case of update breakup by IPFire.

arne_f · 31 March 2020 11:57

For me it looks more like a suricata bugs that drops dns queries without logging it and ignore configuration reloads at reconnect and such things.
With core139 some suricata dns features was simply not working at all. Now it works but not in some configurations like slow red connections.

rodneyp · 1 April 2020 02:31

unbound on core 142 also stopped dhcp. I noticed it only when a newly started PC failed to get an address.

bbitsch · 1 April 2020 08:41

FYI: I didn’t notice such problems. My system is a “standard” installation on a small system without suricata. Thus Arne’s opinion may be right.

arne_f · 2 April 2020 13:30

dhcp server and client are not changed in core142

https://git.ipfire.org/?p=ipfire-2.x.git;a=tree;f=config/rootfiles/core/142/filelists;h=42544ae2cf1913db9a2c83bb50892cd9a1ee5517;hb=70af65df4198c58f99a333748faa39b39ad1c3c4