Use Sophos Firewall Log Viewer correctly

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 in the upper-right corner of WebAdmin and select the relevant 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?

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 timestamp 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.

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.

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.

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: Limits events to the test period.
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.

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. Deanonymization requires an authorized person and their credentials. A screenshot or export should still contain only the rows required for the case.

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 Central 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 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.

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

Modify rules from Log Viewer only in a controlled way

Depending on the event, Log Viewer can open web policies, firewall rules, or SSL/TLS rules directly. 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.

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.

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.