killtec
Goto Top

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.

screenshot 2024-10-17 102406
screenshot 2024-10-17 103212

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.

screenshot 2024-10-17 114325

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.

Content-ID: 668823

Url: https://administrator.de/forum/windows-remotedesktop-rst-ack-668823.html

Ausgedruckt am: 23.12.2024 um 12:12 Uhr

aqui
aqui 17.10.2024 aktualisiert um 13:14:21 Uhr
Goto Top
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.
killtec
killtec 17.10.2024 um 13:04:46 Uhr
Goto Top
Zitat von @aqui:

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.

Das ist eine gute Frage, da habe ich mir noch nie Gedanken drum gemacht... Ich schaue mal ob bzw. wie ich das raus bekomme.
aqui
aqui 17.10.2024 aktualisiert um 13:39:44 Uhr
Goto Top
Du hast es ja schon rausbekommen! Sieh dir deinen Wireshark Trace an. face-wink 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 face-sad ) 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 ....
killtec
killtec 17.10.2024 um 13:13:46 Uhr
Goto Top
Zitat von @aqui:

Du hast es ja schon rausbekommen! Sieh dir deinen Wireshark Trace an. face-wink Normal nutzt RDP initial UDP. Warum bei dir TCP verwendet wird wäre interessant zu klären.

Das lässt sich doch bestimmt umstellen, oder?
killtec
killtec 17.10.2024 um 13:31:26 Uhr
Goto Top
Eventuell ein interessantes Detail. Ich habe an dem Standort den DC umgezogen auf einen neuen. Seit dem ist mir das aufgefallen. Replikation läuft aber. Kann das damit zu tun haben?
killtec
killtec 17.10.2024 um 14:25:17 Uhr
Goto Top
Ich habe meine GPO noch mal angepasst:
screenshot 2024-10-17 142126

Die Einstellung brachte leider nicht den Erfolg... Er versucht immer noch sich via TCP anzumelden.

screenshot 2024-10-17 142224

Das beim Cookie im mstshash nicht der volle Username steht ist korrekt? Da steht nur Domain\adm (anstatt admin)
Wenn ich andere Userdaten eingebe steht da immer noch der adm drin.
killtec
killtec 17.10.2024 um 16:05:39 Uhr
Goto Top
Könnte das Problem auch von der Authentifizierung als solches kommen, so dass es gar kein RDP Problem in dem Fall ist?
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.
MysticFoxDE
MysticFoxDE 17.10.2024 um 18:06:40 Uhr
Goto Top
Moin @killtec,

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
MysticFoxDE
MysticFoxDE 17.10.2024 um 18:18:52 Uhr
Goto Top
Moin @killtec,

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."

🙃

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
killtec
killtec 18.10.2024 um 08:05:15 Uhr
Goto Top
Zitat von @MysticFoxDE:

Moin @killtec,

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
Das werde ich mir heute anschauen.

"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."

🙃
Glücklicherweise funktioniert ICMP innerhalb der Tunnel. Ich will ja auch per ping wissen ob mein System oder die Verbindung da ist face-smile

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.

Ich bin als Admin angemeldet ;)

Gruss Alex
killtec
killtec 18.10.2024 um 09:50:09 Uhr
Goto Top
So, habe mal die MTU an einem Client herab gesetzt um das nachzustellen. Das Verhalten bleibt erhalten.
MysticFoxDE
MysticFoxDE 18.10.2024 um 09:55:54 Uhr
Goto Top
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
killtec
killtec 18.10.2024 aktualisiert um 10:06:43 Uhr
Goto Top
Hi,
ja, es ist ein Hyper-V 2019 (Reiner Hyper-V). Da tritt das Problem übrigens auch auf... Aber nur wenn ich mich mit Domain Cred. anmelden mag. Mache ich das mit dem lokalen Admin, so geht es....

Daher vermute ich eher, dass es ein Authentifizierungsproblem ist und der Server die Creds nicht richtig abgleichen kann, wenn man außerhalb des Netzwerkes kommt.

Umstellen des RSC verändert nichts.
aqui
aqui 31.10.2024 um 11:51:57 Uhr
Goto Top
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
killtec
Lösung killtec 01.11.2024 um 08:34:31 Uhr
Goto Top
Hi,
habe gerade erst gestern wieder an dem Problem gearbeitet. Interessanterweise half hier ein Rejoin der Server in die Domain. Allerdings wird das bei dem lokalen Domaincontroller etwas schwieriger den mal kurz aus der Domain und dann wieder rein zu nehmen...

Ich werde das hier erst einmal schließen. Habe dann noch ein anderes Problem, das muss ich aber erst einmal genauer analysieren. Das Betrifft dann die Console vom Hyper-V, da fragt er auch nach Cred, da funktionieren dann nur die des lokalen Admins. Ich vermute dass das AD etwas komisch ist. Das werde ich jetzt erst einmal prüfen.