Use Sophos Firewall Packet Capture in WebAdmin

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

Log Viewer shows the firewall decision. Packet Capture shows the packet flow. Together, they are often the fastest way to find the cause.

Important context: This article describes the WebAdmin version of Packet Capture. It is ideal for a first check because one 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, tcpdump over SSH is often the better option.

When Packet Capture is useful

Packet Capture is especially helpful for questions such as:

• Does the traffic reach the firewall at all?
• Does the traffic leave again on the expected interface?
• Does a Firewall Rule match?
• Does a NAT Rule match?
• Is a packet dropped by policy, IPS or routing?
• Does a reply come back from the destination system?
• Is another port or protocol being used than expected?

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

Menu path

The tool is available under:

Diagnostics > Packet capture

Packet Capture opens directly in WebAdmin. Depending on the SFOS version and browser view, it looks like a separate diagnostics window inside WebAdmin.

Log Viewer or Packet Capture?

Log Viewer and Packet Capture answer different questions.

A good example is a ping. In Log Viewer, one often sees only one entry or a summarised decision for the connection. In Packet Capture, one sees the individual ICMP packets: Echo Request to the destination and Echo Reply back. Windows sends four ICMP Echo Requests by default with ping. In Packet Capture, one therefore expects several outbound and return packets. If only the requests are visible but no replies come back, that is a different problem than if no request reaches the firewall at all.

In practice, this means:

• Log Viewer answers: Which rule or module made the decision?
• Packet Capture answers: Did the packets really arrive and which path do they take?
• For routing, NAT, VLAN, gateway or return-path problems, Packet Capture is often more meaningful.
• For Web filter, Application Control, IPS or SSL/TLS inspection decisions, Log Viewer is also needed.

Narrow the scope before starting

Packet Capture should not be started without a filter. In production networks, this quickly creates a lot of data and makes the output hard to read.

Beforehand, note:

• Source IP
• Destination IP or FQDN
• Protocol
• Source port, if relevant
• Destination port
• Interface or zone
• Time of the test
• Affected application

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

Configure capture filter

Use Configure to set the narrowest possible filter.

Typical filters:

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

If the destination server is unknown, start by filtering only for the Source IP. If too many packets appear, narrow it down further.

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

Typical BPF examples:

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

host 172.16.10.25 and host 93.184.216.34 and port 443

For a ping test, this is often enough:

host 172.16.10.25 and proto ICMP

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

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

Start the capture and reproduce the issue

1. Set the filter.
2. Turn on Packet Capture using the toggle.
3. Reproduce the issue deliberately.
4. Stop the capture again.
5. Analyse the results.
6. Clear the capture before starting a new test.

Sophos Firewall shows the status and buffer:

When the buffer is full, capturing stops automatically. One must then use Clear before another meaningful capture can be recorded. This is why a tight filter is important.

In the filter settings, one can also specify how many bytes per packet are captured. Header information is enough for many first analyses. If more payload data is required, more bytes must be captured, but privacy and buffer size should be kept in mind.

Understand the important columns

Packet Capture shows many fields. In practice, these are particularly important:

These fields are valuable because they close the gap between “the rule looks correct” and “the traffic really flows like this”.

With Show additional properties or the detail view, additional information may be visible 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.

Interpret status correctly

If only Incoming is visible and no Forwarded, the packet is probably stuck on the firewall. Then check Firewall Rule, NAT, routing and security features.

If Forwarded is visible but no reply returns, the issue is often on the destination system, return path, NAT or a remote peer.

With a successful ping, packets are typically visible in both directions. If Windows sends four pings, one sees several ICMP Echo Requests from the client to the destination and several Echo Replies back. If the replies are missing, check return route, destination system, local firewall on the destination, NAT or a remote peer. If even the requests are missing, check client, gateway, VLAN, switch port or whether the traffic reaches Sophos Firewall at all.

Use Display filter

The capture filter limits which packets are recorded. The Display filter, on the other hand, filters the already recorded view. This is useful when the capture was intentionally started a little broader and only certain packets should be shown afterwards.

In Display filter, one can filter by fields such as:

• Interface name
• Ethernet type, for example 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 especially helpful. If many packets are in the capture, these fields quickly reduce the view to the relevant part without having to restart the test immediately.

Read NAT in Packet Capture

With NAT, keep in mind that a packet looks different before and after NAT. Packet Capture can show NAT ID, Rule ID and the changed addresses.

For NAT issues, check:

• Is the packet visible with the original address?
• Is the packet visible after translation?
• Is the expected NAT ID shown?
• Does the packet leave through the expected Out interface?
• Does a reply come back?

For DNAT, there is an additional point: the Firewall Rule uses the destination zone after NAT, but the destination IP before NAT. This looks unusual at first.

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

Combine Packet Capture and Log Viewer

The best workflow is:

1. Open Log Viewer.
2. Start Packet Capture with a tight filter.
3. Reproduce the test.
4. In Packet Capture, check whether packets arrive and leave.
5. In Log Viewer, check which rule or module made the decision.
6. If needed, switch to the matching log file.

Log Viewer shows events such as Firewall, Web, SSL/TLS inspection, IPS or Application Control. Packet Capture shows the packet flow on the interface level.

This combination is especially important for ping or simple TCP connections. Log Viewer can only show that a connection was allowed or blocked. Packet Capture additionally shows whether reply packets return, whether NAT applies, whether the correct Out interface is used and whether the return path works.

Common examples

Client cannot reach the internet: Set a capture for Source IP and TCP 443. If no packet arrives, check client, VLAN, gateway or switch. If the packet arrives but does not leave, check Firewall Rule, NAT or routing.

DNAT does not work: Set a capture for the public destination 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 the DNAT rule and Firewall Rule.

VPN traffic does not work: Set a capture for the tunnel interface, XFRM interface or relevant source and destination networks. Also check strongswan.log, charon.log or xfrmi.log.

Web filter blocks unexpectedly: In Packet Capture, one usually sees only the packet flow. The actual decision is better checked in Log Viewer under Web, Application Control or SSL/TLS inspection.

When tcpdump is better

WebAdmin Packet Capture is ideal for quick analyses. For longer captures, very precise filters or support cases, CLI-based tcpdump is often better.

More on this: Collect Sophos Firewall logs with TCPDump for analysis.