MacOS - DFS Freigabe funktionieren per VPN nicht, lokal schon, Firewall OK
Hallo Kollegen,
wir sind gerade in einen insourcing Projekt und holen etliche Dienste wieder zurück.
Mit MacOS und DFS Freigaben haben wir aber ein Problem.
im Firmen LAN klappt der Zugriff vom Mac auf das DFS des IT-Dienstleisters ohne Probleme. Das LAN ist über zwei Palo Alto Firewalls gekoppelt.
Die Laufwerke werden mit smb:dfs.local aufgerufen und nach der Anmeldung erscheinen die DFS Root Pfade.
Darunter tauchen dann die Laufwerke auf und die Ordner mit den Dateien.
Per VPN klappt das allerdings nicht, und nein, es liegt nicht an den Firewall Regeln. Wir sehen keine Blocks und unter Windows funktioniert DFS mit den gleichen VPN Parametern. Das VPN ist übrigens ein Palo Alto GlobalProtect auf der Firewall die auch an das Dienstleister Netzwerk gekoppelt ist.
Versuche ich es auf dem Mac (15.4.1) , klappt smb:dfs.local gar nicht ("Beim Verbinden mit dem Server "dfs.local" ist ein Fehler aufgetreten"). Die nslookup Auflösung von dfs.local ergibt 4 IP-Adressen, genauso wie intern.
Versuch ich nun die IP eines der Server, komme ich etwas weiter. Ich kann mich anmelden und sehe dann die DFS Root Pfade und die Ordner eine Ebene tiefer, aber dann kommt nichts mehr. Die Verzeichnisse bleiben einfach leer (was sie natürlich nicht sind).
Mit dem Cisco VPN des Dienstleisters funktioniert es, und nein, er ist hier keine Hilfe zu erwarten; bitte das nicht diskutieren, das ist leider einfach so. Wir haben auch keinen Zugriff auf die Server.
Ich weiß leider nicht, wie ich hier weiterkommen soll?
Im Internet habe ich viel zu MacOS DFS Problemen gelesen, und so weiß ich nicht ob es ein Problem vom Mac ist, oder doch was mit dem GlobalProtect (dazu findet sich auch ein ungelöstes Problem), oder doch vom DFS des Dienstleisters.
Hat jemand einen Tipp für mich?
Oder in welche Richtung ich gucken kann.
Vielen Dank schon mal!
Viele Grüße
Deepsys
wir sind gerade in einen insourcing Projekt und holen etliche Dienste wieder zurück.
Mit MacOS und DFS Freigaben haben wir aber ein Problem.
im Firmen LAN klappt der Zugriff vom Mac auf das DFS des IT-Dienstleisters ohne Probleme. Das LAN ist über zwei Palo Alto Firewalls gekoppelt.
Die Laufwerke werden mit smb:dfs.local aufgerufen und nach der Anmeldung erscheinen die DFS Root Pfade.
Darunter tauchen dann die Laufwerke auf und die Ordner mit den Dateien.
Per VPN klappt das allerdings nicht, und nein, es liegt nicht an den Firewall Regeln. Wir sehen keine Blocks und unter Windows funktioniert DFS mit den gleichen VPN Parametern. Das VPN ist übrigens ein Palo Alto GlobalProtect auf der Firewall die auch an das Dienstleister Netzwerk gekoppelt ist.
Versuche ich es auf dem Mac (15.4.1) , klappt smb:dfs.local gar nicht ("Beim Verbinden mit dem Server "dfs.local" ist ein Fehler aufgetreten"). Die nslookup Auflösung von dfs.local ergibt 4 IP-Adressen, genauso wie intern.
Versuch ich nun die IP eines der Server, komme ich etwas weiter. Ich kann mich anmelden und sehe dann die DFS Root Pfade und die Ordner eine Ebene tiefer, aber dann kommt nichts mehr. Die Verzeichnisse bleiben einfach leer (was sie natürlich nicht sind).
Mit dem Cisco VPN des Dienstleisters funktioniert es, und nein, er ist hier keine Hilfe zu erwarten; bitte das nicht diskutieren, das ist leider einfach so. Wir haben auch keinen Zugriff auf die Server.
Ich weiß leider nicht, wie ich hier weiterkommen soll?
Im Internet habe ich viel zu MacOS DFS Problemen gelesen, und so weiß ich nicht ob es ein Problem vom Mac ist, oder doch was mit dem GlobalProtect (dazu findet sich auch ein ungelöstes Problem), oder doch vom DFS des Dienstleisters.
Hat jemand einen Tipp für mich?
Oder in welche Richtung ich gucken kann.
Vielen Dank schon mal!
Viele Grüße
Deepsys
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673165
Url: https://administrator.de/forum/macos-vpn-dfs-freigabe-673165.html
Ausgedruckt am: 25.06.2025 um 08:06 Uhr
13 Kommentare
Neuester Kommentar
@Deepsys
Moin, hattest du mal die Möglichkeit, ein älteres MacOS zu nehmen um das Problem zu verifizieren?
Dann liesse sich das ja ggf. auf Sequoia eingrenzen.
Es gibt übrigens inzwischen macOS 15.5 Sequoia.
Muss es denn unbedingt .local sein?
Kreuzberger
Moin, hattest du mal die Möglichkeit, ein älteres MacOS zu nehmen um das Problem zu verifizieren?
Dann liesse sich das ja ggf. auf Sequoia eingrenzen.
Es gibt übrigens inzwischen macOS 15.5 Sequoia.
Muss es denn unbedingt .local sein?
Kreuzberger
Hi,
Moin, hattest du mal die Möglichkeit, ein älteres MacOS zu nehmen um das Problem zu verifizieren?
Dann liesse sich das ja ggf. auf Sequoia eingrenzen.
Nein, die sind alle aktuellDann liesse sich das ja ggf. auf Sequoia eingrenzen.
Es gibt übrigens inzwischen macOS 15.5 Sequoia.
Ja, das nörgelt der Mac auch gerade rum Muss es denn unbedingt .local sein?
Ja leider, da kann ich leider nichts dran ändern. War nicht unsere Idee
Muss es denn unbedingt .local sein?
Vorab: .local ist bekanntlich keine besonders intelligente Wahl für eine lokale TLD, denn die ist weltweit dem mDNS Dienst vorbehalten der in jedem Netzwerk umfassend genutzt wird. Deshalb ist es besser diese TLD nie zu verwenden. Das da Probleme früher oder später vorprogrammiert sind liegt auf der Hand.https://imatrix.at/schlechter-domain-name/
Hinweise zur Verwendung der Domäne .local in DNS und mDNS
https://www.heise.de/news/Ueberfaellig-ICANN-legt-sich-auf-Namen-fuer-in ...
Für eine zielführende Hilfe wäre noch wichtig zu wissen welches der zahllosen VPN Optionen du denn verwendest und ob du sinnvollerweise die lokalen VPN Clients dafür nutzt?
Ein IKEv2 Zugriff mit dem Mac (Sequoia) rennt hier mit DFS fehlerfrei. Übrigens ebenso das onboard L2TP.
Hast du mal
smb://123.123.123.123..local
... also mit der entsprechenden IP-Adresse probiert?
Kreuzberger
smb://123.123.123.123..local
... also mit der entsprechenden IP-Adresse probiert?
Kreuzberger
Mit 2 Punkten wird aber auch das nichts obwohl es die korrekte Syntax ist!
Wie oben schon erwähnt, das liegt nicht in unserer Hand und da können wir nichts machen.
Das werde ich hier nicht weiter diskutieren.
Mit dem VPN des Dienstleisters funktioniert es ja.
Auf dem Windows habe ich gerade gesehen, das der Ordner den ich als letztes sehe, auch wieder ein DFS Link ist ....
Das ist noch weiter verschachtelt...
Und da kommt gerade die Frage auf, ob der Mac nicht auch unter der App "Verzeichnisdienste" diese Domäne zumindest als Suchpfad braucht.
Das kann ich aber erst ab Donnerstag testen ....
Danke schon mal für eure Hilfe
Das werde ich hier nicht weiter diskutieren.
Mit dem VPN des Dienstleisters funktioniert es ja.
Auf dem Windows habe ich gerade gesehen, das der Ordner den ich als letztes sehe, auch wieder ein DFS Link ist ....
Das ist noch weiter verschachtelt...
Und da kommt gerade die Frage auf, ob der Mac nicht auch unter der App "Verzeichnisdienste" diese Domäne zumindest als Suchpfad braucht.
Das kann ich aber erst ab Donnerstag testen ....
Danke schon mal für eure Hilfe
Wenn der "Dienstleister" sowas wie .local verzapft spricht das nicht gerade für dessen KnowHow. Aber du hast Recht, das ist nicht das Thema hier...oder nur am Rande.
Bleibt noch die Frage nach der Art des VPNs?
Bleibt noch die Frage nach der Art des VPNs?
Für eine zielführende Hilfe wäre noch wichtig zu wissen welches der zahllosen VPN Optionen du denn verwendest und ob du sinnvollerweise die lokalen VPN Clients dafür nutzt?
Das ist nicht drin, es muss der Palo Alto GlobalProtect sein.
An welche Option denkst du?
es muss der Palo Alto GlobalProtect sein.
Der basiert auf welcher Art VPN?Moment ... SSL .... ähm, das sollte aber IPSec sein, prima noch ein Fehler gefunden.
Die Windows Notebook nehmen aber auch SSL .... noch, da muss ich mal gucken, sollte IPSec sein
könnte es der Domain Name Suffix sein, also Suchreihenfolge?
Bedeutet wenn du im LAN bist regelt das ja vermutlich dein DHCP die Settings.
Wenn aber User zuhause per VPN dann regelt das wer nochmal ?
Ansonsten der Domain Name also \\domainname.xyz\DFS oder so sollte nicht einer Internet Domain entsprechen, ansonsten nutzen die clients nämlich erstmal den Internet DNS.
Was sagt NSLOOKUP wenn du das auf den DFS FQDN machst (Beim Client der per VPN verbunden ist)?
Aja NSLOOKUP auf MAC
Keine Ahnung wie du das dort checkst
Auch ein Traceroute auf den FQDN wäre super um die ecke zu erkennen wo es happert...
nicht das es ein Routingproblem des VPN ist >> hatte ich auch schon das ein Zentrales Routing zu einem VLAN gefehlt hat und dann logisch war auch nix in den Rules/Logs der Firewall, weil das Paket es nicht bis zu den Firewall Rules schaft.
Bedeutet wenn du im LAN bist regelt das ja vermutlich dein DHCP die Settings.
Wenn aber User zuhause per VPN dann regelt das wer nochmal ?
Ansonsten der Domain Name also \\domainname.xyz\DFS oder so sollte nicht einer Internet Domain entsprechen, ansonsten nutzen die clients nämlich erstmal den Internet DNS.
Was sagt NSLOOKUP wenn du das auf den DFS FQDN machst (Beim Client der per VPN verbunden ist)?
Aja NSLOOKUP auf MAC
Keine Ahnung wie du das dort checkst Auch ein Traceroute auf den FQDN wäre super um die ecke zu erkennen wo es happert...
nicht das es ein Routingproblem des VPN ist >> hatte ich auch schon das ein Zentrales Routing zu einem VLAN gefehlt hat und dann logisch war auch nix in den Rules/Logs der Firewall, weil das Paket es nicht bis zu den Firewall Rules schaft.
Das kann ich mal gucken, aber DNS Auflösung klappt
In der Zwischenzeit hat sich was Neues ergeben:
Es sind quasi mehrere DFS Pfade untereinander.
Darum klappt die IP des Server nur bis zur obersten Ordner Ebene, diese ist nämlich gar kein Ordner, sondern wieder ein DFS-Link der auf einen andern Server verweist.
Löse ich dessen IP auf und gebe diese als smb://IP auf, dann komme ich weiter und auch auf Dateien
Es liegt also daran das der Mac irgendwie die Auflösung nicht hinbekommt, ich teste das am Donnerstag mit Aufnahme des Macs in das AD. Denke, da ist der Hund begraben.
Also, am Netzwerk liegt es nicht, auf die Freigabe auf dem Server komme ich ja.
Danke, an alle, das Brainstorming hier hat schon mal geholfen.
Update dann am Donnerstag
Was sagt NSLOOKUP wenn du das auf den DFS FQDN machst (Beim Client der per VPN verbunden ist)?
Wie oben steht, die IP sind die gleichen wie im LAN, beim mac übrigens auch nslookupnicht das es ein Routingproblem des VPN ist >> hatte ich auch schon das ein Zentrales Routing zu einem VLAN gefehlt hat und dann logisch war auch nix in den Rules/Logs der Firewall, weil das Paket es nicht bis zu den Firewall Rules schaft.
Das habe ich unklar ausgedrückt, ich sehe Allow Pakete und auch als smb. Also Routing ist OK.In der Zwischenzeit hat sich was Neues ergeben:
Es sind quasi mehrere DFS Pfade untereinander.
Darum klappt die IP des Server nur bis zur obersten Ordner Ebene, diese ist nämlich gar kein Ordner, sondern wieder ein DFS-Link der auf einen andern Server verweist.
Löse ich dessen IP auf und gebe diese als smb://IP auf, dann komme ich weiter und auch auf Dateien
Es liegt also daran das der Mac irgendwie die Auflösung nicht hinbekommt, ich teste das am Donnerstag mit Aufnahme des Macs in das AD. Denke, da ist der Hund begraben.
Also, am Netzwerk liegt es nicht, auf die Freigabe auf dem Server komme ich ja.
Danke, an alle, das Brainstorming hier hat schon mal geholfen.
Update dann am Donnerstag
Kurzer Zwischenstand, Benutzer mit Mac in Urlaub, noch nichts Neues .....
1
