Restart Sophos Firewall services safely

Restarting individual Sophos Firewall services can help if a module no longer responds correctly, a log no longer shows new entries or Sophos Support requests a targeted restart. It is not a replacement for clean troubleshooting. Restarting the wrong service can briefly interrupt VPN tunnels, routing, WebAdmin, DNS, DHCP, reporting or other functions.

This article explains how to restart services through WebAdmin or Advanced Shell, check the appropriate logs beforehand and then verify that the service is running cleanly again. If it is not yet clear which technical service belongs to which module, the overview Sophos Firewall troubleshooting: services and logs helps. For basic CLI safety, debug and tcpdump, Sophos Firewall CLI troubleshooting: important commands is also relevant.

⚠️ Important: Service restarts in production environments should be planned. Beforehand, it should be clear which service is affected, which users or tunnels may be interrupted and whether alternative access to the firewall is available.

When a service restart makes sense

A targeted service restart makes sense when a specific module is affected and the rest of the firewall is generally stable.

Typical examples:

• WebAdmin no longer loads, but routing and firewall rules continue to work.
• A VPN service is hanging while other firewall functions look normal.
• A log shows current errors for a specific service.
• Sophos Support names a specific service that should be restarted.
• A service did not become cleanly active after a configuration change.

Blindly restarting several services just because the problem is still unclear is not useful. In that case, first check logs, system load, storage space, HA state, routing and affected modules.

When services should not be restarted

A service restart is tempting because it can have an immediate effect. In some situations, however, it makes analysis worse or creates additional interruptions.

• The cause is still completely unclear: The restart changes the state and can hide important traces in logs or status output.
• Several central services fail at the same time: Then the problem is often not a single service, but system load, storage space, database, HA or platform state.
• The firewall is reachable only through exactly this service: A restart can lose the last remote access path.
• Production VPN, routing or DHCP services are affected: Existing users, sites or leases may be interrupted briefly.
• Debug is already running and the error is reproducible: Save relevant logs first, then restart.
• The service has already been restarted several times: Then root cause analysis is needed instead of repetition.

If a restart is still necessary, note at least the current time, affected users or sites, service name, log file and expected impact beforehand.

Check before the restart

Before restarting a service, briefly document what is affected. This saves time if the error returns or a support case becomes necessary.

Practical pre-check:

1. Narrow down the affected module, for example WebAdmin, IPsec, DNS, DHCP, IPS or WAF.
2. Check whether the firewall as a whole is stable or whether several services are failing.
3. Check whether admins, VPN users or critical sites are currently connected.
4. In HA clusters, check which node is being worked on and which node is active.
5. Open the matching log file and save the last messages.
6. Check storage space if debug, large logs or PCAP files are involved.
7. Export logs before the restart if needed.
8. Define a stop criterion: when will the restart be stopped, postponed or escalated?

For HA environments, understand Sophos Firewall HA cluster variants is also relevant. If logs are needed for external analysis, save Sophos Firewall logs for support and analysis fits.

Preserve evidence first if the issue returns

A service restart can temporarily fix a symptom, but it can also change the state that would be important for root cause analysis. If a problem occurs repeatedly, preserve a small evidence window before the next restart.

Useful minimum data:

• exact time with time zone
• affected service and affected function
• latest relevant messages from the matching log file
• service status output before the restart
• system load, disk space, or report/database indicators if the GUI is slow
• affected users, tunnels, interfaces, rules, or sites
• last configuration change, firmware change, hotfix, or HA event

This is especially important if the same service has already been restarted several times. Then the restart is only an immediate measure. The real work is to understand why the service repeatedly hangs, crashes, blocks, or stops writing new logs.

Document a restart in support cases

If a service restart is part of a support case, maintenance window or recurring problem, document the action briefly. This does not need to be a long report. The important point is that it remains clear later which service was restarted when, why and with what result.

Practical note template:

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

This note is especially helpful if an error returns after a few hours or days. It then immediately shows whether the same service is always affected, whether the restart only helps briefly or whether a deeper problem such as storage space, database state, HA behaviour or a product defect becomes more likely.

Restart services through WebAdmin

Some services can be restarted directly through WebAdmin. This is the simplest path if the GUI is still reachable and the required service is visible there.

The exact menu item depends on version and view. The key point is: WebAdmin is suitable only for services that are actually offered there. For deeper troubleshooting, log analysis or services without a GUI action, Advanced Shell is needed.

If only the WebAdmin GUI itself no longer responds, this general article should not be the first step. There is a targeted guide for that: restart Sophos Firewall WebAdmin GUI.

Open Advanced Shell

Advanced Shell is required for service commands. Access is usually by SSH with the admin user.

If SSH is not prepared yet, connect to Sophos Firewall by SSH helps. SSH access should be allowed only from trusted admin networks. Before logging in, check the SSH fingerprint, especially after a reimage, hardware replacement or IP change. The matching hardening is covered in Device Access and Local Service ACL on Sophos Firewall.

After login, open Advanced Shell through:

5. Device Management > Advanced Shell

Advanced Shell provides wide-ranging system access. Commands should only be run there if the affected service and the expected impact are clear.

If only the status should be checked or a log file read, start with read-only commands. Restarts, stop/start and debug are interventions and belong in a conscious analysis window.

List services

This command shows a list of available services:

service -S

If a specific service is being searched for, filter the output:

service -S | grep strongswan
service -S | grep zebra
service -S | grep dns

Technical service names are not always self-explanatory. Before restarting a service, compare the service name with the affected functional area.

• strongswan: Site-to-site IPsec and IPsec Remote Access; Tunnel status, remote peer, planned interruption, strongswan.log
• zebra: Routing and static routes; Routing table, SD-WAN/gateway status, affected sites
• dnsd: Firewall DNS service; DNS Request Routes, client test, dnsd.log
• dhcpd: DHCP lease assignment; affected zone, lease range, test client, dhcpd.log
• awed: Wireless Controller; affected Access Points, Central or local management, wireless logs

The more detailed mapping is in Sophos Firewall troubleshooting: services and logs.

Restart a service

The basic pattern for a restart is:

service <service>:restart -ds nosync

Example for the routing service zebra:

service zebra:restart -ds nosync

The syntax with a space matters: -ds nosync. Variants such as -dsnosync are not the same and should not be copied from old notes.

During a restart, the service is stopped and started again. Depending on the service, this can interrupt active connections. For routing, VPN, DNS, DHCP, Web Proxy, WAF or wireless, assess beforehand who may be affected.

If the service belongs to a security-relevant module, do not only check the status after the restart. The decisive point is whether the expected protection or connectivity function is working again and whether new error messages appear in the log.

Stop and start a service

If a service does not respond cleanly to restart or Sophos Support specifies it, stop and start can be run separately:

service zebra:stop -ds nosync
service zebra:start -ds nosync

Do not wait unnecessarily long between stop and start if the service is needed in production. Afterwards, check the status and perform a functional test.

Check service status

service zebra:status -ds nosync

Also check the matching log file. For routing, for example:

tail -n 80 /log/zebra.log

A successful status is not always enough. The decisive point is whether the affected function is working again: VPN tunnels connect, DNS responds, DHCP assigns leases, WebAdmin loads or routing works.

Examples of common services

The following examples show typical service restarts and do not replace root cause analysis.

Restart Wireless Controller

service awed:restart -ds nosync

Restart SMTP Service

service smtpd:restart -ds nosync

Restart VPN IPsec Service

service strongswan:restart -ds nosync

Restart DNS Service

service dnsd:restart -ds nosync

For IPsec problems, also use Sophos Firewall IPsec troubleshooting. For DNS problems, configure DNS Request Routes on Sophos Firewall or the DNS/DHCP mapping in Sophos Firewall troubleshooting: services and logs is often more relevant than a pure service restart.

Treat sensitive service areas consciously

Not every service restart has the same impact. Some services affect only an administration interface, others sit directly in the data path or control authentication, VPN, routing or local services. The closer a service is to production traffic, the more important maintenance windows, log checks and fallback plans become.

• IPsec / SSL VPN: Tunnels or Remote Access sessions can drop; Inform users and sites beforehand, then actively check tunnels
• DNS / DHCP: Name resolution or lease assignment can be briefly disrupted; Plan client test and log check after the restart
• Routing / SD-WAN: Paths, gateway monitoring or site connections may be affected; Check routing table, gateway status and reachability
• Web Proxy / IPS / TLS Inspection: Web access or inspection can be briefly affected; Check Log Viewer and affected policies after the restart
• WAF / Reverse Proxy: Published applications may be briefly unreachable; Test external URL and backend reachability
• WebAdmin: Admin access is briefly interrupted; Keep alternative access by SSH or local console ready
• Reporting / database / storage: Analysis, reports or GUI stability may be affected; Do not restart blindly; check storage space and logs first

If a service area is not clear, first look it up in Sophos Firewall troubleshooting: services and logs before running a restart. For database, storage or reporting topics, an untargeted restart is rarely the best first measure.

Validate after the restart

After a service restart, do not only check whether the command returns without an error message. The functional test matters.

Useful checks:

• Check service status with service <service>:status -ds nosync.
• Check the matching log file in /log for new errors.
• Validate the affected function with a real test.
• Check Log Viewer if firewall rules, NAT, web, IPS or VPN are affected.
• In HA clusters, check whether the active node continues to work as expected.
• Disable debug if it was enabled before or during the restart.
• Remove temporary SSH or Device Access permissions if they were set only for the support case.
• For recurring errors, save logs and analyse the cause instead of repeatedly restarting services.

Depending on the service, a different functional test makes sense:

• IPsec / strongswan: tunnel status, Log Viewer, strongswan.log, reachability of a host on the remote side
• DNS / dnsd: internal and external name resolution, DNS Request Routes, dnsd.log
• Routing / zebra: routing table, gateway monitoring, ping or traceroute through the affected path
• WAF / Reverse Proxy: test published URL externally, reverseproxy.log, backend reachability
• WebAdmin / tomcat and apache: check login, dashboard, Log Viewer and tomcat.log
• DHCP / dhcpd: check lease assignment with a test client and dhcpd.log

When a reboot is better

A full reboot is more invasive than a service restart, but can make sense if several central services are hanging, storage or database problems have been fixed, Sophos Support requests it or the firewall remains unstable after targeted restarts.

The decision should not be made on gut feeling. A service restart is better when a single module is clearly affected and the firewall is otherwise stable. A reboot is more likely to fit when the system-wide state is unclear or remains damaged after a targeted restart.

• Single service is hanging: Yes, if service and impact are clear; Only if the restart does not help
• Several services show errors: Check logs and storage space first; Yes, if overall system state is unstable
• Firmware or hotfix window is running: Not as a replacement for planned restart; Yes, if the update process requires it
• HA cluster is unstable: Only after role check and support approval; Only with maintenance window and HA plan
• Storage space or database has been cleaned up: Only for the affected service; Yes, if Sophos Support requests it as the final step
• Remote access is uncertain: Carefully, last access can drop; Only with local or alternative access

Before a reboot, backup, maintenance window, site access, HA behaviour and impact on VPN, RED, wireless, routing and published services should be known. For remote sites, there must also be a return path in case the firewall does not come back online cleanly after the restart: local contact, out-of-band access, working HA peer or a clear support process.

After the reboot, perform the same validation as after a service restart, only broader: check HA status, licence status, VPN tunnels, SD-WAN gateways, central logs, WebAdmin, Central connection and the most important published services. For recovery topics, plan Sophos Firewall backup and restore properly also fits.

Operations checklist

• Affected module and service name identified.
• Matching log file checked before the restart.
• Possible impact on users, VPN, routing or sites assessed.
• Maintenance window or HA context clarified if needed.
• SSH access and host key check prepared cleanly if Advanced Shell is required.
• Service restarted in a targeted way.
• Status and log file checked after the restart.
• Function validated with a real test.
• Debug and temporary access removed again after the analysis.
• Recurring errors documented and not hidden by repeated restarts.

FAQ