Schlagwort: NetScaler 23 Beiträge

Finding in the Wild | NetScaler 14.1: Wiederholte Reboots und nsppe-Crashes – Build 73.30 genauer anschauen

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?

Finding in the Wild | NetScaler 14.1-73.33+: Security Patch eingespielt – und plötzlich ist die ICA Session weg?

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. 😉

Finding in the Wild | Wenn Citrix HDX Direct durch einen Cipher-Mismatch ständig die Verbindung verliert!

Citrix-Sitzungen, die sich scheinbar ohne erkennbaren Grund immer wieder trennen und automatisch neu verbinden.

Die erste Vermutung?

Netzwerkprobleme, Paketverluste, Firewalls oder eine instabile UDP-Verbindung.

Doch nicht immer liegt die Ursache im Netzwerk.

🔎 Das Problem

Bei der Verwendung von EDT (Enlightened Data Transport) über HDX Direct kann es zu wiederholten Session-Disconnects und Reconnects kommen.

Besonders interessant: Die Verbindung wird grundsätzlich aufgebaut, bleibt aber nicht stabil.

Citrix dokumentiert dieses Verhalten unter der Fehlernummer CVADHELP-29336.

🛠️ Die Ursache

Ein Cipher-Mismatch bei der Verwendung von EDT über HDX Direct.

Damit liegt die Ursache nicht zwangsläufig an schlechter Netzwerkqualität, sondern an einem Problem bei der Aushandlung beziehungsweise Verwendung der Verschlüsselung.

Das macht die Fehlersuche besonders interessant, weil die Symptome zunächst stark nach einem klassischen Netzwerkproblem aussehen.

💡 Was sollte man prüfen?

✅ Verwendet die betroffene Sitzung tatsächlich EDT über HDX Direct?

✅ Treten die Disconnects ausschließlich bei UDP/EDT auf?

✅ Bleibt dieselbe Sitzung bei Verwendung von TCP stabil?

✅ Gibt es Hinweise auf Transport- oder Verschlüsselungsfehler in den Citrix-Diagnosedaten?

✅ Welche VDA-Version und welcher Cumulative-Update-Stand sind installiert?

Wichtig: Ein Wechsel auf TCP kann bei der Eingrenzung helfen, ist aber keine dauerhafte Lösung für das eigentliche Problem.

🔧 Der Fix

Citrix führt CVADHELP-29336 in den Fixed Issues von Citrix Virtual Apps and Desktops 2507 LTSR CU1 auf.

🎯 Mein Fazit

Nicht jeder Citrix-Reconnect ist ein Netzwerkproblem.

Gerade mit EDT, HDX Direct und den unterschiedlichen Transportwegen wird die Fehlersuche zunehmend komplexer.

Wenn TCP stabil läuft, EDT aber ständig Reconnects verursacht, sollte man nicht nur Firewalls und Paketverluste untersuchen, sondern auch bekannte Citrix-Transportfehler berücksichtigen.

Finding in the Wild | NetScaler SDX – LAS erfolgreich migriert, trotzdem Lizenzverlust!

Ein interessantes Known Issue aus der NetScaler-Dokumentation, das nach einer erfolgreichen Migration auf den License Activation Service (LAS) für böse Überraschungen sorgen kann.

Das Problem:

Eine NetScaler SDX wurde erfolgreich von der dateibasierten Lizenzierung auf LAS umgestellt.

✅ LAS aktiviert
✅ Lizenzierung funktioniert
✅ VPX-Instanzen laufen problemlos

Doch auf der SDX Service VM (SVM) befinden sich noch alte, dateibasierte Lizenzdateien.

Laufen diese alten Lizenzdateien ab, kann die SDX trotz erfolgreicher LAS-Migration ihre Lizenzierung verlieren!

Das kann sich auch auf die betriebenen VPX-Instanzen auswirken.

Der Workaround:

Nach erfolgreicher LAS-Migration das folgende Verzeichnis auf der SDX-SVM überprüfen:

/mpsconfig/license

Vorhandene Legacy-Lizenzdateien identifizieren und gemäß Herstellerempfehlung entfernen.

⚠️ Vorher unbedingt den aktiven LAS-Status kontrollieren und die alten Dateien sichern.

Das Gemeine daran:

Der Fehler tritt möglicherweise erst Wochen oder Monate nach der Migration auf – nämlich dann, wenn eine alte Lizenzdatei abläuft.

Bei der Fehlersuche denkt man dann vermutlich zuerst an LAS, Netzwerkkommunikation oder den Lizenzserver.

Dabei liegt die Ursache in einer längst überholten Lizenzdatei.

Citrix dokumentiert das Problem unter NSADM-128298.

💡 Mein Tipp: Bei jeder SDX-LAS-Migration die alten Lizenzdateien ausdrücklich in die Abschlussprüfung aufnehmen.

Finding in the Wild | Citrix Entra SSO – wenn die Microsoft Security Baseline die Anmeldung blockiert

Eine Citrix-Umgebung mit Microsoft Entra ID, korrekt konfiguriertem SSO und registrierten VDAs.

Die Benutzer authentifizieren sich erfolgreich an Citrix Workspace. Beim Start des Desktops erscheint jedoch erneut eine Windows-Anmeldeaufforderung oder die SSO-Anmeldung schlägt fehl.

Das Fehlerbild:

✅ Entra-ID-Authentifizierung erfolgreich
✅ VDA registriert und erreichbar
✅ Citrix-Ressourcen werden angezeigt
❌ Single Sign-on innerhalb der Sitzung funktioniert nicht

Der erste Verdacht fällt auf Entra ID, Conditional Access, Kerberos oder die Citrix-Konfiguration.

Die eigentliche Ursache kann aber in einer Microsoft Security Baseline liegen.

🔍 Root Cause

Citrix Entra SSO benötigt folgende Windows-Sicherheitseinstellung:

Allow Custom SSPs and APs to be loaded into LSASS

Die Microsoft Intune Security Baseline für Windows setzt diese Einstellung standardmäßig auf Disabled.

Damit verhindert Windows das Laden zusätzlicher Security Support Providers und Authentication Packages in LSASS.

Die für Citrix SSO benötigte Authentifizierungsintegration kann dadurch blockiert werden.

🛠️ Mein Troubleshooting-Ansatz

Ich prüfe auf dem betroffenen VDA zuerst die effektive Richtlinie:

Computer Configuration → System → Local Security Authority

Entscheidend ist:

Allow Custom SSPs and APs to be loaded into LSASS

Anschließend kontrolliere ich, ob die Einstellung über Intune, eine Security Baseline oder eine klassische GPO vorgegeben wird.

Die Lösung:

Die Einstellung auf den betroffenen Citrix-Session-Hosts gezielt auf Enabled setzen.

Wichtig: Nicht die komplette Security Baseline deaktivieren!

Ich würde dafür eine dedizierte Richtlinie beziehungsweise eine abgestimmte Ausnahme für die Citrix-VDAs verwenden.

Danach die Richtlinienübernahme kontrollieren, den VDA neu starten und SSO erneut testen.

⚠️ Security-Hinweis

Diese Änderung erlaubt das Laden zusätzlicher SSP-/AP-Komponenten in LSASS und erweitert damit bewusst die zulässige Authentifizierungsintegration.

Deshalb gehört die Ausnahme ausschließlich auf die Systeme, die diese Funktion tatsächlich benötigen.

💡 Mein Fazit

Nicht jedes Citrix-SSO-Problem ist ein Citrix-Problem.

Manchmal verhindert eine korrekt ausgerollte Security Baseline genau die Funktion, die für die gewünschte Authentifizierungsarchitektur erforderlich ist.

Security Hardening und Funktionalität müssen gemeinsam betrachtet werden – gerade bei Citrix, Entra ID und Windows.