Schlagwort: NetScaler ADC 3 Beiträge

In den letzten Wochen habe ich bei mehreren NetScaler-Umgebungen wiederholt unerklärliche Reboots bzw. Auffälligkeiten rund um die Packet Engine (nsppe) festgestellt.

Interessanterweise bin ich damit offenbar nicht allein. Auch in der NetScaler-Community berichten Administratoren aktuell von ähnlichen Fällen – teilweise mit mehreren Reboots innerhalb weniger Stunden und über mehrere Appliances hinweg.

In einem dieser Fälle soll der Citrix Support einen unerwarteten Abbruch eines Packet Engine Prozesses (nsppe) mit Signal 11 festgestellt haben. Anschließend erkannte der Supervision-Prozess den Ausfall der Packet Engine und initiierte einen Neustart der Appliance.

Besonders auffällig: Einige Ereignisse wurden zeitlich nach einem hohen Aufkommen fehlerhafter bzw. verdächtiger SSL-VPN-Requests beobachtet, darunter auch Path-Traversal-Muster.

Wichtig: Eine Kausalität zwischen diesen Requests und den nsppe-Crashes ist damit aktuell nicht bestätigt. Daraus sollte man also weder einen neuen Exploit noch eine neue Schwachstelle ableiten.

Spannend ist allerdings der aktuelle NetScaler 14.1 Build 73.30.

Die Version enthält eine ganze Reihe von Fixes – darunter auch Änderungen im Bereich der Packet Engine. Gleichzeitig berichten erste Administratoren, dass sich ihre Systeme nach dem Update auf 14.1-73.30 stabilisiert haben.

Meine Empfehlung
Wer aktuell unerklärliche NetScaler-Reboots sieht, sollte genauer hinschauen:
🔹 nsppe-Crashes und Core Dumps prüfen
🔹 /var/core kontrollieren
🔹 newnslog und Systemlogs rund um den Reboot analysieren
🔹 Zeitpunkt mit SSL-VPN-/Gateway-Traffic korrelieren
🔹 aktuellen Firmwarestand prüfen
🔹 Fixes von 14.1-73.30 gegen die eigene Umgebung bewerten

Ich würde 14.1-73.30 deshalb aktuell zumindest in die zeitnahe Upgrade-Planung aufnehmen – natürlich nach vorherigem Test.

Denn wenn die Packet Engine stirbt und die Appliance deshalb rebootet, ist „danach war sie ja wieder UP“ keine ausreichende Fehleranalyse. 😉

Mich würde interessieren: Habt ihr in den letzten Wochen ebenfalls unerklärliche Reboots oder nsppe-Crashes auf NetScaler 14.1 gesehen?

Aktuell dürften viele NetScaler-Administratoren ihre Appliances aufgrund der aktuellen Security-Themen auf 14.1-73.33 oder neuer aktualisieren.

Und natürlich gilt weiterhin:

👉 Security Updates installieren!

Allerdings steckt in den Release Notes ein kleines Detail, das man vor dem Wartungsfenster kennen sollte.

ICA Proxy Sessions können ihren Reconnect verlieren

Das Szenario:

Ein Benutzer startet seine Citrix Session vor dem NetScaler Upgrade.

Die Session läuft auf dem VDA weiter.

Der NetScaler wird anschließend auf 14.1-73.33+ aktualisiert.

Versucht der Benutzer danach, seine bestehende Session zu reconnecten:

💥 Reconnect fehlgeschlagen.

Der Grund sind die vor dem Upgrade ausgestellten Session Tickets.

Diese können nach dem Upgrade nicht mehr für den Reconnect verwendet werden. Der Benutzer muss seine Sitzung neu starten.

Die gute Nachricht:

Das ist kein generelles ICA-Proxy-Problem nach dem Upgrade.

Sessions, die nach dem Upgrade gestartet werden, funktionieren normal – inklusive späterer Reconnects.

Es ist auch keine zusätzliche Konfiguration notwendig.

Betroffen ist also der Übergang:

Pre-Upgrade Session → Upgrade → Post-Upgrade Reconnect

Warum ist das wichtig?

NetScaler HA Upgrades führen wir normalerweise mit möglichst wenig User Impact durch:

Secondary aktualisieren → Failover → Primary aktualisieren.

Dadurch könnte schnell die Annahme entstehen:

„HA Upgrade ohne Downtime = Benutzer merken nichts.“

Genau das muss hier nicht stimmen.

Die Infrastruktur kann vollständig verfügbar sein, während bestehende ICA Sessions beim nächsten Reconnect trotzdem betroffen sind.

🔥 Zero Downtime HA Upgrade ≠ Zero User Impact

Meine Empfehlung

Bei einem Upgrade auf 14.1-73.33+:

👉 bestehende ICA Sessions berücksichtigen
👉 Benutzer über möglichen Sessionverlust informieren
👉 Service Desk entsprechend vorbereiten
👉 Upgrade möglichst außerhalb produktiver Nutzungszeiten durchführen

Gerade in 24/7-Umgebungen kann dieses kleine Detail ziemlich relevant werden.

Fazit

Natürlich ist das kein Grund, ein Security Update aufzuschieben.

Aber es zeigt mal wieder:

Die interessantesten Findings stehen manchmal nicht im Security Bulletin – sondern irgendwo in den Release Notes. 😉