Terminalserver keine RDP Verbindung vom Homeoffice

reini82
Goto Top
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:
homeoffice

Content-Key: 1622986307

Url: https://administrator.de/contentid/1622986307

Ausgedruckt am: 28.06.2022 um 21:06 Uhr

Mitglied: em-pie
Lösung em-pie 15.12.2021 um 15:16:35 Uhr
Goto Top
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
Mitglied: Reini82
Reini82 15.12.2021 um 15:48:52 Uhr
Goto Top
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
Mitglied: aqui
Lösung aqui 15.12.2021 aktualisiert um 16:02:39 Uhr
Goto Top
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... :-( face-sad
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... ;-) face-wink
Mitglied: em-pie
em-pie 15.12.2021 um 17:43:45 Uhr
Goto Top
Zitat von @aqui:

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

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... :-( face-sad
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/16

In der Tat ein interessantes Phänomen... ;-) face-wink
D'accord



@to
könnte es sein, dass für deine Kollegin, ich nenne Sie mal Maria (:-) face-smile), 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"?
Mitglied: ultiman
Lösung ultiman 16.12.2021 um 02:01:59 Uhr
Goto Top
Moin
MTU MTU MTU :-) face-smile sacht @aqui: ja schon
Mitglied: Reini82
Reini82 16.12.2021 um 07:54:26 Uhr
Goto Top
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
Mitglied: aqui
aqui 16.12.2021 aktualisiert um 10:21:57 Uhr
Goto Top
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 ?! :-( face-sad
Mitglied: Reini82
Reini82 16.12.2021 um 10:22:28 Uhr
Goto Top
Zitat von @aqui:

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 ?! :-( face-sad

Neeeein :) face-smile Habe mich falsch ausgedrückt. Ich wollte nur nicht den genauen Adressbereich schreiben. Es ist ein 24 Subnetz.
Mitglied: PeterBC
PeterBC 16.12.2021 aktualisiert um 15:58:54 Uhr
Goto Top
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.
Mitglied: Reini82
Reini82 17.12.2021 um 07:00:50 Uhr
Goto Top
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.

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ß
Mitglied: PeterBC
PeterBC 17.12.2021 um 08:21:17 Uhr
Goto Top
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
Mitglied: aqui
aqui 17.12.2021 aktualisiert um 11:04:02 Uhr
Goto Top
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.
Mitglied: Reini82
Reini82 20.12.2021 um 09:51:16 Uhr
Goto Top
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?
Mitglied: Reini82
Reini82 05.01.2022 um 10:12:41 Uhr
Goto Top
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

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

administrator.de/forum/mtu-fuer-wireguard-ipv6-ermitteln-665412.html

Vielen dank für die Hilfe Gruß
Mitglied: aqui
aqui 05.01.2022 um 12:55:50 Uhr
Goto Top
Da hilft dann immer der MTU Rechner ! ;-) face-wink
https://baturin.org/tools/encapcalc/
Mitglied: Reini82
Reini82 05.01.2022 um 13:10:03 Uhr
Goto Top
Zitat von @aqui:

Da hilft dann immer der MTU Rechner ! ;-) face-wink
https://baturin.org/tools/encapcalc/

Jap, der ist Gold wert ;)