Using Sophos Firewall Packet Capture in WebAdmin

Under Diagnostics > Packet capture, you can trace a single network flow directly in WebAdmin. Set a narrow BPF filter, start the capture, reproduce the problem once, and then check interfaces, Rule ID, NAT ID, Status, and Reason.

Packet Capture shows the actual packet flow. Use Log Viewer as well to check which policy made the decision. For longer captures or a .pcap file, use tcpdump over SSH, because the WebAdmin capture cannot be downloaded as a PCAP file.

If the connection is already established and the first task is only to find the active session with its user, interfaces, Rule ID, NAT ID, or gateway, start with Live Connections and Connection List. Packet Capture follows when the actual outbound and return path must be proved.

Packet Capture in six steps

1. Note the Source IP, destination, protocol, port, and test time. Example: client 172.16.10.25 to 93.184.216.34 over TCP 443.
2. Open Diagnostics > Packet capture and click Configure.
3. Set and save a BPF string, for example host 172.16.10.25 and port 443.
4. Set Packet Capture to Trace On. In current SFOS versions, the packet details appear in a new browser window.
5. Reproduce exactly one test, then stop the capture with Trace Off.
6. Read the sequence from bottom to top and check In/Out interface, Rule ID, NAT ID, Status, Reason, and reply packets.

If you change the BPF string while a capture is running, first set Packet Capture to Trace Off and then back to Trace On so that the new filter takes effect.

⚠️ A broad, continuous capture makes analysis difficult and collects unnecessary operational data. Keep the filter narrow, the test short, and turn off Packet Capture afterwards.

Set a targeted Capture Filter

The Capture Filter determines which packets enter the 2048 KB buffer before the capture. The Display Filter only narrows the data that has already been captured. Therefore, you do not select an interface in the Capture Filter; you select it later in the Display Filter.

For an HTTPS test, at least the source, destination, and port should be known. If the destination is still unclear because of DNS, a CDN, or NAT, start with only the Source IP and narrow down the visible flow afterwards.

Before starting, establish the following:

• Source IP and current Destination IP
• protocol and Source and Destination port, where relevant
• expected inbound and outbound interface or zones
• expected Firewall Rule and NAT Rule
• expected result, such as allowed, blocked, DNAT, SNAT, or VPN
• exact test time and one reproducible action

BPF examples

• Host: host 10.10.10.1
• Source IP: src host 10.10.10.1
• Destination IP: dst host 10.10.10.1
• Network: net 10.10.10.0/24
• Port: port 443
• Destination port: dst port 443
• Protocol: proto TCP, proto UDP, or proto ICMP

A narrow web test can look like this:

host 172.16.10.25 and host 93.184.216.34 and port 443

For a ping test, this is usually sufficient:

host 172.16.10.25 and proto ICMP

Sophos documents these basic BPF forms. This does not automatically guarantee that every arbitrary tcpdump expression works in WebAdmin.

With NAT, the direction of view matters: A filter on the internal client IP may hide the WAN-side entry after MASQ. If packets are missing, first filter only by source, destination, or port and check whether both directions remain visible.

Buffer and capture options

• Number of bytes to capture (per packet) defines how many bytes are stored per packet. Header data is often sufficient for an initial test.
• Without Wrap capture buffer once full, the capture stops automatically at 2048 KB. With Wrap enabled, the oldest data is overwritten.
• Clear empties the buffer before a new test.
• The capture continues if you navigate to another page in WebAdmin. Therefore, deliberately set it to Trace Off after the test.

Read the results correctly

A packet flow appears multiple times because the firewall captures ingress and egress at the interfaces. A ping round trip typically consists of four rows: the request enters on LAN, leaves on WAN, the reply enters on WAN, and leaves on LAN. The newest entries are at the top; read the list from bottom to top for the chronological sequence.

The most important fields

• In interface / Out interface: Where the packet arrives and which interface it leaves through.
• Source IP / Destination IP / Ports: Which flow is currently being examined.
• Rule ID: Which firewall rule processes the traffic.
• NAT ID: Which NAT rule is involved.
• Status: What the firewall does with this packet step.
• Reason: Why a packet is dropped.

The packet list contains additional fields when needed, such as Connection ID, Gateway ID, Username, and Web, Application, or IPS policy IDs. For the selected packet, the detail view also shows headers and Hex and ASCII data.

Interpret Status correctly

• Incoming: The packet was received on an interface; this does not yet prove a later decision.
• Forwarded: The firewall forwarded the packet through an outbound interface.
• Consumed: The packet is intended for the firewall itself, for example WebAdmin, VPN Portal, SSH, DNS, or a VPN service.
• Generated: The firewall generated the packet itself, for example as a response or through a system service.
• Violation: The firewall dropped the packet because of a policy violation.

For Consumed, Administration > Device access, a Local Service ACL, or the affected firewall service is often decisive. Secure Sophos Firewall Device Access explains the relevant configuration.

Check Rule ID, NAT ID, and Reason together

An unexpected Rule ID does not prove that a rule is defective. First check rule order, zones, and matching in Log Viewer. The complete procedure is described in Test a Sophos Firewall rule properly.

With NAT, the same flow can appear with different addresses before and after translation. The expected NAT ID, In/Out interface, and reply packets are decisive. Understand NAT on Sophos Firewall explains the translation logic.

If Reason shows, for example, LOCAL_ACL, IPS, APPLICATION_FILTER, USER_IDENTITY, or IP_SPOOF, check the corresponding module in Log Viewer. A detailed classification is available in Analyze dropped packets on Sophos Firewall.

To cross-check with Log Viewer:

1. Open Log Viewer and Packet Capture side by side.
2. Set the Capture Filter and reproduce exactly one test.
3. In Packet Capture, check interfaces, reply packets, Rule ID, and NAT ID.
4. In the appropriate Log Viewer module, check which rule or Security Policy made the decision.
5. Only then investigate the specific rule, NAT, routing, or affected security module.

Use the Display Filter

The Display Filter helps with a packet list that already contains data. It can filter by interface, IPv4/IPv6/ARP, Packet type, Source/Destination IP and port, Reason, Status, Rule ID, User, or Connection ID, among other fields. Allowed is also available there as a filter value for permitted packets; the packet rows themselves show processing steps such as Incoming or Forwarded.

For ARP or NDP issues, Check the ARP and NDP neighbor cache shows how to correlate the capture display with the local neighbor cache and static bindings.

Use Save to apply the filter and Clear to reset it. For VPN traffic, for example, set the Capture Filter to a host or network and then narrow the display to the expected XFRM or tunnel interface.

Quick troubleshooting

No packets visible: Check the Capture and Display Filters. For FQDNs and CDNs, verify the current destination IP; with NAT, initially filter only by the Source IP. If the list remains empty, check the client gateway, VLAN, switch port, and upstream devices.

Client cannot reach the internet: Filter by the client IP and, for example, TCP 443. If nothing arrives, the cause is before the firewall. If the request arrives but is not forwarded, check the firewall rule, NAT, and routing.

Only Incoming is visible: Look for Forwarded, Consumed, or Violation and ensure that the filter does not hide subsequent steps. In SFOS 22.0 MR1, Known Issue NC-178387 can cause default drops with Firewall ID 0 to appear without a Violation Firewall row. Cross-check with Policy tester or create an explicit logging drop rule at the end of the firewall rule list for the affected flow. Set the source and destination zones specifically; details are available in Analyze dropped packets on Sophos Firewall.

Forwarded, but no reply: Check the return route, NAT, target system, the target’s local firewall, and the remote side. Forwarded only proves that Sophos Firewall passed the packet on.

Unexpected Rule ID or NAT ID: Compare the IDs with Log Viewer and rule position. Do not change multiple rules at once; Sophos Firewall rule does not match helps with matching problems.

DNAT does not work: Check whether the request arrives on WAN, which NAT ID processes it, and whether it is forwarded to the internal server. If nothing appears on WAN, the cause is often before the firewall. Publish a server with DNAT shows the complete setup.

VPN traffic is missing: Capture by host, network, or protocol and select the expected tunnel or XFRM interface in the Display Filter. For further analysis, see Sophos Firewall IPsec troubleshooting.

Web filter blocks unexpectedly: Packet Capture shows the packet flow, but not the complete Web, Application Control, or SSL/TLS decision. Cross-check it in the appropriate Log Viewer module.

Small tests work, but large transfers stall: In WebAdmin, look for missing replies and packet sizes. Retransmissions can be analyzed reliably using a PCAP file in Wireshark. Also check MTU and MSS.

Packet Capture does not start: First clear the buffer and check the new browser window. If the problem persists, restart the Packet capture and Live connections service under System services > Services. The restart also temporarily interrupts the Live Connections display.

Privacy and switching to tcpdump

Capture data can contain internal IP addresses, hostnames, usernames, communication relationships, and, with unencrypted protocols, payload data. Before sharing it, check the recipient, scope, and retention; a few relevant rows are often sufficient instead of the entire capture.

For longer captures, a specific interface, a fixed packet count, Snap Length, or a .pcap file, use tcpdump on Sophos Firewall. Transfer the file securely and remove it from the firewall afterwards.