7
Zugriff auf DFS Verweiss via SSL VPN
Hallo Zusammen,
ich habe schon seit längerem ein Problem mit unserem File Server.
Windows 2008
Clients: Vista und Win7
VPN Client: Watchguard Mobile SSL Client
wir haben einen FileServer im Büro stehen. Ich habe aber schon mal für die Zukunft ein paar Name-Spaces angelegt und die Haupfreigaben des Servers da drunter aufgehangen.
Via Gruppenrichtlinien habe ich 2-3 Netzlaufwerke an die Clients verteilt. Natürlich zeigen diese auf den Namespace und nicht direkt auf den Server...
Im Büro angemeldete PCs und Notebook bzw. lokal arbeitende Mitarbeiter haben ÜBERHAUPT keine Probleme.
Wenn sich jemand jedoch von zuhause anmeldet (also mit seinem Firmen Notebook) und dann VPN Verbindung Herstellt und auf die Netzlaufwerke klickt gibt's einen Fehler:
bei dem schwarzen balken steht dann der genaue Pfad des DFS Verweises. Bei uns ist das so:
\\name.der.domäne\blub\freigabe-name1\
wenn ich jedoch direkt den Servernamen und die Freigabe anwähle klappt es direkt.
Ich habe jetzt einen 2ten Server ins DFS rein gebracht und lasse die Daten syncronieren und habe einigen mitarbeiten als Workarround die Laufwerke direkt gemountet aber ich würde das Problem doch gern in den griff bekommen.
Ich vermute sehr stark, dass die Firewall irgendwelche dinge nicht erlaubt oder verarbeitet: vielleicht WINS oder NetBios ..
ich weiß nicht ob das benötigt wird aber DFS über SSL scheint nicht wirklich zu wollen. Aber ich weiß auch, dass nach einen längeren Warterei (etwa 15Min.) auch der DFS Verweis über SSL klappt. aber so lange wartet natürlich keiner und ich bekomme sofort anrufe.
Wäre wirklich cool wenn jemand der einen plan von DFS Kommunikation über SSL-VPN mir hier weiterhelfen könnte.
Viele Grüße
uLmi
ich habe schon seit längerem ein Problem mit unserem File Server.
Windows 2008
Clients: Vista und Win7
VPN Client: Watchguard Mobile SSL Client
wir haben einen FileServer im Büro stehen. Ich habe aber schon mal für die Zukunft ein paar Name-Spaces angelegt und die Haupfreigaben des Servers da drunter aufgehangen.
Via Gruppenrichtlinien habe ich 2-3 Netzlaufwerke an die Clients verteilt. Natürlich zeigen diese auf den Namespace und nicht direkt auf den Server...
Im Büro angemeldete PCs und Notebook bzw. lokal arbeitende Mitarbeiter haben ÜBERHAUPT keine Probleme.
Wenn sich jemand jedoch von zuhause anmeldet (also mit seinem Firmen Notebook) und dann VPN Verbindung Herstellt und auf die Netzlaufwerke klickt gibt's einen Fehler:
bei dem schwarzen balken steht dann der genaue Pfad des DFS Verweises. Bei uns ist das so:
\\name.der.domäne\blub\freigabe-name1\
wenn ich jedoch direkt den Servernamen und die Freigabe anwähle klappt es direkt.
Ich habe jetzt einen 2ten Server ins DFS rein gebracht und lasse die Daten syncronieren und habe einigen mitarbeiten als Workarround die Laufwerke direkt gemountet aber ich würde das Problem doch gern in den griff bekommen.
Ich vermute sehr stark, dass die Firewall irgendwelche dinge nicht erlaubt oder verarbeitet: vielleicht WINS oder NetBios ..
ich weiß nicht ob das benötigt wird aber DFS über SSL scheint nicht wirklich zu wollen. Aber ich weiß auch, dass nach einen längeren Warterei (etwa 15Min.) auch der DFS Verweis über SSL klappt. aber so lange wartet natürlich keiner und ich bekomme sofort anrufe.
Wäre wirklich cool wenn jemand der einen plan von DFS Kommunikation über SSL-VPN mir hier weiterhelfen könnte.
Viele Grüße
uLmi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 228685
Url: https://administrator.de/contentid/228685
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
7 Kommentare
Neuester Kommentar
DFS basiert ja auf Standard IP und das rennt genau so durch ein VPN wie durch ein Ethernetkabel. Da gibt es keinen Unterschied.
Dein Problem ist vermutlich ein reines DNS Problem wie so häufig.
Testweise kannst du das Zielverzeichenis mal mit \\<ip_adresse_freigabe>\blub\freigabe-name1\ versuchen.
Alternativ die IP Adresses des Share Ziel statisch auf dem Client in die Datei hosts oder lmhosts eingeben. Das löst vermutlich das Problem.
Dein Problem ist vermutlich ein reines DNS Problem wie so häufig.
Testweise kannst du das Zielverzeichenis mal mit \\<ip_adresse_freigabe>\blub\freigabe-name1\ versuchen.
Alternativ die IP Adresses des Share Ziel statisch auf dem Client in die Datei hosts oder lmhosts eingeben. Das löst vermutlich das Problem.
Hallo,
ich kann den Pfad per
\\servername\freigabe
und
\\ip-des-servers\freigabe
wunderbar erreichen
intern (also im Büro) funktionieren die Verweise per DNS Namen auch wunderbar. Das würde auf ein DNS Problem während der VPN schließen aber ich habe grade die DNS geprüft und die vom VPN sind richtig. (Es sind die selben DNS Server eingetragen, welche die User intern vom MS DHCP bekommen)
Zudem habe ich auch schon sämtliche Server mit und ohne .Domäne und ihrer entsprechenden IP in meine Hosts Datei testhalber eingetragen.
Hat nichts gebracht.
Aber der DFS Verweis ist ja an sich kein Servername, der Verweis ist bei uns so:
\\domäne.local\abc\freigabe1\
\\domäne.local\abc\freigabe2\
\\domäne.local\abc\freigabe3\
ich frage mich ob ich im DNS irgendwie den Verweis hinterlegen kann aber das wäre ja schwachsinnig, weil das ganze DFS-System dieses zeug machen sollte.
Ich verstehe es einfach nicht...
Gruß
uLmi
ich kann den Pfad per
\\servername\freigabe
und
\\ip-des-servers\freigabe
wunderbar erreichen
intern (also im Büro) funktionieren die Verweise per DNS Namen auch wunderbar. Das würde auf ein DNS Problem während der VPN schließen aber ich habe grade die DNS geprüft und die vom VPN sind richtig. (Es sind die selben DNS Server eingetragen, welche die User intern vom MS DHCP bekommen)
Zudem habe ich auch schon sämtliche Server mit und ohne .Domäne und ihrer entsprechenden IP in meine Hosts Datei testhalber eingetragen.
Hat nichts gebracht.
Aber der DFS Verweis ist ja an sich kein Servername, der Verweis ist bei uns so:
\\domäne.local\abc\freigabe1\
\\domäne.local\abc\freigabe2\
\\domäne.local\abc\freigabe3\
ich frage mich ob ich im DNS irgendwie den Verweis hinterlegen kann aber das wäre ja schwachsinnig, weil das ganze DFS-System dieses zeug machen sollte.
Ich verstehe es einfach nicht...
Gruß
uLmi
Ich frage mich ob das vielleicht mit dem "Caching von Credentials" zu tun haben könnte.
in diesem Gespräch wird da so dargestellt, dass Windows das PW und den Username vom VPN zwischenspeichert und dann damit die Authentifizierung an das DFS vornimmt.
http://social.technet.microsoft.com/Forums/windowsserver/en-US/dca8a723 ...
in meinem Fall fragt die Firewall beim SSL authenticate den Usernamen bzw. dessen Passwort vom DC ab.
Also das Passwort ist das selbe aber der Username bei der Anmeldung am SSL Client ist ohne den Domainpräfix "DOMÄNE\" (weis nicht ob das damit zusammen hängen kann)
Auf jedenfall könnte man das zwischen speichern hier mit deaktivieren:
You can set the value of the following key to 1, Hkey_Local_Machine\System\CurrentControlSet\Control\Lsa\DisableDomainCreds. This turns off the caching off credentials and forces your domain credentials to be used when accessing resources on both the local and remote network.
aber ein anderer Typ der in dieser Diskussion sagt, es ist wohl doch ein DFS Thema. Ich denke ich muss hier vorsichtig sein und nicht die verschiedenen Probleme durcheinander bringen. Unser Problem scheint kein Anmelde-Problem zu sein, weil die Fehlermeldung ja eindeutig sagt, dass der Pfad nicht gefunden wurde.
Demnach werde ich mir jetzt erst mal dieses Thema hier ansehen:
http://social.technet.microsoft.com/Forums/windowsserver/en-US/c89bd93a ...
Danke soweit für eure Teilnahme, ich halte euch auf den laufenden und packe hier alle Infos rein, wer weiß wem das vielleicht noch nützlich sein könnte.
Gruß
uLmi
in diesem Gespräch wird da so dargestellt, dass Windows das PW und den Username vom VPN zwischenspeichert und dann damit die Authentifizierung an das DFS vornimmt.
http://social.technet.microsoft.com/Forums/windowsserver/en-US/dca8a723 ...
in meinem Fall fragt die Firewall beim SSL authenticate den Usernamen bzw. dessen Passwort vom DC ab.
Also das Passwort ist das selbe aber der Username bei der Anmeldung am SSL Client ist ohne den Domainpräfix "DOMÄNE\" (weis nicht ob das damit zusammen hängen kann)
Auf jedenfall könnte man das zwischen speichern hier mit deaktivieren:
You can set the value of the following key to 1, Hkey_Local_Machine\System\CurrentControlSet\Control\Lsa\DisableDomainCreds. This turns off the caching off credentials and forces your domain credentials to be used when accessing resources on both the local and remote network.
aber ein anderer Typ der in dieser Diskussion sagt, es ist wohl doch ein DFS Thema. Ich denke ich muss hier vorsichtig sein und nicht die verschiedenen Probleme durcheinander bringen. Unser Problem scheint kein Anmelde-Problem zu sein, weil die Fehlermeldung ja eindeutig sagt, dass der Pfad nicht gefunden wurde.
Demnach werde ich mir jetzt erst mal dieses Thema hier ansehen:
http://social.technet.microsoft.com/Forums/windowsserver/en-US/c89bd93a ...
Danke soweit für eure Teilnahme, ich halte euch auf den laufenden und packe hier alle Infos rein, wer weiß wem das vielleicht noch nützlich sein könnte.
Gruß
uLmi
.local als Domänennamen zu verwenden ist kontraproduktiv und sollte man nie machen, denn mDNS http://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS nutzt diesen davor global reservierten Namen per Standard ebenfalls. Über kurz oder lang wird man da also Probleme im Netz bekommen wenn auch mDNS im Spiel ist.
Besser man verwendet dann .lokal oder .intern Aber das nur nebenbei....
Es ist definitiv KEIN Netzwerk oder VPN oder IP Problem, denn VPN ist nur ein Transportvehikel auf IP Basis. WAS an Protokollen darüber transportiert wird ist dem VPN ziemlich Latte.
Es kann also nur an einem DNS oder WINS Problem liegen. Wie gesagt zusätzlich mal statisch eintragen im Client, das fixt meist schon die Probleme.
Besser man verwendet dann .lokal oder .intern Aber das nur nebenbei....
Es ist definitiv KEIN Netzwerk oder VPN oder IP Problem, denn VPN ist nur ein Transportvehikel auf IP Basis. WAS an Protokollen darüber transportiert wird ist dem VPN ziemlich Latte.
Es kann also nur an einem DNS oder WINS Problem liegen. Wie gesagt zusätzlich mal statisch eintragen im Client, das fixt meist schon die Probleme.
ich habe das ganze noch mal gestern Abend von zuhause aus getestet:
1. ich glaube, dass die SSL Verschlüsselung und TCP-Handshakes eine menge Performance im Ordner browsen und beim Öffnen von Dateien schlucken. Da würde ich gerne optimieren (falls Möglich)
2. ich glaube, dass die Offline-Daten auch eine Rolle spielen. Eine Freigabe (DFS) ohne Offlinedaten lässt sich unmittelbar nach VPN nicht öffnen (da gibt es den Pfad nicht gefunden Fehler) Bei dem Laufwerk (auch DFS) mit Offline Dateien sehe ich erst mal nur die Offline Daten, kann dann F5 drücken und nach kurzem warten oben auf Online Modus wechseln. Aber das ganze ist das ziemlich träge und erfordert schon ein menge Geduld. Ich könnte mir ein Arbeiten via SSL-VPN ohne Offlinedaten nicht wirklich vorstellen.
Die zugriffe auf Webseiten sind echt zügig es scheint aber bei den Windows Freigaben echt noch optimierungsbedarf zu geben.
Ich weiß mit PPTP VPN ist das Browsen der Verzeichnisse und Öffnen der Dateien sehr schnell (eigentlich so wie im LAN) aber PPTP ist mir zu unsicher...
Ich frage mich ob ich noch am meinem Windows FileServer was optimieren kann oder ob ich an der SSL Verbindung was verändern kann um es zu beschleunigen.
IPSEC VPN hatte ich auch mal getestet, dort hatte ich eine ähnliche Performance wie beim SSL. LT2P habe ich jetzt noch nicht getestet aber auch da bin ich mir nicht sicher wegen der Sicherheit.
Meine SSL VPN Server Einstellungen sehen wie folgt aus:
ich habe mal gehört es wäre gut wenn ich den DataChannel auf UDP legen würde aber wenn ich das auf UDP umstelle, funktioniert die VPN Einwahl nicht mehr ..
UPDATE:/
hier schreibt einer : For best performance with a high level of encryption, we recommend that you choose MD5 authentication with Blowfish encryption.
würdet ihr dem zustimmen ?
VG
uLmi
1. ich glaube, dass die SSL Verschlüsselung und TCP-Handshakes eine menge Performance im Ordner browsen und beim Öffnen von Dateien schlucken. Da würde ich gerne optimieren (falls Möglich)
2. ich glaube, dass die Offline-Daten auch eine Rolle spielen. Eine Freigabe (DFS) ohne Offlinedaten lässt sich unmittelbar nach VPN nicht öffnen (da gibt es den Pfad nicht gefunden Fehler) Bei dem Laufwerk (auch DFS) mit Offline Dateien sehe ich erst mal nur die Offline Daten, kann dann F5 drücken und nach kurzem warten oben auf Online Modus wechseln. Aber das ganze ist das ziemlich träge und erfordert schon ein menge Geduld. Ich könnte mir ein Arbeiten via SSL-VPN ohne Offlinedaten nicht wirklich vorstellen.
Die zugriffe auf Webseiten sind echt zügig es scheint aber bei den Windows Freigaben echt noch optimierungsbedarf zu geben.
Ich weiß mit PPTP VPN ist das Browsen der Verzeichnisse und Öffnen der Dateien sehr schnell (eigentlich so wie im LAN) aber PPTP ist mir zu unsicher...
Ich frage mich ob ich noch am meinem Windows FileServer was optimieren kann oder ob ich an der SSL Verbindung was verändern kann um es zu beschleunigen.
IPSEC VPN hatte ich auch mal getestet, dort hatte ich eine ähnliche Performance wie beim SSL. LT2P habe ich jetzt noch nicht getestet aber auch da bin ich mir nicht sicher wegen der Sicherheit.
Meine SSL VPN Server Einstellungen sehen wie folgt aus:
ich habe mal gehört es wäre gut wenn ich den DataChannel auf UDP legen würde aber wenn ich das auf UDP umstelle, funktioniert die VPN Einwahl nicht mehr ..
UPDATE:/
hier schreibt einer : For best performance with a high level of encryption, we recommend that you choose MD5 authentication with Blowfish encryption.
würdet ihr dem zustimmen ?
VG
uLmi
Hallo uLmi,
der Eintrag ist nun zwar schon 6 Jahre alt, aber mich würde interessieren, ob du zu einer Lösung gekommen bist?
der Eintrag ist nun zwar schon 6 Jahre alt, aber mich würde interessieren, ob du zu einer Lösung gekommen bist?
