Use Sophos Firewall Log Viewer correctly

In SFOS 22, Log Viewer is often the fastest starting point for an incident: Which firewall rule handled the traffic, which NAT rule was involved, which user was identified, and which security module blocked it? To get the right answer, the module, time range, filters, and timing of the log entry must match.

Log Viewer shows logged events. It is not Packet Capture and not a complete connection history. A missing entry therefore proves neither a drop nor that the packet reached the firewall.

For reliable analysis, always record the source, destination, service, exact test time, and expected direction. Then create exactly one new test flow and search for it in the relevant modules.

Evaluate a test in seven steps

1. In the affected firewall rule, check Log firewall traffic, or Log connections in the SSL/TLS rule.
2. Under System services > Log settings, make sure the required log type is enabled under Local reporting.
3. Open Log viewer (SFOS 22) or Logs and policy test (SFOS 23) in the upper-right corner of WebAdmin, then select the relevant log module.
4. Set the time filter and use Add filter to narrow the view first by source IP, destination IP, and service.
5. Create a new, short test flow and record its exact time.
6. In Detailed view, check Rule ID, NAT ID, action, interfaces, user, and module-specific fields.
7. If the entry and observed behavior do not match, correlate the same test with Packet Capture before changing a rule.

This sequence separates three questions that are often mixed together: Was a log created at all? Which policy made the decision? And did the packets actually enter and leave again?

Event logs record authentication, system events, and configuration changes as well as traffic, and are stored locally by default. Troubleshooting logs are detailed service logs accessed through WebAdmin or the CLI. The service-log workflow explains access and debug collection. Debug uses additional disk space and must be turned off after collecting the required data; it is not a switch for missing event logs.

For central forwarding, the firewall must be registered for Sophos Central Firewall Management. Then enable Central services and Send reports and logs to Sophos Central, and select the required log types under System services > Log settings. The reviewed SFOS 22 documentation calls the destination Sophos Fusion, while the SFOS 23 documentation calls it Sophos Central; follow the named UI fields. The Central Reporting workflow covers setup and receipt checks.

Read log entries correctly

Why log entries do not always appear immediately

Log Viewer refreshes the display automatically. A firewall session, however, is normally logged only when the firewall receives a Destroy event and closes the connection. With a long-running session, the log can therefore appear later than the first request.

If a connection ends without the firewall receiving a Destroy event, for example during loss of internet connectivity, the expected session log may be missing entirely. SSL/TLS connections are logged after a successful handshake and when they close. For a short test, a deliberately closed connection is therefore better than a permanently open browser, streaming, or HTTP/2 session.

A browser refresh does not necessarily create a new connection. Depending on the application, a private browser window, a restarted client process, or a short request such as the following is suitable for a reproducible test:

curl -I https://example.com/

Run the command on the test client, not in the firewall shell. example.com is a reserved example domain and can be replaced with a known, allowed service.

Select the right module

A traffic flow can touch several log modules. The Firewall module may show that a LAN-to-WAN rule allowed the connection, while Web filter, Application filter, IPS, or SSL/TLS inspection later blocks or otherwise handles the same flow.

For that reason, one green firewall entry is not sufficient for web or security problems. Correlate the modules for the same test flow using the test period and addresses:

• Firewall: Rule decision, NAT, interfaces, ports, and basic connection status.
• Web filter: URL, category, and web policy decisions.
• SSL/TLS inspection: Certificate, handshake, and decryption decisions.
• Application filter: Identified application and Application Control action.
• IPS: Signature or anomaly events.
• VPN: Establishment and status of the relevant VPN component.
• Authentication: Identified user and successful or failed authentication.
• System: System and administrator-triggered events.
• SD-WAN: SD-WAN profile, SLA, and route usage.

Which log types appear locally is configured under System services > Log settings in Local reporting. These event logs are not the same as on-box reports. Central reporting and syslog are separate destinations and must be enabled independently. Web policy events also require Log firewall traffic in the associated firewall rule. Wireless logs aren’t available in Log Viewer; send them to Sophos Fusion (formerly Sophos Central) or a syslog server instead.

Web proxy boundary: The SFOS 22/23 log-behavior documentation describes this proxy path for HTTP/HTTPS on ports 80 and 443: a matching Drop rule passes incoming packets to the web proxy, which sends the user a block page; without a matching web exception, the Firewall log shows Allowed and the Web filter log Blocked. Web exceptions still apply and can permit requests despite Drop. The documented Reject path terminates the flow before proxy processing. Review the firewall rule, web policy, and web exceptions together; this is a documented scenario, not a universal block-page guarantee for every build or inspection mode.

Unresolved documentation conflict: The SFOS 22/23 rule-form help describes authentication of unknown web users when Use web authentication for unknown users is enabled, permits matching web exceptions, and otherwise describes an HTML block page. The dropped-traffic logging guide instead describes silent discard and ties the web block page to that authentication option. Do not infer that the option alone determines the response. Before relying on Drop for web blocking, obtain written Sophos clarification for the exact version, build, and processing path, or use explicitly authorized, isolated verification. Record the current rule/settings for rollback; check HTTP and HTTPS separately, known/unknown users, authentication on/off, and matching exceptions present/absent. Correlate fresh flows with Rule ID, logs, Packet Capture, and browser results. Neither a block page nor a timeout alone proves blocking. If access is unexpected or results are unclear, restore test changes and escalate; do not roll out to production.

For ports other than 80 and 443, a matching Drop rule drops packets directly; the Firewall log shows dropped. With Reject, the Firewall log shows rejected on both ports 80/443 and other ports. These observations require Log firewall traffic in the matching rule. A web exception may, for example, allow Microsoft Windows updates despite a Drop rule; that is not a reason to broaden the rule without investigation.

Allow rule and missing heartbeat

A different case from Drop occurs when the firewall rule that actually matches has Action Allow, Block clients with no Heartbeat is enabled, and the endpoint sends no heartbeat. Log firewall traffic must be enabled in that rule for the log observations described here. Before searching, also check the required log types under System services > Log settings > Local reporting; enabling an external log destination alone is not sufficient for the local view.

• Ports other than 80 and 443: The firewall drops this endpoint’s packets. The Firewall log shows dropped.
• Ports 80 and 443 in the documented web proxy path: The firewall accepts incoming packets and passes them to the web proxy. Because the endpoint sends no heartbeat, the heartbeat system decides to block; the proxy sends the user a block page. The Firewall log shows allowed, another Firewall log shows Heartbeat blocked, and the Web filter log shows blocked. Here, Heartbeat blocked therefore also belongs to the Firewall module, not a separate heartbeat log module.

Allowed alone does not prove successful access. Before changing a rule, correlate entries for the same test flow: review the test period, source and destination, ports, and matching rule together. Look for the separate Heartbeat blocked entry and the Web filter entry showing blocked. This does not require a fixed event order, identical timestamps, or a universal number of log rows; if expected entries are missing, first check logging, local destinations, and filters, and use Packet Capture if needed.

This interpretation applies to this exact rule option, an endpoint without a heartbeat, and the described proxy path. It is not a general statement about every Allow rule, red or otherwise unhealthy endpoints, or other inspection modes. Do not disable heartbeat enforcement as a generic fix; first establish the rule match and why the heartbeat is missing.

Distinguish Standard view and Detailed view

Standard view is useful for quick reading. Columns can be added or removed, and clicking a value can use it directly as a filter. For technical acceptance, Detailed view is more important because it shows the underlying field names and additional values.

One important NAT detail: If a translated source address other than the default MASQ address is used, Standard view can still show the MASQ address as the outgoing address. The actual translated source appears in Detailed view in src_trans_ip.

In Standard view, hovering over a module icon also shows details. The copy control copies log information to the clipboard. The viewer opens in a new full-screen browser window; if it does not appear, check the browser’s popup blocker first.

Typical fields for a firewall test include:

• Source and destination IP, and source and destination port
• In interface and Out interface
• Firewall Rule ID and NAT Rule ID
• Action or status
• Username, if an identity was detected
• Translated source and destination
• Log component and Log subtype

A field name or ID does not automatically explain the cause. Compare the Rule ID with the current rule base, the NAT ID with the corresponding NAT rule, and a security policy ID with its module.

If a packet capture is running at the same time under Diagnostics > Packet capture, Open PCAP on the matching log entry can open the associated packet information. This connects the logged decision with packet details, but it does not replace a narrowly scoped capture filter: source, destination, port, and test time must still match the flow being investigated.

Isolate the correct flow

Set filters so that only the correct flow remains

Log Viewer provides four filtering levels:

1. Module: Limits the view to Firewall, Web, IPS, VPN, or another area.
2. Time / Timer filter: Limits events to the test period; click Timer filter and select a time option.
3. Add filter: Combines a specific field, condition, and value.
4. Free text search: Searches for ports, IP addresses, users, or rule names, for example, and also works with anonymized information.

For a normal connection test, start with source IP, destination IP, and destination port. Then narrow further with Rule ID, user, or action. Reset clears all filters. This matters because an old time or field filter can easily create the impression that the viewer is no longer receiving events.

The number of available entries depends on disk size and local retention. Log Viewer is therefore not a replacement for long-term, tamper-resistant storage. For that, use Central Firewall Reporting or Send syslog to a SIEM.

The local event-log quota depends on the appliance model: for higher-end models, Sophos gives up to 15 percent of the entire /var partition or 50 percent of its free space, whichever is lower. This is neither a guaranteed retention period nor a quota for every model. The storage analysis distinguishes event logs, reports, and troubleshooting logs; do not delete files speculatively.

Use Pause, Refresh, and CSV export correctly

Pause stops automatic display refresh. It is useful when a row must be read or copied without moving. It does not stop logging on the firewall. Refresh reloads the view manually, and Export downloads the currently available logs as CSV.

Before exporting, document the module, time range, and filters. The CSV may contain internal IP addresses, usernames, URLs, and communication relationships, so it belongs in a protected support or analysis workflow.

When Data anonymization is enabled, identifying values such as usernames, IP, MAC, and email addresses are shown in protected form. Sophos recommends at least two authorizers: if the signed-in administrator is one of them, at least one other authorizer must approve deanonymization. A screenshot or export should still contain only the rows required for the case.

To reveal identities using the deanonymization control, you must be authorized and provide your authentication credentials. Copying a row does not replace this authorization.

Understand Log suppression and Log occurrence

Under System services > Log settings, the firewall can suppress consecutive, identical firewall events. This saves storage and processing. Suppression affects not only local logs but also Sophos Fusion and configured syslog destinations.

In Log Viewer, Log occurrence shows how often a summarized event occurred. One row can therefore represent many repetitions. It must not automatically be counted as one packet or one connection.

Before changing Log suppression, check whether the current log volume is actually causing a problem. For a short diagnosis, consciously reading Log occurrence is usually sufficient. A global change also affects external log destinations and should not be made only to produce a screenshot.

Interpret findings safely

Interpret Invalid traffic correctly

Invalid traffic means that conntrack could not associate a packet with a current connection. This can occur with an asymmetric path, an expired session, unexpected TCP flags, or additional RST and FIN packets. It is not automatically an attack or a firewall defect.

If a connection problem occurs at the same time, capture both directions with Packet Capture. Source, destination, TCP flags, interfaces, and timestamps must belong to the same flow. Increasing Tcp Connection Establishment Idle Timeout may reduce the number of such logs, but it does not resolve the underlying path or session cause. Do not change the value speculatively.

Invalid traffic logging is enabled by default. Conntrack follows TCP sessions and certain UDP and ICMP sessions; initiating packets such as TCP SYN or an ICMP echo request establish the connection association. Interpret TCP flags as follows:

• SYN: requests synchronization.
• SYN-ACK: acknowledges it and agrees connection parameters.
• ACK: confirms the agreement; data transfer can begin.
• PSH: requests immediate data delivery.
• FIN: requests an orderly end; both sides acknowledge completion.
• RST: ends the connection without waiting for a response, for example after an unexpected packet.

Additional RST and FIN packets can be dropped and logged as Invalid traffic. Correlate an individual entry with the actual connection problem rather than treating it as a separate attack.

The read-only command show advanced-firewall in the Device Console shows the current global value; Sophos documents 10800 seconds, or three hours, as the default. A change affects all corresponding TCP sessions on the firewall. First correlate the affected application, its actual idle time, and the Invalid traffic event. A higher timeout is a justified operational adjustment only, not a repair for asymmetric routing or packet loss.

The complete drop workflow with Reason, Rule ID, and the special Firewall ID 0 is described in Analyze dropped packets on Sophos Firewall.

The source calls the field Tcp Connection Establishment Idle Timeout, but describes conntrack entries expiring after inactivity and uses the setter tcp-est-idle-timeout. This naming is ambiguous; it does not establish a separate handshake timeout. Check the actual output and CLI help on your build.

The SFOS 22/23 CLI reference explicitly assigns tcp-est-idle-timeout to established TCP connections and permits 2700 to 432000 seconds. The differing field name is therefore not used as a recommendation to change a connection-establishment timeout.

Only if a confirmed idle-timeout case justifies a global adjustment, select 4. Device Console in the CLI, record the existing value with show advanced-firewall, and arrange a maintenance window. The documented example increases it to six hours, not a generally recommended value:

set advanced-firewall tcp-est-idle-timeout 21600
show advanced-firewall

Check the new value and retest the same application across the relevant idle period. Fewer Invalid traffic entries alone do not prove a repair. For rollback, use the same setter with the previously recorded number of seconds and check again with show advanced-firewall; use 10800 only if that was the original value. If CLI output is unclear or the problem persists, stop adjusting and investigate the packet path or involve support.

Modify rules from Log Viewer only in a controlled way

Depending on the event, Log Viewer can open web policies, NAT, firewall, or SSL/TLS rules directly. Clicking a web policy, NAT rule, or firewall rule offers a link back to its editor in WebAdmin. This is convenient, but it does not shorten the technical check. Before editing, verify the Rule ID, rule name, position, zones, objects, service, user match, and existing sessions; also record the current values of the fields you will change for rollback.

For an SSL/TLS exception, select SSL/TLS inspection, scroll to Manage, select Exclude, review the option in the dialog, and only then confirm with Exclude. Domain and Subdomain are added to the URL group Local TLS exclusion list, shown under Categories and websites in SSL/TLS rules. Web category goes into Exclusions by website or category, visible on the SSL/TLS rule list page. For Other properties, select the SSL/TLS rule and suitable objects such as usernames or IP addresses. Check the target object and exception scope before confirming; a domain exclusion is not equivalent to an exception intended for one user only. Log Viewer does not offer Exclude for 19004 (allowed traffic) or 19005 (blocked by a web policy).

Clicking an IPS Signature ID can offer Disable signature for this IPS policy. This changes the active IPS policy, not just the display. Document the affected rule, policy, signature, protection impact, and scope of the exception first, then retest exactly the confirmed flow.

A broad allow rule, global web exception, or disabled TLS inspection can hide the symptom while creating a new security gap. Limit changes to the confirmed flow, test them in a maintenance window, and validate a new flow again in Log Viewer and, if necessary, Packet Capture. If the test fails or the exception is too broad, restore the previously recorded state in the linked rule or policy object and test again with a new flow.

When logs are missing or stored on the other HA node

When expected logs are missing

Check an empty result in this order:

1. Check Pause, module, time range, and filters, then use Reset and Refresh.
2. Check rule logging and Local reporting for the required log type.
3. Create a new, deliberately closed connection with a known timestamp.
4. Use Packet Capture to confirm that traffic reaches the firewall and which Rule ID handles it.
5. Check other modules for events belonging to the same flow.
6. Only investigate the viewer or logging service path if the entire local view receives no new events.

The version-specific diagnostic workflow for a completely stalled viewer is described in Log Viewer shows no new logs. A service restart or intervention in the local log database is not part of normal usage.

Log Viewer in HA environments

Each HA node stores only the logs and reports for traffic that it handled. Especially in active-active mode or after a failover, the expected entry may therefore be on the other node. Document the time, node role, and Connection served by together.

Central Firewall Reporting or syslog can provide a central view. They do not replace the node-specific check when investigating a particular HA role change, local service failure, or the traffic path at the time of the event.