27
Standortabhängige Probleme mit einer Remotedesktopverbindung
Habe ein merkwürdiges Problem mit der Remotedesktopverbindung und wäre sehr dankbar, wenn jemand mir einen Tipp geben könnte!
Im Betrieb haben wir einen PC mit Windows 10, der über eine Remotedesktopverbindung bedient werden soll.
Wenn ich diesen von Zuhause aus versuche zu erreichen, klappt dies immer einwandfrei.
Wenn ich mein Notebook zu meinem Kollegen mitnehme und versuche es bei ihm, klappt das nur, wenn der PC im Betrieb neu gestartet wurde.
Hat jemand eine Erklärung?
Im Betrieb haben wir einen PC mit Windows 10, der über eine Remotedesktopverbindung bedient werden soll.
Wenn ich diesen von Zuhause aus versuche zu erreichen, klappt dies immer einwandfrei.
Wenn ich mein Notebook zu meinem Kollegen mitnehme und versuche es bei ihm, klappt das nur, wenn der PC im Betrieb neu gestartet wurde.
Hat jemand eine Erklärung?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7193519309
Url: https://administrator.de/contentid/7193519309
Ausgedruckt am: 24.11.2024 um 18:11 Uhr
27 Kommentare
Neuester Kommentar
WIE greifst du denn auf diesen Rechner von Remote zu??
Für eine für dich hilfreiche Antwort braucht es ein paar mehr technische Details. Das weisst du als guter Administrator ja alles auch selber.
- Die gefährliche und fahrlässige Variante und ungeschützt über simples UDP/TCP 3389 Port Forwarding am Router oder...
- wie es generell üblich ist, gesichert per VPN?
- Wie ist die lokale Firewall an diesem Rechner eingestellt?
- Wichtig wäre noch zu wissen ob der Kollege einen DS-Lite Provider Anschluss zuhause hat. Auch dazu machst du keinerlei hilfreiche Angaben.
Für eine für dich hilfreiche Antwort braucht es ein paar mehr technische Details. Das weisst du als guter Administrator ja alles auch selber.
Dass man keine RDP Verbindung aufbauen kann, dafür würden mir auch einige Gründe einfallen, eben abhängig von der Verbindungsart, so wie von aqui beschrieben.
Allerdings alle diese möglichen Fehlerquellen lassen sich normalerweise nicht mit einem Neustart des Zielrechners beheben. Das finde ich schon noch speziell.
Ist es denn so, dass der Zielrechner oder eine Software darauf in irgendeiner Form crasht? Dies müsste ja in den Logs ersichtlich sein.
Allerdings alle diese möglichen Fehlerquellen lassen sich normalerweise nicht mit einem Neustart des Zielrechners beheben. Das finde ich schon noch speziell.
Ist es denn so, dass der Zielrechner oder eine Software darauf in irgendeiner Form crasht? Dies müsste ja in den Logs ersichtlich sein.
Gabs da nicht sowas wie User-Konten die nicht geschlossen werden?!
1
Hi,
es gibt nen reg-key um RDP von TCP auf UDP umzuschalten. Das hat uns mal bei einem brisanten Fehler geholfen.
Ist nicht das selbe wie bei dir, aber versuchen schadet ja nicht.
Weiss nur grad nicht mehr welcher Key genau das ist. Sieh dich mal im WWW um.
Grüße
bloody
es gibt nen reg-key um RDP von TCP auf UDP umzuschalten. Das hat uns mal bei einem brisanten Fehler geholfen.
Ist nicht das selbe wie bei dir, aber versuchen schadet ja nicht.
Weiss nur grad nicht mehr welcher Key genau das ist. Sieh dich mal im WWW um.
Grüße
bloody
um RDP von TCP auf UDP umzuschalten.
RDP wechselt da normalerweise dynamisch zw. UDP und TCP. Guckst du hier:RDP-Client auf dem Apple iPad auf TCP umstellen
Bei apple vllt. bei Windows gibts dafür einen RegKey der das von vornherein festlegt.
Hatten bei RDPoverVPN öfter Probleme mit TCP. Ala Sitzung friert ein und so.
Hatten bei RDPoverVPN öfter Probleme mit TCP. Ala Sitzung friert ein und so.
Zitat von @aqui:
WIE greifst du denn auf diesen Rechner von Remote zu??
Für eine für dich hilfreiche Antwort braucht es ein paar mehr technische Details. Das weisst du als guter Administrator ja alles auch selber.
WIE greifst du denn auf diesen Rechner von Remote zu??
- Die gefährliche und fahrlässige Variante und ungeschützt über simples UDP/TCP 3389 Port Forwarding am Router oder...
- wie es generell üblich ist, gesichert per VPN?
- Wie ist die lokale Firewall an diesem Rechner eingestellt?
- Wichtig wäre noch zu wissen ob der Kollege einen DS-Lite Provider Anschluss zuhause hat. Auch dazu machst du keinerlei hilfreiche Angaben.
Für eine für dich hilfreiche Antwort braucht es ein paar mehr technische Details. Das weisst du als guter Administrator ja alles auch selber.
- Die Verbindung wird über ein VPN-Tunnel hergestellt - in beiden Fällen, da es dieselben Computer sind.
- Auch die Firewall-Einstellungen sind in beiden Fällen identisch.
- Was sich ändert, ist der Standort und somit auch die Internet-Verbindung. Aber wenn es an der Internet-Verbindung liegen würde, warum ist die Lösung der Neustart des Computers im Betrieb?
Zitat von @HansFenner:
Dass man keine RDP Verbindung aufbauen kann, dafür würden mir auch einige Gründe einfallen, eben abhängig von der Verbindungsart, so wie von aqui beschrieben.
Allerdings alle diese möglichen Fehlerquellen lassen sich normalerweise nicht mit einem Neustart des Zielrechners beheben. Das finde ich schon noch speziell.
Ist es denn so, dass der Zielrechner oder eine Software darauf in irgendeiner Form crasht? Dies müsste ja in den Logs ersichtlich sein.
Dass man keine RDP Verbindung aufbauen kann, dafür würden mir auch einige Gründe einfallen, eben abhängig von der Verbindungsart, so wie von aqui beschrieben.
Allerdings alle diese möglichen Fehlerquellen lassen sich normalerweise nicht mit einem Neustart des Zielrechners beheben. Das finde ich schon noch speziell.
Ist es denn so, dass der Zielrechner oder eine Software darauf in irgendeiner Form crasht? Dies müsste ja in den Logs ersichtlich sein.
Wenn eine "crashende" Software die Ursache wäre, müssten die Auswirkungen unabhängig vom Standort identisch sein.
Zitat von @bloodstix:
Hi,
es gibt nen reg-key um RDP von TCP auf UDP umzuschalten. Das hat uns mal bei einem brisanten Fehler geholfen.
Ist nicht das selbe wie bei dir, aber versuchen schadet ja nicht.
Weiss nur grad nicht mehr welcher Key genau das ist. Sieh dich mal im WWW um.
Grüße
bloody
Hi,
es gibt nen reg-key um RDP von TCP auf UDP umzuschalten. Das hat uns mal bei einem brisanten Fehler geholfen.
Ist nicht das selbe wie bei dir, aber versuchen schadet ja nicht.
Weiss nur grad nicht mehr welcher Key genau das ist. Sieh dich mal im WWW um.
Grüße
bloody
Diesen Lösungsansatz habe ich schon ausprobiert, hat leider keine Änderung ergeben.
Die Verbindung wird über ein VPN-Tunnel hergestellt
Das ist schonmal gut! 👍Wichtig ist hier das die Firewall Einstellung der lokalen Winblows Firewall korrekt eingestellt ist. Normal würde die alle eingehenden (RDP) IP Pakete aus fremden IP Netzen blocken, da sie per Default lediglich immer nur Traffic aus dem lokalen IP Netz zulässt.
Hier muss man also unter "Firewall mit erweiterter Sicherheit" einstellen das der Zugriff (Absender IP) sich auch aus fremden IP Netzen für den RDP Dienst im jeweiligen, verwendeten Profil (Privat, Öffentlich, Domäne) erlaubt ist.
Was sich ändert, ist der Standort und somit auch die Internet-Verbindung.
Wie gesagt da wäre es noch wichtig zu wissen ob der besuchte Kollege an einem DS-Lite Anschluss hängt. Also einen Internet Vertrag wo er keine öffentliche IPv4 mehr bekommt sondern nur noch eine IPv6 und der IPv4 Internet Zugang über ein zentralisiertes CGNAT beim Provider gelöst ist. Das kann ggf. Probleme beim VPN Zugang bereiten.Wird der VPN Zugang an sich allerdings korrekt hergestellt und ist der Ziel PC pdann pingbar, hat der Kollege @HansFenner schon Recht mit der Tatsache das sich sich normalerweise sowas nicht mit einem Neustart des Zielrechners beheben lässt. Das ist dann in der Tat ziemlich unüblich und "speziell" und zeigt das der Fehler vermutlich ganz woanders liegt.
Eine wichtige Sache habe ich vergessen: der Verbindungsversuch bleibt immer (also beim Kollegen, bevor ein Neustart ausgeführt wurde!) bei dem Punkt "Verbindungsqualität wird geschätzt" endlos hängen.
Den Ansatz "RDP Verbindung von UDP auf TCP umstellen (fClientDisableUDP)" habe ich versucht, jedoch erfolglos.
Den Ansatz "RDP Verbindung von UDP auf TCP umstellen (fClientDisableUDP)" habe ich versucht, jedoch erfolglos.
Die Realität sagt aber mehrheitlich etwas anderes:
https://www.borncity.com/blog/2022/10/07/windows-11-22h2-microsoft-unter ...
Hast du mit einem Wireshark Sniffer einmal überprüft ob dein Client auch wirklich TCP benutzt und der Registry Eintrag wirklich in der Praxis auch greift?!
Möglich auch das du mit einem VPN in ein MTU Problem getappt bist. Um das genau beurteilen zu können müsste man aber dein verwendetes VPN Protokoll bzw. deine verwendete WAN/Internet Infrastruktur kennen.
Hier hilft ggf. einmal die max. MTU mit aktivem VPN zu ermitteln:
https://vpntester.de/anleitung/optimale-mtu-groesse-bestimmen/
https://www.comconsult.com/vpn-tunnel-aus-dem-homeoffice-mit-mtu-tuning/
https://strongvpn.com/mtu-ping-test/
usw. usw.
https://www.borncity.com/blog/2022/10/07/windows-11-22h2-microsoft-unter ...
Hast du mit einem Wireshark Sniffer einmal überprüft ob dein Client auch wirklich TCP benutzt und der Registry Eintrag wirklich in der Praxis auch greift?!
Möglich auch das du mit einem VPN in ein MTU Problem getappt bist. Um das genau beurteilen zu können müsste man aber dein verwendetes VPN Protokoll bzw. deine verwendete WAN/Internet Infrastruktur kennen.
Hier hilft ggf. einmal die max. MTU mit aktivem VPN zu ermitteln:
https://vpntester.de/anleitung/optimale-mtu-groesse-bestimmen/
https://www.comconsult.com/vpn-tunnel-aus-dem-homeoffice-mit-mtu-tuning/
https://strongvpn.com/mtu-ping-test/
usw. usw.
So ganz selten scheint das Problem nicht zu sein, wenn ich ein bisschen im Internet lesen. Aber eine konkrete Lösung fand ich nicht.
Hier ein paar lesenswerte Links:
https://www.xadomir.de/betriebssysteme/windows/windows-remote-schlaegt-m ...
Windows Server 2012 R2 Terminalserver "Verbindungsqulität wird geschätzt"
https://support.matic-tec.de/portal/de/kb/articles/rdp-verbindungsaufbau ...
Grundsätzlich bin ich schon weiterhin der Meinung, dass man auf dem Zielrechner die Logs studieren müsste. Und wenn der Zielrechner nicht komplett abgestürzt ist, würde ich auch mal versuchen, statt den ganzen Rechner neu zu starten, nur einzelne Dienste neu zu starten um den Fehler einzugrenzen. Naheliegenderweise erst mal den RDP-Serverdienst.
Hier ein paar lesenswerte Links:
https://www.xadomir.de/betriebssysteme/windows/windows-remote-schlaegt-m ...
Windows Server 2012 R2 Terminalserver "Verbindungsqulität wird geschätzt"
https://support.matic-tec.de/portal/de/kb/articles/rdp-verbindungsaufbau ...
Grundsätzlich bin ich schon weiterhin der Meinung, dass man auf dem Zielrechner die Logs studieren müsste. Und wenn der Zielrechner nicht komplett abgestürzt ist, würde ich auch mal versuchen, statt den ganzen Rechner neu zu starten, nur einzelne Dienste neu zu starten um den Fehler einzugrenzen. Naheliegenderweise erst mal den RDP-Serverdienst.
2Zitat von @aqui:
Die Realität sagt aber mehrheitlich etwas anderes:
https://www.borncity.com/blog/2022/10/07/windows-11-22h2-microsoft-unter ...
Ich habe Windows 10 Pro 21H1Die Realität sagt aber mehrheitlich etwas anderes:
https://www.borncity.com/blog/2022/10/07/windows-11-22h2-microsoft-unter ...
Hast du mit einem Wireshark Sniffer einmal überprüft ob dein Client auch wirklich TCP benutzt und der Registry Eintrag wirklich in der Praxis auch greift?!
Wenn die Verbindung über UDP das Problem wäre, würde das Problem ja auch nach dem Neustart des Zielrechners bestehen.Möglich auch das du mit einem VPN in ein MTU Problem getappt bist. Um das genau beurteilen zu können müsste man aber dein verwendetes VPN Protokoll bzw. deine verwendete WAN/Internet Infrastruktur kennen.
Hier hilft ggf. einmal die max. MTU mit aktivem VPN zu ermitteln:
https://vpntester.de/anleitung/optimale-mtu-groesse-bestimmen/
https://www.comconsult.com/vpn-tunnel-aus-dem-homeoffice-mit-mtu-tuning/
https://strongvpn.com/mtu-ping-test/
usw. usw.
Könnte ein Neustart des Zielrechners das MTU-Problem beheben?Hier hilft ggf. einmal die max. MTU mit aktivem VPN zu ermitteln:
https://vpntester.de/anleitung/optimale-mtu-groesse-bestimmen/
https://www.comconsult.com/vpn-tunnel-aus-dem-homeoffice-mit-mtu-tuning/
https://strongvpn.com/mtu-ping-test/
usw. usw.
Zitat von @HansFenner:
Grundsätzlich bin ich schon weiterhin der Meinung, dass man auf dem Zielrechner die Logs studieren müsste. Und wenn der Zielrechner nicht komplett abgestürzt ist, würde ich auch mal versuchen, statt den ganzen Rechner neu zu starten, nur einzelne Dienste neu zu starten um den Fehler einzugrenzen. Naheliegenderweise erst mal den RDP-Serverdienst.
Grundsätzlich bin ich schon weiterhin der Meinung, dass man auf dem Zielrechner die Logs studieren müsste. Und wenn der Zielrechner nicht komplett abgestürzt ist, würde ich auch mal versuchen, statt den ganzen Rechner neu zu starten, nur einzelne Dienste neu zu starten um den Fehler einzugrenzen. Naheliegenderweise erst mal den RDP-Serverdienst.
Die Idee mit der Eingrenzung ist plausibel! Werde es versuchen.
Auch die Logs schaue ich mir bei nächster Gelegenheit mal an.
Danke!
Könnte ein Neustart des Zielrechners das MTU-Problem beheben?
Klares Nein!1
Wenn's das denn war bitte nicht vergessen deinen Thread als erledigt zu schliessen!
Ich hoffe, dass ich hier noch die Lösung posten kann...
1
Das hoffen wir auch... 
Mittlerweile waren es schon zwei Benutzer, die dieselben Probleme hatten.
Beide waren bei 1&1, vermutlich ein DS-Lite Anschluss.
Die Lösung war die Umstellung von UDP auf TCP.
Es reicht natürlich nicht aus, nur dem PC UDP zu verbieten, sondern die komplette Verbindung muss TCP sein, also auch die VPN-Client Konfiguration und der VPN-Server.
Und kaum macht man es richtig, schon geht's!
PS: Warum wurde die Verbindung mit UDP trotzdem aufgebaut, sobald es einen Clean Boot gab?
Beide waren bei 1&1, vermutlich ein DS-Lite Anschluss.
Die Lösung war die Umstellung von UDP auf TCP.
Es reicht natürlich nicht aus, nur dem PC UDP zu verbieten, sondern die komplette Verbindung muss TCP sein, also auch die VPN-Client Konfiguration und der VPN-Server.
Und kaum macht man es richtig, schon geht's!
PS: Warum wurde die Verbindung mit UDP trotzdem aufgebaut, sobald es einen Clean Boot gab?
also auch die VPN-Client Konfiguration und der VPN-Server.
Das ist netztechnischer Unsinn zumindestens was IPsec, Wireguard, SSTP usw. als klassische VPN Protokolle anbetrifft weil die das gar nicht erlauben oder völlig andere Protokolle (z.B. ESP) nutzen.Mal abgesehen davon das das bei VPN selber völlig absurd ist da ja der RDP Traffic so oder so getunnelt wird. Ob RDP mit UDP oder TCP daherkommt ist dem VPN Tunnel ziemlich Wumpe. Aber egal...vermutlich hast du dich auch nur gedrückt aus falsch?!
Warum wurde die Verbindung mit UDP trotzdem aufgebaut, sobald es einen Clean Boot gab?
Weil das bekanntlich immer der Default ist und wenn du TCP am Server nicht über die Registry oder das RDP Protokollsetup erzwingst ändert ein Reboot natürlich gar nix.https://www.windows-faq.de/2020/04/26/fclientdisableudp-rdp-verbindung-u ...
Wir haben einen OpenVPN-Server im Einsatz. Die VPN-Verbindung wurde ja auch mit UDP ohne Probleme aufgebaut und auch die RDP-Verbindung wurde nach einem Neustart des Zielrechners aufgebaut... Das Problem ist oben beschrieben und weitere Details sind anschließend unter dem obigen Post.
Nun habe ich allerdings nur beim OpenVPN-Server und den VPN-Clients auf TCP umgestellt - und es läuft. Dann kann es nicht komplett "netztechnischer Unsinn" sein, denke ich
Die Antwort auf meine Frage...
Nun habe ich allerdings nur beim OpenVPN-Server und den VPN-Clients auf TCP umgestellt - und es läuft. Dann kann es nicht komplett "netztechnischer Unsinn" sein, denke ich
Die Antwort auf meine Frage...
Weil das bekanntlich immer der Default ist und wenn du TCP am Server nicht über die Registry oder das RDP Protokollsetup erzwingst ändert ein Reboot natürlich gar nix.
... habe ich allerdings nicht verstanden.Wir haben einen OpenVPN-Server im Einsatz.
Wie gruselig. Dort mit TCP Encapsulation zu arbeiten ist keine gute Idee. Schafft einen immensen Overhead und erhöht gleichzeitig die MTU Problematik und reisst die von sich aus sehr schlechte Skalierbarkeit von OpenVPN noch weiter in den Keller.Da gibt es deutlich bessere VPN Protokolle...
Dann kann es nicht komplett "netztechnischer Unsinn" sein, denke ich
Leider doch aus den o.a. Gründen... Aber egal, wenns damit rennt und du damit leben kannst ist doch gut. Ein gutes VPN Design sieht aber anders aus.... habe ich allerdings nicht verstanden.
Was genau hast du daran nicht verstanden?? 🤔Die Logik ist doch ganz einfach. Der RDP Client versucht beim Sessionaufbau zuerst immer UDP zu verwenden. Antwortet der Server mit UDP bleibt UDP als Transportprotokoll für RDP bestehen.
Du kannst TCP als Transportprotokoll nur erzwingen wenn du am RDP Server die Verwendung von TCP in der Registry festlegst!
Dann timed der UDP Request des RDP Clients aus weil der Server auf UDP nicht mehr antwortet und er versucht es danach mit TCP was der Server dann beantwortet. Damit hat man dann RDP fest auf TCP als Transportprokoll umgestellt.
Was ist an dieser banalen Logik nicht zu verstehen??
Das in sich schon schlechte OpenVPN dann nochmal auf TCP umzustellen macht wenig Sinn. Sogar OpenVPN rät dringenst von der Verwendung von TCP als Tunnel encapsulation ab. Wie gesagt es sei denn du kannst dann mit dem mickrigen Durchsatz leben.
Wir hatten früher IPsec. Den Unterschied merken die Anwender nicht. Also ist es ausreichend.
Meine Frage war ja:
Meine Frage war ja:
Warum wurde die Verbindung mit UDP trotzdem aufgebaut, sobald es einen Clean Boot gab?
Ich verstehe nicht, warum die RDP-Verbindung NUR nach einem Neustart aufgebaut wurde, bzw. wie konnte diese nach einem Neustart des Zielrechners aufgebaut werden, wenn es generell unmöglich ist.Den Unterschied merken die Anwender nicht. Also ist es ausreichend.
Gut bei RDP ist das auch klar. Dessen Datenvolumina entsprechend ja denen von damaligen 64kBit/s Modemzeiten. In sofern ist es es völlig egal aus der Sicht da hast du recht.Warum man aber von IPsec oder L2TP und onboard Clients auf das deutlich schlechtere OpenVPN wechselt und sich damit dann auch noch die Frickelei mit externen VPN Clients antut muss man sicher nicht verstehen. Z.B.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Mikrotik L2TP Server
wie konnte diese nach einem Neustart des Zielrechners aufgebaut werden, wenn es generell unmöglich ist.
Da hätte sicher ein Wireshark Trace weitergeholfen der mal auf 3389 gesniffert hätte.
In unserer Umgebung war OpenVPN wesentlich einfacher einzurichten als IPsec.
Und OpenVPN Connect kommt wesentlich moderner als der VPN Client von Shrew Soft Inc.
Es kommt immer auch auf die Erfordernisse und die vorhandene Umgebung an.
Daher gibt es auch hier keine "eierlegende Wollmilchsau".
Und OpenVPN Connect kommt wesentlich moderner als der VPN Client von Shrew Soft Inc.
Es kommt immer auch auf die Erfordernisse und die vorhandene Umgebung an.
Daher gibt es auch hier keine "eierlegende Wollmilchsau".
Und OpenVPN Connect kommt wesentlich moderner als der VPN Client von Shrew Soft Inc.
Wäre Unsinn, denn für IPsec braucht es gar keine externen (überflüssigen) Clients. Alle Betriebssysteme und Smartphones haben ausnahmslos von sich aus immer IPsec und L2TP Clients an Bord so das es keiner Frickelei mit extra Software bedarf. Weder Shrew noch OVPN.Wenn es nur nach der Einfachheit der VPN Einrichtung geht müsstest du Wireguard verwenden. Damit würde man per se auch schon die miese Performance von OpenVPN ersetzen.
Ein Bild sagt mehr als 1000 Worte...
