Sophos Firewall WebAdmin GUI neu starten

Wenn die Sophos Firewall WebAdmin GUI nicht mehr erreichbar ist, muss nicht sofort die ganze Firewall neu gestartet werden. Häufig reicht es, die WebAdmin-Dienste kontrolliert über die Advanced Shell neu zu starten. Das ist deutlich weniger invasiv als ein kompletter Reboot und kann in einem Support- oder Wartungsfenster wertvolle Zeit sparen.

Typische Symptome sind:

• Die WebAdmin GUI zeigt Internal Server Error.
• Login-Seite oder Dashboard laden nicht mehr vollständig.
• WebAdmin reagiert sehr langsam oder bleibt nach einem Klick hängen.
• Andere Dienste wie Routing, VPN oder Firewall-Regeln laufen weiter.
• SSH oder lokale Konsole sind weiterhin erreichbar.

In der Praxis kann das nach hoher GUI-Last, mehreren gleichzeitigen Admin-Sitzungen, intensiver Packet-Capture-Nutzung oder allgemeinen Ressourcenproblemen auftreten. Wenn die Firewall insgesamt instabil ist, Partitionen voll sind oder mehrere Dienste ausfallen, sollte nicht nur die WebAdmin GUI betrachtet werden. Dann passen zusätzlich Sophos Firewall Services und Logs, Sophos Firewall Services sicher neu starten und Speicherplatz prüfen und Reports verwalten.

⚠️ Wichtig: Ein Service-Neustart ist ein Eingriff auf der Firewall. Vor produktiven Änderungen sollte klar sein, wer verbunden ist, ob ein Wartungsfenster nötig ist und ob ein alternativer Zugriff über SSH, lokale Konsole oder HA-Partner vorhanden ist.

Voraussetzungen

Für den gezielten Neustart benötigt man:

• Zugriff auf den Benutzer admin.
• SSH-Zugriff oder lokalen Konsolenzugriff.
• Zugriff auf die Advanced Shell.
• Ein klares Fehlerbild: WebAdmin ist betroffen, aber die Firewall muss nicht komplett neu gestartet werden.
• Möglichst ein kurzer Wartungs- oder Diagnosezeitpunkt, wenn mehrere Admins betroffen sind.

Wenn SSH noch nicht vorbereitet ist, hilft Sophos Firewall per SSH verbinden. Der Zugriff selbst wird über Administration > Device access gesteuert. Für die Absicherung von HTTPS/WebAdmin und SSH ist Device Access richtig konfigurieren der passende Grundartikel.

Vor dem Neustart kurz prüfen

Bevor Dienste neu gestartet werden, sollte man das Problem eingrenzen:

1. Prüfen, ob nur WebAdmin betroffen ist oder ob auch VPN, Routing, DNS oder Firewall-Regeln ausfallen.
2. Wenn möglich mit einem zweiten Browser oder privaten Fenster testen.
3. Prüfen, ob andere Admins gerade in der GUI arbeiten.
4. Per SSH anmelden und die Advanced Shell öffnen.
5. Optional die relevanten Logs kurz ansehen.

Die wichtigsten Logdateien sind:

Beispiel für eine schnelle Sichtprüfung:

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

Wenn die Logs für einen Supportfall gesichert werden sollen, sollte man sie vor weiteren Neustarts exportieren. Der Ablauf steht in Sophos Firewall Logs für Support und Analyse sichern.

Fehlerbild richtig einordnen

Nicht jedes WebAdmin-Problem wird durch tomcat oder apache verursacht. Vor dem Neustart hilft eine kurze Einordnung:

Diese Einordnung verhindert, dass man bei einem Netzwerk- oder Device-Access-Problem unnötig WebAdmin-Dienste neu startet. Wenn nur der Zugriff aus einem bestimmten Netz scheitert, ist Device Access und Local Service ACL auf Sophos Firewall meist wichtiger als ein Service-Neustart.

WebAdmin Dienste neu starten

Die WebAdmin GUI hängt vor allem an zwei Diensten:

In der Advanced Shell können beide Dienste nacheinander neu gestartet werden:

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

Danach einige Sekunden warten und die WebAdmin GUI erneut öffnen. Wenn die Anmeldung wieder funktioniert, sollte man trotzdem prüfen, ob im Log Viewer oder in den Systemlogs wiederkehrende Fehler sichtbar sind.

Status prüfen

Wenn der Neustart nicht ausreicht, kann man den Status der Dienste prüfen:

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

Zusätzlich kann man kontrollieren, ob die Dienste in der Serviceliste auftauchen:

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

Die allgemeine Zuordnung von Diensten, Modulen und Logdateien steht in Sophos Firewall Troubleshooting: Services und Logs. Dort ist auch erklärt, wann Log Viewer, Advanced Shell oder einzelne Logdateien die bessere Analysequelle sind.

Nach dem Neustart validieren

Wenn WebAdmin wieder lädt, ist die Störung noch nicht vollständig geklärt. Man sollte kurz prüfen, ob die GUI stabil bleibt und ob die Ursache wieder sichtbar wird.

Sinnvolle Nachkontrolle:

1. WebAdmin aus dem vorgesehenen Managementnetz öffnen.
2. Mit einem Admin-Konto anmelden und Dashboard, Log Viewer und eine unkritische Konfigurationsseite testen.
3. tomcat.log, apache.log und error_log.log erneut auf neue Fehler prüfen.
4. Speicherplatz und lokale Reports prüfen, wenn die GUI vorher langsam oder leer war.
5. Offene Admin-Sessions, Browser-Cache oder parallele Admin-Zugriffe als Ursache ausschliessen.
6. Temporär erlaubten SSH- oder Device-Access-Zugriff wieder einschränken.
7. Bei HA-Clustern prüfen, ob man auf dem erwarteten Node arbeitet.

Wenn das Problem wiederkehrt, sollte man nicht jeden Tag tomcat und apache neu starten. Dann braucht es eine Ursachenanalyse: Speicherplatz, Datenbankzustand, Reports, GUI-Fehler, Systemlast, HA-Rolle und zuletzt vorgenommene Konfigurationsänderungen. Für Änderungen kurz vor dem Fehler ist Sophos Firewall Audit Trail Logs prüfen hilfreich.

Wenn WebAdmin weiterhin nicht erreichbar ist

Wenn die GUI nach dem Neustart von tomcat und apache weiterhin nicht erreichbar ist, sollte man nicht beliebig viele Dienste neu starten. Sinnvoller ist eine strukturierte Eingrenzung:

• Device Access prüfen: Ist HTTPS/WebAdmin aus der aktuellen Zone und Quelle erlaubt?
• Browser ausschliessen: Cache, private Sitzung oder zweiter Browser testen.
• Zertifikat prüfen: Abgelaufenes oder falsches Zertifikat kann den Zugriff erschweren, erzeugt aber meist keinen echten Internal Server Error.
• Systemlast prüfen: Hohe CPU-, RAM- oder Disk-Auslastung kann WebAdmin beeinflussen.
• Speicherplatz prüfen: Volle Partitionen können GUI- und Reportprobleme verursachen.
• Logs prüfen: tomcat.log, apache.log und error_log.log nach aktuellen Fehlern durchsuchen.
• HA-Kontext beachten: Bei HA-Clustern prüfen, auf welchem Node man arbeitet und welcher Node aktiv ist.
• Letzte Änderungen prüfen: Audit Trail und Config Studio können zeigen, ob kurz vorher Device Access, Zertifikat, Interface oder Admin-Einstellungen geändert wurden.

Wenn WebAdmin und SSH nicht erreichbar sind, bleibt je nach Standort nur lokale Konsole, Sophos Central Management, HA-Failover oder ein geplanter Reboot. In produktiven Umgebungen sollte dieser Fall im Betriebs- und Recovery-Prozess vorbereitet sein.

Remote-Standorte und HA-Cluster

Bei einer einzelnen Firewall im Hauptstandort ist ein WebAdmin-Neustart meistens gut kontrollierbar. Bei Remote-Standorten oder HA-Clustern sollte man vorher genauer prüfen, über welchen Pfad der Zugriff erfolgt und welche Rückfallebene vorhanden ist.

Wichtige Fragen:

• Erfolgt der Zugriff direkt aus dem Managementnetz, über VPN, über Sophos Central oder über einen Jump Host?
• Ist SSH wirklich erreichbar, oder funktioniert nur noch eine bestehende WebAdmin-Session?
• Gibt es vor Ort jemanden, der die Appliance bei Bedarf prüfen kann?
• Bei HA: Auf welchem Node arbeitet man, und welcher Node ist aktuell Primary?
• Wird ein geplanter Failover mehr Risiko erzeugen als der gezielte Neustart von tomcat und apache?
• Sind Logs und Zeitpunkt dokumentiert, bevor ein Failover oder Reboot die Analyse erschwert?

In HA-Umgebungen sollte man nicht automatisch failovern, nur weil WebAdmin auf dem aktiven Node hängt. Wenn der Traffic weiterläuft, ist ein gezielter GUI-Service-Neustart oft weniger invasiv. Wenn dagegen mehrere Dienste betroffen sind, der aktive Node instabil wirkt oder der Zugriff vollständig verloren geht, gehört der Fall in einen kontrollierten HA- oder Standort-Recovery-Ablauf.

Wann ein kompletter Reboot sinnvoller ist

Ein Reboot ist nicht die erste Massnahme für eine hängende WebAdmin GUI. Er kann aber sinnvoll werden, wenn:

• mehrere zentrale Dienste nicht mehr reagieren
• die Firewall nach Service-Neustarts weiterhin instabil ist
• Speicher- oder Datenbankprobleme behoben wurden und ein sauberer Neustart nötig ist
• Sophos Support oder ein Wartungsfenster dies vorgibt
• ein HA-Cluster kontrolliert failovern kann

Vor einem Reboot sollten Backup, Wartungsfenster, Standortzugriff und Auswirkungen auf VPN, Routing, RED, Wireless und veröffentlichte Dienste bekannt sein.

Checkliste

• Fehlerbild dokumentiert: Internal Server Error, Timeout oder leere WebAdmin-Seite.
• SSH oder lokale Konsole verfügbar.
• Advanced Shell geöffnet.
• tomcat.log und apache.log kurz geprüft.
• service tomcat:restart -ds nosync ausgeführt.
• service apache:restart -ds nosync ausgeführt.
• WebAdmin erneut getestet.
• Bei wiederkehrenden Fehlern Speicherplatz, Device Access und Systemlogs geprüft.
• Bei produktiven Störungen Logs für Support gesichert.
• Temporäre SSH- oder Device-Access-Freigaben wieder zurückgebaut.
• Wiederkehrende Fehler nicht nur mit Service-Neustarts kaschiert.

FAQ