Win11 + Wireguard VPN = devices in vpn-netwerk onbereikbaar

[WheeleE]

Casus
Een familielid in het buitenland heeft een W11 (23H2) laptop met daarop een Wireguard-client die verbinding maakt met de Wireguard-VPNserver op mijn Asus RT-AX58U router. De laptop is in eigen beheer zonder afgeschermde accounts.
De bedoeling is om via de vpn incidenteel bestanden op mijn nas te uploaden en het een en ander onderling te delen.

Probleem
Lokale devices in mijn netwerk kunnen niet worden gevonden als de verbinding is opgezet. De NAS niet, maar ook een raspberry of mediaspeler worden niet gevonden.

De troubleshooting tot nu toe

• De connectie met de vpn zelf wordt zonder problemen gemaakt (geen errors in de logging).
• Internetsites worden ook zonder problemen weergegeven.
• Whatsmyip.org laat zien dat er via mijn verbinding wordt gewerkt.
• Een andere kennis in het buitenland kan met dezelfde vpn-config zonder problemen overal bij
• Ipconfig output voor de vpn-adapter laat een ipadres zien in de 10.6.x.x reeks, conform verwachting (maar de default gateway staat op 0.0.0.0, net zoals bij andere wel-werkende clients):
  
• Firewall en Windows Defender uitschakelen maakt geen verschil.
• Pingen naar een ip-adres van een ander device in mijn netwerk geeft “general failure” error, niet de bekende "request timed out".

Mijn troubleshootlijst is nu helemaal afgevinkt. Het probleem zit op de laptop en niet in de vpn-config, lijkt me.
Ik vermoed ergens in een netwerkinstelling voor een gateway, dnsserver of iets dergelijks. Maar wat precies en waar gaat mijn kennis te boven.
Zoek ik in de juiste richting?

[Question Mark]

Laat de routetabel eens zien op de client als de vpn aan staat?

(route print)

[WheeleE]

[nelizmastr]

Ok, en hoe ziet die eruit op een client die wel werkt?

Wat is je interne subnet (dus niet het wireguard subnet)?

Op basis van deze print is er alleen een route naar zichzelf en naar het internet over de tunnel.

[WheeleE]

Mijn interne netwerk draait in 192.168.1.x.

Vandaag heb ik kunnen testen met een windowspc bij iemand anders thuis:

code:

===========================================================================
Interface List
 25...........................WireGuard Tunnel
 12...bc 5f f4 3f d8 f8 ......Qualcomm Atheros AR8151 PCI-E Gigabit Ethernet Controller (NDIS 6.30)
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1     192.168.0.15     25
          0.0.0.0          0.0.0.0         On-link          10.6.0.7      0
         10.6.0.7  255.255.255.255         On-link          10.6.0.7    256
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.0.0    255.255.255.0         On-link      192.168.0.15    281
     192.168.0.15  255.255.255.255         On-link      192.168.0.15    281
    192.168.0.255  255.255.255.255         On-link      192.168.0.15    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      192.168.0.15    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      192.168.0.15    281
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
 12    281 ::/0                     fe80::1a35:d1ff:febf:308
  1    331 ::1/128                  On-link
 12    281 2001:1c00:1102:1300::/64 On-link
 12    281 2001:1c00:1102:1300:2de6:c441:f152:dc3a/128
                                    On-link
 12    281 2001:1c00:1102:1300:71c9:b11d:2a3b:21d8/128
                                    On-link
 12    281 2001:1c00:1102:1300:85e3:9ba5:4298:256f/128
                                    On-link
 12    281 2001:1c00:1102:1300:bc3c:44c0:45f1:514b/128
                                    On-link
 12    281 2001:1c00:1102:1300:cf65:c821:cb98:c219/128
                                    On-link
 12    281 2001:1c00:1102:1300:f08a:7141:1262:5eb6/128
                                    On-link
 12    281 fe80::/64                On-link
 12    281 fe80::5471:b37a:43a2:dd3a/128
                                    On-link
  1    331 ff00::/8                 On-link
 12    281 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Deze pc zit zelf in een 192.168.0.x subnet.

Als ik de twee outputs vergelijk zie ik bij de werkende client een active ip4 route voor de Wireguard tunnel interface. Bij de niet-werkende client zie ik die inderdaad niet.
De vpn-clientconfig is identiek, maar toch wordt op de laptop een ander soort tunnel opgezet...waarom?

Ik zit er over te denken om het vpn-stuk voorlopig in de ijskast te zetten tot de betreffende laptop (en bijbehorende persoon) hopelijk volgend jaar weer een keer in het land is en troubleshooten makkelijker is.
Of een keer openvpn te proberen.

[pennywiser]

Hi gebruik PiVPN op je Raspberry. Dat is een shell over Wireguard of Openvpn. Dan ben je wat flexibeler. Je hebt dan ook een debug functie en krijgt Wireguard patches wanneer ze er zijn. In je modem krijg je die niet of nauwelijks. Of misschien wel nooit meer als firmware support gestopt is.

[sjorsjuhmaniac]

@WheeleE ik zie in beide route dumps 2x een route voor je tunnel interface staan. Ik snap je conclusie van het verschil daarom niet.

[sjorsjuhmaniac]

Kan je eens een trace route doen op de werkende cliënt?

code:

tracert 192.168.1.NAS

Ik zou namelijk verwachten dat geen van beide clients werken omdat ik geen route zie voor jou subnet 192.168.1.x

Ps je kan makkelijk vanaf thuis testen met een ‘iemand van ver’ setup door je eigen laptop via de hotspot van je mobiele telefoon te verbinden. Je laptop zit dan via je mobiel op het internet.

[WheeleE]

pennywiser schreef op maandag 7 oktober 2024 @ 18:03:
Hi gebruik PiVPN op je Raspberry. Dat is een shell over Wireguard of Openvpn. Dan ben je wat flexibeler. Je hebt dan ook een debug functie en krijgt Wireguard patches wanneer ze er zijn. In je modem krijg je die niet of nauwelijks. Of misschien wel nooit meer als firmware support gestopt is.

PiVPN heb ik een tijdje gebruikt toen ik nog Raspberry’s had.
Nu heb ik een proxmox-host waar ik een wireguard-server op kan draaien maar daar moet ik nog een keer goed induiken.

sjorsjuhmaniac schreef op maandag 7 oktober 2024 @ 18:09:
@WheeleE ik zie in beide route dumps 2x een route voor je tunnel interface staan. Ik snap je conclusie van het verschil daarom niet.

Ik koppelde deze regel
Interface List
25...........................WireGuard Tunnel

Aan deze regel.

Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.15 25
Bij de niet-werkend client is zo'n match er niet.

Dat daar allebei 25 staat (interface, metric) is toevallig? Ik heb geen kaas gegeten van dit soort netwerktroubleshooting dus geloof zo dat ik er compleet naast zit.

sjorsjuhmaniac schreef op maandag 7 oktober 2024 @ 18:23:
Kan je eens een trace route doen op de werkende cliënt?

code:

tracert 192.168.1.NAS

Ik zou namelijk verwachten dat geen van beide clients werken omdat ik geen route zie voor jou subnet 192.168.1.x

Ps je kan makkelijk vanaf thuis testen met een ‘iemand van ver’ setup door je eigen laptop via de hotspot van je mobiele telefoon te verbinden. Je laptop zit dan via je mobiel op het internet.

Dat is wel een goeie tip.
Mijn eigen laptop is alleen wel een MacBook, geen windowsmachine:

code:

% traceroute 192.168.1.90
traceroute to 192.168.1.90 (192.168.1.90), 64 hops max, 40 byte packets
 1  10.6.0.1 (10.6.0.1)  40.790 ms  31.407 ms  31.666 ms
 2  192.168.1.90 (192.168.1.90)  39.914 ms  50.698 ms  76.042 ms

[sjorsjuhmaniac]

WheeleE schreef op maandag 7 oktober 2024 @ 20:05:
[...]

Ik koppelde deze regel
Interface List
25...........................WireGuard Tunnel

Aan deze regel.

Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.15 25
Bij de niet-werkend client is zo'n match er niet.

Dat daar allebei 25 staat (interface, metric) is toevallig? Ik heb geen kaas gegeten van dit soort netwerktroubleshooting dus geloof zo dat ik er compleet naast zit.

Nee dat is toevallig hetzelfde getal. Zoek naar regels waar je interface het ip van je tunnel heeft. Ik zit op mijn tel dus kan niet makkelijk copy pasten.

[...]
el een goeie tip.
Mijn eigen laptop is alleen wel een MacBook, geen windowsmachine:

code:

% traceroute 192.168.1.90
traceroute to 192.168.1.90 (192.168.1.90), 64 hops max, 40 byte packets
 1  10.6.0.1 (10.6.0.1)  40.790 ms  31.407 ms  31.666 ms
 2  192.168.1.90 (192.168.1.90)  39.914 ms  50.698 ms  76.042 ms

Goed dat werkt prima dus. Als je pingt, krijg je dan ook wat terug? Kan je de nas benaderen op deze manier?
Niet een super vergelijk omdat het een MacBook is maar daar heb je ook een route table op: route
Kijk een hoe daar de routes staan ingesteld.
Kan je ook de route op je Mac eens bekijken als je gewoon thuis op je wifi zit? Ik zou dan ook traceroute doen en kijken waar het heen gaat als je het lokale ip van je ver weg client intypt, de 192.168.110.x. Die zou naar je router toe moeten gaan.
Kan je de routes in je router zien? Weet je zeker dat je de addresses in je weg config in je router goed hebt staan? Ergens in je router moet je namelijk ook de router instrueren om 192.168.110.x over de tunnel terug moet sturen.

Ik zou wat meer moeten testen maar die tracert op de machine ver weg wannee die verbinden is is wel interessant om te zien.

[WheeleE]

@sjorsjuhmaniac Dank voor je hulp so far!
Als ik m'n macbook met de vpn verbind kan ik mijn NAS pingen, de webinterface bereiken, alles. Precies zoals verwacht.

De routes vanaf mn laptop:
Met vpn

code:

netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags               Netif Expire
default            link#25            UCSg                utun6       
default            172.20.10.1        UGScIg                en0       
3.230.88.176       link#25            UHWIig              utun6       
10.6.0.1           link#25            UHWIig              utun6       
10.6.0.3           10.6.0.3           UH                  utun6       
17.248.236.65      link#25            UHWIig              utun6       
34.107.221.82      link#25            UHWIig              utun6       
34.120.208.123     link#25            UHWIig              utun6       
52.213.179.173     link#25            UHW3Ig              utun6      7
95.101.74.102      link#25            UHWIig              utun6       
95.101.74.224      link#25            UHWIig              utun6       
127                127.0.0.1          UCS                   lo0       
127.0.0.1          127.0.0.1          UH                    lo0       
142.251.39.106     link#25            UHWIig              utun6       
151.101.37.91      link#25            UHWIig              utun6       
157.240.201.61     link#25            UHWIig              utun6       
162.159.136.234    link#25            UHWIig              utun6       
169.254            link#6             UCS                   en0      !
172.20.10/28       link#6             UCS                   en0      !
172.20.10.1/32     link#6             UCS                   en0      !
172.20.10.1        76:9e:af:94:86:64  UHLWIir               en0   1171
172.20.10.5/32     link#6             UCS                   en0      !
192.168.1.72       link#25            UHWIig              utun6       
192.168.1.111      link#25            UHWIig              utun6       
192.229.221.95     link#25            UHWIig              utun6       
224.0.0/4          link#25            UmCS                utun6       
224.0.0/4          link#6             UmCSI                 en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI                en0       
239.255.255.250    link#25            UHmW3I              utun6      8
255.255.255.255/32 link#25            UCS                 utun6       
255.255.255.255/32 link#6             UCSI                  en0      !
255.255.255.255    link#25            UHW3bI              utun6      8

Zonder vpn

code:

% netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags               Netif Expire
default            192.168.1.1        UGScg                 en0       
127                127.0.0.1          UCS                   lo0       
127.0.0.1          127.0.0.1          UH                    lo0       
169.254            link#6             UCS                   en0      !
192.168.0/23       link#6             UCS                   en0      !
192.168.1.1/32     link#6             UCS                   en0      !
192.168.1.1        3c:7c:3f:4b:d:d0   UHLWIir               en0   1164
192.168.1.71       bc:24:11:59:69:39  UHLWIi                en0   1181
192.168.1.90       90:9:d0:10:d3:25   UHLWIi                en0   1167
192.168.1.111      0:e:58:fc:4f:f2    UHLWIi                en0   1119
192.168.1.121/32   link#6             UCS                   en0      !
192.168.1.135      7e:f1:8e:ac:2e:b2  UHLWIi                en0   1148
192.168.1.175      0:e:58:7d:a6:f2    UHLWI                 en0   1170
192.168.1.208      link#6             UHRLWI                en0      !
192.168.1.236      5c:2f:af:12:2a:82  UHLWI                 en0   1174
224.0.0/4          link#6             UmCS                  en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI                en0       
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI                en0       
255.255.255.255/32 link#6             UCS                   en0      !
255.255.255.255    ff:ff:ff:ff:ff:ff  UHLWbI                en0      !

En traceroute met vpn:

code:

% traceroute 192.168.1.90
traceroute to 192.168.1.90 (192.168.1.90), 64 hops max, 40 byte packets
 1  10.6.0.1 (10.6.0.1)  59.371 ms  37.894 ms  40.049 ms
 2  192.168.1.90 (192.168.1.90)  41.052 ms  42.750 ms  45.393 ms

En zonder:

code:

% traceroute 192.168.1.90
traceroute to 192.168.1.90 (192.168.1.90), 64 hops max, 40 byte packets
 1  192.168.1.90 (192.168.1.90)  8.744 ms  2.181 ms  1.852 ms

Dat ziet er allemaal logisch uit volgens mij.

Ik kan in de router helaas geen logging van de vpn vinden. In de configuratie is ook geen optie voor het routeren van verkeer. De enige configuratie die aan te passen is, is die van de clients:

code:

[Interface]
PrivateKey = yyyy
Address = 10.6.0.4/32
DNS = 10.6.0.1

[Peer]
PublicKey = yyyy
AllowedIPs = 0.0.0.0/0
Endpoint = <mijn externe ip>:<poortnr>
PersistentKeepalive = 25

Geen exotische dingen lijkt me.

Een traceroute naar de verweg-laptop lukt pas richting het einde van de week. Dan is die persoon weer bereikbaar/beschikbaar.

[sjorsjuhmaniac]

Ja mee eens. Ziet er normaal uit. Wat je zowel hier als bij de falende route tabel ziet is dat er 2 default routes zijn en geen specifieke routes voor het subnet in je thuis lan. Dat betekend dat in beide gevallen de data via de default route verstuurd wordt. In het Windows voorbeeld kan je aan de metrics zien dat de vpn in dat geval gekozen wordt door de lagere kosten. Ik kan dat in bij de Mac niet herleiden maar die werkt dus daar gaat het goed.

Wat interessant is om te weten en waar de data daadwerkelijk blijf hangen. Daarom zou het mooi zijn om wat te capturen. Dat kan met wireshark of tcpdump. Ik zou die op je nas draaien en filteren op het locale ip van de client waarmee je aan het testen bent. Voor de werkende Mac dus op ip 172….. je kan nu alvast je werkende setup testen waardoor deze test bij je bekend wordt en je hem makkelijker uitvoert als je verre vriend online is.

Met de werkende Mac zou ik ook proberen of je vanaf je nas de Mac kan pingen op 172…..

Het enige wat ik niet begrijp is hoe jou asus router nu moet weten dat 192.168.110.x of 192.168.0.x aan de andere kant van de tunnel leven.
In mijn router moet ik hiervoor zelf een route aanmaken. Voor ieder subnet dat aan de andere kant van de tunnel zet en bereikbaar moet zijn.

Blijkbaar weerkt er iets in je router om die route bekend te maken. Heb je niet toevallig subnet 193.168.0.x in de wg config ergens toegevoegd? Als allowed ip?
Zou je een willen proberen om je home kan toe te voegen aan het allowed ip van je client wg config, dus “0.0.0.0/0,192.168.1.0/24”. Kijk eens of de Mac dan nog steeds werkt.

En een trace in die setup als het werkt

[WheeleE]

Ik heb geprobeerd om verder onderzoek te doen, maar het duizelt me nogal. Het gaat mijn kennis en begrip een beetje te boven merk ik.
Komende week ga ik met de verre laptop nog 1 poging doen met een verse Wireguard-clientconfig. Als dat niet werkt probeer ik OpenVPN, en als dat ook geen soelaas biedt schrijf ik de VPN voorlopig af.
@sjorsjuhmaniac Dank voor alle recente bijstand!

[Wylana]

Ik denk dat dit komt door IPV6 boven IPV4 gaat.

Diverse klanten hebben dit issue ook gehad.

Zet IPV6 eens uit op je adapter (LAN/WIFI) en probeer het dan nog eens.

[WheeleE]

Wylana schreef op donderdag 17 oktober 2024 @ 16:50:
Ik denk dat dit komt door IPV6 boven IPV4 gaat.

Diverse klanten hebben dit issue ook gehad.

Zet IPV6 eens uit op je adapter (LAN/WIFI) en probeer het dan nog eens.

Bedoel je in de instellingen va de VPN-server? Daar zie ik alleen een vinkje "Enable NAT - IPv6"
Buiten de VPN staat in m'n router IPv6 verder helemaal uit.

[sjorsjuhmaniac]

WheeleE schreef op donderdag 17 oktober 2024 @ 19:44:
[...]

Bedoel je in de instellingen va de VPN-server? Daar zie ik alleen een vinkje "Enable NAT - IPv6"
Buiten de VPN staat in m'n router IPv6 verder helemaal uit.

Nee hij bedoelt op de cliënt. De verre laptop in dit geval.

[WheeleE]

Goed nieuws en slecht nieuws!
Het slechte nieuws is dat IP6 disablen niet heeft geholpen. En een aparte Wireguardserver optuigen gaf ook geen soelaas.
Het goede nieuws is dat OpenVPN in 1 keer werkte.

Uiteindelijk niet de meest ideale oplossing, maar het werkt. En na al het gedoe ben ik blij er van af te zijn .
Iedereen die meegedacht heeft hartelijk dank!

[rgos]

WireGuard werkt niet goed met SMB (interface is POINTOPOINT niet BROADCAST wat nodig is voor SMB).

Zie: https://unix.stackexchang...d-wireguard-vpn-interface

[WheeleE]

@rgos Kan dat ook meespelen als het om webinterfaces gaat? Ik heb tijdens het testen nergens een SMB-share proberen te benaderen. Het ging alleen om webinterfaces. De Synology-webportal van mijn NAS voornamelijk. Maar op die Synology zijn wel SMB-shares aanwezig volgens mij.

[ Voor 12% gewijzigd door WheeleE op 13-01-2025 18:53 ]

[rgos]

Dat zou minder problematisch moeten zijn. Maar kennelijk is dat bij jou ook niet gelukt? Ping naar NAS lukte niet?
Die apparaten kondigen zich meestal met een NetBIOS naam aan, en dat werkt dus niet met WireGuard.
Ze zijn dus niet automatisch zichtbaar in Verkenner of Finder.

[ Voor 41% gewijzigd door rgos op 13-01-2025 19:31 ]

[WheeleE]

@rgos nope, ping naar ip werkte niet en via een browser de webinterfaces ook niet. Ik heb het opgegeven en gebruik nu OpenVPN. Als het niet linksom gaat dan moet het maar rechtsom.