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.

Before emergency access: Obtain explicit approval for the purpose, responsible person, affected appliance, and a short emergency window with an end time and stop condition; plan for the interruption of internet forwarding. First actually open an independent recovery path and verify admin access, for example through a local console, the virtualization platform console, or out-of-band management. This access must not depend on the faulty network path or emergency mode and must remain available for disabling the mode. Do not enable without approval or a working independent recovery path; first coordinate recovery with the responsible person or Sophos Support.

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

As soon as the intended full admin access has been restored, immediately disable emergency mode in 4. Device Console and check the state again; do not wait for further diagnostics to finish. Also disable through the prepared independent recovery path if the procedure is aborted or the approved end time is reached:

system appliance_access disable
system appliance_access show

Afterwards, show must confirm Disable. Also test a new WebAdmin or SSH login from the intended admin network under the normal Device Access rules, and confirm that previously blocked access remains blocked. From an affected client behind the firewall, test a real outbound internet connection, for example an HTTPS request to an approved destination, and verify a successful response; a firewall ping or show alone does not prove that forwarding has been restored. If checks fail or the state is unclear, do not close the case as resolved: keep the independent recovery path open, preserve the CLI response and test findings, and coordinate with the responsible person or Sophos Support rather than re-enabling broad emergency access as a permanent workaround.

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.

For Ping in SFOS 22 and SFOS 23, IP address or hostname can contain an IPv4 address, an IPv6 address, or an FQDN. IP family sets the address family, Interface the outgoing interface, and Size the packet size. An FQDN also requires name resolution; to narrow down a DNS issue, compare the same test using the expected IP address.

The Ping output shows whether replies arrive, how many packets were sent and received, packet loss, and the Round-Trip Time (RTT). RTT is the time for the request and reply, not one-way latency. If no replies arrive, 100 percent packet loss is displayed. This alone does not prove that the host is switched off: check the destination address, selected interface, routing, and whether ICMP is permitted, and use a narrowly filtered Packet Capture if needed. A successful test must still match the actual application flow.

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.

In WebAdmin under Diagnostics > Tools > Traceroute, set the destination in IP address or hostname, the address family in IP version, and the outgoing interface in Interface; start the query with Traceroute. For SFOS 22 and SFOS 23, Sophos describes the output as showing the routers traversed, the maximum number of hops, and the packet’s total return time in milliseconds. The maximum number of hops limits the path search; it does not prove that the destination was reached. The time values describe the diagnostic replies and do not prove application throughput. In 4. Device Console, traceroute6 2001:db8::10 complements the IPv4 example above; replace the documentation address with the actual IPv6 destination address.

The labels Name lookup and Lookup using all configured servers below apply to SFOS 22. The changed SFOS 23 labels DNS lookup and All configured servers, along with the additional server options and their prerequisites, are explained in Compare individual resolvers under Diagnostics.

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

For SFOS 22 and SFOS 23, enabling and disabling the service subsystem debug shown here is documented in the Device Console, not in WebAdmin. Pktcapd is the documented example, not a universal switch for all services. Before starting, record the installed build, affected HA node, available disk space, test window and appropriate procedure for disabling debug; check the syntax and available subsystem with ? or Tab. Debug increases log file sizes and remains active until disabled. Enable it only for a short, agreed analysis window:

Before debug on: Determine and document the existing debug state for this exact subsystem on this exact HA node using a read-only method supported for the installed build or with Sophos Support. Also establish who is responsible for any existing diagnostics and whether a collection is running. system diagnostics show subsystem-info is only a supplementary system check; the documented syntax guarantees neither a uniform debug status field nor reliable proof that debug is disabled.

Stop if debug is active or the baseline state or ownership is unclear: Do not follow this on/off procedure, and in particular do not use debug off as a precaution to establish a baseline state. First coordinate the purpose, ownership, and rollback with the person responsible for diagnostics or Sophos Support; proceed only with an explicitly approved and confirmed inactive baseline state. An agreed test window alone does not authorize ending another ongoing diagnostic collection. Only then newly enable debug for this procedure and record your ownership of its activation and deactivation:

system diagnostics subsystems Pktcapd debug on

Reproduce the issue once. Select individual logs under Diagnostics > Tools > Troubleshooting logs and use Download to download them as a compressed archive. For a Consolidated troubleshooting report (CTR), instead go to Diagnostics > Tools > Consolidated troubleshooting report, select the required System snapshot and All log files options, enter the reason, then select Generate followed by Download. The CTR is downloaded in encrypted form; System snapshot does not require debug mode. For some CTR logs, the CLI setting limits the number of log lines included, so a CTR does not automatically contain the entire log history.

Immediately after the download, disable debug mode in 4. Device Console exclusively for the service subsystems whose debug this procedure newly enabled from the confirmed inactive baseline state and still owns. Leave the state of other ongoing diagnostics unchanged. For the example enabled in this way, the exact rollback is:

system diagnostics subsystems Pktcapd debug off

If reproduction is aborted, the download fails, load is high, or storage space is low, end the test and disable exclusively the debug that this procedure newly enabled from the confirmed inactive baseline state and still owns, rather than waiting for a successful export. Do not end other people’s ongoing diagnostic collections; if ownership is unclear, coordinate with the person responsible for diagnostics or Sophos Support rather than disabling debug on an assumption. An ended SSH session or a log download is no substitute for your own off command. Logs and reports are not synchronized between HA nodes; collect and clean up on the node where this procedure newly enabled debug.

Record the on and off commands, time, node and full CLI response. After the off command, check whether the CLI confirms that debug has been disabled or reports an error; as a supplementary check, compare the read-only system check system diagnostics show subsystem-info with the state recorded before the test. The documented syntax does not guarantee a consistent debug-status field on every build. If there is no clear confirmation, do not mark the state as “off”; clarify the output with Sophos Support. If a command is rejected, check the syntax with ? and do not proceed with guessed subsystem, restart or service commands. In particular, do not apply the service subsystem syntax to CSC, whose debug command is documented differently. Advanced Shell debug is deliberately not shown here because the generic service syntax does not provide a consistent 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, collect the files in WebAdmin: select Diagnostics > Tools > Troubleshooting logs for individual log files and choose Download. For a CTR, instead use Diagnostics > Tools > Consolidated troubleshooting report, select the required System snapshot and All log files options and enter a reason; then choose Generate followed by Download. Before sharing, verify that the archive or encrypted report has actually been downloaded, and provide it only through the agreed support portal. A failed export is no reason to leave active the debug that this procedure newly enabled from a confirmed inactive baseline state and still owns; another ongoing diagnostic collection must not be ended as a result. See Collect Sophos Firewall logs for support and analysis for the relevant instructions.

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 your own debug active after analysis: Logs grow unnecessarily and can consume storage space. Promptly disable only the debug that this procedure newly enabled from a confirmed inactive baseline state and still owns; do not end other people’s diagnostic collections.
• 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.
• Not cleaning up after the test: Debug, temporary files, or broad access remain active. Disable only the debug that this procedure newly enabled from a confirmed inactive baseline state and still owns, check files, and remove temporary SSH access permissions; do not end other people’s diagnostic collections.

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.
• Before service subsystem debugging in SFOS 22/23, established the existing state and the person responsible for diagnostics for the exact subsystem and HA node, and confirmed and documented an explicitly approved inactive baseline state; if the state was active or unclear, did not follow the on/off procedure, but coordinated with the responsible person or Support. Newly enabled debug briefly in 4. Device Console only from this baseline state; in the example, used system diagnostics subsystems Pktcapd debug on and then system diagnostics subsystems Pktcapd debug off to disable exclusively the debug newly enabled by this procedure and still owned by it. Left other people’s diagnostic collections unchanged. Checked the off response and supplementary system status; clarified any unclear state with Support rather than marking it as disabled.
• 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