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.

Run a complete restart only as a planned action

A full restart isn’t a diagnostic command. Preserve relevant logs, system time, uptime, HA roles, and the current failure state first. If only WebAdmin or a single service is affected, check whether a targeted WebAdmin restart or service restart is sufficient.

SFOS 22 documents the following Device Console syntax:

system restart [all]

The square brackets aren’t part of the command; they mark the optional all argument. Check the form offered by the installed build with system restart ? first. The command restarts the firewall and interrupts sessions, VPN tunnels, and management access. There is no CLI rollback after execution, so the maintenance window, console access, and a tested management return path must be in place before confirmation.

According to Sophos, system restart triggers a failover in an HA cluster. This doesn’t guarantee uninterrupted connections. The peer, synchronization, roles, and HA link must be stable first. After the restart, check both nodes, roles, synchronization, uptime, WAN, routing, DNS, VPN, published services, and a real application flow. A successful boot doesn’t prove that the original cause has been resolved.

Shut down only with a prepared power-on path

Use exactly this Device Console command for a controlled shutdown:

system shutdown

Sophos documents no options for it. Don’t append all, a node name, or an assumed HA switch to the syntax. Before confirmation, preserve logs and configuration, notify dependent teams, and establish how the appliance will be powered on again through physical access, remote management, or the virtualization platform. The shutdown page makes no HA behavior guarantee, so shut down a cluster node only through the intended HA maintenance procedure and explicitly check the peer afterwards.

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 with full access to system components. This article limits it to the diagnostic commands documented by Sophos: cd /log, tail, grep, less, and service -S.

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 Device Console groups global parameters for packet inspection, TCP, UDP, WAN access, and special paths under advanced-firewall. Their effects and a safe change procedure are covered in Check Advanced Firewall Settings safely.

The DNS test is a good example of why the console environment matters. In the Device Console, the officially documented command is:

dnslookup host example.com

example.com is a safe documentation value; replace it with the affected FQDN for a real test. The response only confirms resolution from the firewall’s perspective. For a client-side fault, also check the client’s DNS server, response, and network path.

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:

The documented default is Disable. With enable, all ports accept incoming connections, temporarily removing the normal Device Access reachability restriction. Authentication by the individual service remains a separate control, but doesn’t make this broad exposure harmless.

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. Sophos documents changing to this directory first in the Advanced Shell:

cd /log

Useful basic commands:

• Follow a log live: tail -f ips.log. Keep the continuous output open only during the recorded test window.
• Read a log file: less ips.log. This displays log lines in sections.
• Search for a term: grep error ips.log. Replace the term and file to match the fault.

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.

tcpdump and drop-packet-capture continue until you stop them with Ctrl+C. Define the filter and test window first, watch the output, and stop the capture immediately afterwards. The commands don’t change the configuration, but their load depends on traffic volume, filter breadth, and run time.

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.

Network checks in WebAdmin without CLI

The same basic questions can be tested without console access under Diagnostics > Tools. Ping lets you select IPv4 or IPv6, the outgoing interface, and the packet size. Sophos uses 32 bytes by default and allows values from 1 to 65,507 bytes. A successful ping confirms ICMP reachability from the selected firewall interface, but not that an application service works.

Traceroute also accepts IPv4, IPv6, or an FQDN and a deliberately selected outgoing interface. Missing replies from individual hops do not prove an interruption if later hops or the destination respond. For a path question, consider destination reachability, the last responding hop, and the packet flow measured in parallel.

Name lookup queries a selected DNS server. Lookup using all configured servers compares every DNS server configured on the firewall and its response time. A single fast result is not yet a reason to change DNS priority; the returned data, reliability, and affected client path must also be correct.

Route lookup shows the interface through which the firewall would route an IPv4 or IPv6 destination. It proves neither the firewall rule, NAT, the SD-WAN decision, nor a working return path. Complete acceptance testing with a real connection, Connection List, or Packet Capture.

Inspect connections without changing their state

Filter current IPv4 and IPv6 connections under Current activities > Live connections and Diagnostics > Connection list. Connection list shows the inbound and outbound interfaces, source and destination, Rule ID, NAT ID, translated addresses, status, and Rx/Tx counters, among other details. This is a better first step than an undocumented Advanced Shell tool.

The Device Console also documents this connection utility:

system diagnostics utilities connections

Check the available arguments before running it with system diagnostics utilities connections ?. Because Connection list is a snapshot, reproduce the test flow while refreshing the view. If the connection remains absent, run a narrow Packet Capture. If it appears, continue with the Rule ID, NAT ID, interfaces, translation, and response counters.

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

system diagnostics show version-info also returns the serial number and device ID. Redact these identifiers before sharing output or screenshots.

Additional read-only targets are interrupts, syslog, sysmsg, subsystem-info, and ctr-log-lines. They answer different questions and shouldn’t be treated as interchangeable health values:

system diagnostics show interrupts
system diagnostics show syslog
system diagnostics show sysmsg
system diagnostics show subsystem-info
system diagnostics show ctr-log-lines

On XGS Appliances, system diagnostics selftest is also available for basic network interface card tests. The command doesn’t apply to other platforms and doesn’t replace a cable test, throughput measurement, or packet capture. Because Sophos doesn’t state the impact on production traffic on the command page, run the self-test only as a planned action or when instructed by support, and compare it with link status, interface counters, and real traffic.

Under system diagnostics utilities, SFOS groups additional tools for ARP, bandwidth, connections, DNS, drop capture, network configuration, ping, processes, routes, and traceroute, including IPv6 variants where Sophos provides them. Check the exact syntax on the installed build with tab completion. Some tools only read state, while others generate test traffic or start continuous output.

For an additional read-only service check, Sophos documents these commands in the Advanced Shell:

service -S
service -S | grep ips

The first form shows many service states; the second uses the IPS example documented by Sophos. No match is not an instruction to restart anything: first correlate the service name and log file with the current Sophos log reference.

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.

Collect debug logs only with a confirmed exit path

SFOS 22 enables debug mode in the Device Console, not in WebAdmin. For a controlled test with Sophos’s documented Pktcapd example, record available disk space and the test time, then run:

system diagnostics subsystems Pktcapd debug on

Reproduce the issue once, then download the log file or a Consolidated Troubleshooting Report (CTR) under Diagnostics > Tools > Troubleshooting logs. Debug increases log-file size and remains active until you turn it off. Run the documented rollback immediately after the download:

system diagnostics subsystems Pktcapd debug off

Record both commands and their CLI output. If either command is rejected, don’t improvise with a subsystem or service command: check the syntax with ? and contact Sophos Support. Advanced Shell debug is deliberately omitted because the generic service syntax doesn’t provide a universal off command for every debug mode.

For service restarts and their effects, see How to restart Sophos Firewall services. Restarting VPN, IPS, web, or authentication services can interrupt active sessions or 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.

Rather than putting credentials in shell commands, download individual logs or a CTR under Diagnostics > Tools > Troubleshooting logs and provide it through the agreed 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, ping, traceroute, drop-packet-capture, or tcpdump was used deliberately in the Device Console.
• Debug was enabled only briefly under Diagnostics > Tools > Troubleshooting logs, then turned off and the normal state was verified.
• 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