14
Samba Server hinter pfSense über Wireguard nicht erreichbar
Hallo,
ich habe heute in der Hetzner Cloud eine pfSense (öffentliche IPv4 und v6) installiert und mittels Wireguard Site-to-Site mit meiner FB 7590 zu Hause verbunden. Das klappt auch wunderbar.
Danach habe ich in dem Cloud-Netzwerk von Hetzner einen 2. Server aufgesetzt (10.100.0.3) und Samba installiert.
Auf diesen kann ich auch mittels der Wireguard Verbindung wunderbar zugreifen. Jedoch kann ich den Samba Share nicht als Netzlaufwerk hinzufügen auf meinem Windows PC. Als Fehler kommt immer wieder, dass der Server nicht erreichbar ist.
Hat jemand eine Idee? Muss ich in der pfSense noch irgendwas einstellen?
ich habe heute in der Hetzner Cloud eine pfSense (öffentliche IPv4 und v6) installiert und mittels Wireguard Site-to-Site mit meiner FB 7590 zu Hause verbunden. Das klappt auch wunderbar.
Danach habe ich in dem Cloud-Netzwerk von Hetzner einen 2. Server aufgesetzt (10.100.0.3) und Samba installiert.
Auf diesen kann ich auch mittels der Wireguard Verbindung wunderbar zugreifen. Jedoch kann ich den Samba Share nicht als Netzlaufwerk hinzufügen auf meinem Windows PC. Als Fehler kommt immer wieder, dass der Server nicht erreichbar ist.
Hat jemand eine Idee? Muss ich in der pfSense noch irgendwas einstellen?
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: 6381928277
Url: https://administrator.de/forum/samba-server-hinter-pfsense-ueber-wireguard-nicht-erreichbar-6381928277.html
Ausgedruckt am: 16.02.2025 um 22:02 Uhr
14 Kommentare
Neuester Kommentar
Hallo,
sind die Routen im Hetzner Network und in der PFsense gesetzt?
Bei Hetzner muss alles in der Cloud über das spezielle GW 172.31.1.1 geoutet werden.
FW regeln in der Sense gesetzt? Was sagt der Log von der pfsense?
sind die Routen im Hetzner Network und in der PFsense gesetzt?
Bei Hetzner muss alles in der Cloud über das spezielle GW 172.31.1.1 geoutet werden.
FW regeln in der Sense gesetzt? Was sagt der Log von der pfsense?
und mittels Wireguard Site-to-Site mit meiner FB 7590 zu Hause verbunden.
OT: Mich würde interessieren wer da der Server (Responder) und der Client (Initiator) ist? Ich vermute FB ist der Server und die pfSense wählt sich als Client dort ein, richtig?Alle Eigenheiten des AVM / Fritzbox Wireguard Setups erklärt dieses Tutorial.
Zum Rest hat Kollege @tech-flare schon alles gesagt. Vermutlich ein FW Problem der lokalen Winblows Firewall. Bedenke das du auf ein Share in einem Fremdnetz zugreifst. Normal blockt die Windows Firewall allen Traffic der NICHT aus ihrem lokalen Netz kommt.
Das Regelwerk passt du unter "Windows Firewall mit erweiterter Sicherheit" (Eingabe im Suchfeld) an unter den dortigen Datei- und Druckerdiensten.
Hallo,
nein, der Server bei Hetzner ist der Server, da feste IP und die FB wählt sich als Peer in die pfsense.
Mache ich ein Packet Capture auf der pfsense (LAN Interface) und will mich dann per Windows mit dem Share verbinden, kommt in der pfsense im Log das:
Grüße
nein, der Server bei Hetzner ist der Server, da feste IP und die FB wählt sich als Peer in die pfsense.
Mache ich ein Packet Capture auf der pfsense (LAN Interface) und will mich dann per Windows mit dem Share verbinden, kommt in der pfsense im Log das:
08:44:56.729131 IP 10.100.0.2.59497 > 10.100.0.3.443: UDP, length 1220
08:44:56.730836 IP 10.100.0.3 > 10.100.0.2: ICMP 10.100.0.3 udp port 443 unreachable, length 556
08:44:57.730899 IP 10.100.0.2.59497 > 10.100.0.3.443: UDP, length 1220
08:44:57.731432 IP 10.100.0.3 > 10.100.0.2: ICMP 10.100.0.3 udp port 443 unreachable, length 556
08:44:59.733156 IP 10.100.0.2.59497 > 10.100.0.3.443: UDP, length 1220
08:44:59.733813 IP 10.100.0.3 > 10.100.0.2: ICMP 10.100.0.3 udp port 443 unreachable, length 556
08:45:03.737353 IP 10.100.0.2.59497 > 10.100.0.3.443: UDP, length 1220
08:45:03.737832 IP 10.100.0.3 > 10.100.0.2: ICMP 10.100.0.3 udp port 443 unreachable, length 556Grüße
nein, der Server bei Hetzner ist der Server, da feste IP und die FB wählt sich als Peer in die pfsense.
Das ist sehr interessant. Ich versuche seit Wochen eine FritzBox als Client an einen Debian Server mit Wireguard zu verbinden woran ich bis dato gescheitert bin.Entsprechende Anleitungen im Internet und auch der entsprechende ct' Artikel gehen einzig und allein immer davon aus das die FB der Server (Responder) ist. Andersrum habe ich es noch nie gesehen.
Mich würde deshalb sehr deine Konfig auf beiden Seiten interessieren!! Ich möchte aber jetzt nicht deinen Thread hier kapern. Wenn du magst gerne per PM denn das Setup wäre sehr interessant für mich und ggf. auf für das hiesige Wireguard Tutorial sofern du dem zustimmst.
Zurück zu deinem Thema...
und will mich dann per Windows mit dem Share verbinden, kommt in der pfsense im Log das:
In welchem Log hast du das gesehen?? Firewall Log??Der Trace hat mit einem Zugriff auf einen SMB/CIFS Share augenscheinlich nichts zu tun! Das kannst du daran sehen das heutige SMB/CIFS Shares so gut wie ausschliesslich nur noch TCP 445 zur Clientkommunikation nutzen. Was du mit einem Paket Capture auf dem lokalen LAN Port auch sehen solltest. https://de.wikipedia.org/wiki/Server_Message_Block
Dein Output ist etwas sehr komisch. Er zeigt ICMP Pakete auf Port UDP 443. TCP 443 ist bekanntlich HTTPS. UDP 443 wird nirgendwo genutzt schon gar nicht von ICMP. ICMP ist bekanntlich ein eigenes IPv4 Protokoll und hat gar nichts mit UDP zu tun. In sofern passt dieser Output irgendwie gar nicht zusammen.
Eine SMB Anfrage an den Share müsste in jedem Falle TCP 445 nutzen!
Hallo,
ich habe die pfSense mithilfe des Videokurses bei Youtube von Dennis Schröder (Kanal: Raspberry Pi Cloud) gemacht und das war auch das einfachste. Inklusive der dort beschriebenen Regeln in der pfSense war ich in 30min fertig und der Tunnel Site-to-Site funktioniert wunderbar.
Zu dem Samba-Problem:
Mit dem Packet Capture muss es was zu tun haben, diese werden nur aufgefangen, wenn ich auf meinem Windows PC das Netzlaufwerk hinzufügen will. Sonst werden auf der LAN Schnittstelle garkeine Pakete aufgenommen.
In der Log zu der Firewall kann ich aber nichts finden, außer der gelb markierte Eintrag mit Port 445 - die Source Adresse passt aber nicht zu meiner vom DSL Anschluss.
Und in der Windows Firewall habe ich die beiden Regeln zu SMB (Datei- und Druckdienste) bei eingehend und ausgehend auf "beliebiges Subnetz" gestellt, bringt aber auch nichts.
ich habe die pfSense mithilfe des Videokurses bei Youtube von Dennis Schröder (Kanal: Raspberry Pi Cloud) gemacht und das war auch das einfachste. Inklusive der dort beschriebenen Regeln in der pfSense war ich in 30min fertig und der Tunnel Site-to-Site funktioniert wunderbar.
Zu dem Samba-Problem:
Mit dem Packet Capture muss es was zu tun haben, diese werden nur aufgefangen, wenn ich auf meinem Windows PC das Netzlaufwerk hinzufügen will. Sonst werden auf der LAN Schnittstelle garkeine Pakete aufgenommen.
In der Log zu der Firewall kann ich aber nichts finden, außer der gelb markierte Eintrag mit Port 445 - die Source Adresse passt aber nicht zu meiner vom DSL Anschluss.
Und in der Windows Firewall habe ich die beiden Regeln zu SMB (Datei- und Druckdienste) bei eingehend und ausgehend auf "beliebiges Subnetz" gestellt, bringt aber auch nichts.
Youtube von Dennis Schröder
Oha, der Gruseltyp mit gefährlichem Halbwissen. Von dem sollte man besser nichts übernehmen. 
Hier mal zur Info ein Wireshark Trace eines Windows 10 Professional Clients (192.168.11.100) auf einen Samba Server mit Gast Share der eine dortige Textdatei öffnet:
[public]
# Gastzugang ohne Passwort
path = /srv/samba/public/
comment = Public
read only = no
guest ok = yes
guest only = yes Funktioniert fehlerfrei auch über einen Wireguard Tunnel!
Dein oben markiert TCP 445 Zugriff kommt von einer öffentlichen IP Adresse 27.110.164.194 die von den Phillipinen kommt.
Das sieht eher nach einem Portscanner Anfriff auf deine Firewall aus wo jemand nach offenen SMB Ports sniffert. SMB wird bekanntlich niemals übers Internet übertragen, da nicht verschlüssel. Es wäre fatal und fahrlässig wenn man sowas macht.
Deine pfSense Firewall blockt den Port also zu Recht. AM WAN Port würdest deshalb du niemals SMB Traffic sehen. Dein Traffic am WAN Port kommt ja über den verschlüsselten Wireguard Tunnel mit UDP 51820 sofern du ihn nicht angepasst hast.
Wenn überhaupt könntest du also nur den entschlüsselten SMB Traffic mitcapturen der am LAN Port zu deinem Server geht oder vom Client kommt.
Hallo,
dann weiß ich leider auch nicht weiter. In meinem eigenen LAN zu Hause habe ich schon öfter Samba Server in Betrieb genommen und das hat auch funktioniert - aber hier bin ich dann leider überfragt.
Ich habe zum Testen mal nen Apache Server drauf installiert und die Standard-Website wird mir dann im Browser auch angezeigt, wenn ich http://10.100.0.3 eingebe. Das geht also
dann weiß ich leider auch nicht weiter. In meinem eigenen LAN zu Hause habe ich schon öfter Samba Server in Betrieb genommen und das hat auch funktioniert - aber hier bin ich dann leider überfragt.
Ich habe zum Testen mal nen Apache Server drauf installiert und die Standard-Website wird mir dann im Browser auch angezeigt, wenn ich http://10.100.0.3 eingebe. Das geht also
Ich habs gerade mal auf einem Wireguard Link mit pfSense und Debian probiert sowohl mit einem Win 10 als auch mit einem Apple MacBook getestet und rennt erwartungsgemäß fehlerlos.
Wenn du den erreichen kannst über den Wireguard Link dann muss in jedem Falle auch die SMB Verbindung klappen.
Wenn du dann im Windows Suchfeld \\10.100.0.3\sharename eingibst sollte sich der Windows Client problemlos mit dem Samba Server verbinden.
Achtung bei Gast Account Shares mit anderen Windows 10 Versionen als Pro und Home!! Siehe hier:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking ...
Wenn du eine solche Version verwendest scheitert zumindestens der Samba Gast Account!
Wenn alle Stricke reissen sieh dir am Server mal an was da ankommt mit tcpdump. (apt install tcpdump)
Ein tcpdump -i <lan_interface> port 445 sollte dir dann eingehenden SMB Traffic zeigen.
Ich habe zum Testen mal nen Apache Server drauf installiert
Auf den Samba Server?Wenn du den erreichen kannst über den Wireguard Link dann muss in jedem Falle auch die SMB Verbindung klappen.
Wenn du dann im Windows Suchfeld \\10.100.0.3\sharename eingibst sollte sich der Windows Client problemlos mit dem Samba Server verbinden.
Achtung bei Gast Account Shares mit anderen Windows 10 Versionen als Pro und Home!! Siehe hier:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking ...
Wenn du eine solche Version verwendest scheitert zumindestens der Samba Gast Account!
Wenn alle Stricke reissen sieh dir am Server mal an was da ankommt mit tcpdump. (apt install tcpdump)
Ein tcpdump -i <lan_interface> port 445 sollte dir dann eingehenden SMB Traffic zeigen.
Hallo,
leider kommt da auch nichts mit dem tcpdump...
Apache Server ist weiterhin erreichbar..
leider kommt da auch nichts mit dem tcpdump...
tcpdump -i ens10 port 445
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens10, link-type EN10MB (Ethernet), snapshot length 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernelApache Server ist weiterhin erreichbar..
root@backup:/home# tcpdump -i ens10 port 80
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens10, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:05:50.965378 IP 10.100.0.2.33525 > 10.100.0.3.http: Flags [S], seq 1769970522, win 64240, options [mss 1352,nop,wscale 8,nop,nop,sackOK], length 0
18:05:50.965381 IP 10.100.0.2.7511 > 10.100.0.3.http: Flags [S], seq 659755408, win 64240, options [mss 1352,nop,wscale 8,nop,nop,sackOK], length 0
18:05:50.965429 IP 10.100.0.3.http > 10.100.0.2.33525: Flags [S.], seq 1626661840, ack 1769970523, win 64860, options [mss 1410,nop,nop,sackOK,nop,wscale 7], length 0
18:05:50.965460 IP 10.100.0.3.http > 10.100.0.2.7511: Flags [S.], seq 1579693524, ack 659755409, win 64860, options [mss 1410,nop,nop,sackOK,nop,wscale 7], length 0
18:05:50.984502 IP 10.100.0.2.33525 > 10.100.0.3.http: Flags [.], ack 1, win 1024, length 0
18:05:50.984505 IP 10.100.0.2.33525 > 10.100.0.3.http: Flags [P.], seq 1:539, ack 1, win 1024, length 538: HTTP: GET / HTTP/1.1
18:05:50.984635 IP 10.100.0.3.http > 10.100.0.2.33525: Flags [.], ack 539, win 503, length 0
18:05:50.984795 IP 10.100.0.2.7511 > 10.100.0.3.http: Flags [.], ack 1, win 1024, length 0
18:05:50.986343 IP 10.100.0.3.http > 10.100.0.2.33525: Flags [P.], seq 1:2705, ack 539, win 503, length 2704: HTTP: HTTP/1.1 200 OK
18:05:50.986361 IP 10.100.0.3.http > 10.100.0.2.33525: Flags [P.], seq 2705:3461, ack 539, win 503, length 756: HTTP
18:05:51.005217 IP 10.100.0.2.33525 > 10.100.0.3.http: Flags [.], ack 3461, win 1024, length 0
18:05:55.991780 IP 10.100.0.3.http > 10.100.0.2.33525: Flags [F.], seq 3461, ack 539, win 503, length 0
18:05:56.006955 IP 10.100.0.2.33525 > 10.100.0.3.http: Flags [.], ack 3462, win 1024, length 0
Bedeutet das da vermutlich dann irgendwo noch eine Firewall im Weg ist die TCP 445 blockt wenn der Traffic gar nicht ankommt. Da wirst du dann nochmal suchen müssen...
Möglich auch das du den Samba Server an ein dediziertes Interface oder IP Netz gebunden hast. In Ermangelung aller dieser Setup Informationen kann man hier aber leider nur Kristallkugeln.
Möglich auch das du den Samba Server an ein dediziertes Interface oder IP Netz gebunden hast. In Ermangelung aller dieser Setup Informationen kann man hier aber leider nur Kristallkugeln.
Ich hab gar nix gemacht, dass sind immer Standard Configs vom Samba bis auf die privates Shares
leider kommt da auch nichts mit dem tcpdump...
Du musst dann natürlich auch einen Mount Versuch machen usw. um TCP 445 Traffic zu erzeugen.Hast du mal gecheckt ob du mit einem lokalen Rechner bzw. SMB Client auf den Samba Server zugreifen kannst? Damit kann man dann erstmal alle Firewall Fussfallen umgehen. Zumindestens das sollte fehlerfrei klappen. Ggf. auch mal einen Gast Share wie oben einrichten um ggf. Username und Passwort Problematiken zu umgehen.
Die Unix Dateirechte für das Share hast du alle korrekt eingestellt?
Fehler gefunden, es war die Option "NetBios zulassen" in dem Wireguard Tunnel in der Fritzbox.
Nun geht's wunderbar.
Nun geht's wunderbar.
Oha...ja was für andere Standard ist muss man in der FB immer noch extra setzen. War ich jetzt im Eifer des Gefechts auch nicht drauf gekommen, sorry!
Wenn's das denn war bitte nicht vergessen deinen Thread dann als gelöst zu markieren!
Wenn's das denn war bitte nicht vergessen deinen Thread dann als gelöst zu markieren!
