frosch2065

Hallo nochmal und vielen Dank für die bisherigen Beiträge!

Ich habe jetzt mal wie vorgeschlagen mit den MTU der Clients gespielt und schrittweise abgesenkt, aber auch das hatte keine Auswirkungen auf das merkwürdige Serververhalten.

Heute abend nun habe ich testweise openvpn auf dem Server installiert und was soll ich sagen: Das Teil war in meiner Umgebung zügig ohne Probleme in Betrieb zu nehmen und läuft seit einigen Stunden unter Last stabil.

Der Nachteil ist halt, dass ich erst die Software und die Zertifikate auf den jeweiligen Client schaffen muß, bevor er sich verbinden kann.

Die Windows Bordmittel waren mir insofern symphatischer, weil man damit die Verbindung ohne große Vorbereitung ganz schnell von jeder beliebigen Windows Installation herstellen konnte.

Wenn also noch jemand eine Idee hat...

Tja, da hüllt sich das Gerät in Schweigen.

Leider habe ich auch eine Firmware-Version drauf, die Telnet oder SSH Verbindungen nicht mehr zuläßt, d.h. ich kann nur in den "erlaubten" Einstellungen schauen.

Bevor ich aber die Firmware wechsel: Gibt es ein Tool, mit dem man zumindest den Wert von außen ermittlen kann?

MTU für das LAN= 1500

So, ich war eben mutig (vulgo verzweifelt) und habe den Server als exp.-Host ins Netz gestellt.

Allerdings hat sich dadurch am Verhalten des RAS nichts geändert. Nach Aufruf der zweiten Freigabe wieder keine Antwort vom Server. Ping in Richtung Client funktioniert aber.

Somit kann ich auch den Router als Ursache ausschliessen, denke ich.

Kennt jemand nicht vielleicht doch noch ein paar Schräubchen, z.B. in der Registry, an denen ich drehen könnte?

@czappb

pptp, maximale Verschlüsselung, Windows-Authentifizierung (also Standard Konfiguration)

@Minutourus

Habe ich nichts dran geändert. Dürfte also auf Standart (1500) stehen, was die Ethernetverbindung des Servers zum Router betrifft.

Hallo!

Ich habe einen 2K3 server als vpn-server hinter einem DSL-Router (Siemens SE515) eingerichtet.

Mit einem XP-Client kann ich mich auch problemlos von außen einwählen (getestet mit 54k-Modem und DSL-Modem). Dabei funktioniert zunächst sowohl der Zugriff auf die Freigaben aller Rechner im lokalen Netz, als auch die Namensauflösung.

Das belegt eigentlich, dass der Tunnel zunächst korrekt aufgebaut wird.

Allerdings hält das Vergnügen jeweils nur wenige Minuten an. Danach besteht die Verbindung eigentlich noch weiter, nur der RAS antwortet dem Client nicht mehr. Es geht dann nichts mehr, noch nicht einmal ein ping auf die ip des vpn-servers. Umgedreht kann ich den Remote-Client aber aus dem lokalen Netz noch anpingen.

Vorher hatte ich im selben Netz einen XP-Rechner provisorisch als VPN-Server betrieben. Der funktionierte im identischen Umfeld (Nur bei LAN-Spielen war er etwas wählerisch).

Desktop-Firewalls sind nicht installiert, der Windows Firewalldienst ist jeweils deaktiviert.

Firewall auf dem Router ist aktiv, VPN-Port wird auf den Server geroutet.

Nachdem ich jetzt an allen Schräubchen der Konfigurationsoberfläche des RAS gedreht habe, ohne das sich etwas zum Besseren verändert hätte, fällt mir nichts mehr ein.

Any ideas?

Hallo!

Also die Sache hat sich für mich zumindest aus der Sicherheitsperspektive geklärt:

Tatsächlich werden diese DHCP-Anforderungen generiert, wenn man das Serverkonfigurationstool im Server 2003 für das Management der Serverrollen verwendet.

Bei jedem Aufruf dieses Tools prüft dies zunächst das Netzwerk, in dem der Server eingebunden ist.

Bei dieser Prüfung werden diese ominösen DHCP-Lease angefordert.

Dies läßt sich nachvollziehbar testen, wenn man die Liste des fraglichen DHCP-Servers löscht, dann auf dem Server 2003 dieses Managementtool startet und anschließend die DHCP-Liste kontrolliert.

Ich bin allerdings noch nicht dahinter gekommen, welchen Sinn das machen soll. Vielleicht ist es nur eine Methode, die Präsenz eines DHCP-Servers im Netzwerk zu testen?

Hallo!

Mein DHCP hat diese MAC-Adressen ebenfalls protokolliert.

Ich vermute mal, du hast einen Server 2003 im Netzwerk laufen!?

Dies scheint nach meinen Recherchen bisher die einzige Gemeinsamkeit derjenigen zu sein, denen diese DHCP-Lease aufgefallen ist.

Aber ich bin bei der Suche nach der genauen Ursache auch nicht weitergekommen.

Für mein Netzwerk bin ich ziemlich sicher, dass eine Einwirkung von außen nicht stattfinden kann. Server und Clients habe ich mit verschiedenen Scannern bearbeitet, ohne auf Besonderheiten zu stoßen.

Daher geht meine Vermutung in die Richtung, dass sich hier der Server selbst hat IPs zuweisen lassen. Aber wie und warum......?

Hat wirklich keiner eine Idee dazu?

wie wäre es mit dem Starten im abgesicherten Modus und dann einer Systemwiederherstellung oder Deinstallation von StyleXP oder Anlegen eines neuen Users mit Adminrechten?

Gruss

Zu diesem Problem habe ich folgende Lösung gefunden:

Slow logon to domain in XP Pro

You may experience extremely long delays (up to 5 minutes) when logging into domains using Windows XP Pro. This is caused by the asyncronous loading of networking during the boot up process. This speeds up the login process in a stand-alone workstation by allowing the user to log in with cached logon credentials before the network is fully ready.

To disable this "feature" and restore your domain logons to their normal speed, open the MMC and add the group policy snap-in. Under Computer Configuration-->Administrative Templates-->System-->Logon, change "Always wait for the network at computer startup and logon" to ENABLED.

This can be fed to clients via a group policy from a Windows 2000 server by upgrading the standard policy template with the XP policy template. Since this is an XP only command, non-XP systems will ignore it in a domain distributed group policy.

Die Lösung hat bei mir funktioniert!

Grüsse

Das Problem saß, wie so oft so auch in diesem Fall, vor dem Computer :D :D

Die Clients haben zwar eine IP via DHCP erhalten, aber leider nicht von meinem, sondern vom DSL-Router. Somit waren sie im falschen Adressbereich und konnten die Domäne nicht sehen.

Hätte mir auch eher auffallen können :(

Lösung: Im RAS für die Clients DHCP deaktivieren und einen festen IP-Bereich (static Address pool) definieren.

Und schon klappt es wieder mit dem Nachbarn...

Vielen Dank für die vielen Hinweise und Tipps!!!!!!!

Grüsse

Wieso Server und Client in verschiedenen Subnets???

Beide befinden sich im Adressbereich der Domäne, hier 192.168.0.xxx

Nachdem unsere DSL-Leitung seit gestern ziemliche Geschwindigkeitsprobleme hat und es auch zu häufigen timeouts bei der Anwahl von verschiedenen Seiten kommt (nicht nur auf meinem Server, sondern auch bei anderen WST die an dem gleichen DSL-Router hängen), hege ich allmählich die Vermutung, dass die VPN-Probleme auch aus dieser Êcke kommen.

Wenn die Telekom ihre Leitung wieder auf Vordermann gebracht hat, werde ich das Ergebnis hier posten.

Grüsse

eine gültige Adresse aus dem lokalen DHCP-Adresspool der Domäne

Nochmal zur Architektur:

VPN-Client= W2K Workstation mit DSL-Internetanbindung

Server= W2K Server als DC im lokalen Netzwerk, hängt mit 2ter Netzwerkkarte an einem Telekom-DSL-Router, stellt Internet in der Domäne mittels NAT zur Verfügung.

DHCP und DNS Server laufen.

Grüsse

schon passier :-)

\\ip\share klappt auch nicht. Ein ping vom Clint auf den VPN-Server bei bestehender Verbindung endet mit time out.

Somit besteht definitiv eine VPN-Verbindung (sehe ich in Routing und Remote Access), aber trotzdem bleibt der Server für den Client nicht sichtbar.

Hast du evtl. noch eine Idee?

\\name\share

Sollte an der Namensauflösung was nicht stimmen?

Habe hinter einem DSL-Router unter W2K-Server einen VPN-Server eingerichtet.

CLients können nun problemlos die VPN-Verbindung (PPTP) etablieren. Allerdings klappt das Verbinden zu den Freigaben auf dem Server nicht.

Fehlermeldung: "Der Netzwerkpfad XY wurde nicht gefunden"

Alle Remote-Benutzer haben Vollzugriff auf den Freigaben.

Hat jemand eine Idee??

Grüsse