Sophos Central Firewall Task Queue prüfen

Wenn eine Änderung aus Sophos Central nicht auf der Firewall ankommt, öffnet man zuerst:

My Products > Firewall Management > Tasks Queue

Dort gibt es zwei Ansichten: Die Task Queue zeigt Gruppenrichtlinien, die Firewall Task Queue MDR- und API-Aufträge. Ein erfolgreicher Task bestätigt die Verarbeitung in Central, nicht automatisch die gewünschte Wirkung auf der Firewall. Deshalb folgt auf die Queue-Prüfung immer eine lokale Kontrolle.

Schnellprüfung bei einem fehlgeschlagenen Task

1. Passenden Tab öffnen und den Task aufklappen.
2. Betroffene Gruppe oder Firewall, Status, Zeitpunkt, Entity und Fehlermeldung dokumentieren.
3. Bei Gruppenrichtlinien Gruppenmitgliedschaft und Synchronisationsstatus der Firewall prüfen.
4. Bei MDR-/API-Tasks Credential ID, Entity und Action dem auslösenden System zuordnen.
5. Auf der Firewall kontrollieren, ob die Änderung vollständig oder nur teilweise vorhanden ist.
6. Bei Konfigurationsänderungen die Audit Trail Logs prüfen; bei Traffic-Problemen den Log Viewer, Policy Test und Packet Capture verwenden.
7. Erst nach geklärter Ursache über Retry, Skip oder einen Supportfall entscheiden.
8. Die technische Wirkung mit einem passenden Testfall abnehmen.

Dieser Ablauf trennt zwei Fragen: Hat Central den Auftrag verarbeitet, und funktioniert die Änderung auf der Firewall tatsächlich?

Task Queue und Firewall Task Queue unterscheiden

Task Queue für Gruppenrichtlinien

Sophos Central erstellt einen Task, wenn ein Administrator eine Firewall-Gruppenrichtlinie ändert. Angezeigt werden Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity und Time. Status zeigt den Gesamtfortschritt und wie viele Firewalls die Policy erfolgreich erhalten haben; aufgeklappt sieht man die betroffenen Firewalls.

Der Zeitstempel zeigt zunächst die Erstellung oder letzte Änderung der Policy. Während der Verteilung wird er aktualisiert und zeigt am Ende den Zeitpunkt, an dem die letzte Firewall die Policy erhalten hat. Über Show History lassen sich abgeschlossene oder übersprungene Tasks für inzwischen gelöschte Firewalls oder Gruppen einblenden.

Sophos Central löscht Tasks, die drei Wochen lang auf Pending stehen. Für einen Supportfall sollte man Task-Nummer, Fehlermeldung, betroffene Firewalls und Zeitpunkt deshalb rechtzeitig sichern.

Firewall Task Queue für MDR- und API-Aufträge

Die Firewall Task Queue zeigt MDR Settings und MDR IOCs, die über die Firewall Configuration API angestossen wurden. Die Übersicht gruppiert sie nach Total Firewall Tasks, Pending, In Progress, Failed, Partial Successful und Successful.

Ein aufgeklappter Task zeigt Firewall, Status, Credential ID unter Modified by, Entity, Action und Zeitpunkt. Als Action sind beispielsweise Add, Update oder Delete möglich. Die Credential ID hilft, den Auftrag dem auslösenden System zuzuordnen.

Die einzelnen Statuswerte sind Pending, In Progress, Success, Failed und Partial Success. Bei Partial Success wurde nur ein Teil des Auftrags angewendet, beispielsweise zwei von drei MDR-Indikatoren. Dann trennt man erfolgreiche und fehlgeschlagene Elemente beziehungsweise Firewalls, korrigiert die Ursache, führt nur den betroffenen Auftrag erneut aus und vergleicht das Ergebnis mit der lokalen Konfiguration.

Firmware-Upgrades werden in Sophos Central unter My Products > Firewall Management > Firewalls geplant und überwacht. Sie gehören nicht zu den beiden hier beschriebenen Queue-Ansichten.

Retry, Skip und Force sync sicher verwenden

Retry und Skip gelten nur für Gruppenrichtlinien in der Task Queue. Sophos Central bietet Retry bei Failed, Skipped und Invalid license an; Skip bei Created, Pending, Invalid license und Failed.

• Retry: erst verwenden, wenn die Ursache behoben ist, etwa eine unterbrochene Central-Verbindung, ein Objektkonflikt oder eine inzwischen korrigierte Lizenzzuordnung.
• Skip: nur verwenden, wenn klar ist, welche Änderung nicht angewendet wird und wie man die betroffene Firewall danach kontrolliert.
• Warten: wenn der Task noch verarbeitet wird und keine belastbare Fehlermeldung vorliegt.
• Supportfall: wenn der Fehler wiederholt auftritt, mehrere produktive Firewalls betrifft oder nicht sicher eingeordnet werden kann.

⚠️ Einen fehlgeschlagenen Task nicht nur überspringen, damit die Queue sauber aussieht. Skip ist eine Betriebsentscheidung; die ausgelassene Änderung bleibt anschliessend zu prüfen oder separat umzusetzen.

Wurde eine Firewall mit Skip full sync in eine Gruppe aufgenommen, kann ihre lokale Konfiguration von der Gruppenrichtlinie abweichen. Den Status prüft man unter My Products > Firewall Management > Firewalls. Zeigt Sync & Management dort Failed to apply a policy, prüft man den zugehörigen Eintrag in der Task Queue. Ein Force sync übernimmt die vollständige Gruppenkonfiguration und sollte deshalb nur bewusst ausgelöst werden. Bei einem HA-Paar steht der Link nur auf der aktiven Firewall zur Verfügung.

Central-Policy lokal richtig prüfen

Bei Firewall- und NAT-Regeln gelten Top und Bottom nur für die Reihenfolge innerhalb der Central-Policy. Auf der Firewall werden aus Central verteilte Regeln oben in die lokale Regelliste eingefügt. Lokale Regeln können die effektive Reihenfolge deshalb schwerer vorhersehbar machen; Sophos empfiehlt, Regeln auf zentral verwalteten Firewalls konsequent über Central zu erstellen.

Nach einem erfolgreichen Task kontrolliert man auf der Firewall:

• Ist die geänderte Regel, Policy, Liste oder das Objekt sichtbar?
• Zeigt der Audit Trail die erwartete Konfigurationsänderung?
• Trifft Testtraffic die erwartete Firewall Rule ID und bei NAT die erwartete NAT Rule ID?
• Bei Web- oder TLS-Änderungen: Stimmen Testclient, Ziel-Domain sowie Web- und SSL/TLS-Inspection-Log überein?
• Bei VPN- oder anderen Funktionsänderungen: Funktioniert der konkrete Anwendungsfall mit der erwarteten Benutzer- oder Objektzuordnung?
• Bei MDR-/API-Tasks: Sind Entity beziehungsweise Indikatoren lokal sichtbar und passt das Ergebnis zur Credential ID und zum erwarteten Logereignis?

Für einen kurzen Abnahmenachweis reichen Task-Status, betroffene Firewall, lokaler Test und Log- oder Audit-Beleg. Bei umfangreichen Änderungen kann Sophos Firewall Config Studio zusätzlich helfen, erwartete und tatsächliche Konfigurationen zu vergleichen. Wenn der passende Log unklar ist, bietet Sophos Firewall Troubleshooting: Services und Logs die Zuordnung.

Bekannte versionsabhängige Fehler

Gruppenrichtlinie bleibt auf Pending

NC-181175 beschreibt einen Fehler, bei dem ein Group Policy Push aus Sophos Central auf Pending blieb und nicht auf Firewalls angewendet wurde. Sophos hat ihn mit SFOS 22.0 MR2 Build 546 behoben. Bei einer älteren 22.0-Version und dauerhaftem Pending sollte man deshalb auch den Firmwarestand prüfen.

XGS 88/w: Local TLS exclusion list

NC-177522 betrifft XGS 88/w mit SFOS 21.5 MR2 Build 323 oder 22.0 GA Build 411. Beim Central-Policy-Sync konnte die Bearbeitung der Local TLS exclusion list mit Failed to apply a policy und einer nicht aktualisierbaren URL-Gruppe scheitern.

Der dokumentierte Workaround ist, die fehlgeschlagene Transaktion zu überspringen, damit spätere Tasks weiterlaufen. Danach muss man die lokale TLS-Ausnahmeliste und die zugehörigen Policies prüfen. Die aktuelle Known Issues List ist beim Fix-Stand widersprüchlich: Unter Fix versions nennt sie SFOS 22.0 MR1 Build 490, während der Workaroundtext weiterhin einen Fix im nächsten Maintenance Release ankündigt. Vor einer Bewertung deshalb den aktuellen Eintrag und die Release Notes prüfen.