Sophos Firewall start onverwacht opnieuw: oorzaak controleren

Als een Sophos Firewall zonder geplande ingreep opnieuw start, moet men niet meteen nogmaals rebooten of uit voorzorg services opnieuw starten. Eerst moet duidelijk zijn of de volledige appliance echt opnieuw is gestart, of alleen WebAdmin, een afzonderlijke service of de actieve HA-rol is uitgevallen. Een geslaagde herstart kan de werking herstellen, maar verklaart de oorzaak nog niet.

⚠️ Bewijs veiligstellen vóór verdere ingrepen: Verwijder geen logs, forceer geen extra reboot, wijzig de status van auto-reboot-on-hang niet en start niet op goed geluk Debug, serviceacties, fsck, Factory Reset of Reimage. Zulke ingrepen kunnen aanwijzingen wijzigen, nieuwe onderbrekingen veroorzaken of de eigenlijke fout verhullen.

De veilige snelle aanpak is:

Noteer het tijdstip met tijdzone, de duur van de uitval en de laatste bekende correcte waarneming.
Leg vast of verkeer, WebAdmin, SSH en de lokale console tegelijk getroffen waren.
Stel in het Control Center de uptime, services, interfaces, VPN’s en bij HA de clusterstatus veilig.
Exporteer onder Log viewer > System passende gebeurtenissen en stel onder Diagnostics > System graphs het verloop veilig.
Download onder Diagnostics > Tools een CTR en sysinit.log, syslog.log en bij HA de lokale node-logs.
Lees in de Device Console uptime, build en Auto-Reboot-status:

system diagnostics show uptime
system diagnostics show version-info
system auto-reboot-on-hang show

Vergelijk bij HA de rollen, status, Last status change en uptime van beide nodes.
Controleer pas daarna de passende oorzaakstak en test de volledige productieomgeving.

system auto-reboot-on-hang show wijzigt niets. SFOS activeert deze functie standaard en kan de firewall automatisch opnieuw starten wanneer de kernel niet meer reageert. Een weergegeven enable bewijst echter alleen de geconfigureerde Recovery-Policy en niet dat een Kernel-Hang deze concrete herstart heeft veroorzaakt.

Controleren wat werkelijk is uitgevallen

De waargenomen onderbreking alleen bewijst nog geen volledige reboot. Deze vier gevallen vereisen verschillende volgende stappen:

Volledige Appliance-Reboot: De uptime begint opnieuw, meerdere services en verbindingen waren tegelijk onderbroken en SFOS heeft de systeemstart opnieuw doorlopen. Dan geldt de reboot-triage in dit artikel.
Alleen WebAdmin of een service was getroffen: De uptime loopt door en productieverkeer kan gedeeltelijk ongewijzigd blijven functioneren. Dan passen een gerichte herstart van de WebAdmin GUI of de controle van een afzonderlijke service beter dan een Appliance-Reboot.
HA-Failover: Gebruikers merken mogelijk een korte onderbreking, hoewel alleen de rollen zijn gewisseld. Uptime, rol en logs van elke node tonen of een apparaat echt opnieuw is gestart. De HA-controle volgt verderop.
Failsafe-modus: De firewall start niet normaal en toont op de console een Recovery-status. Dan is show failure-reason uit het runbook voor de Sophos Firewall Failsafe-modus het juiste eerste commando.

De uptime is daarmee een sterk bewijs voor het tijdvak van de herstart, maar geen bewijs van de oorzaak. Ook een korte stroomonderbreking, een Kernel-Hang, een firmwarefout en een geplande herstart door een beheerder zetten de uptime terug.

Bewijs na de herstart veiligstellen

Na een ongeplande reboot kunnen vluchtige gegevens al ontbreken. Toch moet men de bereikbare toestand volledig veiligstellen voordat verdere wijzigingen volgen.

Bij het incident horen minstens:

model, serienummer en platform: hardware, VM of cloud
volledige SFOS-versie met MR en build
exact tijdstip, tijdzone, duur van de uitval en frequentie
getroffen functies: verkeer, WebAdmin, SSH, console, VPN en gepubliceerde services
laatste firmware-, configuratie-, hypervisor-, storage- of stroomwijziging
huidige uptime en status van services, interfaces, VPN en HA
bij HA: getroffen node, rollen vóór en na de gebeurtenis en Peer-status
beschikbare UPS-, PDU-, hypervisor-, cloud-, switch- en monitoringgebeurtenissen in hetzelfde tijdvak

Onder Diagnostics > System graphs worden CPU, Memory, Load en Disk rond het vermoedelijke tijdstip gecontroleerd. Een afwijking kan de zoektocht beperken. Een normale actuele waarde bewijst daarentegen niet dat de belasting vóór de reboot eveneens normaal was.

Onder Log viewer > System worden start-, restart-, shutdown- en HA-gebeurtenissen tot hetzelfde tijdvak beperkt en geëxporteerd. De Log Viewer is een nuttige tijdbron, maar geen volledig bewijs van een crash. Gebeurtenissen die nog niet zijn opgeslagen, kunnen bij een hang ontbreken.

Systeemtoestand in de Device Console lezen

Naast uptime en build tonen deze alleen-lezencommando’s de huidige toestand:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk

De waarden horen samen met het tijdstip van de controle in de incidentnotitie. Ze beschrijven de toestand na de herstart en mogen niet achteraf als oorzaak worden geïnterpreteerd.

Start- en systeemlogs controleren

In de Advanced Shell kunnen de belangrijkste bestanden volledig en zonder wijziging worden gelezen:

cd /log
less sysinit.log
less syslog.log
less applog.log
less csc.log

Met q wordt less afgesloten. Binnen het bestand start /zoekterm een zoekopdracht, bijvoorbeeld /error; met n gaat men naar de volgende treffer.

sysinit.log documenteert de systeemstart.
syslog.log bevat kernel- en systeemgebeurtenissen.
applog.log en csc.log helpen interne acties en wijzigingen rond hetzelfde tijdstip te duiden.

Onder Diagnostics > Tools > Troubleshooting logs moeten dezelfde bestanden bovendien worden gedownload, zodat de originele gegevens buiten de appliance behouden blijven. Welk aanvullend logbestand bij een service hoort, legt de toewijzing van Sophos Firewall-servicelogs uit.

Daarnaast wordt onder Diagnostics > Tools > Consolidated troubleshooting report een CTR met System snapshot en All log files gemaakt. De CTR bevat de huidige systeemtoestand en veel logs in een versleuteld archief. Bij Service-Subsystem-logs zijn standaard maximaal 10'000 regels opgenomen; voor langere perioden blijven volledige afzonderlijke logs belangrijk. De volledige procedure staat onder Sophos Firewall-logs voor support veiligstellen.

Een lege logsectie sluit een crash of stroomonderbreking niet uit. Informatie die nog niet naar de schijf is geschreven, kan bij een hang verloren gaan en lokale logs kunnen roteren. Daarom zijn externe tijdbronnen en een nauwkeurige incidenttijdlijn zo belangrijk.

HA-Failover en Node-Reboot onderscheiden

Onder System services > High availability worden Health, Mode, rollen, status, serienummers en Last status change veiliggesteld. Daarnaast toont het volgende commando in de Device Console de details:

system ha show details

Daarna wordt de uptime op beide nodes gecontroleerd. Heeft slechts één node een korte uptime, dan wijst dat op een herstart van dat apparaat. Zijn de uptimes ongewijzigd maar zijn de rollen gewisseld, dan moet eerst de HA-trigger worden onderzocht, bijvoorbeeld een Monitored Port of een Peer-probleem. Een handmatige wissel van de actieve rol kan de eerdere Primary eveneens opnieuw starten; daarom hoort ook een mogelijke beheerdersingreep in de tijdlijn.

De HA-logs staan lokaal op de betreffende node en worden niet gesynchroniseerd. Op beide appliances zijn daarom minstens deze bestanden relevant:

cd /log
less ha.log
less msync.log

ha.log toont de opbouw en statuswisselingen, msync.log de synchronisatie. Forceer geen gelijktijdige herstart van beide nodes en geen extra failover ter reproductie. De volledige rol- en linkdiagnose staat onder Sophos Firewall High Availability.

Oorzaak op basis van de context beperken

Geplande herstart door beheerder of firmware

Eerst worden wijzigingskalender, onderhoudsvensters, beheerdersacties, Sophos Central-taken en meldingen met het tijdstip van de gebeurtenis vergeleken. Voorafgaande configuratiewijzigingen kunnen via de Audit Trail Logs worden geduid. Sophos Firewall maakt systeemgebeurtenissen voor een start en voor Restart of Shutdown via WebAdmin. Als e-mailmeldingen zijn ingesteld, kan het bericht in de mailbox het tijdstip en de verzendende firewall aanvullend bevestigen.

Trad de herstart op tijdens een firmware- of Hotfix-proces, dan worden bronversie, doelversie, build, updatetijdstip en fwmgmt.log veiliggesteld. Een herstart hoort bij een normale firmwarewissel; meerdere ongeplande reboots of een onverwachte build niet. Voor verdere analyse dient de procedure Sophos Firewall Firmware Update uitvoeren.

Kernel-Hang of softwarefout

Met actieve auto-reboot-on-hang kan SFOS zichzelf opnieuw starten nadat de kernel niet meer reageert. De functie verbetert de beschikbaarheid, maar laat niet in elk geval een eenduidig lokaal bewijs van de oorzaak achter. De weergegeven status wordt gedocumenteerd en tijdens de triage niet gewijzigd. Het geval wordt afgebakend met tijdstip, logs, System graphs, CTR en de exacte build.

Sophos heeft in SFOS 22.0 MR2 Build 546 meerdere onafhankelijke crash- en restartgevallen opgelost, bijvoorbeeld:

NC-180974: Kernel-Crash in sdwan_profile met HA-Failover
NC-178354: Kernel-Crash bij het matchen van SD-WAN-regels
NC-178745: automatische herstart van een HA-apparaat wegens Out-of-Memory
NC-180433: herhaalde crash bij Multicastverkeer via een VPN-tunnel

Deze Issue-IDs tonen waarom De firewall is opnieuw gestart nog geen diagnose is. Alleen als build, functie, verkeer en fouttijdstip bij het gedocumenteerde geval passen, wordt het ondersteunde upgradepad naar MR2 Build 546 of een nieuwere vrijgegeven versie gecontroleerd. Treedt de fout op deze of een nieuwere build opnieuw op, dan wordt hij niet automatisch aan dezelfde oude Issue-ID gekoppeld. De overige fixes worden in het overzicht van SFOS 22.0 MR2 geduid.

Een Kernel-Crash wordt niet opzettelijk gereproduceerd met belastingstests, Multicast, SD-WAN-wijzigingen of een geforceerde failover. Configuratie en verkeerspatronen worden gedocumenteerd en daarna samen met Sophos Support beoordeeld.

Belasting, opslagruimte of storage

Het verloop van CPU, Memory, Load en Disk kan aantonen of vóór de reboot al langer een afwijking bestond. Daarnaast noemt Sophos /log/system-monitor/cpu_trigger.log voor automatisch vastgelegde systeemtoestanden bij hoge CPU-belasting. In de SFOS 22-documentatie komt /log/system-monitor/memory_trigger.log voor hoog geheugengebruik erbij; op SFOS 21.5 mag men niet aannemen dat dit bestand bestaat.

Een volle schijf, hoge I/O-belasting en een SSD-fout zijn verschillende problemen. Reports of logs worden daarom niet op goed geluk verwijderd. Voor de alleen-lezencontrole en de voorziene opschoning dient Sophos Firewall-opslagruimte en reports controleren; de hardwaretoestand van de schijf wordt uitgelegd in Sophos Firewall SSD-gezondheid via SMART controleren.

Stroom, temperatuur of hardware

Bij een fysieke XGS worden stroomvoorziening, voedingen, UPS/PDU, racktemperatuur, luchtstroom, ventilatoren, leds, SSD en de lokale console gecontroleerd. Het ontbreken van een correcte Shutdown-trace kan bij een abrupte stroomgebeurtenis passen, maar bewijst dit niet. Doorslaggevend is de gezamenlijke tijdlijn van firewall, UPS/PDU, monitoring en omgeving.

Ook een actuele temperatuur na de reboot is slechts een momentopname. De controle van temperatuur, ventilatoren en xgs-healthmond.log legt de thermische oorzaakstak uit. Terugkerende boot-, I/O-, voeding-, NPU- of ventilatorfouten horen met de veiliggestelde gegevens in de voorbereiding van een hardware- en RMA-case.

Virtuele firewall of Cloud Appliance

Bij een VM worden ook hypervisor-events, hostherstarts, datastore-latency, snapshot- of back-uptaken, vCPU, RAM, disks en vNICs op hetzelfde tijdstip gecontroleerd. Bij AWS of Azure horen platformgebeurtenissen, instance-status en gepland onderhoud in de incidenttijdlijn.

Een host- of platformgebeurtenis kan de VM opnieuw starten zonder dat SFOS zelf de oorzaak heeft veroorzaakt. Omgekeerd bewijst een onopvallende hypervisor nog niet dat het gastsysteem foutloos is. Beide tijdlijnen worden daarom samen beoordeeld. De actuele verschillen tussen platformen en resources worden uitgelegd in Sophos Firewall als hardware, VM of Cloud Appliance.

Werking na de herstart controleren

Een bereikbare loginpagina is nog geen volledige acceptatietest. Na het veiligstellen van het bewijs worden passend bij de omgeving gecontroleerd:

Control Center zonder nieuwe waarschuwing voor services, interfaces, VPN of performance; controleer daarnaast System graphs en Notifications op afwijkingen in Memory en Disk
WAN, routing, DNS en internettoegang via het verwachte pad
belangrijke Site-to-Site- en Remote-Access-VPN-verbindingen
centrale DNAT-, WAF- of serverpublicaties
DHCP, RED en Wireless, wanneer de firewall deze services levert
bij HA: Health, rollen, synchronisatie en uptime van beide nodes
nieuwe systeem-, kernel- of hardwarefouten sinds de start

De belangrijkste echte bedrijfsstromen moeten bewust worden getest en met tijdstip worden gedocumenteerd. Blijft de uptime stabiel, dan toont dit alleen dat geen nieuwe reboot is opgetreden. De oorspronkelijke oorzaak geldt pas als opgehelderd wanneer tijdlijn, logs en platformwaarnemingen een betrouwbare verklaring opleveren.

Supportcase en toekomstige detectie voorbereiden

Een Sophos Supportticket is zinvol wanneer de reboot onopgehelderd blijft, opnieuw optreedt, een HA- of vestigingsuitval heeft veroorzaakt of wanneer er aanwijzingen voor kernel, geheugen, storage, NPU of hardware zijn. In de case horen het incidenttijdstip met tijdzone, platform, volledige build, uptime, getroffen functies, laatste wijzigingen, HA-rollen, CTR, volledige relevante logs en de externe stroom- of hypervisortijdlijn.

Voor een volgend incident verbetert voorbereide monitoring de bewijspositie:

Laat e-mailmeldingen voor System started, Restart/Shutdown en HA-statuswijzigingen afleveren.
Stuur systeem- en HA-events naar Syslog of SIEM, zodat de tijdlijn buiten de firewall behouden blijft.
Bewaak uptime en hardwaretoestand via SNMP Monitoring.
Gebruik voor UPS/PDU-, hypervisor- en cloudalarmen dezelfde tijdserver en een duidelijke vestigingsaanduiding.

Zo kan men bij de volgende gebeurtenis sneller beslissen of SFOS zelf, een afzonderlijke node, het platform of de stroom- en hardwareomgeving de uitval heeft veroorzaakt.