Despite being currently busy with an IPFire 3 hackathon, we found the time to release the next Core Update for testing: IPFire 2.27 - Core Update 172. It comes with cryptography improvement for IPsec and OpenVPN, as well as security improvements under the hood, a plethora of package updates and various bugs fixed across the place.

Future-proofing VPN cryptography

This Core Update updates the key lengths of host certificates for both IPsec and OpenVPN clients/peers to 4,096 bit RSA, since the previous default of 2,048 bit is no longer recommended for long-term security purposes.

Both IPsec and OpenVPN root CA length has always been 4,096 bit, as has the key pair generated for IPFire's web interface - no action is required on that front. Unfortunately, existing IPsec/OpenVPN client/peer configurations cannot be migrated automatically, and have to be phased-out manually. Thanks to the respective CA certificates not requiring an update, complete disruptions of VPN infrastructure can, however, be avoided.

OpenVPN is automatically reconfigured to use a secure Diffie-Hellman parameter, both of sufficient length of 4,096 bit and standardized (see RFC 7919, section A.3, bug #12632). All OpenVPN clients and peers will automatically benefit from this cryptography improvement; no manual action is required. This also obsoletes the necessity of generating or uploading Diffie-Hellman parameters while configuring OpenVPN, saving a lot of time, as the generation of such parameters could have taken hours on slower hardware.

For early 2023, we anticipate post-quantum cryptography (PQC) to land in IPFire for IPsec, for which there is a strong (and growing) need, thanks to so-called "capture now, decrypt later" attacks endangering the confidentiality of information with long-term secrecy demand, such as biometric and health data.


  • IPFire's trust store has been updated to incorporate Mozilla's decision to distrust the root certificates of TrustCor Systems S. DE R.L.
  • Displaying the status and actions of add-ons whose service names differed from their package names is fixed (#12935). The same page has also seen some translation improvements.
  • Certificate Revocation Lists (CRLs) of OpenVPN are now properly backed up and reloaded before OpenVPN is (re-)started.
  • Adolf Belka submitted a massive patchset for updating Python.
  • Roberto Peña updated and improved the Spanish translation of IPFire's web interface.
  • Some unnecessary files from linux-firmware are no longer shipped and automatically removed from existing installations to keep the system as lean as possible.
  • Various file permissions have been tightened as a defense in-depth measure.
  • Obsolete gnu-netcat and powertop add-ons have been dropped.
  • Updated packages: arm-trusted-firmware 2.7, bash 5.2, bind 9.16.35, conntrack-tools 1.4.7, curl 7.86.0, elinks 0.15.1, ethtool 6.0, expat 2.5.0, iana-etc 20221107, intel-microcode 20221108, iproute2 6.0.0, libedit 20221030-3.1, libhtp 0.5.42, libloc 0.9.15, libnetfilter_conntrack 1.0.9, libpng , 1.6.39, libtasn1 4.19.0, libtiff 4.4.0, libuv 1.44.2, libxcrypt 4.4.33, libxml2 2.10.3, linux-firmware 20221109, lsof 4.96.4, memtest86+ 6.00, nano 7.0, OpenSSH 9.1p1, OpenSSL 1.1.1s, OpenVPN 2.5.8, poppler 22.11.0, python3 3.10.8, readline 8.2, sed 4.9, sqlite 3400000, strongswan 5.9.8, sudo 1.9.12p1, suricata 6.0.9, sysstat 12.7.1, tzdata 2022e, u-boot 2022.10, unbound 1.17.0, usbutils 015, vnstat 2.10, xz 5.2.8, zlib 1.2.13
  • Updated add-ons: cups-filters 1.28.16, ddrescue 1.26, dehydrated 0.7.1, fetchmail 6.4.34, ffmpeg 5.1.2, flac1.4.2, fmt 9.1.0, git 2.38.1, libassuan 2.5.5, libvirt 8.9.0, mpd 0.23.10, nginx 1.22.1, pcengines-apu-firmware, qemu 7.1.0, qemu-ga 7.1.0, rsync 3.2.7, samba 4.17.3, sdl2 2.26.0, Tor

As always, we thank all people contributing to this release in whatever shape and form. Please help testing this update, especially if you are using exotic hardware, uncommon network setups, or add-ons, and provide feedback - which is absolutely essential to us.

The IPFire Project has been fighting a legal battle against someone who plagiarised our work and sold it as their own. This post is a summary about a fight in front of courts of law over the last couple of years and the lessons learned from it.

Free Software Licenses

IPFire is free software. That means that we, the people who contribute to it, grant people the right to use, study, share, and modify our software free of charge. What we, however, do not give you, is to do whatever you want - that includes giving you copyright to our work.

Copyright law governs who possesses the rights to a piece of music, film, or software. It is there to protect the interests of those people who create works that are easy to copy like all kinds of digital data. Licenses like the GNU General Public License grants exceptions like those outlined above.

In this particular case, someone has violated our software licenses as well as the law of the country by taking IPFire, rebranding it and selling it as their own product of which they hold all rights.

Collectively we spent a lot of time to decide whether and what we are going to do against it and we have come to the conclusion that there would be no need for software licenses unless we enforce them. Not to mention, there was of course a lot of anger that something we are working on so passionately every single day, has been taken away from us for the financial benefit of someone else.

What has happened? An IT company has set up a website with their own brand-new firewall that was written "from scratch" - I am not going to say who, because it does not matter for this story. Someone who purchased the plagiarised version from IPFire has contacted us because he recognised that "under the hood" IPFire was running. He asked us for support, because why get support from someone else when you can have the people who know it best?

You can imagine how surprised I was to find out all these details and how similar the feature set that was that was promoted on the website. Coincidence? No, not really. Writing a firewall like IPFire is not a small job. It will take a lot of experience and a lot of time from many people which clearly were not available in that organisation. The market is also very small and IPFire has quite a unique feature set and uses certain words for them - products of competitors might have the same feature, but call it something slightly different. These things usually give it away.

But to not bore you with a long story that you will have figured out already. The police confiscated the firewall that was purchased by this customer and a brief "forensic analysis" resulted in that it was indeed IPFire with a slightly changed design for the web user interface. Mainly the IPFire logo was replaced with the company logo, but they didn't even bother to change any colours. Therefore it was not a derivative product, but just a copy which still used our servers to download packages and updates.

The owner of this company was charged with copyright infringement (among other things) and a long legal process started that was unfortunately prolonged a lot by the pandemic. In a police statement, they have said that they do not believe at all that they have been doing anything wrong at all, and that IPFire was free to download on the internet. So what would stop them from doing what they were doing?

The answer is very simple:

Us, the Open Source Community

We know from conversations with other software projects, that this sadly is common practise. Many free software developers can tell stories about their software licenses infringed at some point. There are various license models ranging from "take my code, I do not care" to more restrictive licenses like the GPL, which requires that you will have to pass your software on under the same terms. To make that obvious for any end-users, you will have to give them a copy of the license and upon request the entire source code. This was of course denied to the customer, because that would have proven what they actually bought and paid a lot of money for.

I will again spare you the details of defamation and angry emails that we have been receiving from the person on trial. As things like this go, there was a lot of coercion, pressure and ugly words. There were lots of exceptional circumstances around this particular case which is why it ended up in front of a criminal court.

In the end, the owner of the company was sentenced and now has a criminal record. They also have to pay a fine as well as the procedural costs. Since this was a criminal case, neither the IPFire Project, nor anybody else involved has received any compensation for their time and their effort that they have spent.

What did we gain now? We have spent weeks of our own time putting together information that prosecution required. We have been internally debating this, got expertise from outsiders and have built a strategy. I am deeply disappointed that we had to spend so much time on this, when we could have invested that into development instead because of one player who is not following the rules. Instead of not only not supporting our project, they have actively damaged it. We know for a fact, that this is not the only case where someone is selling IPFire as their own software - without giving a penny back to the project. This is so damaging and incredibly disappointing.

The reason why I am telling you this whole story is, that we had the chance to bring this to court which we know has not been as easy for other software projects. Various organisations (e.g. The GPL Violations Project) have been trying to get free software licenses tested in a court of law and we had a unique opportunity and are happy that we could seize it.

I would like to use this post as a warning to everybody else who is taking advantage of IPFire or any other software project like ours. You are actively destroying the Open Source Community that you are at the same time abusing to run your business. You, your business and your customers rely on the software that you are stealing, and you rely on the maintainers to keep maintaining it. You make the whole free software ecosystem less sustainable. So many projects are underfunded and struggling due to this inacceptable behaviour.

But this does not mean that you cannot use IPFire commercially at all - the opposite is true. In fact, we want to work together with businesses who can help others to secure their business with a firewall. We want you to install IPFire at your customers' offices, data centers and everywhere else it fits. We build this software to be used, but...

We Need You To Give Back

If you have customers that can afford it, please donate. If you have customers that really do not care about money, have them donate even more. Get in touch if your organisation cannot donate for whatever reason. We have a massive backlog of things that we need to tackle, and this is the only way.

Report bugs back to us. We need to have feedback on how we are doing. Sometimes things break, but we wouldn't know. Help us test new releases, test new features and help us to make IPFire the best firewall that is out there. Your customers will all benefit from it and appreciate it, too.

Explain how you are using open source technology in your company. It is a miracle to me how their customers believe that a one-man IT company is building all these things that they have stolen on their own - it is absolute bollocks. Instead you will create more trust with your customers when you say: "We are using IPFire, which is a well-known product out there and we are well trained on it and experts who are ready to set it up in your business". And if there is a problem that you cannot solve on your own, it is good to work closely together with the developers.

If we are all going this way together, we will make the open source community stronger.

We make IPFire better and we make it possible for everyone to use it. We enable everyone in the world to secure their networks and contribute to make the Internet a nicer place to be. For that to become reality, we all need to contribute as much as we can. For some this is more, for some this is less. But that doesn't matter. If everyone supports their favourite free software projects as much as they can, we should easily achieve the required funding to take them all to the next level. And if you decide to not play on our side, rest assured that playing by the rules is way more affordable than a court trial.

Once again, if you can, please donate to the IPFire Project. If you are a business and you cannot donate, purchase an IPFire Open Source License from Lightning Wire Labs which will benefit the project just as well. It is very much appreciated by all of us here.

Today, we release IPFire 2.27 - Core Update 171. It updates major parts of the distribution, such as the kernel and the IPS engine, and features bug fixes as well as stability and security improvements - most notably, upstream fixes against a strain of vulnerabilities in the kernel's WiFi components. Particularly IPFire users running WiFi networking hardware are advised to install this update as soon as possible, and reboot their systems afterwards.

Also, this Core Update initiates the deprecation of IPFire support for 32-bit ARM hardware, ultimately taking effect on February 28, 2023.

Modernizing system components

Several core parts of IPFire have been updated and modernized:

  • Suricata has been updated to the 6.x versioning branch, after a show-stopping issue (#12548) has been resolved upstream. IPFire users will benefit from more stable, secure, and versatile IPS functionality.
  • The Linux kernel has been updated to 5.15.71, providing IPFire users with hardware support improvements and security fixes.
    • Most notably, it resolves issues affecting ASIX USB3-to-LAN adapters using the ax88179-178a driver.
    • Upstream patches for fixing CVE-2022-41674 and CVE-2022-42719 to CVE-2022-42722 have been incorporated, plugging several security vulnerabilities in the kernel's WiFi components that could have lead to RCE and DoS attacks, simply by emitting crafted WiFi beacons.
    • To cut attack surface, some debugging functionalities have been removed, for which there is no legitimate use-case on an IPFire machine.
    • ARM installations will experience a security benefit thanks to seccomp support enabled. Doing so previously caused issues on some boards, hence it was enabled on x86 only.
    • Mathew McBride submitted patches to add support for the 64-bit ARM Traverse Ten64 board family.

Sunsetting 32-bit ARM support

Back in the glory days, the IPFire development team was optimistic about ARM becoming an affordable yet powerful alternative to the x86 architecture. Support was added in IPFire 2.11, 13 years ago. Soon, we finally would see some diversification among the hardware landscape, forcing competition and ultimately better products - or so we hoped.

Disappointment kicked in just two years later, when we realized hardware vendors were just dumping new SoCs on the marked without caring about proper operating system support at all. Existing boards disappeared quicker than the kernel developers could reverse engineer them and implement drivers. Very few of these boards actually met IPFire's demands, such as having at least two properly connected NICs.

Things did not improve afterwards, as we had to assess that there was no innovation on the market, and given the hardware specifications of the vast majority of 32-bit ARM boards, the architecture quickly became very much a legacy burden to us. Maintaining our own ARM kernel patchset started to eat into the spare time of IPFire's developers, while the amount of IPFire installations actually running on ARM never exceeded 10%. At some point, we decided not to support any additional SoCs without proper mainline kernel drivers, to prevent the situation from escalating to a DDoS against the people behind IPFire.

Today, despite significant efforts on our part, we are left with a patchy list of ARM boards supported, scanty upstream support (much like 32-bit x86), and a general disinterest in this architecture. Unsurprisingly, at the time of writing, only 0.86% of all IPFire installations out there run on 32-bit ARM.

Due to all these reasons, we decided to discontinue IPFire support for 32-bit ARM on February 28, 2023. Users are recommended to replace their hardware; after that date, IPFire won't provide updates for this architecture anymore.

64-bit ARM board support will continue, and while it is not a mainstream architecture to us (backing only 1.25% of all IPFire installations), supporting it is much less of a hassle, thanks to better upstream development and big server vendors and cloud providers rapidly shifting to 64-bit ARM. As to be expected, the boards available are much more powerful and suitable for firewalling purposes as well. We hope our decision will gain us resources to focus on more important work, such as the development of IPFire 3.


  • Perl, all its modules and related packages were updated to 5.36.0, resolving functional and security issues.
  • The toolchain, comprising of glibc, binutils and more, was modernized as well.
  • linux-firmware, the conglomerate of proprietary 3rd-party firmware files, has been updated as well. By removing some firmware files related to unsupported hardware, especially Bluetooth devices, we save a couple of megabytes.
  • Creating full-ISO backups is now possible again, resolving #12932.
  • libsodium is now shipped with the core system, required as a dependency to some add-ons (#12929).
  • Faulty links to IP blocklist source websites have been fixed (#12938).
  • Orphaned RRD graphs are now cleaned automatically on a weekly basis, saving disk space.
  • NUT logs can now be viewed in the web interface (#12921).
  • Connections to literal IPv6 addresses no longer crash IPFires' proxy (#12826).
  • IPFire's default domain is now used for DHCP leases where no domain can be determined, rather than defaulting to localdomain.
  • Updated packages: bind 9.16.33, binutils 2.39, curl 7.84.0, dhcp 4.4.3-P1, efibootmgr 18, efivar 38, expat 2.4.9, glibc 2.36, iproute2 5.19.0, kbd 2.5.1, libarchive 3.6.1, libhtp 0.5.41, linux-firmware 20220913, nettle 3.8.1, OpenVPN 2.5.7, Perl 5.36.0, sqlite 3390200, Squid 5.7, strongSwan 5.9.7, Suricata 6.0.8, udev 3.2.11, Unbound 1.16.3, util-linux 2.38.1, wireless-regdb 2022-08-12
  • Updated add-ons: elfutils 0.187, fetchmail 6.4.32, hplip 3.22.6, lcdproc 0e2ce9b, ncat 7.92, rsync 2.3.6, Tor

As always, we thank all people contributing to this release in whatever shape and form. Please note IPFire is backed by volunteers, maintaining and improving this distribution in their spare time - should you like what we are doing, please donate to keep the lights on, an consider becoming engaged in development to distribute the load over more shoulders.