Skip to content
Avanet

Use Sophos Central Firewall Groups and Full Sync Safely

A Firewall Group in Sophos Central is a shared configuration template for multiple firewalls. It saves work, but also changes ownership: once a firewall fully follows the group, supported rules, objects, and settings are managed centrally.

The critical decision occurs when adding the firewall. With Full Sync, it adopts the complete supported group configuration. With Skip full sync, the current configuration initially remains, but later group changes are still distributed. Skip full sync is therefore not a permanent separation from the group.

⚠️ Before the first Full Sync, create a current firewall backup, keep a local administrator session open, and test the recovery path. A successful Central task does not prove that routing, NAT, authentication, and production traffic work correctly.

Quick Path for a Safe Introduction

  1. Select a representative pilot firewall and inventory its local configuration, rule order, and dependencies.
  2. Create an empty group under My Products > Firewall Management > Firewalls > Create New Group.
  3. Deliberately select Use Sophos default or Import existing configuration and inspect the resulting group policy before assignment.
  4. Initially add the pilot firewall with Skip full sync only when its current configuration must remain.
  5. Roll out a small, clearly identifiable group change and check the Task Queue.
  6. Validate the change locally on the firewall and with real test traffic.
  7. Only then plan additional firewalls, subgroups, or a full sync.

What a Firewall Group Manages

Open the group policy through Manage Policy. It resembles the local WebAdmin but applies to every assigned firewall. Central distributes supported objects and settings; purely local or interface-specific configuration is not automatically part of the template.

This matters especially across different sites. A shared rule can work only when its zones, dynamic interfaces, networks, services, and dependencies resolve meaningfully on every target. Deliberately planned subgroups or Dynamic Objects are better for site-specific values than later local corrections.

Objects, Settings, and Subgroups

Objects such as firewall rules, NAT rules, FQDN hosts, and IP hosts can be created and deleted in a group policy. Subgroups inherit read-only copies of parent objects but can use them as a basis for their own rules. If a subgroup uses a parent object, Central prevents its deletion and shows the dependency.

Settings with an Apply button are configured only in the top parent and inherited by all subgroups. A subgroup cannot override these settings separately. Before building a hierarchy, establish which values must genuinely be identical at every site.

Create the Group and Select the Initial Configuration

Under My Products > Firewall Management > Firewalls > Create New Group, two starting points are available:

  • Use Sophos default: Creates a new group policy from Sophos default values. This is straightforward for a new design deliberately built in Central.
  • Import existing configuration: Uses the configuration that Central supports from an existing firewall as the template. Interfaces and other local configuration are not imported completely.

Group creation can fail during import if firewall rules reference unsupported user types. Sophos lists AD, Sophos Live, L2TP, and PPTP users. Before importing, inspect the affected rules, user objects, and Task Queue; do not force a failed import by spontaneously deleting production rules.

An empty group is often the safest starting point. Prepare and inspect the policy before assigning a firewall. Connect Sophos Firewall to Sophos Central explains the firewall registration itself.

Select Full Sync or Skip full sync Correctly

Full Sync

Full Sync applies the complete supported group configuration to the firewall. It fits when the group policy is the intended state and local deviations may deliberately be replaced.

Before running it, compare at least firewall and NAT rules, hosts, services, authentication dependencies, certificates, VPNs, web and TLS policies, and Local Service ACLs. A current backup, management access, and a maintenance window belong to the change.

Skip full sync

With Skip full sync, the existing configuration is not completely replaced when the firewall is assigned. It can initially differ from other group members. New or later changed group objects and settings are still distributed to it.

This mode fits a controlled adoption of individual future Central changes. It is unsuitable when local and Central administrators intend to maintain the same object independently. Before each group change, establish whether an existing or identically named object on the pilot firewall will be overwritten or supplemented.

A later Force sync applies the complete group configuration. For an HA pair, this action is available only on the active firewall. Trigger it only after documenting and technically validating the difference between the local state and the group policy.

Change and Distribute the Group Policy

  1. In My Products > Firewall Management > Firewalls, open Manage Policy from the group menu.
  2. Change only the planned rule, object, or setting.
  3. Return to Central and expand the task under My Products > Firewall Management > Tasks Queue.
  4. Document status, affected firewalls, entity, timestamp, and error message.
  5. Perform local validation only after Successful or a clearly understood partial status.

For firewall and NAT rules, Top and Bottom apply only within the Central policy. Central rules are inserted above local rules on the firewall. Mixed management can therefore produce different matches than expected. On centrally managed firewalls, maintain related rules consistently through Central and verify them using the actual Firewall Rule ID or NAT Rule ID.

Validate the Effect Locally

A successful task shows that Central processed the request. Technical validation takes place on every affected firewall:

  • Is the expected object or setting visible and complete?
  • Is the effective rule order correct?
  • Does a defined test flow match the expected firewall and NAT rule?
  • Do forward and return paths, DNS, authentication, and dependent services work?
  • Does an intentionally prohibited test remain blocked?
  • Does the Audit Trail show the expected administrator, time, and change?

Document success and failure per firewall across multiple sites. Do not summarize a partially successful rollout as a group success. Test Sophos Firewall Rules covers rules, Policy Test, Log Viewer, and Packet Capture.

Troubleshoot Safely

Firewall Remains Out of Sync

First check group membership, the Central connection, license, task status, and the specific error message. Use Retry only after resolving the cause. Skip only removes the task from processing; the omitted configuration remains technically unresolved.

Local Rule Behaves Differently After a Push

Check the effective rule order, Rule ID, object resolution, and NAT. Central rules sit above local rules. The answer is not another broad allow rule, but clear ownership and ordering for the affected rule block.

Import of an Existing Firewall Fails

Save the error message and referenced entities. Then check unsupported user references, local interfaces, and other dependencies that cannot be imported. If the cause remains unclear, escalate with task data and the firewall backup to Sophos Support instead of experimentally deleting production objects.

Rollback and Operations

A firewall can be removed from the group, but policies already distributed from Central remain on it. Removal is therefore not an automatic rollback. Inspect the previously documented objects locally before deleting or replacing any rule or object.

For reliable operations, every group change needs an owner, task reference, local test, and rollback decision. Test extensive changes on a pilot firewall or subgroup first. Audit Trail Logs and a current backup remain necessary with Central management.

Checklist

  • Pilot firewall and management recovery path are tested.
  • Backup and initial configuration are secured.
  • Use Sophos default or Import existing configuration was selected deliberately.
  • Full Sync or Skip full sync matches the intended ownership model.
  • Group objects, settings, subgroups, and dependencies are checked.
  • Task Queue shows the expected status for each firewall.
  • Rule order, Rule IDs, and real traffic are validated locally.
  • Rollback accounts for Central policies remaining after group removal.

FAQ

Is Skip full sync a permanent exception from group changes?

No. The existing configuration initially remains when assigning the firewall, but later group policy changes are distributed to it.

Does removing a firewall from the group undo Central changes?

No. Policies already distributed remain on the firewall. A rollback must explicitly inspect and restore the affected rules, objects, and settings.