Restart Sophos Firewall services safely

The safest way to restart an individual Sophos Firewall service is under System services > Services. If the service is not listed there, that is not a reason to run an arbitrary shell command: use the Advanced Shell only with current, service-specific Sophos instructions or in a support case. First identify the affected service and determine which connections a restart could interrupt.

⚠️ Important: Restarting a service changes the system state and can interrupt VPN, routing, DNS, DHCP, web access or administrator access. Save the status and logs beforehand, and have an alternative access method available for remote sites.

Restart a service through WebAdmin

Before clicking, record the current status, exact time of the error, and the functional test that is failing. You can download relevant files individually under Diagnostics > Tools > Troubleshooting logs. For a support case, a Consolidated troubleshooting report (CTR) also includes system status, processes, and resource usage. For a remote site, the pre-check must also cover a maintenance window and alternative access.

1. Open System services > Services.
2. Check the affected service and its current status. Do not start a service that is intentionally stopped or not configured.
3. Under Manage, click Restart.
4. Wait for the service to return to its previous Running state, then test the affected function.

WebAdmin lists services including Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot, and Packet capture and Live connections. If a service is not configured, its button remains disabled. Anti-spam requires an inbound or outbound spam policy. Stopping Packet capture and Live connections ends running captures and makes the Live Connections view unavailable. If packet capture does not start even though its switch is on, Sophos specifically identifies this WebAdmin restart as the recovery step.

A service restart has no rollback that restores active sessions. The state to preserve is therefore the service status recorded beforehand. If a previously running service does not return to Running, do not click Restart repeatedly. Record a new timestamp, download the log or CTR, and investigate the failure or involve Sophos Support.

Under Control Center > System, the services status indicates whether a service is stopped or failed to start. This is a useful starting point, but it does not replace a functional test. If only the WebAdmin interface has stopped responding, follow Restart the Sophos Firewall WebAdmin GUI.

Antivirus service stopped after failed pattern updates

If the Antivirus service remains stopped after failed SAVI and AVIRA pattern updates, do not click Restart repeatedly. First save the firmware version and build, the time of the failure, and the related avd.log and up2date_av.log files. Under Backup & firmware > Pattern updates, also record the last successful update and the current state: Ready to install, Downloading, Success, or Failed. The general process for checking these states is described in Configure and check Sophos Firewall pattern updates.

Sophos tracks this issue as NC-180066; it is fixed in SFOS 22.0 MR2 Build 546. If the symptoms match on an older SFOS 22 build, check the supported path with the firmware update preparation guide and upgrade to MR2 Build 546 or a later approved version first. A single restart under System services > Services is generally available, but Sophos does not document it as a workaround or fix for NC-180066, and it does not replace the firmware update.

Only after the firmware update, click Update pattern now under Backup & firmware > Pattern updates. The affected Antivirus pattern update must reach Success, and the Antivirus service must remain active. The displayed service status alone is not enough: the pattern update must also complete successfully. If the issue occurs again on MR2 Build 546 or later, provide the saved logs and timestamps to Sophos Support rather than continuing to assume NC-180066.

Restart IPsec through VPN Management

The CLI main menu provides a supported restart of the VPN service daemon under 6. VPN Management > Restart VPN Service. Sophos warns that this drops all VPN tunnels. If only one VPN connection needs to be re-established, use its action in WebAdmin instead. Before restarting the daemon, save the tunnel state, exact time, and strongswan.log; afterwards, verify Child SAs, peers, and real application traffic again. Restarting the service does not fix a proposal, routing, or NAT error.

The same menu can regenerate the RSA key pair used for IPsec authentication. This isn’t a service restart but a key change. For connections using RSA key, peers then need the new public key; remote-access users must download their VPN configuration again. Sophos documents no one-click return to the old key pair. Use this action only as a planned rotation with a complete tunnel inventory, maintenance window, and alternative administrator access, not as a general troubleshooting step. It doesn’t repair PSK or certificate problems either.

Restart a service through the Advanced Shell

Use the Advanced Shell only when current Sophos instructions name the specific service and command or Sophos Support provides it. For SSH access and host key verification, follow Connect to Sophos Firewall through SSH. SSH should be allowed only from trusted administration networks; the relevant settings are covered in Device Access and Local Service ACL. Inactive SSH sessions are closed after 15 minutes.

After signing in, open:

5. Device Management > 3. Advanced Shell

The Device Console under menu option 4 validates its documented commands and is intended for supported network and system diagnostics. The Advanced Shell under 5. Device Management > 3. Advanced Shell, by contrast, is a Linux shell with full access to databases and system services. Configuration changes made there are not persistent and are not included in backups. Run read-only checks first, and trigger a restart only after checking the service name, impact, maintenance window, and recovery access.

1. Check the service name and status

To display known services and their current state, run:

service -S

The output can be filtered for the suspected service. For IPsec, for example, run:

service -S | grep -i strongswan

RUNNING means that the service is running. STOPPED, UNREGISTERED or UNTOUCHED do not automatically indicate a fault: depending on the firmware and configuration, a service may intentionally be inactive or unregistered. First check whether the associated function, policy or licence is used at all.

If the technical service name is unclear, see Sophos Firewall troubleshooting: services and logs. It maps functional areas to their log files.

2. Check logs before making a change

A restart can obscure important clues about the cause. For IPsec, read strongswan.log first and save the relevant messages:

less /log/strongswan.log

Press q to exit less. For larger investigations, export the logs beforehand as described in Save Sophos Firewall logs for support and analysis. In HA clusters, each node stores only the logs for traffic it processes; both nodes may need to be checked separately.

3. Restart the service on a standalone firewall

The following example assumes a standalone firewall. Before running it, service -S | grep -i strongswan must confirm the service. The restart can interrupt site-to-site and remote access IPsec connections. Check tunnels, remote peers and the maintenance window first.

Sophos documents this pattern:

service <service>:restart -ds nosync

A complete example for the IPsec service is:

service strongswan:restart -ds nosync

The generic syntax and service -S are documented in the current SFOS 22 help, where strongswan is mapped to the IPsec service. This example was not executed on a firewall and is therefore not described as lab-tested. Do not guess the name of any other service from a list.

For further analysis, see Sophos Firewall IPsec troubleshooting.

⚠️ HA cluster: Do not apply the standalone command without verification. Depending on the service and situation, Sophos instructions use sync or nosync; the public documentation does not provide a sufficient general rule. The service, node, SFOS build and synchronisation mode must come from current service-specific Sophos instructions or a support case.

Separate stop and start commands should be used only when Sophos Support instructs you to do so for the specific service. The service remains fully stopped between the two commands.

This restart also has no state-preserving rollback: disconnected security associations and sessions cannot be restored. The safe stopping criterion is the comparison with the pre-check. If strongswan does not return to its previous state or the tunnels do not re-establish, do not trigger a second restart. Save the logs and CTR and escalate the issue.

4. Validate the result

After the restart, check the status, log and actual function:

service -S | grep -i strongswan
tail -f /log/strongswan.log
grep -i 'error' /log/strongswan.log

tail -f displays new messages continuously and is stopped with Ctrl+C. Compare messages with the time recorded before the restart; an unfiltered grep can also show old errors. Then check the IPsec tunnels and test a host at the remote site. A service status of RUNNING alone does not prove that the connection works again.

If the restart fails, also check csc.log. For HA problems, ha.log, msync.log and applog.log may also be relevant, depending on the symptoms.

Common services and appropriate functional tests

Confirm the exact service name on the affected firewall with service -S. The most important mappings are:

• strongswan: Site-to-site and remote access IPsec. Afterwards, check tunnel status, strongswan.log and reachability of the remote site.
• dnsd: DNS service. Afterwards, test internal and external name resolution, dnsd.log and any configured DNS request routes.
• dhcpd: DHCP server. During a restart, new or renewing clients may not receive a response. Afterwards, test lease assignment and dhcpd.log.
• awed: Communication between the firewall and AP/APX devices. Afterwards, check the access point connection status and awed.log.
• zebra: Installs dynamic and static routes in the kernel. A restart is therefore invasive and should be performed only with specific Sophos instructions; afterwards, test the routing table, gateways and actual paths.
• smtpd: SMTP proxy in MTA mode. The transparent legacy proxy uses a different service; check the operating mode and smtpd_* logs before making a change. Afterwards, test controlled mail sending and receiving.

For WAF, Web proxy, IPS, Authentication and services available in WebAdmin, restarting under System services > Services is usually clearer than using a shell command.

When a service restart is not appropriate

Restarting an individual service is appropriate when a specific module is affected and the rest of the firewall is stable. Do not restart services blindly when:

• the cause or affected service is still unclear;
• several core services fail at the same time;
• that service provides the only remaining remote access;
• the problem is reproducible and the logs have not yet been saved;
• the same service has already been restarted several times;
• the HA role, node or required synchronisation mode is unclear.

If several services are affected, first check system load, storage, database state, HA and the latest configuration or firmware changes. Repeated restarts often only conceal the root cause.

A full reboot is more invasive and should be considered only when the firewall remains unstable overall, a firmware or hotfix process requires it, or Sophos Support instructs it. In the Device Console, system restart restarts the firewall; in an HA cluster, the command causes a failover. By contrast, system shutdown only shuts it down. Before either action, verify the target appliance and HA node, backup, maintenance window, and local or out-of-band access; for a shutdown, that recovery method must actually support powering the appliance on. After a restart, check the HA role and synchronisation, service status, and affected data paths. Interrupted sessions cannot be rolled back. If the appliance does not return, do not repeat the command; use the prepared recovery access and involve Sophos Support if necessary. See Plan Sophos Firewall backup and restore correctly.

Document the change briefly

For recurring problems or a support case, a short note is sufficient. It shows later whether the restart provided a lasting fix or merely concealed a symptom:

Date/time and time zone:
Firewall / HA node:
Service and command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:

Before making the change, record the time, affected function and relevant log messages. Afterwards, record the service status, functional test and next action. Remove temporary SSH or Device Access rules and disable debug modes after the investigation.