Use Sophos Firewall tcpdump Safely

tcpdump is the right tool when you need to see more precisely on the Sophos Firewall which packets are actually arriving, which interface they are running through, and whether a problem arises before, on, or behind the firewall. It complements Log Viewer, WebAdmin Packet Capture, and service logs, but does not replace them.

For quick browser analyses, using Sophos Firewall Packet Capture in WebAdmin is often more convenient. For longer captures, very precise filters, PCAP files, or support cases, tcpdump via SSH is usually more suitable.

⚠️ Important: Packet captures can contain sensitive data: internal IP addresses, hostnames, usernames, DNS queries, certificate details, or unencrypted payload. Therefore, they should be tightly filtered, recorded only as long as necessary, documented, and shared only through secure channels. An unfiltered capture on any can generate a lot of data on productive firewalls.

Tool Selection and Prerequisites

Which Article Fits?

tcpdump is not the first step for every analysis. Depending on the question, a different starting point is faster:

• Quickly see in WebAdmin whether packets arrive, are forwarded, or dropped: Use Sophos Firewall Packet Capture in WebAdmin.
• Validate a firewall rule with Log Viewer, Policy Tester, and Packet Capture: Test Sophos Firewall rules cleanly.
• Focus on Drop, Violation, Rule ID, NAT ID, or drop reasons: Analyse dropped packets on Sophos Firewall.
• Find the right local log file for VPN, web, IPS, GUI, or system services: Map Sophos Firewall service logs correctly.
• Prepare SSH or Advanced Shell: Connect Sophos Firewall via SSH.
• Prepare support case with /log archive, IPsec data, or debug logs: Secure Sophos Firewall logs for support and analysis.
• PCAP file, long capture, or very precise CLI filters needed: This article.

This separation saves time and reduces risk. tcpdump provides strong packet data but no Sophos-specific policy decision. Rule ID, NAT ID, drop reason, Web Policy, IPS, or SSL/TLS inspection must be checked in parallel in the Log Viewer, WebAdmin Packet Capture, or the appropriate log files.

Prerequisites

For this guide, you need:

• Administrative access to the Sophos Firewall.
• SSH access to the firewall or access to the Advanced Shell.
• The source IP, destination IP, destination port, and the affected protocol.
• Sufficient free storage space if a PCAP file is to be written.
• Wireshark or another analysis tool on the admin client if a PCAP file is to be evaluated.

How to securely prepare SSH is detailed in Connecting to Sophos Firewall via SSH. For general CLI basics, Sophos Firewall CLI Troubleshooting: Important Commands is also suitable.

When tcpdump is the Right Next Step

tcpdump should not automatically be the first step. If you just want to know which firewall rule, NAT rule, Web Policy, or SSL/TLS inspection rule decided, the Log Viewer is faster and more readable. If you want to see in the browser whether individual packets are arriving, being forwarded, or dropped, often Packet Capture in WebAdmin is sufficient.

tcpdump becomes particularly useful when one of these points applies:

• The capture is to be evaluated as a PCAP file in Wireshark or by support.
• The WebAdmin capture is too short, too confusing, or the buffer is full.
• The test needs to run longer during a maintenance window, a phone call, or a reproducible user error.
• Precise CLI filters are needed, for example, for VoIP, DNS, IPsec, multiple hosts, or port ranges.
• The relevant traffic should first be compared on any and then on a specific interface.

The expectation is important: tcpdump shows packets but no Sophos-specific Rule ID, NAT ID, Drop Reason, or Web Policy decision. These details must be checked in parallel via Log Viewer, WebAdmin Packet Capture, or appropriate log files.

Advanced Shell or Device Console?

tcpdump can appear in two CLI contexts on Sophos Firewall. The Sophos Device Console includes its own tcpdump command with Sophos syntax and options such as filedump. The Advanced Shell additionally provides the familiar Linux-like tcpdump, which is often more practical for support cases because process handling, scp, /tmp, and other shell tools are available.

This distinction is important:

• Device Console: Suitable for the Sophos CLI command tcpdump. Before running it, check the syntax with Tab or ?. According to Sophos, output created with filedump is stored under /tmp.
• Advanced Shell: Suitable for classic shell workflows with tcpdump, ps, df, grep, scp, file access, and deliberately stopping running processes.

This article deliberately uses the Advanced Shell because PCAP files, background processes, scp, and cleanup fit together more transparently there. If tcpdump is used in the Device Console, the same basic rules apply: narrow filters, short capture window, check free space, and compare the result with Log Viewer or WebAdmin Packet Capture.

If it is unclear which console you are in, the overview Sophos Firewall Troubleshooting: Services and Logs can help.

Prepare Capture

Narrow Down Before Starting

Before a capture, you should note the analysis parameters:

• Source IP: for example 172.16.10.25.
• Destination IP: for example 198.51.100.20.
• Protocol: for example TCP.
• Destination port: for example 443.
• Expected interface: LAN, WAN, or VPN interface.
• Test time: exact time with timezone.
• Expected result: connection allowed, blocked, DNAT, SNAT, VPN, or drop.
• Parallel check: Log Viewer, Packet Capture, service log, or support ticket.

The tighter the filter, the better the result. A capture without a filter is usually only useful on very quiet firewalls.

The test should be reproducible. If multiple people change settings simultaneously or multiple clients test, the capture becomes difficult to interpret. It is better to have a single test client, a tight time frame, and a clear question: Does the packet arrive? Does it go out? Does the response come back? Which rule, NAT rule, or policy was visible in parallel?

For rule tests, Testing Sophos Firewall Rules with Log Viewer and Packet Capture is also suitable. If it is mainly about Drop, Violation, Rule ID, or NAT ID, Analyzing Dropped Packets on Sophos Firewall is the better follow-up article.

Run tcpdump

Execute tcpdump Live

For an initial live check, a host filter is often sufficient:

tcpdump -i any -nn host 198.51.100.20

The parameters:

• -i any: capture on all interfaces.
• -nn: do not perform DNS or port name resolution.
• host 198.51.100.20: only show packets from or to this IP.

For a web test, an additional port filter is useful:

tcpdump -i any -nn 'host 198.51.100.20 and port 443'

Filter expressions with and, or, or not should be enclosed in single quotes. This keeps the expression intact and prevents it from being split by the shell.

Common Filter Examples

• Specific host: tcpdump -i any -nn 'host 198.51.100.20'
• Specific source IP: tcpdump -i any -nn 'src host 172.16.10.25'
• Specific destination IP: tcpdump -i any -nn 'dst host 198.51.100.20'
• Specific network: tcpdump -i any -nn 'net 172.16.10.0/24'
• Specific port: tcpdump -i any -nn 'port 443'
• Host and port: tcpdump -i any -nn 'host 198.51.100.20 and port 443'
• ICMP / Ping: tcpdump -i any -nn 'proto ICMP'
• DNS: tcpdump -i any -nn 'port 53'
• All ports except SSH: tcpdump -i any -nn 'host 198.51.100.20 and port not 22'

For VPN, VLAN, or routing issues, it may be useful to narrow down not on any but on a specific interface. The interface names must match the respective firewall. In practice, this sequence is often useful:

1. Briefly check on any whether the expected host or port is visible at all.
2. Then capture on the suspected incoming interface.
3. Then capture on the suspected outgoing interface.
4. Compare the three observations with Log Viewer, NAT ID, Rule ID, or Drop Reason.

This shows faster whether traffic does not reach the firewall, is stopped on the firewall, or the reply is missing on the return path.

Limit Capture

A capture should be limited so that it does not run unnecessarily long.

With -c, tcpdump stops after a fixed number of packets:

tcpdump -i any -nn -c 100 'host 198.51.100.20 and port 443'

For short tests, this is often cleaner than a background process. You start the capture, reproduce the problem, and then automatically receive the output.

Write PCAP File

If the capture is to be analyzed later in Wireshark or by support, write a PCAP file to /tmp.

tcpdump -i any -nn -s 0 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Important parameters:

• -s 0: capture full packets.
• -w /tmp/sophos-capture.pcap: write output to a PCAP file.
• -nn: disable name resolution.

-s 0 is helpful when a full capture is needed. At the same time, this increases the data protection risk because more packet content is captured. For pure flow or header questions, a live capture without a PCAP file or a short capture with tight filtering is often sufficient.

Before larger captures, check the free storage space:

df -h /tmp
df -h /var

If the problem only needs to be reproduced briefly, -c can also be added here:

tcpdump -i any -nn -s 0 -c 500 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

After starting, you should immediately reproduce the test and not let the capture run unnecessarily. A PCAP that contains five minutes too much is not only larger but often also contains more sensitive side information.

For support cases, the filename should contain neutral context but no customer names, usernames, or confidential hostnames. Better names are /tmp/ticket-12345-wan-443.pcap or /tmp/vpn-test-20260629.pcap.

Start and Stop Background Process

Sometimes a capture needs to run while another test is being performed. Then tcpdump can be started in the background.

tcpdump -i any -nn -s 0 -w /tmp/voip-test.pcap 'host 192.0.2.50 and portrange 5060-5090' &

Show running jobs:

jobs

End job:

kill %1

If multiple tcpdump processes are running or the job is no longer visible in the current shell, first check processes:

ps | grep tcpdump

Then specifically terminate the appropriate process. killall tcpdump should only be used if it is clear that no other important captures are running.

After stopping, check if the PCAP file was written and has a plausible size:

ls -lh /tmp/*.pcap

If a background capture is planned for a support appointment, define beforehand who starts it, who stops it, and where the file goes afterwards. A forgotten capture is not a rare troubleshooting issue, but an avoidable operational risk.

Example: Analyzing VoIP or 3CX

In VoIP issues, SIP signaling and RTP media stream often need to be considered separately. A single capture on port 5060 only shows part of the problem.

For an initial 3CX test, you can capture the PBX host:

tcpdump -i any -nn -s 0 -w /tmp/3cx-test.pcap 'host 192.0.2.50'

If the traffic is too broad, you can narrow it down more specifically to SIP:

tcpdump -i any -nn -s 0 -w /tmp/3cx-sip.pcap 'host 192.0.2.50 and portrange 5060-5090'

For audio issues, the actually used RTP port range must also be checked. This depends on the telephone system and its configuration.

For Sophos Firewall VoIP topics, additionally check Optimizing Sophos Firewall VoIP Settings.

Evaluation and Cleanup

Download and Clean Up PCAP File

A PCAP file can be copied to an internal server via scp:

scp /tmp/sophos-capture.pcap adminuser@192.0.2.10:/tmp/

Depending on the environment, another secure transfer method may be used. FTP with fixed credentials should be avoided.

After successful transfer, the file should be removed from the firewall:

rm /tmp/sophos-capture.pcap

For complete log archives and support cases, Securing Sophos Firewall Logs for Support and Analysis is the more suitable guide.

Context for Support or External Analysis

A PCAP file without context is hard to evaluate. For Sophos Support, Avanet, or an external analysis partner, provide at least these details:

• Time window: for example 2026-06-29, 14:05-14:08 Europe/Zurich.
• Expected flow: for example client 172.16.10.25 to server 198.51.100.20:443.
• Affected function: DNAT, IPsec, SSL VPN, web filter, VoIP, DNS, or routing.
• Observation: for example SYN visible, no SYN-ACK, drop in Log Viewer, or no reply from target.
• Checked in parallel: Rule ID, NAT ID, Packet Capture, and relevant service logs.
• Change before the error: firmware, rule change, provider change, certificate, or SD-WAN route.

Before handing over the file, check whether it contains internal names, private addresses, public customer IP addresses, or unencrypted content. If the content cannot be anonymised, recipients, transfer path, and retention must be decided deliberately.

Properly Evaluate tcpdump

When evaluating, it’s not just about whether packets are visible. What is missing is crucial.

• No packets visible from the client: Problem lies before the firewall. Check client, VLAN, gateway, switch, or routing to the firewall.
• Packets come in but do not go out: Check firewall rule, NAT, routing, security feature, or policy.
• Packets go out, but no response comes back: Check target system, return route, peer firewall, NAT, or provider.
• Only SYN, no SYN-ACK: Target or return path does not respond.
• ICMP request visible, reply missing: Check return route, target firewall, or peer.
• DNS query visible, no response: Check DNS server, route, rule, or upstream.
• Packet visible only on any, but not on expected interface: Check interface assumption, zone, route, or tunnel assignment.
• Packet visible on incoming interface, but not on outgoing interface: Check rule, NAT, route, security feature, or drop reason.

tcpdump shows the packet flow. The policy decision itself is checked in parallel in the Log Viewer. For firewall and NAT questions, the combination of Log Viewer, Packet Capture, and tcpdump is often the fastest.

For NAT errors, it should also be understood that NAT only translates the traffic but does not allow it. The appropriate foundation is Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT. For IPsec tunnels, Sophos Firewall IPsec VPN Troubleshooting and the appropriate VPN logs are helpful.

Common Mistakes and Checklist

Common Mistakes

• Capture without filter: Too much data, hard to evaluate. Always narrow down with host, network, port, or protocol.
• Capture not stopped: Storage space and performance may suffer. Use -c or properly end the background process.
• Only any evaluated: Interface or tunnel problem remains hidden. After the first hit, compare incoming and outgoing interface deliberately.
• Only one direction checked: Return path problem overlooked. Consider both directions.
• Wrong interface chosen: Relevant packets missing. First use any, then narrow down to interface.
• PCAP shared unencrypted: Sensitive data may be exposed. Use secure transfer and a minimal recipient group.
• File left after support case: Unnecessary storage consumption and data risk. Delete PCAP after transfer.

Checklist

• Source IP, destination IP, port, and protocol known.
• SSH access to the firewall securely set up.
• Decided beforehand whether Log Viewer or WebAdmin Packet Capture would suffice.
• Filters chosen as tightly as possible.
• Capture limited with -c or clear stop process.
• PCAP file written only if needed.
• For interface questions, compared any first, then incoming and outgoing interface.
• Problem specifically reproduced during capture.
• Test time documented.
• Log Viewer checked in parallel.
• Rule ID, NAT ID, Drop Reason, or service log noted where visible.
• PCAP securely transferred.
• Temporary PCAP file removed from the firewall.

FAQ