WireGuard en macOS dansen geen SMB

[rgos]

Is er iemand die WireGuard server en client werkend heeft gekregen op macOS waarbij ze beide ook de SMB dansen?

Ik probeer het met de instructies op deze websites:

https://docs.oakhost.net/...reguard-macos-server-vpn/

https://barrowclift.me/articles/wireguard-server-on-macos

Bestanden staan in deze repo:

https://github.com/dbuchanandev/WireGuard-macOS-IPv6

Alles doet het. De VPN-tunnel werkt, client krijgt public IP-adres van server bij internetten, client en server kunnen elkaar pingen, ssh en Screen Sharing werkt beide kanten op, server kan SMB shares op client zien.
Echter, het laatste stukje van de puzzle ontbreekt: de client kan de SMB shares op de server niet zien. En daar was alles om te doen...

Ik heb begrepen dat WireGuard in combinatie met SMB complex is. Dat komt omdat WireGuard een POINTOPOINT interface gebruikt en niet BROADCAST wat nodig is voor SMB (zie: ifconfig).
Ook het internetten voor de client met het publiek IP adres van de server was lastig maar met het openzetten van de pf firewall volgens de instructies is dat gelukt.
Maar probleem is dus dat client de SMB shares van de server niet te zien krijgt.

Heeft er iemand een idee wat voor obscure pf commando's ik op server of client moet uitvoeren om de boel open te krijgen?
Of is er nog een vage instrucie die ik in /etc/nsmb.conf kan zetten voor de client. Of mis ik een configuratie op de SMB server? Poort 445 openzetten op de router voor de client? (Kan nooit de bedoeling zijn, heb ik nog niet gedaan, maar zal het nog eens proberen in uiterste desperatie).

[ Voor 0% gewijzigd door rgos op 16-01-2025 13:10 . Reden: spel ]

[Ben(V)]

Kun je die shares niet gewoon mounten zonder dat je ze ziet, dus via hun ipadres?
Die broadcast worden volgens mij alleen gebruikt voor inventarisatie van je lan, ofwel ze te zien te krijgen.

[rgos]

Nee, shares zijn ook niet te mounten met ip adres.
smb://10.0.0.1 geeft in Finder foutmelding dat er geen shares zijn op de server.

Dit is wel idd een suggestie die je vaker tegenkomt. Gekke is dat de shares van de client zich probleemloos laten zien in de Finder op de server. Dus broadcast (die daarvoor gebruikt wordt) lijkt daar wel te werken.

[Juup]

rgos schreef op donderdag 16 januari 2025 @ 13:07:
smb://10.0.0.1 geeft in Finder foutmelding dat er geen shares zijn op de server.

Hmmm... da's vreemd.
Als je nog telnet hebt (anders via brew te installeren), wat is dan de output van

telnet 10.0.0.1 139

?

[rgos]

code:

% telnet 10.0.0.1 139
Trying 10.0.0.1...
telnet: connect to address 10.0.0.1: Connection refused
telnet: Unable to connect to remote host

Maar na installatie van telnetd op server:

code:

% telnet 10.0.0.1 139
Trying 10.0.0.1...
Connected to 10.0.0.1.
Escape character is '^]'.
login:

Werkt dus allemaal. Maar samba dansen, ho maar.

[ Voor 41% gewijzigd door rgos op 16-01-2025 13:59 ]

[MasterL]

Wordt er überhaupt een connectie gemaakt met poort 139? Volgens mij is deze al een tijdje deprecated en wordt 445 gebruikt sinds een hele tijd. Draai eens een tcpdump met een source filter met het client IP-adres. Ik vermoed dat er gewoon een request wordt gedaan naar poort 445 maar deze in een (lokale) FW geblokkeerd wordt. Gezien het feit dat het one-way wel werkt lijkt mij een wireguard probleem zo goed als uitgesloten, niet verassend want SMB is ook gewoon normaal (routable) TCP verkeer.

[Ben(V)]

Je zou kunnen proberen het volgende in de smb config op te nemen:

bind interfaces only = no

Samba zal dan op alle interfaces willen "binden" dus inclusief de wireguard die geen broadcast ondersteund.
Je zal dan nog steeds geen shares zien, maar op ipadres zou je wel wel moeten kunnen mounten.

[rgos]

code:

bind interfaces only = no

Ook al vaak tegengekomen. En nog vaker geprobeerd. No go.

Nog een andere suggestie tegengekomen:

https://www.reddit.com/r/..._wireguard_on_a_mac_as_a/

code:

sysctl -w net.inet.ip.forwarding=1

Rechtstreeks in /etc/pf.conf:

code:

nat on en1 from 10.1.0.0/24 to any -> (en1)

nat on utun1 from 10.1.0.0/24 to any -> (utun1)

Herstarten pf.

code:

sudo pfctl -ef /etc/pf.conf

Zowel op server als client geprobeerd (met de correcte interfaces en adressen, natuurlijk). No go.

Dit doet het postup.sh script trouwens ook op de server (minus de tweede rule) en dat zorgt ervoor dat internetten met publiek IP adres van server voor client werkt. Hoopte even dat die tweede rule SMB zou laten werken. Niks dus.

[ Voor 12% gewijzigd door rgos op 16-01-2025 19:53 ]

[rgos]

Trouwens, ik zie nu dat die SMB-shares van de client zich niet, zoals ik schreef, automatisch aankondigen in Finder op de server. Wel zijn de shares gewoon bereikbaar op smb://10.0.0.2

Maar dat is ook zoals je het verwacht met WireGuard: geen broadcast interface.

[rgos]

MasterL schreef op donderdag 16 januari 2025 @ 16:16:
Draai eens een tcpdump met een source filter met het client IP-adres.

Op de client neem ik aan?
Client heeft ip: 10.0.0.2 interface: utun0

[rgos]

code:

% sudo tcpdump -v -i utun0 dst 10.0.0.2 and src 10.0.0.1
tcpdump: listening on utun0, link-type RAW (Raw IP), capture size 262144 bytes
17:28:55.573605 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    10.0.0.1.microsoft-ds > 10.0.0.2.57818: Flags [S.E], cksum 0xec75 (correct), seq 3992669256, ack 4152056553, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 2781890722 ecr 4006668542,sackOK,eol], length 0
17:28:55.573613 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    10.0.0.1.microsoft-ds > 10.0.0.2.57818: Flags [S.], cksum 0xec88 (correct), seq 3992669256, ack 4152056553, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 2781890722 ecr 4006668587,sackOK,eol], length 0
17:28:55.573617 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    10.0.0.1.microsoft-ds > 10.0.0.2.57818: Flags [S.], cksum 0xec5c (correct), seq 3992669256, ack 4152056553, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 2781890722 ecr 4006668631,sackOK,eol], length 0
17:28:55.584180 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    10.0.0.1.microsoft-ds > 10.0.0.2.57818: Flags [.], cksum 0x23bb (correct), ack 1, win 2052, options [nop,nop,TS val 2781890733 ecr 4006668650], length 0
17:28:55.632350 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    10.0.0.1.microsoft-ds > 10.0.0.2.57818: Flags [.], cksum 0x2359 (correct), ack 2, win 2052, options [nop,nop,TS val 2781890782 ecr 4006668698], length 0
17:28:55.632356 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    10.0.0.1.netbios-ssn > 10.0.0.2.57819: Flags [R.], cksum 0xb379 (correct), seq 0, ack 2224128348, win 0, length 0
17:28:55.633477 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    10.0.0.1.microsoft-ds > 10.0.0.2.57820: Flags [S.E], cksum 0x965d (correct), seq 1872296696, ack 4123321388, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 3774441359 ecr 1869393033,sackOK,eol], length 0
17:28:55.633482 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    10.0.0.1.microsoft-ds > 10.0.0.2.57818: Flags [F.], cksum 0x2356 (correct), seq 1, ack 2, win 2052, options [nop,nop,TS val 2781890784 ecr 4006668698], length 0

Zoiets? Server zit op 10.0.0.1
Als ik connectie maak met smb://10.0.0.1 komt er dit binnen.
Is 10.0.0.1.netbios-ssn de NetBIOS name die wordt aangeboden? En wat is 10.0.0.1.microsoft-ds?
Ja, komt dus binnen op poort 445:

code:

% sudo tcpdump -v -i utun0 dst 10.0.0.2 and src 10.0.0.1 and src port 445

Meer specifiek:
10.0.0.1.netbios-ssn komt binnen op poort 139 (slechts 1x)
10.0.0.1.microsoft-ds komt binnen op poort 445

Tja, dan zit er ergens een blokkade op de client zo te zien.

[ Voor 8% gewijzigd door rgos op 16-01-2025 18:50 ]

[rgos]

netbios-ssn: NetBIOS Session Service
microsoft-ds: Microsoft Direct SMB

[ Voor 8% gewijzigd door rgos op 16-01-2025 18:56 ]

[rgos]

Tja, dan zit er ergens een blokkade op de client zo te zien.

Hoewel, dat klopt niet helemaal.
SMB pakketten van server komen binnen bij client op poort 445.
Echter, er worden geen shares gevonden.
WireGuard en macOS is geen gelukkig huwelijk.

[ Voor 0% gewijzigd door rgos op 17-01-2025 09:17 . Reden: . ]

[Frogmen]

Wat draait de server zag toevallig in Truenas dat je een specifieke optie voor Mac clients moest aanzetten.

[MasterL]

Oke.. Ik probeer een beetje een mentaal plaatje te maken van het probleem maar er is wel een beetje veel "ruis" je schrijft in je ts:

rgos schreef op donderdag 16 januari 2025 @ 11:52:
Alles doet het. De VPN-tunnel werkt, client krijgt public IP-adres van server bij internetten, client en server kunnen elkaar pingen, ssh en Screen Sharing werkt beide kanten op, server kan SMB shares op client zien.
Echter, het laatste stukje van de puzzle ontbreekt: de client kan de SMB shares op de server niet zien. En daar was alles om te doen...

Dus conclusie:
- Wireguard heeft/maakt netjes verbinding.
- SMB werkt toch? Ik bedoel je kan vanaf de "server" shares op de "client" mounten.

Hoe kom je tot de conclusie dat het überhaupt een WG probleem is als het one-way gewoon werkt?
De TCPdump was een vraag van mij om te bepalen of de packet binnen komen op de server, dus client>server (met als filter een source van de client). Wat wij willen weten is toch of de client verbinding maakt met de server? Andersom werkt al.

Wat is uberhaupt je route table op beide devices?
Ik zie ook dingen als:
nat on en1 from 10.1.0.0/24 to any -> (en1)
nat on utun1 from 10.1.0.0/24 to any -> (utun1)

Dit is hetzelfde subnet? Je gebruikt toch niet hetzelfde subnet (of een subset daarvan) zowel in de tunnel als in je "lan"?

Dus resume:
Wat is je route table op de server?
Wat is je route table op de client?
Welke subnets gebruik je allemaal binnen de tunnel (wellicht staat dit in de route table maargoed).
Doe eens een TCPdump op de server, we willen weten of er packets binnenkomen vanaf de client die de server daadwerkelijk bereiken.

[rgos]

Bedankt voor het meedenken.

De desperatie heeft toegeslagen dus ik heb poort 445 op de routers voor client en server opengezet (wel met originating IP restrictie dus kan geen kwaad). WireGuard staat even helemaal aan de kant.
Wat blijkt? Het probleem blijft bestaan: client kan nog steeds de SMB-shares van de server niet zien. Andersom geen probleem. Dan ligt het toch aan de client.

Dus even een andere oude macOS bak aangezwengeld. Snow Leopard (zo da's lang geleden). Command K, smb://serveradres, maakt verbinding, maar geeft "invalid username or password". Huh? Op server File Sharing > Options > Windows File Sharing > aanvinken voor mijn account (staat op client trouwens niet aangevinkt!), nogmaals Command K, smb://serveradres. Bingo! Daar staan ze: SMB server shares.

Vervolgens naar de oorspronkelijke client met Monterey 12.7.4. Command K, smb://serveradres. Niks! Probleem blijft bestaan.

Ook daar nog even geprobeerd: File Sharing > Options > Windows File Sharing > aanvinken voor mijn account. Nog steeds niks:

There was a problem connecting to the server.

There are no shares available or you are not allowed to access them on the server.
Please contact your system administrator to resolve the problem.

Laat ik dat maar eens doen...

[rgos]

En nog even getest met een moderne laptop, Sonoma (ja, het is door de jaren heen een Apple-huishouden geworden).
Command K, smb://serveradres. Bingo! SMB server shares.

Toch eens kijken of we die client naar Monterey 12.7.6 kunnen schoppen.

[ Voor 3% gewijzigd door rgos op 17-01-2025 20:03 ]

[rgos]

OK, Monterey 12.7.6. Probleem blijft bestaan.
Dus nu de mooie opdracht om uit te zoeken wel stuk software met mijn pure SMB loopt te klooien (het zal toch niet WireGuard zelf zijn?).

[rgos]

Veel problemen met SMB op Monterey:

https://www.google.com/se...working&ie=UTF-8&oe=UTF-8

[ Voor 13% gewijzigd door rgos op 17-01-2025 14:30 ]

[rgos]

Ja, SMB op Monterey is ernstig kapot.

Inloggen met Cyberduck lukt wel. Eindelijk SMB server shares.
Finder blijft problemen geven.

Ik ga nog op zoek naar de reden waarom SMB op Monterey niet werkt en zal het melden wanneer die gevonden is. Bedankt voor alle suggesties.

[rgos]

OK, een workaround voor de niet-werkende Command K in de Finder:

In Terminal:

mount_smbfs //username@serveradres/sharename ./mntpoint

en dan wordt de share wel gevonden en zichtbaar in Finder.