Sophos Firewall Restart WebAdmin GUI

If the Sophos Firewall WebAdmin GUI is no longer accessible, the entire firewall does not have to be restarted immediately. It is often enough to restart the WebAdmin services in a controlled manner using the Advanced Shell. This is significantly less invasive than a complete reboot and can save valuable time during a support or maintenance window.

Typical symptoms are:

• The WebAdmin GUI shows Internal Server Error.
• Login page or dashboard no longer load completely.
• WebAdmin responds very slowly or hangs after a click.
• Other services such as routing, VPN or firewall rules continue to run.
• SSH or local console are still accessible.

In practice, this can occur after heavy GUI load, multiple concurrent admin sessions, heavy packet capture usage, or general resource issues. If the firewall is generally unstable, partitions are full or several services are down, the WebAdmin GUI should not be the only thing to consider. Then Sophos Firewall Services and logs, Sophos Firewall Safely restart services and Check storage space and manage reports also fit.> ⚠️ Important: A service restart is an intervention on the firewall. Before making productive changes, it should be clear who is connected, whether a maintenance window is necessary, and whether alternative access via SSH, local console, or HA partner is available.

Requirements

For a targeted restart you need:

• Access to user admin.
• SSH access or local console access.
• Access to the Advanced Shell.
• A clear error picture: WebAdmin is affected, but the firewall does not have to be restarted completely.
• As short a maintenance or diagnostic time as possible if several admins are affected.

If SSH is not yet prepared, Sophos Firewall connect via SSH will help. The access itself is controlled via Administration > Device access. Configure Device Access correctly is the right basic article for securing HTTPS/WebAdmin and SSH.

Check briefly before restarting

Before restarting services, you should isolate the problem:

1. Check whether only WebAdmin is affected or whether VPN, routing, DNS or firewall rules are also failing.
2. If possible, test with a second browser or private window.
3. Check whether other admins are currently working in the GUI.
4. Log in via SSH and open the Advanced Shell.
5. Optionally, briefly view the relevant logs.

The most important log files are:

• WebAdmin web server: /log/apache.log and /log/apache_access.log.
• WebAdmin Application: /log/tomcat.log.
• GUI/System Error: /log/error_log.log.

Example of a quick visual inspection:

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

If you want to back up the logs for a support case, you should export them before further restarts. The process is in Sophos Firewall Back up logs for support and analysis.

Classify the error pattern correctly

Not every WebAdmin problem is caused by tomcat or apache. Before restarting, a brief classification will help:

Typical classification:

• WebAdmin shows Internal Server Error: Often it is due to the GUI application or web server. Check tomcat.log and apache.log and restart services specifically.
• Browser reports certificate warning: First check certificate, name and trust chain, do not restart services directly.
• Connection is running in timeout: Then Device Access, routing, ACL, VPN or management network are more likely. Check availability and Administration > Device access.
• Login works, dashboard hangs afterwards: Check GUI load, session, reports, memory or database.
• WebAdmin and SSH are not accessible: Then it’s more about access path, Device Access or system status. Check local console, HA partner or central management.
• Several services fail at the same time: This suggests a system problem rather than a pure GUI problem. Back up logs, check storage space and evaluate reboot or support case.

This classification prevents WebAdmin services from being restarted unnecessarily in the event of a network or device access problem. If only access from a specific network fails, Device Access and Local Service ACL to Sophos Firewall is usually more important than a service restart.

When is it better to postpone the restart

Restarting tomcat and apache is relatively targeted, but is still an intervention in the administrative level of the firewall. In these situations, you should first briefly stabilize or document:

• Firmware update, hotfix or pattern update is running: Do not intervene in WebAdmin services at the same time as long as the update process is active.
• HA cluster is currently synchronizing: Check HA role, synchronization and active node first.
• Support debug or log collection is running: First save relevant logs, then restart services.
• Central task is currently active: Check task queue so that an ongoing central change is not mixed with a local GUI problem.
• Only one admin browser is affected: Test private session, second browser or other client first.

This short brake saves explanation work later. If it is no longer clear immediately after a restart whether the error came from WebAdmin, Central, HA or an ongoing update, the analysis becomes unnecessarily difficult.

Restart WebAdmin services

The WebAdmin GUI depends primarily on two services:

• tomcat: WebAdmin application.
• apache: WebAdmin web server.

In the Advanced Shell both services can be restarted one after the other:

service tomcat:restart -ds nosync
service apache:restart -ds nosync

Then wait a few seconds and open the WebAdmin GUI again. If the login works again, you should still check whether there are recurring errors visible in the Log Viewer or in the system logs.

Check status

If restarting is not enough, you can check the status of the services:

service tomcat:status -ds nosync
service apache:status -ds nosync

You can also check whether the services appear in the service list:

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

The general assignment of services, modules and log files is in Sophos Firewall Troubleshooting: Services and Logs. It also explains when Log Viewer, Advanced Shell or individual log files are the better analysis source.

Validate after reboot

If WebAdmin loads again, the problem has not yet been completely resolved. You should briefly check whether the GUI remains stable and whether the cause becomes visible again.

Useful follow-up check:

1. Open WebAdmin from the intended management network.
2. Log in with an admin account and test dashboard, Log Viewer and a non-critical configuration page.
3. Check tomcat.log, apache.log and error_log.log again for new errors.
4. Check storage space and local reports if the GUI was previously slow or empty.
5. Exclude open admin sessions, browser cache or parallel admin access as the cause.
6. Temporarily restrict permitted SSH or device access access again.
7. For HA clusters, check whether you are working on the expected node.

If the problem recurs, you should not restart tomcat and apache every day. Then a root cause analysis is needed: storage space, database status, reports, GUI errors, system load, HA role and recent configuration changes. For changes shortly before the error, Sophos Firewall Check audit trail logs is helpful.

If WebAdmin is still unavailable

If the GUI is still unavailable after restarting tomcat and apache, you should not restart as many services as you like. A structured limitation makes more sense:

• Check Device Access: Is HTTPS/WebAdmin allowed from the current zone and source?
• Exclude browser: Test cache, private session or second browser.
• Check certificate: An expired or incorrect certificate can make access more difficult, but usually does not produce a real internal server error.
• Check system load: High CPU, RAM or disk usage can affect WebAdmin.
• Check disk space: Full partitions can cause GUI and reporting problems.
• Check logs: Scan tomcat.log, apache.log and error_log.log for current errors.
• Note HA context: For HA clusters, check which node you are working on and which node is active.
• Check recent changes: Audit Trail and Config Studio can show whether Device Access, certificate, interface or admin settings were changed recently.

If WebAdmin and SSH are not accessible, depending on the location, only local console, Sophos Central management, HA failover or a planned reboot are left. In productive environments, this case should be prepared in the operation and recovery process.

Remote sites and HA clustersWith a single firewall in the main location, a WebAdmin restart is usually easy to control. For remote locations or HA clusters, you should check in more detail beforehand which path the access takes place and which fallback level is available.

Important questions:

• Is access directly from the management network, via VPN, via Sophos Central or via a jump host?
• Is SSH really accessible, or does only an existing WebAdmin session work?
• Is there someone on site who can check the appliance if necessary?
• For HA: Which node are you working on and which node is currently primary?
• Will a planned failover create more risk than the targeted restart of tomcat and apache?
• Are logs and time documented before a failover or reboot makes analysis difficult?In HA environments, you shouldn’t automatically failover just because WebAdmin is hanging on the active node. If traffic continues, a targeted GUI service restart is often less invasive. However, if multiple services are affected, the active node appears unstable or access is completely lost, the case belongs in a controlled HA or site recovery process.

When a complete reboot makes more sense

A reboot is not the first measure for a hanging WebAdmin GUI. But it can be useful if:

• several central services no longer respond
• the firewall remains unstable after service restarts
• Memory or database issues have been resolved and a clean boot is required
• Sophos Support or a maintenance window specifies this
• an HA cluster can failover in a controlled manner

Before rebooting, backup, maintenance windows, location access, and impact on VPN, routing, RED, wireless, and published services should be known.

Checklist- Error image documented: Internal Server Error, timeout or empty WebAdmin page.

• SSH or local console available.
• Advanced Shell open.
• tomcat.log and apache.log briefly checked.
• service tomcat:restart -ds nosync executed.
• service apache:restart -ds nosync executed.
• WebAdmin tested again.
• Checked storage space, Device Access and system logs for recurring errors.
• Logs saved for support in the event of productive disruptions.
• Checked ongoing updates, HA synchronization, central tasks or support debug before restarting.
• Temporary SSH or device access shares have been removed again.
• Recurring errors are not just hidden with service restarts.

FAQ