OpenVPN: SMB-Netzlaufwerke funktionieren nicht über die FRITZ!Box 7530 – die Lösung

Das Problem: VPN verbunden, aber Netzlaufwerke bleiben hängen oder GPUpdate läuft nicht durch.

Bei einer OpenVPN-Verbindung zu einer Synology NAS können unerwartete Probleme auftreten: Die VPN-Verbindung wird erfolgreich aufgebaut, der Server ist erreichbar und trotzdem lassen sich Windows-Netzlaufwerke nicht öffnen.

Genau dieses Verhalten trat in einer Konfiguration mit folgenden Komponenten auf:

• Internetanschluss: 1&1
• Router am Client-Standort: FRITZ!Box 7530
• VPN-Server: Synology NAS
• VPN-Client: OpenVPN unter Windows
• Netzlaufwerke: SMB-Freigaben auf entfernten Windows-Servern

Das Besondere: Über einen Handy-Hotspot funktionierte der Zugriff auf die SMB-Freigaben. Über den Internetanschluss mit der FRITZ!Box 7530 dagegen nicht.

Damit lag der Verdacht nahe, dass nicht die Freigaben selbst, sondern die Datenübertragung durch den VPN-Tunnel die Ursache war.

1. Die Fehlersuche: SMB-Port erreichbar

Zunächst wurde geprüft, ob der entfernte Server über SMB erreichbar war. Dazu kam in PowerShell folgender Befehl zum Einsatz:

Test-NetConnection SERVER-IP -Port 445

Das Ergebnis bestätigte, dass eine TCP-Verbindung zum SMB-Port 445 aufgebaut werden konnte.

Auch der zusätzliche Test des RPC-Ports 135 verlief erfolgreich.

Damit war klar: Die Server waren grundsätzlich über den VPN-Tunnel erreichbar. Ein offener TCP-Port bedeutet allerdings noch nicht, dass die gesamte SMB-Kommunikation problemlos funktioniert.

2. Die Fehlermeldung: Systemfehler 1726

Beim Versuch, die Freigaben aufzulisten, trat dieser Fehler auf:

net view \\SERVER-IP

Windows meldete:

Systemfehler 1726 aufgetreten.

Der Remoteprozeduraufruf ist fehlgeschlagen.

Auch der Zugriff über den Windows-Explorer blieb teilweise hängen.

Die Fehlermeldung war zunächst irreführend, denn die VPN-Verbindung bestand und die relevanten TCP-Ports waren erreichbar.

Entscheidend war der Vergleich zweier Internetzugänge: Mit dem Handy-Hotspot funktionierte der Zugriff, über die FRITZ!Box 7530 dagegen nicht.

3. Die Ursache: MSS-Einstellung in OpenVPN

Auf der Gegenseite lief eine Synology NAS mit aktiviertem OpenVPN-Server. In der OpenVPN-Konfiguration war folgende Einstellung vorhanden:

mssfix 1450

Der Parameter mssfix beeinflusst bei OpenVPN über UDP die TCP-Segmentgröße, um Probleme durch zu große Pakete im VPN-Tunnel zu vermeiden.

Durch die zusätzliche Kapselung der Daten im VPN-Tunnel steht weniger Platz für die eigentlichen Nutzdaten zur Verfügung. Je nach Netzwerkpfad können zu große Pakete fragmentiert werden oder verloren gehen.

Solche Probleme sind nicht immer sofort sichtbar. Die VPN-Verbindung kann stabil erscheinen, während bestimmte Anwendungen oder Dateiübertragungen hängen bleiben.

Wichtig: Ein erreichbarer TCP-Port 445 schließt ein MTU-/MSS-Problem nicht aus. Auch erfolgreiche Ping-Tests mit größeren Paketen können die Ursache nicht in jedem Fall vollständig ausschließen.

4. Die Lösung: mssfix von 1450 auf 1300 reduzieren

Die entscheidende Änderung war die Anpassung des MSS-Wertes.

Vorher:

mssfix 1450

Nachher:

mssfix 1300

Nach der Änderung wurde die OpenVPN-Verbindung auf dem Laptop getrennt und neu aufgebaut.

Anschließend wurden die SMB-Freigaben erneut getestet.

Ergebnis: Die Netzlaufwerke funktionierten wieder.

Damit war die MSS-Einstellung für diesen konkreten Verbindungsweg als Ursache identifiziert. Die Reduzierung auf 1300 beseitigte das Problem in dieser Konfiguration.

5. Warum funktioniert es über den Handy-Hotspot?

Unterschiedliche Internetzugänge können unterschiedliche Eigenschaften hinsichtlich Paketgröße, Kapselung und Übertragungsweg haben.

Der Handy-Hotspot verwendete einen anderen Netzwerkpfad als der 1&1-Anschluss über die FRITZ!Box 7530. Dadurch konnte sich das Verhalten des VPN-Tunnels unterscheiden, obwohl derselbe Laptop und derselbe OpenVPN-Server verwendet wurden.

Die erfolgreiche Verbindung über den Hotspot war deshalb ein wichtiger Hinweis bei der Fehlersuche.

Das bedeutet nicht, dass die FRITZ!Box 7530 grundsätzlich Probleme mit SMB oder OpenVPN hat. Entscheidend war die Kombination aus VPN-Konfiguration und Netzwerkpfad.

6. So lässt sich ein ähnliches Problem diagnostizieren

Wenn OpenVPN verbunden ist, SMB-Netzlaufwerke aber nicht funktionieren, empfiehlt sich folgende Reihenfolge.

Schritt 1: SMB-Port testen

Test-NetConnection SERVER-IP -Port 445

Ersetze SERVER-IP durch die Adresse des tatsächlichen Dateiservers.

Schritt 2: Freigaben auflisten

net view \\SERVER-IP

Achte auf die genaue Fehlermeldung. Ein Fehler wie Systemfehler 1726 ist ein Hinweis auf ein Kommunikationsproblem, aber noch kein eindeutiger Beweis für eine bestimmte Ursache.

Schritt 3: Paketgröße untersuchen

Beispielsweise mit:

ping SERVER-IP -f -l 1300

Die Option -f setzt das Don’t-Fragment-Bit für IPv4, während -l die Größe der ICMP-Nutzdaten festlegt.

Wichtig: Die angegebene Ping-Größe ist nicht die gesamte IP-Paketgröße. Außerdem können ICMP-Pakete anders behandelt werden als TCP-Verkehr.

Schritt 4: OpenVPN-Konfiguration kontrollieren

Prüfe, ob die Konfiguration über UDP oder TCP arbeitet und welcher MSS-Wert gesetzt ist. Sichere vor Änderungen die ursprüngliche Konfiguration und ändere möglichst nur eine Einstellung gleichzeitig.

Bei OpenVPN über UDP kann eine vorsichtige Reduzierung von mssfix ein sinnvoller Diagnosetest sein. Ein Wert