RDP Problem über VPN

[Overon 10]

Hiho..

 

geh mal bitte auf den Bintec und geb am Prompt ...debug all ein.

 

Dann starte die rdp Verbindung. Schon solltest Du ein Menge Informationen bekommen, die Du ja hier posten könntest.

 

Weiterhin kannst Du am Bintec auch noch die SIF ausschalten. Zu finden unter Security.

 

 

 

Gruss Over

[dalmatino 10]

Hallo und danke schon mal,

 

das Debug all, bringt mir nicht viel. Dort wird nichts von der Client-IP oder dem Server protokolliert. Zumindest finde ich die IP's dort nicht.

 

SIF ist für der Port 3389 (TerminalService) freigeschaltet.

[dalmatino 10]

Ach und noch was; ich habe gerade ma versucht auf unseren WebRemoteServer zuzugreifen (SBS). RDP via HTTPS. Läuft sofort. Habe ich einen VPN-Tunnel offen, geht es nicht mehr....kurios!

[sturmtiger 10]

Hi Ihr...

 

MTU für T-Online ist 1492... Der Speedport nimmt automatisch 1492, wenn man ihm sagt, dass er T-Online-Zugangsdaten hat...

 

FB weiß ich grad nicht genau, müsste aber auch machbar sein...

 

Ich würd mal versuchen, den Port 3389 gezielt auf die Workstation zurück forwarden zu lassen... oder einfach mal die integrierte Firewall der Geräte komplett abzuschalten...

 

Wenn Du sagst, dass Ping und Freigaben funktionieren, KANN's eig. nurnoch ne Einstellungssache sein... :confused:

 

Gruß,

Alex

[grizzly999 11]

Das ist unter Garantie ein MTU-Problem.

 

Stelle mal die MTU Size auf den Rechnern herunter, notfalls recht weit. Du kannst das ja mal mit einem ping testen, wo er nicht mehr fragmentieren muss:

ping <Zielrechner> -l 1492 -f

Setze den blau markierten Wert schrittweise herunter, bis er nicht mehr meint, dass das Paket fragmentiert werden müsse, nimm den wert als MTU-Size, und siehe, es klappt mit RDP ;)

 

grizzly999

[grizzly999 11]

Nachtrag: der RegistryWert EnablePMTUBHDetect auf allen Rechnern, sollte es auch erledigen, hat bei mir jedenfalls immer geklappt (Recommended TCP/IP settings for WAN links with a MTU size of less than 576.

Aber die oben angebene Methode sollte man mal machen, damit man weiß, dass es daran liegt, und worum es letztlich geht.

 

grizzly999

[sturmtiger 10]

Kurze Info... In dem W501V tut auch AVM-Hardware ihren Dienst :suspect: Hat nur ne T-Com-Firmware drauf... man könnte aber auch wieder AVM-Firmware draufknallen (google verrät mehr darüber).

 

@grizly999:

Ne kurze - wenn auch vlt. dumme Frage - wenn ich beim nem Ping den MTU einstelle, gilt der dann nicht bloß für den Weg vom Client zum Router (bzw. wenn man ein DSL-MODEM hat, dann auch WAN)? Vom Router zum Endpunkt (also über WAN) regelt doch der Router?! Oder nicht?

 

Gruß,

Alex

[grizzly999 11]

@grizly999:

Ne kurze - wenn auch vlt. dumme Frage - wenn ich beim nem Ping den MTU einstelle, gilt der dann nicht bloß für den Weg vom Client zum Router? Vom Router zum Endpunkt (also über WAN) regelt doch der Router?! Oder nicht?

 

Gruß,

Alex

Das ist das Problem. Wenn dazwischen irgendwo noch VPN-Strecken sind, die du gar nicht kennst, und jedesmal noch zusätzliche Header drankommen, oder kleinere MTU Sizes dazwischen sind, muss das Paket fragmentiert werden. Manche Router schicken dann aber kein ICMP Destination Unreachable (Code =x=D) zurück (siehe auch: Internet Control Message Protocol "Destination Unreachable" (Code = 0x0D) Packets) und verwerfen das Paket einfach, sog. Black Holes.Der Client weiß dann gar nicht, dass er das Paket fragmentieren müsste. Daher entweder die MTU Size klein genug machen, oder die Black Hole Detection einschalten.

 

grizzly999

[sturmtiger 10]

Das ist das Problem. Wenn dazwischen irgendwo noch VPN-Strecken sind, die du gar nicht kennst, und jedesmal noch zusätzliche Header drankommen, oder kleinere MTU Sizes dazwischen sind, muss das Paket fragmentiert werden. Manche Router schicken dann aber kein ICMP Destination Unreachable (Code =x=D) zurück (siehe auch: Internet Control Message Protocol "Destination Unreachable" (Code = 0x0D) Packets) und verwerfen das Paket einfach, sog. Black Holes.Der Client weiß dann gar nicht, dass er das Paket fragmentieren müsste. Daher entweder die MTU Size klein genug machen, oder die Black Hole Detection einschalten.

 

grizzly999

 

Und wieder was gelernt :) Danke!

 

Und wie wäre es mit nem VPN-Router als Lösung? Gibt ja mittlerweile "billige" Lösungen (Netgear)... Wir haben uns jetz nen Speedport 400P angeschafft... Bis jetzt keine Probleme, arbeitet (nach anfänglichen Schwierigkeiten) auch mit dem Netgear zusammen...

 

Gruß,

Alex

[dalmatino 10]

Hallo Leute, danke für die Antworten.

 

Wie erwähnt, weiß ich, dass es sich bei dem Speedport und ein Fritzbox äquivalent handelt.

Auf der gegenstelle ist, wie aus dem Beitrag zu entnehmen ist, ein VPN-Router installiert.

 

Ich habe m.W. den MTU-Wert geändert. Habe dann aber auch noch mal TuneUp, den optimalen MTU-Wert einstellen lassen. Ich selber hatte den Wert auf 1372 geändert.

 

Leider hab ich mir gestern die Teamviewer-Session gekillt und konnte es nicht mehr testen.

 

Grüße

[sturmtiger 10]

Leider hab ich mir gestern die Teamviewer-Session gekillt und konnte es nicht mehr testen.

 

Ist doch auch mal was ;)

 

Das klappt schon irgendwie!

[Jian 10]

Hallo dalmatino,

 

wie ist jetzt der Stand? Hat eine der Antworten zum Erfolg geführt?

Hab im Moment das selbe Problem und such ne Lösung.

 

Danke für die Info.

 

Gruß

 

Jian

[dalmatino 10]

Hi Jian,

bisher konnte ich es leider nicht wieder testen.

Gebe aber Bescheid.

 

Gruß

[hegl 10]

Schau mal, ob auf dem Server der Patch zu MS05-041 installiert ist. Der müsste dafür verantwortlich sein. Wir hatten das gleiche Problem über IPSec bei einer CISCO PIX und anschließend auch bei der CISCO ASA. Zum Glück hat die ASA jetzt ein feature um dieses Pre-Fregmentation zu beeinflussen und sind so aus der Sache rausgekommen.

 

Nach meinen Recherchen müsste die Ursache aber am o.g. Patch liegen!

[dalmatino 10]

Hallo Hegl,

 

die Frage ist nur, wieso andere Clients keine Probleme damit haben. Wenn ich mich von hier (ausm Büro) bei unserem Kunden einwähle, fluppt es ja tadellos.