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 SFOS 22, 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
• Source network: src net 10.10.10.0
• Destination network: dst net 10.10.10.0
• Port: port 443
• Source port: src 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.

Two further documented forms help with targeted variations:

• Multiple ports with OR: port 80 or port 443 captures packets with either port, for example for a short HTTP/HTTPS comparison. Without a host condition, the filter applies to all hosts, so keep the capture short.
• Exclude one port for a host: host 172.16.10.25 and port not 22 captures this host but omits packets with source or destination port 22. This can hide SSH management traffic, but still captures all other ports for this host.

The operators or, and, and port not are part of the syntax. IP addresses and port numbers are example values: replace the host IP with your own test host and the ports with the services actually being investigated. The existing web-test destination 93.184.216.34 is not a confirmed test endpoint either and must be replaced with the current destination IP. After a short test, check that the intended packets are visible and excluded ports are absent; the filter does not change firewall rules.

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.
• Buffer used shows current occupancy from 0 to 2048 KB, not the fixed total capacity. This shows how close the capture is to the buffer limit.
• The captured packet details can be refreshed. For an up-to-date view, refresh the packet details and read Buffer used; this is not the same as emptying the buffer with Clear.
• 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.

Time, Ethernet Type, and Packet Type help place individual rows in sequence and identify the protocol. The packet list also contains Connection ID, Connection status, Gateway ID, Username, and the IDs of applied Web, Application, IPS, Remote Access, and Bandwidth policies. For the selected packet, the detail view also shows headers and Hex and ASCII data.

For more precise correlation, read the additional metadata separately:

• Connection flags: System flags for the connection; do not confuse these with the packet’s Status field.
• User group: The user’s group membership, not their Username.
• Master connection ID: The primary connection ID associated with the current connection; Connection ID identifies the current connection itself.
• Application ID / Application category ID: The identifier of the application or its category, respectively.
• Application filter ID: The identifier of the application filter policy applied to the connection traffic, not the application identifier.
• Web category ID / Web filter ID: The web category or applied web filter policy, respectively. Category and policy IDs represent different associations.

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.

In SFOS 22, Log Viewer also provides Open PCAP when Packet Capture is on, allowing you to open packet information. A missing firewall log entry during an active test does not yet prove a capture problem: firewall sessions are normally logged only when the firewall receives the connection Destroy event. The packet list therefore remains the primary source for immediate path analysis.

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.

Under User, select a user from the list of existing users. In addition to the examples explained above, the Reason dropdown offers further documented values: DOS_ATTACK, INVALID_FRAGMENTED_TRAFFIC, ICMP_REDIRECT, SOURCE_ROUTED_PACKET, FRAGMENTED_TRAFFIC, MAC_FILTER, IPMAC_FILTER, NEIGHBOR_POISONING, and ICMP ERROR MESSAGE. Keep their spelling, including spaces, unchanged. Select the value matching the observed entry to narrow the display; the name alone does not replace checking the cause in the relevant Log Viewer module.

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. If the expected tunnel or XFRM interface is offered in the Display Filter, narrow the display to it. Otherwise, read In/Out interface directly from the packet rows.

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.1 MR1 Build 490, Known Issue NC-178387 can cause default drops with Firewall ID 0 to appear without a Violation Firewall row. According to the Known Issues entry, Sophos plans a fix in the next maintenance release; the entry names no specific confirmed fixed version or fixed build. The availability of MR2 alone therefore does not establish a fix. Until the fix is confirmed for the build in use, 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. Select the expected tunnel or XFRM interface in the Display Filter if it is offered there. Otherwise, inspect the In/Out interface values in the packet rows. 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.