Windows Remotedesktop (RST, ACK)
Hallo,
Wir haben ein Problem mit RDP-Verbindungen. Das ganze hatte ich schon mal vor einem Jahr gepostet unter.
RDP fragt nach Passwort - loop
Kurzzusammenfassung:
Ich greife via mstsc.exe (Remotedesktop) auf ein System zu. Dieses System befindet sich in einem anderen Netzwerksegment, welches mittels IPSEC Site2Site verbunden ist.
Wird der normale RDP-Client (mstsc) genutzt, so kommt nach korrekter Eingabe der Anmeldedaten direkt wieder die Abfrage der Anmeldedaten. Das ganze ist in einem loop.
Nutze ich hingegen den Remotedesktop aus dem MS-Store, so kann ich mit selbigen Daten eine Verbindung aufbauen.
Im Eventlog des entfernten Systems ist kein logon Versuch Protokolliert worden.
Im Wireshark habe ich gesehen, dass die RDP mit einem RST, ACK quittiert wird.
Greife ich auf selbigen Server aus dem lokalen Netz zu, so funktioniert dies ohne Probleme. (Getestet in dem ich per Fernwartung auf einem Client in dem Netz war und mich dann auf dem Server angemeldet habe, per mstsc.)
Hier mal der Wireshark Auszug. Ich habe nur die User / Rechnernamen gelöscht.
Jetzt wird es noch richtig Spooky...
Ich habe einen weiteren Test aus einem 3. Netzwerk gemacht (mein eigenes Netz, welches per VPN mit der Firma verbunden ist) welches nicht Bestandteil der AD-Domain ist und konnte mich erfolgreich per mstsc anmelden.
Testclient 1 geht nur per Remotedesktop App auf RDP Server
Testclient 2 geht per mstsc auf den RDP Server
Testclient 3 geht auch nicht per mstsc
Der Testclient 3 ist ein Frisch aufgesetzter Windows 10 Rechner.
Würde gerne den mstsc wieder funktionsfähig bekommen. Für Tipps bin ich dankbar.
Wir haben ein Problem mit RDP-Verbindungen. Das ganze hatte ich schon mal vor einem Jahr gepostet unter.
RDP fragt nach Passwort - loop
Kurzzusammenfassung:
Ich greife via mstsc.exe (Remotedesktop) auf ein System zu. Dieses System befindet sich in einem anderen Netzwerksegment, welches mittels IPSEC Site2Site verbunden ist.
Wird der normale RDP-Client (mstsc) genutzt, so kommt nach korrekter Eingabe der Anmeldedaten direkt wieder die Abfrage der Anmeldedaten. Das ganze ist in einem loop.
Nutze ich hingegen den Remotedesktop aus dem MS-Store, so kann ich mit selbigen Daten eine Verbindung aufbauen.
Im Eventlog des entfernten Systems ist kein logon Versuch Protokolliert worden.
Im Wireshark habe ich gesehen, dass die RDP mit einem RST, ACK quittiert wird.
Greife ich auf selbigen Server aus dem lokalen Netz zu, so funktioniert dies ohne Probleme. (Getestet in dem ich per Fernwartung auf einem Client in dem Netz war und mich dann auf dem Server angemeldet habe, per mstsc.)
Hier mal der Wireshark Auszug. Ich habe nur die User / Rechnernamen gelöscht.
Jetzt wird es noch richtig Spooky...
Ich habe einen weiteren Test aus einem 3. Netzwerk gemacht (mein eigenes Netz, welches per VPN mit der Firma verbunden ist) welches nicht Bestandteil der AD-Domain ist und konnte mich erfolgreich per mstsc anmelden.
Testclient 1 geht nur per Remotedesktop App auf RDP Server
Testclient 2 geht per mstsc auf den RDP Server
Testclient 3 geht auch nicht per mstsc
Der Testclient 3 ist ein Frisch aufgesetzter Windows 10 Rechner.
Würde gerne den mstsc wieder funktionsfähig bekommen. Für Tipps bin ich dankbar.
Please also mark the comments that contributed to the solution of the article
Content-ID: 668823
Url: https://administrator.de/contentid/668823
Printed on: November 4, 2024 at 09:11 o'clock
15 Comments
Latest comment
Seit Ver. 8.0 nutzt RDP UDP oder TCP als Transport. Hilfreich wäre zu wissen ob das Verhalten nur bei einer Encapsulation Art passiert oder bei beiden?? Dazu machst du leider keine Angaben.
Der überflüssige Dualismus 2er verschiedener VPN Protokolle tut ein übriges. Dadurch kommt es sehr wahrscheinlich durch falsche Tunnel MTU Settings zu Fragmentierungen so das es Sinn macht die Tunnel MTUs diesbezüglich zu checken. Sinnig wäre nur ein VPN Protokoll zu verwenden!
Sowas ist ganz besonders in einem PPPoE Umfeld einer WAN Verbindung ein Thema sofern diese PPPoE verwendet.
Der überflüssige Dualismus 2er verschiedener VPN Protokolle tut ein übriges. Dadurch kommt es sehr wahrscheinlich durch falsche Tunnel MTU Settings zu Fragmentierungen so das es Sinn macht die Tunnel MTUs diesbezüglich zu checken. Sinnig wäre nur ein VPN Protokoll zu verwenden!
Sowas ist ganz besonders in einem PPPoE Umfeld einer WAN Verbindung ein Thema sofern diese PPPoE verwendet.
Du hast es ja schon rausbekommen! Sieh dir deinen Wireshark Trace an. Normal nutzt RDP initial UDP. Warum bei dir TCP verwendet wird wäre interessant zu klären. Sehr wahrscheinlich verbietet fälschlicherweise die Firewall UDP für den Port 3389?! (Geraten, da Konfig leider fehlt ) Dann gibt es den Fallback auf TCP. Lokal ist (geraten) vermutlich kein Regelwerk der FW aktiv so das UDP zum Einsatz kommt, was klappt. Leider fehlt dazu der WS Trace...
https://www.windows-faq.de/2020/04/26/fclientdisableudp-rdp-verbindung-u ....
https://www.windows-faq.de/2020/04/26/fclientdisableudp-rdp-verbindung-u ....
Moin @killtec,
ja, aber das solltest du nicht wirklich machen, da TCP viel robuster ist als das "Fire and Forget UDP", mit welchem wir bei diversesten RDS Farmen unserer Kunden, noch nie wirklich gute Erfahrungen gemacht haben.
Gruss Alex
Das lässt sich doch bestimmt umstellen, oder?
ja, aber das solltest du nicht wirklich machen, da TCP viel robuster ist als das "Fire and Forget UDP", mit welchem wir bei diversesten RDS Farmen unserer Kunden, noch nie wirklich gute Erfahrungen gemacht haben.
Gruss Alex
Moin @killtec,
theoretisch ja, bauchtechnisch bin ich eher bei @aqui, sprich, dass dein Problem entweder was mit der Firewall und oder MTU zu tun hat.
Ist zwischen den beteiligten Netzen denn ICMP in beide Richtungen freigegeben?
Wenn nein, dann mach das mal bitte als nächstes, sprich ICMP zwischen den beteiligten Netzen freigeben.
Und falls du wissen möchtest warum ... Stichwort PMTUD (Path MTU Discovery).
https://www.elektronik-kompendium.de/sites/net/2012221.htm
🙃
Auf der Konsolenverbindung/Konsolensitzung eines RDS sollte sich eigentlich auch nur ein Admin anmelden können.
Gruss Alex
Könnte das Problem auch von der Authentifizierung als solches kommen, so dass es gar kein RDP Problem in dem Fall ist?
theoretisch ja, bauchtechnisch bin ich eher bei @aqui, sprich, dass dein Problem entweder was mit der Firewall und oder MTU zu tun hat.
Ist zwischen den beteiligten Netzen denn ICMP in beide Richtungen freigegeben?
Wenn nein, dann mach das mal bitte als nächstes, sprich ICMP zwischen den beteiligten Netzen freigeben.
Und falls du wissen möchtest warum ... Stichwort PMTUD (Path MTU Discovery).
https://www.elektronik-kompendium.de/sites/net/2012221.htm
"Leider gibt es einige Paranoide Netzwerk-Administratoren, die in den Netzwerken, die sie betreuen, die ICMP-Pakete von Firewalls sperren bzw. verwerfen lassen. Das heißt, das ursprüngliche Datenpaket wird nie beim Empfänger ankommen und der wird nie erfahren, worin das Problem liegt.
Dieses Problem tritt zum Beispiel bei VPN-Verbindungen auf. Hier müsste wegen dem Tunneling die MTU meist kleiner sein."
Dieses Problem tritt zum Beispiel bei VPN-Verbindungen auf. Hier müsste wegen dem Tunneling die MTU meist kleiner sein."
🙃
Selbiges passiert mir wenn ich im Hyper-V Manager bin und eine Konsolenverbindung öffne, da fragt er auch nach den Daten. Das klappt dort nur mit den lokalen Admin-Daten.
Auf der Konsolenverbindung/Konsolensitzung eines RDS sollte sich eigentlich auch nur ein Admin anmelden können.
Gruss Alex
Moin @killtec,
das ist ja eine Hyper-V VM.
Was ist das den genau für ein Hyper-V, sprich 2016, 2019 oder 2022?
Wenn => 2019 ... hast du schon RSC auf den vSwitchen deaktiviert?
Gruss Alex
das ist ja eine Hyper-V VM.
Was ist das den genau für ein Hyper-V, sprich 2016, 2019 oder 2022?
Wenn => 2019 ... hast du schon RSC auf den vSwitchen deaktiviert?
Gruss Alex
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
How can I mark a post as solved?
How can I mark a post as solved?