05.06.2014, aktualisiert am 10.06.2014

35061

RDP Verbindung über VPN Zugang bricht ab

Hallo,

Habe hier das Problem das die RDP eines Benutzers zur Abendstunde immer abbricht, sprich "Verbindung wird versucht wiederherzustellen, Versuch 1 von ...".
Verbunden über eine VPN aus dem Homeoffice.

Folgende Konstellation:

-> SBS 2011 (DC)
-> Terminalserver 2008 (kein R2)
-> Lancom 1781A (aktueller Firmware ist installiert)
-> Lancom VPN Client (auch aktuell und frisch installiert)

Die VPN ist laut Aussage des Benutzers noch vorhanden, nur die RDP Sitzung bricht ab. Wenn ich selbst die gleiche VPN verwende und eine Remotesitzung laufen lasse bricht bei mir gar nichts ab.
Die Fritzbox die der Benutzer aus seinem Homeoffice verwendet habe ich auch schon aktualisiert.

Das Log am Terminalserver hat mir vorgestern diesen Fehler ausgespuckt:

"Quelle: TermDD Ereignis ID: 56

Die Terminalserver-Sicherheitsschicht hat einen Fehler im Protokollablauf erkannt und den Client getrennt."

Dieser trat jedoch gestern Abend nicht auf und trotzdem hat sich die RDP wieder getrennt. Ich finde auch nichts im Log des Clients, ist ein Lenovo Laptop mit Windows 7 der futsch neu ist.

Jemand ne Idee?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 240130

Url: https://administrator.de/forum/rdp-verbindung-ueber-vpn-zugang-bricht-ab-240130.html

Ausgedruckt am: 23.12.2024 um 16:12 Uhr

41 Kommentare

Neuester Kommentar

Hallo,

hast du mal die Profileinstellungen geprüf? (Einwählen und Sitzungen)
Sonst setze mal einen statischen Eintrag im ARP gemacht?
Sind deine NIC Treiber aktuell?

Grüße, Quentoo

Hi,

- Wenn du die Zeitlimits des Benutzers meinst, dort ist "Nie" eingetragen.

- Meinst du das er den ARP Eintrag des Terminalservers sporadisch verliert? Wäre vielleicht eine Überlegung wert..

- Was ich vergessen habe, beide Server laufen auf einem Hyper-V 2008 R2. Dieser wurde vor kurzem durch neue Hardware und eine Neuinstallation ersetzt. Könnte es hier vielleicht so Konflikten mit den Integrationsdiensten kommen, bin mir grade nicht sicher ob ich diese aktualisiert habe. Meine aber schon.

Gruß

Setzte erstmal die statischen ARP Einträge, denn sollte es gegessen sein.
NIC Treiber nochmal überprüfen.

Gruß und viel Erfolg, Quentoo

HI

Ev kannst das mal testen:

http://blogs.technet.com/b/askperf/archive/2010/03/25/the-curious-case- ...

Grüße
Chris

Die VPN ist laut Aussage des Benutzers noch vorhanden,

Woher meint der benutzer das zu wissen ??
Wie hat er das geprüft ?

Bei Cisco wäre es so das dass Schloss unten noch Vorhanden ist und wenn man den VPN Client aufmacht sollte man es immer sehen.

Also da denke ich das dass der Benutzer sehen könnte.

Gruß, Quentoo

Hallo,

Hab grade Ausversehen deinen Beitrag als Lösung markiert, das war natürlich noch nicht der Fall.

Konnte den Fehler grade selbst nachvollziehen, habe grade noch die Logs am Server geprüft und Zack war die Verbindung weg. Per Konsole vom Hyper-V drauf geschaut und sie an ein BSOD... Bin ja gerade etwas sprachlos.

Jetzt kann man wenigstens den Fehler schon mal eingrenzen, wird vermutlich dann ein Treiber Problem sein oder? Zumindest vermute ich das beim tcp+ip Fehler.

Lade das Bild bitte einmal bei Administrator hoch. (Beitrag -> Oben im Reiter Bilder)

Gucke mir das denn mal an und äußere mich denn.

Statischen ARP mit Mac und IP schon gemacht. Ebenso die Adresse vom Cluster statisch im ARP eingetragen?

Hi,

hatten mit Hyper-V 2008 R2 auch mal massive Probleme (HP Hardware) - welcher aus dem Netzwerk bzw. von den Hardwarefeatures der Netzwerkkarte auftraten. Nach deaktivierung der Hardwarefeature (TCP Offloading,... ) traten keine Probleme mehr auf:

Script dafür war:

echo "Netsh show current Settings" > C:\netconfig.log
netsh int ip show global >> C:\netconfig.log
netsh int tcp show global >> C:\netconfig.log
echo "===========================" >> C:\netconfig.log
echo "Reconfiguring..." >> C:\netconfig.log
netsh int tcp set global netdma=disabled >> C:\netconfig.log 2>&1
netsh int tcp set global chimney=disabled >> C:\netconfig.log 2>&1
netsh int tcp set global rss=disabled >> C:\netconfig.log 2>&1
netsh int ip set global taskoffload=disabled >> C:\netconfig.log 2>&1
netsh int tcp set global autotuninglevel=disabled >> C:\netconfig.log 2>&1
netsh int tcp set global congestionprovider=none >> C:\netconfig.log 2>&1
netsh int tcp set global ecncapability=disabled >> C:\netconfig.log 2>&1
netsh int tcp set global timestamps=disabled >> C:\netconfig.log 2>&1

ARP Eintrag habe ich schon gemacht. Aber der wird es ja dann vermutlich nicht sein wenn der Server noch ganz andere Probleme hat.

Das sieht wirklich eher nach einem Treiberproblem aus. Mal nach Neuerungen geschaut?
Welche Hardware habt ihr im Einsatz?

Hyper-V 2008 R2 auf neuer Hardware und frisch installiert
Der SBS wurde auch neu installiert, nur der Terminalserver ist vom alten Hyper-V auf den neuen umgezogen.

Zitat von @semperf1delis:

Hyper-V 2008 R2 auf neuer Hardware und frisch installiert
Der SBS wurde auch neu installiert, nur der Terminalserver ist vom alten Hyper-V auf den neuen umgezogen.

HP Hardware?

Gruß, Quentoo

Bei Cisco wäre es so das dass Schloss unten noch Vorhanden ist und wenn man den VPN Client aufmacht sollte man es immer sehen.

So so...das ist also das Troupbleshooting was er macht ?? Wie siehst denn aus mit der internen und externen IP Adressierung im Tunnel selber ?
Was sagt das VPN Log auf Client und Server ? Ist die IPsec Phase 1 und 2 wirklich noch aktiv ?

Hab grade Ausversehen deinen Beitrag als Lösung markiert, das war natürlich noch nicht der Fall.

Und...warum machst du es nicht rückgängig ?? Kannst DU als TO doch mit einem Mausklick machen !

Nein Wortmann. Deutscher OEM

- 2x Intel Xeon E5-2620v2
- Mainboard Intel S2600CP4
- LSI 9271-8i
- 4x 900GB SAS
- 4x 8 GB RAM (Samsung)

Also, wir gehen mal davon aus, dass er ein Cisco End-to-Side via SSL hat. Er kann die VPN Verbindung ja auch immer wieder aufbauen um sich ganz sicher zu gehen, sollte man vielleicht mal einen NSLOOKUP oder einen ICMP-Paket auf einen Internet Server absetzen, am besten auf einen, auf dem man gerade drauf war, als die Verbindung abbrach.

1. Verbindung VPN herstellen.
2. Verbindun mit RDP(WTS o.ä).
3. Warten bis die Verbindung abbricht.
4. ICMP oder NSLOOKUP auf den Server absetzen, wo die Verbindung abbrach.

Welche RDP Softwareversion hast du im einsatz?
Hast du Bitmapcaching enabled?

Wie sehen deine übrigen RDP-Konfigurationen aus?

Zitat von @aqui:

> Bei Cisco wäre es so das dass Schloss unten noch Vorhanden ist und wenn man den VPN Client aufmacht sollte man es immer
sehen.
So so...das ist also das Troupbleshooting was er macht ?? Wie siehst denn aus mit der internen und externen IP Adressierung im
Tunnel selber ?
Was sagt das VPN Log auf Client und Server ? Ist die IPsec Phase 1 und 2 wirklich noch aktiv ?
> Hab grade Ausversehen deinen Beitrag als Lösung markiert, das war natürlich noch nicht der Fall.
Und...warum machst du es nicht rückgängig ?? Kannst DU als TO doch mit einem Mausklick machen !

Oh Entschuldigung das ich nicht wusste das es möglich ist. Geht auch ein bisschen freundlicher oder!?
Die VPN habe ich selbst am laufen, und sie läuft... Außerdem zeigt der Lancom Client einem an ob sie steht oder nicht, der Benutzer spricht auch eine Website über den Tunnel an, die Terminalserver unabhängig ist.

Und falls du es noch nicht gelesen hast der Server wandert in nen Bluescreen was vermutlich dann die Ursache ist.

Also nochmal zusammen gefasst:

-> VPN schließe ich aus da die Konfig bei mir einwandfrei läuft und bei dem Benutzer auch, siehe Website die immer per Tunnel erreicht werden kann
-> Weitere VPN's laufen auch einwandfrei
-> Server produziert sporadisch Bluescreen
-> Ich habe F-Secure deinstalliert und nochmal neu installiert
-> Integrationsdienste auch neu installiert

Zitat von @semperf1delis:
Und falls du es noch nicht gelesen hast der Server wandert in nen Bluescreen was vermutlich dann die Ursache ist.

Speicherfehler kannst du auch zu 100% ausschließen? (ECC Check etc.)

Zu der freundlichkeit meines Vorposters wollte ich mich nicht äußern, schließe mich deiner Aussage aber an.

Zitat von @semperf1delis:
Lancom ...

IPSec Lancom?
Versuche mal bitte die verschlüsselung von der RDP auszulassen!

Mainboard Log werde ich grade mal auslesen.

Ja IPsec Lancom.

Zitat von @semperf1delis:

Ja IPsec Lancom.

Denn versuche mal bitte die Verschlüsselung der RDP auszulassen. Passieren diese Probleme auch im lokalen Netz?
Mein Kollege meinte gerade noch, dass es entweder ein defekter Speicherblock oder falscher Pointer sein kann. (lt. DumpFile)

Du solltest die RDP-Verschlüsselung weglassen, denn kann es sein, dass der Pointer nicht angesprochen wird.

Gruß, Quentoo

Nein intern treten diese Probleme nicht auf.

Log ist grade an den Hersteller zur Analyse rausgegangen.

"Defekter Speicherblock oder falscher Pointer"
Wie muss ich das verstehen? Das geht schon eher in die Materie wo ich mich nicht mehr auskenne. Betrifft das RAM, VHD oder Windowstreiber?

Danke für die Hilfe!

Zitat von @semperf1delis:

Nein intern treten diese Probleme nicht auf.

Log ist grade an den Hersteller zur Analyse rausgegangen.

Erzähle denn mal, was bei raus gekommen ist.

"Defekter Speicherblock oder falscher Pointer"
Wie muss ich das verstehen? Das geht schon eher in die Materie wo ich mich nicht mehr auskenne. Betrifft das RAM, VHD oder
Windowstreiber?

Pointer = betrifft Treiber oder Software; Speicherdefekt = RAM

Danke für die Hilfe!

Kein Thema, dafür gibt es das hier.

Btw.: Hast du es ohne RDP-Verschlüsselung ausprobiert? Mach das mal noch, danach heißt es denn abwarten was der Hersteller sagt. Welcher ist es denn? HP?

Hersteller hat das Log geprüft: keine physikalischen Speicherfehler.
Den physikalischen Teil könnten wir dann damit ausschließen.

Hatte oben schon mal geschrieben das der Hersteller Wortmann ist.
Ist ein deutscher OEM. Hier die Daten des Servers :

- 2x Intel Xeon E5-2620v2
- Mainboard Intel S2600CP4
- Raidcontroller: LSI 9271-8i
- 4x 900GB SAS (Hitachi)
- 4x 8 GB RAM (Samsung)

Wo kann man die Verschlüsselung komplett deaktivieren? In der Terminaldienstekonfiguration kann ich sie nur auf Niedrig stellen.

Zitat von @semperf1delis:
Wo kann man die Verschlüsselung komplett deaktivieren? In der Terminaldienstekonfiguration kann ich sie nur auf Niedrig
stellen.

So war es denn auch gemeint, stelle sie mal auf ganz niedrig. Probiere es denn erneut. Dienst neustarten.

Das kann ich leider erst gegen Abend umstellen, momentan sind alle noch auf dem TS am arbeiten.

Das kenne ich, wäre hier genau das selbe.

Hallo,

So jetzt habe ich vermutlich den Bluescreen Verursacher gefunden. Da die normale Dump Datei mir nicht weiter geholfen hat, habe ich den "Verifier" von Windows eingeschaltet und den Server einmal neugestartet -> Bluescreen 0xC4 -> Verifier hat einen Treiber gefunden der Streß macht.

Probably caused by : evserial.sys ( evserial+10455 )

FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: evserial+10455
MODULE_NAME: evserial
IMAGE_NAME: evserial.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 48317a24
STACK_COMMAND: kb
FAILURE_BUCKET_ID: X64_0xc4_32_evserial+10455
BUCKET_ID: X64_0xc4_32_evserial+10455
Followup: MachineOwner

Eine kurze Google Suche später konnte ich die Datei auf ein Programm von Eltima Software zurückführen, was COM-Port Weiterleitungen managen kann. Da dieses sowieso nicht mehr benötigt wird, hat es sofort seinen Weg ins Daten-Nirvana gefunden.

Ich stelle nun nochmal die RDP Sicherheit auf Niedrig. Mal schauen ob der Fehler immer noch auftritt.

Wir bleiben gespannt. Habe aber schon mit einem Treiberproblem gerechnet.

Guten Morgen,

und was ergab das Werken gestern noch? Alles wieder im Lot?

Grüße, Patrick

Wollte auch grade schreiben.
Leider nein, der Benutzer ist grade noch außer Haus aber ich habe schon die Info bekommen das die RDP wohl wieder abgestürzt ist.

Bin etwas ratlos, bis der neue DC (SBS 2011) kam, lief der Server mit RDP einwandfrei. Könnte das mit einer Gruppenrichtlinie zusammen hängen?

Was mir noch aufgefallen ist, der Terminalserver spuckt im System Log unzählige Male die gleiche Fehlermeldung aus.
"Die Remotesitzung von Client a hat die maximal zulässigen Anmeldeversuche überschritten. Die Sitzung wird abgebrochen."

Auch heute Morgen im 30 Sekundentakt.

Jeh nach dem, was hast du denn für Gruppenrichtlinien?

LowLevelEncryption hast du enabled? Was gibt es denn für einen Crashlog auf dem PC von dem Mitarbeiter? Hast du das von zu Hause auch, wenn du dich drauf schalten möchtest?

Grüße, Quentoo

Standard Richtlinien. Habe dort nichts vorgenommen außer das automatische Verbinden von Netzlaufwerken.

Das Niedrige Verschlüsselungslevel habe ich auch eingerichtet.
Das Log bei Mitarbeiter hat so ziemlich gar nichts von sich gegeben. Auch jetzt sehe ich auf dem TS keinelei Einträge was mir das Verhalten erklären könnte.
Außer diese Sicherheitsmeldungen:

Den Terminalserver benutzen höchstens 4-5 Benutzer gleichzeitig.

EDIT: Es scheint so als ob die Benutzer ständig an- und abgemeldet werden. Im Abstand von Sekunden. Dieser Benutzer arbeitet zum Beispiel nur intern und beklagt sich nicht über Verbindungsabbrüche. Vielleicht wirkt sich das bei der VPN anders aus? Ich nehme auch an das dies so nicht der Standardfall ist mit dem ständigen An und Abmelden.

Zitat von @semperf1delis:
Vielleicht wirkt sich das bei der VPN anders
aus? Ich nehme auch an das dies so nicht der Standardfall ist mit dem ständigen An und Abmelden.

Ja, dass kann gut sein, da er für gewöhnlich länger brauch als im internen Netz. Melde mich später nocheinmal genauer.

Grüße, Quentoo

Moin moin!
Vielleicht habe ich eben einfach überlesen ob sich dazu jemand schon geäußert hat, aber vielleicht ist es ein Denkanstoss für eine weitere Fehlerquelle:

Ich hatte so einen ähnlichen Fall auch schon mal selbst gehabt.
Da hat mich eine über PPTP aufgebaute RDP-Sitzung ständig rausgeworfen und die Sitzzung neu aufgebaut.
Das passierte auch in etwa alle halbe Minute.

Das Problem war zu dem Zeitpunkt, dass auf der NW-Karte des Clients zwei Subnetze konfiguriert waren.
Nachdem ich das unter "erweiterte TCP/IP-Einstellungen" aufgenommene Netz wieder rausgenommen hatte, war das Problem erledigt.
Kannst ja mal schauen ob das bei dir ähnlich ist.

Naja, es bricht ja ab mit BlueScreen, dh. hinter diesem Verbindungssabbruch steckt noch ein wenig mehr ausser Paketloss. Semper, hast du mittlerweile neue Informationen bzgl. deines Falles?

Zitat von @semperf1delis:

Standard Richtlinien. Habe dort nichts vorgenommen außer das automatische Verbinden von Netzlaufwerken.

Das Niedrige Verschlüsselungslevel habe ich auch eingerichtet.
Das Log bei Mitarbeiter hat so ziemlich gar nichts von sich gegeben. Auch jetzt sehe ich auf dem TS keinelei Einträge was mir
das Verhalten erklären könnte.
Außer diese Sicherheitsmeldungen:

Den Terminalserver benutzen höchstens 4-5 Benutzer gleichzeitig.

EDIT: Es scheint so als ob die Benutzer ständig an- und abgemeldet werden. Im Abstand von Sekunden. Dieser Benutzer arbeitet
zum Beispiel nur intern und beklagt sich nicht über Verbindungsabbrüche. Vielleicht wirkt sich das bei der VPN anders
aus? Ich nehme auch an das dies so nicht der Standardfall ist mit dem ständigen An und Abmelden.

Ist der Rechner bei dem die abbrüche kommen in der Domäne? Wenn Ja; setze ihn mal wieder in eine A-G und denn wieder in die Domäne. Ist mit deinem Profil alles i.O?

Zitat von @Linuxa:

Naja, es bricht ja ab mit BlueScreen, dh. hinter diesem Verbindungssabbruch steckt noch ein wenig mehr ausser Paketloss. Semper,
hast du mittlerweile neue Informationen bzgl. deines Falles?

Jipp, hab ich gelesen, war ja nur als weiterer Ansatz gedacht ;)

So sorry für die späte Rückmeldung. Die Arbeit hat mich abgehalten...

Den Bluescreen hatte ich ja schon gelöst. Das war ein fehlerhafter Treiber.

Wahrscheinlich war das Problem ein ganz anderes. Da ich mir das Problem leider nicht in dem Homeoffice selbst anschauen konnte, bzw. nicht ständig bei dem Benutzer in der Bude hocken kann habe ich mich auf die Erläuterung des Problems verlassen.
Nicht das ich mir das Problem nur einmal habe erklären lassen, mindestens dreimal habe ich nachgefragt wann der Fehler auftrifft, wie er sich äußert und was er grade gemacht hat.

Erst nachdem ich langsam an mir und dem Server gezweifelt habe ich mir die Fehlerbeschreibung nochmals erklären lassen.
Der Benutzer macht seinen Laptop an, schaltet die VPN an und verbindet sich kurz auf den Terminalserver. Wenn er nach 5 Minuten seine Einträge gemacht / geprüft hat lässt er den Laptop so stehen. Dann würde er vielleicht einmal halbe bis dreiviertel Stunde später nochmal an den Laptop gehen und das gleiche Spielchen nochmal machen.

Da dämmerte es mir langsam... Der Laptop oder wegen mir auch der Netzwerkadapter geht in den Energiesparmodus!!! Der Benutzer hängt ihn auch nicht an den Strom, warum auch er hat ja nen Akku der lange hält. So verabschiedet sich die VPN und die RDP, die VPN wird vermutlich VPN Client abhängig beim reaktivieren wieder verbunden und er sieht die VPN als "grün". Natürlich hat sich die alte RDP weggehangen... Was ich ihr auch nicht übel nehme.

Manchmal ist es wirklich zum heulen, vor allem dann wenn man ein völlig falsches Fehlerproblem vor die Nase gesetzt bekommt. " Die RDP bricht immer ab wenn ich verbunden bin" Dieser Benutzer arbeitet eigentlich schon sein halbes Berufsleben mit VPN, RDP und Computern...

Trotzdem danke für eure Hilfe. Energiespareinstellungen aus und ihm gesagt er soll einfach mal das Ladegerät dran hängen und siehe da es geht...

Verzweifelte Grüße