Sophos Firewall SNMP Set up 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 accessibility and interface values, additional hardware metrics have been available via MIB since Sophos Firewall v22. Depending on the model, this includes CPU temperature, NPU temperature, fan, power supply status and PoE values.

This is particularly interesting for productive XGS installations. A firewall may still be accessible in WebAdmin, but still show signs of thermal problems, defective fans, a failed power supply or unexpected PoE load. Such conditions should not only be noticed the next time you log in manually.

When SNMP makes sense on the firewall

SNMP makes sense if a monitoring system is already in operation and the firewall is to be monitored there as an infrastructure component.

Typical use cases:

• Monitor hardware health of XGS appliances.
• Observe CPU and NPU temperatures over time.
• Include fan and power supply status in a NOC or MSP monitoring.
• Check 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 evaluation. 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 a better fit. SNMP primarily answers status questions: Is the device accessible, are interfaces running, are hardware values ​​inconspicuous and do values ​​change over time?

Requirements

Before setting up, you should clarify these points:

• A monitoring system with SNMP support is available.
• The firewall can be reached via a management or monitoring network.
• SNMP access is only permitted under Device Access for the monitoring system.
• The SNMP agent on the firewall is planned: name, location, contact and preferred SNMP version are known.
• It is clear whether the monitoring system only queries the firewall or whether the firewall should also send SNMP traps.
• The appropriate Sophos Firewall MIB is imported into the monitoring system.
• It is clear which firewall models are monitored and what hardware values ​​these models provide.
• Alarm rules are planned to report real operational problems and not just generate noise.

⚠️ SNMP should not be widely accessible from client, guest, IoT or WAN zones. Monitoring data can make models, interfaces, status values ​​and operating states visible. Access belongs in a trustworthy management or monitoring network.

Cleanly separate SNMP, sFlow and reporting

SNMP, sFlow and reporting provide different answers.

The tools answer different questions:

• SNMP: Good for accessibility, hardware and interface values. Not ideal for individual firewall rules, URL blocks, or VPN errors.
• sFlow: Good for traffic flows on an interface. Not ideal for precise packet or rule analysis.
• Log Viewer, Syslog and Central Reporting: Good for rule, module, user and event context. Not ideal for hardware health and long-term interface polling values.
• Packet Capture: Good for the question of what can actually be seen on an interface. Not suitable for permanent monitoring.

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

Which hardware values SFOS 22 delivers

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

Key Hardware Metrics:

• CPU temperature: available for all XGS models according to Sophos.
• NPU temperature: for XGS models except XGS 88/88w, 108/108w, 118/118w and 128/128w.
• Fan speed: for XGS models except XGS 88/88w and 108/108w.
• Power supply status: for XGS 2100 and above.
• PoE measurements: for XGS models with PoE, except XGS 116/116w.

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

Secure 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 accessible from the network in which 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 wide zone release.

Useful basic rules:

• Do not allow SNMP from WAN.
• Do not release SNMP for entire client or server zones if only one monitoring host is polling.
• Define monitoring server as its own host object or management network.
• Check access for 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.

Configure SNMP agent and manager entries

The base configuration is done under Administration > SNMP. The firewall must first be enabled as an SNMP agent before a monitoring system can query it usefully.

Basic configuration:

1. Open Administration > SNMP.
2. Turn on Enable SNMP agent.
3. Enter a clear name, ideally matching the firewall hostname.
4. Enter location and contact details so alerts can later be assigned to a site and responsible person.
5. Save with Apply.
6. Use Download MIB and import the MIB into the monitoring system.

Sophos describes two standard ports for the agent: queries reach the agent over UDP 161, traps are sent to the manager over UDP 162. These ports must not only be correct in the firewall configuration, but also reachable between the monitoring system, routing, local host firewalls and possible management network segments.

For SNMPv3, create a user under Administration > SNMP > SNMPv3 users and traps. Choose the username deliberately because, according to Sophos, it can’t be changed later. Then decide separately:

• Accept queries: The firewall answers SNMP queries with this user.
• Send traps: The firewall can send traps to the manager.
• Authorized hosts: According to Sophos, this list only applies to trap destinations, not as an access list for SNMP queries.
• Encryption algorithm: AES, DES or None. In production environments, encryption should be active if the monitoring system supports it.
• Authentication algorithm: MD5, SHA256 or SHA512. New setups should use SHA256 or SHA512 where possible.
• Passwords: Sophos requires at least 12 characters each for encryption and authentication.

For SNMPv1/v2c, create a community entry under Administration > SNMP > SNMPv1/v2c. Set name, community string, IP version, manager IP and the options Accept Queries and Send traps. The community string works like a password for SNMP queries and should therefore not appear in screenshots, tickets or monitoring templates in plain text.

If traps are used, the SNMP entry alone isn’t always a complete alert configuration. Under System services > Notification list, SNMP traps and the required alert types must also be enabled.

Choose SNMP version consciously

If possible, SNMPv3 should be used because it enables authentication and, with the 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. During the upgrade, the firewall adopts existing names as Community String and creates 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 is v2c still 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

In order for a monitoring system to meaningfully recognize the Sophos values, it needs the appropriate MIB file. The MIB describes which OIDs are available for firewall, interface and hardware values.

Practical procedure:

1. Obtain the current MIB file under Administration > SNMP > Download MIB.
2. Import MIB into the monitoring system.
3. Add firewall with SNMPv3 or a deliberately chosen v1/v2c configuration.
4. Detect model, firmware version and accessible OIDs.
5. Check hardware metrics against the specific model.
6. Carry out a manual poll and check the plausibility of 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 ​​correctly after an update, you should not first suspect the firewall, but rather check the MIB version, discovery and OID assignment.

Useful alerting

SNMP monitoring is only helpful if alarms are set sensibly. Thresholds that are too narrow create noise, thresholds that are too wide report problems too late.

Typical alarm areas:

• Availability: Firewall no longer responds via SNMP or ping.
• CPU temperature: Temperature continually rises above normal range.
• NPU temperature: Temperature trend is noticeably or permanently higher than comparative values.
• Fan speed: Fan value is missing, zero or significantly outside the normal range.
• Power supply: Redundant power supply is missing or reporting an error.
• PoE: PoE load is approaching the available budget.
• Interfaces: Port down, error counter or unusual bandwidth. A baseline is important for temperature values. A small desktop firewall in a warm technology closet behaves differently than a rack appliance in a climate-controlled room. Therefore, you should first observe normal operation for a few days and only then set productive thresholds.

A two-stage alarm is often useful for productive locations:

• Warning: The value is abnormal but the service is running. Check history, location, load and recent changes.
• Critical: The value indicates an acute risk, for example power supply failure, permanently very high temperature, lost accessibility or rapidly increasing interface errors.

This means that monitoring remains capable of action. Not every temperature rise needs to be escalated immediately, but a recurring trend shouldn’t disappear into the normal dashboard noise.

Set alarm runbook and accountability

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

A short runbook entry should exist for productive firewalls:

Typical first checks:

• Firewall not accessible via SNMP: Check management network, Device Access, routing, monitoring server and appliance accessibility.
• Temperature constantly increases: Compare ambient temperature, ventilation, rack position, dust, load and history.
• Fan value is missing or abnormal: Check model limit, sensor value, noise, temperature trend and support relevance.
• Power supply reports error: Check power supply, UPS, cables, redundant power supply and HA risk.
• PoE load is high: Check connected devices, PoE budget and planned reserves.
• Interface errors increase: Check cable, switch port, duplex/speed, SFP module and provider handover.

The order is important: first check visibility and plausibility, then assess risk, then prepare the support or exchange process. In the case of possible hardware defects, the serial number, model, firmware version, time, affected metric, history and screenshot or monitoring extract should also be documented. In the end, warranty and RMA questions not only depend on the alarm, but also on the specific device, support status and error pattern.

For SSD topics, SNMP is not the main route. If the focus is on disk health or write load, Sophos Firewall Check SSD health via SMART is a better fit.

HA clusters and multiple firewalls

In HA environments, you should clearly define how both devices will be monitored. It is not always enough to just 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 recognized separately?
• Do both devices have their own management IP addresses for monitoring?
• Are the serial number, host name or model clearly displayed in monitoring?
• Do alarms remain understandable after a failover?
• Is a power supply failure on the passive appliance also reported? For HA operation itself, Sophos Firewall Set up high availability is suitable. SNMP should not be planned there in isolation, but together with firmware updates, failover tests, backup concepts and operational documentation.

Validation after setup

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

Checklist:

1. SNMP access is only possible from the monitoring network.
2. The SNMP agent is active and answers on UDP 161.
3. If traps are used, test messages arrive at the manager over UDP 162.
4. The firewall is detected with correct hostname, model and firmware version.
5. The Sophos MIB is imported and hardware values ​​are clearly named.
6. Unsupported metrics are documented as a model limit, not an error.
7. Temperature, fan, power supply and PoE values ​​are plausible.
8. A test alarm is triggered and reaches the correct recipient.
9. For HA clusters, both devices or the desired cluster logic are checked.
10. After a firmware upgrade, Discovery is tested again.

For performance and throughput issues, you should not overinterpret SNMP values. The classification of Sophos performance data is described in the article Understanding Sophos Firewall performance data.

Troubleshooting

Firewall does not respond to SNMP

First check whether the monitoring system comes from the expected zone and whether SNMP is allowed under Administration > Device access. Then check IP address, routing, local ACL rules, SNMP version, Community String or SNMPv3 credentials. If it is unclear whether packets reach the firewall, Packet Capture on the affected interface helps. A normal firewall rule will not solve this problem if the traffic goes to the firewall itself.

MIB is imported but values are missing

First check whether 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.

After the upgrade, SNMP objects are named differently

For SNMPv1/v2c, SFOS can create 22 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 narrow or without a baseline. First record normal values ​​over several days. Then set thresholds based on model, location and ambient temperature. Individual short peaks should be assessed differently than a permanently increasing 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 can be reached separately. The passive appliance is also relevant for hardware status. For productive clusters, you should document which IP address represents which device and which role.

Operational checklist

• Only allow SNMP from management or monitoring networks.
• Prefer SNMPv3 if the monitoring system supports it properly.
• Treat SNMPv1/v2c Community Strings like secrets.
• Import Sophos MIB and check for firmware upgrades.
• Document model limits for hardware values.
• Set temperature and PoE thresholds based on real baselines.
• Clearly name HA devices and evaluate them separately.
• Document alarm runbook with initial check, escalation and responsibility.
• If hardware is suspected, back up the model, serial number, firmware version and history.
• Test alarms regularly and clarify responsibility.
• Combine SNMP data with logs, sFlow, Packet Capture and Central Reporting.

FAQ