Speedport Pro Probleme mit UDP Kommunikation zu Citrix XenApp/XenDesktop

[#1]

Hallo Zusammen, mein alter Speedport Hybrid wurde ersetzt durch einen neuen Speedport Pro. Seither ist bei eingeschaltetem LTE keine Verbindung zu Citrix XenApp/XenDesktop Umgebungen möglich per UDP Verbindung. Alte Citrix Umgebungen die (noch per TCP) erreicht werden können funktionieren, aber neue Umgebungen über UDP scheitern direkt beim Verbindungsaufbau. Schalte ich LTE ab oder verwenden den alten Speedport Hybrid funktioniert alles wieder. Es scheint als gäbe es bei UDP-Traffic ein Problem mit dem Hybrid-Tunnel. Das initiale Firmware aus dem Februar 2019 wurde bereits aktualisiert auf die Version 120133.1.1.004.3 aus dem März 2019 - dies brachte keine Veränderung. Da verschiedene Ziele (unterschiedliche DNS Namen und IP-Adressen) angesprochen werden und immer über HTTPS Port 443 kommuniziert wird ist ein Ausnahmenregelung für eine ausschließliche DSL-Nutzung im Speedport Pro nicht sinnvoll umsetzbar. Zudem lässt sich ausgehend keine Regel explizit für UDP-Traffic einrichten. Aktuell hilft nur LTE abzuschalten wofür ich dann wiederum kein Hybrid Anschluss gebraucht hätte. Falls eine Möglichkeit bekannt ist das Problem zu lösen bitte ich um Rückmeldung. Ansonsten bitte die Infos an das Entwickler-Team des Speedport Pro weitergeben. Vielen Dank und Grüße, Michael Adam PS: das Problem scheint zudem auch Skype for Business beim Audio-Streaming vorzuliegen.

[#2]

Hallo @EternityOne,

ich habe das Verhalten an meine Kollegen aus dem Endgerätebereich weitergegeben und melde mich, sobald ich eine Antwort vorliegen habe.

Wird für die Verbindung zu den Umgebungen ein bestimmtes Programm genutzt? Dann könnte man hier ggf. über DiffServ die entsprechenden Verbindungen auf den DSL Pfad "zwingen". Unter https://telekomhilft.telekom.de/t5/Telefonie-Internet/HowTo-Game-Optimierung-an-Hybrid-Anschluessen/... findest Du dazu eine Anleitung.

Viele Grüße
Henning H.

[#3]

Hallo @Henning H., vielen Dank für die schnelle Rückmeldung und Weiterleitung. Den DiffServ-Ansatz hatte ich vorab bereits auch verfolgt um den betroffenen Datenverkehr auf ausschließliche DSL-Nutzung zu limitieren. Leider kam ich hier nicht weiter aufgrund der verwendeten Endgeräte iOS, Android und macOS. Windows wird Endgeräte, bei denen ich hier das TCP-Flag hätte setzten können, kommen im Haushalt nicht zu Einsatz. Viele Grüße, Michael Adam

[#4]

Bin nicht 100% sicher, aber ich würde spontan sagen, es könnte an der kleineren MTU bei Hybrid liegen? Meine letzten VPN-Probleme lagen zumindest daran (damals noch mit reinem ADSL). Ich weiß nicht, welche MTU der alte Hybridrouter genutzt hat, aber einen Versuch wär es wert (immerhin dürfte auch die Netzwerkverbindung neu/anders erkannt werden und damit wieder mit Standardwerten laufen).

Deine Netzwerkkarte(n) laufen vermutlich mit dem Standardwert von 1500.

Überprüfen kannst du das über eine Eingabeaufforderung und dort Eingabe von:

netsh interface ipv4 show interfaces

Wichtig ist dort nur der Eintrag zur aktiv genutzten Netzwerkkarze (zum Router bzw. Netzwerk hin).

Die MTU bedeutet eben, wie groß einzelne Datenpakete maximal sein dürfen. Weil beim Hybridzugang noch ein paar Extradaten mitgeschubbst werden müssen, sind die Pakete in Standardgröße zu groß (theoretisch auch bei regulärem ADSL, was bis zu 1492 unterstützt).

Der richtige Wert für den Speedport Pro liegt bei 1378.

Gib mal folgenden Befehl in der Eingabeaufforderung ein:

ping -l 1351 -f google.com

Bei aktivem Hybrid sollte das eine Fehlermeldung ausspucken, dass die Pakete fragmentiert werden müssten.

Mit dieser Zeile sollte es ohne Fehler klappen:

ping --l 1350 -f google.com

Der Unterschied zur Angabe 1378 oben kommt daher, dass man da noch 28 für den Header aufschlagen muss.

Zur Abhilfe führe den folgenden Befehl an einer Eingabeaufforderung mit Administratorrechten aus (bitte "NAME" mit dem richtigen Namen vom ersten Befehl oben ersetzen):

netsh interface ipv4 set subinterface “NAME” mtu=1378 store=persistent

Danach ggf. kurz Rebooten (um sicherzugehen, dass auch alle Dienste die neue Einstellung nutzen) und nochmal testen.

Falls das Problem dadurch behoben wird, bist du fertig. Falls das Problem dadurch nicht behoben wird, kannst du die Einstellung so lassen oder sie zurücksetzen, indem du den letzten Befehl wiederholst und eben 1500 als Zahlenwert einfügst. In jedem Fall sorgt das für minimale Unterschiede bei der maximalen Datenrate, aber das sollte eigentlich überhaupt nichts ins Gewicht fallen.

Edit: Mist, jetzt erst gelesen mit deinen Endgeräten, aber guck doch auch ggf. dort mal, ob du eine MTU für das Netzwerk setzen kannst - hier ebenfalls die 1378 verwenden - das  sollte eigentlich funktionieren.

[#5]

Hallo @Mario L, danke dir für die Rückmeldung und die gute Idee. Mit dem Mac hatte ich zuvor bereits die MTU herab gesetzt für einen Test und mit Wireshark überprüft. Mein gesetzte MTU von 1400 wurde sauber verwendet und Pakete wurden weder mit dieser noch mit dem Standardwert fragmentiert. Es scheint vielmehr dass Pakete komplett verschluckt werden und der Empfang meiner Rückantwort nicht funktioniert. Ich bin daher sehr gespannt was das Speedport Pro Team zu dem Thema sagen kann und hoffe hier auf baldige Rückmeldung. Viele Grüße, Michael A

[#6]

@EternityOne Interessant. Aber nur zur Sicherheit. Du hast das mit IPv4 versucht? IPv6 kennt keine Fragmentierung in der Form und stattdessen muss das der Sender im Hintergrund anpassen bzw. aufteilen, nachdem er Rückmeldung dazu bekommen hat.

[#7]

@Mario Lausschließlich via IPv4 da meine betreffenden Ziele alles nur öffentliche IPv4 Adressen sind.

[#8]

Hallo in die Runde,

leider habe ich bis dato noch keine Rückmeldung von den Kollegen. Ich bleibe aber am Ball und melde mich, sobald sich dies ändert.

Viele Grüße
Henning H.

[#9]

Hallo @EternityOne,

wir haben eine erste Rückmeldung. Der Hersteller vermutet, dass das Verhalten mit dem MTU-Wert zusammenhängt und die Pakete dadurch evtl. fragmentieren. Der MTU-Wert wird im Pro im nächsten Software-Release für den Pro angepasst. Allerdings aus anderen Gründen und deshalb kann ich nicht garantieren, dass sich dieses Problem dann auch direkt löst. Die Chancen stehen aber nicht so schlecht.

Viele Grüße
Henning H.

[#10]

Hallo @EternityOne,

ich habe Ihnen eine persönliche Nachricht geschickt.


Grüße Detlev K.

[#11]

Da ich ähnliche UDP Probleme feststelle: gab es hier eine Lösung? 

Danke euch

[#12]

Guten Abend @a.schindler und herzlich willkommen!

---

a.schindler schrieb: Da ich ähnliche UDP Probleme feststelle: gab es hier eine Lösung?

---

Der letzte Beitrag ist ja schon etwas her. Was hast du denn genau vor und welchen Router (und welche Firmware) hast du denn am Start?

Greetz
Stefan D.