32551
Aug 10, 2006, updated at Mar 21, 2009 (UTC)
13162
11
0
Beitritt zu einer Domäne über VPN-Tunnel (2 x netgear FVS318) geht nicht, da der Domänencontroller nicht gefunden werden kann
Hallo,
ich habe das problem, das ich nicht der Domäne über eine VPN-Tunnel beitreten kann, da, laut fehlermeldung, der keine Verbindung mit dem Domänencontroller hergestellt werden kann. Die rechner lassen sich jedoch in beide Richtungen anpingen.
Hier zur technischen Konstellation:
Client IP 192.168.2.10
VPN-Router IP 192.168.2.1
(Internet)
VPN-Router IP 192.168.1.2
Server (DC) IP 192.168.1.1
Ich kann in beide Richtungen pingen, aber die Domänenanmeldung will komischerweise nicht funktionieren.
Was also kann ich tun?
Außerdem: Wie bekomme ich es hin, dass die Freigaben nach dem Muster \\Server\daten und nicht 192.168.1.1\Daten funktionieren?? Sollte man hierfür einen Hostseintrag vornehmen?
Vielen Dank für Eure Hilfe!!!
ich habe das problem, das ich nicht der Domäne über eine VPN-Tunnel beitreten kann, da, laut fehlermeldung, der keine Verbindung mit dem Domänencontroller hergestellt werden kann. Die rechner lassen sich jedoch in beide Richtungen anpingen.
Hier zur technischen Konstellation:
Client IP 192.168.2.10
VPN-Router IP 192.168.2.1
(Internet)
VPN-Router IP 192.168.1.2
Server (DC) IP 192.168.1.1
Ich kann in beide Richtungen pingen, aber die Domänenanmeldung will komischerweise nicht funktionieren.
Was also kann ich tun?
Außerdem: Wie bekomme ich es hin, dass die Freigaben nach dem Muster \\Server\daten und nicht 192.168.1.1\Daten funktionieren?? Sollte man hierfür einen Hostseintrag vornehmen?
Vielen Dank für Eure Hilfe!!!
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: 37756
Url: https://administrator.de/contentid/37756
Printed on: April 20, 2024 at 03:04 o'clock
11 Comments
Latest comment
Ja das macht Sinn sowohl den PDC als auch den //Server in die hosts Datei unter /windows/system32/drivers/etc beide statisch einzutragen. Damit findet Windows sie schneller und du solltest nicht evtl. in Timeouts laufen.
Wenn du die Datei editierst siehst du die entspr. Syntax.
Wenn du die Datei editierst siehst du die entspr. Syntax.
Hi,
ich habe das selbe Problem, nur habe ich an beiden Seiten einen PDC stehen.
Ich möchte einen freigegeben Ordner auf PDC A auf dem anderen PDC (B) verknüpfen.
Habe versucht über Netzlaufwerk verbinden, dann \\IP-AdressePDC\Freigabename.
Kommt aber ein Error. Kann nicht gefunden werden.
Pings auf beide Server gegenseitig sind möglich.
Woran kann es liegen.
ich habe das selbe Problem, nur habe ich an beiden Seiten einen PDC stehen.
Ich möchte einen freigegeben Ordner auf PDC A auf dem anderen PDC (B) verknüpfen.
Habe versucht über Netzlaufwerk verbinden, dann \\IP-AdressePDC\Freigabename.
Kommt aber ein Error. Kann nicht gefunden werden.
Pings auf beide Server gegenseitig sind möglich.
Woran kann es liegen.
auch wenns schon zu spät ist - wir kämpfen gerade mit einem ähnlichen Problem 
Allerdings haben wir vermutlich die Fehlerquelle erkannt:
FVS318v3 aktuellste Firmware, ipsec-tunnel steht, ping, RDP usw geht problemlos, 2 DCs am Hauptstandort, keine DCs in den Niederlassungen.
Alle Clients in den Niederlassungen können keinen DC finden, obwohl sie per NSLOOKUP und "normalem" Ping auf die DCs kommen und auch auflösen können. Auch der Domänenbeitritt auf der Clientseite war problemlos möglich.
Im Ereignislog kommt die Fehlermeldung "DC nicht erreichbar", unter Win2K Event 1000 und unter XP Event 1054.
So, nach langem Suchen bin ich dahintergekommen: Die Clients schauen bei der Anmeldung zuerst mit einem Ping (ICMP mit Packet-Size 2048, kann man verifizieren mit ping -l 2048 hostname), ob der DC erreichbar ist. Mit einem normalen Ping (packet size 32 bis ca. 1450 bytes) ist der DC erreichbar. Die Clients pingen aber mit einer Paket-Size von 2048 Bytes. Nun wird ein Ping mit einer Packet-Size von 2048 Bytes leider vom ipsec-tunnel bzw. den Routern gedroppt und die Clients melden "DC nicht erreichbar", obwohl DNS im Active Directory korrekt konfiguriert ist.
Die Clients können sich untereinander mit einem Ping mit Paketsize 2048 erreichen, nur durch den Tunnel gehen diese Pakete leider nicht.
Auf einer anderen Leitung verwenden wir FVS318v2 (andere Revision), da funktioniert das Problemlos.
Auf eine Lösung dieses Problems sind wir noch nicht gekommen, vermutlich werden wir mal ein Firmware-Downgrade versuchen.
Vielleicht hilfts ja jmd. oder hat evtl. schon jmd. eine Lösung parat ?
Allerdings haben wir vermutlich die Fehlerquelle erkannt:
FVS318v3 aktuellste Firmware, ipsec-tunnel steht, ping, RDP usw geht problemlos, 2 DCs am Hauptstandort, keine DCs in den Niederlassungen.
Alle Clients in den Niederlassungen können keinen DC finden, obwohl sie per NSLOOKUP und "normalem" Ping auf die DCs kommen und auch auflösen können. Auch der Domänenbeitritt auf der Clientseite war problemlos möglich.
Im Ereignislog kommt die Fehlermeldung "DC nicht erreichbar", unter Win2K Event 1000 und unter XP Event 1054.
So, nach langem Suchen bin ich dahintergekommen: Die Clients schauen bei der Anmeldung zuerst mit einem Ping (ICMP mit Packet-Size 2048, kann man verifizieren mit ping -l 2048 hostname), ob der DC erreichbar ist. Mit einem normalen Ping (packet size 32 bis ca. 1450 bytes) ist der DC erreichbar. Die Clients pingen aber mit einer Paket-Size von 2048 Bytes. Nun wird ein Ping mit einer Packet-Size von 2048 Bytes leider vom ipsec-tunnel bzw. den Routern gedroppt und die Clients melden "DC nicht erreichbar", obwohl DNS im Active Directory korrekt konfiguriert ist.
Die Clients können sich untereinander mit einem Ping mit Paketsize 2048 erreichen, nur durch den Tunnel gehen diese Pakete leider nicht.
Auf einer anderen Leitung verwenden wir FVS318v2 (andere Revision), da funktioniert das Problemlos.
Auf eine Lösung dieses Problems sind wir noch nicht gekommen, vermutlich werden wir mal ein Firmware-Downgrade versuchen.
Vielleicht hilfts ja jmd. oder hat evtl. schon jmd. eine Lösung parat ?
Die Lösung ist ganz einfach:
Du benutzt eine fehlerhafte MTU Size auf den Routern ! Du solltest die MTU auf 1420 oder niedriger setzen, damit der VPN Overhead nicht Frames größer 1500 Bytes generiert, die außerhalb des Ethernet Standards liegen.
Ein 2048 Byte großer Frame muss zwangsweise fragmentiert werden am Router und scheinbar kann dein Router damit nicht sauber umgehen. Eigentlich sollte er es können und bei der MTU Path Negotiation am Verbindungsaufbau den richtigen Wert an die Endgeräte signalisieren, damit diese eine entsprechende MTU verwenden.
Viele Consumer Router können damit nicht richtig umgehen im VPN Umfeld...leider
Falls dein Router keine konfigurierbare MTU hat (..was ein sehr schlechtes Licht auf den Hersteller wirft !) hast du als Notanker immer noch solche SW wie Dr.TCP http://www.dslreports.com/drtcp
Mit dem kannst du die MTU an den Endgeräten entsprechend anpassen. Keine gute Lösung denn der Router sollte das tun aber fixt wenigstens das Problem !
Du benutzt eine fehlerhafte MTU Size auf den Routern ! Du solltest die MTU auf 1420 oder niedriger setzen, damit der VPN Overhead nicht Frames größer 1500 Bytes generiert, die außerhalb des Ethernet Standards liegen.
Ein 2048 Byte großer Frame muss zwangsweise fragmentiert werden am Router und scheinbar kann dein Router damit nicht sauber umgehen. Eigentlich sollte er es können und bei der MTU Path Negotiation am Verbindungsaufbau den richtigen Wert an die Endgeräte signalisieren, damit diese eine entsprechende MTU verwenden.
Viele Consumer Router können damit nicht richtig umgehen im VPN Umfeld...leider
Falls dein Router keine konfigurierbare MTU hat (..was ein sehr schlechtes Licht auf den Hersteller wirft !) hast du als Notanker immer noch solche SW wie Dr.TCP http://www.dslreports.com/drtcp
Mit dem kannst du die MTU an den Endgeräten entsprechend anpassen. Keine gute Lösung denn der Router sollte das tun aber fixt wenigstens das Problem !
Danke erstmal für die Antwort.
MTU-Size auf beiden Seiten = 1400 eingestellt, ich habe auch schon mit anderen Werten gespielt, leider ohne Erfolg. Bei früheren Firmware-Versionen gabs das Problem noch nicht, auch bei anderen Hardware-Versionen dieses Geräts funktioniert eine ICMP-Size von 2048 Bytes.
Ich bin bereits mit dem Hersteller in Kontakt, mal schauen, was denen noch so einfällt
Das Ergebnis poste ich hier dann...
MTU-Size auf beiden Seiten = 1400 eingestellt, ich habe auch schon mit anderen Werten gespielt, leider ohne Erfolg. Bei früheren Firmware-Versionen gabs das Problem noch nicht, auch bei anderen Hardware-Versionen dieses Geräts funktioniert eine ICMP-Size von 2048 Bytes.
Ich bin bereits mit dem Hersteller in Kontakt, mal schauen, was denen noch so einfällt
Das Ergebnis poste ich hier dann...
Das wäre in der Tat mal spannend zu erfahren was die dazu sagen....
So... nach 2 Wochen hin und her und vielen Versuchen unsererseits folgendes Ergebnis:
Wir haben den FVS318 der am Hauptstandort steht durch eine IPCOP-Firewall ersetzt, und von dort aus den IPSEC-Tunnel aufgebaut. Auf der anderen Seite des Tunnels ein FVS318 v3.20.
Ergebnis: Die Pings (ping -l 2048 Domänencontroller) gehen anstandslos durch, und die PCs auf der anderen Seite können sich durch den Tunnel am DC anmelden.
Weiteres Ergebnis:
Zwischen FVS318 V 2.2 und V3.20 gehen die ICMPs mit Size 2048 durch. Anmeldung an der Windows-Domäne möglich.
Zwischen FVS318 V3.x auf beiden Seiten war nix zu machen. Wir haben mehrere Firmware-Versionen aufgespielt und getestet, leider alles ohne Erfolg. IPSEC-Tunnel steht, ICMP geht bis ca. 2000 Bytes Size durch. Die Clients pingen aber mit 2048 Byte, daher Event ID 1000: Der Domänencontrollername für Ihr Computernetzwerk konnte nicht ermittelt werden. Zurückgegebener Wert (59).
Die Antworten des Supports waren zusammengefasst die folgenden: Man solle Tracefiles mit Wireshark erstellen (obwohl ich vorher mit tcpdump Mitschnitte bereitgestellt hatte). Auf meine Aufforderung, das Problem mal nachzustellen (sollte für einen Hersteller von DSL-Routern ja kein Problem sein) wurde gar nicht reagiert.
Wir haben den FVS318 der am Hauptstandort steht durch eine IPCOP-Firewall ersetzt, und von dort aus den IPSEC-Tunnel aufgebaut. Auf der anderen Seite des Tunnels ein FVS318 v3.20.
Ergebnis: Die Pings (ping -l 2048 Domänencontroller) gehen anstandslos durch, und die PCs auf der anderen Seite können sich durch den Tunnel am DC anmelden.
Weiteres Ergebnis:
Zwischen FVS318 V 2.2 und V3.20 gehen die ICMPs mit Size 2048 durch. Anmeldung an der Windows-Domäne möglich.
Zwischen FVS318 V3.x auf beiden Seiten war nix zu machen. Wir haben mehrere Firmware-Versionen aufgespielt und getestet, leider alles ohne Erfolg. IPSEC-Tunnel steht, ICMP geht bis ca. 2000 Bytes Size durch. Die Clients pingen aber mit 2048 Byte, daher Event ID 1000: Der Domänencontrollername für Ihr Computernetzwerk konnte nicht ermittelt werden. Zurückgegebener Wert (59).
Die Antworten des Supports waren zusammengefasst die folgenden: Man solle Tracefiles mit Wireshark erstellen (obwohl ich vorher mit tcpdump Mitschnitte bereitgestellt hatte). Auf meine Aufforderung, das Problem mal nachzustellen (sollte für einen Hersteller von DSL-Routern ja kein Problem sein) wurde gar nicht reagiert.
Nicht verwunderlich bei Consumer Produkten dieses Herstellers. Im VPN Bereich sollte man daher besser auf Draytek oder andere spezialisierte Hersteller setzen.
Warum du aber auch eigentlich überflüssige Stresstests mit 2048 byte grossen Pings machst erschliesst sich einem nicht, denn das ist eine für Ethernet völlig unübliche Framesize, die ja maximal 1500 byte beträgt. Du zwingst die Maschinen damit zu eine Fragementierung was aber natürlich per se kein Hinterungsgrund für eine fehlerfreie Übertragung sein sollte. Siehe IPCop der das anstandlos richtig behandelt.
Viele billige Consumer Produkte mit einer Quick and Dirty SW die aus diesen Gründen nichts kosten darf weil nur der Preis zählt hat aber gerade in diesem Bereich von Fragmentierung und MTU große Defizite wie die zahllosen Threads hier zu dem Thema bezeugen.
In dem Sektor auf Support geschweige denn einen Fix zu hoffen ist utopisch !
Wenns das denn war bitte
How can I mark a post as solved?
nicht vergessen !
Warum du aber auch eigentlich überflüssige Stresstests mit 2048 byte grossen Pings machst erschliesst sich einem nicht, denn das ist eine für Ethernet völlig unübliche Framesize, die ja maximal 1500 byte beträgt. Du zwingst die Maschinen damit zu eine Fragementierung was aber natürlich per se kein Hinterungsgrund für eine fehlerfreie Übertragung sein sollte. Siehe IPCop der das anstandlos richtig behandelt.
Viele billige Consumer Produkte mit einer Quick and Dirty SW die aus diesen Gründen nichts kosten darf weil nur der Preis zählt hat aber gerade in diesem Bereich von Fragmentierung und MTU große Defizite wie die zahllosen Threads hier zu dem Thema bezeugen.
In dem Sektor auf Support geschweige denn einen Fix zu hoffen ist utopisch !
Wenns das denn war bitte
How can I mark a post as solved?
nicht vergessen !
Der Ping mit 2048 Bytes ist erforderlich, wenn man sich durch den Tunnel an einem Windows- Domänencontroller anmelden will!
Kein ping 2048 --> Keine Anmeldung durch den Tunnel am DC möglich.
Ansonsten wär mir das Gepinge ja wurscht. Aber wenn die Leut sich net an der Domäne anmelden können ist das halt ungenügend.
--> Beitrag auf erledigt setzen --> Das muss derjenige machen, der den Beitrag eröffnet hat.
Gruss, Stefan
Kein ping 2048 --> Keine Anmeldung durch den Tunnel am DC möglich.
Ansonsten wär mir das Gepinge ja wurscht. Aber wenn die Leut sich net an der Domäne anmelden können ist das halt ungenügend.
--> Beitrag auf erledigt setzen --> Das muss derjenige machen, der den Beitrag eröffnet hat.
Gruss, Stefan
Das kann eigentlich nicht sein ! Siehst du dir eine Domänenanmeldung eines Windows Clients einmal mit einem Wireshark Sniffer genau an siehst du das hier kein einziges Packet dieser Größe gesendet wird. Allerdings gibt es welche die nahe an der max. MTU von 1500 sind. Genau das ist aber vermtlich das Problem, da durch die Encapsulierung in ATM bei DSL die MTU schon limitiert auf 1492 ist und ein VPN obendrauf das noch weiter runterdrückt rennt man in MTU Probleme in so einer Situation. Probleme natürlich nur wenn diese VPN Router nicht sauber mit der MTU und einem MTU Path Discovery umgehen können beim Verbindungsaufbau, was bei der NetGear Firmware und diversen anderen wohl der Fall ist.
Das mit den 2048 Bytes stand in einem anderen Forum und deckt sich halt mit meiner Beobachtung und der Lösung des Problems.
Und mit den FVS318 habe ich ICMP-Pakete bis ca. 2000 Byte Size durchgekriegt. OHNE erfolgreiche DC-Anmeldung.
Nun gehen die Pakete > 2000 auch durch und die Anmeldung ist erfolgreich.
ICMP-Pakete werden bei der Anmeldung vom Client zum DC in jedem Fall gesendet, zur Laufzeitmessung und Erkennung einer langsamen Verbindung.
Das Problem wird auch hier beschrieben: Eventid
Allerdings müsste natürlich Wireshark diese Pakete anzeigen - Ich werde morgen mal nen Hub zwischenklemmen und das anschauen.
Und mit den FVS318 habe ich ICMP-Pakete bis ca. 2000 Byte Size durchgekriegt. OHNE erfolgreiche DC-Anmeldung.
Nun gehen die Pakete > 2000 auch durch und die Anmeldung ist erfolgreich.
ICMP-Pakete werden bei der Anmeldung vom Client zum DC in jedem Fall gesendet, zur Laufzeitmessung und Erkennung einer langsamen Verbindung.
Das Problem wird auch hier beschrieben: Eventid
Allerdings müsste natürlich Wireshark diese Pakete anzeigen - Ich werde morgen mal nen Hub zwischenklemmen und das anschauen.
