IPFire Core Update 204 repariert DNS für VPN-Clients
Seit dem Wechsel auf Knot Resolver in Core Update 203 konnten VPN-Clients hinter IPFire keine Namen mehr auflösen, weil der Resolver von der falschen Quelladresse antwortete. Core Update 204 behebt das, aktualisiert den Kernel auf Linux 6.18.54 und bringt neue Versionen von OpenSSL, OpenSSH und BIND.
Das IPFire-Projekt hat am 14. Oktober 2026 das Core Update 204 für die Firewall-Distribution IPFire 2.29 freigegeben. Es behebt eine Regression aus dem vorherigen Update: Seit dem Wechsel von Unbound auf Knot Resolver konnten Clients, die per IPsec, WireGuard oder OpenVPN verbunden sind, keine DNS-Namen mehr auflösen. Für Betriebe mit Homeoffice- oder Außendienst-Zugängen über IPFire ist das der eigentliche Grund für das Update.
Betroffen sind IPFire-Systeme auf Core Update 203, die VPN-Clients bedienen und deren Namensauflösung über die Firewall läuft. Wer IPFire ohne VPN-Einwahl betreibt, hatte mit diesem Fehler kein Problem, erhält mit dem Update aber einen neuen Kernel und zahlreiche Paketaktualisierungen. Eine konkrete Sicherheitslücke nennt die Ankündigung nicht, das Update sollte trotzdem zeitnah im nächsten Wartungsfenster eingespielt werden, bei gestörten VPN-Zugängen sofort.
Was ist passiert?
Mit Core Update 203 hatte IPFire den DNS-Resolver für geschützte Netze von Unbound auf Knot Resolver umgestellt. Laut Projektleiter Michael Tremer fiel das Echo überwiegend positiv aus, die Namensauflösung sei spürbar schneller und einige alte Probleme seien verschwunden. Allerdings antwortete Knot Resolver gegenüber VPN-Clients von der falschen Quell-IP-Adresse. Die Clients verwarfen diese Antworten, Namen ließen sich nicht mehr auflösen, obwohl der Tunnel selbst stand.
Für die Korrektur waren laut Ankündigung umfangreiche Änderungen an der I/O-Schicht von Knot Resolver nötig, die das Projekt an die Upstream-Entwickler zurückgegeben hat. Tester mit IPsec-, WireGuard- und OpenVPN-Zugängen haben die Lösung vor der Freigabe geprüft. Eine Testversion war seit dem 2. Oktober 2026 verfügbar.
Was sich sonst ändert
- Kernel: Der IPFire-Kernel basiert jetzt auf Linux 6.18.54 mit Fehlerkorrekturen für Stabilität und Sicherheit.
- WireGuard: Konfigurationsdateien mit mehreren durch Leerzeichen getrennten Subnetzen lassen sich nun korrekt importieren (Bug 13951).
- Intrusion Prevention: Das Regelwerk „Advanced Phishing Protection“ von Julio Lira steht als neuer Anbieter zur Auswahl.
- Systempakete: Unter anderem Apache 2.4.68, BIND 9.20.24, cURL 8.21.0, Knot Resolver 6.4.2, OpenSSH 10.4p1, OpenSSL 3.6.5, SQLite 3.53.3 und systemd 261.1.
- Add-ons: Aktualisiert wurden etwa ClamAV 1.5.3, HAProxy 3.4.2, Postfix 3.11.4, rsync 3.5.0 und dnsdist 2.1.0. Der Observium Agent meldet den Apache-Status, Zabbix liefert Metriken zu Knot Resolver, ein Hänger von Avahi beim Herunterfahren ist behoben.
- RISC-V: Die experimentellen Builds sind auf Out-of-Order-Kerne abgestimmt und bleiben zur Basis RVA22 kompatibel.
Wer ist betroffen und wer nicht?
- Betroffen vom DNS-Fehler: IPFire 2.29 mit Core Update 203 und VPN-Clients über IPsec, WireGuard oder OpenVPN, die IPFire als DNS-Server nutzen.
- Typisches Symptom: Der Tunnel steht, Ping auf IP-Adressen klappt, interne und externe Hostnamen lösen aber nicht auf.
- Nicht betroffen vom DNS-Fehler: Systeme ohne VPN-Einwahl sowie Clients, die einen anderen DNS-Server als IPFire verwenden.
- Ältere Systeme vor Core Update 203 nutzen noch Unbound und kennen den Fehler nicht, springen mit dem Update aber direkt auf Knot Resolver.
Wie kritisch ist das?
Technisch handelt es sich um einen Funktionsfehler, nicht um eine ausnutzbare Schwachstelle. Operativ kann er dennoch erheblich sein, wenn Mitarbeitende im Homeoffice oder an Außenstandorten über IPFire auf interne Dienste zugreifen. Wer als Notlösung öffentliche DNS-Server in die VPN-Profile eingetragen hat, sollte das nach dem Update zurückbauen, weil interne Namen sonst nicht aufgelöst werden und DNS-Anfragen das eigene Netz verlassen. Die Ankündigung nennt keine CVE. Kernel und Pakete wie OpenSSL, OpenSSH und BIND bringen aber Upstream-Korrekturen mit, was für eine Firewall am Netzrand allein schon ein Grund für ein zügiges Update ist.
Was sollten Admins jetzt tun?
- Zuerst den installierten Stand prüfen: In der Weboberfläche unter Pakfire oder auf der Konsole mit
cat /etc/system-releasedie Core-Update-Nummer ablesen. - Vor dem Update eine Sicherung der Konfiguration über die Backup-Funktion der Weboberfläche anlegen und extern ablegen.
- Core Update 204 über Pakfire einspielen und wegen des neuen Kernels ein Wartungsfenster für den Neustart einplanen.
- Nach dem Neustart mit je einem Client pro VPN-Typ testen, ob interne und externe Namen auflösen.
- Provisorische DNS-Einträge in VPN-Profilen, die wegen des Fehlers gesetzt wurden, wieder entfernen.
- Wer WireGuard-Konfigurationen mit mehreren Subnetzen importieren musste, kann den Import jetzt erneut versuchen.
Einordnung für Unternehmen
IPFire läuft als freie Firewall häufig auf einer einzelnen Appliance ohne Testumgebung. Der Fall zeigt, warum Resolver-Wechsel gezielt mit VPN-Zugängen getestet werden sollten: Der Fehler betraf nicht die Firewall selbst, sondern nur Clients hinter einem Tunnel und fiel deshalb im Büro oft nicht auf. Wer IPFire produktiv betreibt, sollte nach jedem Core Update eine kurze Prüfliste abarbeiten, die mindestens Namensauflösung lokal, Namensauflösung per VPN und den Zugriff auf einen internen Dienst umfasst.
Passende Anleitungen auf S-EDV
- WireGuard-VPN für Homeoffice und Standorte einrichten: Grundlagen für die Zugänge, die vom Fehler betroffen waren.
- Site-to-Site-VPN mit WireGuard und IPsec: Standortvernetzung und typische DNS-Fragen im Tunnel.
- DNSSEC-Lücken in Unbound und BIND 9: Hintergrund zu den Resolvern, die viele Firewalls einsetzen.
