Sophos Firewall CLI Troubleshooting: important commands

When Sophos Firewall troubleshooting, the Log Viewer is often sufficient for initial isolation. As soon as a service does not start smoothly, VPN connections are unstable, individual packets do not arrive or support needs detailed data, the CLI becomes important.

This overview shows the most important commands for everyday life: where to execute them, what they show and when it is better to switch to a specialized article. For secure access via SSH, Connect Sophos Firewall via SSH should first be checked. Public keys, host key checks and tight device access approval are more important than a quick login from anywhere.

⚠️ Important: CLI and Advanced Shell commands should only be executed from trusted admin networks and with a clear objective. In particular, debug, tcpdump, file operations and service commands can affect storage space, performance or running connections.

First WebAdmin, then CLI

The CLI is not always the quickest way to get started. When it comes to rule matching, NAT or individual connections, Log Viewer, Policy Test and Packet Capture in the WebAdmin often provide a clean result more quickly.

Good introductions:

• Which firewall rule applies? First use Log Viewer, Policy Test and Packet Capture. CLI only becomes necessary when the Log Viewer shows too few details or live logs are required.
• Are packets arriving on the firewall? First use Packet Capture in WebAdmin. CLI is useful when a tight capture or PCAP file is needed for support.
• Does a service have a problem? First check dashboard, Log Viewer and service logs. CLI becomes important when service status, debug or log files need to be checked directly.
• Was something changed? First check Audit Trail Logs. CLI then helps when comparing a configuration difference with logs or backups.

The goal is not to jump into the Advanced Shell as quickly as possible. It is better to have a comprehensible process: first check visible events, then open the appropriate log file or capture.

Document CLI findings in a usable way

CLI output is only useful if it is later clear which test it belongs to. Individual copied error messages without a time window, IP addresses or affected function often lead to queries and double analysis.

A short note per test is usually enough:

• Time window: Start, end and time zone of the test.
• Testflow: Source IP, Destination IP or FQDN, Port, User or VPN peer.
• Tool: Device Console, Advanced Shell, Log Viewer or Packet Capture.
• Command or filter: command executed, grep search term or capture filter used.
• Result: Hit, error message, missing log entry, package visible or package not visible.
• Next conclusion: for example rule problem, DNS problem, return path, service error or support case.

Before sharing with Support, Avanet, or external partners, check whether outputs contain sensitive data: public IPs, internal hostnames, usernames, VPN parameters, serial numbers, tokens, email addresses, or customer identifiers. For a technical analysis, data does not have to be distributed arbitrarily widely; What is important is the smallest section that proves the finding.

Before the first command

CLI troubleshooting becomes much more reliable if the frame is fixed before the first command. Otherwise, log excerpts without any reference to time, captures that are too wide, or debug logs quickly arise that no one can clearly assign later. Before productive CLI testing, you should note:

• Problem time: Logs can be searched specifically for the test window.
• Source IP, Destination IP and Port: grep, tcpdump and Packet Capture remain narrow and readable.
• Affected user or peer: Authentication, VPN and user matching are better attributable.
• Expected module: You first search in the appropriate log file instead of all logs.
• Planned Action: Debug, service check or capture will not accidentally become permanent.
• Rollback or termination criteria: The test is terminated in case of load, full memory or side effects.
• Current backup for change work: Service restarts or configuration changes can be backed up more cleanly. The first step should be reading if possible: check Log Viewer, view the appropriate log file, read service -S or start a close capture. Restarts, debug mode and wide-ranging recordings only belong in a conscious test window afterwards.

For HA clusters, it should also be clear which appliance is currently active. Logs, debug and captures must be checked on the node through which the relevant traffic actually runs.

Device Console or Advanced Shell?

Sophos Firewall has two different console areas. Many errors occur because a command is entered in the wrong area.

The areas have different tasks:

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

After logging in via SSH, the firewall first shows the console menu. For the Device Console you usually choose 4. Device Console. For the Advanced Shell use 5. Device Management > Advanced Shell.

The official Sophos CLI help supports Tab and ? for syntax checking. This is helpful in the Device Console because not every command is structured the same.

If a command is not recognized, check the console area first. A wrong range is more likely than an immediately broken command.

Check logs in the Advanced Shell

The most important log files are located under /log. For initial orientation, change to this directory and list the files.

cd /log
ls -lah

• Track log live: tail -f /log/strongswan.log. Good for reproducible VPN errors.
• Read log file: less /log/ips.log. Within less you can search with /Suchbegriff.
• Check for errors: grep -i "error" /log/ips.log. -i is case-insensitive.
• Hit with line number: grep -n "192.0.2.10" /log/firewall_rule.log. Helpful for longer files.
• Show last lines: tail -n 100 /log/syslog.log. Quick overview without live mode.

Which log file belongs to which module is summarized in Sophos Firewall Troubleshooting: Services and Logs.

With live logs, you should keep the test period short and note the time. This is particularly important if a log archive is later given to Sophos Support or Avanet.

Device Console for quick network checks

The Device Console is suitable for quick tests from a firewall perspective. This allows you to check whether DNS, routing or accessibility are basically working.

Quick checks:

• Reach host: ping 192.0.2.10 count 4 checks ICMP reachability.
• Check DNS: dnslookup example.com checks name resolution from the firewall’s perspective.
• Check route: traceroute 192.0.2.10 shows the path to the destination.
• View interface status: show interfaces shows interface information.
• Start Drop Capture: drop-packet-capture 'host 192.0.2.10' shows packets dropped by firewall rules.
• Start packet capture: tcpdump 'host 192.0.2.10 and port 443' checks whether packets are visible on the firewall. drop-packet-capture is particularly useful when it is unclear whether the firewall is actively dropping packets. However, it does not replace application analysis. If a server responds but the application still doesn’t work, it also needs Log Viewer, NAT check, Packet Capture or application logs.

For longer packet recordings and PCAP files, the separate article Sophos Firewall: Collect logs with TCPDump for analysis is more suitable. You should also plan how large the file can be, where it will be stored and how it will be transferred securely.

Check connections and packet flow in the Advanced Shell

If Log Viewer and Device Console do not provide a clear answer, some advanced shell commands will help you understand the packet flow.

Conntrack

conntrack shows active connections that the stateful firewall path is aware of. This is helpful if you want to check whether a connection even appears in connection tracking.

conntrack -L | grep "192.0.2.10"

If an entry is missing, it may indicate routing, NAT, incorrect source, missing firewall rule, or testing on the wrong path. If an entry exists but the application does not work, an additional check must be made to see whether response packets are returned and whether NAT, policy or application are working correctly.

tcpdump in the Advanced Shell

For quick live tests, the tcpdump can also be used in the Advanced Shell.

tcpdump -i any -nn host 192.0.2.10

For productive analyses, the filter should be as narrow as possible. Wide recordings like tcpdump -i any without host, port or count quickly produce a lot of output and are impractical on busy firewalls.

A safe start is a short recording with host, port and packet limit:

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

If more data is required, storage space should be checked beforehand and a PCAP storage location should be deliberately chosen.

Check storage space and system health

Before debug logging, large log archives or longer packet recordings, the free storage space should be checked.

df -kh
df -h /var

Other quick checks:

uptime
top
service -S
service -S | grep strongswan

service -S shows the status of many services. Individual service names are not always self-explanatory. You should therefore compare the service with the appropriate log file before activating restarts or debug.

If storage space is already limited, debug logging and long packet recording should not be started. First, clarify which logs or reports can be safely backed up and cleaned up.

Activate debug log specifically

Debug logging can help with complex errors, but should only be active for a short time and only for the affected service. Debug generates significantly more log data and can consume storage space if it runs for a long time.

Example for IPS debug:

service ips:debug -ds nosync

Reproduce the problem, note the relevant time and then deactivate debug again:

service ips:debug -ds nosync off

Before restarting a service, you should check which function is affected and whether productive traffic is currently running through it. Restarting VPN, IPS, web or authentication services may affect active sessions or user logins.

Deliver logs securely

Individual log excerpts are often not enough for complex cases. For Sophos Support, Avanet or external analysis, a complete log archive is usually more useful. Instead of writing FTP access data into commands, you should transfer logs via a secure and traceable way, for example via scp to your own server or via a support portal. The appropriate instructions are available at Sophos Firewall Back up logs for support and analysis.

Log files can contain sensitive information: internal IP addresses, public IPs, hostnames, usernames, VPN parameters and error messages. Before sharing it, it should be clear who will receive the data and how long it will be stored.

Typical CLI troubleshooting errors

• Command in wrong console area: Device Console and Advanced Shell support different syntax. Check area first.
• Leave debug active after analysis: Logs grow unnecessarily and can consume storage space. Deactivate debug again immediately.
• Wide tcpdump without filter: A lot of output, high load and data that is difficult to evaluate. Restrict host, port, interface or count.
• FTP credentials in the shell history: Credentials can end up in logs, screenshots or history. Use secure transfer and temporary credentials.
• Check only one log file: Many problems affect multiple modules. Combine Log Viewer, matching service logs and Packet Capture.
• Do not document the time: Support has to search unnecessarily large log areas. Note the time, test action and IPs involved.
• Do not clean up after testing: Debug, temporary files or wide accesses remain active. Turn off debug, check files and remove temporary SSH shares.

Checklist

• SSH access only allowed from trusted admin networks.
• SSH fingerprint and admin access checked before analysis.
• Correct console range selected: Device Console or Advanced Shell.
• Problem time, source IP, destination IP, port and user documented.
• CLI findings documented with time window, command, filter and result.
• Read commands used first before debug, service restarts or longer captures were started.
• Log Viewer checked first.
• Matching log file identified under /log.
• tail, grep or less used with narrow search term.
• Used specifically for network problems ping, dnslookup, traceroute, drop-packet-capture or tcpdump.
• Debug only activated briefly and deactivated again.
• Disk space checked before debug or PCAP.
• Securely transfer log archive and remove temporary files.
• Temporary Device Access or SSH exceptions removed after support case.

FAQ