Kein RDP durch VPN Tunnel

[Bullet 10]

Hallo,

 

ich habe folgendes Problem:

An Standort A steht ein Windows 2003 Server der als Terminal Server arbeitet. Von Standort B sollen 4 Clients durch einen VPN-Tunnel auf den Terminal Server zugreifen. Der VPN-Tunnel wird über einen LinkSys RV082 (Standort A) und einen LinkSys RV042 (Standort B) aufgebaut.

 

Jetzt mal ein paar Daten:

 

Server (Standort A):

- DSL 768

- Windows 2003 Server Standard Edition

- Intel XEON Dual-Core

- 4 x 400 GB (RAID 10)

- Terminal Server (im Lizenzmodus)

 

Clients (Standort B):

- DSL 3000

- Windows XP SP2

- Terminal-Client 256 Farben, Vollbild

 

LinkSys RV082 (Standort A):

- Schlüsselaustausch durch IKE

- Phase 1 Verschlüsselung AES 256 Bit

- Phase 1 Hash MD5

- Phase 2 Verschlüsselung AES 256 Bit

- Phase 2 Hash MD5

- Keep Alive (an)

- Dead Peer Detection (an)

- NetBIOS Broadcast (an)

 

LinkSys RV042 (Standort B):

- siehe LinkSys RV082

 

Bevor der RV042 verbaut wurde stand bei Standort B ein LinkSys BEFSX41 v2.1. Bei diesem gab es leider immer wieder Verbindungsabbrüche. Deswegen wurde er gegen den LinkSys RV042 getauscht. Seitdem der RV042 bei Standort B aufgebaut wurde bleibt zwar der Tunnel konstant bestehen, allerdings ist kein Aufbau der Terminalsitzung durch den Tunnel mehr möglich.

 

Ich kann den Windows 2003 Server durch den Tunnel pingen und auch die Freigaben anzeigen lassen, aber nicht mehr die Terminalsitzung aufbauen.

Wenn ich dir Terminalsitzung durch das Internet aufbaue, funktioniert es sofort, aber nicht durch den Tunnel.

 

Ich habe schon probiert die Verschlüsselung ganz niedrig zu wählen und auch andere Optionen der Router an bzw. ausgeschaltet. Auch das Neustarten des Terminal Servers brachte nur einen kurzen Erfolg. Nach dem Neustart konnte man sich wieder für ein paar Minuten verbinden, danach nicht mehr.

In der Ereignisanzeige des Servers und auch der Clients ist nichts über die Terminal-Dienste protokolliert.

 

Hat jemand eine Idee?

 

Gruß

Bullet

[grizzly999 11]

Dürfte ein MTU Problem sein.

 

Der Server hat SP1? Dann versuche als erstes den Hotfix KB898060 bzw. dort gibt es einen Nachfolger: KB913446

 

Wenn das auch nicht funktioniert, teste vom client aus den Ping mit

 

ping <TS-Server-IP> -l 1500 -f

 

Wenn da die Meldung kommt, das das Paket fragmentiert werden müsste, reduziere die Paketgröße (im ping Befehl der Parameter -l <Paketgräße>) z.B. in 50 Byte Schritten, bis er durchgeht. Dann setze auf dem Server die MTU Size fix auf diese Größe, auf dem Client auch.

 

 

grizzly999

[Bullet 10]

MTU habe ich schon auf 1250 gestellt. Habe ich auch per ping-Befehl ermittelt, daran kann es also nicht liegen.

Trotzdem danke für die schnelle Antwort.

[grizzly999 11]

Welche Fehlermeldung kommt überhaupt?

 

Hast du den HF eingespielt?

 

Hast du schon auf dem Client einen Netzwerkmonitor während des gesamten verbindungsvorganges laufen lassen ?

 

grizzly999

[Bullet 10]

SP Status und Netzwerkmonitor kann ich gerade nicht machen, weil ich nicht bei dem Kunden bin. Da ich aber nachher hin fahre, werde ich das mal testen.

[Bullet 10]

So, ich habe folgendes herausgefunden. Der Windows 2003 Server hat schon SP2 drauf. Mit dem Netzwerkmonitor konnte ich erkennen, dass auf Port 3389 von dem TS-Client zwar Pakete eingehen, aber nachdem der Server versucht hat zu antwortendie Meldung kommt:

 

Destination unreachable (<IP-Adresse des TS-Client>)

 

Ich kann den TS-Client aber vom Server aus anpingen. Außerdem habe ich versucht die Firewalls dazwischen soweit wie möglich und vertretbar zu deaktivieren, aber auch das hat noch keine abhilfe geschafft.

Das komische ist, dass es zwischenzeitlich mal kurz für eine halbe Stunde funktioniert hat. Deswegen kann weitestgehend ausgeschlossen werden, dass es an den Firewalls liegt. Es muss ja aber trotzdem einen Grund haben, dass der Server den Client nicht erreichen kann.

 

Gruß

Bullet

[Bullet 10]

Keiner mehr eine Idee?

[trenas 10]

Hast Du mal Probiert den Port 3389 zu testen, ob der tatsächlich offen ist?

 

Hast zwar einen Tunnel, aber prüfen würde ich mal wirklich ob der Client den TS über den Port erreichen kann.

 

 

Gruß

Trenas

[Bullet 10]

@trenas:

Ja, ich hatte weiter oben schon erwähnt, dass die Pakete vom Client auf Port 3389 zwar beim Terminal Server ankommen, aber die Antwort darauf kommt dann beim Client nicht mehr an.

[grizzly999 11]

Hast du mal einen kompletten Trace des Netzwerkmonitors, vom Verbindungsaufbauversuch bis zur Fehlermeldung aufgezeichnet (mit Angabe der ganzen relevanten IP-Adressen) zum anschauen für mich/alle?

 

grizzly999

[Bullet 10]

Ich fahre heute noch mal zu dem Kunden hin, um der Sache weiter auf den Grund zu gehen. Falls es nicht klappen sollte, werde ich bei der Gelegenheit auch gleich mal ein Protokoll des Netzwerkmonitors speichern und hier posten.

[Bullet 10]

Das Problem ist gelöst.

Es lag doch an der MTU. Im Netzwerkmonitor konnte man erkennen, dass alle Datenpakete ankommen, nur die die wesentlich größer als die anderen waren nicht. Ich habe die MTU zwar schon im Router runtergestellt, aber die Einstellung scheint nur für den Internetzugang beachtet zu werden.

Ich habe jetzt bei dem Terminal Server die MTU kleiner eingestellt und es funktioniert.

 

Trotzdem danke für die Hilfe, bis zum nächsten Problem.

 

Gruß

Bullet

[grizzly999 11]

Ich wusste aus zig-facher Erfahrung, dass es ein MTU-Problem ist, aber du hast so darauf beharrt, dass es keines ist :(

Aber gut, wenn es jetzt funktioniert (und das nächste mal hörst du gleich auf uns ;) :D )

 

grizzly999