Nur mal eben ein Upgrade installieren…

oder

Wie mir Kaspersky völlig unnötig wertvolle Lebenszeit stahl.

Zeit für etwas Systempflege

In meiner kleinen heimischen Netzwerkinfrastruktur, in der ich auch unter anderem zwei Access Points, ein Unifi Security Gateway und einen Cloudkey Gen2+ Controller von Ubiquity betreibe, stand einmal wieder etwas Systempflege auf dem Programm.

Auf den Access Points sollte die aktuellste Firmware installiert werden. Dies habe ich in der Vergangenheit schon sehr häufig erledigt, so dass ich hier keinerlei Probleme erwartete. Es kam, wie erwartet. Die Installation verlief schnell und ohne Fehler.

Eine neue Firmware für den Controller

Im zweiten Schritt wollte ich den Controller (Cloud Key Gen2+) aktualisieren. Seit dem 17.12.2020 ist die neue Firmware in der Version 2.0.24 verfügbar und nach eingehender Recherche nach bekannten Problemen oder Gründen, dieses Upgrade (noch) nicht zu installieren, entschied ich mich für die Installation. Ein Major Release Wechsel ist immer mit gewissen Risiken verbunden, aber ich war positiv optimistisch, dass hier alles ohne Fehler oder Probleme ablaufen wird. Zuvor lud ich mir noch ein Backup der aktuellen Einstellungen herunter. Sicher ist sicher!

Ich führte danach die Installation der neuen Firmware aus und nach wenigen Minuten startete der Controller neu. Das Display begrüßte mich mit den bekannten Informationen. Auf den ersten Blick kein Fehler, keine Probleme. Alles bestens!

Natürlich ging es im letzten Schritt um die Überprüfung der Installation.
Ist alles korrekt verlaufen? Sind alle Einstellungen vorhanden und wie zeigt sich die neue Firmware nun aktuell bei mir?

Den Abend hatte ich mir irgendwie anders vorgestellt

Diese und weitere Fragen wollte ich prüfen und versuchte die Webseite des Controllers aufzurufen. Vorweg wusste ich bereits, dass die alte URL nicht mehr funktioniert, sondern von nun an https://<IPADRESSE> zum Einsatz kommen sollte.
Ich startete also wie gewohnt Google Chrome, gab die URL https://192.168.200.230 in die Adresszeile ein und …

Ich führte mehrere Versuche aus, um diese Webseite zu erreichen. Mal mit mal ohne https. Dann auch mit Hilfe von Microsoft Edge, der aber immer wieder zur selben Fehlermeldung kam. Ich suchte im Netz nach diesem Fehler und fand viele Webseiten, die alle die gleichen Lösungsvorschläge auflisteten: Proxy prüfen (nicht vorhanden), Browser Cache leeren (half nicht), WinSock Reset (brachte nichts) usw. Auch das Beenden des Virenschutzes/Firewall war erfolglos. Ich nutze auf den meisten Rechnern Kaspersky Internet Security. Ich deaktivierte die Schutzfunktionen, aber es half nichts. Der Fehler blieb – der Controller war war über den Browser nicht mehr erreichbar.

Letzte Chance – Werkseinstellungen

Für mich kam hier eigentlich nur noch ein Fehler in den Einstellungen des Controllers in Frage. Da ich zuvor ja zu wohlweißlich eine Sicherung der Einstellungen vorgenommen habe, griff ich zum letzten Mittel: Das Zurücksetzen auf Werkseinstellungen.

Mit einer Büroklammer für fünf Sekunden den Reset-Taster drücken, etwas warten und kurze Zeit später zeigte mir das Controller-Display, dass das Gerät wieder verfügbar war. Es erhielt vom internen DHCP-Server natürlich eine neue Adresse, 192.168.200.117, die ich dann im Browser eingab. Die Seite wurde angezeigt und ich war mir sicher, dass das Problem damit gelöst war. Jetzt noch schnell die alte statische IP-Adresse zuweisen und die Einstellungen aus der Sicherung zurück ins Gerät importieren…

Was zum Teufel passiert hier?

Nach Eingabe der neuen alten IP-Adresse in der Konfiguration blickt ich auf die bekannte Fehlermeldung im Browser. Der Controller war jetzt erneut nicht mehr erreichbar. Nach einem leisen, aber lauter werdenden Fluchen, begab ich mir an die weitere Fehlersuche. Ich erstelle ein neues Profil in Chrome, beendete erneut den Schutz von Kaspersky, versuchte nochmals Microsoft Edge, lud die portable Version von Firefox herunter und und und. Es war nichts zu machen. Keine Chance, die Seite wieder auf den Monitor zu bekommen.

Aber warum konnte ich die Seite aufrufen, als der Controller noch die andere IP-Adresse hatte? Das kann dann ja nichts mit dem Inhalt der Seite zu tun haben. Also irgendein Verbindungsproblem?! Die Firewall in Kaspersky KIS habe ich 10x geprüft. Sie war aus. Alle Schutzmechanismen waren deaktiviert.

Verzweifelt griff ich zu meinem Notebook, fuhr es hoch und versuchte den Controller zu erreichen. Das gelang auf Anhieb.
Ich war verwirrt. Auf dem Notebook war die gleiche Windows- und Google Chrome-Version installiert. Beide nutzen ein identisches synchronisiertes Profil. Der einzige Unterschied war das Fehlen von Kasperski Internet Security auf dem Notebook.

Nachdem ich den Controller über das Notebook geprüft habe und dort alles in bester Ordnung war, versuchte ich mich weiter an der Lösung des Problems. Denn so schnell wollte ich mich damit nicht abfinden.

Des Rätsels Lösung!

Der Fehler „ERR_CONNECTION_RESET“ weist darauf hin, dass die Verbindung hergestellt, danach aber zurückgesetzt wird. Irgendetwas funkt also dazwischen. Mir war bekannt, dass Kaspersky in SSL-Interception macht. Es bricht also den verschlüsselten Verkehr beim Aufruf von Webseiten auf, um diesen auf Viren usw. zu prüfen. Danach verschlüsselt es die Daten wieder mit einem eigenen Zertifikat.

Da das Hinzufügen des Controllers zu der Liste der vertrauten Adressen in der Kaspersky Firewall erfolglos blieb, suchte ich nach einer Möglichkeit das SSL-Interception abzuschalten. Siehe da, die Seite lies sich nun normal in Chrome aufrufen. In den Einstellungen fand ich dann die Möglichkeit, Ausnahmen zu definieren.

Fazit

Das Verhalten und die später ermittelte Ursache widersprachen sich doch sehr.
Wenn der Controller nach dem Deaktivieren von Kaspersky Internet Security erreichbar gewesen wäre, dann hätte ich wohl schon viel früher genau dort nach der Ursache gesucht. Da sich der Fehler aber weiterhin zeigte, obwohl die Software (angeblich komplett) deaktiviert war, glaubte ich anfangs nicht daran.

Zudem konnte und kann ich mir noch immer nicht erklären, warum der Controller über die dynamische IP-Adresse erreichbar war und sich das mit dem Wechsel der Adresse änderte. Warum verhält sich das SSL-Interception in Kaspersky Internet Security bei verschiedenen IP-Adressen aber gleichem Inhalt so unterschiedlich? Und warum ist diese Funktion noch immer aktiv, wenn man den gesamten Schutz deaktiviert?

Ich werde das wohl nie erfahren. Dafür bin ich jetzt trotz relativ unnötig investierter Stunden der Fehlersuche froh, dass das Problem behoben ist und die Systeme wieder fehlerfrei arbeiten.

Vielen Dank, Herr Kaspersky!