Check Sophos Central Firewall Management Task Queue

When a change is saved in Sophos Central but does not reach the Sophos Firewall, the local firewall is not always the first source of error. For centrally managed firewalls, you should also check the Tasks Queue in Sophos Central. There you can see whether Central is still processing, partially applying, skipping, or has completed with errors a group policy, an API-based firewall task, or another central change.

This is especially important when multiple firewalls are managed in a group. A single failed task can delay later changes or confuse troubleshooting because the configuration in Sophos Central looks different from that on the affected firewall.

When the Task Queue is relevant

The Task Queue is relevant as soon as changes are not made directly locally on the firewall but via Sophos Central. This mainly affects environments where firewalls are connected to Sophos Central and Central Firewall Management is actively used.

Typical situations:

• a group policy has been changed in Sophos Central
• a change has reached some firewalls but not others
• a firmware update has been planned or started via Sophos Central
• MDR or API-based firewall tasks do not appear to be fully implemented
• a task remains Pending or In Progress for a long time
• a task is Failed, Skipped, Invalid license, or only partially successful
• after an error, subsequent changes are not processed as expected

For local live troubleshooting, the Firewall Log Viewer remains important. However, the Task Queue answers a different question: Did Sophos Central successfully bring the change to the firewall at all?

Where to find the Task Queue

The Sophos Central path is:

My Products > Firewall Management > Tasks Queue

Sophos distinguishes between Task Queue and Firewall Task Queue.

For classic Central Firewall Management issues, the Task Queue is usually of interest first. The Firewall Task Queue becomes more important when changes are triggered via the Firewall Configuration API or MDR-related firewall functions.

Which information is important

A single task is only useful if it is properly categorised. Before a change or a retry, you should at least note these fields:

• Task number
• affected group or firewall
• Status
• Time
• Administrator or Credential ID
• Entity and Sub-entity
• displayed error message
• Number of successful and failed firewalls

The time is not always synonymous with the start of processing on each firewall. For group policies, Sophos Central first shows the time of creation or change and updates it later when the policy is applied to firewalls. Therefore, for longer rollouts, you should not only look at the first time.

Correctly interpreting status

Sophos Central can automatically remove tasks with the status Pending after several weeks. For operational documentation, support cases, or change reviews, you should therefore secure relevant errors in a timely manner.

Clean review process

For a blocked Central change, a calm process helps more than repeatedly clicking on retry.

1. Open My Products > Firewall Management > Tasks Queue in Sophos Central.
2. Narrow down the time period and affected firewall or firewall group.
3. Expand the task and check affected firewalls.
4. Document status, error message, entity, sub-entity, and time.
5. Check on the firewall whether the change is visible or only saved in Central.
6. For configuration changes, also check Audit Trail Logs.
7. For traffic issues, evaluate Log Viewer, Policy Test, and relevant service logs.
8. Only then decide whether retry, skip, or a support case is sensible.

If it is unclear which local log is relevant, Sophos Firewall Troubleshooting: Services and Logs can help. For rule and traffic analysis, Testing firewall rules with Log Viewer, Policy Test, and Packet Capture is also suitable.

Skip or Retry?

Sophos Central offers the actions Skip and Retry depending on the status. Both are useful but should not be understood as mere cleanup actions.

⚠️ A failed task should not be skipped just to make the queue look clean. Skip is an operational decision: The unapplied change must then be consciously checked or implemented separately.

Typical error scenarios

Change is visible in Central but not on the firewall

In this case, first check whether the appropriate task was successfully completed. If the task is still Pending, In Progress, Failed, or Partial Success, the problem is not necessarily in the local firewall rule. Only when Central reports the task as successful should you delve deeper into local policy, object, or log analysis.

Only individual firewalls in a group are affected

With group policies, a change can be successful on several firewalls and fail on one firewall. Then you should not change the whole group indiscriminately but expand the affected firewall and check differences: license, firmware version, Central connection, local object conflicts, platform, and known issues.

Firmware task via Central does not start cleanly

If a Sophos Firewall Firmware Update was planned via Sophos Central, the Task Queue should be part of the follow-up. If the firewall remains on the old version, first check whether Central triggered and completed the task. For major releases, the SFOS 22 Upgrade Check is also part of the preparation.

Web or TLS policy sync fails

With Web Protection, URL groups, or TLS exclusions, a Central sync can be particularly confusing because Central has accepted a change that the firewall has not fully processed. Then you should compare the affected entity from the Task Queue with the local configuration. For professional classification, Introducing Sophos Firewall TLS Inspection and Creating Sophos Firewall Web Protection Policy are suitable.

XGS 88/w and Local TLS Exclusion List

In the known issues list, a specific problem with XGS 88/w models is documented: When synchronising a Sophos Central policy, processing the Local TLS exclusion list can fail. The displayed error message refers to a URL group that could not be updated. In this case, you can skip the failed transaction from the Task Queue so that later tasks can continue.

In practice, however, you should not just continue afterwards. A follow-up is important:

• Is the desired TLS exception present locally on the firewall?
• Are the web and TLS policies on the firewall still professionally correct?
• Does the problem affect only one XGS 88/w or multiple firewalls?
• Does the change need to be temporarily implemented locally or postponed?
• Is there a maintenance release or a Sophos notice for the affected version?

Follow-up on the firewall

A successful Central task is a good signal but not yet a complete operational test. Depending on the change, you should check locally:

• Is the changed rule, policy, list, or firmware version visible?
• Does the Log Viewer show expected events?
• Was the change logged in the Audit Trail?
• Are Central connection and reporting still active?
• Do affected users, VPNs, web accesses, or applications function?

For security-relevant changes, you should also define a short rollback point. This is especially true for Web Protection, TLS Inspection, firewall rules, VPN, HA cluster, and firmware updates.

Operational checklist

• Before changes via Sophos Central, clarify which firewalls or groups are affected.
• After Central changes, check the Task Queue.
• Document failed tasks with error message, time, and firewall name.
• Do not treat Partial Success as fully completed.
• Use retry only after cause analysis.
• Use skip only when the professional impact is understood.
• For firmware tasks, plan maintenance windows, backups, and local access.
• For repeated errors, secure Audit Trail, Log Viewer, and Sophos Support information.

FAQ