Analyse Dropped Packets on Sophos Firewall

When the Sophos Firewall drops packets, it is not automatically an error. Often, it is the desired security decision: a rule does not match, a policy blocks, a packet belongs to no known connection, or a module like Web Filter, IPS, or Application Control intervenes.

It becomes challenging when a service does not work, and it is unclear whether the firewall is blocking, the traffic is not arriving, or the return traffic is taking a different path. Then, a clear sequence is needed: first Log Viewer, then Packet Capture, and then, if necessary, service logs or CLI.

For general rule matching, see Test firewall rule with Log Viewer, Policy Test, and Packet Capture. This article focuses on drops and dropped packets.

Which Troubleshooting Article Fits?

Not every connection problem is a drop problem. Depending on the observation, a different starting point may be quicker:

• A drop, Invalid traffic, Violation, or Firewall ID 0 is visible in Log Viewer or Packet Capture: This article.
• An expected firewall rule is not matched: Check causes for Sophos Firewall rule not matching.
• A rule needs targeted validation after a change: Test Sophos Firewall rule with Log Viewer and Packet Capture.
• Packets need to be checked in WebAdmin with a tight filter: Use Sophos Firewall Packet Capture in WebAdmin.
• WebAdmin shows too little and log files are needed: Sophos Firewall Troubleshooting: Services and Logs.
• Logs need to be retained longer or centrally correlated: Send Sophos Firewall Syslog to SIEM.
• WebAdmin, SSH, DNS, VPN Portal, or SNMP to the firewall itself is affected: Secure Sophos Firewall access: Configure Device Access correctly.
• IPsec tunnel is up, but traffic does not flow correctly: Sophos Firewall IPsec VPN Troubleshooting.
• Large transfers hang or individual applications break: Check Sophos Firewall MTU and MSS for VPN issues.

This selection saves time because not every problem is treated as a firewall rule error. First, it must be clear whether the firewall sees the traffic, which rule or module decides, and whether the return path even runs the same route.

A Drop is Not Just a Drop

For analysis, you should first distinguish what type of drop is present. Otherwise, you quickly search in the wrong place.

• Intentional Drop: The firewall blocks according to rule, Web Policy, IPS, or Threat Feed. Check if the policy is technically correct.
• Unexpected Drop: Legitimate traffic is dropped by a rule or module. Check Rule ID, NAT ID, module, and reason in Log Viewer or Packet Capture.
• No Firewall Drop: The traffic does not reach the firewall, or the response takes a different path. Check client, VLAN, switch, gateway, route, SD-WAN, or return path.

This classification prevents unnecessary exceptions. If the drop is intentional, no technical repair is needed, but a policy decision. If the traffic does not reach the firewall, no new firewall rule will help. If a security module blocks, a broad firewall rule should not be blindly created.

Initial Classification

Before analysis, you should narrow down the error as concretely as possible.

Important questions:

• Which source IP and destination IP are affected?
• Which port and protocol are used?
• Is it about client internet, site-to-site VPN, remote access, DNAT, WAF, or internal traffic?
• Is the error permanent or sporadic?
• Does it affect only one application, only one user, or an entire network?
• Was a firewall rule, NAT rule, route, SD-WAN rule, TLS Inspection, or Web Policy changed shortly before?

Without this information, you often search too broadly in the Log Viewer. A reproducible test with time, IP addresses, and expected direction is better.

Using Log Viewer Correctly

The Log Viewer is the first starting point. It shows event logs and can be filtered by module, time, field, and free text.

The Log Viewer opens at the top right in the WebAdmin interface. For drops, these modules are important depending on the case:

• Firewall: Rule matching, allowed and dropped connections.
• Web: Web Policy, category, URL group, malware scan.
• SSL/TLS inspection: Decryption, TLS errors, exceptions.
• Application filter: Application Control hits.
• IPS: Intrusion Prevention and DPI decisions.
• Active threat response: Threat Feeds, NDR Essentials, or other ATR hits.
• Web server protection: WAF, reverse proxy, and published web services.
• VPN: IPsec, SSL VPN, and remote access events.

Firewall rules typically log sessions when the firewall receives a Destroy event and closes the connection. If a connection ends without this event, it does not always appear as expected. For SSL/TLS connections, the connection is logged after the handshake and when closing.

Log configuration is also important. If a log type is not enabled under System services > Log settings, it is not reliably visible locally, in Sophos Central, or in Syslog. For long-term evaluation, Send Sophos Firewall Syslog to SIEM or Enable Central Firewall Reporting is suitable.

Classify Invalid Traffic Events

Invalid traffic is an important finding, but not a complete root-cause analysis. The firewall uses it to report traffic that does not cleanly fit a valid connection or policy decision. Typical causes are packets outside an expected session state, asymmetric paths, expired sessions, unexpected TCP flags, or return traffic that does not use the same path.

For such events, do not build an allow rule first. This sequence is better:

1. Take source, destination, port, and time from the event.
2. Check in Log Viewer whether a Firewall Rule ID, NAT Rule ID, or module is visible.
3. Use Packet Capture to test whether both directions pass through the same firewall.
4. Check routing, SD-WAN, VPN paths, HA role, and return route.
5. Only then decide whether a rule, NAT logic, route, or security profile needs to be adjusted.

Invalid traffic is especially valuable as an indication of state or return-path problems. If only the allow rule is expanded, the actual cause often remains.

Using Packet Capture Correctly

The menu path is:

Diagnostics > Packet capture

Packet Capture shows whether packets arrive at an interface, are forwarded, processed by the firewall itself, or dropped. This is especially important if nothing clear appears in the Log Viewer.

Basic procedure:

1. Narrow down the test case: Note source IP, destination IP, port, and protocol.
2. Open Diagnostics > Packet capture.
3. Set capture filter as tightly as possible.
4. Activate Packet Capture.
5. Reproduce the problem.
6. Stop the capture.
7. Check entries for source, destination, Rule ID, NAT ID, status, and reason.

Packet Capture shows, among other things, Rule ID, NAT ID, Status, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID, and Username. These fields help when not only a firewall rule but also Web Filter, IPS, Application Control, or NAT are involved.

For tool operation, Use Packet Capture in WebAdmin is the more detailed guide.

Understanding Packet Capture Status

The status values are crucial for analysis. Sophos Firewall offers six status values in the display filter: Allowed, Violation, Consumed, Generated, Incoming, and Forwarded.

• Incoming: Packet arrives at a WAN or LAN interface. Source reaches the firewall.
• Allowed: The packet was permitted by the applicable firewall rule or policy. This status often overlaps with Forwarded in practice; if a packet shows as Allowed but not Forwarded, check routing, the return path, or a downstream security module.
• Forwarded: Packet is forwarded. Firewall generally allows the packet.
• Consumed: Packet is intended for the firewall itself. Device Access, VPN Portal, DNS, DHCP, or other local service.
• Generated: Packet is generated by the firewall. Response or system traffic of the firewall.
• Violation: Packet is dropped due to a policy violation. Rule, module, or security function blocks.

A single Incoming without a matching Forwarded can mean that the firewall drops the packet, processes it itself, or that the filter does not show the entire flow. Therefore, both directions should always be considered.

After the first status, an exception should not be created immediately. It is better to derive the next test from the status:

• Only Incoming visible: Check filter, capture opposite direction, search for Rule ID, and exclude Firewall ID 0.
• Incoming and Forwarded, but no response: Check return route, target system, local server firewall, NAT, and asymmetric routing.
• Consumed visible: Check Device Access, Local service ACL, and affected local firewall service.
• Generated visible: Check if the firewall itself responds or generates system traffic.
• Violation visible: Match reason, Rule ID, NAT ID, and affected module in Log Viewer.

This keeps the analysis reproducible: The status determines which tool is sensible next. For Violation, the Log Viewer is important; for missing responses, rather the return path and Packet Capture; for Consumed, Device Access instead of a firewall rule.

Quick Symptom Triage

In practice, a short symptom table saves time before going deeper into logs or the shell:

• Log Viewer shows Invalid traffic: Session state, return path, asymmetric routing. Check both directions with Packet Capture.
• Packet Capture only shows Incoming: Drop, local service, default rule, or incomplete filter. Broaden filter, run Policy Test, check Firewall ID 0.
• Packet Capture shows Forwarded, but no response: Target system, return route, NAT, external firewall. Check response packets and return path.
• Packet Capture shows Consumed: Traffic to the firewall itself. Check Device Access and Local service ACL.
• Packet Capture shows Violation: Rule, security module, or policy violation. Compare Reason, Rule ID, NAT ID, and module log.
• Log Viewer and Packet Capture show nothing: Traffic does not reach the firewall. Check client, VLAN, switch, gateway, or wrong test target.

Firewall ID 0 and Explicit Drop Rule

If no explicit firewall rule matches, Sophos Firewall drops the traffic through the built-in final rule with Firewall ID 0 or Policy ID 0. This rule is always at the end of the firewall rules. Important for troubleshooting and SIEM: the built-in drop-all rule does not log traffic itself. Anyone who wants all dropped connections to be traceable therefore needs a dedicated explicit drop rule with active logging.

If drops by the default rule are not visible, the policy decision is not automatically wrong. In Packet Capture, only Incoming may be visible without a matching Violation Firewall entry. The problem is then traceability in troubleshooting, not necessarily the actual drop decision.

If a test case does not match any rule and no drop is visible, also check:

1. Use Policy Test and check whether the test falls on Firewall ID 0 or the default rule.
2. Check rule order and ensure that no other rule unexpectedly matches higher up.
3. Create an explicit drop rule at the end of the rule base if drops should be logged or forwarded to Central Reporting or Syslog.
4. Run the test again and check whether the drop is now visible with the explicit rule ID.
5. Include the explicit drop rule in change documentation and rule review so that it is not later misunderstood as a normal allow or deny rule.

When creating the final rule, choose zones deliberately. Sophos recommends using individual source and destination zones rather than setting Any broadly as the zone, so that internal services are not affected unnecessarily. For an audit-proof environment, the explicit final rule is helpful. It does not replace a clean rule structure. If a lot of legitimate traffic lands on the final rule, a more precise allow rule is probably missing higher up, or a network is incorrectly classified.

Reading Important Fields in Packet Capture

For drops, not only the status is important. The additional fields show which part of the firewall processed the traffic.

• Rule ID: Matched firewall rule. Does it match the expected rule?
• NAT ID: Matched NAT rule. Is NAT expected, is NAT missing, or is a wrong NAT rule applied?
• Reason: Reason for drop or violation. Do not read in isolation, but compare with status and module.
• Web filter ID: Web policy decision. Check category, URL group, and user context.
• Application ID: Recognised application. Application Control may decide differently than the port suggests.
• IPS policy ID: Applied IPS policy. Check signature, rule context, and false-positive risk.
• Username: Recognised user. Only evaluate user matching if the user is really visible.

If Rule ID or NAT ID are unexpected, do not immediately create an exception. First, it must be clear whether the test case was correctly defined, whether a more general rule matches higher up, or whether NAT changes the view of source and destination.

Use Reason as a Guide

The Reason value is not a complete root-cause report, but it is a useful guide to the next module. Firewall points more towards the rule base, default rule, or zone logic. LOCAL_ACL fits Device Access and Local service ACL. INVALID_TRAFFIC points more towards session state, return path, or asymmetric routing. APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION, or VIRTUAL_HOST show that the firewall rule should not be the only thing checked.

A short three-step sequence is helpful: read the status first, classify Reason next, then open the matching module in Log Viewer. This turns a single Violation entry into a traceable check path instead of an invitation to create a broad exception.

Consumed and Local Firewall Services

Consumed is not a normal drop. The status means that the packet is intended for the firewall itself. Typical targets are WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN, or SNMP.

In such cases, it is often not the normal firewall rule that is decisive, but Device Access and Local service ACL. If, for example, WebAdmin, SSH, VPN Portal, or SNMP are not reachable, you should not only search under Rules and policies > Firewall rules. The correct starting point is usually Administration > Device access.

For hardening and troubleshooting local firewall services, Secure Sophos Firewall access: Configure Device Access correctly is suitable.

Common Drop Causes

No Matching Firewall Rule

The most common cause is a rule that does not match. Reasons can be:

• Incorrect source zone
• Incorrect source network
• Incorrect destination zone
• Destination IP misinterpreted in DNAT
• Missing service or incorrect protocol
• User is not authenticated
• Schedule does not fit
• A more specific rule is below a more general rule

For rule structure, Understand and configure Sophos Firewall rules correctly helps. If DNAT is involved, Publish server via DNAT on Sophos Firewall should also be checked.

NAT or Return Path Does Not Fit

Sometimes the firewall allows the outbound path, but the response comes back differently or is incorrectly translated.

Typical points:

• SNAT or MASQ is missing.
• DNAT points to the wrong internal host.
• A linked NAT rule was disabled.
• Return route is missing.
• SD-WAN or static routing sends response traffic over a different path.
• For VPN traffic, a suitable IPsec route or return route is missing.

Asymmetric routing often creates difficult-to-understand errors because the firewall cannot cleanly assign the connection state. Then packets may appear as not belonging to the connection.

Packet Belongs to No Known Connection

Messages like Could not associate packet to any connection or similar Conntrack hints often mean that the firewall cannot find a suitable connection context object.

Possible causes:

• Return traffic takes a different path.
• Connection was established on another HA node.
• Session has already expired.
• TCP flags do not match the expected connection.
• A device sends responses without a prior request.
• Stateful inspection only sees part of the data flow.

Here, Packet Capture is more important than a single log entry. You need to see if both directions run through the same firewall and the same zone.

Web Filter, TLS Inspection, Application Control, or IPS Blocked

Not every drop comes from the firewall rule itself. Often, traffic is allowed but then blocked by a security module.

Typical examples:

• Web Policy blocks a category or URL group.
• TLS Inspection fails due to certificate, SNI, cipher, or exception.
• Application Control detects an unwanted application.
• IPS blocks a pattern.
• Active Threat Response encounters an IoC.
• Zero-Day Protection holds back or blocks a download.

For IPS hits, you should check signature, policy, and rule context before setting a broad exception. The appropriate procedure is in Set up and safely test Sophos Firewall IPS.

For web and TLS cases, you should also check QUIC. If browsers bypass over UDP 443, web filter and TLS expectations do not always match. More on this: Correctly block Sophos Firewall QUIC and HTTP/3.

MTU, MSS, or Fragmentation

In VPN, PPPoE, SD-WAN, mobile networks, or nested tunnels, a packet can be too large for the path. Then you do not always see a clear firewall drop, but rather connection interruptions, slow applications, or individual services that hang.

For such cases, Check Sophos Firewall MTU and MSS for VPN issues is suitable.

Structured Procedure

For practice, this sequence works well:

1. Note test case: Source, destination, port, protocol, time.
2. Check Log Viewer: Filter by firewall module and appropriate security modules.
3. Search for Rule ID and NAT ID: Check which rule was actually hit.
4. Start Packet Capture: Set a tight filter and reproduce the test.
5. Check status: Evaluate Incoming, Forwarded, Consumed, Generated, or Violation.
6. Check return direction: Does the response come back and over the same path?
7. Check security modules: Web, TLS, Application Control, IPS, ATR, WAF.
8. Check service logs: Check appropriate log file under /log for service issues.
9. Check central logs: Include Central Reporting or SIEM if local logs are insufficient.

The appropriate service and log files are summarised in Sophos Firewall Troubleshooting: Services and Logs.

When Nothing Appears in Log Viewer

No log entry does not automatically mean the firewall is not involved.

Possible causes:

• Logging is not enabled in the firewall rule.
• The relevant log type is not active under System services > Log settings.
• The connection was not cleanly terminated and therefore not logged.
• The traffic does not reach the firewall.
• The traffic is processed by a local service.
• The filter in Log Viewer is too tight.
• The log storage is limited, or old entries have already been overwritten.

In such cases, use Packet Capture first. If Packet Capture also shows no entry, the focus is more on client, switch, VLAN, routing before the firewall, or incorrect test target.

When tcpdump or Log Archives Are Needed

The WebAdmin Packet Capture is good for quick analyses. For longer captures, PCAP files, very precise filters, or support cases, tcpdump via SSH is often better suited. This is especially true if a problem only occurs sporadically or if the capture is to be evaluated later in Wireshark or by Sophos Support.

For such cases, you should clarify before the capture:

• Which source IP, destination IP, and ports need to be in the filter?
• How long can the capture run?
• Where will the PCAP file be stored?
• Who is allowed to see the file?
• When will the file be deleted after analysis?

The practical procedure is in Sophos Firewall tcpdump: Capture packets via CLI. If service logs are needed alongside packets, Secure Sophos Firewall logs for support and analysis helps.

Set Exceptions Only Targeted

With drops, the temptation is great to quickly create an exception. This can help in the short term but often worsens security or hides the cause.

Exceptions should only be set when it is clear:

• which module blocks
• which host, domain, or application is affected
• why the traffic is legitimate
• how narrow the exception can be
• when the exception will be reviewed or removed

Broad exceptions for entire networks, Any rules, or global TLS exceptions should be avoided. A small, documented exception with a review date is better.

Document Findings

A good drop finding must be documented so that another person can replicate the test. This is important for internal reviews, change documentation, and support cases.

At least record:

• Date, time, and time zone of the test.
• Source IP, destination IP, port, protocol, and user.
• Expected firewall rule and actually visible Rule ID.
• Expected NAT rule and actually visible NAT ID.
• Packet capture status: Allowed, Incoming, Forwarded, Consumed, Generated, or Violation.
• Relevant reason or module message.
• Change made or consciously no change made.
• If an exception was set: owner, purpose, validity, and review date.

This documentation prevents a temporary troubleshooting step from becoming a permanent, unclear security gap.

Checklist

• Source IP, destination IP, port, and protocol known.
• Test time documented.
• Log Viewer checked with correct module and time filter.
• Rule ID and NAT ID evaluated.
• Checked for missing drop entry if Firewall ID 0 or the default rule is affected.
• Firewall rule and rule order checked.
• NAT rule and return route checked.
• Packet Capture conducted with a tight filter.
• Status and reason in Packet Capture evaluated.
• Checked both directions.
• Web filter, TLS Inspection, Application Control, IPS, and Active Threat Response checked.
• Checked MTU, MSS, and route for VPN.
• Checked target host, hosted address, and backend for DNAT or WAF.
• Checked central logs or Syslog if local logs are insufficient.
• Prepared tcpdump or log archive for support needs.
• Set exceptions only narrowly and documented.
• Documented findings with Rule ID, NAT ID, status, reason, and change.

Frequently Asked Questions