Skip to content
Avanet

Set up SNMP hardware monitoring on Sophos Firewall

Sophos Firewall

To use SNMP hardware monitoring, enable the agent under Administration > SNMP, preferably create an SNMPv3 user, restrict access to the monitoring host under Administration > Device access, and download the current MIB. The connection can then be tested from the monitoring system with snmpget, while snmpwalk can query the hardware subtree.

Since Sophos Firewall v22, the MIB provides additional hardware metrics depending on the XGS model, including CPU and NPU temperatures, fan speeds, power supply status, and PoE values. SNMP primarily answers questions about device health. For individual security events, Central Firewall Reporting or syslog is more appropriate, while sFlow is better suited to traffic patterns.

If the task is an immediate check directly on the appliance rather than continuous monitoring, Check Sophos Firewall temperature and fan via SSH shows how to read sensors and xgs-healthmond.log and interpret apparent raw sensor alarms correctly.

⚠️ SNMP should only be reachable from a trusted management or monitoring network. Broad access from client, guest, IoT, or WAN zones unnecessarily exposes information about the model, interfaces, and operating state.

Configure SNMP securely

Restrict access to the monitoring host

If a dedicated monitoring zone needs access, enable SNMP under Administration > Device access only for that zone. If exactly one server with a fixed IP address performs the polling, leave SNMP disabled for the zone. Instead, use a Local service ACL exception rule to permit the source, the firewall destination, and the SNMP service specifically. The complete configuration is described in Secure Sophos Firewall Device Access.

SNMP is a local service on the firewall. A regular LAN-to-WAN rule does not replace Device Access. SNMP should not be exposed directly from the WAN; a management VPN is the safer connection for external monitoring.

Enable the agent

  1. Open Administration > SNMP.
  2. Enable Enable SNMP agent.
  3. Enter the name, location, and contact, for example xgs-zrh-01, ZRH-DC1 / Rack 3, and noc@example.net.
  4. Save with Apply.
  5. Use Download MIB to download the MIB for the installed firewall version and import it into the monitoring system.

Queries reach the agent over UDP 161. Traps are sent to the manager over UDP 162. Routing and local host firewalls between the two systems must also allow traffic in the required direction.

Configure SNMPv3

  1. Under Administration > SNMP > SNMPv3 users and traps, click Add.
  2. Set a permanent username such as monitoring. It cannot be changed later.
  3. Enable Accept queries.
  4. Enable Send traps only if the firewall should also send notifications to the manager.
  5. For new deployments, use AES and SHA256 or SHA512 where possible. Both passphrases must be at least twelve characters long.
  6. Save the configuration.

According to Sophos, Authorized hosts applies only to trap destinations. The list does not restrict SNMPv3 queries. Matching credentials, Accept queries, and Device Access determine query access.

Use SNMPv1 or SNMPv2c only when necessary

If the monitoring system does not properly support SNMPv3, create a community entry under Administration > SNMP > SNMPv1/v2c. The required fields are name, Community String, IPv4 or IPv6, the manager IP, and Accept queries. Leave Send traps disabled if traps are not used.

The Community String acts like a password but is transmitted without encryption in v1/v2c. It must not appear in screenshots or tickets and should only be used within a tightly restricted management network.

After upgrading to SFOS 22, review existing v1/v2c entries. The firewall copies the previous name into the Community String and creates a name with the snmp prefix for migrated objects. This is also an opportunity to remove unnecessary IPv4 or IPv6 variants and monitoring sources that are no longer used.

Enable traps selectively

For traps, the SNMP user or community entry alone is not sufficient. Under System services > Notification list, enable SNMP traps and the alert types that are actually required.

Test reception with a selected event that actually occurs. SNMPv3 informs are acknowledged; according to Sophos, the firewall does not attempt to resend an inform if it receives no acknowledgement. Traps and informs therefore do not replace monitoring of the polling process itself.

Hardware metrics and model limitations

SFOS 22 provides the new hardware values for XGS appliances:

  • CPU temperature: all XGS models.
  • NPU temperature: all XGS models except 88/88w, 108/108w, 118/118w, and 128/128w.
  • Fan speed: all XGS models except 88/88w and 108/108w.
  • Power supply status: XGS 2100 and higher.
  • PoE measurements: PoE-capable XGS models except XGS 116/116w.

Sophos documents these sensors for XGS hardware. Physical host sensors from the SFOS MIB should not be expected on virtual, cloud, or software appliances. Even on XGS, a missing metric does not automatically indicate a fault; first check whether the model supports it.

OIDs and units from the SFOS 22 MIB

The hardware subtree starts at .1.3.6.1.4.1.2604.5.1.9. The most important areas are:

  • NPU temperature: .1.3.6.1.4.1.2604.5.1.9.1.0
  • CPU temperature: .1.3.6.1.4.1.2604.5.1.9.2.0
  • Fan speed: .1.3.6.1.4.1.2604.5.1.9.3.1.2
  • Power supply status: .1.3.6.1.4.1.2604.5.1.9.4.1.2
  • PoE table: .1.3.6.1.4.1.2604.5.1.9.5

Temperatures are returned in tenths of a degree Celsius: 420 means 42.0 °C. Fan values are in RPM. PoE power is reported in milliwatts, voltage in millivolts, and current in milliamperes. For a power supply, up(1) means operational and down(2) means failed.

For hardware values that can be evaluated numerically, at least SFOS 22.0 GA Build 411 should be installed. This build fixes NC-169564, which caused sensor values to be returned as strings instead of integers, as well as other MIB and OID issues.

After a firmware upgrade, download the current MIB again, import it into the monitoring system, and repeat discovery. Monitoring templates must not depend on display names alone.

Test the connection and hardware values

The following Bash commands run on a Linux or macOS monitoring host with Net-SNMP, not on Sophos Firewall. On macOS, start bash first because read -p has a different meaning in the default zsh shell. The examples have been checked against the documented Net-SNMP syntax and the official SFOS 22 MIB, but not executed against a customer firewall.

SHA-256 and SHA-512 generally require Net-SNMP 5.8 or later. Use snmpwalk -h to check which algorithms the installed client accepts. Older macOS versions may support only MD5 and SHA.

⚠️ Net-SNMP passes Community Strings and passphrases as process arguments. Reading them with read keeps them out of the shell history, but does not prevent their brief appearance in the process list. Run these tests only on a trusted monitoring host.

Test SNMPv3 with AuthPriv

Adjust the IP address and username, enter the passphrases, and first query the harmless standard OID sysUpTime.0:

FIREWALL_IP="192.0.2.1"
SNMP_USER="monitoring"

read -r -s -p "SNMPv3 authentication password: " SNMP_AUTH
printf '\n'
read -r -s -p "SNMPv3 encryption password: " SNMP_PRIV
printf '\n'

snmpget -v3 -l authPriv -u "$SNMP_USER" \
  -a SHA-256 -A "$SNMP_AUTH" \
  -x AES -X "$SNMP_PRIV" \
  -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.2.1.1.3.0

snmpwalk -v3 -l authPriv -u "$SNMP_USER" \
  -a SHA-256 -A "$SNMP_AUTH" \
  -x AES -X "$SNMP_PRIV" \
  -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.4.1.2604.5.1.9

unset SNMP_AUTH SNMP_PRIV

A successful first query returns sysUpTime.0 as Timeticks. The subsequent walk shows only the sensors supported by the specific model.

Use SNMPv2c as a compatibility test

For a deliberately configured v2c manager:

FIREWALL_IP="192.0.2.1"

read -r -s -p "SNMP community: " SNMP_COMMUNITY
printf '\n'

snmpget -v2c -c "$SNMP_COMMUNITY" -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.2.1.1.3.0

snmpwalk -v2c -c "$SNMP_COMMUNITY" -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.4.1.2604.5.1.9

unset SNMP_COMMUNITY

A successful uptime test proves reachability and matching credentials, but not yet the plausibility of every sensor value. Then compare the hostname, model, firmware, MIB version, and readings with the WebAdmin, the appliance, and normal operation. Establish a baseline over several days before enabling temperature and PoE alerts.

Alerting and HA

Useful alerts report an operational deviation, not just a single measurement:

  • SNMP reachability or an expected interface fails.
  • CPU or NPU temperature remains above its established baseline.
  • An installed fan reports 0 RPM or no value.
  • A redundant power supply changes to down(2).
  • PoE consumption approaches the available budget.
  • Interface errors or drops increase abnormally.

Fixed universal temperature thresholds would be misleading. The model, rack, ambient temperature, and workload determine the normal range. An alert runbook should first check the reading, its history, and the model limitation, then assess cooling, power supply, cabling, the switch port, or PoE devices.

Alerts should distinguish at least between Warning and Critical. For each level, the runbook must define the owner, the first check, and the escalation path.

If a hardware fault is confirmed, record the model, serial number, firmware, time, and history. The warranty and replacement process is described in Prepare a Sophos hardware RMA and replacement. For storage devices, Check SSD health with SMART is more appropriate than SNMP.

Both appliances matter in an HA cluster. Querying only the cluster address does not necessarily show the fan, power supply, or port of the passive appliance. If the network design and platform allow separate management access, Primary and Auxiliary should be identified individually. Verify actual SNMP reachability and attribution after the HA configuration and again after a failover. The underlying concepts are explained in Set up Sophos Firewall High Availability.

SNMP readings should not be used as the sole evidence of performance. Interpret Sophos Firewall performance data correctly explains how to assess throughput and utilization.

Troubleshooting

Timeout or no response

First check the monitoring IP, routing, Device Access, Local Service ACL, Accept queries, the SNMP version, and the credentials. In WebAdmin under Diagnostics > Packet capture, use the filter host 192.0.2.50 and port 161; Packet Capture in WebAdmin explains how to use it.

Alternatively, use option 4, Device Console, to check whether the query reaches the firewall:

tcpdump 'host 192.0.2.50 and port 161'

Stop the test with Ctrl+C. If no packet arrives, the cause lies before the SNMP agent. If the query arrives but no response leaves, check Device Access, the manager IP, credentials, and agent configuration next.

Authentication or algorithm fails

The username, authPriv security level, authentication algorithm, and encryption algorithm must exactly match the firewall configuration. If the client does not accept SHA-256 or SHA-512, use snmpwalk -h to check the supported algorithms and update Net-SNMP. Do not silently fall back to MD5 or unencrypted SNMP.

For query errors, do not focus on Authorized hosts: under SNMPv3, this list applies only to trap destinations.

Hardware values are missing or appear incorrect

Check the model limitation, firmware, and MIB version. In SFOS 22.0 GA Build 365, hardware values may appear as strings instead of integers because of NC-169564; Build 411 fixes the issue. Refresh the MIB and monitoring discovery after the update.

The latest messages can be read in Device Console:

show logs snmpd.log lines 100
show logs xgs-healthmond.log lines 100

snmpd.log belongs to the SNMP agent. xgs-healthmond.log helps with CPU temperature and fan status. Additional mappings are listed in Sophos Firewall service logs.

Traps do not arrive

Check Send traps, Authorized hosts, UDP 162, and the selected events under System services > Notification list. In Device Console, a narrow packet capture shows whether the firewall sends traffic to the manager:

tcpdump 'host 192.0.2.50 and port 162'

If packets leave the firewall but do not arrive, check routing, intermediate firewalls, and the trap receiver. For SNMPv3 informs, also verify the manager’s acknowledgement.