Analyse dropped packets on Sophos Firewall

A dropped packet is not automatically an error. The firewall may be blocking the traffic as intended, unexpectedly dropping legitimate traffic, or not seeing the flow at all. The following workflow quickly identifies whether the rule, NAT, return path, a security module, or a system upstream of the firewall is responsible.

Narrow down drops in a few minutes

1. Record the test case: Note the source IP, destination IP, port, protocol, time, and expected direction. For intermittent problems, also record the user, application, and latest configuration change.
2. Filter Log Viewer: Search the Firewall module by IP address, port, and time. Depending on the case, also open Web, SSL/TLS inspection, Application filter, IPS, Active threat response, Web server protection, or VPN.
3. Start Packet Capture: Under Diagnostics > Packet capture, set a narrow filter, activate the capture, and perform exactly one reproducible test.
4. Read the packet status: Incoming, Forwarded, Consumed, Generated, or Violation shows whether the packet arrives, is forwarded, is processed locally, is generated by the firewall, or is dropped.
5. Map the decision: Compare Rule ID, NAT ID, and Reason with the expected firewall and NAT rules. For Web, IPS, or Application hits, also check the corresponding policy ID.
6. Capture the return direction: If the outbound path is forwarded but no reply is visible, check the return route, destination system, NAT, SD-WAN, and asymmetric routing.
7. Only then make changes: Do not create a broad allow rule or global exception before the responsible module and actual cause are known.

For general rule matching and the Policy Tester, see the detailed guide Test a Sophos Firewall rule with Log Viewer and Packet Capture.

Read Log Viewer and Packet Capture together

Log Viewer and Invalid traffic

The Log Viewer opens at the top right of WebAdmin. It shows not only firewall decisions but also events from the security modules involved. For Web Proxy traffic, for example, the Firewall module may report Allowed while the Web module reports Blocked: the firewall rule permits the connection to the proxy, while the Web Policy blocks the content. Always correlate the modules for the same test time. Filters, Detailed view, session timing, and Log occurrence are explained in Use Sophos Firewall Log Viewer correctly.

Two requirements must be checked separately for firewall traffic:

• Log firewall traffic is enabled in the relevant rule. SSL/TLS rules have their own Log connections option.
• Under System services > Log settings, the required output target is enabled for Log Viewer under Local reporting, Sophos Central, or Syslog.

Firewall sessions typically appear when the firewall receives a Destroy event while closing the connection. If a connection ends without this event, the expected entry may be missing. For longer retention, use Central Firewall Reporting or Syslog to a SIEM.

Invalid traffic means that Conntrack cannot associate a packet with a current connection. An expired session or additional TCP RST and FIN packets can generate these events and do not automatically indicate an error. If connection problems occur at the same time, capture both directions and check possible causes such as a missing return route, an asymmetric path, or an HA role change. A longer Conntrack timeout may only reduce log entries; it does not resolve the cause.

If the specific drop reason is Invalid TCP reserved bit, Accurate ECN rather than a firewall rule may be the cause. Resolve Invalid TCP reserved bit caused by Accurate ECN explains how to prove the cause and assess the security impact of the global CLI workaround.

Status, Rule ID, NAT ID, and Reason

Packet Capture shows packets that pass an interface and adds processing information from the firewall, NAT, and security modules. The current SFOS 22 documentation defines these status values:

• Incoming: The packet arrives at an interface. This does not prove that it is forwarded.
• Forwarded: The firewall forwards the packet to an outbound interface. If the reply is missing, focus next on the destination system and return path.
• Consumed: The packet is intended for the firewall itself, such as WebAdmin, SSH, DNS, or a VPN portal.
• Generated: The firewall generates the packet itself, for example as a reply or system traffic.
• Violation: A policy violation causes the drop. Rule ID, Reason, and the responsible module indicate the next check.

Also important are Rule ID, NAT ID, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID, and Username. An unexpected value may mean that a broader rule higher in the list matches, NAT changes the visible addresses, or the user was not identified.

Reason is a guide, not a complete root-cause report. Depending on the version, values such as Firewall, LOCAL_ACL, INVALID_TRAFFIC, APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION, or VIRTUAL_HOST can point to the responsible module. Read the status and IDs first, then open the corresponding Log Viewer section. Sophos Firewall Packet Capture explains how to use and filter the tool.

Firewall ID 0 and missing drop logs

If no explicit firewall rule matches, the built-in Drop all rule at the end of the rule base applies with Policy or Firewall ID 0. It does not generate a normal firewall traffic log entry. To make these drops traceable in Log Viewer, Central Reporting, or Syslog, create a separate rule at the end of the rule base with Action: Drop and Log firewall traffic enabled.

Select the required source and destination zones individually and do not use Any indiscriminately for the zones. This keeps local services reachable. If the final rule receives a large amount of legitimate traffic, a suitable allow rule is probably missing higher in the list or a network has been classified incorrectly.

For SFOS 22.0.1 MR1 Build 490, Sophos also documents the known issue NC-178387: default drops with ID 0 are missing from Dropped Packet Capture and drppkt; normal Packet Capture may show only Incoming without a corresponding Violation Firewall entry. The traffic is still dropped. Sophos does not identify a confirmed fix version in the Known Issues List, so this behaviour must not be assumed outside the stated build.

If a default drop is suspected:

1. Check the rule order and Policy Test.
2. Compare the result with an actual Packet Capture.
3. If logging is required, create a final rule with specific zones and its own Rule ID.
4. Repeat the test and confirm the new Rule ID in the log or capture.

The Policy Tester under Diagnostics > Tools does not account for SD-WAN routes and must therefore never be the sole evidence. On SFOS 22.0 GA, NC-177587 could also show incorrect rule results; production logs and Packet Capture remain authoritative.

Narrow down the cause from the evidence

Rule, NAT, and return path

If the Rule ID does not match the expected rule, check the source and destination zones, network objects, service, protocol, user, schedule, and rule order. For DNAT, confirm whether the test targets the public address and which NAT ID actually applies. The fundamentals are covered in Understand firewall rules and Publish a server using DNAT.

If Packet Capture shows Forwarded but no reply, another allow rule is rarely the solution. Common causes include missing SNAT/MASQ or a missing return route, a disabled linked NAT rule, local blocking on the destination system, or SD-WAN sending the reply over a different path. Both directions must pass through the same stateful firewall.

Session, asymmetric routing, and HA

Messages such as Could not associate packet to any connection mean that no matching Conntrack entry was found. Possible causes include an expired session, unexpected TCP flags, an asymmetric return path, or a flow that the firewall sees in only one direction. After an HA role change, the node on which the connection was established may also be relevant.

A single RST or FIN event without a user-visible problem does not require an immediate change. For reproducible interruptions, capture both directions using the same filter, then check routing, SD-WAN, VPN paths, and HA status.

Consumed and local firewall services

Consumed is not a normal transit drop. The destination is the firewall itself, such as WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN, or SNMP. These connections are usually controlled by Administration > Device access and Local service ACL, not by a normal firewall rule. Secure Sophos Firewall Device Access explains the secure configuration.

Security modules, VPN, and MTU

A firewall rule can allow traffic before a downstream module blocks it. Therefore, if the IDs or Reasons indicate it, also check Web Policy, SSL/TLS inspection, Application Control, IPS, Active Threat Response, and WAF. For an IPS hit, assess the signature and rule context before creating an exception; the workflow is described in Safely test Sophos Firewall IPS.

For Web and TLS problems, QUIC over UDP 443 can change the expected processing. Block QUIC and HTTP/3 shows the relevant control.

With VPN, PPPoE, SD-WAN, or nested tunnels, MTU, MSS, and fragmentation are more likely to cause stalls or partial interruptions than a clear drop. See the guides for MTU and MSS and IPsec VPN troubleshooting.

When the standard checks are not enough

No entry in Log Viewer or Packet Capture

If a log entry is missing, first check rule logging, Log settings, the time filter, and the responsible module. If Packet Capture also shows no packets, verify the following before diagnosing the network:

• Packet Capture is actually active and the test was performed only after activation.
• The filter contains the correct addresses, ports, direction, and interface; broaden it slightly for a test.
• The 2048 KB buffer is not full. When the buffer is full, recording stops automatically and must be restarted after selecting Clear.
• Under System services > Services, Packet capture and Live connections is running; if it fails to start, restart this service in a controlled manner.

Only when a reproducible test with a working capture shows no incoming packet should the investigation move upstream of the firewall: client, VLAN, switch, gateway, upstream router, or an incorrect test target.

tcpdump, Drop Capture, and log archives

For longer captures, PCAP files, or precise BPF filters, sign in over SSH and select Option 4: Device Console. A narrow example capture for two hosts and HTTPS is:

tcpdump 'host 192.0.2.10 and host 198.51.100.20 and port 443'

The same filter can be used with drop-packet-capture for packets dropped by firewall rules:

drop-packet-capture 'host 192.0.2.10 and host 198.51.100.20 and port 443'

drop-packet-capture does not help with application-layer problems. For a PCAP file, tcpdump supports the filedump option; the file is stored temporarily under /tmp. Keep the capture as short and narrow as possible because packets may contain sensitive data, and delete the file after analysis. More examples are available in tcpdump on Sophos Firewall.

If support also needs service logs, first identify the responsible log and collect only the required time range. Sophos Firewall services and logs and Collect logs for support and analysis explain the process.

Fix and document the issue securely

An exception is appropriate only when the module, legitimate purpose, and narrowest scope are known. Do not permit a global TLS exception, an Any allow rule, or entire networks simply because the service then works. Specific hosts, services, and users with a review or expiry date are safer.

Before closing the case, document:

• Source, destination, port, protocol, time, and user.
• Expected and actually observed Rule ID and NAT ID.
• Status, Reason, and the security module involved.
• Outbound and return direction, or the point at which the flow ends.
• Change, owner, ticket, and review date; also record when no change was intentionally made.

Then repeat the same test. The permitted connection must work, and a comparison source that is not permitted must remain blocked. This prevents a quick fix from becoming a permanent security gap.

Frequently asked questions