6
Windows Server 2012 R2 Terminalserver "Verbindungsqulität wird geschätzt"
Hallo zusammen,
ich habe hier ein kleines Problem mit einem 2012 R2 Remote Desktop Server.
Ich greife von extern über ein GW 2 GW VPN auf dieses Netzwerk zu und habe das Problem, dasss nach einem 24 Stunden Disconnect des externen Netzwerks die Verbindung zum Terminal Server von bestimmten IP Adressen nicht mehr möglich ist. Und zwar kann von den IP Adressen die bis zum Disconnect drauf zugegriffen haben nicht mehr zugegriffen werden.
Hier ein Beispiel: ich greife von der 192.168.51.12 an einem Tag problemlos auf den Terminalserver zu. Wenn diese Verbindung per RDP über Nacht offen lasse (da findet der DC statt) ist die Verbindung am nächsten Tag unterbrochen, obwohl das VPN problemlos ins andere Netzwerk wieder aufgebaut wurde. Wenn ich dann versuche mich wieder mit dem Server zu verbinden, kommt der Remote Desktop aufbau nur bis zu der Meldung "Verbindungsqualität wird geschätzt" und das wars. Danach kommt nur eine Meldung, dass die Verbindung nicht aufgebaut werden konnte.
Wenn ich dann meine Lokale IP Adresse von 192.168.51.13 ändere, komme ich wieder problemlos drauf. Bis zum nächsten disconnect. Am nächsten Tag funktioniert dann schon die 192.168.51.12 und die 192.168.51.13 nicht mehr und ich darf meine lokale IP wieder ändern.
Wenn ich den Terminalserver reboote, kann ich wieder bei meinen vorher verwendeten IP Adressen anfangen.
Im Ereignislog habe ich auch Unterschiede in bereits benutzten IP Adressen und "frischen" gefunden: (unterschied liegt bei den EreignisIDs 134 / 137)
Hierbei bleibt es bei Verbindungsqualität stehen:
131 Vom Server wurde eine neue Verbindung "TCP" mit Client "192.168.51.12:57213" akzeptiert.
65 Verbindung RDP-Tcp#22 wurde erstellt.
141 PerfCounter-Sitzung mit Instanz-ID 22 gestartet
102 Der Server hat die RDP-Hauptverbindung mit dem Client getrennt.
103 Der Grund für die Trennung lautet: 0.
131 Vom Server wurde eine neue Verbindung "TCP" mit Client "192.168.51.12:57219" akzeptiert.
65 Verbindung RDP-Tcp#23 wurde erstellt.
141 PerfCounter-Sitzung mit Instanz-ID 23 gestartet
134 Die Linklatenz und Bandbreite konnten für Tunnel "8" nicht erkannt werden. Fehlercode: 0x5B4. Die folgenden Standardnetzwerkmerkmale werden verwendet: Linklatenz: 24 Millisekunden und Bandbreite:0 KBit/s.
137 Die folgenden Netzwerkmerkmale wurden für Tunnel "8" erkannt; Linklatenz: 24 Millisekunden und Bandbreite: 0 KBit/s. Verbindungen mit diesen Netzwerkmerkmalen können die Benutzerschnittstelle beeinträchtigen.
132 Zwischen dem Server und dem Client wurde der Kanal "rdplic" mithilfe des Transporttunnels "0" verbunden.
132 Zwischen dem Server und dem Client wurde der Kanal "rdpcmd" mithilfe des Transporttunnels "0" verbunden.
102 Der Server hat die RDP-Hauptverbindung mit dem Client getrennt.
103 Der Grund für die Trennung lautet: 0.
Hier mit einer neuen IP Adresse die funktioniert:
131 Vom Server wurde eine neue Verbindung "TCP" mit Client "192.168.51.17:57261" akzeptiert.
65 Verbindung RDP-Tcp#24 wurde erstellt.
141 PerfCounter-Sitzung mit Instanz-ID 24 gestartet
102 Der Server hat die RDP-Hauptverbindung mit dem Client getrennt.
103 Der Grund für die Trennung lautet: 0.
131 Vom Server wurde eine neue Verbindung "TCP" mit Client "192.168.51.17:57269" akzeptiert.
65 Verbindung RDP-Tcp#25 wurde erstellt.
141 PerfCounter-Sitzung mit Instanz-ID 25 gestartet
133 Die folgenden Netzwerkmerkmale wurden für den Tunnel "8" erkannt: Linklatenz: 22 Millisekunden, Bandbreite: 3366 KBit/s.
132 Zwischen dem Server und dem Client wurde der Kanal "rdplic" mithilfe des Transporttunnels "0" verbunden.
132 Zwischen dem Server und dem Client wurde der Kanal "rdpcmd" mithilfe des Transporttunnels "0" verbunden.
98 Die TCP-Verbindung wurde erfolgreich hergestellt.
100 Vom Server wurde die Mehrfachtransportfunktion des Clients bestätigt.
130 Vom Server wurde eine Mehrfachtransportanforderung mit dem Client für den Tunnel "1" initiiert.
130 Vom Server wurde eine Mehrfachtransportanforderung mit dem Client für den Tunnel "3" initiiert.
131 Vom Server wurde eine neue Verbindung "UDP" mit Client "[192.168.51.17]:61358" akzeptiert.
Der Terminalserver läuft auf einem VMWare Esx i und es sind schon verschiedene Netzwerkkarten und Treiber getestet worden.
Jemand von euch eine Idee wo ich da ansetzen könnte?
Gruß
ich habe hier ein kleines Problem mit einem 2012 R2 Remote Desktop Server.
Ich greife von extern über ein GW 2 GW VPN auf dieses Netzwerk zu und habe das Problem, dasss nach einem 24 Stunden Disconnect des externen Netzwerks die Verbindung zum Terminal Server von bestimmten IP Adressen nicht mehr möglich ist. Und zwar kann von den IP Adressen die bis zum Disconnect drauf zugegriffen haben nicht mehr zugegriffen werden.
Hier ein Beispiel: ich greife von der 192.168.51.12 an einem Tag problemlos auf den Terminalserver zu. Wenn diese Verbindung per RDP über Nacht offen lasse (da findet der DC statt) ist die Verbindung am nächsten Tag unterbrochen, obwohl das VPN problemlos ins andere Netzwerk wieder aufgebaut wurde. Wenn ich dann versuche mich wieder mit dem Server zu verbinden, kommt der Remote Desktop aufbau nur bis zu der Meldung "Verbindungsqualität wird geschätzt" und das wars. Danach kommt nur eine Meldung, dass die Verbindung nicht aufgebaut werden konnte.
Wenn ich dann meine Lokale IP Adresse von 192.168.51.13 ändere, komme ich wieder problemlos drauf. Bis zum nächsten disconnect. Am nächsten Tag funktioniert dann schon die 192.168.51.12 und die 192.168.51.13 nicht mehr und ich darf meine lokale IP wieder ändern.
Wenn ich den Terminalserver reboote, kann ich wieder bei meinen vorher verwendeten IP Adressen anfangen.
Im Ereignislog habe ich auch Unterschiede in bereits benutzten IP Adressen und "frischen" gefunden: (unterschied liegt bei den EreignisIDs 134 / 137)
Hierbei bleibt es bei Verbindungsqualität stehen:
131 Vom Server wurde eine neue Verbindung "TCP" mit Client "192.168.51.12:57213" akzeptiert.
65 Verbindung RDP-Tcp#22 wurde erstellt.
141 PerfCounter-Sitzung mit Instanz-ID 22 gestartet
102 Der Server hat die RDP-Hauptverbindung mit dem Client getrennt.
103 Der Grund für die Trennung lautet: 0.
131 Vom Server wurde eine neue Verbindung "TCP" mit Client "192.168.51.12:57219" akzeptiert.
65 Verbindung RDP-Tcp#23 wurde erstellt.
141 PerfCounter-Sitzung mit Instanz-ID 23 gestartet
134 Die Linklatenz und Bandbreite konnten für Tunnel "8" nicht erkannt werden. Fehlercode: 0x5B4. Die folgenden Standardnetzwerkmerkmale werden verwendet: Linklatenz: 24 Millisekunden und Bandbreite:0 KBit/s.
137 Die folgenden Netzwerkmerkmale wurden für Tunnel "8" erkannt; Linklatenz: 24 Millisekunden und Bandbreite: 0 KBit/s. Verbindungen mit diesen Netzwerkmerkmalen können die Benutzerschnittstelle beeinträchtigen.
132 Zwischen dem Server und dem Client wurde der Kanal "rdplic" mithilfe des Transporttunnels "0" verbunden.
132 Zwischen dem Server und dem Client wurde der Kanal "rdpcmd" mithilfe des Transporttunnels "0" verbunden.
102 Der Server hat die RDP-Hauptverbindung mit dem Client getrennt.
103 Der Grund für die Trennung lautet: 0.
Hier mit einer neuen IP Adresse die funktioniert:
131 Vom Server wurde eine neue Verbindung "TCP" mit Client "192.168.51.17:57261" akzeptiert.
65 Verbindung RDP-Tcp#24 wurde erstellt.
141 PerfCounter-Sitzung mit Instanz-ID 24 gestartet
102 Der Server hat die RDP-Hauptverbindung mit dem Client getrennt.
103 Der Grund für die Trennung lautet: 0.
131 Vom Server wurde eine neue Verbindung "TCP" mit Client "192.168.51.17:57269" akzeptiert.
65 Verbindung RDP-Tcp#25 wurde erstellt.
141 PerfCounter-Sitzung mit Instanz-ID 25 gestartet
133 Die folgenden Netzwerkmerkmale wurden für den Tunnel "8" erkannt: Linklatenz: 22 Millisekunden, Bandbreite: 3366 KBit/s.
132 Zwischen dem Server und dem Client wurde der Kanal "rdplic" mithilfe des Transporttunnels "0" verbunden.
132 Zwischen dem Server und dem Client wurde der Kanal "rdpcmd" mithilfe des Transporttunnels "0" verbunden.
98 Die TCP-Verbindung wurde erfolgreich hergestellt.
100 Vom Server wurde die Mehrfachtransportfunktion des Clients bestätigt.
130 Vom Server wurde eine Mehrfachtransportanforderung mit dem Client für den Tunnel "1" initiiert.
130 Vom Server wurde eine Mehrfachtransportanforderung mit dem Client für den Tunnel "3" initiiert.
131 Vom Server wurde eine neue Verbindung "UDP" mit Client "[192.168.51.17]:61358" akzeptiert.
Der Terminalserver läuft auf einem VMWare Esx i und es sind schon verschiedene Netzwerkkarten und Treiber getestet worden.
Jemand von euch eine Idee wo ich da ansetzen könnte?
Gruß
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: 290363
Url: https://administrator.de/contentid/290363
Ausgedruckt am: 22.11.2024 um 18:11 Uhr
6 Kommentare
Neuester Kommentar
Hi,
mit was baut ihr das VPN auf?
Cisco , Microsoft oder andrer Drittanbieter?
Wie ist das mit dem automatischen Logoff bei dem Terminalserver?
Gruß
Holli
mit was baut ihr das VPN auf?
Cisco , Microsoft oder andrer Drittanbieter?
Wie ist das mit dem automatischen Logoff bei dem Terminalserver?
Gruß
Holli
Hallo holli,
wir bauen das IPSEC VPN über zwei Endian Firewalls (Community Version) (auf einer Seite V2.5.1 und auf der anderen V3.0.5)auf.
Der Automatische Logoff ist nicht konfiguriert. Die Sitzungen sind auch noch genau dieselben wenn ich mich dann von einer anderen IP Adresse drauf verbinde. Es geht nur nicht mehr von alten.
Automatischer Logoff ist auch nicht gewünscht. Da alle Fenster möglichst geöffnet bleiben sollen, auch über Nacht.
Es scheint mir fast so als würde er die alten Verbindungen irgendwie offen halten.
Lieben Gruß
Scream
wir bauen das IPSEC VPN über zwei Endian Firewalls (Community Version) (auf einer Seite V2.5.1 und auf der anderen V3.0.5)auf.
Der Automatische Logoff ist nicht konfiguriert. Die Sitzungen sind auch noch genau dieselben wenn ich mich dann von einer anderen IP Adresse drauf verbinde. Es geht nur nicht mehr von alten.
Automatischer Logoff ist auch nicht gewünscht. Da alle Fenster möglichst geöffnet bleiben sollen, auch über Nacht.
Es scheint mir fast so als würde er die alten Verbindungen irgendwie offen halten.
Lieben Gruß
Scream
Hallo,
gibt es nach einem Jahr weitere Erkenntnisse bzw. eine Lösung für das Problem?
Habe aktuell ein vergleichbares Fehlerbild und finde kaum Informationen dazu. Verwende zwar einen anderen VPN-Tunnel (Sophos UTM mit Windows-Client), aber ansonsten scheint es das gleiche Problem zu sein.
Gruß
gibt es nach einem Jahr weitere Erkenntnisse bzw. eine Lösung für das Problem?
Habe aktuell ein vergleichbares Fehlerbild und finde kaum Informationen dazu. Verwende zwar einen anderen VPN-Tunnel (Sophos UTM mit Windows-Client), aber ansonsten scheint es das gleiche Problem zu sein.
Gruß
Problem (hoffentlich) gelöst...
Fehler lies sich auf den Internetanschluss des Nutzers eingrenzen. War ein Kabelanschluss von Unitymedia für Privatkunden, also mit DS-Lite. Auf Business-Anschluss mit echtem IPv4 umgestellt und seit Tagen keinerlei Probleme mehr.
Fehler lies sich auf den Internetanschluss des Nutzers eingrenzen. War ein Kabelanschluss von Unitymedia für Privatkunden, also mit DS-Lite. Auf Business-Anschluss mit echtem IPv4 umgestellt und seit Tagen keinerlei Probleme mehr.
2
Soweit ich mich erinnern kann konnte ich das Problem damals mit einer neueren Endian Version beseitigen.
Gruß
Gruß
1
Gleiches Problem mit Vodafone Kabel gehabt.
