Using Sophos Firewall Packet Capture in WebAdmin

Packet Capture is one of the most important troubleshooting tools in the WebAdmin of Sophos Firewall. It shows whether packets arrive at an interface, whether they are forwarded, which rule or NAT ID is involved, and whether a packet is dropped.

The Log Viewer shows the firewall’s decision. Packet Capture shows the packet flow. Together, they are often the quickest way to find the cause. If a firewall rule needs to be specifically tested, the process in Testing Sophos Firewall Rules with Log Viewer, Policy Tester, and Packet Capture is also suitable.

It’s important to note: This article describes the WebAdmin version of Packet Capture. It is ideal for an initial check because you can see directly in the browser whether packets arrive, are forwarded, or are dropped. For longer captures, very precise filters, PCAP export, or support cases, a tcpdump via SSH is often better suited.

Tool Selection

Which Article Fits?

Packet Capture is particularly strong when the actual packet flow is unclear. For related questions, a different starting point may be quicker:

This distinction is important: Packet Capture shows packets and status at the packet level. However, it does not replace the Log Viewer for policy decisions, the NAT article for translation logic, or tcpdump when an analysable PCAP file is needed.

When Packet Capture is Useful

Packet Capture is particularly helpful for questions like:

• Does the traffic even reach the firewall?
• Does the traffic exit on the expected interface?
• Does a firewall rule apply?
• Does a NAT rule apply?
• Is a packet dropped by policy, IPS, or routing?
• Does a response come back from the target system?
• Is a different port or protocol used than expected?

If nothing is visible in the Log Viewer, Packet Capture is often the next step. It shows whether the problem lies before the firewall or if the firewall processes the traffic.

If the focus is on drops, Violation, Rule ID, NAT ID, or dropped packets, Analyse Dropped Packets on Sophos Firewall is also suitable.

Menu Path

You can find the tool under:

Diagnostics > Packet capture

Packet Capture opens directly in WebAdmin. Depending on the SFOS version and browser display, it appears as a separate diagnostic window within the WebAdmin view.

Before opening, the test case should already be determined. The tool is most effective when reproducing a single flow rather than deciding what to look for during the capture.

After opening, you should first use Configure and set the capture filter before triggering the test. If the destination, CDN target, or NAT view is still unclear, an initial filter on the source IP is often better than a too narrow filter with the wrong destination address. After the reproduced test, the capture should be stopped again to prevent the view from filling up with background traffic.

Log Viewer, Packet Capture, or tcpdump?

Log Viewer, Packet Capture in WebAdmin, and tcpdump answer different questions. Using the wrong tool first often leads to searching in the wrong place.

A good example is a ping. In the Log Viewer, you often see only one entry or a summarised decision about the connection. In Packet Capture, you see the individual ICMP packets: Echo Request to the target and Echo Reply back. Windows sends four ICMP Echo Requests by default with ping. Therefore, you expect several request and reply packets in Packet Capture. If only the requests are visible but no replies come back, that’s a different problem than if no request reaches the firewall at all.

In practice, this means:

• Log Viewer answers: Which rule or module decided?
• Packet Capture answers: Did the packets really arrive and what path do they take?
• For routing, NAT, VLAN, gateway, or return path issues, Packet Capture is often more informative.
• For web filter, application control, IPS, or SSL/TLS inspection decisions, you also need the Log Viewer.
• For captures that go to Sophos Support or external analysis partners, tcpdump is usually better than a screenshot from WebAdmin.

Prepare Capture

Narrow Down Before Starting

Packet Capture should not be started unfiltered. In productive networks, this otherwise generates a lot of data, and the output becomes confusing.

⚠️ Packet Capture should never run as a broad continuous capture on productive firewalls. A narrow filter, a short test, and a clear timing reduce data volume, data protection risk, and misinterpretations.

You should note in advance:

• Source IP
• Destination IP or FQDN
• Protocol
• Source Port, if relevant
• Destination Port
• Interface or Zone
• Time of the test
• Affected application
• Expected firewall rule or NAT rule, if known
• Expected result: allowed, blocked, DNAT, SNAT, VPN, web policy, or IPS

For a web test, the narrowing could look like this:

In practice, you should always reproduce only one test case at a time. Multiple parallel changes to firewall rule, NAT, routing, and client configuration make the capture output difficult to evaluate. If the test concerns a user problem, you should also note the logged-in user, the affected device, and the exact time.

Configure Capture Filter

Use Configure to set a filter as narrow as possible.

Typical filters:

• Source IP of the client
• Destination IP of the server
• Destination Port
• Protocol TCP, UDP, or ICMP
• Interface

If you don’t know the target server, you can first filter only by the source IP. If too many packets are visible afterward, narrow it down further.

Sophos Firewall uses Berkeley Packet Filter syntax, or BPF. The capture filter determines which packets are written to the capture buffer at all. Therefore, it should be set cleanly before the test.

Typical BPF examples:

For a very targeted web test, a filter might look like this:

host 172.16.10.25 and host 93.184.216.34 and port 443

For a ping test, often this is sufficient:

host 172.16.10.25 and proto ICMP

If the Filter is Too Narrow

A narrow capture filter is important, but it must not hide the error. Especially with DNS, NAT, CDNs, and return paths, you should consciously decide whether to filter broadly enough first or immediately very precisely.

Typical pitfalls:

For the first run, a filter on the source IP is often more sensible than a too precise filter with the wrong destination IP. Once the relevant flow is visible, you can filter more narrowly in the second run. For NAT errors, you should also check whether you are currently viewing before or after the translation.

In the WebAdmin view, you see the active BPF string above the packet list after saving. The first screenshot shows the filter configuration, the second screenshot the result list with the active filter.

⚠️ PCAP data can contain IP addresses, hostnames, protocol details, and depending on the protocol, also payload data. Captures should only be shared with people or partners who are allowed to see this data.

Run Capture

Start and Reproduce Capture

1. Set filter.
2. Turn on Packet Capture via the slider.
3. Reproduce the problem specifically.
4. Stop the capture again.
5. Analyse the results.
6. Clear the capture when starting a new test.

Sophos Firewall shows the status and the buffer:

If the buffer is full, the capture stops automatically. You must then clear it with Clear before recording again sensibly. Therefore, a narrow filter is important.

In the filter settings, you can also specify how many bytes per packet are captured. For many initial analyses, header information is sufficient. If more payload data is needed, you must capture more bytes, but keep data protection and buffer size in mind.

Interpret Output

Understand Important Columns

Packet Capture shows many fields. These are particularly important in practice:

These fields are valuable because they bridge the gap between “rule looks correct” and “traffic actually flows this way.”

Through Show additional properties or the detail view, you can see additional information depending on the version, such as Connection ID, Web filter ID, Application ID, Web category ID, Gateway ID, Username, or other policy IDs. These details help when a packet is processed not only by a firewall rule but also by web, application control, IPS, or other modules.

Correctly Interpret Status

If you only see Incoming and no Forwarded, the packet likely gets stuck on the firewall. You should then check firewall rule, NAT, routing, and security features.

If Forwarded is visible but no response comes back, the problem often lies with the target system, return path, NAT, or a counterpart.

In a successful ping, you typically see packets in both directions. If Windows sends four pings, you see several ICMP Echo Requests from the client to the target and several Echo Replies back. If the replies are missing, check return route, target system, local firewall of the target system, NAT, or a counterpart. If the requests are already missing, check client, gateway, VLAN, switch port, or whether the traffic reaches the Sophos Firewall at all.

Correctly Read Consumed and Generated

Consumed and Generated are easily misinterpreted. These statuses do not automatically mean that a normal firewall rule is missing.

Examples of Consumed are accesses to WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP, IPsec, or SSL VPN of the firewall itself. Such traffic is not treated like normal transit traffic through a LAN-to-WAN or WAN-to-DMZ rule. If a packet shows Consumed in the capture, you should first clarify whether the client really intended to reach the firewall itself.

For these cases, Administration > Device access and Local Service ACL are more important than a normal firewall rule. Hardening these accesses is described in Secure Sophos Firewall Access: Configure Device Access Correctly.

Use Display Filter

The capture filter limits which packets are recorded. The Display filter filters only the already recorded view. This is useful if you intentionally started the capture a bit broader and then only want to display certain packets.

In the display filter, you can filter by fields such as:

• Interface name
• Ethernet type, such as IPv4, IPv6, or ARP
• Packet type
• Source IP and Source port
• Destination IP and Destination port
• Reason
• Status
• Rule ID
• User
• Connection ID

For troubleshooting, Status, Reason, Rule ID, Source IP, Destination IP, and Destination port are particularly helpful. If there are many packets in the capture, you can quickly reduce to the relevant part without having to restart the test immediately.

Read NAT in Packet Capture

With NAT, you must note that a packet looks different before and after NAT. Packet Capture can make NAT ID, Rule ID, and the changed addresses visible.

For NAT problems, you should check:

• Do you see the packet with the original address?
• Do you see the packet after translation?
• Is the expected NAT ID displayed?
• Does the packet go over the expected out interface?
• Does a response come back?

For DNAT, additionally: The firewall rule uses the target zone after NAT, but the target IP before NAT. This initially looks unusual.

More on this: Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Combine Packet Capture and Log Viewer

The best procedure is:

1. Open Log Viewer.
2. Start Packet Capture with a narrow filter.
3. Reproduce the test.
4. Check in Packet Capture whether packets arrive and proceed.
5. Check in Log Viewer which rule or module decided.
6. Switch to the appropriate log file if necessary.

The Log Viewer shows, for example, firewall, web, SSL/TLS inspection, IPS, or application control events. Packet Capture, on the other hand, shows the packet flow at the interface level.

Especially with ping or simple TCP connections, the combination is important. The Log Viewer can only show that a connection was allowed or blocked. Packet Capture additionally shows whether the response packets return, whether NAT applies, whether the correct out interface is used, and whether the return path is correct.

Typical Analysis Cases

Client cannot reach the internet: Set capture on source IP and TCP 443. If no packet arrives, check client, VLAN, gateway, or switch. If the packet arrives but does not exit, check firewall rule, NAT, or routing.

DNAT does not work: Set capture on public target IP and external port. If no packet arrives, check provider router, port forwarding, cloud security group, or WAN. If the packet arrives but does not go to the internal server, check DNAT rule and firewall rule.

VPN traffic does not flow: Set capture on tunnel interface, XFRM interface, or relevant source/target networks. Also check strongswan.log, charon.log, or xfrmi.log.

Web filter blocks unexpectedly: In Packet Capture, you usually only see the packet flow. The decision itself is better checked in the Log Viewer under web, application control, or SSL/TLS inspection.

Small tests work, large transfers hang: Set capture on the affected client and target and watch for retransmits, missing responses, or noticeable packet sizes. If ping, login, or small HTTP requests work, but larger downloads, RDP, VoIP, or VPN applications hang, you should also check MTU, MSS, PPPoE, VPN overhead, and fragmentation. The procedure is in Check MTU and MSS on Sophos Firewall for VPN Issues.

Typical Misinterpretations

Packet Capture shows a lot, but not always what you first expect. Some misinterpretations are particularly common in support cases.

If Packet Capture shows an unexpected Rule ID, you should not immediately change multiple rules. It is better to first compare with the Log Viewer and the rule position. For systematic matching, Check Causes for Sophos Firewall Rule Not Matching is suitable.

Limits, Data Protection and Sharing

Data Protection and Sharing of Captures

Packet capture data is operational data. Even if only headers are often visible, they can reveal internal IP addresses, public targets, usernames, hostnames, ports, protocols, and communication relationships. With unencrypted protocols, payload data can also be visible.

Before sharing, you should check:

• Does the capture contain customer names, internal hostnames, or public IP addresses?
• Are users, systems, or applications recognisable?
• Is the recipient authorised to see this information?
• Is a screenshot of the relevant lines sufficient, or is a PCAP file really needed?
• Does the capture need to be shortened or anonymised beforehand?

For support cases, a targeted tcpdump capture with a clean filter is often better than a broad WebAdmin capture. If log files are also needed, Secure Sophos Firewall Logs for Support and Analysis helps.

When tcpdump is Better

The WebAdmin Packet Capture is ideal for quick analyses directly in the browser. You quickly see whether packets arrive, are forwarded, consumed, generated, or dropped. For an initial narrowing down, this is usually the right start.

tcpdump is better when the capture is needed not just as a screen view but as an analysable file or as a longer technical trace.

The most important difference: tcpdump shows packets but no Sophos-specific decision. If you need to know which firewall rule, NAT rule, web policy, IPS policy, or SSL/TLS inspection rule was involved, you still need Log Viewer, WebAdmin Packet Capture, or the appropriate log file.

Before tcpdump, SSH or Advanced Shell should be consciously enabled. The capture should be narrowly filtered, time-limited, and removed after analysis. A broad PCAP on a productive firewall can quickly contain sensitive data and unnecessarily much background traffic.

More on this: Sophos Firewall tcpdump: Capture Packets via CLI.

Checklist

• Note test case with source, destination, port, protocol, and time.
• Know expected firewall rule and NAT rule, if possible.
• Set capture filter narrowly.
• For DNS, NAT, or CDN targets, check if the filter really captures both directions.
• Reproduce only one test case at a time.
• Stop Packet Capture after the test.
• Consciously distinguish Incoming, Forwarded, Consumed, Generated, and Violation.
• Compare Rule ID and NAT ID with Log Viewer.
• Check return path, NAT, target system, and counterpart if response is missing.
• Check MTU/MSS, fragmentation, and VPN overhead for hanging large transfers.
• Check captures for sensitive data before sharing.
• Use tcpdump for longer captures or PCAP files.

FAQ