UltraVNC über VPN funktioniert nicht bei WIN2k

Hallo,

benutze für die Fernwartung UltraVNC über einen VPN-Tunnel, erstellt mit Windows Bordmitteln. Das klappt mit XP wunderbar. Probiere ich die Gleiche Verbindung, vom selben Netz ins selbe Netz, aber von einem WIN2k-Rechner aus, kommt erst die Passwortabfrage und daraufhin "Startbildschirm wird geladen"................Bis heute

.
Das verhält sich bei 3 getesteten WIN2k-Rechnern so. UltraVNC macht auf selbigen aber keinerlei Probleme, wenn ich eine Verbindung im lokalen Netz ohne VPN einrichte. Die Konfiguration auf den XP- bzw. WIN2k-Rechnern ist absolut identisch.

Hmmhh???

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

Content-ID: 59618

Url: https://administrator.de/contentid/59618

Ausgedruckt am: 19.11.2024 um 22:11 Uhr

12 Kommentare

Neuester Kommentar

Hallo,

wenn Du über VPN den VNC nutzt, nimmst Du dann den Namen oder die IP des Rechners den Du steuern willst?

Wir haben bisweilen Probleme mit dem Namen und nehmen daher nur noch die IP, wenn wir über das VPN reinkommen.

Greetings, Ollie

Hört sich nach falschen MTU-Wert der VPN-Verbindung an.
Wenn die Pakete so groß sind, das sie nur durch Aufteilung bzw. Fragmentierung durch den VPN-Tunnel
geschleußt werden können, werden die Header der Pakete geändert und damit durch IPSEC als "invalid" abgestempelt...

Eine Verkleinerung der MTU-Werte vermeidet solche Fragmentierungen.

CU,
TBW

Sehr wahrscheinlich ein MTU Problem der 2k LAN Adapter. (Mein Vorgaenger war schneller

)Sofern es da keinen Patch in der MS Knowledgebase gibt solltest du das mal mit Dr. TCP auf einen kleinerern Wert (z.B. 1440) customizen und nochmal testen.
http://www.dslreports.com/drtcp

Danke erst mal, aber Das war es wohl nicht (MTU). Habe mich langsam mit:

ping -l >MTU< -f >IP-Adresse<

an den maximalen MTU-Wert herangetastet, bis die Pakete nicht mehr fragmentiert wurden.
Diesen dann anschließend in der Registry bei entsprechendem Adapter eingetragen. Aber UltraVNC bleibt weiter hartnäckig beim Laden des Startbilschirmes hängen.

Danke erst mal, aber Das war es wohl nicht
(MTU). Habe mich langsam mit:

ping -l >MTU< -f >IP-Adresse<

an den maximalen MTU-Wert herangetastet, bis
die Pakete nicht mehr fragmentiert wurden.
Diesen dann anschließend in der
Registry bei entsprechendem Adapter
eingetragen. Aber UltraVNC bleibt weiter
hartnäckig beim Laden des
Startbilschirmes hängen.

An welchen Adapter ???
Und welche Windows-Boardmittel für VPN? IPSEC, PPTP oder sonstwas ??

CU,
TBW

An welchen Adapter ???
Und welche Windows-Boardmittel für VPN?
IPSEC, PPTP oder sonstwas ??

Am virtuellen Adapter der VPN-Verbindung über PPTP ist eine MTU von Null eingestellt, laut Microsoft wird dann der kleinstmöglichste Wert genommen. Und Hardwareseitig habe ich es auch probiert, sprich am LAN-Adapter des W2k-Rechners den MTU-Wert zwischen 1100 und 1200 eingestellt.

Im Augenblick weiß ich jetzt auch nicht weiter.
Kann eventl. auch an UVNC liegen. Aber das ist jetzt nur eine Vermutung.

Cu,
TBW

Was noch komisch ist, habe mich gerade mal von einem W2k-Rechner aus per UltraVNC auf einen Windows Server 2003 in besagtem Netz verbunden. Da klappt die Verbindung dann, nicht jedoch auf die Workstations (XPPro).
Diese Erkenntnis macht es mir jedoch nicht gerade einfacher, denn sie lässt bei mir die Frage aufkommen, ob es auch am Zusammenwirken von Client und Server liegt. Und nicht nur Clientseitig Einstellungen anzupassen sind, um das Zusammenwirken von W2k-Rechnern mit XP-Rechnern über UltraVNC zu ermöglichen.

Der Length Wert bei einem Ping hat rein gar nichts mit dem MTU Wert zu tun. Damit erreichst du nichts, der betrifft ja nur deinen PC und nicht den kompletten Pfad zum Ziel.

Der Length Wert bei einem Ping hat rein gar
nichts mit dem MTU Wert zu tun. Damit
erreichst du nichts, der betrifft ja nur
deinen PC und nicht den kompletten Pfad zum
Ziel.

Verstehe ich nicht, ich pinge doch das Zielnetz. Und ausserdem liegt das Problem ja wohl offensichtlich bei meinem Rechner, da es wie gesagt mit XP funktioniert.

Vermutlich bleibts dabei das das ein Problem der MTU Einstellung des Adapters ist. 2k ist bekannt dafür. Entweder Dr. TCP oder auch:

http://www.aidex.de/software/improve-tcp/

sollte das Problem ggf. fixen.