Deutsche GigaNetz: seltsames problem mit Citrix über VPN

    Zitat von belegdol

    DGN Kundendienst hat dagegen wieder Thema zum großen Teil verfehlt.

    Für so ein Problem auf Applikationsebene sind die auch nicht zuständig. Das können die unmöglich beurteilen.

    Zitat von belegdol

    Wenn TCP kompatibler ist, welche Vorteile bringt EDT sodass der erste Wahl sei?

    TCP ist für Tunnelprotokolle und Streaming grundsätzlich schlecht geeignet. EDT arbeitet über UDP.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von frank_m

    Für so ein Problem auf Applikationsebene sind die auch nicht zuständig. Das können die unmöglich beurteilen.

    Naja, irgendwas machen die anders. Vodafone Kabel funktioniert, Handy Hotspot über 1und1 Netz auch.

    Zitat von frank_m

    TCP ist für Tunnelprotokolle und Streaming grundsätzlich schlecht geeignet. EDT arbeitet über UDP.

    Deswegen versuche ich herauszufinden, wieso es über EDT nicht klappt. Ich habe mein Zitat vorhin zu früh abgeschnitten:

    Zitat

    MTU-Discovery schlägt möglicherweise für Benutzer fehl, die sich über ein DS-Lite-Netzwerk verbinden. Einige Modems ignorieren das DF-Bit bei aktivierter Paketverarbeitung, sodass die MTU-Discovery eine Fragmentierung nicht erkennt. In dieser Situation sind folgende Optionen verfügbar:

    • Deaktivieren Sie die Paketverarbeitung auf dem Modem des Benutzers.
    • Deaktivieren Sie MTU Discovery und verwenden Sie eine fest codierte MTU, wie unter So konfigurieren Sie MSS bei Verwendung von EDT in Netzwerken mitnicht stehender MTU beschrieben.
    • Deaktivieren Sie den adaptiven Transport, um die Verwendung von TCP für Sitzungen zu erzwingen. Wenn nur eine Untergruppe von Benutzern betroffen ist, können Sie sie möglicherweise auf der Clientseite deaktivieren, damit andere Benutzer EDT weiterhin verwenden können.

    Punkt 3 hat was gebracht, Frage wäre, ob es ein Zufall sei oder ob man irgendwie Punkt 1 versuchen kann. Entfernt vielleicht FritzBox den DF-Bit?

    Einmal editiert, zuletzt von belegdol (27. November 2024 um 22:22)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Zu viele verschachtelte Tunnel... einer propagiert Fehlermeldungen nicht vernunftig... Mach doch mal Packetcaptures mit TCP und EDT, einmal von den verschluesselten Paketen (Tunnel von aussen) einmal die unverschluesselten Pakete im Tunnel, wenn das moeglich ist.

    Zitat von pufferueberlauf

    Zu viele verschachtelte Tunnel...

    Ja, ich glaube auch, das ist das Hauptproblem. PPPOE, DS-Lite, VPN und dann noch Citrix mit seinem EDT über UDP. Da sind schnell mal 50 Byte weg.

    Ich bin mir auch gar nicht sicher, ob dieses DF Bit am Ende entscheidend ist. Da wird ein Paket auf die Reise geschickt, das für den Transport-Kanal zu groß ist. Entweder wird das DF Bit entfernt, dann wird das Paket fragmentiert, und die Anwendung kommt nicht damit zurecht. Oder das DF Bit bleibt erhalten, dann ist das Paket aber immer noch zu groß und kann nicht übertragen werden. Funktionieren wird es am Ende so oder so nicht.

    Zitat von pufferueberlauf

    Mach doch mal Packetcaptures mit TCP und EDT, einmal von den verschluesselten Paketen (Tunnel von aussen) einmal die unverschluesselten Pakete im Tunnel, wenn das moeglich ist.

    Ja, vielleicht kann man da sehen, warum die Pakete verloren gehen. Ob man der Lösung näher kommt, wird man dann sehen.

    Zitat von frank_m

    der das DF Bit bleibt erhalten, dann ist das Paket aber immer noch zu groß und kann nicht übertragen werden. Funktionieren wird es am Ende so oder so nicht.

    Was mit dem DF bit im aeusseren Tunnel passieren sollte ist, dass Hops die fragmentieren muessten statt dsessen eine ICMP Fehlermeldung an die SRC-IP Adresse schicken. Aber schon das passiert im existierenden Internet nicht zuverlaessig, und selbst wenn, muss dass dann vom VPN noch an Citrix weitergeben werden, weil es letztlich Citrix ist wo die Paketgroessen angepasst werden muessten. Path MTU discovery ist leider kaputt... bei TCP kann man sich bei den ueblichen Verdaechtigen wie PPPoE mit MSS_clamping etwas behelfen, aber das gibt es fuer UDP halt nicht...

    Einmal editiert, zuletzt von pufferueberlauf (12. September 2025 um 14:54)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Umstellung auf TCP hat dazu geführt, dass sich andere Sessions die Verbindung oft verloren haben. Wir haben es noch versucht auf EDT mit einer definierten Paketgröße - 1320 Bytes wenn ich mich nicht irre. Es hat leider nicht geholfen, die Session hängt sich wieder auf. Entweder muss die Paketgröße noch weiter runter, oder das Problem liegt woanders.

    Weiter kann ich das Thema nicht verfolgen. Hätte ich selbst Admin Berechtigungen auf beiden Enden, könnte ich vielleicht rumspielen. Wenn aber alles über IT Helpdesk laufen muss, dauert es einfach zu lange. Da ist es einfacher einfach sich über Handy Hotspot zu verbinden wenn man auf dem betroffenen Server arbeiten muss.

    Wir könnten das Problem endlich lösen - es lag in der Tat an nicht funktionierenden MTU Discovery. Lösung:

    1. Die .ica Datei vom Storefront herunterladen (InPrivate Fenster hilft)

    2. Datei im Editor öffnen und folgendes hinzufügen:

      Code
      MtuDiscovery=Off
OutBufLength=1320
edtMSS=1320
    3. Speichern und die angepasste Datei mit Citrix ausführen. Man muss relativ schnell sein, es scheinen drin zeitlich begrenzt gültige Werte zu stecken