Sophos Firewall in failsafe mode: check the cause

When a Sophos Firewall starts in failsafe mode, SFOS has detected a critical error and has not entered normal operation. Depending on the cause, packet processing, interfaces, and management access may fail completely or partially. A management port that remains accessible must therefore not be taken as proof that the firewall is still providing reliable protection.

The most important first step is not a Factory Reset or reimage, but preserving the cause detected by SFOS:

1. Connect through the local, serial, or hypervisor console.
2. Open Device Console in the failsafe menu.
3. Run the following read-only command:

show failure-reason

The console may then look like this, for example:

failsafe> show failure-reason
Unable to apply Firewall Framework

failsafe> is only the prompt and must not be entered. The exact message may differ. What matters is photographing or copying the unchanged output and the first visible console lines. If SSH still works while the error is present, Device Console can also be reached through it; the local, serial, or hypervisor console remains the more robust method during an outage.

⚠️ Preserve evidence before restarting: A reboot can change or temporarily resolve the visible error condition. Before restarting, document at least the error message, SFOS version including build, appliance role, and time. Reset to Factory Defaults, Remove Firewall Rules, and manual database or file-system changes are not diagnostic measures and can destroy important configuration or evidence.

What failsafe mode means

Failsafe is a protection and recovery state. SFOS enters it when a component required for secure firewall operation fails to start correctly. Known messages and real-world failures can affect, for example, the configuration database, firewall framework, ruleset, logging or network service, signature database, or, on an appropriately equipped XGS model, the Network Processing Unit (NPU). This is not a complete repair matrix; the specific console output remains decisive.

WebAdmin being unreachable on its own does not prove a failsafe condition. If traffic continues to flow and only the interface is unresponsive, first perform the targeted check or restart the WebAdmin GUI. Genuine failsafe is identified on the console. Whether management access or individual interfaces still work alongside it depends on the cause and is not proof of system health.

This distinction is important: when a single service has failed, a targeted service restart can be appropriate. In failsafe mode, however, a critical startup requirement is missing. Restarting multiple services on suspicion is then more likely to obscure the cause than to correct it.

Check the failsafe cause with show failure-reason

show failure-reason belongs in the Device Console, not in the Advanced Shell. The command does not change the configuration. It displays the error category that SFOS detected during startup.

The output is a starting point, not a complete repair instruction. The following message groups help classify the problem:

• Configuration database: The firewall could not start its configuration database correctly. Before any manual repair, preserve the error message, build, most recent change, and available backup. Do not delete or modify database files.
• Firewall framework or firewall rules: SFOS could not apply the foundation for packet processing or the ruleset. The most recent rule, object, restore, or firmware changes are relevant. Removing all firewall rules indiscriminately would cause data loss and is not a sound initial diagnosis.
• Logging daemon: A critical logging service did not start. In addition to the error message, check the storage state, build, and logs. Do not clear reports or logs blindly before preserving the required data.
• Network daemon: Network components could not start correctly. For virtual appliances, include the existing vNICs, adapter order, and hypervisor changes in the investigation.
• Signature database: A required signature database could not be loaded. Pattern status, storage, and the timing in relation to updates are relevant; do not delete signature files manually.
• NPU: On an XGS model with an NPU, the first console line may already report Network processing unit error. Even if show failure-reason then produces no useful output, preserve the entire console and prepare a support or hardware case.

The exact wording of a message can vary by SFOS version. For support, the unchanged output is therefore more valuable than a self-written summary such as Firewall does not start.

Check the platform and most recent change

The next step depends on whether hardware, a virtual or software appliance, or an HA cluster is affected. The same error message must not automatically lead to the same action.

Virtual firewall and software appliance

A virtual firewall can enter failsafe mode solely because its resources are unsuitable. For locally operated SFOS 22 appliances on VMware, Hyper-V, KVM, and Citrix, Sophos currently specifies at least:

• 1 vCPU
• 4 GB vRAM
• 2 vNICs
• 32 GB Primary Disk
• 80 GB Report Disk

In addition, the configured vCPU and vRAM must not exceed the purchased license. These minimum values are only technical startup limits and are not production sizing for IPS, TLS Inspection, or high throughput.

The Auxiliary Disk included in the VM images is this separate Report Disk. It is not optional and does not replace the Primary Disk. For AWS and Azure, use the supported cloud instance types and platform-specific sizes instead.

In the hypervisor, verify that both disks and all intended vNICs are still present, connected, and assigned in the expected order. Any subsequent change to CPU, RAM, disk controller, or virtual network also belongs in the incident timeline. The platform differences and resource requirements are covered in more detail in a separate article.

For an SFOS 22 software appliance, x86-64, Legacy BIOS, at least 4 GB RAM, and two network cards are undisputed requirements. However, two current Sophos pages contradict each other regarding storage: the general platform overview lists a minimum of 10 GB, while the newer, specific software appliance page lists a minimum of 32 GB and recommends 64 GB. There is therefore no single published Sophos limit. For new installations, Avanet conservatively recommends at least 32 GB and, whenever possible, 64 GB; this follows the more specific product page and avoids a system that is already short of space at startup.

Do not change resources repeatedly and arbitrarily during an unclear recovery attempt. Document the current state first, then perform one planned correction with a defined startup test.

Hardware appliance and NPU

For a physical XGS, also consider power events, temperature, fans, SSD or I/O errors, and the first boot messages. An NPU error on an appropriately equipped XGS model is not a reason to try undocumented reset or service commands. If the message recurs or the diagnostic process itself fails, the appropriate next step is a support case with possible RMA preparation.

A single successful restart does not prove that a hardware problem has been resolved. For repeated failures, the available checks for temperature and fans and SSD health provide additional information.

Failsafe in an HA cluster

For HA, first determine which Node is affected and whether the peer is processing production traffic reliably. Document Primary or Auxiliary, cluster status, the most recent role change, and the corresponding time on both appliances.

Do not restart both Nodes simultaneously or disable HA on suspicion. An uncoordinated change can put the remaining working path at risk, alter the role situation, or force a rebuild. Set up Sophos Firewall High Availability explains roles, synchronization, and Node-specific logs; the specific failsafe cause must still be preserved on the affected Node.

After a firmware update or restore

If failsafe occurs immediately after an upgrade, rollback, or restore, record the source version, target version, and complete build number. In SFOS 22, Sophos fixed several specific causes of failsafe with MR2 Build 546, including errors after upgrading to GA, a logging daemon that did not start, a full configuration partition, and certain faulty service objects. The SFOS 22 MR2 overview lists the resolved issue IDs.

This does not mean that every failsafe event is resolved by an update. First verify whether the error message and installed build actually match a known fix. A firmware change still requires a backup, maintenance window, HA plan, and return path. Use preparing a firmware update and the SFOS 22 upgrade check for this purpose.

Failed to start Red server service

If the firewall shows this exact message in failsafe mode, the symptoms match NC-178906. Sophos fixed this failsafe error in SFOS 22.0 MR2 Build 546. On an older build, assess a controlled recovery and upgrade path to build 546 or later after preserving the evidence. If the message occurs on build 546 or later, the issue ID alone does not prove the cause; open a support case with the preserved logs.

Before a restart or firmware change, preserve the complete build number, time of failure, affected HA Node, and sysinit.log, red.log, and syslog.log entries from the time of the failure. Do not delete RED interfaces, the RED Firmware Pattern, or the RED configuration on suspicion, and do not repeatedly restart the RED service. If the firewall starts normally and only one RED tunnel remains offline, use RED troubleshooting instead.

Preserve evidence before recovery or restart

Whenever possible, collect the following before the first state-changing action to enable a reliable analysis:

• complete output from show failure-reason and the first visible boot lines
• model, serial number, and hardware, virtual, or software platform
• exact SFOS version including MR and build
• time of failure and last known working time
• most recent changes to firmware, restore, rules, objects, interfaces, VM resources, or storage
• for HA: affected Node, role, peer status, and time of the most recent failover
• an available current backup and the associated Secure Storage Master Key
• for VMs: vCPU, vRAM, vNICs, Primary Disk, Report Disk, and license limit
• recurring symptoms such as reboots, I/O, NPU, temperature, or storage errors

If the Advanced Shell is still accessible, relevant log excerpts can also be preserved. These examples only read the last 200 lines and do not change the system:

tail -n 200 /log/sysinit.log
tail -n 200 /log/syslog.log
tail -n 200 /log/postgres.log

sysinit.log is the central log for system startup, syslog.log contains kernel and system events, and postgres.log helps with the configuration database. Depending on show failure-reason, apply the same read-only tail command to the appropriate detailed log, for example:

tail -n 200 /log/networkd.log
tail -n 200 /log/sigdb.log
tail -n 200 /log/npu-startup.log

networkd.log covers physical and virtual interfaces, sigdb.log covers the signature database, and npu-startup.log applies only to hardware models with an NPU. Not every file exists on every platform. The additional mapping is available in Sophos Firewall services and log files. Log excerpts can contain confidential data and must be transferred securely.

When WebAdmin becomes available again, also preserve a CTR or troubleshooting archive. The procedure is described in Preserve Sophos Firewall logs for support.

Choose a safe next step

After preserving the evidence, the recovery path can be selected more reliably:

1. Clear resource mismatch on a VM or software appliance: Document the current state, verify license limits and current minimum values, shut down the VM in a controlled manner, correct exactly the confirmed mismatch, and observe the next startup.
2. Storage or logging indication: Inspect the partition and affected data type using read-only methods. Do not delete files with rm. Check storage space and reports safely shows the intended diagnostic and cleanup procedures.
3. Error immediately after a firmware change: Compare the build with known problems, and only then decide in a controlled manner between the current Maintenance Release, rollback, or support.
4. NPU, I/O, or recurring hardware indication: Prepare a support case and, if necessary, an RMA. A temporarily successful reboot does not rule out a defect.
5. Database, framework, rule, or unknown startup error: Preserve the output and logs, then open a Sophos Support case with a complete description of the error. Do not remove database files, rulesets, or signatures manually.
6. Reimage as recovery: Use this only when operating-system damage, support, or the documented recovery plan justifies it. Backup, password, and SSMK must be available beforehand. The complete procedure is described under Reinstall Sophos Firewall OS.

After each action, do not check only WebAdmin. The decisive criteria are normal console startup, correct HA status, interface and routing state, internet and VPN connections, and whether the same error message recurs. If the cause remains unclear or recurs, do not obscure it with further spontaneous changes.