Sophos Firewall Service-Logs richtig zuordnen

Bei der Sophos Firewall gibt es drei wichtige Ebenen für Troubleshooting: Event Logs im Log viewer, Diagnosewerkzeuge im WebAdmin und Dienst- beziehungsweise Logdateien auf der Firewall. Der Log Viewer ist ideal für schnelle Fragen wie „wurde die Verbindung erlaubt oder blockiert?“. Die Dateien unter /log sind wichtiger, wenn ein Dienst nicht startet, ein VPN-Tunnel instabil ist, Webfilter unerwartet greifen oder der Support detaillierte Daten benötigt.

Dieser Artikel ordnet die wichtigsten Services und Logdateien nach typischen Admin-Problemen. Er hilft auch dann, wenn im Dashboard, in der Advanced Shell oder in einem Supportfall ein technischer Dienstname auftaucht und nicht sofort klar ist, welche Firewall-Funktion dahintersteckt. Namen wie zebra, warren, awed, garner oder strongswan sind im Alltag nicht selbsterklärend.

Werkzeugwahl und Voraussetzungen

Bevor man in Logdateien sucht, sollte klar sein, welches Werkzeug die schnellste Antwort liefert. Viele Fälle lassen sich bereits mit Log Viewer oder Packet Capture eingrenzen. Die Shell wird erst dann wirklich hilfreich, wenn ein Dienst selbst geprüft werden muss oder der Support detaillierte Logdaten benötigt.

Welches Troubleshooting-Werkzeug passt?

Nicht jedes Firewall-Problem beginnt mit einer Shell. Oft ist zuerst ein anderes Werkzeug schneller:

• Verbindung erlaubt oder blockiert? Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.
• Pakete kommen an, gehen aber unklar weiter? Sophos Firewall Packet Capture im WebAdmin verwenden.
• Paketmitschnitt muss länger laufen, als PCAP gespeichert oder in Wireshark analysiert werden? Sophos Firewall tcpdump: Pakete per CLI mitschneiden.
• Konfigurationsänderung als Auslöser vermutet? Sophos Firewall Audit Trail Logs prüfen.
• Änderung aus Sophos Central hängt? Sophos Central Firewall Management Task Queue prüfen.
• Reports oder Verlauf in Sophos Central benötigt? Sophos Firewall Central Reporting aktivieren und betreiben.
• Logs müssen langfristig in SIEM, SOC oder Logserver landen? Sophos Firewall Syslog an SIEM senden.
• Traffic-Flows, Bandbreitenspitzen oder Kommunikationsmuster stehen im Fokus? sFlow Monitoring auf Sophos Firewall konfigurieren.
• Dienst läuft nicht oder Support braucht Logs? Dieser Artikel.
• Lokale Logs für Sophos Support oder Avanet sichern? Sophos Firewall Logs für Support und Analyse sichern.
• Support Case vorbereiten? Sophos Supportticket eröffnen: Vorbereitung und Portal.

Die Reihenfolge ist wichtig. Der Log Viewer zeigt oft schneller, welche Regel oder welches Modul entschieden hat. Packet Capture beweist den Paketfluss im WebAdmin. tcpdump ist sinnvoll, wenn ein längerer Mitschnitt, eine PCAP-Datei oder ein sehr genauer CLI-Filter gebraucht wird. Service-Logs und Debug helfen, wenn ein bestimmter Dienst selbst das Problem ist oder wenn Daten für Sophos Support gesammelt werden müssen.

Schneller Einstieg nach Symptom

Wenn nicht klar ist, welcher Log relevant ist, hilft ein Start nach Symptom statt nach Dienstname.

• Einzelne Verbindung funktioniert nicht: Zuerst Log Viewer mit Source, Destination, Service und Uhrzeit prüfen. Danach Packet Capture, firewall_rule.log und nat_rule.log verwenden.
• VPN-Tunnel ist down oder instabil: VPN-Status, Peer-IP, Uhrzeit und Log Viewer prüfen. Danach strongswan.log, charon.log, sslvpn.log und IPsec-Diagnosedaten ansehen.
• WebAdmin, User Portal oder SSH ist nicht erreichbar: Device Access, Local Service ACL und betroffene Zone prüfen. Danach apache.log, tomcat.log, sshd.log und Packet Capture auf den Zielport verwenden.
• Webfilter, TLS Inspection oder IPS blockiert unerwartet: Log-Viewer-Modul und Policy-ID prüfen. Danach ips.log, webproxy.log, awarrenhttp.log und Packet Capture vergleichen.
• Sophos Central Aufgabe bleibt hängen: Central Task Queue und lokalen Status vergleichen. Danach centralmanagement.log, sophos-central.log und fwcm-api-executor.log prüfen.
• HA verhält sich unterschiedlich pro Node: Aktiven Node, Auxiliary Node und betroffenen Traffic-Pfad bestimmen. Danach direkt auf dem betroffenen Node anmelden und HA-Logs prüfen.
• Lokale Reports fehlen oder Speicher läuft voll: Report-Einstellungen, Speicherplatz und Central Reporting prüfen. Danach reportdb.log, garner.log und Speicherplatzanalyse verwenden.

Diese Sicht verhindert eine typische Falle: Man sucht in einer Dienstlogdatei, obwohl zuerst Regel-Matching, Device Access, NAT oder Routing bewiesen werden müsste.

Log Viewer oder Logdatei?

Den Log viewer öffnet man in der WebAdmin-Konsole oben rechts. Er aktualisiert sich automatisch, lässt sich nach Modul, Zeit, Feldwerten und Freitext filtern und kann Logs als CSV exportieren.

Troubleshooting-Logs liegen auf der Firewall im Verzeichnis /log. Zugriff erhält man über die WebAdmin-Konsole oder per SSH. Für kurze Checks funktioniert Device Management > Advanced Shell im Browser, in der Praxis ist SSH aber meistens angenehmer, stabiler und besser für längere tail, grep oder less Sitzungen geeignet. Wie man SSH sicher vorbereitet, steht in der Anleitung Sophos Firewall per SSH verbinden.

Vor längeren Shell-Sitzungen sollte klar sein, aus welchem Admin-Netz verbunden wird, ob der SSH-Fingerprint geprüft wurde und ob wirklich die Advanced Shell benötigt wird. Für viele erste Prüfungen reicht der Log Viewer oder Packet Capture im WebAdmin.

Als Faustregel hilft diese Reihenfolge:

1. Einzelner Traffic-Flow ist betroffen: Log Viewer nach Source, Destination, Service und Uhrzeit filtern.
2. Log Viewer zeigt keine Entscheidung: Packet Capture mit engem Filter starten.
3. Packet Capture zeigt Incoming, aber keinen klaren Entscheid: Rule ID, NAT ID, Firewall ID 0, Rückweg und passende Logdatei prüfen.
4. Ein konkreter Dienst wirkt instabil: Passende Datei unter /log mit tail -f beobachten.
5. Ein Fehler ist sporadisch oder braucht Support: Zeitfenster, Filter, Logarchiv und gegebenenfalls tcpdump vorbereiten.
6. Normale Logs reichen nicht: Debug nur für den betroffenen Dienst und nur kurz aktivieren.

Damit bleibt die Analyse klein genug. Man sammelt zuerst den sichtbaren Befund, wechselt dann zum Paketfluss und erst danach zu Dienstlogs oder Debug. Das reduziert die Gefahr, zu früh breite Debug-Logs zu aktivieren oder eine falsche Logdatei auszuwerten.

Logdateien in der Advanced Shell lesen

Bevor man in /log sucht, sollte der Testfall möglichst eng dokumentiert sein: lokale Zeit, betroffene Source-IP, Destination-IP, Port, Benutzer, Modul und erwartetes Verhalten. Diese Angaben machen den Unterschied zwischen einer brauchbaren Loganalyse und einer langen Suche durch alte Einträge.

1. Per SSH verbinden oder in der WebAdmin-Konsole Device Management > Advanced Shell öffnen.
2. In das Log-Verzeichnis wechseln.

cd /log

Nützliche Befehle:

tail -f firewall_rule.log
tail -f nat_rule.log
grep -i error ips.log
less strongswan.log
service -S | grep ips

Die wichtigsten Befehle aus der Advanced Shell:

• Live mitlesen: tail -f /log/<logfilename>.log, zum Beispiel tail -f /log/ips.log.
• Statische Logdatei lesen: less /log/<logfilename>.log, zum Beispiel less /log/ips.log.
• Nach Begriff suchen: grep <keyword> /log/<logfilename>.log, zum Beispiel grep error /log/ips.log.
• Dienst steuern oder Debug aktivieren: service <service>:<start/restart/stop/debug> -ds nosync, zum Beispiel service ips:debug -ds nosync.

Für Support oder eine spätere Analyse sollte man nicht nur einzelne Logzeilen kopieren. Besser sind ein klarer Zeitbereich, der reproduzierte Test, relevante Screenshots aus Log Viewer oder Packet Capture und bei Bedarf ein vollständiges Logarchiv. Lokale Logs rotieren; deshalb sollten wichtige Daten gesichert werden, solange das Ereignis noch im betroffenen Zeitraum vorhanden ist. Der Ablauf steht in Sophos Firewall Logs für externe Analyse sichern.

Troubleshooting-Logs im WebAdmin herunterladen

Nicht jede Logsammlung muss manuell per tar aus der Advanced Shell gebaut werden. Für Supportfälle gibt es im WebAdmin zusätzlich den Bereich Diagnostics > Tools > Log file details beziehungsweise die Troubleshooting-Log-Auswahl. Dort lassen sich Logdateien nach Modul auswählen und herunterladen.

In der Praxis gibt es zwei Wege:

• Einzelne Logdateien: Diagnostics > Tools > Troubleshooting logs öffnen, betroffene Logdateien auswählen und als komprimierte Datei herunterladen.
• Consolidated Troubleshooting Report (CTR): Diagnostics > Tools > Consolidated troubleshooting report verwenden, wenn Support alle Logs plus Systemzustand, Prozesse und Ressourcendaten in einem Paket benötigt.

Das ist praktisch, wenn ein Admin keine längere Shell-Sitzung öffnen möchte oder wenn nur ein klar abgegrenztes Logpaket benötigt wird. Der CTR ist dagegen besser, wenn Sophos Support einen breiten System-Snapshot braucht. Bei der CTR-Erzeugung sollte der Grund für die Erstellung kurz und nachvollziehbar eingetragen werden, zum Beispiel Ticketnummer, Zeitraum oder Fehlerbild. Der Report wird verschlüsselt heruntergeladen und enthält bei Service-Subsystem-Logs standardmässig nur eine begrenzte Anzahl Logzeilen. Vollständige einzelne Logdateien erhält man zuverlässiger über Troubleshooting logs oder direkt aus /log.

Wichtig: Ein heruntergeladenes Logpaket ersetzt nicht die Kontextdaten. Support braucht weiterhin Uhrzeit mit Zeitzone, betroffene IPs, Benutzer, Tunnelname, Regel-ID, NAT-ID und eine kurze Beschreibung, was genau reproduziert wurde.

Bei HA-Clustern muss man zusätzlich beachten: Logs und Reports werden nicht einfach zwischen Primary und Auxiliary synchronisiert. Jeder Node enthält die Logs für den Traffic und die Dienste, die er selbst verarbeitet hat. Bei Node-spezifischen Fehlern muss deshalb der betroffene Node geprüft werden.

Advanced Shell oder Device Console?

Bei Sophos Firewall gibt es zwei unterschiedliche Konsolenbereiche, die oft verwechselt werden:

• Device Console: Sophos CLI für Firewall-spezifische Befehle, zum Beispiel Routing-Priorität, IPsec-Routen oder Systemoptionen.
• Advanced Shell: Linux-nahe Shell für Dateisystem, Logdateien, tail, grep, less, service -S, Service-Neustarts und Debug-Kommandos.

Nicht jeder Befehl funktioniert in beiden Bereichen. Wenn ein Artikel ausdrücklich Device Console erwähnt, sollte der Befehl dort ausgeführt werden. Wenn es um /log, tail -f, grep, service -S oder Debug-Logging geht, ist in der Regel die Advanced Shell gemeint.

Diese Unterscheidung ist wichtig, weil viele Fehler nur dadurch entstehen, dass ein korrekter Befehl am falschen Ort eingegeben wird.

Logging muss aktiv sein

Nicht jede erwartete Information erscheint automatisch.

• In Firewall Regeln muss Log firewall traffic aktiv sein.
• In SSL/TLS inspection rules muss Logging aktiviert sein.
• Unter System services > Log settings muss definiert sein, welche Logtypen lokal, an Sophos Central oder an Syslog gesendet werden.

Für langfristige Aufbewahrung ist ein Syslog-Server oder Sophos Central Firewall Reporting sinnvoll. Wie man externe Logserver oder ein SIEM anbinden kann, steht in Sophos Firewall Syslog an SIEM senden. Für Sophos Central ist Central Firewall Reporting aktivieren der passende Ablauf.

Debug nur gezielt aktivieren

Debug-Logging ist sehr hilfreich, erzeugt aber viele Daten und kann Speicherplatz verbrauchen. Debug sollte nur für den relevanten Dienst aktiviert werden. Danach reproduziert man das Problem und deaktiviert Debug wieder.

Beispiel:

service ips:debug -ds nosync
service ips:debug -ds nosync off

Die genaue Syntax hängt vom Dienst ab. Wenn der betroffene Dienst unklar ist, sollte zuerst die passende normale Logdatei geprüft werden.

Sophos unterscheidet dabei zwei Bedienwege. In der Advanced Shell werden Dienstbefehle wie service ips:debug -ds nosync verwendet. In der Device Console gibt es zusätzlich die Befehle system diagnostics subsystems <subsystem> debug on und system diagnostics subsystems <subsystem> debug off für unterstützte Subsysteme. Diese Varianten sollten nicht vermischt werden: erst klären, in welcher Konsole man arbeitet, dann den passenden Befehl verwenden.

Das Thema Debug-Logging und grundlegende CLI-Befehle ist ausführlicher im Artikel Sophos Firewall CLI Troubleshooting: wichtige Befehle beschrieben. Für den Neustart einzelner Dienste hilft zusätzlich Sophos Firewall Services sicher neu starten.

Typische Fehler bei der Logsuche

Viele Loganalysen dauern nicht wegen fehlender Daten lange, sondern weil zu früh im falschen Werkzeug gesucht wird.

• Direkt Debug aktivieren: Erst Log Viewer, passende Logdatei und reproduzierbaren Test prüfen.
• Nur nach Fehlermeldungen suchen: Zusätzlich Source, Destination, User, Rule ID, NAT Rule ID und Uhrzeit eingrenzen.
• Packet Capture ignorieren: Wenn unklar ist, ob Pakete überhaupt ankommen oder weitergehen, früh Packet Capture verwenden.
• Central Reporting als Live-Debug verstehen: Central Reporting für Verlauf und Reports nutzen, lokale Logs für Detailanalyse.
• Support-Logs erst Tage später sichern: Logs, Uhrzeit und Reproduktionsschritte sichern, solange das Ereignis noch nachvollziehbar ist.
• Debug nach dem Test laufen lassen: Debug wieder deaktivieren und Speicherplatz kontrollieren.

Ein guter Troubleshooting-Fall hat deshalb immer drei Dinge: einen engen Test, die passende Logquelle und eine dokumentierte Uhrzeit. Ohne diese Basis sieht man zwar viele Logzeilen, aber nicht zwingend die Ursache.

Logdateien nach Funktionsbereich

Die folgenden Listen sind als Nachschlagewerk gedacht. Am besten wählt man zuerst den betroffenen Funktionsbereich und prüft dann die passende Logdatei mit einem engen Zeitfenster.

System, Management und Basisdienste

• Systemmeldungen: syslog.log; zusätzlich Zeit, Reboot und Interface-Events prüfen.
• WebAdmin Webserver: apache.log, apache_access.log; zusätzlich Device Access und Local Service ACL prüfen.
• WebAdmin Anwendung: tomcat.log; zusätzlich GUI-Fehler, hohe Last und Service-Status prüfen.
• SSH: sshd.log; zusätzlich Device Access, Source-Netz und Public-Key-Login prüfen.
• GUI/CLI Fehler: error_log.log; zusätzlich aktuelle Änderung, Browser und Admin-Aktion prüfen.
• Konfigurationsänderungen: applog.log, csc.log; zusätzlich Audit Trail und Config Studio prüfen.
• Konfigurationsdatenbank: postgres.log; zusätzlich Speicherplatz, Backup/Restore und Supportfall prüfen.
• Kommunikation zwischen Komponenten: garner.log; zusätzlich Reporting, Central Reporting und Logverarbeitung prüfen.
• API: apiparser.log, app-feedback.log; zusätzlich API-ACL, Token und Central Task Queue prüfen.
• Validierung: validation.log, validationError.log; zusätzlich fehlerhafte Objekte oder Imports prüfen.
• Lizenzierung: licensing.log; zusätzlich Lizenzstatus, Central Sync und Air-Gap-Sonderfall prüfen.
• System Updates: u2d.log, sig_update.log; zusätzlich Patternstatus, DNS/HTTPS und Speicherplatz prüfen.

Bei Management-Problemen sollte nicht nur die WebAdmin-Logdatei geprüft werden. Sehr oft entscheidet Device Access, eine Local Service ACL Exception Rule oder ein falsches Quellnetz darüber, ob WebAdmin, SSH, User Portal, VPN Portal, DNS oder SNMP erreichbar sind. Für diesen Teil ist Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren der bessere Einstieg.

Firewall, NAT und Packet Capture

• Firewall-Regel-Matching: firewall_rule.log; zusätzlich Log Viewer Modul Firewall prüfen.
• Allgemeine Firewall-Verarbeitung: fwlog.log; zusätzlich Packet Capture verwenden.
• NAT-Regeln: nat_rule.log; zusätzlich NAT Rule ID im Log Viewer prüfen.
• DNAT mit Link Load Balancing: zusätzlich dgd.log prüfen, wenn Gateway- oder Link-Auswahl beteiligt ist.
• Packet Capture im WebAdmin: pktcapd.log; zusätzlich Diagnostics > Packet capture prüfen.
• Bandwidth Management / QoS: bwm.log; zusätzlich Traffic Shaping Policy prüfen.
• Virtual Host / ältere Serverpublikation: vhost.log; zusätzlich NAT und WAF prüfen.
• Web Server Protection / WAF: reverseproxy.log; zusätzlich WAF-Regel, Hosted address und Backend-Erreichbarkeit prüfen.

Bei DNAT-Problemen immer Firewall Regel und NAT Regel gemeinsam prüfen. NAT übersetzt nur, erlaubt aber keinen Traffic. Mehr dazu: NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.

Sophos Firewall nutzt für Firewall-Verbindungen unter anderem IP tables, ARP table, IPset und conntrack. Für QoS beziehungsweise Bandwidth Management kommt IMQ zum Einsatz. Diese Information ist hilfreich, wenn man Logmeldungen oder Supportausgaben mit technischen Begriffen aus dem Linux-Netzwerkpfad sieht.

IPS, Application Control und TLS Inspection

• Intrusion Prevention: Service ips, Logdatei ips.log.
• Application Control: Service ips / Application Filter, Logdatei ips.log.
• DPI und TLS Inspection: DPI Engine, Logdatei ips.log.
• Antivirus im Netzwerkpfad: Service avd, Logdatei avd.log.
• Zero-Day Protection / Sandbox: Sandbox Service, Logdateien sandboxd.log, sessiontbl.log.
• Active Threat Response / X-Ops Threat Feeds: ATR im Netzwerkpfad; zuerst Log Viewer, je nach Modul zusätzlich ips.log.
• MDR Threat Feeds: ATR / MDR-Feed-Status, Logdatei atr.log.
• Signatur-Updates: Signature Updater, Logdateien sig_upgrade.log, sig_update.log.
• Signatur-Migration: Signature Migration, Logdatei sigmigration.log.

Viele moderne Schutzfunktionen sehen erst genug Details, wenn HTTPS entschlüsselt wird. Wenn TLS Inspection nicht greift, sind Webfilter, Application Control, IPS und Malware Scan je nach Traffic weniger aussagekräftig.

Wenn unklar ist, ob IPS überhaupt aktiv ist, welche Policy greift oder warum eine Signatur blockiert, hilft zuerst Sophos Firewall IPS einrichten und sicher testen. Danach kann man ips.log, Log Viewer und Packet Capture gezielter zusammenführen.

Wenn es um Anwendungserkennung, Application Filter oder unerwartete App-Control-Blocks geht, passt zuerst Sophos Firewall Application Control einrichten und testen.

Für Zero-Day Protection sollte man zusätzlich prüfen, ob Web Protection, TLS Inspection, Dateityp, Dateigrösse, Policy und Aktion zusammenpassen. Der passende Betriebsartikel ist Sophos Firewall Zero-Day Protection verstehen und betreiben. Für Threat Feeds passt Sophos Firewall Threat Feeds einrichten und sicher betreiben. Mehr zu TLS Inspection: TLS Inspection auf Sophos Firewall schrittweise ausrollen.

Web, Proxy, WAF und Webfilter

• HTTPS Proxy: Service awarrenhttp, Logdatei awarrenhttp.log.
• HTTPS Proxy Access: awarrenhttp Access Log, Logdatei awarrenhttp_access.log.
• Web Proxy: Logdatei webproxy.log.
• Web Categorization / Reputation: Service nSXLd, Logdatei nSXLd.log.
• Legacy HTTP/FTP Proxy: Service skein, Logdatei skein.log.
• FTP Proxy: Service ftpproxy, Logdatei ftpproxy.log.
• Web Application Firewall: Reverse Proxy, Logdatei reverseproxy.log.

Wenn Webtraffic im Log Viewer als blockiert erscheint, kann die Ursache in mehreren Modulen liegen: Web Policy, SSL/TLS inspection, Application Control, IPS oder WAF. Darum immer das konkrete Modul im Log Viewer auswählen und zusätzlich die passende Logdatei prüfen.

Sophos blockiert Webseiten der Kategorie highly objectionable criminal activity grundsätzlich und blendet den Domainnamen in Logs und Reports aus. Wenn ein Eintrag in diesem Bereich bewusst anonymisiert wirkt, kann dies also beabsichtigt sein.

Für Web-Kategorien, URL-Gruppen, Web Policies und Instant Alerts passt Sophos Firewall Web-Kategorien und Instant Alerts nutzen.

VPN

• IPsec ab SFOS v17+: Services strongswan, charon; Logdateien strongswan.log, charon.log.
• IPsec verbindungsspezifisch: einzelne IPsec Connection, Logdatei strongswan-<connection>.log.
• IPsec ältere Versionen: IPsec Service, Logdatei ipsec.log.
• IPsec Test Connection: IPsec Test, Logdatei ipsec_Test_Connect.log.
• IPsec Monitoring: IPsec Monitor, Logdatei ipsec_monitor.log.
• XFRM / route-based VPN: Service xfrmi, Logdatei xfrmi.log.
• SSL VPN: SSL VPN / OpenVPN, Logdatei sslvpn.log.
• SSL VPN Status: OpenVPN Status, Logdatei openvpn-status*.log.
• VPN Portal: Logdatei vpnportal.log.
• L2TP: Service l2tpd, Logdatei l2tpd.log.
• PPTP: PPTP VPN, Logdatei pptpvpn.log.
• VPN Zertifikate: VPN Certificate Services, Logdateien vpncertificate.log, wc_remote.log.
• Clientless SSL VPN: Clientless Access, Logdatei clientless_access.log.

Sophos Firewall verwendet strongSwan für IPsec VPN und OpenVPN für SSL VPN. Bei IPsec-Problemen sind Uhrzeit, Peer-IP, Proposal, Local/Remote Subnets, NAT-T, Routing und Firewall Regeln entscheidend.

Für IPsec-Probleme ist der Artikel Sophos Firewall IPsec Troubleshooting die bessere Schritt-für-Schritt-Anleitung. Wenn es um route-based VPN und manuelle IPsec-Routen geht, hilft IPsec Route auf Sophos Firewall erstellen.

Authentication, User Portal und SSO

• Benutzer-Authentifizierung: Access Server / AAA, Logdatei access_server.log.
• NTLM / NASM: Service nasm, Logdatei nasm.log.
• Chromebook SSO: Chromebook SSO Backend, Logdatei chromebook-sso-backend.log.
• OAuth SSO Captive Portal: Logdatei oauth_sso_captive.log.
• OAuth SSO WebAdmin: Logdatei oauth_sso_webadmin.log.
• OAuth SSO VPN: Logdatei oauth_sso_vpn.log.
• STAS: STAS / Access Server Kontext, je nach Dienstkontext und access_server.log.

Bei Benutzerregeln immer zuerst prüfen, ob der Benutzer überhaupt bekannt ist. Wenn Match known users aktiv ist und die Authentifizierung nicht funktioniert, matcht die Regel nicht.

Wenn Captive Portal mit Microsoft Entra ID SSO verwendet wird, hilft Microsoft Entra ID SSO für Sophos Firewall Captive Portal einrichten beim Abgleich von oauth_sso_captive.log, Device Access, Gruppen und späterem Regel-Matching.

DNS, DHCP und Netzwerk

• DNS Service: Service dnsd, Logdatei dnsd.log.
• DNS Grabber: Service dnsgrabber, Logdatei dnsgrabber.log.
• DNS Entity / weitere DNS-Komponenten: Services entity, eacd; Logdateien entity.log, eacd.log.
• DHCP IPv4: Service dhcpd, Logdatei dhcpd.log.
• DHCP IPv6: Logdatei dhcp6.log.
• Netzwerkdienst: Service networkd, Logdatei networkd.log.
• FQDN Hosts: Service fqdnd, Logdateien fqdnd.log, fqdndebug.log.
• Dead Gateway Detection: Service dgd, Logdatei dgd.log.
• Dynamic DNS: Dynamic DNS Client, Logdatei ddc.log.
• NTP Client: Logdatei ntpclient.log.
• IPv6 Router Advertisement: Service radvd, Logdatei radvd.log.

DNS- und DHCP-Probleme wirken oft wie Firewall-Probleme. Daher sollten zuerst IP-Adresse, Gateway, DNS-Server und die Frage geprüft werden, ob Clients die Firewall als DNS oder DHCP-Server verwenden sollen.

Wenn interne Domains nicht korrekt aufgelöst werden, ist meistens DNS request routes auf Sophos Firewall konfigurieren relevant. Für DHCP-Sonderoptionen gibt es den eigenen Artikel Sophos Firewall DHCP Options konfigurieren.

Cellular WAN

• WWAN / USB-Modem: Einstecken und Entfernen von USB-Geräten in mdev.log prüfen.
• Modem-Netzwerkkonfiguration: modembezogene Interfaces und IP-Konfiguration in networkd.log prüfen.
• USB, Modem und PPP: Syslog-Meldungen zu USB, Modem und Point-to-Point Protocol in syslog.log prüfen.

Bei Cellular-WAN-Problemen sollte man zusätzlich prüfen, ob das Modem erkannt wird, ob PIN/SIM/APN korrekt sind und ob die Firewall ein passendes Gateway erstellt.

Routing

• Static Routing: Service zebra, Logdatei zebra.log.
• Application Based Routing: Service appcached, Logdatei appcached.log.
• Redis App Cache: Redis, Log redis.
• Multicast Routing: Logdatei mrouting.log.
• BGP: Service bgpd, Logdatei bgpd.log.
• OSPF: Service ospfd, Logdatei ospfd.log.
• RIP: Service ripd, Logdatei ripd.log.
• PIM-SM: Service pimd, Logdatei pimd.log.

Bei Routing-Problemen zusätzlich Routing > SD-WAN routes, Gateways und Packet Capture prüfen. Der Policy tester ersetzt keinen echten Routing-Test.

Mehr dazu: Routing-Priorität auf Sophos Firewall anpassen.

GUI, CLI und Systemzugriff

Für WebAdmin, SSH, API und lokale Managementdienste steht die Basistabelle weiter oben unter System, Management und Basisdienste. Wenn WebAdmin oder SSH nicht erreichbar ist, nicht nur apache.log, tomcat.log oder sshd.log prüfen. Lokaler Zugriff wird über Administration > Device access und Local Service ACL gesteuert.

Mehr dazu: SSH-Verbindung zur Sophos Firewall herstellen.

Sophos Central, Heartbeat und Central Management

• Sophos Central Management: Central Management, Logdateien centralmanagement.log, sophos-central.log.
• CSC: Services csc, cschelper, csd; Logdateien csc.log, cschelper.log, csd.log.
• Security Heartbeat: Services heartbeatd, hbtrust; Logdateien heartbeatd.log, hbtrust.log.
• Heartbeat zu Central: Services fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; jeweilige Service-Logs prüfen.
• Central API Executor: Service fwcm-api-executor, Logdatei fwcm-api-executor.log.
• Active Threat Response: ATR-Kontext; je nach Version und Modul prüfen.

Bei Central-Problemen zuerst prüfen, ob die Firewall registriert ist, Central Services aktiv sind und ob DNS/HTTPS ausgehend funktioniert. Wenn eine Änderung aus Central nicht lokal ankommt, sollte man die Sophos Central Firewall Management Task Queue mit den lokalen Logs vergleichen. Ein grüner Central-Status allein beweist nicht, dass eine konkrete Policy lokal verarbeitet wurde.

High Availability

• HA Status und Konfiguration: HA Application Log, Logdatei applog.log.
• HA Pair Service: Service ha_pair, Logdatei ha_pair.log.
• HA Tunnel: Service ha_tunnel, Logdatei ha_tunnel.log.
• Conntrack Sync: Service ctsyncd, Logdatei ctsyncd.log.
• Msync: Service msync, Logdatei msync.log.

HA-Logs liegen auf dem Gerät, auf dem sie erzeugt wurden. Für Rohlogs des Auxiliary-Geräts muss man sich direkt auf dieses Gerät verbinden, zum Beispiel über dessen Admin-Port per SSH. Für konsolidierte Reports ist Sophos Central Firewall Reporting praktischer.

Mail und Anti-Spam

• Antivirus: AV Service, Logdatei av.log.
• Antivirus Updates: Up2Date AV, Logdatei up2date_av.log.
• Anti-Spam: Service sasi, Logdatei sasi.log.
• Sandbox: Service sandboxd, Logdateien sandboxd.log, sessiontbl.log.
• SMTP MTA: Service smtpd, Logdatei smtpd_main.log.
• SMTP Fehler: smtpd Error/Panic/Reject, Logdateien smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
• Legacy SMTP/S Proxy: Services awarrensmtp, awarrenmta; Logdateien awarrensmtp.log, awarrenmta.log, awarrenmta_debug.log.
• POP/IMAP Proxy: Service warren, Logdatei warren.log.

Bei Mailproblemen immer prüfen, ob MTA Mode, Firewall Regel, DNS, Zertifikate und Provider-Restriktionen zusammenpassen. Der Ablauf für Mailflow, Spool, Quarantäne und Relay ist in Sophos Firewall Mail Protection im MTA Mode einrichten beschrieben.

Sophos Firewall verwendet Avira und Sophos Antivirus. Der Anti-Spam-Dienst startet nur, wenn eine eingehende oder ausgehende Spam Policy vorhanden ist. Diese Abhängigkeit ist wichtig, wenn sasi.log leer bleibt oder der Anti-Spam-Service nicht läuft.

Wireless, RED, Hotspot und weitere Dienste

• Wireless Controller: Service awed, Logdatei awed.log.
• Wi-Fi Authentication: Service wifiauth, Logdatei wifiauth.log.
• Hotspot: Services hostapd, hotspot, hotspotd; Logdateien hostapd.log, hotspot.log, hotspotd.log.
• RED: RED Service, Logdatei red.log.
• SNMP: Service snmpd, Logdatei snmpd.log.
• Syslog Service: Logdatei syslog.log.
• Licensing: Licensing Service, Logdatei licensing.log.
• System Updates: Service u2d, Logdatei u2d.log.
• VMware Tools: Service vmtool, Logdatei vmtool.log.
• SMB-Filesystem: Services smbnetfs, snireport; Logdateien smbnetfs.log, snireport.log.

Bei Lizenz-, Air-Gap- oder Pattern-Problemen sind licensing.log und u2d.log die ersten technischen Anlaufstellen. Für den Betriebsablauf mit Lizenzdatei, 180-Tage-Fenster und manuellen Pattern-Updates passt Sophos Firewall Air-Gap-Lizenzierung und Pattern-Updates betreiben.

Datenbank und Reporting

• Configuration database: Config DB, Logdateien confdbstatus.log, crreportdb.log.
• Postgres: Service postgres, Logdatei postgres.log.
• Signature database: Service sigdb, Logdatei sigdb.log.
• Report database: Report DB, Logdatei reportdb.log.
• Migration database: Report Migration, Logdateien sac-feedback.log, reportmigration.log.
• Garner: Service garner, Logdatei garner.log.
• iView: Service iview, Logdatei iview.log.

Wenn Reports fehlen, langsam sind oder Speicherplatzprobleme auftreten, sind Reporting- und Datenbanklogs relevant. Zusätzlich sollte man prüfen, ob Reports lokal gespeichert oder an Sophos Central gesendet werden.

Analyseablauf

1. Problem genau notieren: Uhrzeit mit Zeitzone, Client, Ziel, Port, User, Aktion.
2. Entscheiden, ob es um Traffic, Dienststatus, Konfigurationsänderung oder Central-Synchronisation geht.
3. Im Log Viewer nach Source IP, Destination IP, Modul und Uhrzeit filtern.
4. Sichtbarkeit von Firewall Rule ID, NAT Rule ID, User, Gateway und Policy IDs prüfen.
5. Packet Capture nutzen, wenn Paketfluss, Rückweg oder NAT-Sicht unklar ist.
6. Passende Logdatei mit tail -f, less oder grep prüfen.
7. Problem reproduzieren und den exakten Testzeitpunkt dokumentieren.
8. Wenn nötig Debug nur für den betroffenen Dienst und nur kurz aktivieren.
9. Debug wieder deaktivieren und Speicherplatz prüfen.
10. Logs sichern, solange der Fehler frisch reproduziert wurde.

Für Supportfälle sollte man ausserdem alle Fehlermeldungen, Reproduktionsschritte und bereits ausgeführten Troubleshooting-Schritte dokumentieren. Genau diese Informationen beschleunigen Supportfälle deutlich. Der passende Ablauf steht in Sophos Supportticket eröffnen: Vorbereitung und Portal.

FAQ