7
Domaincontroller über VPN nicht erreichbar
Hallo,
ich habe ein Problem mit der Erreichbarkeit eines XP-Clients mit seiner Domäne.
Der Client (XP-Prof. SP2) ist mit seiner Netgear Prosafe-VPN-Firewall an meine selbige Firewall per VPN verbunden (Dyndns).
Pingen, Laufwerke sharen und DNS-Auflösung über den DC (Server 2003) ist möglich.
Aber beim Versuch die neuen Richtlinien vom DC zu laden, bricht der Client immer mit der Fehlermeldung:
"Domaincontroller ist nicht verfügbar" ab.
Die VPN-Verbindung steht 24 Stunden (Zeit der DSL-Zwangstrennung bei beiden fast gleich).
Selbige Probleme sind im lokalen LAN absolut nicht vorhanden.
Eine Desktop-Firewall, die den Netzverkehr zum DC blocken könnte ist nicht vorhanden.
Kann das etwas mit den nicht ausfürbaren Broadcasts in gerouteten Subnetzen zutun haben ??
Ein kleiner Schubs in die richtige Richtung hilft mir schon sehr weiter.......
ich habe ein Problem mit der Erreichbarkeit eines XP-Clients mit seiner Domäne.
Der Client (XP-Prof. SP2) ist mit seiner Netgear Prosafe-VPN-Firewall an meine selbige Firewall per VPN verbunden (Dyndns).
Pingen, Laufwerke sharen und DNS-Auflösung über den DC (Server 2003) ist möglich.
Aber beim Versuch die neuen Richtlinien vom DC zu laden, bricht der Client immer mit der Fehlermeldung:
"Domaincontroller ist nicht verfügbar" ab.
Die VPN-Verbindung steht 24 Stunden (Zeit der DSL-Zwangstrennung bei beiden fast gleich).
Selbige Probleme sind im lokalen LAN absolut nicht vorhanden.
Eine Desktop-Firewall, die den Netzverkehr zum DC blocken könnte ist nicht vorhanden.
Kann das etwas mit den nicht ausfürbaren Broadcasts in gerouteten Subnetzen zutun haben ??
Ein kleiner Schubs in die richtige Richtung hilft mir schon sehr weiter.......
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 38305
Url: https://administrator.de/contentid/38305
Printed on: April 18, 2024 at 04:04 o'clock
7 Comments
Latest comment
Ich weiß jetzt nicht genau über welchen Weg die Richtlinien geladen werden. Aber evtl. ist da ein wichtiger Port gesperrt?
Ich bin gerade dabei, das ganze mal mit Ethereal zu loggen.
Das komische an der Sache ist, die Zeit wird vom DC als Timeserver übernommen.
Auch das Einbinden (aus der Arbeitsgruppe raus und in die Domäne rein) klappt wunderbar.
Nur halt die Richtlinien (und vielleicht noch was anderes) werden nicht gefunden.
Ich tippe mal auf ein Routing-Problem.
Das komische an der Sache ist, die Zeit wird vom DC als Timeserver übernommen.
Auch das Einbinden (aus der Arbeitsgruppe raus und in die Domäne rein) klappt wunderbar.
Nur halt die Richtlinien (und vielleicht noch was anderes) werden nicht gefunden.
Ich tippe mal auf ein Routing-Problem.
Der Timeserver läuft aber auf jeden Fall auf einem anderen Port.
Haste evtl. beim Routing Teile des Rückwegs vergessen?
Haste evtl. beim Routing Teile des Rückwegs vergessen?
Das ist eine gute Frage.
Muß ich denn noch Extra-Routen angeben??
Normalerweise wird doch alles zum GW geschoben, was nicht ins eigen Subnetz geht.
Das heißt für den Client, das 172.16.140.0 uber VPN 172.15.152.17 zu erreichen ist.
(Vielmehr 0.0.0.0 ist über 172.16.152.17 zu erreichen).
Ob diese Pakete dann ins Internet oder über den VPN-Tunnel gehen müssen, entscheidet doch der Netgear-VPN-Router anhand der Policy.
Muß ich denn noch Extra-Routen angeben??
Normalerweise wird doch alles zum GW geschoben, was nicht ins eigen Subnetz geht.
Das heißt für den Client, das 172.16.140.0 uber VPN 172.15.152.17 zu erreichen ist.
(Vielmehr 0.0.0.0 ist über 172.16.152.17 zu erreichen).
Ob diese Pakete dann ins Internet oder über den VPN-Tunnel gehen müssen, entscheidet doch der Netgear-VPN-Router anhand der Policy.
Normalerweise wird doch alles zum GW
geschoben, was nicht ins eigen Subnetz geht.
geschoben, was nicht ins eigen Subnetz geht.
Korrekt.
Was ich nicht genau verstanden habe. Hast du in beiden Netzen einen VPN-Router? Oder nur im DC-Netz?
Normalerweise braucht man ja nur einen. Der Client baut über ein Programm bzw. über die Windows-Tools eine VPN-Verbindung zu einem VPN-Router auf, der sich in einem anderen Netz befindet.
Was ich nicht genau verstanden habe. Hast du
in beiden Netzen einen VPN-Router? Oder nur
im DC-Netz?
in beiden Netzen einen VPN-Router? Oder nur
im DC-Netz?
Ja der Client hat ein DSL-Modem und dahinter den Netgear FVS318.
Das ist ein DSL-Firewall/VPN-Router(macht glaube ich 10 VPN-Tunnel, braucht naber nur einen).
Im DC-Netz steht ein FVS338.
also... da du ja von a nach b und von b nach a pingen kannst ist da erstmal alles OK.
Hab hier was bei MS gefunden: http://support.microsoft.com/kb/832017/DE/
Zitat: "Für die erfolgreiche Anwendung einer Gruppenrichtlinie muss ein Client über die DCOM-, ICMP-, LDAP-, SMB- und RPC-Protokolle eine Verbindung zu einem Domänencontroller herstellen können. Wenn eines dieser Protokolle nicht verfügbar ist oder zwischen dem Client und dem entsprechenden Domänencontroller blockiert ist, wird die Richtlinie nicht angewendet oder aktualisiert. Für eine domänenübergreifende Anmeldung, bei der sich Computer und Benutzerkonto in unterschiedlichen Domänen befinden, sind diese Protokolle möglicherweise nötig, damit der Client, die Ressourcendomäne und die Kontendomäne kommunizieren können. ICMP wird für die Erkennung langsamer Verbindungen verwendet. "
Hab hier was bei MS gefunden: http://support.microsoft.com/kb/832017/DE/
Zitat: "Für die erfolgreiche Anwendung einer Gruppenrichtlinie muss ein Client über die DCOM-, ICMP-, LDAP-, SMB- und RPC-Protokolle eine Verbindung zu einem Domänencontroller herstellen können. Wenn eines dieser Protokolle nicht verfügbar ist oder zwischen dem Client und dem entsprechenden Domänencontroller blockiert ist, wird die Richtlinie nicht angewendet oder aktualisiert. Für eine domänenübergreifende Anmeldung, bei der sich Computer und Benutzerkonto in unterschiedlichen Domänen befinden, sind diese Protokolle möglicherweise nötig, damit der Client, die Ressourcendomäne und die Kontendomäne kommunizieren können. ICMP wird für die Erkennung langsamer Verbindungen verwendet. "
