Correctly check Sophos Firewall Missing Heartbeat Alerts

Missing Heartbeat Alerts on Sophos Firewall or Sophos Central do not automatically mean that an endpoint is compromised. The alert first means: The firewall sees network traffic from a device, but does not receive a suitable security heartbeat. This is an important difference. A missing heartbeat can be a real protection problem, for example if Sophos Endpoint is not running or a device is not correctly connected to Sophos Central. In practice, however, many messages arise from network changes, DNS design, devices outside the firewall path or firewall rules that enforce security heartbeat too broadly. The article classifies Missing Heartbeat Alerts as a checkpoint: endpoint status, traffic path, DNS design, firewall rule and Sophos Central health must be considered together.

Short answer

A missing heartbeat alert should be checked, but not blindly treated as a malware case. First you clarify:

• Is Sophos Endpoint installed and active on the affected device?
• Is the traffic really going through the same Sophos firewall that expects the heartbeat?
• Did the device just switch between LAN, WLAN, VPN or an external network?
• Does the device use external DNS resolvers even though the firewall sees the DNS traffic?
• Does a firewall rule enforce Security Heartbeat for devices that cannot send a heartbeat at all? When multiple alerts occur shortly after network changes, docking station changes, or Wi-Fi/LAN switches, the focus is usually on design and timing, not a single infected client.

What Missing Heartbeat means

Security Heartbeat is part of Synchronized Security. Sophos Endpoint and Sophos Firewall report security-relevant status information via Sophos Central. The firewall can use this status in rules, for example to restrict devices with a red heartbeat. A missing heartbeat alert occurs when the firewall assigns traffic to a device but does not see a matching heartbeat. This can have several reasons:

• The endpoint does not send a heartbeat.
• The traffic comes from a device without Sophos Endpoint.
• The client is not behind the same firewall.
• The firewall only sees part of the traffic.
• DNS or network changes create an incomplete picture for a short time. The basic function is classified in the article Connect Sophos Firewall to Sophos Central. If Security Heartbeat is used in firewall rules, Create and understand Sophos Firewall rules also fits.

Typical causes

The alert is particularly often misunderstood when Microsoft Defender or another EDR product is in use. Such devices may be properly protected, but do not send a Sophos security heartbeat. Heartbeat-based rules should therefore only apply where Sophos Endpoint is really a requirement.

Check DNS design

DNS traffic is a typical trigger for missing heartbeat alerts because devices often continue to generate DNS queries or short background connections during network changes. When clients use external DNS resolvers, the firewall can see traffic without a clean match between heartbeat, client path, and policy design. In environments with Security Heartbeat it is therefore important that the DNS design is conscious:

• Which DNS servers do clients receive via DHCP?
• Do managed clients use the firewall, internal DNS servers or external resolvers?
• Do internal domains run via DNS request routes?
• Are there VPN profiles, WLANs or guest networks with different DNS servers?
• Are there browser or endpoint functions that send DNS past the local resolver? When clients use the Sophos Firewall as a DNS forwarder, internal domains must be resolved using appropriate DNS request routes. The flow is in Configure DNS Request Routes on Sophos Firewall. On the other hand, if clients use internal DNS servers directly, that is also legitimate. But then you shouldn’t expect that a DNS request route on the firewall influences every client query. What matters is which resolver is actually used from the client’s perspective.

Check firewall rules with heartbeat

Security Heartbeat should not be casually built into every client rule. A heartbeat condition is an access requirement. If there are devices without Sophos Endpoint, mixed endpoint strategies, or special networks, a rule that is too broad will quickly lead to false positives or unexpected blocks. Useful questions for checking rules:

1. Which rule generates the alert or blocks traffic?

2. Is Configure Synchronized Security Heartbeat active in this rule?

3. Does the rule only apply to Sophos managed endpoint devices?

4. Are there any exceptions for printers, scanners, IoT, servers, guests or third-party EDR?

5. Is heartbeat required for source, destination or both sides?

6. Is there a separate rule for devices that cannot provide a heartbeat? For the actual rule analysis, Test firewall rule with Log Viewer, Policy Test and Packet Capture and Sophos Firewall rule does not work: check causes help.

Check logs and central

For individual alerts, the timing is often sufficient. For recurring alerts, you should check the firewall, Sophos Central and Endpoint together. These places are helpful on the firewall:

• Log Viewer: Check traffic, firewall rule, web, DNS and system events around the alert time.

• Protect > Rules and policies > Firewall rules: check affected rule and heartbeat condition.

• System > Sophos Central: Check Central registration and activated services.

• Diagnostics > Packet capture: check whether the traffic really goes through the firewall.

• Advanced Shell: evaluate heartbeatd.log and hbtrust.log if necessary. The most important service logs are collected in Find and organize Sophos Firewall service logs. In Sophos Central you also check:

• Is the endpoint online?

• Does the endpoint have a green, yellow or red status?

• Are there endpoint events at the same time?

• Is the computer duplicate, out of date or visible in the wrong tenant?

• Was the endpoint recently reinstalled, renamed, deleted or moved? If the firewall is not properly connected to Sophos Central, the Central connection itself should be checked first. This fits Connect Sophos Firewall to Sophos Central.

Troubleshooting flow

A compact process prevents you from immediately searching in the wrong place.

1. Note the alert time, client name, IP address, user and affected rule.

2. In Sophos Central, check that the endpoint was online and healthy at the same time.

3. On the client, check that Sophos Endpoint is installed, up to date, and connected.

4. Check network path: LAN, WLAN, VPN, docking station, other site network or external network.

5. Check the client’s DNS server and compare it to the expected design.

6. Check in the firewall rule whether Security Heartbeat is set deliberately and tightly enough.

7. Check in the log viewer which traffic triggered the alert.

8. Evaluate packet capture and heartbeat logs for recurring cases.

9. Adjust rule or DNS design if the alert arises from normal operations. The order is important: First clarify whether the client can deliver heartbeat and whether the traffic goes through the expected firewall. Only then is it worth analyzing individual logs in detail.

Typical fixes

A correction should fit the operating model. In a pure Sophos endpoint environment, Heartbeat can make sense as a hard access requirement. In mixed environments, Heartbeat is more of a targeted control tool for specific client groups.

Checklist

• Affected devices always send Sophos Security Heartbeat.
• Firewall and endpoint are in the correct Sophos Central tenant.
• Traffic goes through the firewall, which expects the heartbeat.
• DNS servers and DNS request routes are documented.
• Firewall rules enforce heartbeat only for matching sources.
• Devices without Sophos Endpoint have their own rules or exceptions.
• Log viewer, endpoint events and alert time were checked together.
• Recurring alerts have been grouped by network changes, VPN and DNS patterns.

Frequently Asked Questions