Restart the Sophos Firewall WebAdmin GUI

If the Sophos Firewall WebAdmin GUI stops responding, there is no need to reboot the entire firewall immediately. As long as routing, VPN, and firewall rules continue to work and SSH or the local console remains accessible, the two WebAdmin services, tomcat and apache, can be checked and restarted individually.

The following commands are intended for a standalone firewall. In an HA cluster, the correct synchronization mode depends on the service, node, SFOS build, and specific issue. Do not use -ds nosync in HA without verifying that it is appropriate.

⚠️ Restarting a service changes the system state, ends active WebAdmin sessions, and may also interrupt the User Portal briefly. Save the relevant logs first, inform other administrators, and have an alternative access method ready for remote sites.

Quick procedure for a standalone firewall

This procedure applies when WebAdmin shows an Internal Server Error, HTTP 503, an incomplete login page, or a permanently unresponsive interface while SSH and the firewall’s other functions remain available.

Sign in as admin through SSH or the local console. If SSH has not yet been configured, Connect to Sophos Firewall through SSH explains how to set up secure access.
Open 5. Device Management > 3. Advanced Shell.
Display the latest WebAdmin errors and copy relevant output for the change record or a support case:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log

Check the current service status:

service -S | grep -iE 'tomcat|apache'

If a service shows STOPPED, run only the corresponding start command:

# If tomcat is STOPPED:
service tomcat:start -ds nosync

# If apache is STOPPED:
service apache:start -ds nosync

If a service shows DEAD, restart only that service. If both show RUNNING but WebAdmin remains unusable, start with tomcat:

service tomcat:restart -ds nosync

Test WebAdmin again. Only if apache shows DEAD or the issue persists after restarting tomcat, run:

service apache:restart -ds nosync

Wait a few seconds, reopen WebAdmin from the intended management network, and check the service status again:

service -S | grep -iE 'tomcat|apache'

Both services should show RUNNING. The functional test is what matters, however: the login, dashboard, Log Viewer, and a non-critical configuration page must all load reliably. A running process alone does not prove that WebAdmin is working correctly.

Inactive SSH sessions are closed after 15 minutes. Prepare the log checks, restart, and validation before entering the Advanced Shell so that an expired session does not interrupt the procedure.

Check whether a service restart is appropriate

Behind the service name tomcat is the Jetty web application server; apache is the Apache HTTP Server. Both components are used by WebAdmin and the User Portal. Their logs are available in the Advanced Shell:

Application server: /log/tomcat.log
Web server: /log/apache.log and /log/apache_access.log
Additional web server errors: /log/error_log.log

Not every WebAdmin issue originates in these services. The type of error determines the next step:

Internal Server Error, HTTP 503, or an incomplete login page: Check tomcat, apache, and the listed logs. A targeted restart is reasonable here.
Certificate warning: Check the certificate name, validity, and trust chain. Restarting a service does not correct an invalid certificate.
Timeout or access failure from only one network: Check the route, management network, and Administration > Device access. Local firewall services are permitted through Device Access, not through a standard firewall rule. Device Access and Local Service ACL explains the secure configuration.
Only one browser is affected: Test a private session, a second browser, or another administrator client before changing anything on the firewall.
WebAdmin, SSH, VPN, or other services fail together: This points instead to system load, storage, the database, HA, or a wider system issue. Do not restart services at random.

If a firmware, hotfix, or pattern update, HA synchronization, support debug session, or active Central task is in progress, identify and, where possible, complete that process first. Otherwise, it will be difficult to determine later whether the issue came from the update, Central, HA, or the service restart.

Preserve evidence before the intervention

A restart can move current error messages out of the visible context. For a recurring issue or support case, record at least the time, SFOS build, affected access path, and the latest messages from tomcat.log, apache.log, and error_log.log.

If WebAdmin still works partially, individual logs or a Consolidated Troubleshooting Report can be downloaded under Diagnostics > Tools. If only the shell remains available, Save Sophos Firewall logs for support and analysis explains the process. In an HA cluster, each node stores its own logs; check the Primary and Auxiliary separately when necessary.

Before a production restart, also confirm:

whether other administrators or an active change are affected;
whether SSH, the local console, Sophos Central, or another management connection provides a return path;
whether WebAdmin is the only affected service;
whether the correct node and current service-specific Sophos guidance are available for an HA cluster.

Restart Sophos Firewall services safely explains the general handling of service names, status, logs, and HA boundaries. Sophos Firewall troubleshooting: Services and logs provides further mappings between functions and log files.

Verify success and investigate recurring issues

Read the logs again after the restart. New errors immediately after startup are more useful than old messages without a time reference:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log

Then open the dashboard, Log Viewer, and a non-critical page. Restrict any temporary SSH or Device Access permissions again to the intended administrator sources.

If the issue returns, the service restart was only a short-term recovery. The root-cause analysis should then cover:

free partition space, local reports, and database status;
CPU and RAM utilization and unusual system logs;
concurrent administrator sessions or intensive packet capture use;
active or failed Central tasks;
HA role, synchronization, and the affected node;
configuration, certificate, interface, or Device Access changes immediately before the issue.

Manage Sophos Firewall storage and reports helps with storage and reporting issues. Changes made before the outage can be traced with Sophos Firewall Audit Trail logs.

A short operations note prevents a recurring issue from being handled with repeated restarts alone:

Date, time, and time zone:
Firewall and HA node, if applicable:
SFOS version and build:
Symptoms:
Logs checked:
Command run:
Result and next action:

If WebAdmin is still unavailable

If a service remains STOPPED or DEAD, the restart returns an error, or the issue returns immediately, save tomcat.log, apache.log, error_log.log, the system state, and the CTR for analysis with Sophos Support. Restarting additional services at random is more likely to degrade the evidence.

If neither WebAdmin nor SSH is accessible, the available recovery path depends on the environment: the local console through a console cable or Micro-USB on supported models, Sophos Central, a prepared HA fallback, or a planned reboot. At remote sites, identify who can gain local access if the firewall does not start successfully. In an HA cluster, do not initiate an unverified failover solely because WebAdmin is unresponsive while production traffic continues to flow normally.

A complete reboot is more invasive than restarting the affected services. Consider it only when several core services are affected, the firewall remains unstable, a firmware or hotfix process requires it, or Sophos Support instructs it. First confirm the backup, maintenance window, and effects on VPN, routing, RED, wireless, and published services. Plan Sophos Firewall backup and restore correctly explains the preparation.