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, SFOS 20.0 or later, the Central Orchestration licence, Sophos Fusion management and group membership for all firewalls; AWS or Azure deployments must use BYOL rather than PAYG.
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. Normally, the hub responds as the remote gateway to tunnels initiated by the spokes. This suits, for example, a headquarters with server networks and several branches. Roles normally follow the shared resources: the firewall sharing a resource is the responder. There is an exception for a dynamic WAN address with a wildcard override: even the resource-sharing firewall remains the initiator in this case. The prerequisites are explained under Resolve network and WAN conflicts.

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.
Behind FW-BE, the branch network 10.20.0.0/16 needs access to the shared resource.
Behind FW-ZH, the branch network 10.30.0.0/16 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

The orchestration workflow described here requires SFOS 20.0 or later on every participating firewall, Sophos Fusion management and a valid Central Orchestration licence. The older minimum of SFOS 18.5 MR1 does not establish version support for this workflow. For Sophos Firewall in AWS or Azure, BYOL (Bring Your Own License) is supported; PAYG (Pay As You Go) is not supported for SD-WAN Orchestration. Before adding a cloud firewall, check its deployment and licensing model, not just the SFOS version.

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

On the resource-sharing firewall, the assistant only lets you enable or disable the network; it does not offer NAT assignment. To continue sharing an overlapping network, first resolve the address conflict on that firewall or in the network design. Simply enabling it does not resolve the overlap. On the accessing firewall, the NAT option can be used to resolve the conflict. Before saving, therefore check for each overlapping network which firewall shares it, which accesses it, and whether the chosen measure actually resolves the conflict. If a network is excluded instead, it is unavailable through this connection group.

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. A resource-sharing firewall with a dynamic WAN address and wildcard override remains the initiator and uses the IPsec profile Central_DefaultBranchOffice. Its peer must be the responder and run SFOS 20.0 or later. Sharing resources alone therefore does not make the dynamic firewall the responder in this case.

Before setting *, document the dynamic local firewall, its initiator role and the reachable responder peer with its SFOS version for each WAN path. After deployment, check that the generated IPsec connections’ roles, profile and WAN assignment match this plan, and verify the resource path with real application traffic. Do not use the wildcard to hide an unresolved WAN or NAT condition. The initiator, public reachability and peer identity must remain unambiguous; do not indiscriminately rewrite centrally generated profiles locally.

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.

After tasks complete, also check tunnel status: GOOD means the VPN tunnel is established; DOWN means it is not established or connectivity has been lost. UNKNOWN, by contrast, means no heartbeat information has arrived for approximately five minutes, so Sophos Fusion cannot determine tunnel status. This is neither a proven tunnel outage nor successful validation. For approval, the expected tunnels must report GOOD and pass the local checks below.

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 behaviour, 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

The following minimum versions concern individual profile features and do not replace the SFOS 20.0 or later prerequisite for the orchestration workflow described here.

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 behaviour 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 behaviour.

Troubleshoot by symptom

A firewall cannot be selected

Check Sophos Fusion registration, the valid licence or Orchestration entitlement, and membership in a Sophos Fusion firewall group. Then determine whether an open group or synchronisation 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, licence restrictions, or a group policy that could not be applied fully. Retry only after correcting the cause.

Tunnel status is UNKNOWN

First check Sophos Fusion connectivity, heartbeat and synchronisation status for the affected firewalls, along with the Tasks Queue. In parallel, use independent management access to check local tunnel status under Site-to-site VPN > IPsec and perform the documented application test. If the local tunnel and application traffic work, central status evidence is initially what is missing; do not delete or recreate the group solely because of UNKNOWN. If the local connection is also disrupted, check WAN reachability, IKE/Child SAs and the data path. After restoring heartbeat delivery, check again whether Sophos Fusion reports GOOD. If UNKNOWN persists despite healthy connectivity, preserve status, timestamps and task details for further troubleshooting.

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.

When an update recreates objects

An expansion generally adds the required configuration; existing tunnels, routes and firewall rules remain intact as long as their creation criteria are unaffected. An additional branch does not automatically rebuild every existing connection. However, changing the conditions for centrally managed firewall rules, NAT rules or SD-WAN routes causes Sophos Fusion to remove and recreate the affected objects. This includes changes to:

local or permitted source networks;
Shared resources or destination networks;
services and ports;
user or Security Heartbeat conditions;
NAT used to resolve overlapping subnets;
backup gateways or the assignment of SD-WAN routes to gateways.

For example, changing the permitted service from HTTPS to another service in the existing HQ-Branches design can trigger recreation of affected access rules and routes; it is not merely a description change. Before saving, compare affected source networks, destinations, services and paths against the previous test flow. Schedule object-recreation changes in a maintenance window allowing for possible interruption; an unchanged tunnel alone does not guarantee that access remains correct.

Save only one orchestration change per cycle. While Sophos Fusion creates, updates or deletes the group, do not make parallel interface, WAN, LAN or network changes on the firewalls. After tasks complete, recheck the newly generated Central_ rules, NAT mappings and routes on affected firewalls, identify the Firewall Rule ID currently in use, and repeat both the previous and changed application tests. If gateway assignment changes, also check the backup path. Local corrections or deletions of Central_ objects are not a rollback path: make the intended change in the connection group.

Revert an expansion or remove the group

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 run SFOS 20.0 or later, are Sophos Fusion-managed, licensed and assigned to a firewall group; AWS/Azure firewalls use BYOL.
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.
Expected tunnels report GOOD; any UNKNOWN has been clarified and is not counted as a successful tunnel test.
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.