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.
@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.
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:
Makes me sayā¦ Not time for IPFire, today (2020). And i am sorry for that
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.
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.
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.
unbound on core 142 also stopped dhcp. I noticed it only when a newly started PC failed to get an address.
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.
dhcp server and client are not changed in core142
didnāt have such problems on a LWL mini Appliance Suricata on for red, green and openvpn with 14 ECR Rules activeted. DoT. Provider Telekom.
there is a problem on really slow connections. I had this on a 4MB DSL Line at my parents and also if i connect an IPFire via Mobile Phone.
But increasing the flood protection trigger in suricata.yaml from 512 to 2048 will help on both installations.
I do have a very slow DSL ~ 5 Mb/s down, 900kb/s up, most times. I could pay for the next step up in plan, but have no reliable information of whether it would be much faster in practice. Iāll adjust suricata.
I have also been using Recursor Mode, as suggested recently in this forum. The DHCP issue occurred while DNS was in TCP mode. I have switched between UDP & TCP mode, but each switch restarts unbound and makes it difficult to ascertain any difference in reliability
You should always be on the latest version. There is literally no excuse to run one of more behind. Essential security updates are in each and every release and you should protect yourself against it.
If there are any bugs, please report them to the bug tracker. I often get emails when someone has mentioned something that doesnāt look ride in a side note in the 17th post on a long thread. Nobody has time to read through all this here and read peopleās minds. We have a bug tracker. It tracks bugs. That is the important thing about.
You wonāt get that in IPFire.
What was problematic? There are thousands of changes in each release. How is anyone of the development team supposed to guess which one could have introduced a regression?
But you are clearly doing it. You have been complaining about ālack of featuresā a couple of times, and complaining wonāt get you anything. It just brings down morale.
What else do you want? That is how updates work. IPFire is a big operating system. Do you literally want to walk through a list with tens of thousands of patches and only pick the ones that you like? Luck for you, you can do it. IPFire is Open Source.
I am not aware that an update has broken production anywhere recently. Our updates are better than ever. Very few bugs are filed after a release and those are mostly non-critical issues.
If we do not know about something, or do not have enough data, we wonāt be able to fix it.
What is the bug ID where this was reported?
That was sarcasm because as far as I know there was no release.
Sarcasm really doesnāt work when it is written 
I have my desktip PC on fixed IP (not fixed lease) and noticed this bug on an infrequently used PC. I have not attempted to duplicate the condition and thus did not lodge a bug report.
Core 142 was running on Banana Pi and did have minimal IDS activated.
I donāt āwantā anything that something that works a bit better than Ipfire since Update 139.
Plenty of issues with DNS, unbound, DNSSEC, DoH.
I wish to have something that will allow me to tell to my customer āhey, if you want you can signup a better ISP without stopping operationsā, and manage it through remote support. The customer has only to tell to ISP guy āplease, set this IP Address and connect cable hereā. Then a change of external DNS can be rolled out without stopping the published services even for a minute. Without going on premises. This cannot be achieved with IPFire, currently.
Also, i cannot choose ipfire for having a backup connectivity with cheap USB LTE devices. No Multiwan allowed, currently
The last incorrect thing of this statement is that āi can cherry pick because itās GPLā. As far as i can understand, thatās not completely true. At least, as sysadmin perspective.
For cherry picking anything the first thing i should do is instruct my installation to accept .pakfire packages signed from another source. Then i should browse to the source and create a āFirecustomā version with something thatās not gonna break at the next update, chopping of the changes.
Occamās Razor: do the simplest thing.
I am not a developer, I cannot repair or implement things lacking. Then i change the thing that currently doesnāt work with something that currently works.
I am not fool enough to pretend that the project has features that are not. If telling the truth and state the facts is complaining, what should be the name for calling the project useless and the developers too proud or deaf to listen to the community about problems and needs? (Iād like to point out that I am not thinking nor telling that).
A 200 euros box cannot do the same things that IPFire can do, but can provide multiple WAN connections with rules about load balancing, can be used with mobile adapters as backup, supports IPv6, and as far as I know into Germany IPv6 is quite pervasiveā¦ neverthelessā¦ i donāt know, can a firm subscribe a contract only with IPv4 public static address currently?
IPFire is far more powerful than that boxes, but today is not advisable to use it into this not-so-uncommon user cases. Tomorrow could not be even a option for a long list, not the short-one.
First for the lacking features, second because i cannot update it without being afraid that it will stuck or explode. That happened twice into ESX 6.5, the second one the āpoor man cold spareā of another machine, with another project installed, was raised and after two years of update untill today without keeps running without any issue. Today that customer doesnāt want to listen anything about IpFire.
(by the way, i already know that virtual hardware itās not your favorite flavor for install, but sometimes stream of the demands cannot be changed)
This brings down morale? Iām sorry, but i cannot make calls for development, only remind to development team why i cannot stand by IPFire into my next customerās choice.
As I said, we have fixed all problems that were reported.
It might not come as a surprise to you that I am using IPFire in my office and it is working absolutely fine without any problems for me. If there would be a problem, I would fix it of course.
We do not even support DoH, so I have no idea where your issues are with that then.
No, but that is because this was not designed into it. Nobody needs it.
There is no solution that you take out of the box and just plug in power. You can do that with a cheap plastic router, but do not expect a secure network as the end result.
Allowed? Fallback to LTE is supported. That is not the same as āMultiWANā.
No, of course we wonāt allow your packages to be installed on our distribution. We peer-review every change, we have secure processes to make sure that nobody can put any malware into our packages. That of course does not work with any third-party sources.
But it is free to you to create your own keys to sign your packages and so on. All our code is free for you to change.
I can absolutely not recommend for you to start your own fork, because you have to be an expert on everything. Building and maintaining IPFire is really really hard work.
All those people who contribute to IPFire spend a lot of time to make it better. Every day. That is why I am kicking out here right now, because that hard work deserves recognition. I am quite sure that you will appreciate everyone to give their best and sometimes, there are bugs. Then we analyse what went wrong, find a solution and everyone has learnt.
This statement is clearly hurtful and unnecessary.
If you think that the developers and other people in the community do not care, you are clearly wrong. We might just care about different aspects than you. That is why this is an open community where everyone can contribute what is important for them.
As a simple example: I do not care whether IPFire supports DSL or not. I do not have a DSL connection. I do not need it, I cannot test it. But that does not mean that other people have added this and many people use it every day.
Why do you simply not go for that then?
You can trust me that we all know that we do not support IPv6 right now. We have noticed. We actually do have a very good IPv6 stack in IPFire 3, but instead of working on that, I am now typing these words.
Well, if this is all the case, I can only assume that you expect other people to do your work for you.
If you are really running a virtual environment, it takes you two clicks to make a snapshot to which you can return to at any time. An upgrade is absolutely non-dangerous for you. It is more difficult to restore a snapshot on hardware obviously.
That is cool. I do not care about your customers. They might be in that small percentage for which IPFire isnāt right. For 95% of the people IPFire works really well. Others might have requirements that we cannot meet. That is cool though.
You are getting an excellent distribution for free. You and even your customers should appreciate that. But I assume that you are charging them generously for your services.
Maybe IPFire simply isnāt right for you. Our development model clearly isnāt. You will have to take some action here. It is as simple as that. But complaining about other people not doing your job cannot seriously be what you are suggesting.
Hello Pike_it and Michael,
perhaps we should work together to move forward instead of arguing.
Ipfire may not cover every requirement 100%, but it works reliably and well for most people.
If thatās not enough, you can use one of the many other products on the market. But to find one that can do everything will be impossible.
In these times we wish for good health instead of quarrelling about small things.
