Sophos Firewall CLI troubleshooting: essential commands

For initial Sophos Firewall troubleshooting, the Log Viewer is often enough. The CLI becomes important when a service does not start correctly, VPN connections are unstable, individual packets do not arrive, or support needs more detailed data.

This overview covers the most useful day-to-day commands: where to run them, what they show, and when to move to a specialized article. Before using SSH, review How to connect to Sophos Firewall with SSH. A public key, host-key verification, and tightly restricted Device Access are more important than being able to sign in quickly from anywhere.

⚠️ Important: Only run CLI and Advanced Shell commands from trusted admin networks and with a clear objective. Debug logging, tcpdump, file operations, and service commands can affect disk space, performance, or active connections.

Start with WebAdmin, then use the CLI

The CLI is not always the fastest place to begin. For rule matching, NAT, or individual connections, Log Viewer, Policy Test, and Packet Capture in WebAdmin often provide a clear result more quickly.

Useful starting points:

• Which firewall rule matches? Start with Log Viewer, Policy Test, and Packet Capture. Use the CLI only when Log Viewer does not provide enough detail or live logs are required.
• Do packets reach the firewall? Start with Packet Capture in WebAdmin. The CLI is useful when support needs a narrowly filtered capture or a PCAP file.
• Is a service having problems? Check the dashboard, Log Viewer, and service logs first. Use the CLI when you need to inspect service status, debug output, or log files directly.
• Was something changed? Check the Audit Trail logs first. The CLI can then help correlate a configuration difference with logs or backups.

The objective is not to enter the Advanced Shell as quickly as possible. Use a traceable workflow: inspect visible events first, then open the relevant log file or run the appropriate capture.

Document CLI findings so they remain useful

CLI output is only useful if it can later be tied to a specific test. A copied error message without a time window, IP addresses, or the affected function usually creates follow-up questions and duplicate analysis.

A short note for each test is normally enough:

• Time window: Start, end, and time zone of the test.
• Test flow: Source IP, destination IP or FQDN, port, user, or VPN peer.
• Tool: Device Console, Advanced Shell, Log Viewer, or Packet Capture.
• Command or filter: The command, grep search term, or capture filter used.
• Result: Match, error message, missing log entry, packet visible, or packet not visible.
• Next conclusion: For example, a rule issue, DNS issue, return-path issue, service fault, or support case.

Before sharing output with support, Avanet, or external partners, check it for sensitive data such as public IP addresses, internal hostnames, usernames, VPN parameters, serial numbers, tokens, email addresses, or customer identifiers. Technical analysis does not require distributing data broadly; share the smallest excerpt that proves the finding.

Before the first command

CLI troubleshooting is much more reliable when the context is defined before the first command. Otherwise, you quickly end up with log excerpts without timestamps, overly broad captures, or debug output that nobody can confidently associate with a test.

Before running CLI tests in production, record:

• Problem time: This makes it possible to search logs within the relevant window.
• Source IP, destination IP, and port: grep, tcpdump, and Packet Capture remain focused and readable.
• Affected user or peer: Authentication, VPN, and user matching can be correlated more reliably.
• Expected module: Start with the relevant log instead of searching every log file.
• Planned action: Debug, a service check, or a capture must not remain active accidentally.
• Rollback or stop condition: Stop the test if load, disk usage, or side effects become unacceptable.
• Current backup for change work: Service restarts and configuration changes are safer with a current recovery point.

The first step should be read-only whenever possible: inspect Log Viewer, open the relevant log file, read service -S, or start a narrowly filtered capture. Restarts, debug mode, and broad captures belong in a deliberate test window.

In an HA cluster, also determine which appliance is currently active. Logs, debug output, and captures must be checked on the node that actually processes the relevant traffic.

Device Console or Advanced Shell?

Sophos Firewall provides two distinct console environments. Many errors occur simply because a command is entered in the wrong one.

They serve different purposes:

• Device Console: Sophos CLI for network, system, and diagnostic commands. Typical commands include ping, dnslookup, traceroute, tcpdump, drop-packet-capture, and show.
• Advanced Shell: Linux-like shell for files, logs, processes, and service checks. Typical commands include nslookup, cd /log, tail -f, grep, less, df -kh, service -S, and conntrack.

After an SSH login, the firewall first displays the console menu. Select 4. Device Console for the Device Console. Open the Advanced Shell through 5. Device Management > 3. Advanced Shell.

The DNS test illustrates the difference particularly well. The commands aren’t interchangeable:

Device Console:

dnslookup host example.com

Advanced Shell:

nslookup example.com

This message is not a DNS test result. If /bin/sh: dnslookup: not found appears in the Advanced Shell, dnslookup is not available there. Use nslookup instead; its output then shows whether DNS resolution works.

The official Sophos CLI help supports Tab and ? for syntax checks. This is useful in the Device Console because command structures differ.

Do not guess incomplete commands in the Device Console. Sophos warns that an incomplete command can cause access_server to stop responding. Use Tab or ? to display the syntax before deliberately running the complete command.

Configuration changes made directly in the Advanced Shell are not persistent and are not included in backups. This guide therefore uses the Advanced Shell only for diagnostic commands.

system appliance_access enable is a special emergency command. It overrides Device Access and permits access to all local firewall services, including legacy services such as Telnet. Important: while this mode is active, the firewall stops forwarding outbound traffic to the internet. This is not a routine troubleshooting step and should only be used briefly in an emergency. Check the current state before enabling it:

system appliance_access show

After the test, disable emergency access and verify the state again:

system appliance_access disable
system appliance_access show

If a command is not recognized, check the console environment first. Using the wrong environment is more likely than the command itself being broken.

Inspect logs in the Advanced Shell

The main log files are stored under /log. Change to that directory and list its contents for an initial overview.

cd /log
ls -lah

Useful basic commands:

• Follow a log live: tail -f /log/strongswan.log. Useful for reproducible VPN failures.
• Read a log file: less /log/ips.log. Within less, search with /search-term.
• Search for errors: grep -i "error" /log/ips.log. -i ignores case.
• Show matches with line numbers: grep -n "192.0.2.10" /log/firewall_rule.log. Helpful with longer files.
• Show the latest lines: tail -n 100 /log/syslog.log. This provides a quick overview without live mode.

Sophos Firewall troubleshooting: services and logs maps modules to their relevant log files.

Keep live-log tests short and record the time. This is especially important when a log archive will later be provided to Sophos Support or Avanet.

Use the Device Console for quick network checks

The Device Console is suitable for quick tests from the firewall’s perspective. It can confirm whether DNS, routing, or basic reachability works.

Quick checks:

• Reach a host: ping 192.0.2.10 count 4 tests ICMP reachability.
• Check DNS in the Device Console: dnslookup host example.com tests name resolution from the firewall.
• Check the route: traceroute 192.0.2.10 shows the path to the destination.
• Inspect interface status: show interfaces displays interface information.
• Start a drop capture: drop-packet-capture 'host 192.0.2.10' shows packets dropped by firewall rules.
• Start a packet capture: tcpdump 'host 192.0.2.10 and port 443' checks whether packets are visible on the firewall.

The equivalent IPv6 commands are ping6, dnslookup6, and traceroute6.

drop-packet-capture is particularly useful when it is unclear whether the firewall is actively dropping packets. It does not replace application-level analysis. If a server responds but the application still fails, also check Log Viewer, NAT, Packet Capture, and the application logs.

For longer captures and PCAP files, use Sophos Firewall: collect logs with tcpdump for analysis. That article also explains how to limit file size, choose a storage location, and transfer the capture securely.

Inspect connections and packet flow in the Advanced Shell

If Log Viewer and the Device Console still do not provide a clear answer, a few Advanced Shell commands can help assess the packet flow.

Inspect connections

Before using Advanced Shell tools, filter the flow under Current activities > Live connections and Diagnostics > Connection list. These documented WebAdmin views show Rule ID, NAT ID, interfaces, user, gateway, and translated addresses without changing the session.

In the Device Console, system diagnostics utilities connections is an officially documented connection diagnostic. Use ? first to review the available options and output.

conntrack is a support-oriented Advanced Shell tool that displays active connections known to the stateful firewall path. Availability may depend on the firmware version.

conntrack -L | grep "192.0.2.10"

No match is only an indication: timing, filter direction, or FastPath can affect visibility. Correlate the result with Log Viewer and Packet Capture. If a connection exists but the application still fails, also verify that return packets arrive and that NAT, policy, and the application behave as expected.

tcpdump in the Advanced Shell

The Advanced Shell can also run tcpdump for quick live checks.

tcpdump -i any -nn host 192.0.2.10

Keep the filter as narrow as possible in production. Broad captures such as tcpdump -i any without a host, port, or packet count quickly generate large amounts of output and are impractical on busy firewalls.

A safe starting point is a short capture limited by host, port, and packet count:

tcpdump -i any -nn -c 50 host 192.0.2.10 and port 443

If more data is required, check disk space first and deliberately choose where to store the PCAP file.

Check disk space and system health

Before enabling debug logging, creating large log archives, or running longer captures, check available disk space.

The Device Console provides these read-only, officially documented system checks:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk
system diagnostics show uptime
system diagnostics show version-info

The following Advanced Shell tools provide additional information; availability may depend on the firmware version:

df -kh
df -h /var

Other quick checks:

uptime
top
service -S
service -S | grep strongswan

service -S displays the status of many services. Service names are not always self-explanatory, so correlate a service with its log file before restarting it or enabling debug.

If disk space is already low, do not enable debug logging or start a long capture. First determine which logs or reports can be backed up and cleaned up safely.

Enable debug logging deliberately

Debug logging can help with complex faults, but it should only be enabled briefly and for the affected service. Debug output grows quickly and can consume significant disk space.

For an explicit on/off workflow, use a supported subsystem in the Device Console. First run system diagnostics subsystems ? to display the available names. Sophos documents the following example for Pktcapd:

system diagnostics subsystems Pktcapd debug on
system diagnostics subsystems Pktcapd debug off

Sophos also documents this IPS debug command for the Advanced Shell:

service ips:debug -ds nosync

No separate Advanced Shell command with an appended off is documented for this variant. Only use it when Sophos Support has confirmed the exact rollback command for the installed build.

The image shows how, on SFOS 20.0.1, the same command toggles IPS debug mode and how service -S | grep ips confirms the state before and after the test. Do not assume that this toggle behaves identically on current versions without verification.

For service restarts and service identification, also see How to restart Sophos Firewall services. Record the exact debug interval for support cases.

Before restarting a service, determine which function it affects and whether production traffic currently depends on it. Restarting VPN, IPS, web, or authentication services can interrupt active sessions or user sign-ins.

Provide logs securely

Individual log excerpts are often insufficient for complex cases. A complete log archive is usually more useful for Sophos Support, Avanet, or an external analysis.

Do not place FTP credentials in shell commands. Transfer logs through a secure, traceable method, such as scp to your own server or a support portal. Follow How to collect Sophos Firewall logs for support and analysis.

Log files can contain sensitive information, including internal and public IP addresses, hostnames, usernames, VPN parameters, and error messages. Before sharing them, establish who will receive the data and how long it will be retained.

Common CLI troubleshooting mistakes

• Running a command in the wrong console environment: Device Console and Advanced Shell use different syntax. Check the environment first.
• Leaving debug enabled after the test: Logs grow unnecessarily and can consume disk space. Disable debug immediately after the analysis.
• Running a broad tcpdump without a filter: This creates excessive output, adds load, and makes the data harder to interpret. Limit the host, port, interface, or packet count.
• Putting FTP credentials in shell history: Credentials can appear in logs, screenshots, or command history. Use secure transfer methods and temporary credentials.
• Checking only one log file: Many faults involve several modules. Combine Log Viewer, the relevant service logs, and Packet Capture.
• Failing to record the time: Support then has to search unnecessarily large log windows. Record the time, test action, and involved IP addresses.
• Failing to clean up: Debug, temporary files, or broad access remain active. Disable debug, inspect temporary files, and remove temporary SSH access.

Checklist

• SSH access is restricted to trusted admin networks.
• The SSH fingerprint and admin access were verified before the analysis.
• The correct environment was selected: Device Console or Advanced Shell.
• Problem time, source IP, destination IP, port, and user were recorded.
• CLI findings include the time window, command, filter, and result.
• Read-only commands were used before enabling debug, restarting services, or starting longer captures.
• Log Viewer was checked first.
• The relevant file under /log was identified.
• tail, grep, or less was used with a focused search term.
• For network problems, dnslookup was used in the Device Console or nslookup in the Advanced Shell, together with ping, traceroute, drop-packet-capture, or tcpdump as needed.
• Debug was enabled only briefly and disabled with the documented off command for the selected subsystem.
• Disk space was checked before debug or PCAP collection.
• The log archive was transferred securely and temporary files were removed.
• Temporary Device Access or SSH exceptions were removed after the support case.

FAQ