Software 45029 Published by

IPFire 2.29 Core Update 204 released today as a housekeeping release that fixes a DNS regression and ships dozens of security updates. The headline repair addresses a bug that left VPN users unable to resolve names after the CU 203 migration to Knot Resolver, with the fix contributed upstream rather than patched locally. Alongside the DNS work, the update bumps OpenSSL, OpenSSH, BIND, and cURL, adds a community phishing-protection ruleset, and tunes experimental RISC-V builds for out-of-order cores. Existing 2.29 users can apply Core Update 204 directly through Pakfire, and IPFire is teasing a major monitoring and reporting upgrade for a near-future release.



IPFire releases Core Update 204, mending a DNS regression that broke VPN clients

IPFire 2.29 Core Update 204 shipped today as a housekeeping release, and if you've been pulling your hair out over DNS through your VPN tunnels, this is the one that fixes it.

The project's own wording is modest. Lead developer Michael Tremer calls it a release that "brings a healthy dose of updates across the entire operating system and fixes a regression in our recent migration to Knot Resolver." In other words: mostly maintenance, with one real repair at the center.

That's actually a fair reading. Most of what's in here is the unglamorous work that keeps a firewall from rotting: OpenSSL, OpenSSH, BIND, cURL, and a couple dozen more packages bumped to newer, patched versions. It's not going to win any design awards. But a firewall that stops breaking on its own is doing its job.

In Core Update 203, released July 20, IPFire swapped its longtime DNS resolver, Unbound, for Knot Resolver. That migration was mostly a win. It brought encrypted upstream forwarding, a DNS firewall, SafeSearch, a persistent cache, and noticeably faster resolution.

Then someone tried to look up a hostname through a VPN.

And it broke. Clients over IPsec, WireGuard, and OpenVPN found they couldn't resolve names at all. Turns out Knot Resolver was answering queries from the wrong source IP: send a query to the tunnel-side address, say 192.168.99.1 deep inside a WireGuard pool, and the reply comes back off the Red, or Internet-facing, interface. That lands entirely outside the tunnel. VPN clients are supposed to reject replies arriving from an unexpected source, since that's how spoofing attacks look. So they reject it. Name resolution dies.

The whole thing played out in the IPFire community forum, which is where these things usually do. One user nailed the failure mode: the query goes to 192.168.99.1 inside the tunnel, but the reply comes back from the Red interface address outside the tunnel scope entirely, and the client rightly rejects it.

Operators were left with a stopgap. You could add an explicit source address to the tunnel route via /etc/sysconfig/firewall.local while waiting for the real fix. Fine for a weekend. Not fine for a production branch link.

The actual fix wasn't a simple config tweak you could paste into a shell. IPFire says it "required substantial changes to the I/O layer of Knot Resolver, which we have contributed upstream." Rather than papering over it with a local patch that would vanish on the next upgrade, the devs dug into the resolver's core and fed their work back to the upstream project. Upstream contribution is a maturity signal you don't see everywhere: a small team feeding real fixes into a dependency it relies on.

The rest of the bag

Beyond the DNS fix, the change list is a grab bag of things that matter more than they read.

The Suricata-based IPS gains a community ruleset called "Advanced Phishing Protection" by Julio Lira, adding proactive blocking for phishing domains on top of the defaults. Timely, given how much credential theft has become the default move for attackers. The kernel jumps to Linux 6.18.54 for stability and security. WireGuard gains a fix for importing config files that list multiple space-separated subnets, an actual bug that previously mangled peer entries.

And here's a slight detour worth a look: IPFire's experimental RISC-V builds have been tuned for out-of-order cores, still compatible with the RVA22 baseline while taking advantage of RVA23 improvements. The project recently announced that it cut RISC-V build testing from days to hours by using real hardware. That's the kind of detail that only surfaces if you're actually following the port.

Also fixed: Avahi, the mDNS/Bonjour daemon, which hung during shutdown when it wasn't running.

Bumps and add-ons

The core package table is long. OpenSSL is now 3.6.5, OpenSSH is 10.4p1, BIND sits at 9.20.24, cURL is at 8.21.0, systemd is 261.1, and Knot Resolver itself has moved to 6.4.2. Add-ons got their own refresh, including an Observium agent that can now report Apache status and a Zabbix update that reports Knot Resolver metrics, the latter doubling as a teaser for what's coming.

Which brings us to the teaser. The announcement closes by promising that "monitoring and reporting are getting a serious upgrade that will give you a much clearer picture of what your firewall is doing." Translation: expect a bigger visibility overhaul in a near-future release. The Zabbix Knot Resolver metrics are apparently the first taste.

Where to grab it

Core Update 204 covers x86_64 and aarch64, in three flavors. The ISO image is 671 MB for x86_64 and 613 MB for aarch64. The flash image comes in at 511 MB and 506 MB respectively, and there's also a cloud image for AWS, Exoscale, and Hetzner.

If you're already on 2.29, you don't need to download anything. Just run the update through Pakfire and it lands on the running system without a reinstall. Everything sits on downloads.ipfire.org, with torrent links if you're into that.

It's a quiet release, and honestly that's the point. IPFire isn't chasing features this month. It's fixing a self-inflicted wound and tightening bolts. Sometimes that's exactly what you want from a firewall.

Head here for the download links.