Sophos Firewall v22 MR2: Features, Fixes und Upgrade-Hinweise

Sophos hat am 14. Juli 2026 Sophos Firewall OS 22.0 MR2 Build 546 veröffentlicht. Das Maintenance Release ist kleiner als ein Major Release, aber deutlich mehr als ein reines Bugfix-Paket: Es bringt Kontrolle für Post-Quantum Cryptography, eine genauere Erkennung generativer KI-Anwendungen, eine neue Chromebook-Erweiterung, eine weniger disruptive STAS-Standardeinstellung und aktualisierte Let’s-Encrypt-Vertrauensketten. Gleichzeitig korrigiert Sophos 53 dokumentierte Probleme aus den Bereichen Firewall, HA, IPsec, Authentifizierung, Logging, WAF, Reporting und weiteren Komponenten.

MR2 ist damit vor allem ein Betriebs- und Stabilitätsrelease. Die neuen Funktionen sind interessant, doch für viele produktive Umgebungen sind die behobenen Kernel-Abstürze, Failsafe-Ursachen, HA-Probleme und VPN-Fehler der wichtigere Grund für das Update.

Post-Quantum Cryptography erkennen und kontrollieren

Die auffälligste neue Sicherheitsfunktion betrifft Post-Quantum Cryptography (PQC). Damit sind kryptografische Verfahren gemeint, die gegen Angriffe mit künftigen, ausreichend leistungsfähigen Quantencomputern widerstandsfähig sein sollen. Das aktuelle Risiko besteht nicht nur darin, dass ein solcher Computer eines Tages verfügbar sein könnte. Bei besonders schützenswerten Daten spielt bereits heute das Prinzip Harvest now, decrypt later eine Rolle: Verschlüsselter Traffic wird aufgezeichnet und gespeichert, um ihn später mit leistungsfähigerer Technik zu entschlüsseln.

SFOS 22.0 MR2 erkennt reine und hybride Schlüsselaustauschverfahren auf Basis von ML-KEM. Das Verfahren wurde 2024 vom National Institute of Standards and Technology als FIPS 203 standardisiert und basiert auf dem mathematischen Module-Learning-with-Errors-Problem. NIST definiert mit ML-KEM-512, ML-KEM-768 und ML-KEM-1024 drei Parametergruppen mit unterschiedlichen Sicherheits- und Performance-Eigenschaften.

ML-KEM verschlüsselt nicht direkt den späteren Web-Traffic. Es ist ein Key Encapsulation Mechanism und dient dazu, über einen öffentlichen Kanal ein gemeinsames Geheimnis zwischen Client und Server aufzubauen. Aus diesem Geheimnis werden anschliessend die symmetrischen Sitzungsschlüssel abgeleitet, mit denen die eigentlichen Daten effizient verschlüsselt und authentifiziert werden.

Bei einem reinen PQC-Schlüsselaustausch hängt die Sicherheit der Aushandlung allein vom Post-Quantum-Verfahren ab. In aktuellen TLS-Implementierungen werden häufiger hybride Verfahren verwendet. Dabei wird ML-KEM mit einem klassischen Verfahren wie X25519 kombiniert. Ziel einer korrekt konstruierten hybriden Aushandlung ist, dass die Sitzung geschützt bleibt, solange mindestens einer der beiden Bausteine sicher ist. Das ist allerdings eine Eigenschaft der konkreten Kombination und nicht automatisch bei jedem beliebigen Hybridverfahren garantiert. Der Ansatz reduziert das Risiko, sich in einer frühen Migrationsphase vollständig auf ein vergleichsweise neues kryptografisches Verfahren verlassen zu müssen.

Sophos nennt bisher weder die erkannten ML-KEM-Parametergruppen noch die konkreten IPS-Signatur-IDs. Öffentlich dokumentiert ist nur, dass SFOS 22.0 MR2 reine und hybride ML-KEM-Aushandlungen erkennen und kontrollieren kann.

Erkennung und Policy-Steuerung über IPS

Bei TLS 1.3 kündigt der Client die unterstützten Schlüsselaustauschgruppen bereits im ClientHello an. Diese Metadaten werden übertragen, bevor die verschlüsselte Anwendungssitzung aufgebaut ist. Dadurch kann das IPS die Verwendung eines PQC- oder Hybridverfahrens grundsätzlich an der TLS-Aushandlung erkennen, ohne dafür den späteren HTTP-Inhalt entschlüsseln zu müssen.

Sophos stellt dafür neue IPS-Patterns bereit. Damit sie tatsächlich ausgewertet werden, müssen IPS Protection aktiv, eine gültige Network-Protection-Lizenz vorhanden und die entsprechende IPS-Policy einer Firewall-Regel zugewiesen sein. Innerhalb einer eigenen Policy lassen sich für passende Signaturen Aktionen wie diese festlegen:

erlauben,
protokollieren,
einzelne Pakete oder die ganze Sitzung verwerfen,
die TCP-Sitzung durch einen Reset beenden oder
die Signatur deaktivieren.

Die in MR2 eingeführten PQC-Signaturen sind standardmässig deaktiviert. Das ist sinnvoll, weil aktuelle Browser, Cloud-Plattformen, CDNs und TLS-Bibliotheken hybride PQC-Verfahren zunehmend regulär einsetzen. Würde Sophos diese Signaturen sofort mit einer blockierenden Standardaktion ausliefern, könnten legitime Web- und API-Verbindungen unterbrochen werden. Im ersten Feedback-Thread begründet Sophos die deaktivierte Voreinstellung ebenfalls mit der wachsenden Verbreitung von PQC-TLS und dem Risiko einer grossen Zahl unnötiger Alarme.

Ich würde die neuen Signaturen nicht sofort blockierend aktivieren. Sinnvoller ist eine separate IPS-Policy für eine begrenzte Testgruppe, bei der die Treffer zunächst nur protokolliert werden. Danach lässt sich im Log Viewer auswerten, welche Browser, Anwendungen und Ziele ML-KEM einsetzen. Erst wenn klar ist, welche kryptografische Policy durchgesetzt werden soll und welche legitimen Dienste betroffen wären, würde ich mit Drop session oder Reset arbeiten. PQC ist nicht automatisch verdächtig – in den meisten Fällen zeigt ein Treffer lediglich, dass eine Anwendung bereits moderne TLS-Verfahren nutzt.

Kontrolle der TLS-Aushandlung durch Web Protection

Zusätzlich zum IPS greift Web Protection direkt in die zulässige TLS-Aushandlung ein. Sophos formuliert es so, dass Web-Sitzungen keine von der Firewall nicht unterstützten PQC-Algorithmen aushandeln können. Das ist eine andere Aufgabe als die reine Erkennung durch das IPS: Das IPS klassifiziert die sichtbare Aushandlung und wendet eine Policy-Aktion an, während Web Protection sicherstellen soll, dass eine geschützte Web-Sitzung nur mit einem kryptografischen Verfahren zustande kommt, das der SFOS-Verarbeitungsweg unterstützt.

Das ist besonders bei TLS Inspection wichtig. Die Firewall sitzt dabei nicht nur passiv im Datenpfad, sondern muss die TLS-Sitzung terminieren, Zertifikate prüfen beziehungsweise neu ausstellen und auf beiden Seiten kompatible kryptografische Parameter aushandeln. Ein Algorithmus, den Browser und Zielserver unterstützen, ist deshalb nicht automatisch auch für jede dazwischenliegende Inspection Engine geeignet.

PQC-Schlüsselaustausch verändert ausserdem die TLS-Aushandlung technisch. Hybride Key Shares sind grösser als klassische X25519-Werte und können dazu führen, dass ein ClientHello auf mehrere Pakete verteilt wird. Solche Verbindungen sind gemäss TLS grundsätzlich zulässig, können aber ältere Middleboxes, Proxies oder nicht aktualisierte Inspection Engines sichtbar stärker fordern. Die neue MR2-Unterstützung ist deshalb nicht nur eine zusätzliche Signatur, sondern auch eine Kompatibilitätsanpassung für einen TLS-Stack, der sich gerade verändert.

Sophos dokumentiert derzeit nicht im Detail, ob Web Protection bei einem nicht unterstützten PQC-Verfahren die Sitzung beendet, die Aushandlung auf ein klassisches Verfahren zurückfallen lässt oder je nach Datenpfad unterschiedlich reagiert. Deshalb sollte man aus der Release-Ankündigung kein bestimmtes Fallback-Verhalten ableiten. Klar ist nur: Nicht unterstützte PQC-Aushandlungen sollen nicht unkontrolliert an der Schutzschicht vorbeilaufen.

Nach dem Upgrade sollten besonders Umgebungen mit TLS Inspection folgende Punkte testen:

Aktuelle Chrome-, Edge-, Firefox- und Safari-Versionen gegen häufig genutzte SaaS- und Cloud-Dienste testen.
Dieselben Ziele einmal über eine Regel mit und einmal ohne TLS Inspection aufrufen.
TLS-Inspection-Ausnahmen, Zertifikatsfehler und Blockseiten kontrollieren.
IPS- und Web-Protection-Logs auf neue PQC-Meldungen, Handshake-Fehler und Resets prüfen.
Geschäftskritische Anwendungen mit eigenen TLS-Bibliotheken, API-Clients oder Java-Runtimes separat testen.
Bei Problemen mit Packet Capture prüfen, ob bereits der TLS-Handshake scheitert oder erst die geschützte Anwendungssitzung abbricht.
Erst danach entscheiden, ob eine explizite Allow-, Drop- oder Reset-Aktion notwendig ist.

Generative AI mit Synchronized Application Control

MR2 verbessert die Kategorisierung von Generative-AI-Anwendungen. Die entscheidende Einschränkung steckt bereits im Funktionsnamen: Die zusätzliche Sichtbarkeit kommt über Synchronized Application Control. Sophos Endpoint erkennt lokal Anwendungen und teilt diese Information über Security Heartbeat mit der Firewall. SFOS kann die Anwendung anschliessend in Reporting und Application-Control-Regeln genauer zuordnen.

Das hilft bei Anwendungen, die über allgemeine Webprotokolle, gemeinsam genutzte CDNs oder wechselnde Ziele kommunizieren und allein anhand klassischer Firewall-Signaturen nur schwer eindeutig zu erkennen sind. Eine genauere Kategorie erleichtert beispielsweise die Unterscheidung zwischen normalen Webanwendungen und GenAI-Werkzeugen sowie die Auswertung, welche Benutzer oder Geräte solche Anwendungen einsetzen.

Die Funktion ist aber kein universelles CASB und kein DLP-System. Eine automatische Analyse vertraulicher Prompt-Inhalte findet nicht statt, und ohne kompatiblen Sophos Endpoint steht keine identische Anwendungssicht zur Verfügung. In Microsoft-Defender- oder gemischten Endpoint-Umgebungen bleiben DNS-, Web-, TLS-, Proxy- oder SSE/CASB-Kontrollen weiterhin relevant.

Für eine brauchbare Policy braucht es deshalb mehr als die neue Kategorie:

Sophos Endpoint und Security Heartbeat müssen korrekt verbunden sein.
Unbekannte Anwendungen müssen in Synchronized Application Control regelmässig klassifiziert werden.
Firewall-Regeln brauchen eine passende Application-Control-Policy und aktiviertes Logging.
Erlaubte GenAI-Dienste, Unternehmensaccounts und Datenschutzvorgaben müssen definiert sein.
Für sensible Daten braucht es zusätzliche DLP-, Browser-, Endpoint- oder SaaS-Kontrollen.

Ein pauschaler Block sämtlicher GenAI-Anwendungen ist selten die beste erste Massnahme. Sinnvoller ist eine abgestufte Policy: freigegebene Unternehmensdienste erlauben, unbekannte oder nicht geprüfte Dienste protokollieren beziehungsweise blockieren und die Nutzung anhand realer Geschäftsanforderungen bewerten.

Authentifizierung: Chromebook, STAS und eDirectory

MR2 verändert gleich drei technisch unterschiedliche Bereiche der Benutzeridentifikation. Im Alltag betreffen alle denselben kritischen Punkt: Ob die Firewall einen Benutzer zuverlässig erkennt und die richtige Policy zuordnet.

Chromebook User ID mit Manifest V3

Die neue Sophos Chromebook User ID Extension unterstützt Chrome Manifest V3. Manifest V3 ist die aktuelle Erweiterungsplattform von Chrome und verändert unter anderem Berechtigungen, Hintergrundprozesse und die Art, wie Erweiterungen Netzwerkereignisse verarbeiten. Ohne die neue Version würde die bisherige Sophos-Erweiterung langfristig keine regulären Updates mehr erhalten.

Ein In-place-Update ist laut Sophos nicht vorgesehen. Die alte Erweiterung muss deinstalliert und die neue installiert werden. In verwalteten Chromebook-Umgebungen gehört das in die Google-Admin-Konsole oder das verwendete Endpoint-Management:

Alte Sophos Chromebook User ID Extension aus der erzwungenen Installation entfernen.
Neue Manifest-V3-Version hinzufügen und den Zielgruppen zuweisen.
Mit einem Testbenutzer anmelden.
Auf der Firewall prüfen, ob Benutzername und IP-Adresse korrekt zugeordnet werden.
Eine benutzerbasierte Firewall- oder Web-Policy auslösen und das Ergebnis im Log Viewer kontrollieren.

Wichtig ist die Reihenfolge. Wird die alte Erweiterung entfernt, bevor die neue Version verteilt ist, fehlt vorübergehend die Benutzerzuordnung. Regeln können dann auf eine allgemeinere Fallback-Policy fallen oder den Zugriff blockieren.

Die vollständige Einrichtung von Device Access, Zertifikat, Firewall-Regeln, JSON-Policy und API Controls zeigt Chromebook SSO mit Google Workspace einrichten.

STAS blockiert während der Identitätsprüfung nicht mehr standardmässig

Bei der Sophos Transparent Authentication Suite (STAS) fragt die Firewall bei einem neuen oder geänderten Client ab, welcher Active-Directory-Benutzer hinter einer IP-Adresse steht. Die Einstellung Restrict client traffic during identity probe entscheidet, ob der Client während dieser Prüfung bereits Datenverkehr senden darf.

Der Standardwert ist mit MR2 auf No geändert. Der Verkehr darf also weiterlaufen, während die Firewall Benutzer und Zieladresse abgleicht. Das reduziert kurze Unterbrüche, die besonders bei neuen Sessions, Benutzerwechseln, Roaming oder verzögerten Antworten des STAS Collectors auffallen können.

Der Komfortgewinn hat einen Trade-off: Während der Probe muss die Firewall mit dem noch verfügbaren Identitätskontext arbeiten. In Umgebungen mit sehr strikten benutzerbasierten Regeln sollte deshalb geprüft werden, welche Policy in diesem kurzen Fenster greift. Nach dem Update sollte man nicht blind voraussetzen, dass bestehende Konfigurationen automatisch denselben Wert übernehmen. Aktuellen Wert, gewünschtes Verhalten und tatsächliche Logs kontrollieren.

Novell eDirectory endet mit SFOS 23.0

MR2 zeigt ausserdem einen End-of-Life-Hinweis für Novell eDirectory Authentication Server. Die Unterstützung endet mit SFOS 23.0. In MR2 funktioniert eDirectory weiterhin; die Meldung ist eine Vorwarnung und kein unmittelbarer Funktionsentzug.

Vermissen werden wir diese Integration nicht. Novell eDirectory ist bei keinem unserer Kunden mehr im Einsatz und spielt auch bei neuen Projekten schon lange keine Rolle mehr. Für die wenigen Umgebungen, die es noch verwenden, bleibt bis SFOS 23.0 Zeit für die Migration auf eine unterstützte Identity-Quelle. Dabei müssen neben dem Authentication Server auch importierte Gruppen, Firewall-Regeln, VPN-Berechtigungen, Web-Policies, Captive Portal und benutzerbasierte Reports geprüft werden.

Let’s Encrypt und Zertifikatsbetrieb

SFOS 22.0 MR2 aktualisiert die Unterstützung für neue Let’s-Encrypt-Root- und Intermediate-Zertifikate. Neu berücksichtigt werden die Ketten YE Root, YE1, YE2, YR Root, YR1 und YR2. Damit bereitet Sophos Firewall die automatische Zertifikatsausstellung und -verlängerung auf die aktuellen und kommenden Let’s-Encrypt-Ketten vor.

Das ist relevant, weil eine korrekte ACME-Anfrage allein nicht genügt. Firewall, Gegenstelle und Clients müssen auch die ausgestellte Zertifikatskette korrekt aufbauen und validieren können. Veraltete Trust Stores können sonst zu scheinbar unerklärlichen Zertifikatsfehlern führen, obwohl das Leaf-Zertifikat selbst gültig ist.

Zudem enthalten Let’s-Encrypt-E-Mail-Benachrichtigungen neu Hostname und Seriennummer der Firewall. In Umgebungen mit mehreren Appliances lässt sich dadurch schneller erkennen, welches Gerät eine Verlängerung, einen Fehler oder eine andere Zertifikatsmeldung ausgelöst hat. Die Seriennummer gehört allerdings zu den inventarrelevanten Gerätedaten; Benachrichtigungen sollten deshalb nur an kontrollierte Empfänger und Mailboxen gehen.

Nach dem Upgrade lohnt sich ein vollständiger Zertifikatstest:

ACME-Status und nächstes Verlängerungsdatum kontrollieren.
Hostname, DNS-Auflösung und Erreichbarkeit der Challenge prüfen.
Zertifikatskette im Browser oder mit einem externen TLS-Test validieren.
WAF-, WebAdmin-, User-Portal- und VPN-Zertifikate getrennt betrachten.
Eingang der neuen E-Mail-Benachrichtigung und die Empfängerliste prüfen.

Config Studio 2.6 erweitert Analyse und Migration

Parallel zu MR2 hebt Sophos Firewall Config Studio 2.6 hervor. Das Tool läuft browserbasiert ausserhalb der Firewall und ist daher technisch keine in Build 546 eingebettete WebAdmin-Funktion. Es ergänzt den Betrieb aber an genau den Stellen, an denen SFOS selbst weiterhin nur begrenzte Analyse- und Vergleichsmöglichkeiten bietet.

Die wichtigsten Funktionen von Version 2.6 sind:

Merge templates: Eine Baseline-Konfiguration lässt sich mit einer branchen- oder einsatzspezifischen Vorlage kombinieren. Das beschleunigt standardisierte Rollouts, ersetzt aber keine Prüfung auf kollidierende Objekte, Interfaces oder Regeln.
Enhanced Global Search: Objekte lassen sich global suchen und direkt an ihrer Verwendungsstelle öffnen. Das hilft besonders bei grossen Regelwerken und der Bereinigung unklarer Abhängigkeiten.
Improved Configuration Report: Firewall-, NAT- und TLS-Regeln zeigen nicht nur referenzierte Objektnamen, sondern auch deren Werte und Details. Reviews werden damit verständlicher, ohne jedes Objekt separat nachzuschlagen.
Migration Insights: Nach einer Konvertierung zeigt Config Studio den erfolgreich migrierten Anteil. Der Prozentwert ist eine Orientierung, aber keine Abnahme: Nicht übertragene VPNs, Authentifizierung, Zertifikate und herstellerspezifische Funktionen müssen weiterhin manuell geprüft werden.
Multi-file Configuration Diff: Mehrere Konfigurationsstände lassen sich vergleichen. Damit kann man nachvollziehen, zwischen welchem Backup eine Änderung, ein Fehler oder eine unerwünschte Abweichung entstanden ist.
Backup-Restore-Kompatibilität: Das Tool hilft zu prüfen, ob ein Backup auf einem anderen Sophos-Firewall-Modell wiederhergestellt werden kann.
Flexi-Port- und Port-Speed-Referenz: Portlayouts, Flexi-Module sowie unterstützte Geschwindigkeiten bis 25, 40 oder 100 Gbit/s lassen sich vor Hardwaremigrationen vergleichen.

Config Studio 2.6 wurde bereits ausführlich im Beitrag Sophos Firewall Config Studio 2.6: Migration eingebaut eingeordnet. Der praktische Workflow für Report, Compare, Editor und kontrollierten Rückimport steht in Sophos Firewall Config Studio nutzen.

Die 53 behobenen Probleme in Build 546

Sophos nennt mehr als 50 Stabilitäts-, Zuverlässigkeits- und Sicherheitskorrekturen. Die folgende Einordnung enthält alle 53 IDs aus den offiziellen Release Notes. Die Liste ersetzt keine individuelle Supportbewertung, zeigt aber, welche Funktion betroffen war und warum der Fix im Betrieb relevant ist.

Firewall, Kernel, HA und Systemstabilität

NC-180331 – Fehlerhafte Speicherbehandlung in algif_aead und algif_skcipher: Schliesst eine Linux-Kernel-Schwachstelle in kryptografischen Komponenten.
NC-181331 – Volle Konfigurationspartition versetzte die Firewall in Failsafe: Reduziert das Risiko eines Betriebsausfalls durch erschöpften Konfigurationsspeicher.
NC-180974 – Kernel-Crash in sdwan_profile löste HA-Failover aus: Stabilisiert SD-WAN-Umgebungen und vermeidet unnötige Rollenwechsel im Cluster.
NC-178354 – Kernel-Crash während des SD-WAN-Rule-Matchings: Verhindert Abstürze beim Auswerten von SD-WAN-Regeln.
NC-178413 – Leerer Wert in Services führte zu ipset-Fehler und Failsafe: Fängt beschädigte oder unvollständige Serviceobjekte robuster ab.
NC-177934 – Firewall ging nach Upgrade auf SFOS 22.0 GA in Failsafe: Behebt eine direkte Upgrade-Folge früher v22-Builds.
NC-177441 – Initiales primäres HA-Gerät ging nach Upgrade auf SFOS 22.0 GA in Failsafe: Verbessert die Startstabilität des Primärknotens nach dem Upgrade.
NC-177467 – Auxiliary-Gerät startete wegen sehr vieler gleichzeitiger nicht authentifizierter SSH-Verbindungen nicht: Wichtig für exponierte oder stark gescannte HA-Systeme; genau dieser Fix wird im ersten MR2-Feedback für XGS 5500 HA kritisch beobachtet.
NC-173031 – Importierte Application Policies wurden nicht automatisch zum Auxiliary-Gerät synchronisiert: Sorgt für konsistentere Policy-Stände auf beiden HA-Knoten.
NC-177536 – Firmware-Upgrade auf SFOS 22.0 GA scheiterte auf dem primären HA-Gerät: Stabilisiert den Upgradepfad in HA-Clustern.
NC-178745 – HA-Gerät startete wegen Out-of-Memory automatisch neu: Reduziert ungeplante Neustarts durch den Logging-Bereich.
NC-180110 – Primäres HA-Gerät ging in Failsafe, weil der Logging-Daemon nicht startete: Verhindert, dass ein Logging-Startfehler den gesamten Primärknoten ausser Betrieb setzt.
NC-180933 – Admins konnten sich nicht an der WebAdmin-Konsole anmelden: Behebt einen direkten Verlust des administrativen GUI-Zugriffs.
NC-177769 – eBPF-Service reagierte nach einem Pattern-Update nicht mehr: Stabilisiert den beschleunigten Datenpfad nach Signaturaktualisierungen.
NC-180152 – Interface-Updates dauerten in SFOS 22.0 GA länger als in 21.5: Verkürzt Verzögerungen beim Anwenden von Schnittstellenänderungen.
NC-179462 – Wiederholte Warnungen beim Auslesen von Hardwarestatistiken: Bereinigt unnötiges Lograuschen auf XGS-Appliances.

Firewall-Regeln, Benutzerverkehr und Routing

NC-181741 – Verkehr nicht authentifizierter Benutzer wurde stündlich verworfen: Verhindert regelmässige Unterbrüche in Umgebungen mit unauthentifiziertem Traffic.
NC-178903 – SATC-Benutzer verloren nach Upgrade auf SFOS 22.0 GA den Internetzugriff: Stellt benutzerbasierten Zugriff mit dem Sophos Authentication Thin Client wieder her.
NC-178141 – Bestimmte ICMP-Fehlermeldungen wurden nach GA-Upgrade durch Local ACL verworfen: Verbessert Path-MTU-Discovery und Fehlerdiagnose, bei denen ICMP technisch notwendig ist.
NC-178197 – Application Traffic stoppte zeitweise mit applikationsbasierter Bandwidth Policy: Stabilisiert QoS für Regeln, die Bandbreite anhand erkannter Anwendungen steuern.
NC-180226 – GUI zeigte bei doppelter MAC-Adresse in Spoof protection trusted MAC keinen Fehler: Verhindert stille Fehlkonfigurationen in der Spoof-Protection-Ausnahmeliste.
NC-181299 – GeoIP-Datenbank ordnete eine IP dem Vereinigten Königreich statt Deutschland zu: Korrigiert Länderzuordnung für GeoIP-Regeln und Reports.

IPsec und VPN

NC-180433 – Multicast über einen VPN-Tunnel führte zu wiederholten Firewall-Crashes: Wichtig für Routing-, Streaming- oder Discovery-Szenarien mit Multicast über IPsec.
NC-178121 – Site-to-Site-IPsec-Verbindungen landeten nach Drag-and-drop an falscher Position in der Failover-Gruppe: Stellt sicher, dass die konfigurierte Tunnelpriorität tatsächlich erhalten bleibt.
NC-171719 – SD-WAN-Routingproblem mit ESP-Traffic: Verbessert die Pfadauswahl für natives IPsec/ESP in SD-WAN-Szenarien.
NC-180520 – XFRM-Gateway blieb bei IPsec-Beschleunigung, Alias-IP und ESP-Eingang über anderem WAN-Port unerreichbar: Behebt einen komplexen Multi-WAN-Sonderfall bei beschleunigten IPsec-Tunneln.
NC-176855 – Niedriger IPv6-Durchsatz über route-based IPsec: Verbessert IPv6-Performance in tunnelbasierten VPN-Designs.
NC-181687 – Erstellen einer SSL-VPN-Policy endete mit internem Serverfehler: Stellt die Policy-Erstellung in der neuen Control-Plane-/HA-Architektur wieder her.
NC-175860 – Remote-Access-IPsec fiel nach HA-Failover aus, wenn das Appliance Certificate neu erzeugt worden war: Stabilisiert zertifikatsabhängige Remote-Access-Verbindungen über Rollenwechsel hinweg.

Authentifizierung, Central und Konfigurationsmanagement

NC-180824 – Neue AD-Benutzer in einer sekundären AD-Gruppe konnten sich nicht am VPN Portal anmelden: Korrigiert verschachtelte beziehungsweise sekundäre Gruppenmitgliedschaften beim Portalzugriff.
NC-176806 – Microsoft Entra ID SSO scheiterte wegen fehlender Intermediate-CAs: Verbessert die Zertifikatsvalidierung bei Entra-ID-Anmeldungen.
NC-160157 – Last access time blieb nach Benutzerlöschung erhalten und erschien beim neu angelegten Benutzer: Verhindert irreführende historische Zugriffsdaten nach dem Neuerstellen eines Kontos.
NC-181175 – Group Policy Push aus Sophos Central blieb auf pending und wurde nicht angewendet: Behebt festhängende Gruppenänderungen im zentralen Management.
NC-180513 – Konfigurationsimport aus der Sophos-Central-Ansicht funktionierte nach MR1-Upgrade nicht: Stellt den Central-basierten Importweg wieder her.
NC-181904 – Quarantäne-E-Mails liessen sich über Sophos Central nicht freigeben: Behebt den bekannten Central-Workflow; der lokale WebAdmin war zuvor der praktische Workaround.

Die Central Firewall Task Queue sollte nach dem Update weiterhin kontrolliert werden. Ein behobener Produktfehler garantiert nicht, dass ältere festhängende Tasks oder inkonsistente Gruppenstände automatisch verschwinden.

Logging und Reporting

NC-181520 – Log Viewer war zu langsam: Verbessert die Reaktionszeit bei Suche und Fehleranalyse.
NC-172912 – System Graph flackerte: Stabilisiert die Darstellung von Systemmetriken.
NC-172020 – Firewalls ohne On-box Reporting verschickten leere Traffic-Dashboard-PDFs: Verhindert inhaltslose tägliche Reports.
NC-169646 – On-demand-PDFs enthielten in Chrome falsche Diagramme und Tabellen: Korrigiert die browserbasierte Reportgenerierung.
NC-155252 – Hohe Disk-I/O erzeugte CPU-Spitzen und bis zu einminütige Internetausfälle: Ein besonders relevanter Stabilitätsfix für reporting- und logging-intensive Systeme.

NC-178745 und NC-180110 aus der Stabilitätsliste betreffen ebenfalls das Logging Framework, hatten aber wegen Neustart beziehungsweise Failsafe direkte Auswirkungen auf die gesamte Appliance.

E-Mail, Antivirus und Security Heartbeat

NC-180066 – SAVI- und AVIRA-Pattern-Updates scheiterten und stoppten den Antivirus-Dienst: Stellt sicher, dass ein Patternfehler nicht den gesamten AV-Service beendet.
NC-177930 – E-Mails blieben wegen eines mailpoller-Crashes im Spool: Verhindert blockierte Mailzustellung im MTA-Betrieb.
NC-171602 – Firewall-Benachrichtigungen bestanden die DKIM-Prüfung nicht: Verbessert die Zustellbarkeit signierter System-E-Mails.
NC-176012 – Fehlender Heartbeat wurde gemeldet, wenn zwei Endpoints dieselbe Dockingstation oder USB-Schnittstelle nutzten: Reduziert falsche Heartbeat-Alarme bei wechselnden Geräten an gemeinsam genutzter Hardware.

Wer MTA Mode nutzt, sollte nach dem Update Mail-Spool, Quarantäne, DKIM und Central-Freigabe anhand der Schritte im Artikel Sophos Firewall Mail Protection im MTA Mode testen.

WAF, Web Protection und RED

NC-180200 – WAF stoppte bei Home Edition während der nächtlichen Lizenzsynchronisation: Verhindert regelmässige WAF-Ausfälle in Home-Edition-Installationen.
NC-177457 – Bei aktiviertem WAF-Debugging war das Passwort in reverseproxy.log sichtbar: Schliesst eine sensible Klartext-Offenlegung im Debug-Log. Alte Debug-Logs sollten trotzdem geprüft und geschützt beziehungsweise nach Vorgabe gelöscht werden.
NC-176788 – ResponseFieldSize fiel beim Zertifikatswechsel in einer WAF-Regel auf den Standard zurück: Bewahrt eine bewusst gesetzte Grössenbegrenzung bei Zertifikatsänderungen.
NC-167019 – Snort verursachte bei Veeam-Traffic ohne Ausnahme hohe CPU-Last: Reduziert Lastspitzen bei Backup-Datenverkehr; bestehende Ausnahmen sollten dennoch auf Notwendigkeit geprüft werden.
NC-178906 – Firewall ging mit Failed to start Red server service in Failsafe: Stabilisiert den RED-Serverdienst und verhindert einen applianceweiten Failsafe-Zustand.

Firmware, DDNS und Benutzeroberfläche

NC-170200 – Mehrere Upgradeversuche innerhalb weniger Minuten liessen Firmware-Upgrades scheitern: Macht Firmware Management robuster; parallele oder hektisch wiederholte Starts bleiben trotzdem zu vermeiden.
NC-180219 – Cloudflare DDNS funktionierte nach Upgrade auf SFOS 22.0 MR1 nicht: Stellt dynamische DNS-Updates für Cloudflare wieder her.
NC-181575 – Zeitfeld in Schedules wurde falsch dargestellt: Verhindert Fehlinterpretationen beim Bearbeiten zeitgesteuerter Regeln.
NC-171424 – Nach Löschen der einzigen Exception auf der letzten Seite erschien die Web-Exceptions-Liste leer: Führt korrekt auf die vorherige Seite zurück, statt eine vermeintlich leere Konfiguration zu zeigen.

Upgrade planen und MR2 validieren

Sophos unterstützt das Upgrade auf v22 MR2 von allen unterstützten Versionen der Reihen v21.5, v21 und v20. Das Firmware-Image kann manuell über Sophos Central bezogen werden; die automatische Bereitstellung an verbundene Geräte erfolgt gestaffelt über die kommenden Wochen. Laut Sophos ist das Update für lizenzierte Firewalls mit Enhanced oder Enhanced Plus Support ohne zusätzliche Firmwarekosten verfügbar.

Trotz der langen Fixliste sollte MR2 nicht ungetestet auf alle Systeme gleichzeitig verteilt werden. Der öffentliche Feedback-Thread wurde erst am Veröffentlichungstag eröffnet. Erste Beiträge fragen insbesondere nach der Stabilität von XGS 5500 im Active-Passive-HA-Betrieb und dem Fix NC-177467. Das ist noch kein bestätigter neuer MR2-Fehler, aber ein guter Grund, HA-Systeme und geschäftskritische Standorte gestaffelt zu aktualisieren.

Vor dem Update

Unterstützten Upgradepfad und Lizenzstatus prüfen.
Vollständiges, verschlüsseltes Backup erstellen und extern verfügbar halten.
SFOS 22 Upgrade Check durchführen.
Offene Health-Check-Findings im Sophos Firewall Health Check bewerten.
HA-Status, SSD-Zustand, freie Partitionen und Pattern-Status kontrollieren.
Kritische Funktionen dokumentieren: WAN, SD-WAN, IPsec, SSL VPN, WAF, MTA, DDNS, Authentifizierung und Central Management.
Wartungsfenster, Zugriff auf die lokale Konsole und Rollback-Entscheid vorbereiten.

Nach dem Update

Build 22.0 MR2 546, Systemstatus und aktive Hotfixes prüfen.
Bei HA beide Knoten, Synchronisation, Rollen und Failover kontrollieren.
WAN, DNS, DHCP/DDNS, SD-WAN und Internetzugriff testen.
Site-to-Site- und Remote-Access-VPNs inklusive IPv6 und Failover prüfen.
AD, Entra ID, STAS, SATC und Portalanmeldung mit Testbenutzern validieren.
WAF, Let’s Encrypt, MTA, Quarantäne und Benachrichtigungen kontrollieren.
Central Task Queue und zuletzt angewendete Gruppenänderungen prüfen.
Log Viewer auf neue Fehler, Failsafe-Hinweise, Service-Restarts und PQC-Meldungen durchsuchen.
Erst nach einer stabilen Beobachtungsphase weitere Appliances aktualisieren.

Der vollständige Ablauf für Backup, Wartungsfenster und Nachkontrolle ist in Sophos Firewall Firmware Update vorbereiten beschrieben.

Fazit

Sophos Firewall v22 MR2 ist ein sinnvolles Maintenance Release mit einem ungewöhnlich breiten Mix. Post-Quantum Cryptography und die bessere GenAI-Kategorisierung zeigen, wohin sich Netzwerk- und Anwendungskontrolle entwickeln. Chromebook Manifest V3, STAS und Let’s Encrypt sind weniger spektakulär, lösen aber konkrete Lifecycle- und Betriebsprobleme.

Der stärkste Grund für Build 546 bleibt die Stabilität: mehrere Kernel-Crashes, Failsafe-Zustände, HA-Probleme, VPN-Fehler, ein Klartextpasswort im WAF-Debug-Log und relevante Ausfälle in Logging, Reporting, Antivirus und Mail wurden korrigiert. Genau wegen dieser Eingriffstiefe sollte das Update nicht als beiläufiger Klick behandelt werden. Backup, gestaffelter Rollout und eine gezielte Funktionskontrolle bleiben Pflicht.