Set up SNMP hardware monitoring on 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 Appliance 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

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

In addition to the Sophos-specific hardware tree, SFOS provides the standard MIBs SNMPv2-MIB, IF-MIB with Counter32 and Counter64, SNMPv2-SMI, IP-MIB, IP-FORWARD-MIB, TCP-MIB, and UDP-MIB. These can be used to monitor uptime, interface counters, IP and routing values, and TCP/UDP statistics. The current Sophos MIB remains important because it provides the vendor-specific OIDs and their meaning for the installed SFOS version.

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

Under Administration > SNMP > SNMPv3 users and traps, click Add.
Set a permanent username such as monitoring. Use letters without spaces and configure the same username on the manager. It cannot be changed later.
Enable Accept queries.
Enable Send traps only if the firewall should also send notifications to the manager.
If Send traps is enabled, enter the actual IPv4 or IPv6 addresses of the intended trap receivers under Authorized hosts before saving the SNMPv3 user. These must be the receiver addresses in your own environment, not automatically the IP addresses of the polling hosts.
For new deployments, use AES and SHA256 or SHA512 where possible. Both passphrases must be at least twelve characters long.
Save the configuration.

SFOS also offers DES or None for encryption and MD5 for authentication. These options should not be used for new configurations. If a collector supports only these methods, update it first or confine the SNMP connection to a technically justified, isolated management path; a silent downgrade is not a successful compatibility test.

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, click Add under Administration > SNMP > SNMPv1/v2c and create a community entry. 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. Then save the entry with Save.

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

SFOS 23 – hotfix security updates: SNMP notifications are not available for these updates. Instead of expecting a trap, configure email for Firmware > Security updates with the global email switch and working SMTP, and verify applied updates. This exception does not apply indiscriminately to all hotfixes or firmware events.

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.

Back up or transfer the SNMP configuration

SFOS 22 can export and import the SNMP agent, community, and SNMPv3 user configuration as a TAR file under Backup and firmware > Import export. This is useful for a controlled hardware replacement or before larger changes. The archive contains security-relevant monitoring configuration and therefore belongs in protected storage. The general workflow is described in Export and import Sophos Firewall configuration.

A successful import doesn’t prove that monitoring works. Afterwards, verify the agent status, Device Access or ACL exception, credentials, query, and trap destination again with a real polling and event test. The monitoring system must also have the current MIB that matches the target version.

Roll back a test configuration

Before a pilot, record whether the agent and SNMP for the relevant zone were already enabled, which users, communities, and ACL exceptions exist, and which SNMP options are enabled under System services > Notification list. This allows the pilot changes to be reversed without disconnecting another monitoring system.

To roll back, first disable the pilot polling job and any pilot-specific trap handling in the monitoring system, but don’t stop a shared trap receiver. Then delete the newly created SNMPv3 user or community and remove the Local Service ACL exception created for it. Disable Enable SNMP agent and confirm with Apply only if the agent was disabled before the pilot and no other manager uses it. If SNMP was enabled for an entire zone, restore the previous setting under Administration > Device access. Also restore the recorded state of any trap and alert options enabled solely for the pilot under System services > Notification list. Finally, the query from the pilot host must time out, while existing managers must continue to receive query responses and the expected traps.

Hardware metrics and model limitations

SFOS 22 provides the new hardware values for XGS Appliances:

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

Sophos documents these sensors for XGS Appliances. Physical host sensors from the SFOS MIB should not be expected on virtual, cloud, or software appliances. Even on an XGS Appliance, 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 each port, the PoE table also returns the label, status, configured power limit, and current consumption. enabled(1) means that PoE power is active, while disabled(2) means it is disabled. Therefore, disabled(2) alone is not a hardware fault. For alerting, compare current consumption with the limit of the same port and rediscover the port label and index rather than blindly mapping table rows to an old template. The table doesn’t expose the appliance’s overall PoE budget; an aggregate-consumption alert therefore also needs a separately verified, model-specific PoE budget.

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 a port’s configured power limit.
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.

In an HA cluster, each appliance has its own sensors. Sophos documents a peer administration address for WebAdmin access to the auxiliary appliance, but not that its SNMP hardware values can be polled separately through that address. A poll of the cluster address must therefore not be treated as proof of both appliances’ hardware health. After setting up HA and after a failover, verify whether the manager can map the readings unambiguously to one appliance; otherwise, use another documented method to check the auxiliary appliance. Set up Sophos Firewall High Availability explains the HA fundamentals.

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

First check the event type: for hotfix security updates in SFOS 23, a missing trap is expected. It does not prove a routing, UDP 162, or SNMPv3 inform acknowledgement failure and says nothing about update success. For this event, use the email and update verification path above rather than changing SNMP transport. The following checks apply to supported trap events.

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.