Use Sophos Fusion Firewall Groups and Full Sync Safely

A Firewall Group in Sophos Fusion (formerly 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, Central pushes all existing supported group configurations. With Skip full sync, Central does not push those existing group configurations during assignment; group changes applied afterward still reach the firewall. 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.

Requirements

You need the Admin or Super Admin role in Sophos Fusion to create a group and open its policy. The firewalls must already be registered and approved for Central Management. Sophos requires an active paid firewall subscription other than the Base License or an active support contract, and the internet connection to Central must use IPv4. Connect Sophos Firewall to Sophos Fusion covers registration and approval.

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. Open Edit Group from the group menu, move the pilot firewall from Available Firewalls to Assigned Firewalls, and select Skip full sync only when its current configuration must initially 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.

Dynamic Zones and Dynamic Interfaces

A Dynamic Object maps a logical group-policy zone or interface to the matching local object on each firewall. Create it under My Products > Firewall Management > Dynamic Objects on the Zones or Interfaces tab and specify the mapping for each firewall. For Dynamic Interfaces, the IP Address Family and Interface Type must match the local interfaces.

The Default (Any firewall) mapping also applies to firewalls added later. It is therefore safe only when the selected zone or interface exists on every device without an individual mapping. Check all mappings before rollout; Usage References shows the group and policy section that uses the Dynamic Object.

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.

Select Full Sync or Skip full sync Correctly

Full Sync

Full Sync pushes all existing supported group configurations to the firewall. It fits when the group policy is the intended state and its effect on the local configuration has been assessed.

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, Central does not push the group’s existing configurations when the firewall is assigned. The firewall can therefore differ from other group members. Group changes applied afterward are distributed to all firewalls in the group.

Central then shows the firewall as Connected, although a configuration mismatch can exist between the firewall and the group policy. The status alone therefore does not prove identical configurations.

This mode supports controlled adoption of future Central changes, but it does not create an independent local ownership model. Before each group change, establish which local configuration it can affect and how you will validate the result.

A later Force sync pushes all group configurations. Under Sync & Management, click the Connected status and then Force sync. For an HA pair, the link is available only for 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