Samba-Zugriff über WireGuard
Hallo zusammen,
ich habe mir zu Übungszwecken auf einem Proxmox einen Wireguard-Server in einem lxc installiert und im Wesentlichen nach Anleitung von aqui - Merkzettel: VPN Installation mit Wireguard konfiguriert, anschließend nochmals kontrolliert und für korrekt befunden.
Portforwarding und Route ist in der Fritzbox eingestellt.
Die Verbindung eines Test-Clients funktioniert über Mobilfunk-Hotspot einwandfrei.
Nun zu meinem Problem:
Im internen Heimnetz habe ich auf dem Proxmox auch einen weiteren Linux-Server der einen Samba-Share öffentlich (NUR im Heimnetz) zur Verfügung stellt. Der Zugriff darauf OHNE WireGuard funktioniert von diversen Clients ohne Authentifizierung einwandfrei. Sobald ich jedoch per WireGuard verbunden bin und versuche, auf den Share zuzugreifen, erfordert Windows 11 die Eingabe von Netzwerkanmeldeinformationen und egal, was ich eingebe, die Anforderung wird mit einer Fehlermeldung quittiert. Da der Zugriff auf den Share bisher und ansonsten grundsätzlich funktioniert, gehe ich dennoch von einer korrekten Konfiguration aus. Alles andere wie Ping (in beide Richtungen, also VPN-Client <-> lokale Clients/Server), RDP usw. macht ebenfalls keine Probleme.
Außerdem ist mir aufgefallen, dass auf dem Windows 11 VPN-Client bei aktivierter WireGuard-Verbindung auch keine anderen Dienste und PC's in der Netzwerkumgebung mehr zu sehen sind. Eigentlich möchte ich "nur" jederzeit von überall ins Heimnetz verbinden und dort auf alle Ressourcen zugreifen können, als wäre ich direkt im Netz. Da ich mittlerweile einige Tage an diesem Problem sitze und auch nach intensiver Recherche nicht wirklich weiterkomme, bin ich mit meinem Latein am Ende.
Über Hilfe, Anregungen und Tipps würde ich mich sehr freuen!
Nachfolgend noch meine aktuellen Configs:
wg0.conf
Laptop.conf
Falls jemand noch etwas braucht, bitte nachfragen. Vielen Dank im Voraus!
ich habe mir zu Übungszwecken auf einem Proxmox einen Wireguard-Server in einem lxc installiert und im Wesentlichen nach Anleitung von aqui - Merkzettel: VPN Installation mit Wireguard konfiguriert, anschließend nochmals kontrolliert und für korrekt befunden.
Portforwarding und Route ist in der Fritzbox eingestellt.
Die Verbindung eines Test-Clients funktioniert über Mobilfunk-Hotspot einwandfrei.
Nun zu meinem Problem:
Im internen Heimnetz habe ich auf dem Proxmox auch einen weiteren Linux-Server der einen Samba-Share öffentlich (NUR im Heimnetz) zur Verfügung stellt. Der Zugriff darauf OHNE WireGuard funktioniert von diversen Clients ohne Authentifizierung einwandfrei. Sobald ich jedoch per WireGuard verbunden bin und versuche, auf den Share zuzugreifen, erfordert Windows 11 die Eingabe von Netzwerkanmeldeinformationen und egal, was ich eingebe, die Anforderung wird mit einer Fehlermeldung quittiert. Da der Zugriff auf den Share bisher und ansonsten grundsätzlich funktioniert, gehe ich dennoch von einer korrekten Konfiguration aus. Alles andere wie Ping (in beide Richtungen, also VPN-Client <-> lokale Clients/Server), RDP usw. macht ebenfalls keine Probleme.
Außerdem ist mir aufgefallen, dass auf dem Windows 11 VPN-Client bei aktivierter WireGuard-Verbindung auch keine anderen Dienste und PC's in der Netzwerkumgebung mehr zu sehen sind. Eigentlich möchte ich "nur" jederzeit von überall ins Heimnetz verbinden und dort auf alle Ressourcen zugreifen können, als wäre ich direkt im Netz. Da ich mittlerweile einige Tage an diesem Problem sitze und auch nach intensiver Recherche nicht wirklich weiterkomme, bin ich mit meinem Latein am Ende.
Über Hilfe, Anregungen und Tipps würde ich mich sehr freuen!
Nachfolgend noch meine aktuellen Configs:
wg0.conf
[Interface]
PrivateKey = [PrivateKey]
Address = 10.64.161.1/24
MTU = 1420
ListenPort = 51825
### begin Laptop ###
[Peer]
PublicKey = [PublicKey]
PresharedKey = [PresharedKey]
AllowedIPs = 10.64.161.2/32
### end Laptop ###Laptop.conf
[Interface]
PrivateKey = [PrivateKey]
Address = 10.64.161.2/24
DNS = 192.168.178.1
[Peer]
PublicKey = [PublicKey]
PresharedKey = [PresharedKey]
Endpoint = [dyndnsEndpoint]:51825
AllowedIPs = 0.0.0.0/0, 192.168.178.0/24Falls jemand noch etwas braucht, bitte nachfragen. Vielen Dank im Voraus!
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: 3714973823
Url: https://administrator.de/forum/samba-zugriff-ueber-wireguard-3714973823.html
Ausgedruckt am: 12.05.2025 um 06:05 Uhr
10 Kommentare
Neuester Kommentar
Hat der Windows 11 Client administrative Rechte ?
https://www.andysblog.de/wireguard-client-unter-windows
Deine WG Konfig hat trotz deiner vorgeblichen Kontrolle dennoch einen Fehler oder du hast das Tutorial nicht aufmerksam genug gelesen.
Laut deiner Konfig nutzt du ja ein Gateway Redirect Konzept also das immer der gesamte Traffic bei aktivem Tunnel ins VPN geroutet wird. (0.0.0.0/0) Die Angabe eines zusätzlichen IP Netzes wie bei dir ist dann völlig sinnfrei und ohne Funktion.
Beachte das ein VPN Gateway Redirect Konzept im Vergleich zum Split Tunneling eine deutlich schlechtere Performance hat weil der Tunnel dann sämtlichen Traffic aufnehmen muss auch den lokalen. In einem Split Tunneling Konzept wird lediglich nur der relevante Traffic fürs remote lokale Netz gesendet. Nur das du das auf dem Radar hast...
https://www.andysblog.de/wireguard-client-unter-windows
Deine WG Konfig hat trotz deiner vorgeblichen Kontrolle dennoch einen Fehler oder du hast das Tutorial nicht aufmerksam genug gelesen.
Laut deiner Konfig nutzt du ja ein Gateway Redirect Konzept also das immer der gesamte Traffic bei aktivem Tunnel ins VPN geroutet wird. (0.0.0.0/0) Die Angabe eines zusätzlichen IP Netzes wie bei dir ist dann völlig sinnfrei und ohne Funktion.
Beachte das ein VPN Gateway Redirect Konzept im Vergleich zum Split Tunneling eine deutlich schlechtere Performance hat weil der Tunnel dann sämtlichen Traffic aufnehmen muss auch den lokalen. In einem Split Tunneling Konzept wird lediglich nur der relevante Traffic fürs remote lokale Netz gesendet. Nur das du das auf dem Radar hast...
Hi und danke erstmal für die schnelle Antwort.
Ja, der Windows 11 Client hat administrative Rechte.
Die Angabe des zusätzlichen Netzes war dem Versuch geschuldet, eine Fehlerquelle auszumachen - leider erfolglos und wie du schon richtig gesagt hast, in Kombination mit der 0.0.0.0/0 eigentlich überflüssig. Dabei habe ich die schlechtere Performance tatsächlich zunächst in Kauf genommen, um eventuelle andere "Steine im Weg" zu umgehen.
Zur Ergänzung hänge ich noch die Aufforderung zur Eingabe von Netzwerkanmeldeinformationen, die folgende Fehlermeldung, einen kurzen Ping auf den Samba-Server (.45) und des laufenden WG-Clients an:
Ja, der Windows 11 Client hat administrative Rechte.
Die Angabe des zusätzlichen Netzes war dem Versuch geschuldet, eine Fehlerquelle auszumachen - leider erfolglos und wie du schon richtig gesagt hast, in Kombination mit der 0.0.0.0/0 eigentlich überflüssig. Dabei habe ich die schlechtere Performance tatsächlich zunächst in Kauf genommen, um eventuelle andere "Steine im Weg" zu umgehen.
Zur Ergänzung hänge ich noch die Aufforderung zur Eingabe von Netzwerkanmeldeinformationen, die folgende Fehlermeldung, einen kurzen Ping auf den Samba-Server (.45) und des laufenden WG-Clients an:
Auch lesenswert dazu aber ob das auch für externe 3rd Party VPN Clients gilt sei dahingestellt.
Windows VPN L2TP , falsche Anmeldedaten
Windows VPN L2TP , falsche Anmeldedaten
Danke für den Artikel - die rasphone.pbk war bei mir allerdings leer und auch mit manuellen Einträgen hat es nichts geändert.
Was allerdings was gebracht hat: ich habe einen neuen Benutzer angelegt und der kann auf den Samba-Share zugreifen?! Der andere war zwar auch noch nicht so alt und eigentlich wurde nichts in diese Richtung verändert...
Im Endeffekt bleibt jetzt noch als i-Tüpfelchen, dass ich bei VPN-Verbindung die anderen Geräte und Dienste in der Netzwerkumgebung sehe bzw. wirklich den "wie-direkt-im-LAN"-Effekt herstellen kann, falls möglich.
Im internen Netz läuft beispielsweise ein SQL-Server, andere lokale Clients sehen diesen auch und eine Software kann sich dann auf die Datenbank verbinden. Bei laufender VPN-Verbindung will das auf einem remote-Client aber nicht klappen und auch eine direkte Verbindung per IP schlägt fehl - trotz funktionierendem gegenseitigen Ping und RDP.
Vielleicht hat noch jemand Tipps und Vorschläge?
Was allerdings was gebracht hat: ich habe einen neuen Benutzer angelegt und der kann auf den Samba-Share zugreifen?! Der andere war zwar auch noch nicht so alt und eigentlich wurde nichts in diese Richtung verändert...
Im Endeffekt bleibt jetzt noch als i-Tüpfelchen, dass ich bei VPN-Verbindung die anderen Geräte und Dienste in der Netzwerkumgebung sehe bzw. wirklich den "wie-direkt-im-LAN"-Effekt herstellen kann, falls möglich.
Im internen Netz läuft beispielsweise ein SQL-Server, andere lokale Clients sehen diesen auch und eine Software kann sich dann auf die Datenbank verbinden. Bei laufender VPN-Verbindung will das auf einem remote-Client aber nicht klappen und auch eine direkte Verbindung per IP schlägt fehl - trotz funktionierendem gegenseitigen Ping und RDP.
Vielleicht hat noch jemand Tipps und Vorschläge?
Bei den "Diensten" kommt es darauf an WIE die sich bekannt machen. mDNS/Bonjour und auch Windows SSDP z.B. nutzt Link local Multicast was so über geroutete Links ohne Proxy nicht übertragbar ist. Ebenso Dienste die mit Broadcasts arbeiten die prinzipbedingt ebenfalls nicht über geroutete IP Netze übertragen werden können ohne IP Helper/Relay Funktionen im Router wie du ja auch selber weisst.
Zu all dem machst du bei deinen Diensten leider keinerlei Angaben wie diese Dienste sich selber im Netz bekannt machen bzw. welche Protokolle sie dafür nutzen so das eine zielführende Hilfe eher in wilder Raterei endet. Da fehlen also wichtige Informationen.
Wenn das Ziel pingbar ist und auch RDP klappt aber der SQL Zugriff nicht, kann man nur vermuten das hier sehr wahrscheinlich die lokale Firewall zuschlägt.
Ganz besonders wenn das Ziel ein Windows Rechner ist wo die lokale Firewall im Default den Zugriff auf Dienste aus fremden IP Netzen generell immer unterbindet. Ohne ein entsprechendes FW Customizing wird das dann nix.
Möglich wäre auch eine MTU Problematik was aber bei Wireguard VPNs wegen des immer aktiven PMTUD eher unwahrscheinlich ist.
Zu all dem machst du bei deinen Diensten leider keinerlei Angaben wie diese Dienste sich selber im Netz bekannt machen bzw. welche Protokolle sie dafür nutzen so das eine zielführende Hilfe eher in wilder Raterei endet. Da fehlen also wichtige Informationen.
Wenn das Ziel pingbar ist und auch RDP klappt aber der SQL Zugriff nicht, kann man nur vermuten das hier sehr wahrscheinlich die lokale Firewall zuschlägt.
Ganz besonders wenn das Ziel ein Windows Rechner ist wo die lokale Firewall im Default den Zugriff auf Dienste aus fremden IP Netzen generell immer unterbindet. Ohne ein entsprechendes FW Customizing wird das dann nix.
Möglich wäre auch eine MTU Problematik was aber bei Wireguard VPNs wegen des immer aktiven PMTUD eher unwahrscheinlich ist.
Ich muss gestehen, so tief stecke ich tatsächlich nicht im (Netzwerk)Thema, als dass ich sicher wüsste, wie genau sich die Dienste bekannt machen... Wie kann ich das denn herausbekommen? Ich verstehe aber durchaus deine Ausführungen dazu. Auf einige trifft wahrscheinlich tatsächlich die Bonjour/SSDP-Problematik zu.
Die Firewall auf dem Ziel (W10 Pro) habe ich testweise komplett deaktiviert - ohne Erfolg.
Es tut mir leid, dass ich nicht alle notwendigen Infos direkt mitliefere - was zum Teil sicherlich an fehlendem Wissen liegt. Ich gebe mir aber Mühe, soviel wie möglich zur Verfügung zu stellen, wenn du mir sagst, wie und was genau du brauchst.
Die Firewall auf dem Ziel (W10 Pro) habe ich testweise komplett deaktiviert - ohne Erfolg.
Es tut mir leid, dass ich nicht alle notwendigen Infos direkt mitliefere - was zum Teil sicherlich an fehlendem Wissen liegt. Ich gebe mir aber Mühe, soviel wie möglich zur Verfügung zu stellen, wenn du mir sagst, wie und was genau du brauchst.
als dass ich sicher wüsste, wie genau sich die Dienste bekannt machen...
Das musst du ja auch nicht. Ganz einfach mal den Wireshark anklemmen und selber nachsehen. 
https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
Das gilt ebenso für die SQL Problematik auf dem Zielrechner. Auch hier mal den Wireshark nutzen um zu checken das dort überhaupt die Pakete vom SQL Client ankommen. Der Server lauscht normal auf TCP 1433. Möglich auch das die SQL Server App eine Limitierung auf bestimmte IP Netze hat.
Das würdest du auch am Wireshark sehen das TCP 1433 Pakete vom Client ankommen aber der Server dann nicht antwortet.
Wenn es das denn nun war bitte dann nicht vergessen deinen Thread auch als erledigt zu schliessen!
Sorry für die lange Wartezeit - war einige Zeit verhindert und kam nicht dazu, weiter zu testen...
Ich habe - entgegen deiner Empfehlung - testweise mal NAT am Server aktiviert
und plötzlich lief es dann...
Anschließend habe ich mangels Motivation und Zeit nicht weiter nachgeforscht und bin nun erstmal glücklich damit.
Vielen Dank @aqui für deinen unermüdlichen Einsatz!
Ich habe - entgegen deiner Empfehlung - testweise mal NAT am Server aktiviert
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADEAnschließend habe ich mangels Motivation und Zeit nicht weiter nachgeforscht und bin nun erstmal glücklich damit.
Vielen Dank @aqui für deinen unermüdlichen Einsatz!
und plötzlich lief es dann...
Zeigt das du die statische Route vergessen hast. Wie gesagt, NAT im Tunnel ist überflüssig und kostet unnötig viel Performance und macht das VPN langsam. Aber egal...wenns nun klappt...Und...danke für die 💐 !
