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.
• 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, webproxy.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.

Troubleshooting logs are stored on the firewall in the /log directory. Access is available via the WebAdmin console or SSH. For short checks, Device Management > Advanced Shell in the browser works, but in practice SSH is usually more comfortable, more stable, and better 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. Connect via SSH or open Device Management > Advanced Shell in the WebAdmin console.
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.
• Control a service or enable debug: service <service>:<start/restart/stop/debug> -ds nosync, for example service ips:debug -ds nosync.

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 built manually with tar from the Advanced Shell. For support cases, WebAdmin also provides Diagnostics > Tools > Log file details or the troubleshooting log selection. There, log files can be selected by module and downloaded.

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 limited log package is needed. The CTR is better when Sophos Support needs a broad system snapshot. When creating a CTR, enter a short, clear reason such as ticket number, time window, or symptom. The report is downloaded encrypted and, for service subsystem logs, normally contains only a limited number of log lines. Complete individual log files are more reliably available through Troubleshooting logs or directly from /log.

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.

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 file system, log files, tail, grep, less, service -S, service restarts, and debug commands.

Not every command works in both areas. If an article explicitly mentions Device Console, run the command there. If it concerns /log, tail -f, grep, service -S, or debug logging, the Advanced Shell is usually meant.

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 is very helpful, but it generates a lot of data and can consume storage space. Debug should only be enabled for the relevant service. Then reproduce the problem and disable debug again.

Example:

service ips:debug -ds nosync
service ips:debug -ds nosync off

The exact syntax depends on the service. If the affected service is unclear, check the matching normal log file first.

Sophos distinguishes between two operating paths here. In the Advanced Shell, service commands such as service ips:debug -ds nosync are used. In the Device Console, the commands system diagnostics subsystems <subsystem> debug on and system diagnostics subsystems <subsystem> debug off are additionally available for supported subsystems. These variants should not be mixed: first clarify which console is being used, then use the matching command.

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.

System, Management, and Core Services

• 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 between components: garner.log; also check reporting, Central Reporting, and log processing.
• API: apiparser.log, app-feedback.log; also check 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, sig_update.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 files sandboxd.log, sessiontbl.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.
• Signature updates: Signature Updater, log files sig_upgrade.log, sig_update.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 Proxy: Log file webproxy.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.

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 strongswan-<connection>.log.
• IPsec older versions: IPsec service, log file ipsec.log.
• IPsec Test Connection: IPsec test, log file ipsec_Test_Connect.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.
• PPTP: PPTP VPN, log file pptpvpn.log.
• VPN certificates: VPN Certificate Services, log files vpncertificate.log, wc_remote.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.
• 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.

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 dhcp6.log.
• Network service: Service networkd, log file networkd.log.
• FQDN Hosts: Service fqdnd, log files fqdnd.log, fqdndebug.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 mdev.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 Routing: Service zebra, log file zebra.log.
• Application Based Routing: Service appcached, log file appcached.log.
• Redis App Cache: Redis, log redis.
• Multicast Routing: Log file mrouting.log.
• BGP: Service bgpd, log file bgpd.log.
• OSPF: Service ospfd, log file ospfd.log.
• RIP: Service ripd, log file ripd.log.
• PIM-SM: Service pimd, log file pimd.log.

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.
• 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 logs are stored on the device where they were generated. For raw logs from the auxiliary device, connect directly to that device, for example via its admin port over SSH. For consolidated reports, Sophos Central Firewall Reporting is more practical.

Mail and Anti-Spam

• Antivirus: AV Service, log file av.log.
• Antivirus updates: Up2Date AV, log file up2date_av.log.
• Anti-Spam: Service sasi, log file sasi.log.
• Sandbox: Service sandboxd, log files sandboxd.log, sessiontbl.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, awarrenmta_debug.log.
• POP/IMAP Proxy: Service warren, log file warren.log.

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.
• Wi-Fi Authentication: Service wifiauth, log file wifiauth.log.
• Hotspot: Services hostapd, hotspot, hotspotd; log files hostapd.log, hotspot.log, hotspotd.log.
• RED: RED Service, log file red.log.
• 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.
• SMB filesystem: Services smbnetfs, snireport; log files smbnetfs.log, snireport.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 files confdbstatus.log, crreportdb.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 files sac-feedback.log, 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.

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