Using Sophos Firewall Config Studio

Sophos Firewall Config Studio is a browser-based Sophos tool that allows you to view, compare, and prepare firewall configurations. It is particularly useful when you want to know not just that something has changed, but which rule, object, or setting is affected.

In practice, Config Studio is well-suited to three situations:

• Comparing two configurations before and after a maintenance window.
• Making an existing firewall configuration more readable for review, handover, or audit.
• Preparing changes before they are implemented on a production firewall.

However, Config Studio does not replace a backup, change process, or testing. It is an analysis and preparation tool. Changes must still be carefully checked, documented, and secured with a rollback plan.

Video Guide

What Config Studio Can Do

Config Studio is the successor or further development of the former Sophos Firewall Configuration Viewer. Three functions are particularly relevant for operation:

The main advantage lies in the comparison. If you need to know what has really changed after an update, migration, or change, a visible diff is much faster than manually reading backup files.

When to Use Config Studio

Config Studio is particularly worthwhile for changes that affect multiple areas of the firewall.

Typical examples:

• Migration from XG to XGS.
• Restore to different hardware or a virtual appliance.
• Review of a large firewall rule set.
• Comparison before and after a firmware update.
• Check after a major NAT or VPN overhaul.
• Handover of a firewall from one team to another.
• Analysis after an unplanned change.

If it’s just about a single live connection, other tools are usually more direct. For traffic issues, Log Viewer, Policy Test, and Packet Capture are more suitable. The article Testing firewall rules with Log Viewer, Policy Test, and Packet Capture shows this process.

Create a Clean Backup First

Config Studio works with configuration data. Therefore, a complete and current backup of the firewall should be created first.

The WebAdmin path is:

Backup & Firmware > Backup & Restore

For productive work, this procedure is recommended:

1. Create a current backup of the firewall.
2. Securely store the backup outside the firewall.
3. If a change is planned, additionally document the desired target state.
4. Create a second backup after the change.
5. Compare both configurations in Config Studio.

The actual backup and restore topic is described in the article Creating or restoring a Sophos Firewall backup. Secure Storage Master Key, restore compatibility, and interface mapping are also covered there.

⚠️ Firewall backups contain sensitive information about network structure, rules, objects, VPNs, and services. Before using an analysis tool, it should be clear internally where the file is processed, who has access, and how it is deleted or archived afterward.

Handle Entities.xml Securely

Config Studio works with the exported configuration. Processing takes place in the browser of the end device; configuration data is not uploaded to an external service. Nevertheless, the file remains security-relevant because it describes the firewall structure in great detail.

For operation, you should not only plan the download of the file but also how to handle it afterward:

• Open the file only on a trusted admin device.
• Do not share the file via private cloud storage, messengers, or uncontrolled email distribution.
• Limit access to change, audit, or migration participants.
• Delete the file after analysis or archive it in a defined, protected storage location.
• When passing it to support or external partners, first clarify which data is included and whether approval exists.

Especially for audits and migrations, a simple naming convention is helpful. Example: firewall-location-before-change-2026-06-21.xml and firewall-location-after-change-2026-06-21.xml. This makes it clearer later which file represents which state and whether it was created before or after a maintenance window.

Check Configuration as a Report

The Configuration Report helps to read a firewall in a structured way. This is particularly useful when taking over an existing environment or needing to understand what rules and objects are present before an audit.

During the review, you should not simply look for “many rules.” More important are specific operational questions:

• Are there rules with very broad sources, destinations, or services?
• Are old VPN, NAT, or WAF rules still active?
• Are there objects that are similarly named multiple times?
• Are management accesses cleanly restricted to own networks?
• Are logging, IPS, Web Protection, TLS Inspection, or NDR consciously set?
• Do rule groups, names, and descriptions match the actual operation?

For management accesses, you should also check Configuring Device Access correctly. Normal firewall rules do not control who can access local services of the firewall such as WebAdmin, SSH, User Portal, or VPN Portal.

Compare Two Configurations

Comparison is the strongest use case of Config Studio. You load two configuration states and then check which entries have been added, removed, or changed.

Meaningful comparison pairs are:

The comparison does not replace the Audit Trail. Config Studio shows what is different between two configurations. The Audit Trail helps to see who made which change and when. In a clean analysis, you use both: first narrow down the time period and responsible party via audit logs, then examine the configuration difference in detail.

Interpreting the Diff Result

A configuration comparison is only helpful if the result is triaged. Not every change is technically relevant, and not every missing change is automatically uncritical.

During the review, you should sort the differences into groups:

Changes to firewall rules, NAT rules, interfaces, VPNs, certificates, authentication, Device Access, and hosts and services are particularly important. In these areas, a small difference can directly affect whether a service remains accessible, whether a VPN tunnel routes, or whether an admin access is possible from the correct network.

For productive change reviews, you should not only save the Config Studio result. A short note is useful: checked backup files, noticeable objects, expected changes, unexpected changes, open questions, and decision whether the change is complete or needs to be reworked.

Preparing Changes

Config Studio can also edit configurations or provide changes as API or curl format. This is powerful but should not be understood as a shortcut for unchecked mass changes. If such exports are used productively, XML API access should be properly restricted beforehand.

Prepared changes should go through at least these checkpoints:

1. Prepare change in Config Studio.
2. Check affected objects, rules, and dependencies.
3. Validate change in a test or replacement environment if possible.
4. Prepare backup and rollback plan for the productive firewall.
5. Implement change during the maintenance window.
6. Then check Log Viewer, affected services, and configuration comparison.

Be particularly cautious with NAT, VPN, interfaces, Device Access, authentication, and HA configurations. A seemingly small difference can have a direct impact on accessibility or failover behavior.

⚠️ Editor outputs from Config Studio should never be directly copied from the browser into a productive firewall without checking dependencies, backup, test, and rollback. This is especially true for mass changes to objects, rules, VPNs, and interfaces.

Use in Migrations

In migrations, Config Studio is a good tool but not the first step. First, check whether the backup matches the target platform.

Important questions:

• Is the migration from XG to XGS?
• Does the number or order of interfaces change?
• Is there a switch from hardware to virtual or cloud?
• Is an HA cluster involved?
• Does an interface mapping need to be adjusted after the restore?
• Are there old VPN, RED, wireless, or legacy configurations?

Config Studio should be used at the right point in this process. It shows differences and helps with the review but does not alone decide whether a restore is technically supported or whether the new firewall really works cleanly after the migration.

Therefore, a green gut feeling after the import is not enough for acceptance. You should define beforehand which services must function after the migration, which rules are critical, and which measurement points need to be checked. These include at least Log Viewer, Policy Test, Packet Capture, central logs, and the most important user or site tests.

For XG-to-XGS projects, What is the difference between an XG and XGS Firewall? is also suitable. If an HA cluster is involved, Setting up Sophos Firewall High Availability should also be considered before the restore.

Troubleshooting in Config Studio Analyses

Import Does Not Work

If Config Studio cannot load a file, first check whether the correct export file is actually being used. For Config Studio, the Entities.xml from Backup & Firmware > Import export is relevant, not any compressed backup or a screenshot from the firewall.

Additionally check:

• File was fully downloaded.
• Browser does not block local file or JavaScript functions.
• File comes from a supported Sophos Firewall version.
• Export was not manually edited afterward.

Diff Contains Many Changes

Many differences do not automatically mean that a change was bad. System-related changes can appear during firmware updates, migrations, or restore tests. The decisive factor is whether the technically relevant areas are plausible: rules, NAT, interfaces, VPN, certificates, authentication, hosts and services, and Device Access.

If the comparison becomes confusing, you should first filter by modules and not evaluate everything at once. For disruptions after a change, the combination of Config Studio, Audit Trail, Log Viewer, and Packet Capture is often faster than a complete manual review of all objects.

Editor Export Does Not Match Planned Import

If a prepared export does not fit as expected, the change should not be improvised productively. First check:

• Was the correct starting configuration used?
• Are there dependent objects missing in the target system?
• Do names, zones, interfaces, and services match the target firewall?
• Is XML API access allowed and sufficiently restricted for the account used?
• Is there a current backup and a way back?

For API or curl outputs, checking the API account, source IP, and rights is part of the change. The article Securing Sophos Firewall XML API Access describes this part in more detail.

Common Mistakes

Checklist for Admins

Before Use:

• Create a current backup.
• Internally regulate access to backup files.
• Process Entities.xml only on a trusted admin device.
• Define the purpose of the analysis: audit, migration, change review, or troubleshooting.
• Prepare relevant times and change tickets.

During Comparison:

• Select the correct backup versions.
• Check added, removed, and changed entries separately.
• Pay special attention to firewall rules, NAT, interfaces, hosts and services, VPN, and Device Access.
• Match noticeable changes with configuration-audit.log.
• Document unexpected changes and assign them to a responsible person.

After Analysis:

• Document the result.
• Clarify unexpected differences.
• Secure a new backup state for productive changes.
• If a restore or import is planned, define rollback and maintenance window beforehand.

FAQ