Setting Up Sophos Firewall SNMP Hardware Monitoring

With SNMP Hardware Monitoring, you can better integrate the status of a Sophos Firewall into an existing monitoring system. In addition to classic reachability and interface values, since Sophos Firewall v22, additional hardware metrics are available via the MIB. Depending on the model, these include CPU temperature, NPU temperature, fans, power supply status, and PoE values.

This is particularly interesting for productive XGS installations. A firewall may still be reachable in WebAdmin but still show signs of thermal issues, defective fans, a failed power supply, or unexpected PoE load. Such conditions should not only be noticed during the next manual login.

When SNMP on the Firewall is Useful

SNMP is useful when a monitoring system is already in place and the firewall is to be monitored there as an infrastructure component.

Typical use cases:

• Monitor the hardware status of XGS appliances.
• Observe CPU and NPU temperature over time.
• Include fan and power supply status in an NOC or MSP monitoring.
• Control PoE load on XGS models with PoE ports.
• Compare interface values with switch, router, and provider monitoring.
• Correlate alarms from firewall, switch, UPS, and ambient temperature.

SNMP does not replace log analysis. For traffic and security questions, Log viewer, Central Firewall Reporting, Syslog, or a SIEM remain more important. For traffic patterns on interfaces, sFlow Monitoring on Sophos Firewall is more suitable. SNMP primarily answers status questions: Is the device reachable, are interfaces running, are hardware values normal, and do values change over time?

Prerequisites

Before setting up, you should clarify these points:

• A monitoring system with SNMP support is available.
• The firewall is reachable via a management or monitoring network.
• SNMP access is allowed under Device Access only for the monitoring system.
• The appropriate Sophos Firewall MIB is imported into the monitoring system.
• It is clear which firewall models are being monitored and what hardware values these models provide.
• Alarm rules are planned to report real operational problems and not just noise.

⚠️ SNMP should not be broadly accessible from client, guest, IoT, or WAN zones. Monitoring data can reveal model, interfaces, status values, and operational states. Access should be in a trusted management or monitoring network.

Cleanly Separate SNMP, sFlow, and Reporting

SNMP, sFlow, and reporting provide different answers.

In practice, these tools are combined. SNMP, for example, reports high temperature or interface errors. Then you check Log Viewer, Packet Capture, switch port, ambient temperature, or the affected network segment.

What Hardware Values SFOS 22 Provides

Sophos has described additional SNMP hardware metrics in the SFOS 22 release notes. Availability depends on the firewall model.

This table is important for expectations. If a small desktop model does not provide fan value or NPU temperature, it is not automatically a monitoring error. First, it must be checked whether the model supports the respective metric at all.

Securing SNMP Access

The first security check does not take place in the monitoring system but on the firewall itself.

Under Administration > Device access, SNMP should only be reachable from the network where the monitoring server is located. If the monitoring system has a single fixed IP address, a Local service ACL exception rule is usually better than a broad zone release.

Sensible basic rules:

• Do not allow SNMP from WAN.
• Do not allow SNMP for complete client or server zones if only one monitoring host polls.
• Define the monitoring server as its own host object or management network.
• Check access after changes with Packet Capture or monitoring test.
• Remove unused SNMP rules and old monitoring sources.

Device Access controls traffic to the firewall itself. A normal firewall rule for LAN-to-WAN traffic does not replace this setting.

Choose SNMP Version Wisely

If possible, SNMPv3 should be used because it allows authentication and, with appropriate AuthPriv configuration, encryption. SNMPv1 and SNMPv2c work with community strings. These community strings are not user accounts but shared secrets and should be protected accordingly.

For SNMPv1/v2c, Sophos mentions a change in SFOS 22: You can add the community string and choose whether the configuration applies to IPv4 or IPv6. Upon upgrade, the firewall adopts existing names as community strings and generates migrated object names with the prefix snmp.

After an upgrade, you should therefore check:

• Are there old SNMPv1/v2c community strings?
• Are the automatically migrated snmp objects clearly named?
• Is IPv4, IPv6, or both really needed?
• Can old monitoring sources be removed?
• Is SNMPv3 possible, or does v2c remain necessary for compatibility reasons?

⚠️ Community strings should not be treated like harmless labels. Such strings belong in a password or secrets concept, should not be copied into tickets, and must not be visible in screenshots.

Import MIB and Check OIDs

For a monitoring system to sensibly recognise Sophos values, it needs the appropriate MIB file. The MIB describes which OIDs are available for firewall, interface, and hardware values.

Practical approach:

1. Obtain the current MIB file from the Sophos Firewall or the appropriate Sophos documentation.
2. Import the MIB into the monitoring system.
3. Add the firewall with SNMPv3 or a deliberately chosen v1/v2c configuration.
4. Let the model, firmware version, and reachable OIDs be recognised.
5. Check hardware metrics against the specific model.
6. Conduct a manual poll and validate values.
7. Only then activate alarm rules.

After firmware upgrades, the MIB page should be checked again. New SFOS versions can add OIDs or change existing areas. If a monitoring system no longer resolves values cleanly after an update, you should not first suspect the firewall but check MIB version, discovery, and OID assignment.

Sensible Alerting

SNMP monitoring is only helpful if alerts are sensibly set. Too narrow thresholds create noise, too broad thresholds report problems too late.

Typical alert areas:

For temperature values, a baseline is important. A small desktop firewall in a warm tech cabinet behaves differently than a rack appliance in an air-conditioned room. Therefore, normal operation should be observed for a few days first, and only then should productive thresholds be set.

Establish Alarm Runbook and Responsibility

An SNMP alarm is only helpful if it is clear who reacts and what procedure applies. Hardware values are often early indicators: A rising temperature, a missing fan value, or a power supply alarm does not automatically mean the appliance must be replaced immediately. However, it does mean that the condition should be assessed and documented.

For productive firewalls, a short runbook entry should exist:

The order is important: first check visibility and plausibility, then assess risk, then prepare support or replacement process. In case of possible hardware defects, additionally document serial number, model, firmware status, time, affected metric, trend, and screenshot or monitoring excerpt. Warranty and RMA questions ultimately depend not only on the alarm but on the specific device, support status, and error image.

For SSD topics, SNMP is not the right main path. If disk condition or write load is the focus, Check Sophos Firewall SSD Health via SMART is more suitable.

HA Cluster and Multiple Firewalls

In HA environments, it should be clearly defined how both devices are monitored. It is not always sufficient to only observe the cluster address. For hardware values, both appliances are often relevant because a fan, power supply, or port on the passive appliance can also fail.

Important questions:

• Are primary and auxiliary recognised separately?
• Do both devices have their own management IP addresses for monitoring?
• Are serial number, hostname, or model clearly displayed in monitoring?
• Do alarms remain understandable after a failover?
• Is a power supply error on the passive appliance also reported?

For HA operation itself, Set Up Sophos Firewall High Availability is suitable. SNMP should not be planned in isolation there but together with firmware updates, failover tests, backup concept, and operational documentation.

Validation After Setup

After setting up SNMP, you should not only check if the monitoring is green. It is important whether the correct data comes from the correct source.

Checklist:

1. SNMP access is only possible from the monitoring network.
2. The firewall is recognised with the correct hostname, model, and firmware version.
3. The Sophos MIB is imported, and hardware values are clearly named.
4. Unsupported metrics are documented as model limits, not as errors.
5. Temperature, fan, power supply, and PoE values are plausible.
6. A test alarm is triggered and reaches the correct recipient.
7. In HA clusters, both devices or the desired cluster logic are checked.
8. After a firmware upgrade, the discovery is tested again.

For performance and throughput questions, SNMP values should not be overinterpreted. The classification of Sophos performance data is described in the article Understanding Sophos Firewall Performance Metrics.

Troubleshooting

Firewall Does Not Respond to SNMP

First, check if the monitoring system comes from the expected zone and if SNMP is allowed under Administration > Device access. Then check IP address, routing, local ACL rules, SNMP version, community string, or SNMPv3 access data.

If it is unclear whether packets reach the firewall, Packet Capture on the affected interface helps. A normal firewall rule does not solve this problem if the traffic goes to the firewall itself.

MIB Is Imported, but Values Are Missing

First, check if the missing metric is available for the model used. Small XGS models do not provide all hardware values. Then compare MIB version, OID assignment, and firmware version.

SNMP Objects Are Named Differently After Upgrade

With SNMPv1/v2c, SFOS 22 can generate migrated objects with the prefix snmp. After an upgrade, you should therefore check community strings, object names, and monitoring discovery. If monitoring works with names instead of stable OIDs, templates may need to be adjusted.

Monitoring Reports Too Many Temperature Alarms

Then thresholds are probably set too narrowly or without a baseline. First, record normal values over several days. Then set thresholds based on model, location, and ambient temperature. Individual short peaks are to be evaluated differently than a consistently rising temperature trend.

HA Cluster Shows Only One Device

Then it must be checked whether the monitoring only queries the cluster address or whether both appliances are separately reachable. For hardware status, the passive appliance is also relevant. In productive clusters, you should document which IP address represents which device and role.

Operational Checklist

• Allow SNMP only from management or monitoring networks.
• Prefer SNMPv3 if the monitoring system supports it cleanly.
• Treat SNMPv1/v2c community strings like secrets.
• Import Sophos MIB and check after firmware upgrades.
• Document model limits for hardware values.
• Set temperature and PoE thresholds based on real baselines.
• Clearly name and separately evaluate HA devices.
• Document alarm runbook with first check, escalation, and responsibility.
• Secure model, serial number, firmware status, and trend in case of hardware suspicion.
• Regularly test alarms and clarify responsibility.
• Combine SNMP data with logs, sFlow, Packet Capture, and Central Reporting.

FAQ