Sophos Central Firewall Management Task Queue controleren

Wanneer een wijziging in Sophos Central is opgeslagen, maar niet op de Sophos Firewall aankomt, is de lokale firewall niet altijd de eerste foutbron. Bij centraal beheerde firewalls moet men ook de Tasks Queue in Sophos Central controleren. Daar ziet men of Central een groepsbeleid, een API-gebaseerde firewall-taak of een andere centrale wijziging nog verwerkt, gedeeltelijk toegepast, overgeslagen of met een fout beëindigd heeft.

Dit is vooral belangrijk wanneer meerdere firewalls in een groep worden beheerd. Een enkele mislukte taak kan latere wijzigingen vertragen of het zoeken naar fouten verwarren, omdat de configuratie in Sophos Central anders lijkt dan op de getroffen firewall.

Wanneer de Task Queue relevant is

De Task Queue is relevant zodra wijzigingen niet direct lokaal op de firewall, maar via Sophos Central worden uitgevoerd. Dit betreft vooral omgevingen waarin firewalls met Sophos Central verbonden zijn en Central Firewall Management actief wordt gebruikt.

Typische situaties:

een groepsbeleid is in Sophos Central gewijzigd
een wijziging is op enkele firewalls aangekomen, maar op andere niet
een firmware-update is via Sophos Central gepland of gestart
MDR- of API-gebaseerde firewall-taken worden niet volledig uitgevoerd
een taak staat lang op Pending of In Progress
een taak is Failed, Skipped, Invalid license of slechts gedeeltelijk succesvol
na een fout worden latere wijzigingen niet zoals verwacht verwerkt

Voor lokale live-foutopsporing blijft de Firewall Log Viewer belangrijk. De Task Queue beantwoordt echter een andere vraag: Heeft Sophos Central de wijziging überhaupt succesvol tot de firewall gebracht?

Waar de Task Queue te vinden is

Het Sophos Central pad is:

My Products > Firewall Management > Tasks Queue

Sophos maakt daar onderscheid tussen Task Queue en Firewall Task Queue.

Weergave	Waarvoor bedoeld
Task Queue	Status van firewall-groepsbeleidsregels die via Sophos Central op firewalls worden toegepast
Firewall Task Queue	Firewall-taken uit MDR-instellingen, MDR-IOC’s en Firewall Configuration API

Voor klassieke Central Firewall Management problemen is meestal eerst de Task Queue interessant. De Firewall Task Queue wordt belangrijker wanneer wijzigingen via de Firewall Configuration API of MDR-gerelateerde firewall-functies zijn geactiveerd.

Welke informatie belangrijk is

Een enkele taak is alleen nuttig als men deze correct kan interpreteren. Voor een wijziging of een nieuwe poging moet men ten minste deze velden noteren:

Taaknummer
Betrokken groep of firewall
Status
Tijdstip
Beheerder of Credential ID
Entiteit en sub-entiteit
Weergegeven foutmelding
Aantal succesvolle en mislukte firewalls

Het tijdstip is niet altijd gelijk aan de start van de verwerking op elke firewall. Bij groepsbeleidsregels toont Sophos Central eerst het tijdstip van aanmaak of wijziging en werkt dit later bij wanneer het beleid op firewalls wordt toegepast. Daarom moet men bij langere uitrol niet alleen naar de eerste tijd kijken.

Status correct interpreteren

Status	Betekenis voor de praktijk
`Pending`	De taak wacht nog op verwerking. Bij langere duur connectiviteit, licentie en Central-verbinding controleren.
`In Progress`	Central verwerkt de taak nog. Niet parallel meerdere correcties starten als de taak nog loopt.
`Success`	Central meldt de taak als succesvol. Daarna toch op de firewall valideren of het verwachte effect zichtbaar is.
`Partial Success`	Een deel is toegepast, een deel niet. Dit is vooral belangrijk bij groepen of meerdere objecten.
`Failed`	De wijziging is niet succesvol afgerond. Foutmelding en getroffen firewall documenteren.
`Skipped`	De taak is bewust overgeslagen. Daarna is een vakinhoudelijke nacontrole nodig.
`Invalid license`	Licentie of toestemming past niet bij de geplande actie. Niet door herhaaldelijk opnieuw proberen oplossen.

Sophos Central kan taken met de status Pending na enkele weken automatisch verwijderen. Voor bedrijfsdocumentatie, supportgevallen of wijzigingsbeoordelingen moet men relevante fouten daarom tijdig vastleggen.

Correcte controleprocedure

Bij een geblokkeerde Central-wijziging helpt een rustige procedure meer dan herhaaldelijk op Retry klikken.

Open in Sophos Central My Products > Firewall Management > Tasks Queue.
Beperk de periode en betrokken firewall of firewall-groep.
Vouw de taak uit en controleer de getroffen firewalls.
Documenteer status, foutmelding, entiteit, sub-entiteit en tijdstip.
Controleer op de firewall of de wijziging zichtbaar is of alleen in Central is opgeslagen.
Controleer bij configuratiewijzigingen ook Audit Trail Logs.
Evalueer bij verkeersproblemen Log Viewer, Policy Test en relevante servicelogs.
Beslis pas daarna of Retry, Skip of een supportgeval zinvol is.

Als onduidelijk is welk lokaal log relevant is, helpt Sophos Firewall Troubleshooting: Services en Logs. Voor regel- en verkeersanalyse past daarnaast Firewall-regel testen met Log Viewer, Policy Test en Packet Capture.

Skip of Retry?

Sophos Central biedt afhankelijk van de status de acties Skip en Retry aan. Beide zijn nuttig, maar moeten niet als pure opruimactie worden gezien.

Actie	Zinvol wanneer	Vooraf controleren
Retry	de oorzaak is verholpen, bijvoorbeeld verbinding, licentie, objectconflict of tijdelijke Central-storing	Is duidelijk waarom de taak is mislukt?
Skip	een mislukte of niet meer relevante taak latere taken blokkeert en de vakinhoudelijke impact begrepen is	Wordt hierdoor een geplande beleidswijziging bewust niet toegepast?
Wachten	de taak nog loopt of Central veel firewalls verwerkt	Zijn er aanwijzingen voor een echte blokkade of alleen normale vertraging?
Supportgeval	de fout herhaaldelijk optreedt, meerdere productieve firewalls betreft of de melding niet duidelijk is	Zijn taakdetails, tijdstip, firewall-naam en logs vastgelegd?

⚠️ Een mislukte taak moet men niet overslaan alleen om de wachtrij schoon te laten lijken. Skip is een operationele beslissing: De niet toegepaste wijziging moet daarna bewust worden gecontroleerd of apart worden uitgevoerd.

Typische foutbeelden

Wijziging is zichtbaar in Central, maar niet op de firewall

In dit geval eerst controleren of de betreffende taak succesvol is afgerond. Als de taak nog Pending, In Progress, Failed of Partial Success is, ligt het probleem niet noodzakelijk in de lokale firewallregel. Pas als Central de taak als succesvol meldt, moet men dieper in lokale beleids-, object- of loganalyse duiken.

Alleen enkele firewalls in een groep zijn getroffen

Bij groepsbeleidsregels kan een wijziging op meerdere firewalls succesvol zijn en op één firewall mislukken. Dan moet men niet de hele groep zomaar wijzigen, maar de getroffen firewall uitvouwen en verschillen controleren: licentie, firmwareversie, Central-verbinding, lokale objectconflicten, platform en bekende problemen.

Firmware-taak via Central start niet goed

Als een Sophos Firewall Firmware Update via Sophos Central is gepland, moet de Task Queue deel uitmaken van de nacontrole. Blijft de firewall op de oude versie, controleer dan eerst of Central de taak heeft gestart en afgerond. Voor grote releases hoort daarnaast de SFOS 22 Upgrade Check bij de voorbereiding.

Web- of TLS-beleidsynchronisatie mislukt

Bij Web Protection, URL-groepen of TLS-uitsluitingen kan een Central-synchronisatie bijzonder verwarrend zijn, omdat Central een wijziging heeft geaccepteerd die de firewall niet volledig verwerkt. Dan moet men de getroffen entiteit uit de Task Queue met de lokale configuratie vergelijken. Voor de vakinhoudelijke interpretatie passen Sophos Firewall TLS Inspection correct invoeren en Sophos Firewall Web Protection Policy maken.

XGS 88/w en Local TLS Exclusion List

In de lijst met bekende problemen is een specifiek probleem bij XGS 88/w modellen gedocumenteerd: Bij het synchroniseren van een Sophos Central Policy kan de verwerking van de Local TLS exclusion list mislukken. De weergegeven foutmelding verwijst naar een URL-groep die niet kon worden bijgewerkt. In dit geval kan men de mislukte transactie uit de Task Queue overslaan, zodat latere taken doorgaan.

In de praktijk moet men daarna echter niet zomaar doorgaan. Belangrijk is een nacontrole:

Is de gewenste TLS-uitzondering lokaal op de firewall aanwezig?
Zijn web- en TLS-beleid op de firewall nog vakinhoudelijk correct?
Betreft het probleem alleen een XGS 88/w of meerdere firewalls?
Moet de wijziging tijdelijk lokaal worden uitgevoerd of uitgesteld?
Is er een onderhoudsrelease of een Sophos-mededeling voor de getroffen versie?

Nacontrole op de firewall

Een succesvolle Central-taak is een goed signaal, maar nog geen volledige operationele test. Afhankelijk van de wijziging moet men lokaal controleren:

Is de gewijzigde regel, policy, lijst of firmwareversie zichtbaar?
Toont de Log Viewer verwachte gebeurtenissen?
Is de wijziging in de Audit Trail vastgelegd?
Zijn Central-verbinding en rapportage nog steeds actief?
Werken getroffen gebruikers, VPN’s, webtoegang of applicaties?

Bij veiligheidsrelevante wijzigingen moet men daarnaast een kort rollback-punt definiëren. Dit geldt vooral voor Web Protection, TLS Inspection, firewallregels, VPN, HA-cluster en firmware-updates.

Operationele checklist

Voor wijzigingen via Sophos Central duidelijk maken welke firewalls of groepen getroffen zijn.
Na Central-wijzigingen de Task Queue controleren.
Mislukte taken met foutmelding, tijdstip en firewall-naam documenteren.
Partial Success niet als volledig afgehandeld beschouwen.
Retry pas na oorzaakonderzoek gebruiken.
Skip alleen gebruiken als de vakinhoudelijke impact begrepen is.
Bij firmware-taken onderhoudsvenster, back-up en lokale toegang plannen.
Bij herhaalde fouten Audit Trail, Log Viewer en Sophos Support-informatie vastleggen.

FAQ

Wat toont de Sophos Central Task Queue?

De Task Queue toont de status van firewall-groepsbeleidsregels die via Sophos Central op firewalls worden toegepast. Men ziet onder andere getroffen groepen, firewalls, status, beheerder, entiteit, sub-entiteit en tijdstip.

Wat is de Firewall Task Queue?

De Firewall Task Queue toont firewall-taken die afkomstig zijn uit MDR-instellingen, MDR-IOC’s of de Firewall Configuration API. Daar zijn bijvoorbeeld status, Credential ID, entiteit, actie en tijdstip relevant.

Mag men een mislukte taak overslaan?

Ja, technisch kan men bepaalde taken overslaan. Operationeel moet men dat alleen doen als duidelijk is welke wijziging daardoor niet is toegepast en hoe de getroffen firewall daarna wordt gecontroleerd.

Wanneer is Retry zinvol?

Retry is zinvol wanneer de oorzaak van de fout is verholpen. Voorbeelden zijn een herstelde Central-verbinding, een gecorrigeerde licentie, een opgelost objectconflict of een tijdelijke fout die niet meer bestaat.

Vervangt de Task Queue de Log Viewer?

Nee. De Task Queue toont of Central een wijziging heeft verwerkt. De Log Viewer toont lokale firewall-gebeurtenissen en is voor verkeer-, beleids- en dienstanalyse nog steeds noodzakelijk.