network
Citrix CVAD und MTU Discovery
Update November 2022:
Martin Latteier schrieb mir, dass Citrix heimlich eine neue Funktion eingeführt hat, die das Problem behebt. Tatsache ist, dass bei bestimmten Kabelverbindungen mit DS-Lite (nur IPv6) die MTU-Ermittlung mit EDT nicht richtig funktionierte, weil das Kabelmodem das „DF-Flag“ nicht verarbeitete, was dazu führte, dass die MTU-Ermittlung eine zu hohe MTU erkannte, die Datagramme fragmentiert werden mussten und die Performance schlecht war. Die Lösung bestand bisher darin, EDT auf der Client-Seite auszuschalten oder die MTU-Erkennung auf eine statische MTU zu ändern (edtMSS=13xx).
Wenn Sie dieses Flag setzen, sollte das Problem für alle Verbidnungen gelöst sein:
Update Januar 2022:
Ich empfehle die default.ica gemäss https://support.citrix.com/article/CTX231821 nur wie unten empfohlen anzupassen wenn auch die WorkspaceApp für Mac 2201 oder höher eingesetzt wird!
In letzter Zeit traf ich öfters mal die Situation an, wo es bei der ICA Verbindungsherstellung auf virtuelle Desktops via Citrix ADC (aka Netscaler) oder virtuelle Apps im Firmennetz ab den Aussenstandorten Probleme gab. Dazu habe ich für den Fall mit den virtuellen Desktops auch einen Blogpost geschrieben: Probleme beim Zugriff auf Citrix virtual Apps und Desktops auf einem reinen IPv6 Internet Anbieter bei eingeschaltetem EDT
Der Workaround war für beide Fälle das Deaktivieren von dem UDP-basierten EDT Protokoll, welches heute bei Citrix virtual Apps und Desktops Standard ist. Das ist aber nicht so toll, weil wir möchten es nicht für alle ausschalten da es gewisse Vorteile hat. Somit mussten wir alle «Problem-Clients» entdecken und mittels Registry-Key (siehe vorangehender Blog Artikel) auf TCP umstellen.
Eine weitere Analyse der Problems ergab, dass die Ursache bei der MTU, also der maximalen Übertragungseinheit oder eben Paketgrösse liegt. In unserem Firmennetz kommt es bei der Anbindung zu Aussenstandorten aufgrund von eines Krypto-Tunnels, welches wir zu allen Aussenstandorten einsetzen, zu einer Verkleinerung der möglichen MTU was wiederum zu einer Paket-Fragmentierung führt. In gewissen Fällen ist die Fragmentierung so stark, dass der Payload nicht mehr ausreicht für die Citrix Verbindung. Es zeigt sich
, das hier EDT via UDP viel anfälliger als ICA auf TCP.Lösung 1: How to configure MSS when using EDT on networks with non-standard MTU
Im vorangehenden Blog-Post habe ich aufgerufen «Citrix fixt das» und das taten sie bereits vor meinem nörgeln… Dieser Artikel beschreibt wie man die MTU für EDT reduziert: https://support.citrix.com/article/CTX231821 z.B. auf 1480 via das default.ica
Diese Methode hat den Nachteil dass die MTU für alle Verbindungen reduziert wird, und man etwas ausknobeln muss welches denn nun die richtige MTU ist. Dafür funktioniert diese Variante für alle Plattformen ausser Android.
Lösung 2: MTU Discovery aktivieren
Eine etwas noch elegantere Variante hat sich Citrix mit dem etwas heimlichen einführen von MTU Discovery überlegt. Mit CVAD 19.12 ist es nun möglich die optimale MTU automatisch herauszufinden und zu setzen. MTU Discovery ist keine Citrix Erfindung, aber hier neu, Details zu MTU Discovery findet man hier: https://de.wikipedia.org/wiki/Path_MTU_Discovery
Ich habe versucht, dies nun bildlich etwas darzustellen:
Standartkonfiguration, MTU ist auf 1500
Standartmässig werden 1500 byte grosse Pakete versendet, ist die mögliche MTU auf dem Pfad irgendwo kleiner, wird fragmentiert, das kann funktionieren, aber es gibt in der Praxis teilweise auch Probleme.
MTU reduziert auf 1380 gemäss oben genannten Citrix Artikel (Anpassung default.ica auf dem StoreFront)
Nun werden immer 1380 byte grosse Pakete versendet.
– Ist die mögliche MTU auf dem Pfad irgendwo kleiner, wird dennoch fragmentiert, hier im Beispiel der Client aus dem Internet.
– Weiter wir unter Umständen die MTU verkleinert wo es nicht nötig ist, hier im Bild unser Client am Hauptstandort.
+ Diese Lösung funktioniert auf allen Plattformen ausser bei Android.
MTU mit MTU Discovery
(Anpassung in der Registry des VDA)
+ Mit MTU Discovery wird die MTU für jede Verbindung individuell ausgehandelt, verbunden wird mit 1024 bytes und dann wird hochgefahren. Eigentlich der beste Weg … aber es ist zu beachten, dass dafür mindestens der Virtual Desktop Agent 19.12 benötigt wird, weiter muss bei der Verbindung über ADC mindestens die Version 13.0.52.24 oder 12.1.56.22 im Einsatz sein. Wenn die ADC Version tiefer ist, klappt die Verbindung trotzdem aber der MTU Wert bleibt auf 1024 und wird nicht dynamisch wieder nach oben angepasst!
– Weiter funktioniert heute MTU Discovery nur mit der Citrix Workspace App für Windows ab der Version 19.11 (Non-Windows Geräte haben ev eine kleiner MTU Size als nötig)
Kontrolliert werden wie hoch die EDT MTU ist kann mit dem Befehl: ctxsession -v
MTU Discovery ist heute nicht per Default aktiv, sondern kann auf dem VDA mit dem setzen eine Registry Keys aktiviert werden. Details wie man da macht hier: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/technical-overview/hdx/adaptive-transport.html#edt-mtu-discovery
Update 5.6.2020 – Kombination Lösung 1 & 2
In unserem Fall haben wir für die Verbindungen via ADC eine separate Storefront Konfiguration, hier setze ich nun die MTU auf 1480 um auch macOS Computern (BYOD) gerecht zu werden, aber für Windows Computer haben wir auch die MTU Discovery aktiv:
Technische Umsetzung:
auf dem VDA: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\icawd
Name: MtuDiscovery
Type: DWORD
Data: 00000001
default.ica:
OutBufLength=1300
udtMSS=1300
edtMSS=1300
Wenn MTU Discovery aktiv ist, also eingeschaltet und ab einem Windows Client mit CWA 19.12 oder neuer zugegriffen wird, übersteuert dies auch den gesetzten Werte vom default.ica !
Wie sieht bei euch die MTU Konfiguration für Citrix mit EDT aus? Hinterlasse dazu doch ein Kommentar!
Wie sein Netzwerk innerhalb Minuten wieder online bringen mit Ubiquiti UniFi Geräten
Vor weniger als einem Monat hatte ich die Idee ein neuer WLAN Access-Point zu kaufen um die Qualität und Möglichkeiten meines Heimdrahtlosnetzwerks zu verbessern. Bis jetzt hatte ich eine Fritzbox welche für den Hausgebrauch schon sehr gut ist. Fritz macht alles, schnelles Drahtlosnetzwerk, DSL Modem, Router, Voice-over-IP, Anrufbeantworter und DECT-Basisstation. Fritz war einfach zum konfigurieren und stabil. Natürlich hätte ich mir noch paar Enterprise Features gewünscht, besonders weil ich in meinem Netz noch meine EUC Spielwiese betreiben und diverse IoT Geräte habe. Aber ehrlich gesagt waren alle mir bekannten professionellen Netzwerkgeräte ausserhalb meines Budgets.
Also war es der Plan einfach das Wifi zu verbessern, ich habe den Ubiquiti UniFi AP-AC-Pro ohne weitere Hintergedanken gekauft. Aber ganz ehrlich, es war eine Einstiegsdroge. Ich sah alle die Möglichkeiten zu einem bezahlbaren Preis und ohne zusätzliche Lizenzkosten. Ich will hier aber kein Bericht über die Ubiquiti Geräte schreiben, dazu gibt es schon einige Posts. Ein guter Post ist der von meinem CTP Kollegen Jason Samuel (englisch): Building a secure high visibility WiFi network using Ubiquiti Networks UniFi gear
Ich kann nun nur sagen dass ich mittlerweile einen Router (UniFi Security Gateway 3P) einen managed Switch (UniFi Switch 16 POE-150W) und zwei Access Points (UniFi AP-AC-Pro and UniFi AP-AC-LR) von Ubiquiti in meinem Netzwerk betreibe. Endlich kann ich mein Netzwerk segmentieren und in mehrere virtuelle Netze unterteilen (VLANs). Für mich macht es das ganze transparenter und hoffentlich sicherer, ganz sicher ist es aber einfacher zu verwalten. Aktuell habe ich 3 Drahtlos-SSIDs und 4 VLANs. Software definiertes Netzwerk ist grossartig und lässt mich dinger tun von welchen ich bisher nur träumen konnte. Wenn ich über alle die Möglichkeiten nachdenke die man machen kann, bin ich mir immer mehr sicher das man sich mehr Sorgen über die Netzwerksicherheit machen sollte … aber das ist eine andere Geschichte …
Der USG 3P, UniFi Security Gateway, kommt mit 3 Anschlüssen. WAN, LAN und Voip. Die Software wird ständig weiter entwickelt und einen Neuheiten kommen erst als Beta-Funktion rein. So auch die Möglichkeit das der Voip-Port als WAN2 definiert werden kann:
Diese Funktion macht es möglich wie der Name sagt den Voip Anschluss als zweiten WAN Link zu benutzen, entweder als Ausfallsicherung (Failover) oder als ausgewogenes LoadBalancing (Weighted LB). Natürlich ist dies für den Heimgebraucht nicht der gewöhnliche Fall, kann aber für kleinere Firmen oder Aussenbüros eine interessante Option sein.
Ich habe momentan nur eine Verbindung in’s Internet, eine Verbindung über das TV-Kabel vom Anbieter Quickline mit 250M down- und 25M Upload. Wenn das Internet mal ausfällt kann ich mir mit einem 4G Hotspot von Huawei aushelfen auf welchen ich mit meinem Laptop verbinde.
Letzten Samstag
, genau als ich mit meiner Spielwiese „rumgebastelt“ habe, ist meine Kabelinternet-Verbindung unterbrochen. Ein Neustart des Routers brachte nichts. Dann habe ich entschieden mir nun dieses oben genannte Feature genauer anzuschauen, ich hatte zwar keine zweiter Internetleitung aber eben mein 4G Router und dann kam mir in den Sinn das ich doch noch ein Zyxel Reise RouterNBG2105 in der Schublade habe. So habe ich den 4G-Wifi Router eingeschaltet, den Reise-Router darauf verbunden und diesen anschliessen mit einem Cat5-Kabel an den freien Port des USG gehängt welches ich von Voip auf WAN2 umstellte. Innerhalb 30 Minuten war ich wieder mit meinem gesamten Netzwerk zurück online.
Auf WAN2 kann also irgendwas rein kommen das Internet bietet, in meinem Fall wird eine IP per DHCP vom WiFi router zugewiesen. Natürlich musste ich die um die Verbindung vom Zyxel NBG2105 zum 4G-Wifi herzustellen das NBG2105 zuest kurz per Kabel an mein Laptop hängen. Das wichtigste bei diesem Konstrukt ist es beim NBG2105 den Schalter auf Client zu stellen.
Statt des Zyxel NBG2105 könnte hier natürlich jedes Gerät sein das aus WLAN das Internet auf LAN bringt, also auch ein RaspberryPi oder ein alter Comptuer. Oder wer es richtig machen will für eine dauernde Installation mit einer Mobile Simkarte nimmt gleich ein 4G-Router mit Kabelanschluss.
Natürlich ist die Geschwindigkeit von 4G nicht annähernd so schnell wie mein Kabelinternet, aber definitiv besser als Offline zu sein:
Auch Netflix schauen am AppleTv war kein Problem!
Und nun habe ich nicht nur die Lösung „Wie innerhalb Minuten wieder online zu sein“ sondern kann es auch für ein „bleib immer online“ verwenden.