RDP "Verbindungsqualität wird geschätzt" HomeOffice

Herest0

Cadet 4th Year
Registriert
Jan. 2014
Beiträge
73
Hi zusammen,

habe das Phänomen, dass genauer einer meiner User von Zuhause nicht per VPN eine Remotedesktop-Session aufbauen kann.
Der RDP Aufbau läuft bis zur Meldung "Verbindungsqualität wird geschätzt " und bricht dann später mit einem internen Fehler ab. In den Ereignislogs finde ich nichts dazu. Aber auch nur in seinem Heimnetz, nutzt er einen Hotspot oder bei einem Kollegen etc. dann funktioniert die RDP-Session - keine Änderungen, außer anderes Netzwerk.

Geschwindigkeit sollte kein Problem sein, er hat eine 100mbit Kabelleitung, das VPN verbindet sich ohne Probleme und er kann sogar die gewünschte Maschine, ohne Paketverlust oder hoher Latenz, anpingen. Genutzt wird eine Fritzbox und dort wurde auch eine Freigabe für Port 3389 eingetragen (obwohl es bei anderen Usern komplett ohne Freigabe geht).
Leider funktioniert es weiterhin nicht und ich bin gerade mit meinem Latein am Ende.

Danke für weitere Ideen!
 
Hat er dummerweise die selbe subnetz ip wie du? Oder ist er über wlan/dlan mit dem Internet verbunden?
 
Freigabe ist total unnnötig, sogar jez eher gefährlich/fahrlässig weil man je nachdem nun von aussen direkt per RDP auf das private Netz bzw einen Client darin zugreifen kann. Würde ich dringend raten das sofort wieder zu schliessen.
Das braucht man in den typischen Home Netzwerk Konstellationen nur für eingehende Verbindungen, hier gehts aber um ausgehende Verbindungen - und dann bräuchte man das ja auch noch in ein Firmen-Netzwerk was die Fritzbox sowiso nicht kennt d.h. die Weiterleitung ist auch noch total sinnfrei.

Fritzbox wurde mal stromlos gemacht?
RDP Zugriff per IP Adresse mal probiert?
Die Idee von @chrigu wäre ein Ansatz falls die VPN Client DHCP Range mit dem lokalen Netz übereinstimmen sollte (denke aber nicht, gehe nicht davon aus dass der IT Admin den VPN Client DHCP Range auf das setzt was die Fritzbox standardmässig nutzt und was sicher 99% der Besitzer nicht ändern), dann frage ich mich allerdings wohin es scheinbar erfolgreich pingt.
 
  • Gefällt mir
Reaktionen: guzzisti, Ja_Ge und eigsi124
chrigu schrieb:
Hat er dummerweise die selbe subnetz ip wie du? Oder ist er über wlan/dlan mit dem Internet verbunden?

Nein haben keine gleiche Subnet-IP, war auch eine der ersten Überlegungen. Fehler ist sowohl mit LAN als auch WLAN. Eine Vermutung am Anfang meinerseits war auch, dass mit dem Benutzer auf seinem Laptop etwas nicht stimmt. Aber es klappt ja in anderen Netzen.

Lawnmower schrieb:
Freigabe ist total unnnötig, sogar jez eher gefährlich/fahrlässig weil man je nachdem nun von aussen direkt per RDP auf das private Netz bzw einen Client darin zugreifen kann. Würde ich dringend raten das sofort wieder zu schliessen.
Das braucht man in den typischen Home Netzwerk Konstellationen nur für eingehende Verbindungen, hier gehts aber um ausgehende Verbindungen - und dann zusätzlich auch noch in ein anderes Netzwerk d.h. die Weiterleitung ist auch noch total sinnfrei.

Fritzbox wurde mal stromlos gemacht?

Das wahrscheinlich noch nicht, werde ich ihm mal sagen.
 
Bei uns in der Firma war es so, dass gerade bei den Kabel-Internetanschlüssen die MTU-Size der VPN-Verbindungen zu groß war. Probier mal mit ping -f -l xxxx <IP-von-RDP-Ziel> (-f damit er nicht fragmentiert, -l für die Paketgröße in Byte, Std sind meist 32 oder 64 Byte, je nach System). Std-MTU müsste 1500 sein, oft ging es bei uns bei Kabelinternet dann erst bei 1436 oder sogar 1400.
Wenn die VPN-Verbindung aufgebaut ist kannst du in einer CMD mit folgendem Command schauen wie groß die MTU-Size eingestellt ist
Code:
netsh interface ipv4 show subinterfaces
Dort dann den Namen der VPN-Verbindung raussuchen und mit diesem Command die MTU-Size auf z.B. 1400 setzen
Code:
set subinterface “NAME-DER-VPN-VERBINDUNG” mtu=1400 store=persistent
Bin mir nicht sicher ob ein Reboot notwendig ist, schadet bei Windows i.d.R. aber nicht 😅
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Herest0, eigsi124, derlorenz und 2 andere
Herest0 schrieb:
Genutzt wird eine Fritzbox und dort wurde auch eine Freigabe für Port 3389 eingetragen
Wo wird diese Fritzbox genutzt? Beim Anwender zuhause?
Solche Portfreigaben sind bei Consumer Routern immer nur eingehend. Deaktiviere diese unbedingt wieder.
Welchen DNS Server verwendet der User? Wird ein anderer DNS Server verwendet sobald VPN aktiv ist?

Was wird als Router/Firewall/VPN auf der Serverseite eingesetzt?


Möchte sich der User per auf einen PC oder einen (Terminal-)Server verbinden?
Generell wäre es interessant, was du vom PC des Users aus bei aktiver VPN Verbindung im Zielnetz erreichen kannst. Irgendein Gerät sollte dort pingbar sein.

Liste mal idealerweise die lokalen IP Adressen vom Client und vom RDP Host auf.
 
h00bi schrieb:
Wo wird diese Fritzbox genutzt? Beim Anwender zuhause?
Solche Portfreigaben sind bei Consumer Routern immer nur eingehend. Deaktiviere diese unbedingt wieder.
Welchen DNS Server verwendet der User? Wird ein anderer DNS Server verwendet sobald VPN aktiv ist?

Was wird als Router/Firewall/VPN auf der Serverseite eingesetzt?


Möchte sich der User per auf einen PC oder einen (Terminal-)Server verbinden?
Generell wäre es interessant, was du vom PC des Users aus bei aktiver VPN Verbindung im Zielnetz erreichen kannst. Irgendein Gerät sollte dort pingbar sein.

Liste mal idealerweise die lokalen IP Adressen vom Client und vom RDP Host auf.

Beim Anwender zu Hause. Gut zu wissen mit den Freigaben, sind schon wieder deaktiviert worden, nachdem es keine Änderung brachte. Nein DNS ist weiterhin der gleiche, verbunden wird sich über die IP-Adresse des Terminalservers, nicht der Hostname.
Auf der Serverseite sitzt eine Sophos mit entsprechenden Regeln. >15 User funktionieren derzeit so.

Ziel ist ein Terminalserver und ich kann ALLE Geräte pingen, die erreichbar sein sollen, ohne jeden Paketverlust. Auch Ordnerfreigaben sind erreichbar, nur eben nicht die RDP-Session.

CubeID schrieb:
Bei uns in der Firma war es so, dass gerade bei den Kabel-Internetanschlüssen die MTU-Size der VPN-Verbindungen zu groß war.

Das ist mal was ganz neues, werde ich mal ausprobieren.
 
Herest0 schrieb:
Ziel ist ein Terminalserver und ich kann ALLE Geräte pingen, die erreichbar sein sollen, ohne jeden Paketverlust. Auch Ordnerfreigaben sind erreichbar, nur eben nicht die RDP-Session.
Ping schickt bei Windows wenn ich es richtig im Kopf habe Paket mit nur 32 Byte große Pakete raus, womit die MTU-Size noch kein Problem darstellt. Wenn man mit ping -l jedoch mal in den 1400-1500 Byte-Bereich geht kommt man eben an die Grenze was in EINEM Paket übertragen werden kann.
Ah, da merke ich grad noch, das -f vergessen, weil sonst teilt er das Paket einfach auf zwei Pakete auf (fragmentiert), sprich:
Code:
ping -f -l xxxx <IP-von-RDP-Ziel>
Werde ich oben auch noch korrigieren.
 
  • Gefällt mir
Reaktionen: Herest0
Bin jetzt gerade nicht beim User zu Hause, aber zumindest von mir aus geht ein ping erst mit <1472 MTU Size durch. Habe für das VPN die Größe auf 1400 gesetzt und werde es mal testen lassen. Danke schonmal für den Tipp!
 
RDP geht auf keines der Geräte, welche übers VPN erreichbar sind. RDP auf Geräte im selben Heimnetzwerk wurde noch nicht ausprobiert, da er keinen zweiten PC zu Hause hat (und keine Frau/Kind etc). Auf der Arbeit klappt RDP aber auch auf lokaler Ebene.

Habe den Eintrag aus dem Link auch schon vorgenommen, also nutzt tcp.
 
CubeID schrieb:
Ping schickt bei Windows wenn ich es richtig im Kopf habe Paket mit nur 32 Byte große Pakete raus, womit die MTU-Size noch kein Problem darstellt. Wenn man mit ping -l jedoch mal in den 1400-1500 Byte-Bereich geht kommt man eben an die Grenze was in EINEM Paket übertragen werden kann.
Ah, da merke ich grad noch, das -f vergessen, weil sonst teilt er das Paket einfach auf zwei Pakete auf (fragmentiert), sprich:
Code:
ping -f -l xxxx <IP-von-RDP-Ziel>
Werde ich oben auch noch korrigieren.

Leider keine Änderung gebracht. RDP bricht weiterhin mit "Interner Fehler aufgetreten" ab.
Trotzdem danke :)
 
Wenn Ping via VPN geht, RDP via VPN hingegen nicht, muss man an dieser Stelle meines Erachtens ins Eingemachte gehen und zB mittels WireShark den Traffic sniffen und sich anschauen wie der Paketfluss aussieht und ob man sehen kann warum das eine geht und das andere nicht.

Abgesehen davon kann eventuell auch die Ereignisanzeige (Windows -> System) mehr Details zu dem Fehler liefern.

Eine weitere Ursache kann auch die Windows-Firewall sein. Sollte beispielsweise die VPN-Verbindung im "öffentlichen" Profil laufen und in den ausgehenden Regeln des Clients die RDP-Verbindung für "öffentlich" geblockt werden, kann natürlich keine Verbindung zustande kommen. Zwar müsste das theoretisch auch in fremden (W)LANs passieren, aber es schadet dennoch nicht, sich mal die Regeln anzuschauen.
 
Und sonst die radikale Methode: Neu aufsetzen.
 
  • Gefällt mir
Reaktionen: Raijin
Zurück
Oben