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

An SD-WAN connection group lets 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. Central 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 the Central Orchestration entitlement, Central management, and firewall-group membership for every firewall.
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 Central 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 Central during normal operation without planning. Deregistering a firewall causes Sophos Central 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 Central creates automatically

An SD-WAN connection group uses route-based IPsec VPN. Depending on the topology, Sophos Central 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. This suits, for example, a head office with server networks and several branches.

In a full mesh, Central connects every firewall to all other group members. This can shorten direct site paths but creates significantly more tunnels and dependencies. The design should therefore first establish whether every site really needs direct communication with every other site.

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 Central 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.
FW-BE shares the branch network 10.20.0.0/16.
FW-ZH shares the branch network 10.30.0.0/16.
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

Central uses /30 networks for XFRM interfaces. If no custom pool is configured, Sophos Central 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.

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 require Central management and the appropriate Central Orchestration entitlement. They must also already be members of a firewall group in Sophos Central. A firewall that is merely registered but not assigned to a Central firewall group is not available for the connection group as expected.

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

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, then select the participating firewalls and topology. For each firewall, define the local networks or hosts that will be available to the other sites as Shared resources.

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.

Central 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

Central checks the selected resources and WAN connections for conflicts. A conflict does not automatically mean that a network is wrong. It means that Central 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 Central

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 * as a public address or FQDN is appropriate only for a remote-gateway side that operates as responder. It must not be used to hide an unresolved WAN or NAT condition. The initiator, DNS, public reachability, and peer identity must still be unambiguous.

Save the group and monitor tasks

After saving, Central 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 Central 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 Central Firewall Tasks Queue explains Retry, Skip, Force Sync, and local validation in detail.

Verify the automatically generated configuration locally

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

The expected Central 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.

Central 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 Central 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

Central can use SD-WAN profiles for connection groups when the participating firewalls and XFRM interfaces meet the requirements. A profile defines how multiple gateways are evaluated and used. It does not replace a correct route or a working individual VPN connection.

Test every WAN and tunnel path separately before enabling a profile. Then use real traffic to verify that new connections take the intended primary path and switch to the backup path during a planned outage. Health checks should target a system that meaningfully represents the required end-to-end path.

The local routing logic, SLA values, and failover validation are covered in Configure a Sophos Firewall SD-WAN route. Central 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 Central registration, the valid license or Orchestration entitlement, and membership in a Central 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.

Central 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. Remove only the newly added resource, firewall, or profile change first, and verify that Central redistributes the previous configuration completely. Then repeat the local tunnel, route, rule, and traffic tests.

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 Central-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 Central 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. Central 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 Central prove?

It shows that the participating firewalls are active or that the overall group status appears healthy. It 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 Central 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.