90948
15.12.2021, aktualisiert um 14:39:15 Uhr
5077
16
0
Terminalserver keine RDP Verbindung vom Homeoffice
Einen schönen guten Nachmittag,
wir haben mehrere Laptops für das Homeoffice. Diese bauen eine VPN-Verbindung mittels Wireguard (aktuelle Version) zu einer OPNSense auf. Anschließend gehts weiter mittels RDP auf einen Terminalserver. Das funktioniert auch seit über einem halben Jahr ohne Probleme (bin selbst jede Woche 1-2mal im Homeoffice)
Nun hat eine Kollegin auch einen Homeoffice Arbeitsplatz bekommen und einen vorkonfigurierten Laptop von mir ausgehändigt bekommen.
Sie hat nun das Problem, das Sie sich nicht auf den Terminalserver einloggen kann. Beim Verbinden erscheint das Login-Fenster, anschließend auch das die Remoteverbindung aufgebaut und gesichert wird. Dann bricht er nach ein paar Minuten ab.
Besagten Laptop habe ich nun zur hier nochmal getestet. Über das interne WLAN kann ich erfolgreich eine Verbindung aufbauen. Auch habe ich diesen PC mal bei mir zu Hause gehabt und alles lief ohne Probleme. Dann hab ich dies mal über einen mobilen Hotspot von meinem Handy aus probiert und tatsache hab ich das gleiche Phänomen. Die VPN-Verbindung wird aufgebaut und in der OPNSense sehe ich auch, wie eine Remotedesktopsession aufgebaut werden soll. Diese bricht nach ein paar Minuten auch ab. Ein Versuch mit einem zweiten Laptop führte zum gleichen Ergebnis.
Nun habe ich mal mittels iperf ein paar Testmessungen zum Server gemacht. Im Durchschnitt waren es zwischen 300-600 kbit/s was doch für eine Remotedesktopsession funktionieren sollte? In der RDP-Session wurde auch die Auflösung reduziert, die Verbindungsgeschwindigkeit angepasst und die Farbtiefe heruntergesetzt. Alles ohne Erfolg. Zudem meint die Kollegin, sie hat einen 1GBit/s Anschluss zu Hause und Ihr Mann ist ebenso im Homeoffice. Jetzt weiß ich gerade nicht, was ich noch testen könnte. Hier noch ein Bild:
wir haben mehrere Laptops für das Homeoffice. Diese bauen eine VPN-Verbindung mittels Wireguard (aktuelle Version) zu einer OPNSense auf. Anschließend gehts weiter mittels RDP auf einen Terminalserver. Das funktioniert auch seit über einem halben Jahr ohne Probleme (bin selbst jede Woche 1-2mal im Homeoffice)
Nun hat eine Kollegin auch einen Homeoffice Arbeitsplatz bekommen und einen vorkonfigurierten Laptop von mir ausgehändigt bekommen.
Sie hat nun das Problem, das Sie sich nicht auf den Terminalserver einloggen kann. Beim Verbinden erscheint das Login-Fenster, anschließend auch das die Remoteverbindung aufgebaut und gesichert wird. Dann bricht er nach ein paar Minuten ab.
Besagten Laptop habe ich nun zur hier nochmal getestet. Über das interne WLAN kann ich erfolgreich eine Verbindung aufbauen. Auch habe ich diesen PC mal bei mir zu Hause gehabt und alles lief ohne Probleme. Dann hab ich dies mal über einen mobilen Hotspot von meinem Handy aus probiert und tatsache hab ich das gleiche Phänomen. Die VPN-Verbindung wird aufgebaut und in der OPNSense sehe ich auch, wie eine Remotedesktopsession aufgebaut werden soll. Diese bricht nach ein paar Minuten auch ab. Ein Versuch mit einem zweiten Laptop führte zum gleichen Ergebnis.
Nun habe ich mal mittels iperf ein paar Testmessungen zum Server gemacht. Im Durchschnitt waren es zwischen 300-600 kbit/s was doch für eine Remotedesktopsession funktionieren sollte? In der RDP-Session wurde auch die Auflösung reduziert, die Verbindungsgeschwindigkeit angepasst und die Farbtiefe heruntergesetzt. Alles ohne Erfolg. Zudem meint die Kollegin, sie hat einen 1GBit/s Anschluss zu Hause und Ihr Mann ist ebenso im Homeoffice. Jetzt weiß ich gerade nicht, was ich noch testen könnte. Hier noch ein Bild:
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: 1622986307
Url: https://administrator.de/contentid/1622986307
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
16 Kommentare
Neuester Kommentar
Moin,
frag sie mal, ob sie via WLAN arbeitet und wie gut das Signal dort ist. Die Gegenprobe könnte ein Standortwechsel/ Anbindung per Netzwerkkabel sein.
Wählt sie sich zudem per DNS oder IP-Adresse auf den RDS-Server ein? Habt ihr das mal getestet?
Findet sich ggf. etwas im Eventlog des RDS-Server/ Clients wieder?
300-600kBit/s ist wahrlich nicht die Masse und könnte (nicht muss) mit ein Knackpunkt sein.
Gruß
em-pie
frag sie mal, ob sie via WLAN arbeitet und wie gut das Signal dort ist. Die Gegenprobe könnte ein Standortwechsel/ Anbindung per Netzwerkkabel sein.
Wählt sie sich zudem per DNS oder IP-Adresse auf den RDS-Server ein? Habt ihr das mal getestet?
Findet sich ggf. etwas im Eventlog des RDS-Server/ Clients wieder?
300-600kBit/s ist wahrlich nicht die Masse und könnte (nicht muss) mit ein Knackpunkt sein.
Gruß
em-pie
Hi,
WLAN und LAN wurde getestet. Auch ein ping auf den Terminalserver geht erfolgreich durch. Ebenso eine Verbindungsversuch mittels IP-Adresse getestet. Alles ohne Erfolg.
Die Eventslog sind tatsache noch ein Punkt zum prüfen. thx
WLAN und LAN wurde getestet. Auch ein ping auf den Terminalserver geht erfolgreich durch. Ebenso eine Verbindungsversuch mittels IP-Adresse getestet. Alles ohne Erfolg.
Die Eventslog sind tatsache noch ein Punkt zum prüfen. thx
frag sie mal, ob sie via WLAN arbeitet und wie gut das Signal dort ist.
Der TO hat den besagten Rechner ja zuhause sowohl per Kabel und WLAN getestet und da rennt es fehlerlos. Besagt ja erstmal das es der Rechner per se nicht sein kann.Verdächtig ist das genau der gleiche Rechner an einem Tethering Hotspot nicht rennt. Das nährt den Verdacht das es ggf. etwas mit DS-Lite oder CGN zu tun hat. Leider fehlen dazu aber alle zielführenden Informationen so das man nur die Kristallkugel bemühen kann...
Aber auch wenn, sollte das immer klappen, denn auch wenn das VPN über einen DS-Lite Anschluss arbeitet ist es ja immer die Client Seite die den Tunnel initiiert und damit den Tunnel aufbaut (Initiator). Technisch kann es daran eigentlich auch nicht liegen.
Lokale Firewall scheidet auch aus wenn der Rechner beim TO sowohl im WLAN als auch LAN fehlerfrei rennt. An der Bandbreite liegt das auch nicht, denn RDP klappt auch mit 64kBit/s.
Das der Provider den Wireguard Standard Port filtert könnte sein wenn er VPN Nutzer in einen Business Tarif zwingen will scheidet aber sicher aus da der VPN Tunnel ja immer zustande kommt.
Könnte noch die Tunnel MTU sein aber auch dagegen spricht das der lokale Test beim TO fehlerlos ist.
Kann es ggf. sein das das lokale LAN des Clients IP adresstechnisch identisch ist mit dem internen Wireguard Netz oder deinem Tethering WLAN ? Kann passieren wenn man einfache Allerwelts Adressen fürs VPN verwendet. Siehe dazu auch hier.
In der Tat ein interessantes Phänomen...
1Zitat von @aqui:
Nöö, aber wenn das WIFI-Signal zwischen Laptop und FritzBox (oder Speedport, Ruckus AP, ...) 13 Stahlbetonwände passieren muss, beim TO aber das Laptop neben dem AP steht, ist obige Frage durchaus berechtigt.frag sie mal, ob sie via WLAN arbeitet und wie gut das Signal dort ist.
Der TO hat den besagten Rechner ja zuhause sowohl per Kabel und WLAN getestet und da rennt es fehlerlos. Besagt ja erstmal das es der Rechner per se nicht sein kann.Verdächtig ist das genau der gleiche Rechner an einem Tethering Hotspot nicht rennt. Das nährt den Verdacht das es ggf. etwas mit DS-Lite oder CGN zu tun hat. Leider fehlen dazu aber alle zielführenden Informationen so das man nur die Kristallkugel bemühen kann...
An CGN habe ich auch als nächstes gedacht, aber wenn der VPN steht und er die Gegenseite anpingen kann, obendrein ja schon bis zur ANmeldemaske kommt, steht grundsätzlich der Tunnel ja!?Aber auch wenn, sollte das immer klappen, denn auch wenn das VPN über einen DS-Lite Anschluss arbeitet ist es ja immer die Client Seite die den Tunnel initiiert und damit den Tunnel aufbaut (Initiator). Technisch kann es daran eigentlich auch nicht liegen.
Lokale Firewall scheidet auch aus wenn der Rechner beim TO sowohl im WLAN als auch LAN fehlerfrei rennt. An der Bandbreite liegt das auch nicht, denn RDP klappt auch mit 64kBit/s.
Das der Provider den Wireguard Standard Port filtert könnte sein wenn er VPN Nutzer in einen Business Tarif zwingen will scheidet aber sicher aus da der VPN Tunnel ja immer zustande kommt.
Könnte noch die Tunnel MTU sein aber auch dagegen spricht das der lokale Test beim TO fehlerlos ist.
Kann es ggf. sein das das lokale LAN des Clients IP adresstechnisch identisch ist mit dem internen Wireguard Netz oder deinem Tethering WLAN ? Kann passieren wenn man einfache Allerwelts Adressen fürs VPN verwendet. Siehe dazu auch hier.
Habe ich auch gedacht, aber aufgrund des Hotspots am Handy verworfen. Die Netze sind zumeist ja nicht aus den Haushaltsüblichen Bereichen eines 192.168.0.0/16Lokale Firewall scheidet auch aus wenn der Rechner beim TO sowohl im WLAN als auch LAN fehlerfrei rennt. An der Bandbreite liegt das auch nicht, denn RDP klappt auch mit 64kBit/s.
Das der Provider den Wireguard Standard Port filtert könnte sein wenn er VPN Nutzer in einen Business Tarif zwingen will scheidet aber sicher aus da der VPN Tunnel ja immer zustande kommt.
Könnte noch die Tunnel MTU sein aber auch dagegen spricht das der lokale Test beim TO fehlerlos ist.
Kann es ggf. sein das das lokale LAN des Clients IP adresstechnisch identisch ist mit dem internen Wireguard Netz oder deinem Tethering WLAN ? Kann passieren wenn man einfache Allerwelts Adressen fürs VPN verwendet. Siehe dazu auch hier.
In der Tat ein interessantes Phänomen...
D'accord@to
könnte es sein, dass für deine Kollegin, ich nenne Sie mal Maria (
), ein personifiziertes VPN-Profil hat?Ich kenne das von der Sophos und den OpenSSL-Tunneln. Da kann man je User/ Gruppe eigene Regeln definieren. Ist das bei Wireguard auch so (habe hier null Erfahrung mit)?
Hat "Maria" auch das Problem, wenn Sie den Tunnel nicht Zuhause aufbaut?
Bzw. der Hotspot-Test: verlief der mit dem User "Maria"?
Moin,
MTU könnte ein Punkt sein. Dies aber bei Ihr rauszufinden wird interessant. Sonst gibt es keine Probleme
@em-pie Alle sind auf dem gleichen Wireguard Server mit den gleichen Einstellungen.
@aqui Die Tunneladressen liegen innerhalb eines 10.0.0.0/8 Netz um evtl. Heimadressen n. möglichkeit aus dem Weg zu gehen. Denke MTU könnte schon ein Punkt sein oder deren Leitung ist wohl doch nicht so arg 1 GBit wie gedacht
MTU könnte ein Punkt sein. Dies aber bei Ihr rauszufinden wird interessant. Sonst gibt es keine Probleme
@em-pie Alle sind auf dem gleichen Wireguard Server mit den gleichen Einstellungen.
@aqui Die Tunneladressen liegen innerhalb eines 10.0.0.0/8 Netz um evtl. Heimadressen n. möglichkeit aus dem Weg zu gehen. Denke MTU könnte schon ein Punkt sein oder deren Leitung ist wohl doch nicht so arg 1 GBit wie gedacht
Die Tunneladressen liegen innerhalb eines 10.0.0.0/8 Netz
Keine gute Idee und etwas sinnfrei hier mit einem /8er Prefix zu arbeiten. Du wirst ja wohl kaum 16,777 Millionen Clients bedienen wollen, oder ? Recht unsinniger Prefix also und kontraproduktiv bei einem VPN.Bedeutet auch das dein VPN nie funktioniert wenn sich Clients in einem irgendwie gearteten 10.x.y.z Netzwerk befinden.
Also keine besonders intelligente IP Adresse für das Tunnelnetz. Siehe dazu auch HIER !
Ein etwas "exotischerer" /24er Prefix wäre hier bei VPN schon sinnvoll für die Betriebssicherheit.
Sowas weiss man aber eigentlich wenn man ein VPN plant ?!
Zitat von @aqui:
Bedeutet auch das dein VPN nie funktioniert wenn sich Clients in einem irgendwie gearteten 10.x.y.z Netzwerk befinden.
Also keine besonders intettilgente IP Adress für das Tunnelnetz. Siehe dazu auch HIER !
Ein etwas "exotischerer" /24er Prefix wäre hier bei VPN schon sinnvoll. Sowas weiss man aber eigentlich wenn man ein VPN plant ?!
Die Tunneladressen liegen innerhalb eines 10.0.0.0/8 Netz
Keine gute Idee und etwas sinnfrei hier mit einem /8er Prefix zu arbeiten. Du wirst ja wohl kaum 16,777 Millionen Clients bedienen wollen, oder ? Recht unsinniger Prefix also.Bedeutet auch das dein VPN nie funktioniert wenn sich Clients in einem irgendwie gearteten 10.x.y.z Netzwerk befinden.
Also keine besonders intettilgente IP Adress für das Tunnelnetz. Siehe dazu auch HIER !
Ein etwas "exotischerer" /24er Prefix wäre hier bei VPN schon sinnvoll. Sowas weiss man aber eigentlich wenn man ein VPN plant ?!
Neeeein
Habe mich falsch ausgedrückt. Ich wollte nur nicht den genauen Adressbereich schreiben. Es ist ein 24 Subnetz.
Hallo,
ich hatte in den vergangenen Tagen auch sehr komische Probleme mit Wireguard in Verbindung mit CGN. Das lief bis vor ein paar Wochen problemlos, jetzt melden die Mitarbeiter von einem Kunden vermehrt Probleme.
Die hängen alle an Vodafone-Kabel im Homeoffice.
Ich bin noch nicht dazu gekommen das weiter zu verfolgen, aber ich vermute hier das Problem.
Gruß
Edit: komische Probleme bedeutet manche Dienste gehen, manche nicht, manche nur zu bestimmten Servern. RDP geht z.B. auf PCs im Netzwerk, nicht aber auf den Terminalserver.
ich hatte in den vergangenen Tagen auch sehr komische Probleme mit Wireguard in Verbindung mit CGN. Das lief bis vor ein paar Wochen problemlos, jetzt melden die Mitarbeiter von einem Kunden vermehrt Probleme.
Die hängen alle an Vodafone-Kabel im Homeoffice.
Ich bin noch nicht dazu gekommen das weiter zu verfolgen, aber ich vermute hier das Problem.
Gruß
Edit: komische Probleme bedeutet manche Dienste gehen, manche nicht, manche nur zu bestimmten Servern. RDP geht z.B. auf PCs im Netzwerk, nicht aber auf den Terminalserver.
Zitat von @PeterBC:
Hallo,
ich hatte in den vergangenen Tagen auch sehr komische Probleme mit Wireguard in Verbindung mit CGN. Das lief bis vor ein paar Wochen problemlos, jetzt melden die Mitarbeiter von einem Kunden vermehrt Probleme.
Die hängen alle an Vodafone-Kabel im Homeoffice.
Ich bin noch nicht dazu gekommen das weiter zu verfolgen, aber ich vermute hier das Problem.
Gruß
Edit: komische Probleme bedeutet manche Dienste gehen, manche nicht, manche nur zu bestimmten Servern. RDP geht z.B. auf PCs im Netzwerk, nicht aber auf den Terminalserver.
Hallo,
ich hatte in den vergangenen Tagen auch sehr komische Probleme mit Wireguard in Verbindung mit CGN. Das lief bis vor ein paar Wochen problemlos, jetzt melden die Mitarbeiter von einem Kunden vermehrt Probleme.
Die hängen alle an Vodafone-Kabel im Homeoffice.
Ich bin noch nicht dazu gekommen das weiter zu verfolgen, aber ich vermute hier das Problem.
Gruß
Edit: komische Probleme bedeutet manche Dienste gehen, manche nicht, manche nur zu bestimmten Servern. RDP geht z.B. auf PCs im Netzwerk, nicht aber auf den Terminalserver.
Hi,
interessant da es sich in dem Fall auch um Vodafone Kabel handelt. Gestern hat nicht einmal ein simpler Speedtest mit iperf mehr funktioniert. Ich habe daher den Provider bzw. dessen "1Gbic" Leitung in Verdacht. Da ich aber noch nicht vor Ort war, kann ich dies nicht nachvollziehen bißher.
Gruß
Hallo,
Sei so nett und halte uns auf dem Laufenden wenn du die Ursache findest.
Bei dem Kunden ist eine Fehlersuche nicht gewünscht, ich kann also selbst nicht weiter testen.
Ich kann mir vorstellen, dass das Problem aber noch öfter auftaucht.
Grüße
Sei so nett und halte uns auf dem Laufenden wenn du die Ursache findest.
Bei dem Kunden ist eine Fehlersuche nicht gewünscht, ich kann also selbst nicht weiter testen.
Ich kann mir vorstellen, dass das Problem aber noch öfter auftaucht.
Grüße
interessant da es sich in dem Fall auch um Vodafone Kabel handelt.
Vodafone stellt viele Consumer Anschlüsse in letzter Zeit heimlich auf DS-Lite um ohne Endkunden darüber zu informieren. Dabei kann man auch z.T eklatante Performance Unterschiede zw. IPv4 und IPv6 messen. Man sollte also mal explizit testen ob die Connectivity Probleme in beiden Protokollen v4 und v6 auftreten.Zitat von @aqui:
interessant da es sich in dem Fall auch um Vodafone Kabel handelt.
Vodafone stellt viele Consumer Anschlüsse in letzter Zeit heimlich auf DS-Lite um ohne Endkunden darüber zu informieren. Dabei kann man auch z.T eklatante Performance Unterschiede zw. IPv4 und IPv6 messen. Man sollte also mal explizit testen ob die Connectivity Probleme in beiden Protokollen v4 und v6 auftreten.Wird schwierig, da wir keine öffentliche v6 Adresse haben. Oder gibt es da noch andere Möglichkeiten?
Zitat von @PeterBC:
Hallo,
Sei so nett und halte uns auf dem Laufenden wenn du die Ursache findest.
Bei dem Kunden ist eine Fehlersuche nicht gewünscht, ich kann also selbst nicht weiter testen.
Ich kann mir vorstellen, dass das Problem aber noch öfter auftaucht.
Grüße
Hallo,
Sei so nett und halte uns auf dem Laufenden wenn du die Ursache findest.
Bei dem Kunden ist eine Fehlersuche nicht gewünscht, ich kann also selbst nicht weiter testen.
Ich kann mir vorstellen, dass das Problem aber noch öfter auftaucht.
Grüße
Hi,
also definitiv die Tunnel MTU musste bei der Kollegin angepasst werden. In meinem Fall war es MTU 1386.
Danke vor allem dank diesen Beitrags
MTU für Wireguard IPv6 ermitteln
Vielen dank für die Hilfe Gruß
Jap, der ist Gold wert ;)
