Secure Sophos Firewall Logs for Support and Analysis

In cases of disruptions, VPN issues, or unclear firewall events, individual screenshots from the web interface are often insufficient. A support case requires traceable timestamps, appropriate log files, and sometimes an additional packet capture for a thorough analysis.

This guide describes how to package the logs of a Sophos Firewall into an archive via the Advanced Shell and securely provide them for Sophos Support, Avanet, or external analysis. This process does not replace the initial narrowing down in the Log Viewer. If it is still unclear which module is affected, the overview Sophos Firewall Troubleshooting: Services and Logs is helpful first.

Which Troubleshooting Article Fits?

The log archive is just one tool in troubleshooting. Depending on the error pattern, a different starting point may be quicker:

• Which rule, NAT rule, or route affects a specific connection attempt?: Test firewall rule with Log Viewer, Policy Test, and Packet Capture.
• Which local log file belongs to VPN, Web, IPS, GUI, or system services?: Sophos Firewall Troubleshooting: Services and Logs.
• A support case requires local log files, IPsec data, or debug outputs: This article.
• Historical reports or recurring events should be checked in Sophos Central: Central Firewall Reporting.
• Logs should be stored externally long-term or correlated with a SOC/SIEM: Set up Syslog or SIEM with Sophos Firewall.
• Traffic patterns, top talkers, or interface flows should be visible: Set up sFlow Monitoring on Sophos Firewall.
• A targeted packet capture is needed: Packet Capture or tcpdump-PCAP.

This separation saves time. A complete log archive helps with service and support analyses but does not replace a reproducible test case in the Log Viewer or a targeted packet capture.

What Data Does Support Need?

Not every problem immediately requires a complete log archive. The clearer the error is narrowed down, the smaller and more useful the data becomes.

• Firewall rule or NAT rule unexpectedly applies: Time, Source IP, Destination IP, Rule ID, NAT ID, Log Viewer export, and if needed Packet Capture.
• Service does not start or WebAdmin shows errors: Log archive from /log, affected service, time, and last configuration step.
• IPsec tunnel does not establish or drops: Normal log archive, IPsec diagnostic data, peer IP, local and remote networks, time of connection attempt.
• Traffic does not reach the destination: Log Viewer, Packet Capture, or for longer analyses tcpdump-PCAP.
• Problem after configuration change: Audit Trail, approximate change time, involved admin, and affected objects.

For many tickets, the combination of problem time, a brief error description, log archive, and a targeted additional proof is better than a very broad data package without context. If an official Sophos ticket is created, additionally Open a Sophos Support Ticket: Preparation and Portal fits.

Prerequisites

For this guide, you need:

• Administrative access to the Sophos Firewall
• Access to the Advanced Shell
• A target server or another secure way to transfer the log archive
• Enough free storage space on the firewall for the temporary archive

The commands are executed directly on the firewall. Therefore, you should work carefully and not delete any files unless it is clear what they are used for.

If access to the shell is not yet set up, the guide Connect to Sophos Firewall via SSH explains how to establish an SSH connection to the firewall.

⚠️ Log archives and PCAP files can contain sensitive information. Such files should only be stored briefly on the firewall, securely transferred, and removed again after successful handover.

Open Advanced Shell

Log in to the Sophos Firewall and open the Advanced Shell:

1. Open Device Management.
2. Select Advanced Shell.
3. Confirm access if the firewall displays an additional query.

After logging in, you are on the firewall’s shell. From there, the log files can be archived.

Collect Logs Before Securing

If a problem is reproducible, it should be triggered again directly before archiving the logs if possible. This ensures that the relevant entries are as current as possible in the log files.

For more complex problems, the normal logs may not be sufficient. In this case, it may be useful to enable a debug log for the affected service before archiving. How this works is described in the section Enable Debug Log Specifically.

Which log file belongs to which firewall module is summarized in Sophos Firewall Troubleshooting: Services and Logs. This overview is helpful if you want to specifically check whether VPN, IPS, Web, Mail, GUI, or system logs are more relevant for a problem.

If it is not a service problem but the packet flow itself is unclear, a log archive alone is often not enough. For short tests, Packet Capture in WebAdmin is suitable. For PCAP files, longer captures, or support analyses, tcpdump on the Sophos Firewall is the appropriate tool.

Secure All Log Files

Before archiving, check if there is enough free storage space under /var:

df -h /var

Then create a compressed archive with the files from the /log directory:

tar -cvzf /var/Sophos-Firewall-Logs.tar.gz -C / log

The command creates the file:

/var/Sophos-Firewall-Logs.tar.gz

The key components of the command:

• tar creates an archive.
• -c creates a new archive.
• -v displays the processed files.
• -z compresses the archive with gzip.
• -f specifies the archive’s filename.
• -C / changes to the root directory for the archiving process.
• log is the directory with the Sophos Firewall log files.

The advantage of -C / is that the command works independently of the current working directory. A prior cd / is therefore not necessary. If the file already exists, it will be overwritten by the command.

Depending on the size and load of the firewall, the archiving process may take some time. The output of tar shows which files are being written to the archive during this time.

Then you can check the archive size:

ls -lh /var/Sophos-Firewall-Logs.tar.gz

Additionally, you should briefly check if the archive is readable and actually contains the log directory:

tar -tzf /var/Sophos-Firewall-Logs.tar.gz

The output should show paths under log/. If the command reports an error or the archive is unusually small, the archive should not be passed on. Then first check free storage space, write permissions, and the previous tar run.

Copy Log Archive to a Linux Server

If a Linux server is reachable via SSH, the archive can be transferred with scp.

Example:

scp /var/Sophos-Firewall-Logs.tar.gz root@192.0.2.10:/root/

The IP address, user, and target path must be adjusted to your own environment.

After the transfer, the archive is located on the target server under:

/root/Sophos-Firewall-Logs.tar.gz

From there, it can be passed on internally or made available to Sophos Support or Avanet.

Secure IPsec Diagnostic Data Separately

For VPN or IPsec issues, the IPsec connection data from /tmp/ipsec/connections/ can also be helpful.

Create a separate archive for this:

tar -cvzf /var/Sophos-Firewall-IPsec-Connections.tar.gz -C /tmp/ipsec connections

Here too, the generated file can be briefly checked:

ls -lh /var/Sophos-Firewall-IPsec-Connections.tar.gz

This archive can also be copied to a target server via scp:

scp /var/Sophos-Firewall-IPsec-Connections.tar.gz root@192.0.2.10:/root/

Especially for IPsec errors, it is useful to provide this archive along with the normal firewall logs so that tunnel status, connection information, and log entries can be evaluated together.

Log Archive, Central Reporting, or Syslog?

A local log archive answers a different question than Central Reporting or Syslog.

• Log archive from /log: Support case, service error, VPN debug, local detailed analysis. Snapshot of the local firewall.
• Central Firewall Reporting: Reports, history, and search in Sophos Central. not a replacement for complete local support logs.
• Syslog or SIEM: own long-term storage, correlation, and SOC processes. requires parser, operation, and previously enabled logging.
• Audit Trail Logs: Trace configuration changes. no packet flow or service analysis.

For an acute support case, the local log archive is often still necessary, even if Central Reporting or Syslog is active. Conversely, for long-term storage, one should not hope that local logs on the firewall will still be fully available later.

Handle Packet Captures Separately

Log archives and packet captures are different pieces of evidence. The log archive shows service messages, errors, VPN states, and system events. A Packet Capture or tcpdump, on the other hand, shows whether packets really arrive, are forwarded, or if responses are missing.

For support cases, packet captures should not be sent unfiltered. It is better to:

1. Note test case with Source IP, Destination IP, Port, Protocol, and Time.
2. First check Log Viewer and WebAdmin Packet Capture if that suffices.
3. Only if needed, create a narrow tcpdump capture as PCAP.
4. Securely transfer the PCAP file.
5. Remove the PCAP file from the firewall after successful transfer.

The PCAP file does not belong in the /log archive but is created and transferred separately. This keeps it clear which file contains service logs and which file contains network packets.

Security and Data Protection

Log files can contain sensitive information, such as:

• Public and internal IP addresses
• Usernames
• Hostnames
• VPN information
• Error messages with technical details
• Indications of internal network structures

Log archives should therefore only be transferred over secure channels and only provided to persons or organisations involved in the analysis. If logs are sent to an external partner, it should first be clarified internally whether the transfer is permitted according to your own data protection and security policies.

Remove Temporary Archives

After the archive has been successfully transferred, it should be deleted from the firewall to avoid unnecessary storage space usage:

rm /var/Sophos-Firewall-Logs.tar.gz

If a separate IPsec archive was also created, it should also be removed:

rm /var/Sophos-Firewall-IPsec-Connections.tar.gz

Before deleting, check whether the files have successfully arrived on the target system.

Checklist for Support Cases

• Briefly described the problem: What is not working, since when, how often?
• Noted exact time with time zone.
• Noted affected Source IP, Destination IP, user, service, or tunnel name.
• Checked relevant module in Log Viewer.
• If necessary: Enabled and disabled debug only briefly.
• Created log archive from /log.
• Additionally secured IPsec diagnostic data for IPsec issues.
• Created Packet Capture or tcpdump separately for packet flow issues.
• Briefly checked archive readability with tar -tzf.
• Transferred archive and PCAP only over secure channels.
• Removed temporary files on the firewall after successful transfer.

FAQ