Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Replies 7 replies
  • Subscribers 10 subscribers
  • Views 758 views
  • Users 0 members are here
Options
Suggested

Nach Herunterfahren der Sophos 136 XGS im HA keine Reaktion mehr [SFOS 20.0.1 MR-2-Build378]

Patrick81

Hallo liebe Community,

ich würde sehr gerne einmal meinen Einsatz beim Kunden Vorort beschreiben, von Samstag den 10.08.2024.

Der Kunde hat wie oben im Titel zu sehen zwei Sophos 136 im HA, der besagte Kunde hat neue Gebäude gekauft in der nähe seiner alten Firmen Gebäude. Der neue Serverraum liegt Zentraler, ist größer und besser Klimatisiert, daher haben wir vor Wochen die Entscheidung gefasst, alle Server (außer Backup-Server) sowie die 3 Internetanschlüsse, sowie die beiden Sophos in den neuen Serverraum zu verfrachten.

Am Samstag war es dann soweit. Ich habe beide Sophos, erst die Sekundäre, dann die Primäre "anständig" herunter gefahren über die Weboberfläche. Da ich nichts riskieren wollte. Die Infrastruktur des Kunden ist enorm komplex und diese Sophos wäre im Fall eines Falles nicht mal eben in 5 oder 10 Stunden neu konfiguriert!

Vor dem runterfahren der Sophos, habe ich nochmal eine Sicherung gezogen, sowie aktuelle Sicherungen in Sophos Central vorhanden waren.

Als wir die Sophos dann im neuen Serverschrank eingebaut, vernetzt und hochgefahren hatten, sah alles gut aus, alle Link LEDs die leuchten sollten, waren auch am leuchten. Als ich dann auf die Sophos zugreifen wollte, zwecks Kontrolle der Netze, hat die GUI keinerlei Reaktion mehr gezeigt! Es war kein Ping möglich, nichts mehr!

Weder die Primäre Sophos, noch die Sekundäre Sophos, einzeln, oder zusammen haben irgend eine Reaktion gezeigt! Via SSH Putty ging natürlich auch nicht, wie den auch wenn nicht mal ein Ping beantwortet wird.

Gott sei dank, hatte ich auf meinem Notebook schon die COM Schnittstelle für die Sophos installiert und noch mehr glück war gewesen, das ich tatsächlich ein Micro-USB Kabel bei hatte......

Ich konnte sehen, das die Sophos ganz normal hochfährt, dann habe ich die Netzkonfiguration aufgerufen, es war alles da und vollkommen korrekt! Es gab keinen Grund für das oben beschriebene Verhalten!

Ich habe nach einer Anleitung eine Allgemeine Regel erzeugt, danach ging der Ping wieder, weiter habe ich in der ZSL auf allen Zonen HTTPS/Admin Zugriff erlaubt. Dennoch war immer noch kein Zugriff via GUI möglich, egal aus welchen der 7 Netze.

Vor lauter Verzweiflung habe ich mich an ein Wochenende erinnert, wo ich zum testen an meiner Sophos zu Hause, Wiederherstellung  getestet habe. dann habe ich zum Spaß meine Sophos mal auf eine ältere Firmware zurück gesetzt von SFOS 20.0.1 MR-1-Build342 auf die 20.0.0. Nach dem zurück stellen auf die älter Firmware, habe ich verstanden, das die Sophos die Konfig auf die nächste Version migriert. ERGO: Habe ich Einstellungen in der Firmware SFOS 20.0.1 MR-1-Build342 getroffen und boote dann auf die 20.0.0 um, sind die Regeln die ich in der SFOS 20.0.1 MR-1-Build342 angelegt habe weg!

Der Kunde hatte auch die Version SFOS 20.0.1 MR-1-Build342 drauf, vor lauter Verzweiflung, nach einem 12 Stunden Arbeitstag, habe ich die Firmware umgebootet auf die Version 20.0.0. Ich wusste das es keine Regelanpassung seit der Version 20 gab, also konnte auch nichts "weg" sein.

Und siehe da!!!!!!! Die Beiden Sophos liefen GANZ normal!!!!!  Im Anschluss habe ich dann von der Version 20.0.0 auf die Version  SFOS 20.0.2 MR-2-Build378. geupdatet. Da wurde die Konfig dann wieder hoch Migriert und beide Sophos liefen normal auf der neusten Firmware.

An der Stelle an Sophos direkt -> SOWAS DARAF NICHT PASSIEREN!! Wir haben NICHTs falsch gemacht, hätten wir die Sophos einfach aus dem Strom gezogen, OK! Fair, da kann wirklich mal was in die Hose gehen. In dem Fall habe ich nur mit dem Thema Sophos instand setzen, knapp 5 Stunden beim Kunden zusätzlich verbracht!!

Eigentlich wären wir nach 7 Stunden mit allem fertig gewesen, so war es ein 12 Stunden Arbeitstag +1 Stunde Anfahrt + 1 Stunde Abfahrt = 14 Stunden. Ich empfinde das wirklich als extrem bedrückend. Ich bin auch nicht mehr der jüngste und nach 14 Stunden Arbeiten, ist nur noch Grütze im Gehirn und es fällt einem nochmal schwerer solche Probleme zu lösen.

Warum ich hier das ganze nun geschrieben habe, weiß Jemand wie das passieren kann? Oder ist die HA Lösung gegeneinander gelaufen beim starten der Sophos und haben sich untereinander "abgeschossen" ? Ich habe keinerlei Erklärung dafür.......

Vielleicht ist hier jemand so dicht an Sophos dran, der mir das erklärt.....

Vielen Dank vorab, an alle die sich hier immer soviel Mühe geben.

LG

Patrick



Added TAGs
[edited by: Erick Jan at 3:25 PM (GMT -7) on 12 Aug 2024]
Parents Reply Children
  • 0 in reply to LuCar Toni

    Hallo Toni, vielen lieben Dank ID kommt.

      Du armer Kerl, das vom am Samstag wünsche ich keinem! Mein Stresslevel war echt hoch und habe die Welt nicht verstanden.

    Nachtrag: Ich habe ja nicht mal wiederhergestellt, sondern nur die Firmware "umgebootet", aber kommt wohl aufs gleiche Ergebnis.....In diesem Fall

  • 0 in reply to Patrick81

    Also ich muss sagen, es ist ziemlich verwirrend, was hier passiert ist.

    Beide Appliances wurden mehrfach immer wieder neugestartet und der HA Daemon ist immer wieder von A nach B gesprungen und zurück.

    Es gab keine AUX-AUX Situation, ob es eine Primary,Primary situation gab, kann ich so nicht sagen, da die Appliances beide immer wieder manuell via Power Knopf neugestartet wurde. 

    Was super auffällig ist: Alle Dienste der Firewall selbst konnten auch nicht das Internet erreichen. Ihr habt mehrere Interfaces, die als WAN dienen. Für mich sieht das so aus, als wäre die Verkabelung oder Switche oder ähnliches am blockieren gewesen.

    Das GW Monitoring hat alle Interfaces von beiden Appliances (Immer wenn die jeweilige Appliance Primary war) offline genommen. Zum Beispiel die aktuelle Primary hat um 14:17 (UTC+0) die Aufgabe übernommen, und sofort alle Interfaces nach WAN offline genommen, da die Interfaces nicht erreichbar waren. 

    So etwas deutet häufig darauf hin, dass die Interfaces zwar Up waren, jedoch keine Kommunikation darüber funktioniert hat. Typisches Beispiel: Virtual MAC Spoofing hat den Switch dazu verleitet, die Ports "zu beschränken". Oder die Ports waren falsch verkabelt. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Hallo Toni, danke erstmal für deine Mühe.

    Ich musste die Primäre einige male von "hand" Neustarten bis sich der Putty via COM3 verbindet. Es geht um den Zeitraum  vom ersten herunterfahren gegen 10:20/10:40 Uhr bis zum ersten hochfahren gegen 14:00/15:00 Uhr (Deutsche Zeit). Alles andere danach waren die kläglichen Versuche der wieder Inbetriebnahme. Die WAN Anschlüsse waren alle 3 (erst seit heute4) schon längst verkabelt. Sowie alle Verbindungen der LANs angelegt waren. In der Tat wurde über das VLAN  Switch zu Switch zwei Internetanschlüsse untereinander vertauscht. Das darf aber doch nicht der Grund sein?

    Aber zu keinem Zeitpunkt waren die LANs falsch verkabelt. Vor allem nach dem ich die Sophos mit der MR 20.0.0 neu gestartet habe lief alles sofort außer die beiden WAN Ports die wir vertauscht hatten. Mit der MR 20.0.0 gab es ja da auch kein Problem mit dem Booten und den beiden vertauschten wan ports. 

    PS: Sorry, noch ein Nachtrag

    Ich bin sogar mit dem Notebookdirekt an Port 1 gegangen wo das 192.168.1.X Netz Angelegt ist. Da habe ich auch keinen Zugriff bekommen oder eine Antwort auf ICMP bzw. Ping.

  • +1 in reply to Patrick81

    "Ich bin direkt an Port1 gegangen". 
    Die Frage ist, ob dann die Appliance Primary oder Aux war in diesem Szenario.

    Wenn du VLAN Fehler hattest, könnte das den ganzen Switch durcheinander gebracht haben und der via STP oder ähnliche Mechanismen die Ports abgeschaltet haben? 

    Also die Logs sind voller Reboots links und rechts, es ist schwer zu sagen, wo die Appliances waren, weil selbst im Sync Zustand wieder ein Neustart gestartet wurde etc. 

    In solchen Fällen immer folgendes machen: 
    Eine Node herunterfahren. Nur mit einer Node arbeiten. Schauen, was diese einzeln Node macht, da diese dann als Primary/Standalone arbeitet. Danach auf die Appliance zugreifen, wenn das über keinen Switch Port möglich ist, via Console auf die Firewall zugreifen und ein Wireshark / tcpdump durchführen. 
    Dort sollte man dann sehen, wo man steht: Kommen die Requests überhaupt an, wo kommen sie an etc. 
    Anhand dessen kann man sich weiter hangeln. 

    Du kannst gerne auch einen Support Case eröffnen, es wird nur schwer sein, anhand der Logs wirklich rauszufinden, was das Thema hier war. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Guten Morgen Toni, alles gut habe ich mir fast gedacht.

    Die Switches waren ja später außer vor, nach dem ich die Sophos alleine hochgefahren habe und nun mit dem Notebook dran gegen bin. bei den FS COM Switches die wir verwenden ist STP im standard deaktiviert, daher kann es das auch nicht sein. 

    Bis auf die beiden WAN Anschlüsse hättest du Verbindungen sehen müssen, mindestens 1 WAN Verbindung sowie die LANs waren korrekt verkabelt und sind mit der 20.0.0 wie beschrieben Tadellos in betrieb gegangen.

    Das von dir Beschriebene Verhalten untermauert ja nur meine Aussage, das keinerlei Kommunikation auf den Ports mehr statt gefunden hat.

    Ich danke dir für das Deeskalationsverfahren war du da unten noch beschrieben hast. Das werde ich beherzigen.

    Grüße

    Patrick

Unfiltered HTML