9
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.
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: 668823
Url: https://administrator.de/contentid/668823
Ausgedruckt am: 18.10.2024 um 03:10 Uhr
9 Kommentare
Neuester Kommentar
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.
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.
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.
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 ....
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 ....
Zitat von @aqui:
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.
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.Das lässt sich doch bestimmt umstellen, oder?
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?
Ich habe meine GPO noch mal angepasst:
Die Einstellung brachte leider nicht den Erfolg... Er versucht immer noch sich via TCP anzumelden.
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.
Die Einstellung brachte leider nicht den Erfolg... Er versucht immer noch sich via TCP anzumelden.
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.
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.
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.
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
