11
Netzwerkprobleme - VPN - Mobile Daten - RDP "interner Fehler"
Hallo
Ich habe mit folgender Ausgangslage Probleme:
Externer Standort soll via VPN an den Hauptstandort angebunden werden. Es sind 2 Draytek Geräte im Einsatz. Verbindungsaufbau via Wireguard mit routing und auch via SSL-VPN funktioniert wie erwartet. Ping geht durch,VoIP Telefonie, Outlook und Kommunikation mit Exchange, Webinterfaces von Geräten jeweils am anderen Standort öffnen geht.
Was nicht geht:
Via Wireguard kriege ich wenn ich eine RDP Verbindung herstellen will beim "Geschwindigkeit überprüfen" einen "Internen Fehler". RDP Verbindung klappt dann nicht.
Wenn ich mit dem selben Notebook via Draytek VPN Client die Verbindung via Hotspot vom Handy aufbauklappt die RDP Verbindung sofort.
Wenn die Verbindung zwischen den beiden Standorten via SSL VPN LAN zu LAN hergestellt wird klappt auch alles, bis auf RDP. RDP verbindet sich dann, die RDP Sitzung kann gestartet werden aber sobald man ein Fenster verschiebt bricht nicht nur die RDP Verbindung ab, bzw. friert mit Grafikfehlern ein, es ist dann auch der SSL Tunnel im Router getrennt. Wenn ich den Draytek Smart VPN Client benutze wird der auch getrennt. Ping geht nicht mehr durch.
Ich habe 15 minuten ping durchlaufen lassen, Telefonie probiert. Und dann erst RDP ausprobiert und die Verbindung war sofort wieder getrennt. Also das war auch nicht Zufall meiner Ansicht nach.
Ich habe am externen Standort ein ZTE 5G Router von der Telekom. Kann der irgendwie die SSL Verbindungen ruinieren? Ein Hop zu viel dann? Ich habe da keine Einstellung für gefunden im ZTE 5G Gerät. Im Draytek sind die Firewalls aus. Die Geräte machen zum Internet hin NAT, VPN ist geroutet. Oder kann das der 5G Mast sein auf dem der Router hängt?
Eigentlich ist lediglich die Simkarte ist getauscht, von flex mit 100GB auf company backup wo tagesflats gebucht werden. Falls das eine Rolle spielt.
Als nächstes probiere ich mal den Flex Tarif vor Ort wieder aus mit anderer Sim und Speedbox 2.
Aber wäre ja schon irgendwie überraschend, wenn das darin liegen soll...
Jemand sonst noch Ideen?
Ich habe mit folgender Ausgangslage Probleme:
Externer Standort soll via VPN an den Hauptstandort angebunden werden. Es sind 2 Draytek Geräte im Einsatz. Verbindungsaufbau via Wireguard mit routing und auch via SSL-VPN funktioniert wie erwartet. Ping geht durch,VoIP Telefonie, Outlook und Kommunikation mit Exchange, Webinterfaces von Geräten jeweils am anderen Standort öffnen geht.
Was nicht geht:
Via Wireguard kriege ich wenn ich eine RDP Verbindung herstellen will beim "Geschwindigkeit überprüfen" einen "Internen Fehler". RDP Verbindung klappt dann nicht.
Wenn ich mit dem selben Notebook via Draytek VPN Client die Verbindung via Hotspot vom Handy aufbauklappt die RDP Verbindung sofort.
Wenn die Verbindung zwischen den beiden Standorten via SSL VPN LAN zu LAN hergestellt wird klappt auch alles, bis auf RDP. RDP verbindet sich dann, die RDP Sitzung kann gestartet werden aber sobald man ein Fenster verschiebt bricht nicht nur die RDP Verbindung ab, bzw. friert mit Grafikfehlern ein, es ist dann auch der SSL Tunnel im Router getrennt. Wenn ich den Draytek Smart VPN Client benutze wird der auch getrennt. Ping geht nicht mehr durch.
Ich habe 15 minuten ping durchlaufen lassen, Telefonie probiert. Und dann erst RDP ausprobiert und die Verbindung war sofort wieder getrennt. Also das war auch nicht Zufall meiner Ansicht nach.
Ich habe am externen Standort ein ZTE 5G Router von der Telekom. Kann der irgendwie die SSL Verbindungen ruinieren? Ein Hop zu viel dann? Ich habe da keine Einstellung für gefunden im ZTE 5G Gerät. Im Draytek sind die Firewalls aus. Die Geräte machen zum Internet hin NAT, VPN ist geroutet. Oder kann das der 5G Mast sein auf dem der Router hängt?
Eigentlich ist lediglich die Simkarte ist getauscht, von flex mit 100GB auf company backup wo tagesflats gebucht werden. Falls das eine Rolle spielt.
Als nächstes probiere ich mal den Flex Tarif vor Ort wieder aus mit anderer Sim und Speedbox 2.
Aber wäre ja schon irgendwie überraschend, wenn das darin liegen soll...
Jemand sonst noch Ideen?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-ID: 669748
Url: https://administrator.de/contentid/669748
Printed on: December 14, 2024 at 16:12 o'clock
11 Comments
Latest comment
Guten Abend,
hast du mal versucht, einen betroffenen Client auf RDP over TCP umzustellen und geschaut, ob du selbiges Problem damit auch hast?
hast du mal versucht, einen betroffenen Client auf RDP over TCP umzustellen und geschaut, ob du selbiges Problem damit auch hast?
- Regedit
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client- DWORD-Wert anlegen und dem Wert
fClientDisableUDPzuweisen1
1
Schau die mal die MTU Size für die Wireguard Verbindung an. Evtl. ist die zu groß eingestellt.
Danke für die Ideen.
Der Vigor hat so eine Funktion, dass man den MTU automatisch ermitteln kann. 1500 und auch 1484 hat beides diese Komplikationen mit verursacht. Also keine Besserung gebracht.
Das ist der MTU vom Draytek richtung 5G Router. Also als Ziel für die Bestimmung war "gateway" ausgewählt. Danach ist 1484 als optimal angezeigt worden. Mit "ok" hat sich auch der Wert für Wireguard und die anderen VPN Verbindungen umgestellt angeblich.
2 Dinge habe ich jetzt noch als Test vor:
1. Anderer Draytek und anderer 4G Router.
2. Umstellung von Sicherheit für RDP von SSL auf RDP.
Und zusätzlich werde ich das mal mit UDP als Protokoll für RDP ausprobieren. Wenn das geht: Was sagt mir das denn?
Der Vigor hat so eine Funktion, dass man den MTU automatisch ermitteln kann. 1500 und auch 1484 hat beides diese Komplikationen mit verursacht. Also keine Besserung gebracht.
Das ist der MTU vom Draytek richtung 5G Router. Also als Ziel für die Bestimmung war "gateway" ausgewählt. Danach ist 1484 als optimal angezeigt worden. Mit "ok" hat sich auch der Wert für Wireguard und die anderen VPN Verbindungen umgestellt angeblich.
2 Dinge habe ich jetzt noch als Test vor:
1. Anderer Draytek und anderer 4G Router.
2. Umstellung von Sicherheit für RDP von SSL auf RDP.
Und zusätzlich werde ich das mal mit UDP als Protokoll für RDP ausprobieren. Wenn das geht: Was sagt mir das denn?
5G ZTE MC8810 gegen einen Speebox 2 (4G) Router getauscht. Selbe SIM (company backup) und es funktionierte sofort einwandfrei. Liegt also in irgendeiner Art am 5G Router.
Hi,
ich kenne genau das Problem. Bei mir war es auch die MTU via OpenVPN. Prüfe bei aufgebauten VPN mit folgenden Befehl die nutzbare MTU:
ping -n 1 -l 1500 -f ip-des-zielservers
Und reduziere dann schrittweise die 1500, bis du eine funktionierende MTU hast.
ich kenne genau das Problem. Bei mir war es auch die MTU via OpenVPN. Prüfe bei aufgebauten VPN mit folgenden Befehl die nutzbare MTU:
ping -n 1 -l 1500 -f ip-des-zielservers
Und reduziere dann schrittweise die 1500, bis du eine funktionierende MTU hast.
Und den trage ich dann im Draytek ein für die WAN Verbindung, die für die VPN Strecke benutzt wird und dann wird es funktionieren?
Weil zu viele fragmentierte Pakete die SSL Verbindungen zerstören?
Weil zu viele fragmentierte Pakete die SSL Verbindungen zerstören?
Zitat von @hausrocker:
Und den trage ich dann im Draytek ein für die WAN Verbindung, die für die VPN Strecke benutzt wird und dann wird es funktionieren?
Weil zu viele fragmentierte Pakete die SSL Verbindungen zerstören?
Und den trage ich dann im Draytek ein für die WAN Verbindung, die für die VPN Strecke benutzt wird und dann wird es funktionieren?
Weil zu viele fragmentierte Pakete die SSL Verbindungen zerstören?
Ich kann dir leider nicht sagen, wie das im Draytek eingetragen wird. Ich kenne mich mit Draytek nicht aus bzw. nur mit deren VDSL-Modems. Bei einer OpenVPN Road Warrior Verbindung z.b. gehe ich in die Client-config und trage mssfix <mtu-40> wie z.B. hier beschrieben ein: https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-ope ...
Hier steht etwas bzgl. MTU bei Draytek: https://www.draytek.co.uk/support/guides/kb-vigor-mtu-2
Das muss irgendwo bei der VPN-Client-Konfiguration des Drayteks einstellbar sein.
Das Trügerische ist, dass die VPN-Verbindung zustande kommt, Ping und DNS usw alles funktioniert. In dem Moment, wo allerdings der UDP Stream genutzt wird (innerhalb des Tunnels) macht die MTU immer öfter Probleme. Edit: Zur Info, MS RDP nutzt UDP und TCP, probiert allerdings zuerst UDP. Wenn das klappt, wird TCP nicht mehr probiert. TCP wird eher als Failback genutzt. Gerade in Terminsalerverumgebungen ist die Nutzung von TCP aber gegenüber UDP zu bevorzugen. Die genauen Gründe müsste ich selbst nochmal recherchieren :D
Du könntest daher probieren, den RDP-Zugriff auf nur-TCP um zu stellen, wie z.B. hier besprochen: Bildqualität der Windows Remotedesktop-Sitzung verbessern Damit zwingst du deine Geräte UDP gar nicht erst zu nutzen sondern direkt TCP zu probieren. Muss natürlich Firewallmäßig auch freigegeben werden.
MfG
Ok. Der Punkt ist unter WAN - Internet Access - Details - MTU dann bei Draytek.
Geprüft habe ich jetzt mal folgendes:
Der Draytek am externen Standort hat tatsächlich 1500 als MTU. Was vermeintlich zu hoch ist.
Jetzt im Moment funktioniert der 1500er MTU aber in Verbindung mit der Speedbox 2. Aber ja vorher nicht mit dem ZTE 5G Router.
Den ZTE 5G habe ich jetzt bei mir. Ausprobiert mit älterem Draytek, der weder SSL noch Wireguard kann aber IPSec.
Entweder macht es was aus, wenn es IPSec ist oder das Gerät kann auf einmal in Verbindung mit dem ZTE 5G Router auch mit 1500er MTU Pakete ohne Fragmentierung übertragen. Oder spielt da noch der Sendemast mit? Am externen Standort gibt es vllt. schon diese neue Version von 5G, die nicht LTE als Träger verwendet? Denn da hatte ich mit einem iPhone mit 5G überraschend fast 1 Gbit via 5G im Speedtest.
Denn hier jetzt funktioniert die Verbindung 5G Router, 1500er MTU und alter Draytek wie erwartet. Ping mit dem MTU zeigt auch nicht an, dass die Pakete fragmentiert werden.
Es ist also speziell die Kombi aus dem neueren Draytek mit dem neueren 5G ZTE Router und vermutlich zu hohem MTU, die Probleme macht. Oder Standort oder Version 5G oder alles irgendwie.
Ist es ein alter Draytek oder ein 4G LTE Router (oder anderer Standort), ist auf einmal auch MTU von 1500 in Ordnung.
Schon echt komisch... Die neueren Draytek Router haben auch unter WAN - Internet Access - Details einen Punkt mit "Path MTU Discovery" wo man einen IPv4 Host als Ziel angeben kann und via detect dann erkennen lassen kann, welcher MTU Wert gut ist. IPv4 Hosts, die nur via VPN erreicht werden können, kann man hier aber offenbar nicht angeben. Das gibt immer "fail".
Für den DNS 8.8.8.8 ist als Wert 1476 gut. Jetzt ist noch die Frage: Ist das mit oder ohne headers?
Mal sehen, ob die LTE Geschwindigkeit vor Ort für flüssige Benutzung ausreicht. Sonst tausche ich noch mal LTE gegen 5G und probiere die MTU Anpassung noch mal gezielt aus.
Geprüft habe ich jetzt mal folgendes:
Der Draytek am externen Standort hat tatsächlich 1500 als MTU. Was vermeintlich zu hoch ist.
Jetzt im Moment funktioniert der 1500er MTU aber in Verbindung mit der Speedbox 2. Aber ja vorher nicht mit dem ZTE 5G Router.
Den ZTE 5G habe ich jetzt bei mir. Ausprobiert mit älterem Draytek, der weder SSL noch Wireguard kann aber IPSec.
Entweder macht es was aus, wenn es IPSec ist oder das Gerät kann auf einmal in Verbindung mit dem ZTE 5G Router auch mit 1500er MTU Pakete ohne Fragmentierung übertragen. Oder spielt da noch der Sendemast mit? Am externen Standort gibt es vllt. schon diese neue Version von 5G, die nicht LTE als Träger verwendet? Denn da hatte ich mit einem iPhone mit 5G überraschend fast 1 Gbit via 5G im Speedtest.
Denn hier jetzt funktioniert die Verbindung 5G Router, 1500er MTU und alter Draytek wie erwartet. Ping mit dem MTU zeigt auch nicht an, dass die Pakete fragmentiert werden.
Es ist also speziell die Kombi aus dem neueren Draytek mit dem neueren 5G ZTE Router und vermutlich zu hohem MTU, die Probleme macht. Oder Standort oder Version 5G oder alles irgendwie.
Ist es ein alter Draytek oder ein 4G LTE Router (oder anderer Standort), ist auf einmal auch MTU von 1500 in Ordnung.
Schon echt komisch... Die neueren Draytek Router haben auch unter WAN - Internet Access - Details einen Punkt mit "Path MTU Discovery" wo man einen IPv4 Host als Ziel angeben kann und via detect dann erkennen lassen kann, welcher MTU Wert gut ist. IPv4 Hosts, die nur via VPN erreicht werden können, kann man hier aber offenbar nicht angeben. Das gibt immer "fail".
Für den DNS 8.8.8.8 ist als Wert 1476 gut. Jetzt ist noch die Frage: Ist das mit oder ohne headers?
Mal sehen, ob die LTE Geschwindigkeit vor Ort für flüssige Benutzung ausreicht. Sonst tausche ich noch mal LTE gegen 5G und probiere die MTU Anpassung noch mal gezielt aus.
Hi, soweit ich weiß ist die MTU nur bei SSL-VPNs relevant. Und auf die MTU seitens des Provides haben wir keinen Einfluss. Jenachdem, mit welchem Provider und welcher Technik und von welchem Standort man ins Internet geht verhält sich die MTU anders.
Wir müssen nur einen Workaround kennen. Testweise solltest du die MTU auch sehr klein einstellen können, kleiner geht immer, der Durchsatz leidet letztlich drunter. In letzter Zeit häufen sich auch bei uns die Probleme mit der MTU. Da rufen Kunden an, die vom Homeoffice aus keinen Zugriff auf den Server mehr haben, mit ihrem Handy als Hostspot funktinioert es dann. Oder mit dem WLAN des Nachbars, der als Provider vielleicht 1und1 statt Telekom hat usw usw.
Probiere noch die Umstellung auf TCP ;)
MfG
Wir müssen nur einen Workaround kennen. Testweise solltest du die MTU auch sehr klein einstellen können, kleiner geht immer, der Durchsatz leidet letztlich drunter. In letzter Zeit häufen sich auch bei uns die Probleme mit der MTU. Da rufen Kunden an, die vom Homeoffice aus keinen Zugriff auf den Server mehr haben, mit ihrem Handy als Hostspot funktinioert es dann. Oder mit dem WLAN des Nachbars, der als Provider vielleicht 1und1 statt Telekom hat usw usw.
Probiere noch die Umstellung auf TCP ;)
MfG
Ich glaube ja, SSL grundsätzlich ist dann "gestört", das würde auch erklären, warum ich überraschend oft vom https Interface vom Router abgemeldet werde. Je mehr Daten über die SSL Verbindung gehen, je eher eskaliert es.
Und ob man ein SSL VPN hat oder RDP via SSL verschlüsselt wird, ist am Ende SSL und macht dann Probleme. Dafür gibt es auch einen Registry Key wo man Security von RDP auf RDP oder ssl stellen kann.
Das würde auch erklären, warum bei einer Wireguard VPN Verbindung trotzdem SSL dann Probleme macht.
Im Draytek, wenn man den MTU für die Internetverbindung im WAN Setup ändert, kommt danach ein Hinweis, dass der MTU für die VPN Verbindungen auch angepasst wird, mit Info auf welche Werte. Die sind je nach VPN wegen vermutlich Overhead unterschiedlich.
Und ob man ein SSL VPN hat oder RDP via SSL verschlüsselt wird, ist am Ende SSL und macht dann Probleme. Dafür gibt es auch einen Registry Key wo man Security von RDP auf RDP oder ssl stellen kann.
Das würde auch erklären, warum bei einer Wireguard VPN Verbindung trotzdem SSL dann Probleme macht.
Im Draytek, wenn man den MTU für die Internetverbindung im WAN Setup ändert, kommt danach ein Hinweis, dass der MTU für die VPN Verbindungen auch angepasst wird, mit Info auf welche Werte. Die sind je nach VPN wegen vermutlich Overhead unterschiedlich.
Ich glaube du verwechselst da etwas. Mit RDP meine ich das RDP-Protokoll: https://de.wikipedia.org/wiki/Remote_Desktop_Protocol
RDP basiert auf dem ITU-Protokoll T.120 und ist ein Protokoll der Ebenen 4–7 des OSI-Modells. Es benutzt grundlegend das Transmission Control Protocol (TCP) für den Sitzungsaufbau und die Datenübertragung. Zur Verringerung der Latenzen (z. B. Multimediainhalte, Telefon- und Videokonferenzen) wird nach Möglichkeit ein paralleler Kanal mit User Datagram Protocol (UDP) verwendet.
Und dein Router nutzt HTTPS um die GUI dar zu stellen, und bekanntlich nutzt HTTPS ja TCP als Transport, ist also auch keine Erklärung für das von dir beschriebene Verhalten. Wenn du immer wieder ausgeloggt wirst kann das einfach nur sehr kurzer Timeout deiner Session sein?
SSL-VPN heißt nur, dass SSL als Verschlüsselung genutzt wird: https://de.wikipedia.org/wiki/SSL-VPN
Anders als OpenVPN kann Wireguard allerdings nur UDP als Transport nutzen. Und UDP ist der Grund, weswegen die MTU Größe relevant ist.
Und genau so lässt sich auch erklären, warum du den RDP-Zugriff ebenfalls auf TCP einschränken sollst, damit die Remotedesktopsitzung garnicht erst UDP nutzt.
Mach das erstmal und lass die Finger von der Sicherheitsaushandlung des RDP Protokolls weg, das hat nichts miteinander zu tun.
MfG
RDP basiert auf dem ITU-Protokoll T.120 und ist ein Protokoll der Ebenen 4–7 des OSI-Modells. Es benutzt grundlegend das Transmission Control Protocol (TCP) für den Sitzungsaufbau und die Datenübertragung. Zur Verringerung der Latenzen (z. B. Multimediainhalte, Telefon- und Videokonferenzen) wird nach Möglichkeit ein paralleler Kanal mit User Datagram Protocol (UDP) verwendet.
Und dein Router nutzt HTTPS um die GUI dar zu stellen, und bekanntlich nutzt HTTPS ja TCP als Transport, ist also auch keine Erklärung für das von dir beschriebene Verhalten. Wenn du immer wieder ausgeloggt wirst kann das einfach nur sehr kurzer Timeout deiner Session sein?
SSL-VPN heißt nur, dass SSL als Verschlüsselung genutzt wird: https://de.wikipedia.org/wiki/SSL-VPN
Anders als OpenVPN kann Wireguard allerdings nur UDP als Transport nutzen. Und UDP ist der Grund, weswegen die MTU Größe relevant ist.
Und genau so lässt sich auch erklären, warum du den RDP-Zugriff ebenfalls auf TCP einschränken sollst, damit die Remotedesktopsitzung garnicht erst UDP nutzt.
Mach das erstmal und lass die Finger von der Sicherheitsaushandlung des RDP Protokolls weg, das hat nichts miteinander zu tun.
MfG