Skip to content
Avanet

Check Sophos Firewall temperature and fan via SSH

Sophos Firewall

Sophos Firewall does not display the temperature in WebAdmin. On a physical XGS appliance, however, the hardware values can be read in the Advanced Shell and compared with the hardware log. The raw sensor command that returns values depends on the model.

On the XGS 138 tested here, two read-only commands are enough for an initial check:

sensors
tail -n 100 /log/xgs-healthmond.log

The first command shows the current raw values from the sensor chip. The log presents the most important values more clearly as Host_CPU_Temperature, NPU_CPU_Temperature, and Fan_Speed_Avg. A single high value does not prove overheating; the trend, load, ambient temperature, fans, and observed failures all matter.

⚠️ Important: The Advanced Shell provides direct access to the operating system. The commands shown here only read information. Do not change sensor thresholds or fan control, delete files, or restart services.

Read the temperature directly with sensors

The check requires SSH access with the admin user. After signing in, open:

5. Device Management
3. Advanced Shell

Connect to Sophos Firewall via SSH explains how to allow SSH securely and open the correct console.

Run the current sensor view in the Advanced Shell:

sensors

This command was run on an XGS 138 with SFOS 22.0 GA Build 411. The raw sensor CLI depends on the model: For an XGS 2100, Sophos Hardware Development specifies the following command when sensors returns no values:

xgs-1us-sensors -a

Use such alternatives only on the corresponding model. /log/xgs-healthmond.log is the more broadly documented source and should be checked regardless. Hardware sensor commands may be unavailable on virtual, cloud, or software appliances because SFOS cannot access the physical sensors of the hypervisor or server.

The output varies by model. It typically contains temperature channels, fan speeds in RPM, voltages, and additional raw values from the hardware monitoring chip. Save the complete output first instead of filtering only for ALARM. On some models, such a filter would show numerous raw channels that exist technically but do not have a meaningful assignment.

Check product values in the hardware log

Sophos documents /log/xgs-healthmond.log on hardware appliances for CPU usage and temperature, fan speed, and the NPU management port. Show the most recent entries with:

tail -n 100 /log/xgs-healthmond.log

For a short observation period, follow the log live:

tail -f /log/xgs-healthmond.log

Stop the output with Ctrl+C. Debugging does not need to be enabled. xgs-healthmond.log is a log filename, not a valid name to use as a debug subsystem.

The following lines are particularly useful:

  • Host_CPU_Temperature: Temperature of the main CPU.
  • NPU_CPU_Temperature: Temperature of the separate NPU or Xstream Flow Processor, if the model has an NPU.
  • Fan_Speed and Fan_Speed_Avg: Current and aggregated fan speed in RPM.
  • Host_CPU_Usage and NPU_CPU_Usage: Utilization at the time of measurement. This helps correlate a rise in temperature with high load.
  • Min, Max, Current, and Avg: Statistics maintained by the health monitor.

Sophos does not publicly document the exact time window for these statistics. Therefore, Max must not be described as the peak from the last five minutes, since the last reboot, or over the appliance’s entire lifetime. For a support case, save the value together with its timestamp.

Interpret raw values and apparent alarms correctly

The sensors output comes directly from Linux hardware monitoring. A sensor chip may provide more inputs than are actually connected on the appliance or meaningfully labelled for SFOS. Not every displayed line is therefore a usable product value.

On the tested XGS 138, for example, several voltage lines appeared in this form:

in1: +1.78 V  (min = +0.00 V, max = +0.00 V)  ALARM

The positive reading is formally above the configured maximum of 0.00 V, which causes the raw chip to report ALARM. This alone does not confirm a voltage or hardware fault. A reliable diagnosis would require the input mapping and the valid thresholds for the specific board.

Other apparent anomalies also require caution:

  • Several fan channels showing 0 RPM do not automatically mean that several fans have failed. If the model does not use those connectors and also shows min = 0 RPM, they may be unused channels.
  • Values such as -128 °C, 0 °C, 99 °C, or -1.0 can indicate a sensor that is disconnected, unsupported, or not assigned in a usable way.
  • intrusion0: ALARM belongs to chassis intrusion detection and is not a temperature alarm.
  • high and crit apply only to the sensor next to which they appear. A threshold shown for CPUTIN must not be transferred to Host_CPU_Temperature without evidence.

For an initial assessment, the named values in xgs-healthmond.log are therefore more reliable than individual unclear raw channels. Keep unusual raw values in the support extract so that Sophos can evaluate them for the specific model.

Is the Sophos Firewall too hot?

First distinguish between ambient temperature and internal component temperature. Sophos specifies an ambient operating temperature of 0 to 40 °C for the XGS 118, 128, and 138. This refers to the air at the installation location or inside the rack, not to the internal CPU temperature. The exact limit for the installed model is stated in its Sophos Operating Instructions.

An internal CPU temperature of, for example, 70 °C cannot be compared with the ambient limit of 40 °C. Sophos also does not publish one generally valid normal CPU or NPU temperature for every XGS model. Blanket statements such as “everything below 80 °C is normal” or “the firewall is defective above 90 °C” would therefore be unreliable.

A meaningful assessment combines several observations:

  1. Environment: Measure the air temperature at the appliance intake, not only the room temperature at a distant point. If the output shows Chassis_Ambient_Temperature : -1.0, the firewall itself is not providing a usable ambient value.
  2. Trend: Compare readings taken under similar load and room temperature. A sustained upward trend is more meaningful than a brief peak.
  3. Fan: Check whether the fan that is actually installed is running and responds when the temperature rises.
  4. Load: Record CPU and NPU utilization at the same time.
  5. Symptoms: Unexpected reboots, freezes, NPU errors, or repeated failures increase the urgency.
  6. Model limit: Check the operating and rack conditions in the hardware instructions for the specific model.

A warm chassis alone does not prove a fault. It does indicate that airflow, rack temperature, unobstructed ventilation openings, and the temperature trend should be checked.

Real XGS 138 example

On an XGS 138 with SFOS 22.0 GA Build 411, the hardware log included:

Fan_Speed_Avg : 6081 RPM
NPU_CPU_Temperature : +61.3 Degrees C
Host_CPU_Temperature : +71.5 Degrees C
Host_CPU_Usage : 86.7681 %
{Host_CPU_Temperature} Min: +69.5 Max: +82.5 Current: +71.5 Avg: 71.8534

At that time, the main CPU was under heavy load, the fan was running, and the log showed that the NPU was still responding successfully. The recorded maximum of 82.5 °C is worth investigating together with the load, rack temperature, and preceding failure. However, the excerpt contains no explicit thermal or fan error and does not prove that overheating caused the failure.

This distinction is important: A reboot may temporarily relieve a thermal condition, but it can also clear a software, load, or process problem. After a failure, save temperature data and system logs together.

Continue troubleshooting after a failure

If the firewall stopped responding or only returned to operation after a reboot, a single current temperature reading is not enough. Document the incident as a possible hardware or system fault:

  1. Record the model, serial number, hardware revision, SFOS version, build, time, and observed behavior.
  2. Check the air temperature at the intake and the state of the cooling system, rack, and airflow.
  3. Save the sensors output and the most recent entries from xgs-healthmond.log.
  4. Search the current hardware and system logs for relevant indications:
grep -Ei 'temp|thermal|fan|overheat|critical|fault' /log/xgs-healthmond.log /log/syslog.log
  1. Save a Consolidated Troubleshooting Report and the relevant logs. Volatile information may already be missing after a crash or reboot.
  2. Do not replace fans, open the chassis, or change sensor values. An unexplained failure should already be investigated through a support case; repeated failures, an excessive rack temperature, a significant temperature rise, fan faults, or NPU problems increase the urgency.

For a possible replacement, follow Sophos hardware failure: prepare RMA and replacement. Checking SSD health via SMART is a separate test and does not answer temperature or fan questions.

HA and continuous monitoring

In an HA cluster, check both appliances separately. Each XGS has its own sensors, fans, and local troubleshooting logs. An unremarkable primary appliance does not prove that the auxiliary appliance is also thermally unremarkable. With the same rack position and comparable load, the peer can also provide a useful comparison value. Sophos Firewall High Availability explains the roles and access methods.

The Advanced Shell and hardware log are quick for a one-time diagnosis, but they do not replace operational monitoring. Since SFOS 22, the Sophos MIB provides CPU temperature, NPU temperature, and fan speed depending on the XGS model. SNMP hardware monitoring explains the MIB, OIDs, model limitations, secure SNMPv3 configuration, and alerting.

Good monitoring first establishes a baseline and alerts on sustained deviations, missing expected fan values, unreachability, and real hardware faults. It should not apply a generic CPU limit from the internet to every XGS model without verification.