Properly Configure Sophos Firewall After the Setup Wizard

After the Setup Wizard, a Sophos Firewall is accessible and basically operational; registration is either complete or deliberately deferred on eligible hardware. However, it is not yet securely operated. The wizard handles the start, not the productive architecture.

This article brings together the checks that follow initial setup: internet access, registration, licensing, firmware, backups, zones, Device Access, DNS, DHCP, firewall and NAT rules, logging, and initial hardening. It follows SFOS 22 and serves as a practical checklist for new XGS Appliances, virtual firewalls, and small migrations. Field names match the English Sophos interface; individual pages and options can vary by platform, model, and online or offline setup.

If it involves a migration from XG to XGS Appliance, hardware to virtual, or a restore to a replacement device, you should also check Create or Restore Sophos Firewall Backup and Sophos XG vs. XGS: Differences, EOL, and Migration.

For context: Firewall rules and policies control internet and network traffic. SSL/TLS inspection can intercept and decrypt SSL and TLS connections over TCP. IPS uses rules that help prevent network attacks. Web Protection allows browsing restrictions to be defined based on categories, URL groups and file types. Whether a particular feature is available and how it operates depends on the license and configuration. The intended protective effect must be verified with appropriate tests; successful basic setup is no guarantee of comprehensive protection.

Quick Path After First Login

When the firewall just comes out of the wizard, not every detail is immediately urgent. In the first 30 minutes, it’s mainly about not losing access, securing the state, and recognizing the most significant operational risks.

This order is sensible for most new installations:

1. Secure admin access: Document password, Secure Storage Master Key, and a second admin or break-glass access.
2. Check license and registration: Under Administration > Licensing, verify that model, serial number, base license, and subscriptions are correct.
3. Create a backup: Download a manual backup and store it externally before making further changes.
4. Check firmware and patterns: Verify firmware version, hotfixes, and pattern updates, but only install updates with a maintenance window and rollback plan.
5. Limit Device Access: Do not leave WebAdmin and SSH broadly accessible from client, guest, IoT, or WAN zones.
6. Validate zones and interfaces: Check WAN, LAN, VLANs, bridges, management network, and future security zones against the network plan.
7. Evaluate default rules: Do not adopt initial firewall and NAT rules as a finished security design.
8. Enable logging: Turn on Log firewall traffic for important rules so that later tests are traceable in the Log Viewer.
9. Plan acceptance testing: Do not release production traffic straight from the wizard; first work through a short test plan.

Only when these points are clean should productive traffic, remote access, WAF, SD-WAN, RED, or TLS Inspection be set up. Otherwise, troubleshooting later becomes unnecessarily difficult because it’s unclear whether a problem stems from the basic configuration, a security function, or an application.

Setup Paths by Situation

After the wizard, work quickly branches into several areas. For new firewalls, this order is sensible:

• Central connection: If the firewall should be connected to Sophos Fusion (formerly Sophos Central) or the limits of Central should be understood, Connect Sophos Firewall with Sophos Fusion fits.
• Licence status: For Base License, support and subscriptions, Understand Sophos Firewall Base License helps.
• Backup and restore: Before the first change, Create or restore Sophos Firewall backup should be prepared.
• Management access: WebAdmin, SSH, User Portal or VPN Portal are hardened through Secure Sophos Firewall access: configure Device Access properly.
• Network design: For zones, interfaces, VLANs or bridges, Configure Sophos Firewall zones and interfaces is the better starting point.
• First rules: For firewall and NAT basics, Understand and configure Sophos Firewall rules properly fits.
• DNS and DHCP: Internal name resolution becomes cleaner with Configure DNS Request Routes on Sophos Firewall.
• Reporting: For logs, reports and longer retention, Activate Central Firewall Reporting helps.
• Health Check: Security findings after SFOS 22 can be prioritised with Use Sophos Firewall Health Check properly.
• Upgrade planning: For firmware updates or SFOS 22 upgrades, Check Sophos Firewall before SFOS 22 upgrade fits.

This separation is important because a successful wizard does not mean a finished security architecture. Before productive traffic, management access, backup, license, zones, rules, logging, and protection functions should be consciously checked.

Prepare Before Setup

Before starting the wizard, access, WAN connectivity, management network, and licensing context should be clear. This prevents improvisation during setup and avoids having to correct unclear assumptions later.

Prerequisites for Setup

Before setup, it should be clear how the firewall will be integrated into the network. Many later problems do not arise in the wizard itself but because WAN, LAN, DNS, management access, or license data are improvised.

Have ready before starting:

• Firewall model, serial number, and planned location.
• WAN access data or provider information, such as DHCP, static IP, PPPoE, VLAN, or upstream router.
• Internal target network for the first LAN or management access.
• DNS servers that function during setup.
• A Sophos Fusion account with a full or trial license and a firewall with a base license; for Central connectivity of an already set-up and claimed device, someone who can generate an OTP if needed.
• Planned admin password and storage location in the password manager.
• Planned Secure Storage Master Key (SSMK) and a protected storage location in the password manager or the designated recovery procedure; choose both before starting setup.
• Decision whether the firewall will be newly set up directly or restored via backup.

Have your own Sophos ID ready for sign-in. If you do not yet have a personal Sophos ID, you can create one during setup. This does not replace the invitation and permissions in the intended Sophos Fusion account, selection of the correct tenant, the firewall claim, or its licensing prerequisites. Manage Sophos ID and account access explains account preparation.

The firewall needs a functioning internet connection for registration, license synchronization, pattern updates, and Central connection. If an upstream device filters outgoing traffic, at least the necessary HTTPS access must work. For more complex provider setups, the WAN access should be consciously planned first, rather than guessed during the wizard.

Connections and Network Configuration

Depending on the model, port names and default assignments differ. For many hardware appliances, the first LAN access is possible via the standard address, while larger models may also have a dedicated management port.

In the described factory hardware setup, Port B is the WAN port and obtains its address through DHCP. This is a starting default, not a requirement for every platform or provider: For static addressing, PPPoE or provider VLANs, adapt the WAN configuration to the connection plan.

For initial LAN access using the documented factory configuration, first assign the admin PC an unused IPv4 address in 172.16.16.0/24, for example 172.16.16.2 with subnet mask 255.255.255.0. Connect the PC directly or through the controlled setup network to the intended LAN port; this is Port A in the described hardware example. Only then open https://172.16.16.16:4444. Port names and factory assignments must match the model or platform; these LAN instructions do not replace the separate MGMT access path.

Typical initial accesses:

• LAN port with https://172.16.16.16:4444: Initial setup through the local setup network.
• MGMT port with https://10.0.1.1:4444: Dedicated management access for models with an MGMT port.
• Serial console or local access: Emergency or reimage scenarios.

The client for the initial setup should be connected directly or via a controlled setup network. Old DHCP servers, incorrect VLANs, or a productive switch port with unexpected port configuration can unnecessarily complicate the initial setup.

Configure the dedicated management port

Optionally, the management port’s IP address can be changed in the Setup Assistant. Then complete setup and reopen WebAdmin using the address actually assigned there, with HTTPS and the configured console port; if the default port is unchanged, this is, for example, https://10.0.1.1:4444, provided that this address was retained. After an address change, the admin PC must also be on the appropriate subnet or have an allowed route to the new management network. Subsequent editing under Network > Interfaces and the HA distinction described below remain unaffected.

On models with a dedicated management port, this network should genuinely remain reserved for administrators. Non-administrative users, regular clients or guest devices do not belong in the same management-port subnet. Otherwise, convenient initial access can very quickly become an unnecessary management exposure.

Appliances of 1U and larger have at least one dedicated management port. It appears as PortMGMT under Network > Interfaces, belongs to the LAN zone by default, and initially uses 10.0.1.1. For setup, give the directly connected administration computer a free address in the same subnet, for example 10.0.1.2/24. After setup, change PortMGMT to an address in the intended management VLAN. If access is required through a VPN, allow only the required HTTPS and, if needed, SSH services for the VPN zone under Administration > Device access.

HA note: The official HA and management-port guides conflict on IP addressing. Identical PortMGMT IPs plus an additional Peer administration IP are not a verified general resolution. Before Initiate HA or management-address changes, clarify the HA role and management-addressing requirements for the installed build; stop if the behavior remains unclear and retain independent administrative access.

Accessing the Web Interface

To configure, access the WebAdmin Console via a web browser. Depending on the interface, one of these addresses is used:

• LAN port: https://172.16.16.16:4444
• Management port: https://10.0.1.1:4444

On first access, the firewall uses a locally signed certificate. The browser warning is normal at this moment but should not be ignored later. For productive WebAdmin access, a suitable certificate should be planned, especially if multiple admins, Central Management, or a management FQDN are used.

As long as the default admin user with the default password is still used, additional restrictions apply. SSH from the WAN zone is not rejected normally; the firewall closes the connection silently. WebAdmin from the WAN zone shows a Forbidden message. SCP with the default credentials is not usable in the LAN or WAN zone. Treat this as an installation phase, not an operating model.

The username is admin and the password is admin only if the factory configuration has not been changed. Perform this first login only on an isolated, controlled admin or setup network, and immediately replace the password with a strong, unique password. If the device has already been configured or the password has been changed, use the credentials that are actually valid. Factory defaults are not credentials for production use.

For subsequent browser access, use HTTPS with the firewall’s actual current internal IP address or resolvable hostname and the configured console port, for example https://firewall.example:4444. Replace the example hostname and, if necessary, the port: 4444 is the default, not necessarily the currently configured value. The IP addresses listed above are factory examples and do not automatically remain valid after a change. Console settings are adjusted under Administration > Admin settings. Separately, Administration > Device access controls which zones or sources can access local services; neither account permissions nor signing out replaces these access restrictions. Do not enable unrestricted WebAdmin access from WAN.

WebAdmin Console Browser and Language

The common browsers Chrome, Edge, Firefox and Safari are supported; use a current browser version. The console language applies to menus, buttons, error messages, tooltips and other on-screen text. Since SFOS 20.0 MR1, the firewall automatically detects the preferred browser language. If no matching supported language is available, English is used. The language preference is stored in the browser cache.

To change the language, open the language dropdown on the login page, select the desired language and then sign in. The WebAdmin Console will then use that language. The menu paths and UI labels in this article remain in English for clear navigation; a console in another language displays the corresponding localized labels.

Run the Setup Wizard

The Setup Wizard configures the firewall at a basic level. In this phase, the goal is not the final security design, but to bring the firewall online, registered, and manageable in a controlled way.

Initial Setup with the Setup Wizard

The Setup Wizard collects the basic information and leaves the firewall ready to start. The list below identifies the decisions; it is not a screen order that is identical on every platform:

1. Accept Sophos End User Terms of Use.
2. Start setup.
3. Replace the default admin password with a strong, complex password and store it securely.
4. Set firewall name and time zone.
5. Check the deployment mode and WAN, LAN, and DNS details against the network plan.
6. Enter the serial number or existing license details.
7. Carefully review the automatic firmware installation option. In the claim path described below, Install the latest firmware automatically during setup (recommended) is deselected; the firmware upgrade is then planned separately with a maintenance window and local access.
8. Create the Secure Storage Master Key and record it in the password manager.
9. Complete registration and license synchronization or, if the platform permits it, deliberately defer registration.

If the network settings need changing during gateway setup and the assistant offers this step, open Manual configuration, enter settings appropriate for the network and apply them with Apply. Confirm the dialog with OK and proceed with Continue. Do not copy example values without checking them; this optional sequence is not a universal screen order for every platform.

The Secure Storage Master Key is important for protected data and restore scenarios. It should not be in a local text file on the admin notebook but in a controlled password or recovery procedure. If lost, it can be technically reset, but existing protected backups or data cannot be automatically decrypted.

SFOS 22 applies recommended defaults in the assistant, including settings for hotfixes and Device Access. Treat these as a baseline, not blanket approval: verify the effective settings after the first sign-in. Under Administration > Admin and user settings, pay particular attention to signing out inactive administrator sessions and protection against brute-force sign-in attempts. Do not weaken the recommended values indiscriminately; document the original values before making changes and test sign-in from the intended management network.

Review Sign out administrator session for the inactivity timeout. Under Prevent brute force sign-in attacks, review the number of failed sign-in attempts from the same IP address within the configured time window and the duration for which access is blocked. Record the effective values before changing them; do not deliberately trigger a lockout to test these controls.

For administrator SSH access, public-key authentication is an alternative to password authentication; it does not replace WebAdmin authentication. The SSH access and public-key setup guide explains Administration > Device access > Public key authentication for admin, key handling and testing in a second session while keeping an existing management session open. Keep a working management fallback until the new SSH sign-in is verified.

Choose Gateway Mode or Bridge Mode

The deployment mode in the Setup Wizard is not a cosmetic setting. With This Firewall (Routed Mode), Sophos Firewall acts as the layer 3 gateway, routes traffic, and can replace the existing gateway. This is usually the clearer design for a new installation, but it requires planned WAN and LAN addresses, routes, NAT, and firewall rules.

With Internet gateway (Bridge Mode), the firewall operates inline as a layer 2 bridge in front of or behind the existing router. The current IP scheme can remain in place while traffic passes through IPS, malware scanning, and other protection features. The bridge also forwards STP, RSTP, and multicast routing. Transparent does not mean risk-free: the switch path, loop protection, bridge members, zones, and rules still belong in the network plan.

⚠️ When Finish is selected, the assistant applies the configuration and restarts the firewall. Running the assistant after an HA cluster has already been configured turns off HA. Do not repeat the mode selection in the wizard on an existing HA cluster. Sophos supports HA on bridge interfaces for a new bridge deployment through the assistant, but cabling, role changes, and the data path still require controlled testing.

For models with an integrated wireless radio, configure the protected wireless network and guest wireless network to match the network plan in the corresponding gateway setup step, then select Continue. These choices do not replace checking the intended separation between the guest network and LAN.

On XGS 88w, 108w, 118w, and 128w models, the wizard does not offer Bridge wireless network with LAN. This limitation also applies during gateway setup, so the post-setup configuration below is not limited to Bridge Mode. If LocalWifi0 must bridge directly to the LAN, configure this deliberately after setup under Wireless > Access points > LocalWifi0 > Bridge to Ethernet and test it with a wireless client.

In Gateway Mode, the wizard can additionally enable Enable TAP/Discover Mode for one or more passive monitoring ports. This does not make the routed interfaces passive: only the TAP port observes a mirrored copy. Set up Discover Mode with TAP and SPAN explains the complete SPAN, reporting, and HA workflow.

After the restart, first verify management access, interface status, DNS, and a known test flow in either mode. In Gateway Mode, also check the default gateway, NAT, and Firewall Rule ID. In Bridge Mode, verify both bridge members, STP/RSTP, the router that remains responsible, and a real forward and return path.

Internet Connection and DNS Check

The wizard checks if the firewall reaches the internet. If the check fails, do not just enter “any DNS.” A clean delimitation is better:

• Does the WAN interface have a valid IP address?
• Is the default gateway correct?
• Is PPPoE, VLAN, or static routing needed?
• Can the firewall resolve DNS?
• Is outgoing HTTPS traffic blocked by an upstream device?
• Are date, time, and time zone correct?

For productive environments, DNS should not be randomly set to public resolvers if internal name resolution is needed. After initial setup, internal domains should be cleanly forwarded to internal DNS servers via DNS request routes on Sophos Firewall.

Registration of the Sophos Firewall

Registration connects the firewall with the Sophos license and Central context. It can be done directly in the wizard or later during operation. For productive firewalls, this step should not remain open unnecessarily long because license status, support, subscriptions, and Central functions depend on it.

Claiming assigns the serial number to the correct Sophos Fusion account. It is not the same as subsequently registering an existing firewall for Central Management using an OTP. The online setup route below requires a Sophos Fusion account with a full or trial license and a firewall with a base license.

The following claim procedure assumes an existing serial number. If no serial number is available and the online assistant offers the corresponding second option, that option provides a temporary serial number for a 30-day trial. Then sign in to the intended Sophos Fusion account or create an account, choose the licensing option for the trial and confirm with Claim firewall. The serial number is assigned to the firewall; proceed with Continue. This temporary serial number is neither the evaluation of individual protection modules on an already identified firewall described below nor hardware registration deferral.

Claim a new firewall during online setup

1. In the assistant, deselect Install the latest firmware automatically during setup (recommended) and click Continue. This keeps the upgrade a planned step with a maintenance window and local access, rather than running it alongside registration.
2. Set the firewall name and time zone. Select I have an existing serial number, enter the intended firewall’s serial number, and click Continue.
3. On Claim your firewall with Sophos Central, select Claim in Sophos Central. Sign in to the correct Sophos Fusion account; the English UI labels may still say Sophos Central.
4. In Claim firewall, enter the serial number and click Validate. Check the device assignment before claiming.
5. Choose deliberately between Just claim the firewall with Base license and Claim with 30 days Xstream Protection, Web Server Protection and Email Protection evaluation license. The first option assigns only the base license; the second also starts the named 30-day evaluation. A trial is not a paid protection bundle or a replacement for a planned renewal.
6. Click Claim firewall. Back on the firewall, finish on Basic setup is complete with Skip to finish, or use Continue to configure advanced settings in a controlled way.
7. Once setup finishes, sign in locally and check the serial number and license status under Administration > Licensing. In Sophos Fusion, go to My Products > Firewall Management > Firewall licenses, find the same firewall, and expand the arrow beside its name. The account, serial number, and license details must match the device you set up.

For an already set-up and claimed device, an administrator in a partner or customer environment can instead generate an OTP for the Central Management connection. This avoids sharing super admin credentials, but does not replace claiming or license activation. Connect Sophos Firewall to Sophos Fusion explains the OTP and management workflow.

Important: Sophos Fusion Firewall Management requires a paid subscription beyond the Base Firewall License or an eligible active support license, such as Enhanced Support. The Base Firewall License alone is not sufficient. In addition, the firewall must be able to access the Internet via IPv4 for Central Management.

Defer registration: Only hardware firewalls can remain unclaimed for up to 30 days during initial setup, for example for a demonstration or setup without internet access. This option isn’t available for software, virtual, Azure, or AWS BYOL firewalls.

• With internet access: On Register your firewall, select I do not want to register now. Click Continue, then Continue in the warning prompt, and finish the assistant.
• Without internet access: On Internet Connection, select Continue Offline. Click Continue, then Continue in the warning prompt, and finish the assistant.

Until registration, all local firewall features work except Sophos Fusion and Synchronized Security Heartbeat. After setup, Administration > Licensing must show Registration has been currently deferred on this device. Claim the firewall in Sophos Fusion and complete registration within 30 days. Deferral does not grant paid subscription entitlements; check the actual license status separately.

Activation of Licenses

After registration, the firewall checks its licenses with the Sophos license server. If the firewall has internet access, license information is regularly synchronized. Additionally, synchronization can be manually triggered in the WebAdmin Console.

New subscriptions start when the order is fulfilled, not when the license key is applied. You must still apply the key to assign the license to this firewall. Applying it later changes neither the start nor the expiry date.

Activate a paid subscription on the firewall

Under Administration > Licensing, click Activate subscription, enter the license key, and select Verify key. Compare the displayed subscription details with the order and firewall; click Confirm only if the assignment is correct. The new subscription must then show Subscribed under Module subscription details.

Next, open My Products > Firewall Management > Firewall licenses in Sophos Fusion, find the same serial number, and expand the arrow beside the name. Check that the locally activated subscription also appears there with the expected modules and expiry dates. Activate a Sophos Firewall license key covers the License Schedule, renewals, and activation errors.

Start an evaluation from the firewall

Under Administration > Licensing, click Sign in to Sophos Central in Activate evaluations in Sophos Central. In Activate Evaluations, select only the features you intend to test and confirm with Evaluate selected. Back on the firewall, the selected modules must show Evaluating under Module subscription details. Record the expiry and the decision about continued licensing before production rules depend on these modules.

Apply a subscription in Sophos Fusion and synchronize locally

Alternatively, apply the key centrally:

1. In Sophos Fusion, open My Products > Firewall Management > Firewall licenses, find the firewall by serial number, and expand its details using the arrow.
2. Click Apply subscriptions, enter the subscription key, and select Preview subscription.
3. Check the subscription details and device assignment before confirming with Apply subscription. The new subscriptions must appear in the portal’s firewall details.
4. On the firewall, open Administration > Licensing and click Synchronize. The same subscriptions must appear under Module subscription details with matching statuses and expiry dates.

This checks both directions: local activation in the Central view and central application in the local license view. If they differ, check the serial number, account, WAN, DNS, and system time first, rather than trying the key on other devices. A valid license does not configure a protection policy; test its effect separately.

Under Administration > Licensing, check:

• Is the correct model registered with the correct serial number?
• Is the base license active?
• Are support, Xstream Protection, Standard Protection, or individual subscriptions correctly visible?
• Are expiration dates plausible?
• Has a new license key been truly applied or just stored in the portal?
• Does the firewall show the same status as Sophos Fusion after Synchronize?

Without a suitable license, many protection functions do not work or only work in a limited way. Depending on the function, this affects IPS, Web Protection, Zero-Day Protection, DNS Protection, Central Orchestration, Active Threat Response, or support services. The basics of support and modules are explained in Understand Sophos Firewall OS Base License and What Sophos Firewall Bundles Are Available?.

Connection to the Sophos Fusion Platform

For the local operation of a single Sophos Firewall, Sophos Fusion is not strictly necessary. The firewall can be fully operated via WebAdmin. However, Sophos Fusion offers advantages if these functions are consciously used:

• Central overview of one or more firewalls,
• Central Firewall Management without direct WebAdmin publication from the internet,
• Central backups,
• Central Firewall Reporting,
• Depending on the license, longer log retention and additional reporting functions,
• Security Heartbeat and Synchronized Application Control in Sophos endpoint environments,
• Integration into further Sophos Fusion processes.

The right expectation is important: Sophos Fusion does not replace local operational documentation and a clean admin process. Those who activate Central Management should consciously define roles, MFA, access, backup storage, and reporting retention.

More on this is in the article Connect Sophos Firewall with Sophos Fusion: Advantages and Limits.

Completion of Setup

If the gateway assistant offers a selection of network protection options, deliberately select the options appropriate for the planned network and the licence, and proceed with Continue. This selection does not replace the subsequent review of the protection profiles and their effects either.

In the corresponding wizard step, set an email recipient for notifications and backups and proceed with Continue. Before Finish, compare the configuration summary with the intended settings. Only then finish: The firewall applies the changes and reboots. The HA warning and subsequent checks still apply.

After setup is complete, the firewall restarts or redirects to the login screen. In the claim path described above, Install the latest firmware automatically during setup (recommended) was deselected: completing this path therefore does not mean that the latest firmware has been installed. Check the firmware version actually running after login and plan any required update separately with a backup, a maintenance window and a rollback path. If an automatic update was selected in another setup path and the connection drops during it, this alone is not proof of a hardware fault or a successful upgrade. Once local access is available again, check the firmware version and basic operating state before allowing production traffic.

For that automatic setup-upgrade path, the documented recovery scenario for connection loss is a restart with the firmware with which the firewall was shipped. This can explain seeing the original firmware version again. It is not a guaranteed recovery outcome for every interruption or platform, nor a universal rollback promise for ordinary firmware updates. Verify the active version and basic operating state through local access and keep production traffic on hold until those checks are complete.

Directly after the first login, check:

• Date, time, and time zone.
• Firmware version and pattern updates.
• License status under Administration > Licensing.
• WAN status and internet access.
• Admin password and Secure Storage Master Key in the password manager.
• Backup configuration.
• Accessibility of the WebAdmin Console only from desired networks.
• Default rules, NAT, and DNS.
• Initial logs in the Log viewer.

General WebAdmin Navigation

After every login, Control center opens with an overview of system status and the state of the security features. The search field at the top of the left-hand menu searches menu entries, tabs and section headings. The results also show their respective paths, allowing you to find the relevant settings page without opening every menu individually.

SFOS 22 Header: Navigation and Signing Out

This guidance applies to the documented header in SFOS 22. How-to guides opens the configuration video library, Log viewer opens the Log Viewer in a separate window, and Help opens context-sensitive help for the current page.

Click the signed-in username at the top right, for example admin. The menu provides Support for accessing the support page and opening a support case, About product for the license page, and Console for the CLI console. On HA devices, it also shows the HA type, current status, node names and serial numbers of the Primary and Auxiliary.

When you have finished working, open the username menu at the top right and select Logout so that no signed-in session remains open. Reboot device restarts the firewall and Shutdown device turns it off: both interrupt operation and must be used only as planned maintenance actions, not as substitutes for signing out. The different labels in the explicitly documented SFOS 23 header are covered in the next section; they do not establish that the older menu paths have been removed generally.

SFOS 23 Header: Finding Your Way After Login

This orientation applies specifically to the WebAdmin header documented for SFOS 23; the SFOS 22 setup procedure above remains the baseline.

• The Sophos logo returns to Control center. The header displays the model and serial number. Open the Account icon to check the user role, device name, serial number, firmware version and build before working on the device.
• In the account menu, Command line opens the CLI console and Licenses opens the licence view. To log out, choose Account icon > Sign out. Restart restarts the device; Shutdown shuts it down. Both interrupt operation and are not alternatives to signing out: do not click them just to explore the interface; use them only as planned maintenance actions.
• The question-mark menu provides Help, Videos and Support. The feedback icon opens a feedback window.
• When HA is configured, the separate HA icon opens the cluster status and the names and serial numbers of the primary and auxiliary devices. This is not the HA icon in Sophos Fusion. For configuration and operation, see HA clusters and variants.
• Logs and policy test combines log access with the Policy test tab. Log operation remains covered in the Log Viewer guide; testing firewall rules correctly explains the version-specific test entry point.

Do not generalise the labels: The earlier sign-out section in the SFOS 23 documentation still says Logout, whereas its header section uses Sign out. The unchanged Manage page also says admin > Console, rather than Account icon > Command line. These passages are inconsistent; the new labels here apply only to the explicitly documented SFOS 23 header. They do not establish that the earlier SFOS 22 routes have been removed everywhere.

Make the Firewall Production-Ready After the Setup Wizard

After the wizard, the real work begins: the firewall must be hardened, integrated into the network architecture, documented, and prepared for troubleshooting. These steps have a greater impact on later operation than the wizard itself.

Why the Setup Wizard Is Not Enough

Follow-up work checks interfaces and zones, Device Access, DNS, DHCP, rules, NAT, logs, and backups. Protection profiles such as web filtering, IPS, Application Control, and TLS Inspection are enabled and tested to suit the architecture. The following sections walk through these checks.

First, it’s worth looking into the Control Center. There you can see system status, traffic, user and device information, active firewall rules, reports, and notices like new firmware or health check findings. Warnings and notices in this area should not just be clicked away but used as a practical checklist for follow-up work.

Check Firmware, License, and Backup

Under Backup & firmware, check if the active firmware is up to date. Firmware updates are security-relevant because they include bug fixes, stability improvements, and security fixes. Updates should not be postponed indefinitely but also not installed unprepared.

Sophos Firewall works with two firmware slots. This allows booting back to a previous firmware in case of problems. Nevertheless, a manual backup should be created before each major change. For productive firewalls, plan a maintenance window, check release notes, HA status, free space, VPN dependencies, and external accessibility.

Under Backup & firmware, a regular backup should also be set up. For encrypted backups, a backup password is needed. For restoring sensitive data, the Secure Storage Master Key is also relevant. This key absolutely belongs in a password manager. If lost, it can be reset via the console, but existing protected backups can no longer be normally restored.

Then check under Administration > Licensing if registration, base license, and booked subscriptions are correctly displayed. For the update topic, the articles Sophos Firewall Firmware Update: Preparation and Best Practices and Updating Firmware on Sophos Firewall are helpful. Backups are explained in more detail in the article Create or Restore Sophos Firewall Backup.

Plan Zones and Interfaces Cleanly

The wizard can combine multiple LAN ports into a bridge on hardware appliances. This is practical for a quick start but not always the best target architecture. Under Network > Interfaces, check which ports, VLANs, bridges, or LAGs are really needed.

Each interface is assigned to exactly one zone. This assignment later determines how firewall rules, Device Access, and protection profiles apply. Typical productive zones are, for example, LAN, Server, DMZ, Guest, VoIP, Management, or VPN. Not every VLAN necessarily needs its own zone, but each zone should have a clear security meaning.

More on this is in the article Plan and Configure Sophos Firewall Zones and Interfaces.

Secure Device Access

A common mistake after initial setup is too much management access. Accesses to local services of the firewall, such as WebAdmin, SSH, User Portal, VPN Portal, DNS, or Ping, are not controlled by normal firewall rules. Administration > Device access is responsible for this.

⚠️ WebAdmin, SSH, User Portal and VPN Portal should never be reachable just because the firewall rule base looks clean. These services depend on Device Access and Local Service ACLs. After every change, actively test from which zones and source networks access is really possible.

For productive systems, HTTPS and SSH should not be broadly allowed from insecure zones. If external access is necessary, work with a Local service ACL exception rule and limit access to fixed IP addresses or defined management networks. Alternatively, Sophos Fusion Firewall Management is often the cleaner solution.

More on this is in the article Secure Sophos Firewall Access: Properly Configure Device Access.

Set Admin Accounts, MFA, and Fallback

After the first login, do not work permanently with a shared admin access. For everyday use, individual administrator accounts, clear roles, and documented emergency access are better. This way, it can later be traced who made a change, and a single compromised password does not automatically lead to full access to the firewall.

For new firewalls, this order is sensible:

1. Test at least one second administrative access before broadly activating MFA.
2. Treat the local default user admin as a break-glass account and do not use it as a daily user.
3. Plan to activate MFA for WebAdmin, VPN Portal, and Remote Access.
4. Document roles and responsibilities, especially if Sophos Fusion Firewall Management is used.
5. Define token reset, password storage, and access outside office hours.

MFA reduces the risk of stolen credentials but does not replace access restriction. Therefore, MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access and Device Access belong together. If multiple people work via Sophos Fusion, the Sophos Fusion Administrative Roles should also be checked.

Check DNS, DHCP, and Internal Name Resolution

Under Network > DNS, it is defined how the firewall receives DNS servers: via DHCP, through PPPoE information from the provider, or statically. For internal domains, DNS request routes should be used so that requests for internal zones go to the correct internal DNS server.

In new installations, DNS should be tested with real internal and external names. A test only with google.com is not enough if Active Directory, file servers, printers, management systems, or internal applications are used later. It is especially important whether clients receive the correct DNS servers and whether the firewall does not inadvertently forward internal domains to public resolvers.

Practical DNS check:

• Firewall resolves external names: DNS resolution works for the tested names. Check registration, license synchronization, updates and Central connectivity separately afterwards.
• Client resolves external names: DNS resolution works for the tested names. Also check DHCP assignment, the DNS server used and the firewall rule.
• Client resolves internal names: Internal name resolution works for the tested names. Check whether the intended internal DNS server or the DNS request route is being used.
• VPN or VLAN client resolves internal names: Name resolution also works from the tested network. Nevertheless, check the DNS server, search domain and zone rule against the planned configuration.

DHCP is set up per interface under Network > DHCP. Configure Sophos Firewall as a DHCP server explains how to plan and test the address range, gateway, DNS, lease time and static assignments correctly.

If DHCP is to be forwarded over VPN routes, the firewall can also work as a DHCP relay. For DHCP special options, there is Configure Sophos Firewall DHCP Options.

Check Initial Firewall and NAT Rules

The default outbound rule created by the wizard should not be blindly adopted. Under Rules and policies > Firewall rules, check which source zones are allowed, which destinations should be reachable, and which security features are active. Rules are processed from top to bottom; the first matching rule wins.

For the start, at least one consciously named client-to-internet rule should exist. This rule should not simply allow Any to Any but clearly show source zone, source network, destinations, services, logging, and security features. If the rule is expanded later, it should remain traceable whether it is intended for normal clients, servers, guests, IoT, or management devices.

An initial rule check can look like this:

1. Connect a test client in the intended zone.
2. Check IP address, gateway, and DNS on the client.
3. Generate an external HTTPS call.
4. Search in the Log viewer for source IP, destination, service, and rule ID.
5. Check if the expected firewall rule and NAT rule were hit.
6. Conduct an intentionally not allowed test, for example, from a guest or management zone.
7. Document which rule remains productive and which wizard or test rule is removed.

For NAT: NAT does not allow traffic by itself. It always needs a matching firewall rule. For normal clients to the internet, a source NAT rule with MASQ is usually relevant. For published servers, DNAT plus a matching firewall rule, logging, and an external test from outside your own LAN are needed. For new configurations, standalone NAT rules are usually clearer than linked NAT rules. The basics are in Understand and Properly Configure Sophos Firewall Rules and Understand NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT. If an internal server is to be published, the article Publish Server via DNAT on Sophos Firewall fits.

Consciously Activate Protection Functions

A firewall rule is not automatically a complete protection rule. Depending on the license and target, IPS, Web Protection, Application Control, Malware Scanning, TLS Inspection, Zero-Day Protection, or Threat Feeds should be consciously activated, tested, and documented.

Practical order:

1. Create clean zones and rules.
2. Activate logging for important rules.
3. Activate IPS and Web Protection where they fit technically.
4. Add Application Control for risky or unwanted applications.
5. Introduce TLS Inspection only with a planned approach, test group, CA distribution, and exceptions.
6. Activate Threat Feeds, NDR, or Active Threat Response only when monitoring and false-positive processes are clarified.

For the broader hardening context, Sophos Firewall Best Practices: Network, Rules, and Security fits. For Zero-Day Protection, there is Understand and Operate Sophos Firewall Zero-Day Protection, for TLS Inspection Introduce Sophos Firewall TLS Inspection.

Prepare Logging and Troubleshooting

In important firewall rules, Log firewall traffic should be activated, otherwise, the information needed for troubleshooting is often missing later. Many are not aware of this: If a firewall rule does not log, the corresponding traffic does not appear meaningfully in the Log Viewer. You may see other system events, but not the specific rule decision you are actually looking for.

Under System services > Log settings, you can define which log types are sent locally, to Syslog servers, or to Sophos Fusion. The firewall has local log files and an internal reporting database, but these are not intended as a long-term archive for weeks, months, or years. If logs are to be retained permanently or searched centrally, either an external Syslog server or Central Firewall Reporting is needed.

For Sophos Fusion, roughly: With an active firewall subscription, Central Firewall Reports are available for a limited period. With Xstream Protection or Central Orchestration, longer reporting periods are available. With Central Firewall Reporting Advanced, you get additional storage and significantly longer retention. The details are described in Activate Central Firewall Reporting.

For initial analyses, Log viewer, Policy tester, and Packet capture are usually sufficient. For deeper analyses, you can additionally secure CLI logs, activate debug logs, or use tcpdump. Debug logs should only be turned on selectively and for a limited time because they generate significantly more data. How to test rules is shown in Test Firewall Rule with Log Viewer, Policy Test, and Packet Capture. For Packet Capture, service names, and log files, there are the articles Use Packet Capture Tool in WebAdmin and Sophos Firewall Troubleshooting: Services and Logs. If logs are to be collected for support or external analysis, Secure Sophos Firewall Logs for External Analysis helps.

Acceptance Test Before Productive Traffic

Before going live, do not just check if “the internet works.” A small, documented acceptance test prevents many later support cases.

Where possible, test the rule set offline on a test network first. Another safe staged approach is to run the firewall on the live network with a different gateway address and point only selected test clients to it. Change the gateway address or cabling during the planned maintenance window only after forward and return traffic both pass. If the test fails, point the test clients back to the existing gateway so production remains unchanged.

Sensible tests:

• Admin login from management network: WebAdmin is reachable but not open from unwanted zones.
• Admin login from client, guest or WAN zone: Access is blocked if no deliberate management network is planned there.
• Second admin or break-glass access: Access remains possible if MFA, SSO or a user account fails.
• Client from LAN to internet: Firewall rule, NAT, DNS and security policy work as expected.
• Internal DNS name: DNS request routes or internal resolvers work.
• Blocked test traffic: Log Viewer shows the matching rule or the expected drop.
• Backup download and storage: The backup is not only created but also findable.
• Central or Syslog target: Logs and reports arrive outside the firewall, if planned.

The test should be briefly documented: date, firmware version, location, tested source IP, destination, expected result, and open points. This seems unspectacular but saves time when a VPN, a NAT rule, or a DNS problem needs to be investigated days later.

Checklist After Initial Setup

Check Immediately

• Admin password and Secure Storage Master Key securely stored.
• Firewall registered and license status checked.
• Firmware version and pattern updates verified.
• Manual backup created and stored externally.
• WebAdmin and SSH accessible only from desired networks.
• Actively negative-tested WebAdmin and SSH from unwanted zones.
• Second admin access and break-glass concept tested.
• WAN, DNS, and time zone checked.
• Default firewall rule consciously evaluated.

Check in the First Days

• Zones, VLANs, bridges, and LAGs cleanly planned.
• DNS request routes and DHCP ranges checked.
• Firewall rules and NAT rules documented.
• Logging activated on important rules.
• Central backup or local backup process set up.
• Central reporting, Syslog, or other log target decided.
• First rules validated with Log Viewer, Policy Test, and Packet Capture.

Check Before Productive Operation or Go-live

• Management access hardened.
• MFA and admin roles checked.
• IPS, Web Protection, Application Control, and other protection functions consciously activated.
• TLS Inspection planned only with test and exception process.
• Remote Access, IPsec, WAF, RED, or SD-WAN separately tested, if used.
• Rollback and support path documented.

Common Mistakes

• Wizard configuration is used directly in production: Too broad rules, wrong zones or open management services remain. Work through a dedicated operations checklist after the wizard.
• Secure Storage Master Key not documented: Restore or migration becomes unnecessarily difficult. Store the SSMK in the password manager immediately.
• WebAdmin accessible from WAN or client networks: Bots, brute force and unnecessary attack surface become more likely. Device Access and Local Service ACL Exception Rules should be tight.
• MFA enabled without fallback: Admins can lock themselves out with token, time or group problems. Test second admin, break-glass access and token process beforehand.
• Logging forgotten in rules: Later troubleshooting becomes blind. Log firewall traffic should be active on important rules.
• DNS resolved only with public resolver: Internal names do not work reliably. Plan internal DNS servers and DNS request routes.
• NAT expected without matching firewall rule: Servers or services are not reachable despite NAT. Always check NAT and firewall rule together.
• Firmware update installed without backup: The way back is missing if problems occur. Check backup, release notes and maintenance window before updates.

FAQ