Map Sophos Firewall Service Logs Correctly

Sophos Firewall has three important levels for troubleshooting: event logs in the Log viewer, diagnostic tools in WebAdmin, and service or log files on the firewall. The Log Viewer is ideal for quick questions such as “was the connection allowed or blocked?”. The files under /log are more important when a service does not start, a VPN tunnel is unstable, web filters apply unexpectedly, or support needs detailed data.

This article maps the most important services and log files to typical admin problems. It also helps when a technical service name appears in the dashboard, in the Advanced Shell, or in a support case, and it is not immediately clear which firewall function it belongs to. Names such as zebra, warren, awed, garner, or strongswan are not self-explanatory in daily operations.

Tool Selection and Prerequisites

Before searching in log files, it should be clear which tool gives the fastest answer. Many cases can already be narrowed down with Log Viewer or Packet Capture. The shell only becomes genuinely useful when a service itself must be checked or support needs detailed log data.

Which Troubleshooting Tool Fits?

Not every firewall problem starts with a shell. Often, another tool is faster first:

• Connection allowed or blocked? Test firewall rule with Log Viewer, Policy Test, and Packet Capture.
• Does the entire Log Viewer show no new events? Check filters, logging, and the build-specific Garner workaround.
• Did the entire firewall restart unexpectedly? First classify the restart as an appliance reboot, HA failover, or service outage, then preserve sysinit.log, syslog.log, and the CTR.
• Packets arrive, but forwarding is unclear? Use Sophos Firewall Packet Capture in WebAdmin.
• Packet capture must run longer, be saved as PCAP, or analysed in Wireshark? Sophos Firewall tcpdump: capture packets via CLI.
• Configuration change suspected as the trigger? Check Sophos Firewall Audit Trail Logs.
• Change from Sophos Central is stuck? Check Sophos Central Firewall Management Task Queue.
• Reports or history needed in Sophos Central? Enable and operate Sophos Firewall Central Reporting.
• Logs must go to SIEM, SOC, or a log server long term? Send Sophos Firewall Syslog to SIEM.
• Traffic flows, bandwidth peaks, or communication patterns are the focus? Configure sFlow Monitoring on Sophos Firewall.
• Service is not running or support needs logs? This article.
• Secure local logs for Sophos Support or Avanet? Secure Sophos Firewall logs for support and analysis.
• Prepare a support case? Open a Sophos support ticket: preparation and portal.

The order matters. The Log Viewer often shows faster which rule or module made the decision. Packet Capture proves the packet flow in WebAdmin. tcpdump is useful when a longer capture, a PCAP file, or a very precise CLI filter is needed. Service logs and debug help when a specific service itself is the problem or when data must be collected for Sophos Support.

Quick Start by Symptom

If it is unclear which log is relevant, start by symptom rather than by service name.

• Single connection does not work: First check Log Viewer with source, destination, service, and time. Then use Packet Capture, firewall_rule.log, and nat_rule.log.
• VPN tunnel is down or unstable: Check VPN status, peer IP, time, and Log Viewer. Then review strongswan.log, charon.log, sslvpn.log, and IPsec diagnostic data.
• WebAdmin, User Portal, or SSH is not reachable: Check Device Access, Local Service ACL, and the affected zone. Then use apache.log, tomcat.log, sshd.log, and Packet Capture on the destination port.
• Web filter, TLS Inspection, or IPS blocks unexpectedly: Check Log Viewer module and policy ID. Then compare ips.log, awarrenhttp.log, and Packet Capture.
• Sophos Central task remains stuck: Compare Central Task Queue and local status. Then check centralmanagement.log, sophos-central.log, and fwcm-api-executor.log.
• HA behaves differently per node: Determine the active node, auxiliary node, and affected traffic path. Then log in directly to the affected node and check HA logs.
• Local reports are missing or storage is filling up: Check report settings, storage, and Central Reporting. Then use reportdb.log, garner.log, and storage analysis.

This view prevents a common trap: searching in a service log file even though rule matching, Device Access, NAT, or routing would need to be proven first.

Log Viewer or Log File?

Open the Log viewer in the top right of the WebAdmin console. It updates automatically, can be filtered by module, time, field values, and free text, and can export logs as CSV.

To protect usernames, IP, MAC, and email addresses in the everyday log view, Data Anonymization for local logs and reports can be used. Its effect in the Log viewer does not automatically prove that files under /log, CTR, remote syslog, or Central anonymize the same identities; each output path is checked separately.

Troubleshooting logs are stored on the firewall in the /log directory. The officially documented route is through the CLI: sign in, select 5 Device Management, then 3 Advanced Shell. SSH is usually more comfortable for longer tail, grep, or less sessions. Secure SSH preparation is described in Connect Sophos Firewall via SSH.

Before longer shell sessions, it should be clear which admin network is used, whether the SSH fingerprint has been checked, and whether the Advanced Shell is really needed. For many first checks, Log Viewer or Packet Capture in WebAdmin is enough.

As a rule of thumb, this order helps:

1. Single traffic flow is affected: Filter Log Viewer by source, destination, service, and time.
2. Log Viewer shows no decision: Start Packet Capture with a narrow filter.
3. Packet Capture shows Incoming, but no clear decision: Check Rule ID, NAT ID, Firewall ID 0, return path, and matching log file.
4. A specific service seems unstable: Watch the matching file under /log with tail -f.
5. An error is sporadic or needs support: Prepare time window, filter, log archive, and, if needed, tcpdump.
6. Normal logs are not enough: Enable debug only for the affected service and only briefly.

This keeps the analysis small enough. First collect the visible finding, then switch to packet flow, and only after that to service logs or debug. This reduces the risk of enabling broad debug logs too early or evaluating the wrong log file.

Read Log Files in the Advanced Shell

Before searching in /log, document the test case as narrowly as possible: local time, affected source IP, destination IP, port, user, module, and expected behaviour. These details make the difference between useful log analysis and a long search through old entries.

1. Sign in to the CLI, select 5 Device Management, then 3 Advanced Shell.
2. Change to the log directory.

cd /log

Useful commands:

tail -f firewall_rule.log
tail -f nat_rule.log
grep -i error ips.log
less strongswan.log
service -S | grep ips

The most important Advanced Shell commands:

• Follow live: tail -f /log/<logfilename>.log, for example tail -f /log/ips.log.
• Read a static log file: less /log/<logfilename>.log, for example less /log/ips.log.
• Search for a term: grep <keyword> /log/<logfilename>.log, for example grep error /log/ips.log.
• Read service status: Use service -S, or narrow it to a name, for example service -S | grep ips. This check does not change the service.

For support or later analysis, do not only copy individual log lines. A clear time range, the reproduced test, relevant screenshots from Log Viewer or Packet Capture, and, where needed, a complete log archive are better. Local logs rotate, so important data should be secured while the event is still present in the affected time range. The process is covered in Secure Sophos Firewall logs for external analysis.

Download Troubleshooting Logs in WebAdmin

Not every log collection must be assembled manually in the Advanced Shell. WebAdmin collects the files under Diagnostics > Tools.

In practice, there are two paths:

• Individual log files: Open Diagnostics > Tools > Troubleshooting logs, select the affected log files, and download them as a compressed file.
• Consolidated Troubleshooting Report (CTR): Use Diagnostics > Tools > Consolidated troubleshooting report when support needs all logs plus system state, processes, and resource data in one package.

This is practical when an admin does not want to open a longer shell session or when only a clearly scoped log package is needed. The CTR is better when Sophos Support needs a broad system snapshot. Enter a clear reason such as the ticket number, time window, or symptom. The report downloads encrypted; its filename also contains the firewall serial number, so it does not belong in public attachments.

By default, a CTR contains 10,000 lines per service subsystem log. In the Device Console, the value can only be set from 250 to 10,000, so it can only be reduced from the default. Default subsystem logs are exempt and include all lines. This limit applies only to the CTR; complete individual files remain available through Troubleshooting logs or the Advanced Shell.

Important: a downloaded log package does not replace context data. Support still needs the time with timezone, affected IPs, user, tunnel name, rule ID, NAT ID, and a short description of what exactly was reproduced.

For HA clusters, also note: logs and reports are not simply synchronised between Primary and Auxiliary. Each node contains the logs for the traffic and services it processed itself. For node-specific issues, the affected node must therefore be checked.

Understand log rotation and volatile data

Troubleshooting logs are initially created in memory and copied by the firewall to the file system. If the firewall stops responding, entries that haven’t yet been copied to the file system can be lost. An unexpected reboot or hang is therefore no reason to postpone evidence collection; save the available CTR, logs, and timeline first.

Each subsystem has its own file-size and storage limits based on criticality and appliance model. When the active file reaches its limit, SFOS compresses it as .gz and continues writing under the original filename. Once the subsystem also reaches its rotation limit, it deletes the oldest compressed file first. The number of rotations and available history therefore differ between services.

Don’t rename or delete log files or .gz rotations manually. Follow Manage storage space and reports safely for storage analysis, export, and the documented purge commands.

Advanced Shell or Device Console?

Sophos Firewall has two different console areas that are often confused:

• Device Console: Sophos CLI for firewall-specific commands, for example routing priority, IPsec routes, or system options.
• Advanced Shell: Linux-like shell for the file system, log files, and read-only commands such as tail, grep, less, and service -S.

Not every command works in both areas. If an article explicitly mentions Device Console, run the command there. /log, tail -f, grep, and service -S belong in the Advanced Shell. The documented system diagnostics ... commands for CTR limits, log purging, and subsystem debug belong in the Device Console.

This distinction matters because many errors happen simply because a correct command is entered in the wrong place.

Logging Must Be Active

Not every expected piece of information appears automatically.

• In firewall rules, Log firewall traffic must be active.
• In SSL/TLS inspection rules, logging must be enabled.
• Under System services > Log settings, define which log types are sent locally, to Sophos Central, or to Syslog.

For long-term retention, a Syslog server or Sophos Central Firewall Reporting is useful. How to connect external log servers or a SIEM is covered in Send Sophos Firewall Syslog to SIEM. For Sophos Central, Enable Central Firewall Reporting is the matching process.

Enable Debug Only Deliberately

Debug logging generates substantially more data, consumes storage, and can capture confidential content. It is not a sensible first step. Establish the normal log, time window, and reproducible test first; use debug only for the affected subsystem and only as long as necessary.

Sophos documents two different methods. The Advanced Shell form service <service>:debug -ds nosync toggles state and has no separate on or off argument. For a supported service subsystem, prefer the explicit Device Console commands documented by Sophos: system diagnostics subsystems <subsystem> debug on, reproduce and collect the issue, then run system diagnostics subsystems <subsystem> debug off. For example, use Pktcapd as the subsystem name for packet-capture debug. Debug is off by default, but before changing it, confirm that no other administrator or support engineer is already collecting data. Record the change and verify that debug is off after collection.

Treat CSC system-controller debug as a separate toggle

SFOS 22 documents a separate Device Console command for the system controller (CSC):

system diagnostics subsystems CSC debug

Unlike the service-subsystem syntax above, this command has no on or off argument: each execution toggles CSC debug. Use it as a controlled change, not as a status query:

1. Pre-check: Confirm with the other administrators and Sophos Support that CSC debug isn’t already enabled or part of an active collection. Record the firewall or HA node, time, reason, and intended collection window. Preserve a baseline copy of the relevant CSC log before making the change. Don’t run the toggle merely to discover its state.
2. Enable and reproduce: In Device Console, run the command exactly once. Reproduce only the scoped issue and record the test time with timezone.
3. Preserve evidence: Before rollback, either download the relevant individual troubleshooting log, or generate the CTR and download the completed CTR file. Keep the encrypted CTR and any log archive restricted because they can contain confidential data; don’t purge or overwrite the evidence needed for the case.
4. Disable / roll back: Return to Device Console and run the same command exactly once. This second, planned execution toggles CSC debug back off.
5. Verify: Perform a short controlled test and confirm in the newly written CSC log lines that debug-level output has stopped and log growth has returned to its normal rate. Record the rollback time and result. If the initial state or post-check is ambiguous, don’t issue the toggle repeatedly; stop and coordinate the state with Sophos Support.

⚠️ WAF debug and reverseproxy.log: With SFOS 22.0 MR2 Build 546, Sophos fixed issue NC-177457, in which a password was visible in reverseproxy.log when WAF debugging was enabled. Sophos states neither when the affected version range began nor what type of password was exposed. Existing WAF debug logs, troubleshooting archives, and CTR files from older or unknown builds should therefore be treated as potentially containing credentials.

If a plaintext credential is found: Restrict access, document the incident, and rotate the affected credential. Do not delete logs indiscriminately before support, forensic, and retention requirements have been clarified.

Debug logging and basic CLI commands are described in more detail in Sophos Firewall CLI troubleshooting: important commands. For restarting individual services, Safely restart Sophos Firewall services is also helpful.

Common Log Search Mistakes

Many log analyses take a long time not because data is missing, but because the wrong tool is used too early.

• Enable debug immediately: First check Log Viewer, the matching log file, and a reproducible test.
• Search only for error messages: Also narrow down source, destination, user, Rule ID, NAT Rule ID, and time.
• Ignore Packet Capture: If it is unclear whether packets arrive or are forwarded, use Packet Capture early.
• Treat Central Reporting as live debug: Use Central Reporting for history and reports, local logs for detailed analysis.
• Secure support logs days later: Secure logs, time, and reproduction steps while the event is still traceable.
• Leave debug running after the test: Disable debug again and check storage space.

A good troubleshooting case therefore always has three things: a narrow test, the matching log source, and a documented time. Without this basis, many log lines may be visible, but not necessarily the cause.

Log Files by Functional Area

The following lists are intended as a reference. It is best to choose the affected functional area first and then check the matching log file with a narrow time window.

The primary mappings follow the current SFOS 22.0 documentation. On older installations or in old support archives, the previously used names app-feedback.log, sig_update.log, sessiontbl.log, webproxy.log, fqdndebug.log, ipsec_Test_Connect.log, redis, hotspot.log, awarrenmta_debug.log, smbnetfs.log, snireport.log, confdbstatus.log, and crreportdb.log may also appear. Sophos no longer lists them in the current SFOS 22.0 log reference, so they should not be assumed to exist on a current build.

System, Management, and Core Services

• System startup: sysinit.log; check this first for boot and Failsafe problems.
• System messages: syslog.log; also check time, reboot, and interface events.
• WebAdmin web server: apache.log, apache_access.log; also check Device Access and Local Service ACL.
• WebAdmin application: tomcat.log; also check GUI errors, high load, and service status.
• SSH: sshd.log; also check Device Access, source network, and public-key login.
• GUI/CLI errors: error_log.log; also check current change, browser, and admin action.
• Configuration changes: applog.log, csc.log; also check Audit Trail and Config Studio.
• Configuration database: postgres.log; also check storage, backup/restore, and support case.
• Communication channel between specific components and their services: garner.log; for Central Management and reporting, also check the relevant plugin entries.
• API: apiparser.log; also check validation.log, API ACL, token, and Central Task Queue.
• Validation: validation.log, validationError.log; also check faulty objects or imports.
• Licensing: licensing.log; also check licence status, Central Sync, and air-gap special case.
• System updates: u2d.log; also check pattern status, DNS/HTTPS, and storage.

For management problems, do not only check the WebAdmin log file. Very often, Device Access, a Local Service ACL Exception Rule, or an incorrect source network decides whether WebAdmin, SSH, User Portal, VPN Portal, DNS, or SNMP is reachable. For this part, Secure Sophos Firewall access: configure Device Access correctly is the better starting point.

Firewall, NAT, and Packet Capture

• Firewall rule matching: firewall_rule.log; also check Log Viewer module Firewall.
• General firewall processing: fwlog.log; also use Packet Capture.
• NAT rules: nat_rule.log; also check NAT Rule ID in Log Viewer.
• DNAT with Link Load Balancing: also check dgd.log when gateway or link selection is involved.
• Packet Capture in WebAdmin: pktcapd.log; also check Diagnostics > Packet capture.
• Bandwidth Management / QoS: bwm.log; also check Traffic Shaping Policy.
• Virtual Host / older server publication: vhost.log; also check NAT and WAF.
• Web Server Protection / WAF: reverseproxy.log; also check WAF rule, Hosted address, and backend reachability.

For DNAT problems, always check firewall rule and NAT rule together. NAT only translates; it does not allow traffic. More details: Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Sophos Firewall uses, among other things, IP tables, ARP table, IPset, and conntrack for firewall connections. IMQ is used for QoS or Bandwidth Management. This information is helpful when log messages or support outputs contain technical terms from the Linux network path.

IPS, Application Control, and TLS Inspection

• Intrusion Prevention: Service ips, log file ips.log.
• Application Control: Service ips / Application Filter, log file ips.log.
• DPI and TLS Inspection: DPI Engine, log file ips.log.
• Antivirus in the network path: Service avd, log file avd.log.
• Zero-Day Protection / Sandbox: Sandbox service, log file sandboxd.log.
• Active Threat Response / X-Ops Threat Feeds: ATR in the network path; first check Log Viewer, then ips.log depending on module.
• MDR Threat Feeds: ATR / MDR feed status, log file atr.log; the operations guide correlates the audit ID, Task Queue, and local traffic evidence.
• Signature updates: Signature Updater, log file sig_upgrade.log.
• Signature migration: Signature Migration, log file sigmigration.log.

Many modern protection functions only see enough detail when HTTPS is decrypted. If TLS Inspection does not apply, web filters, Application Control, IPS, and malware scanning may be less informative depending on the traffic.

If it is unclear whether IPS is active, which policy applies, or why a signature blocks, start with Set up and safely test Sophos Firewall IPS. Then ips.log, Log Viewer, and Packet Capture can be combined more precisely.

If the topic is application detection, Application Filter, or unexpected App Control blocks, start with Set up and test Sophos Firewall Application Control.

For Zero-Day Protection, also check whether Web Protection, TLS Inspection, file type, file size, policy, and action fit together. The matching operations article is Understand and operate Sophos Firewall Zero-Day Protection. For Threat Feeds, use Set up and operate Sophos Firewall Threat Feeds safely. More on TLS Inspection: Roll out TLS Inspection on Sophos Firewall step by step.

Web, Proxy, WAF, and Web Filter

• HTTPS Proxy: Service awarrenhttp, log file awarrenhttp.log.
• HTTPS Proxy Access: awarrenhttp access log, log file awarrenhttp_access.log.
• Web Categorization / Reputation: Service nSXLd, log file nSXLd.log.
• Legacy HTTP/FTP Proxy: Service skein, log file skein.log.
• FTP Proxy: Service ftpproxy, log file ftpproxy.log.
• Web Application Firewall: Reverse Proxy, log file reverseproxy.log.

For a suspected proxy loop, block_proxy_loop together with briefly enabled awarrenhttp debug can produce Duplicate Via header values, proxy loop. Check HTTP proxy settings safely explains the prerequisite, global impact, and safe rollback. Keep debug active only for the reproducible test and turn it off afterwards.

If web traffic appears as blocked in the Log Viewer, the cause can be in several modules: Web Policy, SSL/TLS inspection, Application Control, IPS, or WAF. Therefore, always select the specific module in Log Viewer and also check the matching log file.

Sophos blocks websites in the highly objectionable criminal activity category by default and hides the domain name in logs and reports. If an entry in this area looks deliberately anonymised, this can therefore be intentional.

For web categories, URL groups, Web Policies, and Instant Alerts, use Use Sophos Firewall web categories and Instant Alerts.

VPN

• IPsec from SFOS v17+: Services strongswan, charon; log files strongswan.log, charon.log.
• IPsec connection-specific: individual IPsec connection, log file /log/ipsec_conn/ipsec_<connectionname>.log.
• IPsec older versions: IPsec service, log file ipsec.log.
• IPsec Monitoring: IPsec Monitor, log file ipsec_monitor.log.
• XFRM / route-based VPN: Service xfrmi, log file xfrmi.log.
• SSL VPN: SSL VPN / OpenVPN, log file sslvpn.log.
• SSL VPN Status: OpenVPN status, log file openvpn-status*.log.
• VPN Portal: Log file vpnportal.log.
• L2TP: Service l2tpd, log file l2tpd.log. L2TP remote access on Sophos Firewall explains setup and diagnostics.
• PPTP: PPTP VPN, log file pptpvpn.log.
• VPN certificates: VPN Certificate Services, log file vpncertificate.log.
• Clientless SSL VPN: Clientless Access, log file clientless_access.log.

Sophos Firewall uses strongSwan for IPsec VPN and OpenVPN for SSL VPN. For IPsec problems, time, peer IP, proposal, Local/Remote Subnets, NAT-T, routing, and firewall rules are decisive.

For IPsec problems, Sophos Firewall IPsec troubleshooting is the better step-by-step guide. For route-based VPN and manual IPsec routes, Create IPsec route on Sophos Firewall helps.

Authentication, User Portal, and SSO

• User authentication: Access Server / AAA, log file access_server.log.
• NTLM / NASM: Service nasm, log file nasm.log.
• Chromebook SSO: Chromebook SSO Backend, log file chromebook-sso-backend.log.
• OAuth SSO Captive Portal: Log file oauth_sso_captive.log.
• OAuth SSO WebAdmin: Log file oauth_sso_webadmin.log.
• OAuth SSO VPN: Log file oauth_sso_vpn.log.
• RADIUS SSO: User-to-IP mapping through accounting in access_server.log. RADIUS SSO with accounting explains setup and validation.
• STAS: STAS / Access Server context, depending on service context and access_server.log.

For user rules, always first check whether the user is known at all. If Match known users is active and authentication does not work, the rule does not match. For classic browser sign-ins, Set up and test Sophos Firewall Captive Portal combines Device Access, the user rule, Live users, Log Viewer, and access_server.log into a complete diagnostic path.

If it is still unclear whether the service selection, identity, main group, quota, or only the subsequent traffic path fails, Systematically troubleshoot Sophos Firewall authentication errors brings these layers together in one diagnostic workflow.

If Captive Portal is used with Microsoft Entra ID SSO, Set up Microsoft Entra ID SSO for Sophos Firewall Captive Portal helps compare oauth_sso_captive.log, Device Access, groups, and later rule matching.

DNS, DHCP, and Network

• DNS Service: Service dnsd, log file dnsd.log.
• DNS Grabber: Service dnsgrabber, log file dnsgrabber.log.
• DNS Entity / further DNS components: Services entity, eacd; log files entity.log, eacd.log.
• DHCP IPv4: Service dhcpd, log file dhcpd.log.
• DHCP IPv6: Log file dhcpd6.log.
• Network service: Service networkd, log file networkd.log.
• FQDN Hosts: Service fqdnd, log file fqdnd.log.
• Dead Gateway Detection: Service dgd, log file dgd.log.
• Dynamic DNS: Dynamic DNS client, log file ddc.log.
• NTP Client: Log file ntpclient.log.
• IPv6 Router Advertisement: Service radvd, log file radvd.log.

DNS and DHCP problems often look like firewall problems. Therefore, first check IP address, gateway, DNS server, and whether clients are supposed to use the firewall as DNS or DHCP server.

If internal domains are not resolved correctly, Configure DNS Request Routes on Sophos Firewall is usually relevant. For DHCP special options, there is the separate article Configure Sophos Firewall DHCP Options.

Cellular WAN

• WWAN / USB modem: Check plugging and unplugging of USB devices in modemd.log.
• Modem network configuration: Check modem-related interfaces and IP configuration in networkd.log.
• USB, modem, and PPP: Check syslog messages about USB, modem, and Point-to-Point Protocol in syslog.log.

For Cellular WAN problems, also check whether the modem is recognised, whether PIN/SIM/APN are correct, and whether the firewall creates a suitable gateway.

Routing

• Static unicast routes: Log file staticd.log. Configure and test a static route on Sophos Firewall explains setup and testing.
• Installation of static IPv4 unicast routes: Service zebra, log file zebra.log.
• Application Based Routing: Service appcached, log file appcached.log.
• Multicast Routing: Log file mrouting.log.
• BGP: Service bgpd, log file bgpd.log. Configure and validate BGP on Sophos Firewall explains the setup and validation; zebra.log additionally helps determine whether a learned route was installed in the system.
• OSPFv2 and OSPFv3: Services ospfd and ospf6d, log files ospfd.log and ospf6d.log. The additional zebra.log shows whether the dynamic route was installed in the system. Configure and validate OSPF on Sophos Firewall explains the setup and validation.
• RIP: Service ripd, log file ripd.log. Configure and validate RIPv2 on Sophos Firewall explains setup and validation; zebra.log also shows whether a learned route was installed in the routing stack.
• PIM-SM: Service pimd, log file pimd.log. Configure and validate PIM-SM on Sophos Firewall explains the setup and validation.

For routing problems, also check Routing > SD-WAN routes, gateways, and Packet Capture. The policy tester does not replace a real routing test.

More on this: Adjust routing priority on Sophos Firewall.

GUI, CLI, and System Access

For WebAdmin, SSH, API, and local management services, the base list above under System, Management, and Core Services applies. If WebAdmin or SSH is not reachable, do not only check apache.log, tomcat.log, or sshd.log. Local access is controlled via Administration > Device access and Local Service ACL.

More on this: Establish an SSH connection to Sophos Firewall.

Sophos Central, Heartbeat, and Central Management

• Sophos Central Management: Central Management, log files centralmanagement.log, sophos-central.log.
• CSC: Services csc, cschelper, csd; log files csc.log, cschelper.log, csd.log.
• Security Heartbeat: Services heartbeatd, hbtrust; log files heartbeatd.log, hbtrust.log.
• Synchronized Application Control: Check data sent to SophosLabs in sac-feedback.log.
• Heartbeat to Central: Services fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; check the respective service logs.
• Central API Executor: Service fwcm-api-executor, log file fwcm-api-executor.log.
• Active Threat Response: ATR context; check depending on version and module.

For Central problems, first check whether the firewall is registered, Central services are active, and outbound DNS/HTTPS works. If a change from Central does not arrive locally, compare the Sophos Central Firewall Management Task Queue with the local logs. A green Central status alone does not prove that a specific policy was processed locally.

High Availability

• HA status and configuration: HA Application Log, log file applog.log.
• HA Pair Service: Service ha_pair, log file ha_pair.log.
• HA Tunnel: Service ha_tunnel, log file ha_tunnel.log.
• Conntrack Sync: Service ctsyncd, log file ctsyncd.log.
• Msync: Service msync, log file msync.log.
• HA establishment and status changes: ha.log.
• File synchronisation for selected services to the auxiliary device: filesync.log.

HA logs and reports aren’t synchronised between the devices. Each node stores only the data for traffic it processed itself. Check Log Viewer and Diagnostics > Tools > Troubleshooting logs on every affected device. To retrieve the auxiliary device’s troubleshooting logs, sign in directly to its CLI using the IP address or FQDN of its administration interface. Sophos Central Firewall Reporting can combine reports from both devices, but it doesn’t replace node-local troubleshooting files.

Mail and Anti-Spam

• Antivirus: AV Service, log file avd.log.
• Antivirus updates: Up2Date AV, log file up2date_av.log.
• Anti-Spam: Service sasi, log file sasi.log.
• Sandbox: Service sandboxd, log file sandboxd.log.
• SMTP MTA: Service smtpd, log file smtpd_main.log.
• SMTP errors: smtpd Error/Panic/Reject, log files smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
• Legacy SMTP/S Proxy: Services awarrensmtp, awarrenmta; log files awarrensmtp.log, awarrenmta.log. Mail Protection in legacy mode explains setup and end-to-end testing.
• POP/IMAP Proxy: Service warren, log file warren.log. Scan POP3 and IMAP on Sophos Firewall explains setup and end-to-end testing.

For mail problems, always check whether MTA Mode, firewall rule, DNS, certificates, and provider restrictions fit together. The process for mail flow, spool, quarantine, and relay is described in Set up Sophos Firewall Mail Protection in MTA Mode.

Sophos Firewall uses Avira and Sophos Antivirus. The anti-spam service only starts if an incoming or outgoing spam policy exists. This dependency matters if sasi.log stays empty or the anti-spam service is not running.

Wireless, RED, Hotspot, and Other Services

• Wireless Controller: Service awed, log file awed.log.
• Wireless clients: Check communication between the client and AP/APX in wc_remote.log.
• Hotspot: Services hostapd, hotspotd; log files hostapd.log, hotspotd.log.
• RED: RED Service, log file red.log. Depending on the RED type and instance, red-<serial ID of RED>.log and red-<RED ID>.log can also appear.
• SNMP: Service snmpd, log file snmpd.log.
• Syslog Service: Log file syslog.log.
• Licensing: Licensing Service, log file licensing.log.
• System updates: Service u2d, log file u2d.log.
• VMware Tools: Service vmtool, log file vmtool.log.

For licence, air-gap, or pattern problems, licensing.log and u2d.log are the first technical places to look. For the operating process with licence file, 180-day window, and manual pattern updates, Operate Sophos Firewall air-gap licensing and pattern updates fits.

Database and Reporting

• Configuration database: Config DB, log file postgres.log.
• Postgres: Service postgres, log file postgres.log.
• Signature database: Service sigdb, log file sigdb.log.
• Report database: Report DB, log file reportdb.log.
• Migration database: Report Migration, log file reportmigration.log.
• Garner: Service garner, log file garner.log.
• iView: Service iview, log file iview.log.

If reports are missing, slow, or storage problems occur, reporting and database logs are relevant. Also check whether reports are stored locally or sent to Sophos Central.

Additional current SFOS 22 log files

The following files are needed less often for daily traffic troubleshooting but belong to the current SFOS 22 mapping. They are grouped by function so that a filename isn’t mistaken for a root cause:

• Audit, FIPS, and support access: configuration-audit.log records the configuration change, administrator, and time; fips.log covers startup in FIPS mode; uma.log covers support access.
• Log pipeline and local data maintenance: syslog-ng.log shows suppression of consecutive event entries; reportdb_v9.log belongs to the old report database. dbcleanup.log, readobject.log, fstrim.log, and logrotate.log cover database cleanup, internal object reads, file-system trimming, and log rotation.
• ATR, NDR, and FastPath: atr-service.log shows ATR service initialization and shutdown. ndr.log and ndr_agent.log cover NDR licensing, configuration, agent initialization, and metadata processing; vfpdf.log applies to NDR metadata on XGS 88/88w, 108/108w, 118/118w, and 128/128w. setup_vf_dpdk.log records FastPath memory initialization and specifically doesn’t apply to these four model ranges.
• TLS and SSL VPN: httplogd.log shows undecrypted HTTPS connections in the DPI path. peruser_cert_sslvpn.log records per-user SSL VPN certificates; openvpn-status0.log, openvpn-status1.log, and further numbered files show active SSL VPN connections per process.
• Network and HA: dhcprelay.log belongs to DHCP relay. ha.log shows success or failure in establishing HA and status transitions; filesync.log covers file synchronization for selected services to the auxiliary device.
• Central, deployment, and ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log, fwcm-updaterd.log, and fwcm-frpcd.log cover zone/interface information sent to Central, connectivity, transferred configuration, and Fast Reverse Proxy. ssod.log contains firmware and Central backup information, zt.log and zerotouch.log cover Zero Touch variants, and ztna-connector.log covers the local ZTNA connector.
• Backup, firmware, air gap, and certificates: interfacemapping.log records interface mapping during restore, legacyconversion.log covers backups without a Secure Storage Master Key, and fwmgmt.log covers firmware installation and management. u2d_airgap.log applies to air-gap updates, cps_messages.log to hotfix errors, and letsencrypt.log together with applog.log to Let’s Encrypt certificates.
• Hardware and system state: npu-startup.log, npu_syslog.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-npu-serial.log, and xgs-pport-wait.log cover NPU startup, communication, firmware, serial port, health, and physical interface creation. raid.log shows software RAID and lcd.log the hardware display. system-monitor/cpu_trigger.log records system state at high CPU usage; system-monitor/memory_trigger.log applies in SFOS 22 for high memory load.
• Cloud and platform services: iaasd.log covers provisioning and license inspection in Azure, waagent.log covers the Azure agent and health monitoring, and vmtool.log belongs to VMware Tools.

The presence of a file doesn’t prove a fault in that module. Correlate event time, affected node, platform, service status, and reproducible symptom first; only then search the relevant file with a narrow filter.

Analysis Workflow

1. Note the problem precisely: time with timezone, client, target, port, user, action.
2. Decide whether it concerns traffic, service status, configuration change, or Central synchronisation.
3. Filter in Log Viewer by source IP, destination IP, module, and time.
4. Check visibility of Firewall Rule ID, NAT Rule ID, user, gateway, and policy IDs.
5. Use Packet Capture if packet flow, return path, or NAT view is unclear.
6. Check the matching log file with tail -f, less, or grep.
7. Reproduce the problem and document the exact test time.
8. If needed, enable debug only for the affected service and only briefly.
9. Disable debug again and check storage space.
10. Secure logs while the error has just been reproduced.

For support cases, also document all error messages, reproduction steps, and troubleshooting steps already performed. These exact details significantly speed up support cases. The matching process is described in Open a Sophos support ticket: preparation and portal.

FAQ