Set up and verify a Sophos Fusion SD-WAN connection group

An SD-WAN connection group lets Sophos Fusion (formerly Sophos Central) build route-based IPsec connections between multiple managed firewalls. This avoids a great deal of repeated configuration in hub-and-spoke or full-mesh topologies. Sophos Fusion can generate tunnels, XFRM interfaces, routes, network objects, and, when selected, the corresponding firewall rules.

Automation does not replace network planning and validation. A green group status mainly confirms that the participating firewalls are active. It does not prove that a specific client can reach the remote destination through the expected rule, route, and NAT handling.

Quick path to a working connection group

Verify an Admin or Super Admin role, the Central Orchestration license, Sophos Fusion management, and firewall-group membership.
Document local networks, WAN addresses, NAT conditions, redundancy, and the intended topology.
Make sure the XFRM address pools do not overlap any production network.
Create a group under My Products > Firewall Management > SD-WAN Connection Groups.
Select the firewalls, shared resources, services, and optionally automatic firewall-rule creation.
Resolve every network and WAN conflict detected by Sophos Fusion individually.
Monitor the Tasks Queue and group status until every participating firewall has been processed.
Check tunnels, Central_ objects, XFRM addresses, routes, and rules on every firewall.
Generate real bidirectional traffic and verify the Firewall Rule ID, route, NAT, and return path.
Add further resources or firewalls only after the first scope has passed validation.

⚠️ Do not delete an active connection group or deregister a firewall from Sophos Fusion during normal operation without planning. Deregistering a firewall causes Sophos Fusion to delete the associated connection group and its automatically generated tunnels. Such a change requires a current backup, a maintenance window, and a documented recovery path.

What Sophos Fusion creates automatically

An SD-WAN connection group uses route-based IPsec VPN. Depending on the topology, Sophos Fusion creates the required connections and configuration objects on the member firewalls. Automatically generated objects use names with the Central_ prefix in the local configuration. They include IPsec connections, XFRM interfaces, network objects, and routes.

In a hub-and-spoke topology, shared resources reside behind the hub firewall. The hub responds as the remote gateway to tunnels initiated by the spokes. The roles follow the shared resources: the firewall sharing a resource is the responder.

In a full mesh, when both firewalls share resources, Sophos Fusion assigns the responder alphabetically by hostname. If the hostnames are identical, it uses the alphabetical order of the firewall IDs. This can enable direct site paths but creates significantly more tunnels and dependencies. Hostnames should therefore be stable and unique; the roles are not freely selected per tunnel.

The option to create firewall rules automatically is convenient, but it does not replace a review of the permitted sources, destinations, and services. If the option is not selected, the required rules must exist locally or in the responsible Sophos Fusion group policy. If it is selected, the generated rules still need to be checked for order, scope, and logging. The underlying principles are explained in Plan and create firewall rules on Sophos Firewall.

Plan the topology and example values

The following example connection group links three firewalls:

FW-HQ shares the server network 10.10.0.0/16.
The branch network 10.20.0.0/16 behind FW-BE needs access to the shared resource.
The branch network 10.30.0.0/16 behind FW-ZH also needs access to it.
Initially, only HTTPS and RDP to selected systems in the server network are required.
The example uses hub-and-spoke with FW-HQ as the hub.

These names and networks are documentation values only. Replace them with the actual firewall names, local resources, and services. Planning must cover more than direct overlaps between the three sites. Remote cloud, partner, VPN client, RED, and management networks must also be compared with the planned resources and XFRM pools.

Understand XFRM address pools

Sophos Fusion uses /30 networks for XFRM interfaces. If no custom pool is configured, Sophos Fusion uses 10.252.0.0/15 and 10.254.0.0/16 by default. If either range already occurs in the environment, choose a free custom pool before creating the first group. You can add several pools; when one is exhausted, Sophos Fusion uses the next.

The setting is located under:

My Products > Firewall Management > SD-WAN Connection Groups > Add IP Pool

A pool change only affects new connection groups. Existing groups keep their assigned XFRM addresses. Changing the pool is therefore not a retroactive repair step for a production group.

Requirements before creation

All participating firewalls must run at least SFOS 18.5 MR1, be Sophos Fusion-managed, and have a Central Orchestration license. Sophos Fusion requires the Admin or Super Admin role to create the prerequisite firewall group and access its policy. Each connection group needs at least two firewalls that already belong to a Sophos Fusion firewall group. A firewall that is registered but not assigned to a group cannot be added.

Also verify the following before creation:

reachable public IP address or FQDN for each WAN path
upstream NAT and the resulting initiator or responder role
unique local resources without overlap
available XFRM networks
active WAN links and intended backup gateways
services permitted between sites
existing local IPsec, routing, NAT, and SD-WAN configuration
independent management access and a current configuration backup

Set up a Sophos Firewall site-to-site IPsec VPN explains the structure of an individual route-based connection. Sophos Fusion performs many of these steps in a connection group, but the underlying routing, rule, and return-path requirements remain the same.

Create the connection group in Sophos Fusion

Select firewalls and resources

Start at:

My Products > Firewall Management > SD-WAN Connection Groups > Create Connection Group

Give the group an unambiguous name, such as HQ-Branches, and optionally a description. Then select at least two firewalls. For each firewall, define the IP address or network range that will be available to the other sites as Shared resources. In the example, only FW-HQ shares the server network, producing the hub-and-spoke role assignment.

Choose resources as narrowly as possible. Instead of sharing the entire headquarters network, a server or application network is often sufficient. Likewise, avoid selecting Any for services as a precaution when only a few applications are required.

Sophos Fusion can optionally create firewall rules. The options also cover authenticated users and Security Heartbeat. Before saving, document whether rules are generated automatically or managed separately. This keeps it clear later whether a missing rule is an error or a design decision.

Resolve network and WAN conflicts

Sophos Fusion checks the selected resources and WAN connections for conflicts. A conflict does not automatically mean that a network is wrong. It means that Sophos Fusion cannot generate an unambiguous connection without an additional decision.

Depending on the finding, the available decisions include:

turn an overlapping subnet off for this connection
attach a unique NAT address to the subnet
define an additional network object
select the appropriate WAN link
select a backup gateway
override the address detected by Sophos Fusion

Every decision changes the resulting data path. NAT addresses, WAN overrides, and disabled networks are therefore recorded in an addressing and routing plan, not merely configured until the status turns green.

A wildcard * in Public IP or FQDN for selected WAN link is allowed only when the remote-gateway firewall is the responder and runs SFOS 20.0 or later. It must not be used to hide an unresolved WAN or NAT condition. The initiator, public reachability, and peer identity must still be unambiguous.

Save the group and monitor tasks

After saving, Sophos Fusion creates the required tasks for all participating firewalls. Keep the existing administrative session open on at least one firewall during this process. Check the connection-group status and details in Sophos Fusion as well as:

My Products > Firewall Management > Tasks Queue

Do not simply skip Pending, Failed, or Partial Success. Record the firewall, entity, error, and time, then compare them with the local configuration. Check the Sophos Fusion Firewall Tasks Queue explains Retry, Skip, Force Sync, and local validation in detail.

Verify the automatically generated configuration locally

After a successful Sophos Fusion task, open every participating firewall separately and verify:

The expected Sophos Fusion connections are active under Site-to-site VPN > IPsec.
The XFRM interfaces have unique /30 addresses from the planned pool under Network > Interfaces.
The generated routes point through the expected XFRM interface under Routing.
Network, host, and service objects named Central_ match the shared resources.
Automatically or separately created firewall rules permit only the planned sources, destinations, and services.
NAT applies only where it was deliberately selected to resolve a conflict.
With multiple WAN paths, gateway and SD-WAN status match the planned primary and backup selection.

If a group contains both shared resources and participating networks, the firewall creates two similar SD-WAN routes: one for the shared resources and one for the participating networks. This is expected deployment behavior, not a duplicate to delete locally without investigation.

Sophos Fusion manages the generated objects. Manual local changes to Central_ objects can be overwritten by a later group change or cause inconsistencies. Changes therefore belong in the connection-group design or the responsible Sophos Fusion policy.

Validate with real traffic

For the first validation, perform at least one real test for each shared-resource path. In the example, a client from 10.20.0.0/16 connects by HTTPS to an explicitly permitted server in 10.10.0.0/16, followed by a test from 10.30.0.0/16.

Check on both sides:

active IKE and Child SAs
the correct Firewall Rule ID
incoming and outgoing interfaces in Packet Capture
the expected source and destination addresses after any deliberate NAT translation
forward and return paths
the application result, not only a ping

A green tunnel or group status is only an intermediate result. Test a Sophos Firewall rule explains the complete validation with Log Viewer, Policy Test, and Packet Capture.

Add SD-WAN profiles and resilience

Sophos Fusion supports SD-WAN profiles for connection groups on SFOS 19.0 and later. The routing strategy is available on SFOS 19.5 and later. Sophos Fusion creates the VPN-tunnel gateway automatically; select an existing gateway on the firewall as the backup. The profile can use First available gateway or Load balancing; load balancing offers round-robin and several session-persistence types. It does not replace a correct route or a working individual VPN connection.

The XFRM address must be in a /30 subnet. Otherwise, Sophos Fusion shows Migrate and, during migration, assigns all tunnel addresses from 10.252.0.0/15 and 10.254.0.0/16. This migration and every profile change alter the data path: preserve a backup and out-of-band access first, change one site or path in a maintenance window, verify Sophos Fusion tasks and the local configuration, and only then expand the rollout.

Test every WAN and tunnel path separately before enabling a profile. Then use real traffic to verify that new connections take the intended path and switch as designed during a planned outage. Health checks use Ping or TCP and up to two probe targets behind the gateway. If a probe target is a public IP address, the destination firewall needs a rule from the VPN zone to the WAN zone. If no gateway meets the custom SLA, the firewall uses the First available gateway strategy. Validate this behavior in a planned failover test.

The local routing logic, SLA values, and failover validation are covered in Configure a Sophos Firewall SD-WAN route. Sophos Fusion simplifies distribution but does not change the meaning of gateways, route precedence, NAT, or session behavior.

Troubleshoot by symptom

A firewall cannot be selected

Check Sophos Fusion registration, the valid license or Orchestration entitlement, and membership in a Sophos Fusion firewall group. Then determine whether an open group or synchronization task is blocking the change.

A task failed or was only partially successful

Do not immediately recreate the group. First preserve the task details and local partial configuration. Common causes include object or network conflicts, unreachable firewalls, license restrictions, or a group policy that could not be applied fully. Retry only after correcting the cause.

The tunnel is active but application traffic is missing

Compare shared resources, service selection, and the firewall rule with the real flow. Then check the route, XFRM interface, NAT, route precedence, and return path. A ping is meaningful only if ICMP is allowed and the target is intended to respond.

Only one WAN or backup path works

Check the public address or FQDN, upstream NAT, gateway role, WAN link, and backup gateway. For an SD-WAN profile, continue with the SLA target and gateway status. A wildcard address or green tunnel must not conceal missing end-to-end reachability.

A pool change does not appear in the group

This is expected for existing connection groups. New IP pools are used only by groups created afterward. Do not delete and recreate a production group merely to change addressing; plan impact, downtime, and rollback first.

Sophos Fusion is green but the application remains unavailable

Do not interpret the group status as application monitoring. Check logs, rule IDs, Packet Capture, routing, and NAT on both firewalls at the same time. In HA or distributed processing, use the node that handled the test traffic.

Make changes and roll back safely

Before a major group change, record the connection-group configuration, firewall members, shared resources, WAN assignment, XFRM pool, automatically generated rules, and a working test flow. Also preserve a current firewall backup.

If an expansion fails, do not delete the entire group reflexively. First reverse only the newly added resource, firewall, or profile change in the assistant. Wait for the Sophos Fusion tasks to finish, then verify that tunnels, routes, rules, and the previously recorded test flow match the baseline again. Only that result confirms the rollback; saving the change alone does not.

If the connection group must be removed completely, do so in a maintenance window. Alternative site paths or manually managed tunnels must be ready first. After deletion, check every firewall to make sure the associated Central_ objects were removed and no orphaned rules, routes, or NAT dependencies remain.

Release checklist

All firewalls are Sophos Fusion-managed, licensed, and assigned to a firewall group.
Resources, services, WAN paths, and XFRM networks are documented and free of overlaps.
Every detected conflict was resolved deliberately.
All Sophos Fusion tasks completed with a documented result.
Tunnels, XFRM interfaces, routes, rules, and Central_ objects were checked locally.
A real bidirectional application test works for each site path.
Primary and backup paths were tested in a maintenance window.
Backup, management access, and recovery path are documented.

Frequently asked questions

Does a connection group replace local IPsec and routing knowledge?

No. Sophos Fusion automates repeated creation, but the data path remains route-based IPsec with XFRM interfaces, routes, firewall rules, and possibly NAT. These layers still need to be understood for troubleshooting and validation.

What does a green status in Sophos Fusion prove?

Green means that all firewalls in the connection group are active. Orange means that at least one is inactive; red means that all are inactive. This tunnel overview does not prove that every resource is reachable through every rule and application. Local checks and real test connections remain necessary.

What happens when a firewall is deregistered?

Sophos Fusion deletes the associated connection group and the tunnels it created. A firewall must therefore not be deregistered and registered again as a routine troubleshooting step. This change belongs in a maintenance window with a backup and a prepared replacement path.