n00b Unlimited - Ipfire https://n00bunlimited.net/ News Taken from the IPfire blog en Wed, 12 Aug 2026 10:54:33 GMT vBulletin 60 https://n00bunlimited.net/images/misc/rss.png n00b Unlimited - Ipfire https://n00bunlimited.net/ IPFire 2.29 - Core Update 203 released https://n00bunlimited.net/home/forum/site-news/ipfire/80491-ipfire-2-29-core-update-203-released Mon, 20 Jul 2026 09:00:48 GMT
This is the release announcement for IPFire 2.29 – Core Update 203, which is now available.

This is a substantial update, and its centrepiece is a fundamental change to how IPFire handles DNS: we have replaced Unbound with Knot Resolver, giving us a more flexible foundation and a range of new capabilities, from a DNS Firewall to encrypted upstream forwarding. Alongside it, the WiFi access point gains support for the 6 GHz band, and there are the usual security fixes and package updates throughout. These changes reach into a core part of the system, and we're grateful to everyone who helped test the release candidate over the past weeks and reported back.

DNS: Moving from Unbound to Knot Resolver

With this release, IPFire replaces its DNS Resolver with Knot Resolver.

This is a significant change under the hood, and not one we made lightly. Unbound has served IPFire well for many years and remains an excellent resolver. But DNS has quietly become one of the most important parts of the modern network. It is no longer only about turning names into addresses — it increasingly carries the information other protocols rely on to connect quickly, securely and privately, from encrypted transport to the records clients use to establish encrypted connections. To keep building on top of DNS, we needed a resolver we can extend and integrate deeply with the rest of IPFire. Knot Resolver's modular, scriptable architecture gives us exactly that foundation.

What this brings you today:
  • Encrypted upstream forwarding (DNS over TLS) — queries to your chosen upstream resolvers can now be sent over TLS, so they can't be read or tampered with in transit.
  • DNS Firewall — block malware, advertising and whole categories of unwanted domains at the DNS layer.
  • Encrypted zone data (over TLS) — the DNS Firewall's filtering and policy zones are now pulled over an encrypted connection by zone-sync, a new tool we built in C. Updates are transferred incrementally and can no longer be read or tampered with in transit.
  • SafeSearch — enforce safe search across the major search engines and YouTube for your whole network.
  • Conditional forwarding — send queries for specific zones to specific servers. (Note the change below.)
  • Local overrides — define your own DNS records for local hostnames.
  • DHCP integration — a custom module makes hostnames from DHCP leases resolvable in DNS, replacing the old Unbound DHCP Leases Bridge with no loss of function.

Under the hood:
  • Persistent Cache — the cache now survives restarts, so resolution stays fast after a reboot and there's less load on upstream servers.
  • Shared state across multiple workers — Knot Resolver uses several worker processes that share one cache and state, making efficient use of multiple CPU cores without fragmenting the cache.

Please note: Forwarded zones can no longer be specified as fully-qualified domain names. You now need to replace any entries on the DNS Forwarding page that use FQDNs with IP addresses.

A note on what went into this release: replacing the DNS resolver was far from a drop-in swap. Alongside integrating Knot Resolver itself, we wrote a good deal of new code — including custom modules for DHCP and filtering, and zone-sync, a tool we built in C to keep the DNS Firewall's data current over an encrypted connection.

WiFi: Support for the 6 GHz Band

The IPFire WiFi access point now supports the 6 GHz band, opening up the spectrum introduced with WiFi 6E and WiFi 7.

Why this matters:
  • More room, less interference — the 6 GHz band is new and largely empty. Without decades of legacy devices crowding it, wireless clients get cleaner airtime and more stable connections, even in busy neighbourhoods.
  • Wider channels, higher throughput — the additional spectrum leaves room for many more wide (80 and 160 MHz) channels, so you can run faster connections without them overlapping and interfering with one another.
  • No radar detection, no interruptions — unlike parts of the 5 GHz band, the 6 GHz band does not require radar detection (DFS). The access point starts up immediately and can never be forced off its channel by a radar event, so there are no sudden dropouts.

We have also fixed a bug that prevented the access point from starting when a 40 MHz channel width was combined with a manually selected channel.

Misc.

  • AWS: IPFire can now retrieve EC2 instance metadata using IMDSv2, the token-based and more secure version of the metadata service that AWS now recommends and increasingly enforces by default. This means IPFire runs correctly on instances configured to require IMDSv2, while IMDSv1 remains supported for existing deployments.
  • The microcode for some Intel processors has been updated to version 20260512 to address a vulnerability filed as INTEL-SA-01420
  • A bug with Perl failing to properly encode/decode UTF-8 strings has been fixed so that the web UI will show translations with non-ASCII characters properly again
  • OpenVPN: The icon to download the configuration has been replaced by a clearer version; and for Roadwarrior clients with a static IP address allocation, the name of the subnet is now shown next to the connection.
  • sysklogd will now listen on localhost again, which is useful for chrooted processes that want to log messages
  • Updated packages: BIND 9.20.23, Boost 1.90.0, coreutils 9.11, btrfs-progs 7.0, e2fsprogs 1.47.4, elfutils 0.195, expat 2.8.1, fcron 3.4.1, fontconfig 2.18.1, gdb 17.2, gnupg 2.5.20, GRUB 2.14, grub-btrfs 4.14, iana-etc 20260511, krb5 1.22.2, less 702, libedit 20260512-3.1, libksba 1.8.0, libloc 0.9.19, libunistring 1.4.2, libusb 1.0.30, LuaJIT 2.1.707c12b, LVM2 2.03.41, meson 1.11.1, nettle 4.0, OpenVPN 2.7.4, rrdtool 1.10.3, SQLite 3.53.1, strongswan 6.0.7 (CVE-2026-47895), Suricata 8.0.6, util-linux 2.42, vim 9.2.0526, which 2.25, xfsprogs 7.0.1, zone-sync 0.0.2

Add-Ons

  • Updated packages: dnsdist 2.0.6, ntfs-3g 2026.2.25, Postfix 3.11.3, rsync 3.4.3, samba 4.24.2, spice 0.16.0, spice-protocol 0.14.5, tmux 3.6b, tshark 4.6.6
  • Zabbix Agent: Fixes for OpenVPN 2.7 status parsing and ping error handling have been applied

Thank You

Core Update 203 reaches into one of the most fundamental parts of the system, and getting there took months of work: rebuilding DNS resolution from the ground up, writing new tooling like zone-sync, and testing all of it against real-world traffic. We're especially grateful to everyone who ran the release candidate, filed bugs, and helped us catch issues before they reached the wider community.

Work like this is slow, detailed and largely invisible, and it is only possible because IPFire is supported by the people who rely on it. If this release is useful to you, please consider making a donation — it is what lets us keep building.

Thank you for using IPFire.


More...]]> Ipfire siosios https://n00bunlimited.net/home/forum/site-news/ipfire/80491-ipfire-2-29-core-update-203-released <![CDATA[From Days to Hours: IPFire's RISC-V Builds Get a Real Machine]]> https://n00bunlimited.net/home/forum/site-news/ipfire/80489-from-days-to-hours-ipfire-s-risc-v-builds-get-a-real-machine Thu, 16 Jul 2026 09:30:13 GMT Building IPFire 2 can be painful. The build system requires that large parts of the distribution are built from scratch each time we run a build....
Building IPFire 2 can be painful. The build system requires that large parts of the distribution are built from scratch each time we run a build. Usually that takes a couple of hours, but for one architecture, it has been taking days. What we call a Nightly Build has actually been taking more than a whole weekend; we needed to get it back down to something that could finish overnight.

If you have been following the IPFire development team for some time, you know that we are quite keen to make IPFire run on any kind of suitable hardware. We have been early adopters for ARM - back in the day when 32 bit ARM was very painful - and we ported IPFire to RISC-V a couple of years ago, too. However, we didn't have any suitable hardware to build it as it wasn't available at all at the time, so we had to fall back on an emulated build inside our infrastructure. Every command that is being called will have to be interpreted just-in-time from the riscv64 instruction set and converted into runnable x86 code. This is a process that is extremely slow; so slow that day-to-day development is virtually impossible for RISC-V.

Ending The Emulation Bottleneck

This didn't bother us too much at first - RISC-V is still a second-class citizen in IPFire and we are early to the party. But to move it forward, we needed to get rid of the emulation bottleneck.

Some months ago, we pre-ordered a Milk-V Jupiter 2 which has finally arrived.

Previous experiences with early-bird ARM hardware have not been great. Lack of support in the Linux kernel, stability issues and a small community have resulted in lots of products being shelved. With RISC-V and Jupiter 2 it seems to be the exact opposite. We chose from a couple of distributions, used a custom kernel from SpacemiT, and had the whole thing set up very quickly.



The Rough Edges

Some caveats had to be sorted though: There are some outstanding issues with the power management of the device and support for the NVMe SSD that we added is not too stable yet. The biggest issue however is that the device generates a lot of heat - even when it is idle. Idling at 74°C, the board climbed past 85°C within minutes of starting a build, which required us to improve the cooling a little. Hopefully the power management will improve soon so that we can operate the system at a more sustainable temperature soon.

The Result

Despite these smaller issues, our Milk-V Jupiter 2 has now been added to our build system for IPFire 2 and it has started to compile the nightly builds. The build time is down from a whopping 54-56 hours in the emulated setup to only seven hours.

This is a huge step forward for us to actually work on the RISC-V ecosystem and only the start. As more RISC-V hardware is becoming available and as it matures, we intend to put more resources behind it. We want more choice, a real alternative from x86, and we are hoping to see very small, yet very powerful IPFire systems on RISC-V over the next couple of years.

Where We Go From Here

We see vast potential in RISC-V as a target architecture and we believe that now is the time to invest in it. Let's iron out the gaps in hardware support, build out the IPFire to take advantage of the features of the hardware, and get it to a viable, production-ready alternative to ARM and x86.

When will it be ready? We don't know, yet. But the only way to find out is to start now. So join us and contribute. Help us test and send us feedback.


More...]]> Ipfire siosios https://n00bunlimited.net/home/forum/site-news/ipfire/80489-from-days-to-hours-ipfire-s-risc-v-builds-get-a-real-machine IPFire 2.29 - Core Update 203 is available for testing https://n00bunlimited.net/home/forum/site-news/ipfire/80483-ipfire-2-29-core-update-203-is-available-for-testing Wed, 10 Jun 2026 09:40:21 GMT
This is the release announcement for IPFire 2.29 – Core Update 203, which is now available for testing.

This is a substantial update, and its centrepiece is a fundamental change to how IPFire handles DNS: we have replaced Unbound with Knot Resolver, giving us a more flexible foundation and a range of new capabilities, from a DNS Firewall to encrypted upstream forwarding. Alongside it, the WiFi access point gains support for the 6 GHz band, and there are the usual security fixes and package updates throughout. Because these changes reach into a core part of the system, we would especially value your help in testing this release before it reaches everyone.

DNS: Moving from Unbound to Knot Resolver

With this release, IPFire replaces its DNS Resolver with Knot Resolver.

This is a significant change under the hood, and not one we made lightly. Unbound has served IPFire well for many years and remains an excellent resolver. But DNS has quietly become one of the most important parts of the modern network. It is no longer only about turning names into addresses — it increasingly carries the information other protocols rely on to connect quickly, securely and privately, from encrypted transport to the records clients use to establish encrypted connections. To keep building on top of DNS, we needed a resolver we can extend and integrate deeply with the rest of IPFire. Knot Resolver's modular, scriptable architecture gives us exactly that foundation.

What this brings you today:
  • Encrypted upstream forwarding (DNS over TLS) — queries to your chosen upstream resolvers can now be sent over TLS, so they can't be read or tampered with in transit.
  • DNS Firewall — block malware, advertising and whole categories of unwanted domains at the DNS layer.
  • Encrypted zone data (over TLS) — the DNS Firewall's filtering and policy zones are now pulled over an encrypted connection by zone-sync, a new tool we built in C. Updates are transferred incrementally and can no longer be read or tampered with in transit.
  • SafeSearch — enforce safe search across the major search engines and YouTube for your whole network.
  • Conditional forwarding — send queries for specific zones to specific servers. (Note the change below.)
  • Local overrides — define your own DNS records for local hostnames.
  • DHCP integration — a custom module makes hostnames from DHCP leases resolvable in DNS, replacing the old Unbound DHCP Leases Bridge with no loss of function.

Under the hood:
  • Persistent Cache — the cache now survives restarts, so resolution stays fast after a reboot and there's less load on upstream servers.
  • Shared state across multiple workers — Knot Resolver uses several worker processes that share one cache and state, making efficient use of multiple CPU cores without fragmenting the cache.

Please note:

Forwarded zones can no longer be specified as fully-qualified domain names. You now need to replace any entries on the DNS Forwarding page that use FQDNs with IP addresses.

A note on what went into this release: Replacing the DNS resolver is a large piece of work we have undertaken, and it was far from a drop-in replacement. Alongside integrating Knot Resolver itself, we wrote a good deal of new code — including custom modules for DHCP and filtering, and zone-sync, a tool we built in C to keep the DNS Firewall's data current over an encrypted connection. Work like this is slow, detailed and largely invisible, and it is only possible because IPFire is supported by the people who rely on it. If this release is useful to you and you would like to see more of it, please consider making a donation — it is what lets us keep building.

WiFi: Support for the 6 GHz Band

The IPFire WiFi access point now supports the 6 GHz band, opening up the spectrum introduced with WiFi 6E and WiFi 7.

Why this matters:
  • More room, less interference — the 6 GHz band is new and largely empty. Without decades of legacy devices crowding it, wireless clients get cleaner airtime and more stable connections, even in busy neighbourhoods.
  • Wider channels, higher throughput — the additional spectrum leaves room for many more wide (80 and 160 MHz) channels, so you can run faster connections without them overlapping and interfering with one another.
  • No radar detection, no interruptions — unlike parts of the 5 GHz band, the 6 GHz band does not require radar detection (DFS). The access point starts up immediately and can never be forced off its channel by a radar event, so there are no sudden dropouts.

We have also fixed a bug that prevented the access point from starting when a 40 MHz channel width was combined with a manually selected channel.

Misc.

  • AWS: IPFire can now retrieve EC2 instance metadata using IMDSv2, the token-based and more secure version of the metadata service that AWS now recommends and increasingly enforces by default. This means IPFire runs correctly on instances configured to require IMDSv2, while IMDSv1 remains supported for existing deployments.
  • The microcode for some Intel processors has been updated to version 20260512 to address a vulnerability filed as INTEL-SA-01420
  • A bug with Perl failing to properly encode/decode UTF-8 strings has been fixed so that the web UI will show translations with non-ASCII characters properly again
  • OpenVPN: The icon to download the configuration has been replaced by a clearer version; and for Roadwarrior clients with a static IP address allocation, the name of the subnet is now shown next to the connection.
  • sysklogd will now listen on localhost again, which is useful for chrooted processes that want to log messages
  • Updated packages: BIND 9.20.23, Boost 1.90.0, coreutils 9.11, btrfs-progs 7.0, e2fsprogs 1.47.4, elfutils 0.195, expat 2.8.1, fcron 3.4.1, fontconfig 2.18.1, gdb 17.2, gnupg 2.5.20, GRUB 2.14, grub-btrfs 4.14, iana-etc 20260511, krb5 1.22.2, less 702, libedit 20260512-3.1, libksba 1.8.0, libloc 0.9.19, libunistring 1.4.2, libusb 1.0.30, LuaJIT 2.1.707c12b, LVM2 2.03.41, meson 1.11.1, nettle 4.0, OpenVPN 2.7.4, rrdtool 1.10.3, SQLite 3.53.1, strongswan 6.0.7 (CVE-2026-47895), util-linux 2.42, vim 9.2.0526, which 2.25, xfsprogs 7.0.1, zone-sync 0.0.2

Add-Ons

  • Updated packages: dnsdist 2.0.6, ntfs-3g 2026.2.25, Postfix 3.11.3, rsync 3.4.3, samba 4.24.2, spice 0.16.0, spice-protocol 0.14.5, tmux 3.6b, tshark 4.6.6
  • Zabbix Agent: Fixes for OpenVPN 2.7 status parsing and ping error handling have been applied

Testing and Feedback

As always, please help us make this release as solid as it can be. If you are able, install Core Update 203 on a test system, put it through its paces — particularly around DNS resolution, the DNS Firewall and WiFi — and report anything unexpected on our bug tracker.

Your testing and your reports are what let us release with confidence, and we are grateful to everyone who takes the time.

Thank you for helping us build IPFire.


More...]]> Ipfire siosios https://n00bunlimited.net/home/forum/site-news/ipfire/80483-ipfire-2-29-core-update-203-is-available-for-testing IPFire 2.29 - Core Update 202 released https://n00bunlimited.net/home/forum/site-news/ipfire/80482-ipfire-2-29-core-update-202-released Tue, 26 May 2026 14:04:47 GMT In this release, IPFire 2.29 - Core Update 202, we are fixing the most prominent kernel vulnerabilities of the last few weeks. OpenVPN has been...
In this release, IPFire 2.29 - Core Update 202, we are fixing the most prominent kernel vulnerabilities of the last few weeks. OpenVPN has been updated to version 2.7 which brings support for Data Channel Offloading massively upgrading throughput for your OpenVPN tunnels. As usual, this release contains a large number of package updates with various more security fixes.

We would like to encourage to install this update as soon as possible to be protected against the unusually large amount of vulnerabilities that have been discovered recently in the Linux kernel as well as lots of other software components. Ensure to reboot your IPFire system afterwards.

Linux Kernel Security Vulnerabilities

In this release, the IPFire kernel has been rebased on Linux 6.18.32 which most notably fixes a couple of prominent security vulnerabilities:
  • Dirty Frag — ESP/IPsec (CVE-2026-43284) — A local privilege escalation flaw disclosed on May 7, 2026 in the kernel module providing support for ESP, one of the protocols used for IPsec, allowing an unprivileged local user to escalate to root.
  • Copy Fail (CVE-2026-31431) — A logic flaw in the Linux kernel's cryptographic subsystem, specifically within the algif_aead module of the AF_ALG interface, disclosed April 29, 2026, that lets any unprivileged local user gain root via a tiny exploit on essentially every distribution shipping kernels built since 2017.



While these vulnerabilities are serious for Linux systems in general, IPFire is by design not exposed to the most common attack paths. Both flaws require an unprivileged local user with shell access to the system, and IPFire does not provide unprivileged shell accounts on the firewall - only the administrator has access to the console, and there are no other users logged in. That said, defence in depth matters, and we always recommend keeping systems up to date regardless of whether a known attack path applies, because the next vulnerability may well take a different shape.

OpenVPN 2.7

IPFire is now shipping OpenVPN 2.7 which has been released earlier this year. Over the last couple of updates, we have already rolled out changes that allow a smooth transition. The highlight of this release is support for Data Channel Offloading (DCO) to the kernel. Instead of passing any packets to the OpenVPN daemon for encryption and decryption, the kernel can encrypt or decrypt packets itself which will massively boost throughput. We have observed throughput to jump from 1 GBit/s to 10 GBit/s per tunnel with reduced jitter and less CPU utilisation due to the kernel's better use of the hardware's crypto acceleration.

Misc.

  • Firewall: Multiple ports in a comma-separated list are now being applied properly (#13959)
  • Intrusion Prevention System: The IPS is no longer logging any stats which have used a lot of disk space on some systems. The updater automatically removes any log files freeing the disk space. The remaining log files are now being rotated daily instead of weekly.
  • The IPFire DNS Proxy is now permitted outbound access without any additional firewall rules
  • IPsec: Due to a typo in a script, some automatically generated firewall rules were not removed after a tunnel was shut down. This did not have any other implications than a growing table of redundant rules.
  • In glibc, a crafted DNS response can trick gethostbyaddr/gethostbyaddr_r into treating a non-answer section as a valid answer, violating the DNS spec. The result is an out-of-bounds read and bogus hostnames returned to callers — risky for anything that uses reverse DNS in logging or access decisions (GLIBC-SA-2026-0005).
  • Updated packages: abseil-cpp 20260107.1, Apache2 2.4.67, autoconf 2.73, BIND 9.20.22, btrfs-progs 6.19.1, cURL 8.20.0, ethtool 7.0, expat 2.8.0, freetype 2.14.3, glib 2.88.1, GnuTLS 3.8.13, groff 1.24.1, harfbuzz 14.2.0, hwdata 0.406, iana-etc 20260409, intel-microcode 20260227, inotify-tools 4.25.9.0, iproute2 7.0.0, ipset 7.24, Knot 3.5.4, libarchive 3.8.7, libcap 2.78, libcap-ng 0.9.3, libedit 20251016-3.1, libgcrypt 1.12.2, libinih 62, libjpeg 3.1.4.1, libpng 1.6.58, libsodium 1.0.22, liburcu 0.15.6, libxml2 2.15.3, lmdb 0.9.35, LVM2 2.03.40, man-pages 6.18, mdadm 4.6, oath-toolkit 2.6.14, OpenSSH 10.3p1, OpenSSL 3.6.2, OpenVPN 2.7.3, pango 1.57.1, parted 3.7, pciutils 3.15.0, python3-yaml 6.0.3, sed 4.10, SQLite 3.53.0, strongSwan 6.0.6, Suricata 8.0.5, systemd 260.1, texinfo 7.3, tzdata 2026b, Unbound 1.25.1, usb-modeswitch-data 20251207, wireguard-tools 1.0.20260223, XZ 5.8.3
  • IP Blocklist: Links to the BOGON and BOGON_FULL lists have been updated

Add-Ons

  • Samba: A security researcher working under the pseudonym valent1 has reported two security vulnerabilities in this add-on which are patched in this release:
    • Missing input validation during the join operation allowed authenticated attackers to run arbitrary shell commands as a non-privileged user (CVE pending)
    • Inappropriate shell command escaping allowed attackers to gain root privileges from a shell using the sambactrl helper binary (CVE pending)
  • Who Is Online? valent1 reported a now fixed XSS vulnerability for authenticated users (CVE pending)
  • Updated packages: arpwatch 3.9, dnsdist 2.0.5, ffmpeg 8.1, FRR 10.6.0, htop 3.5.1, iperf3 3.21, Git 2.54.0, HAProxy 3.2.15, keepalived 2.3.4, libid3tag 0.16.4, libmicrohttpd 1.0.5, libmpc 1.4.1, libpciaccess 0.19, libvirt 12.3.0, lldpd 1.0.21, mympd 25.0.1, nano 9.0, ncat 7.99, nfs 2.9.1, nmap 7.99, Postfix 3.11.1, rsync 3.4.2, Samba 4.24.1, Tor 0.4.9.7, transmission 4.1.1, tshark 4.6.5, Zabbix Agent 7.0.24 (LTS) + Monitoring for D-Bus & LLDP


We want to urge you to upgrade your systems, so you aren't vulnerable to the Dirty Frag, Copy Fail, Fragnesia vulnerabilities. Thanks to everyone for giving feedback for the testing release and reporting any problems to Bugzilla.

If you would like to thank the developers & support their work, please donate, to keep the project moving fast!


More...]]> Ipfire siosios https://n00bunlimited.net/home/forum/site-news/ipfire/80482-ipfire-2-29-core-update-202-released IPFire 2.29 - Core Update 202 is available for testing https://n00bunlimited.net/home/forum/site-news/ipfire/80479-ipfire-2-29-core-update-202-is-available-for-testing Mon, 11 May 2026 08:21:15 GMT Today we are proud to present the next challenger stepping into the ring: IPFire 2.29 Core Update 202! In this corner, a brand-new Linux 6.18 kernel....
Today we are proud to present the next challenger stepping into the ring: IPFire 2.29 Core Update 202! In this corner, a brand-new Linux 6.18 kernel. In the other corner, OpenVPN 2.7 with kernel-accelerated Data Channel Offload, delivering up to 10 Gigabit per second per tunnel. Add to that a long list of important security fixes, package updates, and bug fixes - and you have a release that is ready for testing. So power up your test systems, and let's get readyyyy to upgraaaade!

Linux Kernel Security Vulnerabilities

In this release, the IPFire kernel has been rebased on Linux 6.18.28 which most notably fixes a couple of prominent security vulnerabilities:
  • Dirty Frag — ESP/IPsec (CVE-2026-43284) — A local privilege escalation flaw disclosed on May 7, 2026 in the kernel module providing support for ESP, one of the protocols used for IPsec, allowing an unprivileged local user to escalate to root.
  • Copy Fail (CVE-2026-31431) — A logic flaw in the Linux kernel's cryptographic subsystem, specifically within the algif_aead module of the AF_ALG interface, disclosed April 29, 2026, that lets any unprivileged local user gain root via a tiny exploit on essentially every distribution shipping kernels built since 2017.

While these vulnerabilities are serious for Linux systems in general, IPFire is by design not exposed to the most common attack paths. Both flaws require an unprivileged local user with shell access to the system, and IPFire does not provide unprivileged shell accounts on the firewall - only the administrator has access to the console, and there are no other users logged in. That said, defence in depth matters, and we always recommend keeping systems up to date regardless of whether a known attack path applies, because the next vulnerability may well take a different shape.

OpenVPN 2.7

IPFire is now shipping OpenVPN 2.7 which has been released earlier this year. Over the last couple of updates, we have already rolled out changes that allow a smooth transition. The highlight of this release is support for Data Channel Offloading (DCO) to the kernel. Instead of passing any packets to the OpenVPN daemon for encryption and decryption, the kernel can encrypt or decrypt packets itself which will massively boost throughput. We have observed throughput to jump from 1 GBit/s to 10 GBit/s per tunnel with reduced jitter and less CPU utilisation due to the kernel's better use of the hardware's crypto acceleration.

Misc.

  • Firewall: Multiple ports in a comma-separated list are now being applied properly (#13959)
  • Intrusion Prevention System: The IPS is no longer logging any stats which have used a lot of disk space on some systems. The updater automatically removes any log files freeing the disk space. The remaining log files are now being rotated daily instead of weekly.
  • The IPFire DNS Proxy is now permitted outbound access without any additional firewall rules
  • IPsec: Due to a typo in a script, some automatically generated firewall rules were not removed after a tunnel was shut down. This did not have any other implications than a growing table of redundant rules.
  • In glibc, a crafted DNS response can trick gethostbyaddr/gethostbyaddr_r into treating a non-answer section as a valid answer, violating the DNS spec. The result is an out-of-bounds read and bogus hostnames returned to callers — risky for anything that uses reverse DNS in logging or access decisions (GLIBC-SA-2026-0005).
  • Updated packages: abseil-cpp 20260107.1, Apache2 2.4.67, autoconf 2.73, BIND 9.20.22, btrfs-progs 6.19.1, cURL 8.20.0, ethtool 7.0, expat 2.8.0, freetype 2.14.3, glib 2.88.1, GnuTLS 3.8.13, groff 1.24.1, harfbuzz 14.2.0, hwdata 0.406, iana-etc 20260409, intel-microcode 20260227, inotify-tools 4.25.9.0, iproute2 7.0.0, ipset 7.24, Knot 3.5.4, libarchive 3.8.7, libcap 2.78, libcap-ng 0.9.3, libedit 20251016-3.1, libgcrypt 1.12.2, libinih 62, libjpeg 3.1.4.1, libpng 1.6.58, libsodium 1.0.22, liburcu 0.15.6, libxml2 2.15.3, lmdb 0.9.35, LVM2 2.03.40, man-pages 6.18, mdadm 4.6, oath-toolkit 2.6.14, OpenSSH 10.3p1, OpenSSL 3.6.2, OpenVPN 2.7.3, pango 1.57.1, parted 3.7, pciutils 3.15.0, python3-yaml 6.0.3, sed 4.10, SQLite 3.53.0, strongSwan 6.0.6, Suricata 8.0.4, systemd 260.1, texinfo 7.3, tzdata 2026b, Unbound 1.25.0, usb-modeswitch-data 20251207, wireguard-tools 1.0.20260223, XZ 5.8.3
  • IP Blocklist: Links to the BOGON and BOGON_FULL lists have been updated

Add-Ons

  • Updated packages: arpwatch 3.9, dnsdist 2.0.5, ffmpeg 8.1, FRR 10.6.0, htop 3.5.1, iperf3 3.21, Git 2.54.0, HAProxy 3.2.15, keepalived 2.3.4, libid3tag 0.16.4, libmicrohttpd 1.0.5, libmpc 1.4.1, libpciaccess 0.19, libvirt 12.3.0, lldpd 1.0.21, mympd 25.0.1, nano 9.0, ncat 7.99, nfs 2.9.1, nmap 7.99, Postfix 3.11.1, rsync 3.4.2, Samba 4.24.1, Tor 0.4.9.7, transmission 4.1.1, tshark 4.6.5, Zabbix Agent 7.0.24 (LTS) + Monitoring for D-Bus & LLDP


As always, this update would not be possible without the hard work of the IPFire developers, the wider open-source community whose projects we ship, and everyone who tests, reports bugs, and contributes patches. If you would like to support the continued development of IPFire, please donate - every contribution helps us keep the project independent and moving forward.

Happy testing!


More...]]> Ipfire siosios https://n00bunlimited.net/home/forum/site-news/ipfire/80479-ipfire-2-29-core-update-202-is-available-for-testing