RDP-Performance mit VPN schlecht

[soulseeker 13]

Hi zusammen,

 

wir nutzen mehrere Watchguards in unserem Unternehmen, dabei u.a. DIALin-SSLVPN und Ipsec-Tunnel ... hin und wieder auch IPsec-Dialin.

 

Leider ist die RDP-Performance relativ schlecht, man sieht bei Verbindungen zu Win2012-Terminalservern auch oben in der RDP-Leiste nur 1-2 Balken und das  ganze ist sehr laggy. Allerdings in erster Linie bei SSL-Dialin (über einen OpenVPN-Dialer) und dem IPsec-Tunnel. Die Performance ist bei IPsec-Dialin am besten, aber da haben wir nur 5 Lizenzen.

 

Ich vermute mal, dass es an der MTU liegen könnte ... ich habe diesen sowohl auf dem Client, als auch dem Server auf 1400 mit netsh interface ipv4 set subinterface xyz mtu=1400 store=persistent festgelegt, aber ich sehe keine wirkliche Änderung.

 

Muss ich die MTU sowohl eigentlich auf dem Client als auch dem antwortenden Server festlegen? Woran kann es evtl. noch liegen?

 

VG

 

Marcel

[daabm 1.387]

Du sollst die MTU eigentlich gar nicht mehr "manuell" befrickeln - das ist seit Win7 nicht mehr State of the Art. KB-Artikel dazu gibt's auch, bin grad aber zu müde zum Raussuchen... Mach lieber mal einen E2E-Trace und finde raus, wo die Zeit "vergeht".

[Doso 77]

Seit Windows Vista sollte man da nicht mehr drann rumfummeln müssen. Die tollen "Tuning Guides" machen da meist mehr kaputt als richtig.

[soulseeker 13]

Ok, das war ein Vorschlag aus dem Watchguard-Forum ... aber woran kann die lahme RDP-Performance denn sonst noch liegen?

 

Grüße

 

Marcel

[lefg 276]

Hallo,

 

was ist denn mit dem Vorschlag aus #2, eien E2E-Trace? Ich wüsste natürlich auch gerne, wie und womit macht man so etwas?

 

Wo beginnt/endet der Tunnel eigentlich, am Watchgard oder am Rechner?

 

Ich begenete MTU zum Erstenmal auf der WAN-Side eines Routers, zum Einstellen war der Datenträger mit mit dem Konfigurator nötig, im Menü der Routers war das nicht möglich. Der Standort lag ungünstig am Ende einer langen Leitung. Nun, ob es aber an der Leitung, an dem einen Ende liegen muss?

bearbeitet 22. Juni 2014 von lefg

[daabm 1.387]

E2E-Trace? Ganz einfach: Netmon/Wireshark/Message Analyzer/netsh hernehmen auf dem Client und dem Zielsystem, und dann gleichzeitig Trace starten, und dann die betreffende Anwendung (hier also RDP) starten. Und dann kommt das mühsame Korrelieren der einzelnen Pakete auf Server- und Clientseite inkl. der zugehörigen Timestamps.

[lefg 276]

Also ist es doch nicht für jedermann einfach. :)

 

Trotzdem danke dafür.

bearbeitet 22. Juni 2014 von lefg

[daabm 1.387]

Ja, so ist es - erstellen ist ganz einfach, aber das Analysieren ist - mit Verlaub - ein echter Sch*****dr*ck :mad:  Vor allem, weil Du mitunter auch noch nen Trace von einem Zwischenpunkt dazu benötigst... Und wenn dann noch "magische" Wunderkisten wie die Steelheads im Spiel sind, dann wird's vollends wahnsinnig :p

[NeMiX 76]

Also ist es doch nicht für jedermann einfach. :)

 

Trotzdem danke dafür.

Das sollte Basic für jeden SysAdmin sein. Leider wird das immer mehr vernachlässigt und dann wird blind an MTUs oder anderen Settings geschraubt, anstatt dem Problem auf den Grund zu gehen.

 

@TO: Kannst du evtl. einen Laptop direkt an einen freien Watchguard Port anschließen und dort mal RDP testen? Das wäre mein 1. schneller Ansatz um das Problem einzukreisen.

[NorbertFe 2.155]

Jeder SysAdmin sollte wissen, dass man sowas machen kann und sollte, aber nicht jeder muß das können. Dafür gibt's bei uns die Spezis aus der LAN Abteilung. ;)

[RobertWi 81]

Definitiv. Ich durfte letzte Woche mal einem erfahrenen Netzwerker über die Schulter schauen, wie der einen "Netzwerkcrash" nach einem gesteckten Loop analysiert hat. Der hat dafür nur Wireshark unter Linux benutzt (und zum Beweisen einen Zweizeiler in der Shell). Die Benutzung des Tools war kein Problem, aber die Auswertung der in 2 Sekunden bis zum Abschalten des Netzwerkes gesammelten Informationen hätte jeden Sysadmin hoffnungslos überfordert. IMHO kann man das gar nicht "lernen", dass war einfach nur Erfahrung.

[Weingeist 165]

Betreffend MTU-Size: Hatte grad letztens ein Gespräch mit nem Netzanbieter, dass manche DSL-Angebote (bevorzugt Business für Kleinkunden) mit verkorksten MTU's arbeiten, weil der Anbieter selber einen Teil davon brauchen. Auf alle Fälle kann dann die Übertragungsrate enorm sinken, wenn man an den Verbrauchern eine fixe übliche MTU eingestellt hat. So zumindest die Aussage des Anbieters. Also entweder auf die MTU des Netzanbieters einstellen oder schauen, dass diese dynamisch sein kann, was aber auch nicht immer tut.

[soulseeker 13]

Sorry, kam nicht früher zum Antworten ... die Tunnel sind WG zu WG, dahinter dann noch eine geroutete Switchlandschaft. Ich habe derzeit ein Ticket mit Watchguard offen, ich berichte, falls es was interessantes ergibt. Derzeit fällt denen leider auch nur "an der MTU rumschrauben" ein ;). Ich häng bei Gelegenheit auch mal ein Notebook direkt an einen freien Port ...