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 Fusion (formerly Sophos Central) is stuck? Check the Sophos Fusion Firewall Task Queue.
• Reports or history needed in Sophos Fusion? 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.

For questions purely about connectivity, Diagnostics > Tools complements log searches with Ping, Traceroute, and DNS and route lookups. Ping checks reachability, Traceroute checks the path, and a lookup checks name resolution or the route. The basic diagnostic commands help with tool selection; a successful test from the firewall does not replace a test from the affected client.

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 Fusion 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 a narrowly scoped live filter, you can add a date or client address:

tail -f /log/ips.log | grep 2026-10-10
tail -f /log/ips.log | grep 192.0.2.10
less /log/ips.log | grep error

The date and 192.0.2.10 are example values: replace them with the date shown in the log or the affected client’s IP address. tail -f shows only the last existing lines and newly added entries, not automatically the entire day’s history. For entries already stored, use, for example, grep 2026-10-10 /log/ips.log. If the filter returns nothing, first check the time format, time zone, IP address and log file before assuming that logging is missing. In less /log/ips.log, Shift+G jumps to the end of the file, Enter moves forward one line, and q exits the display; Ctrl+C stops a running tail -f capture. The pipeline with less produces filtered text output, not an interactive less view. These commands read logs but do not change rules or the debug state.

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 Fusion, 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 Fusion, 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 cover SFOS 22.0 and 23.0; the OAuth SSO files differ between these versions, as indicated below. Older installations or old support archives may also contain 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. Sophos does not include them in the SFOS 22/23 log lists considered here, so you should not assume they are present on a current build.

Check the general system and configuration logs in addition to those for the relevant module. A file can serve several functions: what matters is its relevance to the specific symptoms, not just the service name.

System, Management, and Core Services

• System startup: sysinit.log; check this first for boot and failsafe problems.
• Kernel-level system messages: syslog.log; also check time, reboot and interface events. Compare system events and administrator-triggered events in Log Viewer as well.
• Apache web server for WebAdmin and User Portal: apache.log, apache_access.log and error_log.log; also check Device Access and Local Service ACL.
• WebAdmin and User Portal application: Jetty web application server, log file tomcat.log; also check GUI errors, high load and service status. The file name is not the name of the current web application server.
• SSH: sshd.log; also check Device Access, the source network and public-key login.
• GUI/CLI errors: error_log.log; also check the latest change, browser and administrator action.
• Configuration changes: applog.log, csc.log; also check Audit Trail and Config Studio.
• Configuration database: postgres.log; also check disk space, backup/restore and the support case.
• Communication channel between certain 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 the special air-gap case.
• System updates: u2d.log; also check pattern status, DNS/HTTPS and disk space.

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 the Firewall module in Log Viewer.
• Connection-related firewall logs: fwlog.log; their generation depends on firewall rule logging and Log settings. Use Packet Capture as well.
• 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 / legacy server publishing: vhost.log; also check NAT and WAF.
• Web Server Protection / WAF: reverseproxy.log; some WAF configuration details are also recorded in firewall_rule.log. Check the WAF rule, Hosted address and backend reachability.

NAT is not just a matter of nat_rule.log: check the NAT setting of a site-to-site IPsec connection in charon.log, and a NAT command executed through the CLI in applog.log. This helps distinguish a tunnel configuration from a normal NAT rule.

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.

appcached.log also contains the temporary cache of categorised applications before they are stored in the database; its use for Application Based Routing is listed further below. For MDR and third-party threat feeds, atr.log shows licence and configuration status, not just a traffic decision. For IP address IoCs, also check firewall_rule.log. For domain or URL IoCs, consider the firewall, DNS, SSL/TLS inspection and web proxy logs together: firewall_rule.log, dnsd.log, ips.log, httplogd.log and, depending on the processing path, awarrenhttp.log. The modules involved implement Active Threat Response according to the IoC type.

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

• HTTP and HTTPS through the web proxy: service awarrenhttp, log file awarrenhttp.log.
• HTTPS proxy access: awarrenhttp access log, log file awarrenhttp_access.log. For SFOS 22/23, individual web proxy requests appear here only when awarrenhttp is running with debug enabled; follow the capture procedure below.
• Web categorisation / reputation: service nSXLd, log file nSXLd.log.
• Category updates (SFOS 22/23): log file catUpdateLog – note the case, with no .log extension.
• FTP through the HTTP 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 this access-log collection, first identify the affected firewall/HA node, test case, time, and a short collection window, check disk space, and confirm with other administrators or support that debug is off. Do not use the toggle as a status query. Then run service awarrenhttp:debug -ds nosync exactly once in the Advanced Shell, reproduce the narrowly defined issue, and save awarrenhttp_access.log securely. Afterwards, run the same command exactly once to turn debug off again. Use a brief controlled test to check that no new debug entries appear and the normal log grows at its normal rate again; document the rollback and disk-space check. If the initial state or post-check is unclear, do not keep toggling; clarify it with support. This method applies here to awarrenhttp in SFOS 22/23, not generally to all services or releases.

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 always blocks websites in the highly objectionable criminal activity category and hides the domain name in logs and reports. This is not a freely configurable default action. If an entry in this area appears deliberately anonymised, this may 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.

These implementations apply to both site-to-site and remote access. /log/ipsec_conn/ipsec_<connectionname>.log contains, in particular, the connection-specific WebAdmin actions for enabling, disabling and connecting the tunnel; replace <connectionname> with the actual connection name. For VPN user authentication, also check access_server.log, and for portal problems, check vpnportal.log. For Sophos Connect client problems, preserving evidence also includes the client’s technical support report: firewall logs alone do not show the client’s entire state. The IPsec troubleshooting procedure helps bring together the client and firewall findings.

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, authorisation and accounting: 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.
• Chromebook SSO process: csd.log; distinguish this from the backend log.
• OAuth SSO Captive Portal (SFOS 22): log file oauth_sso_captive.log.
• OAuth SSO WebAdmin (SFOS 22): log file oauth_sso_webadmin.log.
• OAuth SSO VPN (SFOS 22): log file oauth_sso_vpn.log.
• OAuth SSO (SFOS 23): oauth_sso_svc.log for SSO logins to WebAdmin, Captive Portal, VPN Portal, IPsec VPN and SSL VPN.
• RADIUS SSO: user-to-IP mapping through accounting in access_server.log. RADIUS SSO with accounting explains setup and acceptance testing.
• STAS: STAS / Access Server context, depending on the 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 (SFOS 22; in SFOS 23: oauth_sso_svc.log), Device Access, groups, and later rule matching.

DNS, DHCP, and Network

• DNS service: service dnsd, log file dnsd.log.
• Wildcard FQDN service / DNS Grabber: service dnsgrabber, log file dnsgrabber.log.
• DNS Entity / other 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.
• Physical and virtual interfaces: service networkd, log file networkd.log.
• FQDN hosts: service fqdnd, log file fqdnd.log.
• Dead Gateway Detection and WAN/gateway management: service dgd, log file dgd.log; also check link failover, VPN failover and DNAT.
• 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. Set up a static route on Sophos Firewall explains setup and verification.
• 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 and BGP IPv6: service bgpd, log file bgpd.log. Configure BGP on Sophos Firewall explains setup and acceptance testing; zebra.log also helps check whether a learned dynamic IPv4 or IPv6 route was installed in the kernel.
• OSPFv2 and OSPFv3: services ospfd and ospf6d, log files ospfd.log and ospf6d.log. zebra.log also shows whether the dynamic route was applied in the system. Configure OSPF on Sophos Firewall explains setup and acceptance testing.
• RIP: service ripd, log file ripd.log. Configure RIPv2 on Sophos Firewall explains setup and acceptance testing; zebra.log also shows whether a learned route was installed in the routing stack.
• PIM-SM: service pimd, log file pimd.log. Configure PIM-SM on Sophos Firewall explains setup and acceptance testing.

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

For static and dynamic routes, csc.log also provides opcode information and indications of service restarts. In an HA context, add ha.log, msync.log and applog.log. For SD-WAN routes, check applog.log, csc.log and dgd.log alongside appcached.log; if IPsec is involved, consult the IPsec logs as well.

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 Fusion, Heartbeat, and Central Management

• Sophos Central Management: Central Management, log files centralmanagement.log, sophos-central.log.
• CSC and helper services: services csc, cschelper, csd; log files csc.log, cschelper.log, csd.log. cschelper.log covers system-generated emails and authentication tools, while csd.log covers the Chromebook SSO process.
• Security Heartbeat and Synchronized Security: heartbeatd.log contains endpoint status and application information sent to the firewall; hbtrust.log contains communication with Central. The services are named heartbeatd and hbtrust; also check csc.log and applog.log.
• Synchronized Application Control: check data sent to SophosLabs in sac-feedback.log.
• SAC database optimisation (SFOS 22/23): sac-vacuum.log records the weekly optimisation of the Synchronized Application Control database; sac-feedback.log remains the separate log for data sent to SophosLabs.
• Central events, connection and configuration transfer: fwcm-eventd.log shows zone/interface information sent for dynamic objects, fwcm-heartbeatd.log shows the connection, and fwcm-updaterd.log shows transferred configuration. The services are named fwcm-eventd, fwcm-heartbeatd and fwcm-updaterd; not all three are heartbeat services.
• Central API Executor: service fwcm-api-executor, log file fwcm-api-executor.log.
• Active Threat Response: ATR context; check according to version and module.

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

sophos-central.log is relevant to registration and access tokens, while centralmanagement.log is relevant to enabled management and reporting. Cross-check registration and deregistration against applog.log, and firmware upgrades against csc.log. hbtrust.log shows communication; in garner.log, SCM plugin entries belong to Central Management and CR plugin entries to Central Reporting. fwcm-api-executor.log also contains MDR analyses transferred to the firewall. The SFOS 22 documentation considered here calls the platform Sophos Fusion (formerly Sophos Central), while the SFOS 23 documentation calls it Sophos Central; existing service and file names remain unchanged.

High Availability

• HA status and configuration: HA application log, log file applog.log.
• HA peer discovery in QuickHA: service ha_pair, log file ha_pair.log.
• SSH tunnel between HA devices over the dedicated link: 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 of 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 in MTA mode: smtpd_error.log for mail scanning errors, smtpd_panic.log for internal errors and smtpd_reject.log for rejected emails; the service is smtpd.
• 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 and AP/APX communication with the firewall: service awed, log file awed.log.
• Wireless clients: communication between the client and AP/APX in wc_remote.log.
• LocalWifi SSID: service hostapd, log file hostapd.log; do not confuse this with hotspot events.
• Hotspot events: service hotspotd, log file hotspotd.log.
• RED: red.log records all configured RED devices, including site-to-site RED and SD-RED. red-<serial ID of RED>.log belongs to the corresponding SD-RED device, while red-<RED ID>.log belongs to the corresponding site-to-site RED configuration. Find the RED ID under Network > Interfaces by opening the relevant site-to-site RED. Replace the placeholders with its actual serial number or RED ID, respectively.
• 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: new report database from SFOS 21.0 onwards, log file reportdb.log.
• Migration database: Report Migration, log file reportmigration.log.
• Configuration migration (SFOS 22/23): log file migration.log; do not confuse this with reportmigration.log for report migration.
• Garner: service garner, log file garner.log.
• Log visualisation in WebAdmin: 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 Fusion.

Additional Log Files for SFOS 22/23

The following files are needed less often in day-to-day traffic troubleshooting, but are part of the SFOS 22/23 mapping. They are grouped by function to avoid drawing premature conclusions about a cause from a file name:

• Audit, FIPS and support access: configuration-audit.log records the configuration change, administrator and time; fips.log records startup in FIPS mode; uma.log records Support Access.
• Log pipeline and local data maintenance: syslog-ng.log shows the suppression of consecutive entries for the same event; reportdb_v9.log belongs to the old report database. dbcleanup.log covers database cleanup when the firewall restarts, readobject.log covers internal object reading, fstrim.log covers file system trimming, and logrotate.log covers rotation to .gz files.
• ATR, NDR Essentials and FastPath: atr-service.log shows the start and end of the ATR service. ndr.log covers the NDR licence, configuration and agent startup; ndr_agent.log covers service startup and metadata processing. vfpdf.log shows metadata sent by FastPath to NDR Essentials exclusively on XGS 88/88w, 108/108w, 118/118w and 128/128w. setup_vf_dpdk.log records FastPath memory initialisation and specifically does not apply to these four model ranges.
• TLS and SSL VPN: httplogd.log shows HTTPS connections that are not decrypted in the DPI path. peruser_cert_sslvpn.log records SSL VPN certificates generated for individual users; openvpn-status0.log, openvpn-status1.log and other numbered files show active SSL VPN connections per process.
• Network and HA: dhcprelay.log belongs to DHCP Relay. ha.log shows success or failure when establishing HA, as well as status changes; filesync.log shows file synchronisation of selected services to the auxiliary device.
• Central, deployment and ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log and fwcm-updaterd.log cover zone/interface information, connection and configuration transfer. fwcm-frpcd.log covers the Fast Reverse Proxy when opening multiple firewalls in Central simultaneously. ssod.log contains firmware upgrade information sent to Central and firewall backups created there. For True/Controlled Zero Touch, check zt.log and fwcm-heartbeatd.log; for Zero Touch via USB, check zerotouch.log, not fwcm-heartbeatd.log. ztna-connector.log contains customer account/connector IDs, connector status, ZTNA tunnels, applications accessed and configuration updates.
• Backup, firmware, air gap and certificates: interfacemapping.log records interface mapping during restore, legacyconversion.log records backups without a Secure Storage Master Key, and fwmgmt.log records 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.
• API, restore and certificate management: apiparser.log covers API translation between JSON and XML, while validation.log and validationError.log cover API validation. For backup/restore, also check applog.log and postgres.log. vpncertificate.log covers not only VPN certificates, but also CAs, CSRs and CRLs.
• Hardware and system state: npu-startup.log shows NPU startup, npu_syslog.log shows NPU syslogs, and xgs-host.log shows host drivers at startup. xgs-npu-fw.log covers NPU compatibility checks, upgrades and recovery, xgs-npu-serial.log covers the NPU serial port, and xgs-pport-wait.log covers physical interface creation at startup. xgs-healthmond.log covers CPU utilisation, temperature, fan speed and the NPU management port. raid.log shows software RAID and lcd.log shows the hardware display. On hardware, virtual, cloud and software firewalls, system-monitor/cpu_trigger.log and system-monitor/memory_trigger.log record the system state during high CPU or memory load, respectively; both are listed for SFOS 22/23.
• FastPath syslogs: npu_syslog.log covers NPU-based FastPath and does not apply to XGS 88/88w, 108/108w, 118/118w and 128/128w. syslog.log shows host communication with NPU-based FastPath as well as Virtual FastPath. For VMware, check syslog.log in addition to the VMware Tools log vmtool.log.
• Cloud and platform services: iaasd.log records configuration provisioning and licence checks in Azure, while waagent.log records OS-level provisioning and health monitoring by the Azure provisioning agent; 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