Direkt zum Hauptinhalt

FritzBox WireGuard: NetBIOS-Option & SMB / SAMBA

Beschreibung:

Fehler 80004005 bedeuet entweder Benuterzname Kennwort sind falsch, bzw. im Credentialmanager beschädigt.
Dann in der Systemsteuerung Anmeldeinformationen diese löschen neu anmelden oder, es ist eine Fritzbox als Wireguard Client konfiguriert zum Zugriff auf den Zielserver.

image.png



Warum Windows-Dateifreigaben über WireGuard-VPN ohne die NetBIOS-Option nicht funktionieren — auch bei direkter IP-Adresse

Inhaltsverzeichnis

  1. Das Problem in der Praxis
  2. Hintergrund: SMB vs. NetBIOS
  3. Protokolle & Ports im Überblick
  4. Was passiert beim Verbindungsaufbau?
  5. Warum scheitert es auch bei direkter IP-Eingabe?
  6. FritzBox-interne Mechanik
  7. Fix & Empfehlungen
  8. Quellen

🔍 Das Problem in der Praxis

Wer über eine FritzBox, die als WireGuard-Client konfiguriert ist, auf Windows-Dateifreigaben (SMB/CIFS) im Remote-Netz zugreift, erlebt oft folgenden Fehler:

\\192.168.2.11\Freigabe Fehlercode: 0x80004005 "Zugriff verweigert" / "Auf Netzwerkressource kann nicht zugegriffen werden"

Das Verwirrende: Port-Checks auf TCP 445 schlagen durch, die Authentifizierung klappt in separaten Test-Tools — aber Windows Explorer und net use scheitern zuverlässig.

💡
Die Lösung In der FritzBox-Oberfläche unter dem WireGuard-Peer den Haken bei "NetBIOS über diese Verbindung zulassen" setzen. Danach funktioniert der Zugriff sofort — ohne Neustart.

Aber warum ist das nötig? Und warum hilft es sogar, wenn man gar keinen Hostnamen, sondern direkt die IP-Adresse eingibt?

📚 Hintergrund: SMB vs. NetBIOS

SMB (Server Message Block) ist das Windows-Protokoll für Dateifreigaben. Es existiert in zwei grundlegend verschiedenen Betriebsmodi:

✅ Modernes SMB (Direct Hosting)

  • · TCP Port 445
  • · SMB 2.x und 3.x
  • · Ab Windows Vista / Server 2008
  • · Kein NetBIOS benötigt
  • · Direkte TCP-Verbindung
  • · Sicherer, effizienter

⚠️ Legacy SMB über NetBIOS

  • · TCP Port 139
  • · SMB 1.0 / CIFS
  • · Ältere Systeme, NAS-Geräte
  • · Benötigt NBNS (Port 137)
  • · Namensauflösung über Broadcast
  • · Sicherheitsrisiken bekannt
⚠️
Das zentrale Problem Windows versucht beim Verbindungsaufbau immer beide Wege gleichzeitig. Auch wenn der Server modernes SMB auf Port 445 spricht, sendet Windows parallel NetBIOS-Queries (Broadcasts auf UDP 137/138). Diese Broadcasts werden von WireGuard-Tunneln und den Firewalls dahinter standardmäßig gefiltert.

🔌 Protokolle & Ports im Überblick

Port Protokoll Dienst Ohne NetBIOS-Option Zweck
445/TCP TCP Direct SMB DURCH Modernes SMB, direkte Verbindung
137/UDP UDP NBNS (Name Service) BLOCKIERT NetBIOS-Namensauflösung via Broadcast
138/UDP UDP NetBIOS Datagram BLOCKIERT Verbindungslose Broadcasts, Netzwerk-Discovery
139/TCP TCP NetBIOS Session BLOCKIERT Legacy SMB über NetBIOS (ältere Systeme)

NetBIOS wurde ursprünglich für kleine Netzwerke der 1980er Jahre entwickelt und basiert konzeptionell auf Broadcasts. Broadcasts können per Design nicht durch IP-Router geleitet werden. WireGuard als Layer-3-Protokoll routet nur Unicast-Pakete — Broadcasts bleiben am Tunnel-Ende stecken.

🔄 Was passiert beim Verbindungsaufbau?

❌ Ohne "NetBIOS aktivieren"

Schritt 1
Windows-Client gibt \\192.168.2.11\Freigabe ein
↓
Schritt 2
Windows startet parallel: TCP-Verbindung auf Port 445 und NetBIOS-Query auf UDP 137
↓
Schritt 3
UDP 137-Broadcast → WireGuard-Tunnel → FritzBox-Firewall filtert → kein NBNS-Response
↓
Schritt 4
Windows wartet auf NBNS-Timeout, versucht LLMNR als Fallback — auch geblockt
↓
Schritt 5
Verbindungsaufbau schlägt fehl: 0x80004005 — Zugriff verweigert

✅ Mit "NetBIOS aktivieren"

Schritt 1
Windows-Client gibt \\192.168.2.11\Freigabe ein
↓
Schritt 2
Windows startet parallel: TCP Port 445 und NBNS-Query (UDP 137)
↓
Schritt 3
FritzBox lässt UDP 137/138 und TCP 139 durch (dont_filter_netbios = yes)
↓
Schritt 4
NBNS-Response kommt zurück — Windows nimmt das schnellste
↓
Schritt 5
SMB-Session wird aufgebaut — Freigabe erreichbar ✓

❓ Warum scheitert es auch bei direkter IP-Eingabe?

Die häufigste Verwunderung: "Ich gebe doch \\192.168.2.11\Freigabe ein — keine Hostnamen! Warum brauche ich NetBIOS?"

Das liegt am Windows-SMB-Stack. Auch bei direkter IP-Eingabe sendet Windows intern zunächst eine NBNS-Reverse-Query — eine Art "Wer bist du?" an die Ziel-IP. Das dient der Sessionvorbereitung und Capability-Discovery, nicht nur der Namensauflösung.

Konkret: Windows sendet einen NetBIOS Node Status Request (UDP 137) direkt an die Ziel-IP um den NetBIOS-Namen des Ziels herauszufinden und die SMB-Session korrekt zu initialisieren. Das ist Legacy-Verhalten das auch in modernen Windows-Versionen mit SMB 2/3 beibehalten wird.

Windows Explorer / net use

  • · Nutzt den Windows LanmanWorkstation-Dienst
  • · Vollständiger SMB-Stack inkl. NetBIOS-Init
  • · Sendet NBNS Node Status Request
  • · Scheitert wenn UDP 137 geblockt ist

Eigene SMB-Test-Tools

  • · Nutzen oft eigene SMB-Bibliotheken
  • · Direkte TCP-445-Verbindung
  • · Überspringen die NetBIOS-Phase
  • · Funktionieren auch ohne NetBIOS-Freigabe
💡
Erklärt den scheinbaren Widerspruch Deshalb meldet ein eigenes Test-Tool "Authentifizierung OK, Freigaben erreichbar" — während Windows Explorer gleichzeitig 0x80004005 wirft. Das Tool umgeht den Windows-Stack und damit die NetBIOS-Phase vollständig.

⚙️ FritzBox-interne Mechanik

Hinter der UI-Option steckt ein interner FritzBox-Konfigurationsparameter:

# NetBIOS deaktiviert (Standard nach Stromausfall/Reset): dont_filter_netbios = no # → FritzBox-Firewall filtert UDP 137/138, TCP 139 # NetBIOS aktiviert (Haken gesetzt): dont_filter_netbios = yes # → NetBIOS-Traffic passiert den Tunnel

Es handelt sich dabei nicht um ein echtes Application-Level Gateway (ALG) — die FritzBox modifiziert den SMB-Traffic nicht. Sie öffnet lediglich Firewall-Regeln für die betreffenden NetBIOS-Ports auf dem WireGuard-Interface.

⚠️
Wichtig: Nur für Site-to-Site AVM bietet diese Option offiziell nur für Netzwerk-zu-Netzwerk-WireGuard-Verbindungen an, nicht für reine Client-VPN-Profile.

Warum nach Stromausfall weg?

Ein Stromausfall kann dazu führen, dass die FritzBox ihre WireGuard-Konfiguration aus einem älteren Checkpoint restauriert, oder dass einzelne Konfigurationsparameter auf Defaults zurückfallen. Der Default für dont_filter_netbios ist in manchen Firmware-Versionen no.

📌
Historisch In FritzOS 8.20 wurde der Default auf no geändert, was bei vielen Nutzern SMB-Probleme über WireGuard auslöste.

🛠️ Fix & Empfehlungen

Sofort-Fix (FritzBox-Oberfläche)

FritzBox UI → Internet → Freigaben → VPN (WireGuard) → WireGuard-Peer auswählen (Bearbeiten) → Haken bei "NetBIOS über diese Verbindung zulassen" setzen → Speichern
✅
Kein Neustart nötig — wirkt sofort.

Dauerhaft absichern

Nach dem Fix die aktuelle Konfiguration als Backup exportieren: System → Sicherung. Dann überlebt die Einstellung den nächsten Stromausfall.

Alternative: NetBIOS clientseitig abschalten

Langfristig sauberer: NetBIOS auf den Clients vollständig deaktivieren und nur Direct-SMB auf TCP 445 zulassen — setzt voraus, dass alle Server SMB 2+ sprechen.

# PowerShell (als Admin): $adapters = Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True" $adapters | ForEach-Object { $_.SetTcpipNetbios(2) } # 2 = Disable NetBIOS over TCP/IP
⛔
Achtung: Wenn noch ein altes NAS oder Gerät mit SMB1/CIFS im Netz ist (ältere Synology, QNAP, Windows XP), kann NetBIOS deaktivieren den Zugriff darauf brechen.

📎 Quellen

nach oben