Solved Wireguard Server not allowing access to Intranet even though selected

[ZebMcKayhan]

For some reason, exactly same configure,
when I setup on my mac book pro, it works (access LAN without any issue)
but when I setup on my win11 laptop, it does not work. (can visit google.com, but cannot visit my LAN)

Could you discribe your setup better. Are you running vpn client for internet on the same router or is it just your server running?
Can you access the router itself? Say, the router gui?
What type of resource are you trying to reach in your lan?
What do you mean by mac book pro vs win11, are those clients to your server on some other network?

 

[ZebMcKayhan]

Enable the firewall rules portion of the page. Put 10.6.0.1 in the IP field, then enter your port in the port field and select UDP. Hit apply and you're done.

That rule does not make any sense. Wireguard udp tunnel would be between the client public ip and the router and the port should be opened in the INPUT chain, filter table. Why would you setup this port to access to your LAN??

When the tunnel is setup your wg clients would communicate out of the wireguard interface and be forwarded to lan, or wan or wherever you wish, but surely you need all ports and both udp and tcp to work.

You say that this fixed your connection issue and I cant argue with that, but I don't believe that rule fixed anything. It must have been something else.

 

[kamanwu]

Could you discribe your setup better. Are you running vpn client for internet on the same router or is it just your server running?
Can you access the router itself? Say, the router gui?
What type of resource are you trying to reach in your lan?
What do you mean by mac book pro vs win11, are those clients to your server on some other network?

Yes, I can describe my setup better.

1) both my win11 laptop and mac book pro connect to my LAN router (192.168.0.1). they use the SAME WG client setup.
a) win11 laptop can visit google.com, but cannot visit my router (cannot ping 192.168.0.1)
b) mac book pro can visit google.com, and my router (can ping and open webui)

2) I did try use my 4G phone network. So both my win11 laptop and mac book pro DO NOT connect to my LAN router. they use the SAME WG client setup.
a) win11 laptop can visit google.com, and my router (can ping and open webui)
b) mac book pro is SAME.

I think I am fine now. Since most use case is 2.a and 2.b.

But I waste more than 2 hours on 1.a

Thank you very much.

 

[ZebMcKayhan]

1) both my win11 laptop and mac book pro connect to my LAN router (192.168.0.1). they use the SAME WG client setup.
a) win11 laptop can visit google.com, but cannot visit my router (cannot ping 192.168.0.1)
b) mac book pro can visit google.com, and my router (can ping and open webui)

The only thing that comes to mind is if your local lan at your clients share the same ip range as the lan you are trying. The behaviour could then be dependant on how wg app does this. Perhaps the windows app set up so that 192.168.0.1 is reached locally.

 

[skeal]

I tracked this method down with help from merlin and a few other heavy weights. It was supposed to work like OVPN when it was first released for merlin. This was a workaround. The problem may no longer exist.

 

[Aiadi]

Try to setup VPN director rule, modify to fit you needs. (I hope I understand you right)

I have tried various settings within VPN Director without changing anything on the Firewall and this very simple one appears to be working perfectly.

My router's IP is: 192.168.1.1 (Guest's IP is 192.168.101.1) and the Wireguard's awarded Peers IP is in the range: 10.6.0.2/32. Running quite well with this setup but I just wanted to confirm that I am doing it the right way and that it does not pose any unusual security risk. Thank you again to all for their help.

 

[ZebMcKayhan]

the Wireguard's awarded Peers IP is in the range: 10.6.0.2/32

10.6.0.2/32 is not a range, its a single ip address which is my only comment to change this in your highlighted rule in vpndirector to 10.6.0.0/24 for future compatibility reasons when you add more clients to your server.

Vpndirector is aboute routing and has little to do with security so I cant comment there.

 

[Aiadi]

10.6.0.2/32 is not a range, its a single ip address which is my only comment to change this in your highlighted rule in vpndirector to 10.6.0.0/24 for future compatibility reasons when you add more clients to your server.

Vpndirector is aboute routing and has little to do with security so I cant comment there.

Noted, changed and working well. Much appreciate your pointers.

 

[raxor]

Thats' happens to me in my new Router Ax86u Pro - Merlin 3004.388.8_2 configured from scratch

I try some solutions commented before, none works in my case.

After some research and try and error.

My solution was explicit declare router LAN in client allowed IP's

1- Don't touch anything commented before, inbound firewall etc..... stay on default settings (Wireguard port can be changed of course).

2- When you created WG Client, Below QR Code in "More Settings for Site to Site Usage" declare your routers LAN network in allowed IP's for this client.
example: Allowed IPs (Client): 192.168.1.0/24,0.0.0.0/0

Like this:

3 - Deploy client config:
Windows Wireguard client example:

Yes, is counter intuitive 0.0.0.0/0 is all, but this explicit LAN's declaration do something that make it work in my case.

Maybe there are a bug in "Allow intranet" Switch

Other advice, recently suffer routing issues when mi mobile client wifi matchs IP ranges LAN -- Asus remote LAN:

Routing issues:

if your WG client are in a network that matches your router LAN's network you can have routing issues, you need to declare routes to help.

Example:
Your remote client have IP ex. 192.168.1.110 and you try to tunneling to your LAN router in 192.168.0/24, if you do not enable KillSwitch or redirect Gateway to WG Tunnel you can't access your lan services (NAS, Router), you remote client priorize local network routing.

If your client is a windows for example you can declare routes to help

You need to reach your NAS in 192.168.210

CMD Admin mode

route add 192.168.1.210 10.6.0.1

where 10.6.0.1 is Wireguard Gateway

if you do not add -p this route is deleted when you reboot windows

After use your WG tunnel you can delete this route to make everything normal again

route delete 192.168.1.210

Regards

 

[ZebMcKayhan]

Yes, is counter intuitive 0.0.0.0/0 is all, but this explicit LAN's declaration do something that make it work in my case.

while 0.0.0.0/0 means all ip's, in the world of routing it also have the lowest priority. This means that if your device have a more specific route to i.e. the local network it is connected to it will choose that path instead.

this implementation may differ between Wireguard implementation, which is why behavior could be different on Apple products vs Windows or Android for example.

Adding your LAN range (/24) would indeed give you a more specific route to your lan with higher priority and increase your chances that conflicting routes would go over Wireguard and your LAN instead instead of ending up on whatever local lan your roaming client is currently connected to.

The router itself is problematic tough. if your roaming client is connected to the same LAN 192.168.1.0/24 with a default gateway of 192.168.1.1 then there will usually be an explicit route to the gateway (192.168.1.1/32) which triumphs all other routes and even if a same route was added via AllowedIPs it may not be the best of idea to break the connection to your local gateway. unfortunately the router GUI cannot be accessed via the tunnel address 10.6.0.1 since it is bound to the LAN address.
unfortunately there are heaps of coffee shops and hotels using this common ip range - which is why it may be a good idea to change your own LAN address. for example, I use 192.168.128.0/24 for my LAN - but there are no guarantee, although it reduces the risk.

in my case, I dont see access to router GUI to be highest priority for me, I rater secure access to my NAS (192.168.128.100) and my alarm system (192.168.128.90) so I can add these routes explicitly instead of my entire network:

AllowedIPs = 0.0.0.0/0, 192.168.128.100/32, 192.168.128.90/32

Maybe there are a bug in "Allow intranet" Switch

Nope, this issue is completely confined at your roaming client. its a routing issue at the client and the local network it is connected to. the router itself does not use "AllowedIPs (Client)" at all, it's only there to populate the client config file/qrcode to your client.

 

[raxor]

while 0.0.0.0/0 means all ip's, in the world of routing it also have the lowest priority. This means that if your device have a more specific route to i.e. the local network it is connected to it will choose that path instead.

this implementation may differ between Wireguard implementation, which is why behavior could be different on Apple products vs Windows or Android for example.

Adding your LAN range (/24) would indeed give you a more specific route to your lan with higher priority and increase your chances that conflicting routes would go over Wireguard and your LAN instead instead of ending up on whatever local lan your roaming client is currently connected to.

The router itself is problematic tough. if your roaming client is connected to the same LAN 192.168.1.0/24 with a default gateway of 192.168.1.1 then there will usually be an explicit route to the gateway (192.168.1.1/32) which triumphs all other routes and even if a same route was added via AllowedIPs it may not be the best of idea to break the connection to your local gateway. unfortunately the router GUI cannot be accessed via the tunnel address 10.6.0.1 since it is bound to the LAN address.
unfortunately there are heaps of coffee shops and hotels using this common ip range - which is why it may be a good idea to change your own LAN address. for example, I use 192.168.128.0/24 for my LAN - but there are no guarantee, although it reduces the risk.

in my case, I dont see access to router GUI to be highest priority for me, I rater secure access to my NAS (192.168.128.100) and my alarm system (192.168.128.90) so I can add these routes explicitly instead of my entire network:

AllowedIPs = 0.0.0.0/0, 192.168.128.100/32, 192.168.128.90/32

Nope, this issue is completely confined at your roaming client. its a routing issue at the client and the local network it is connected to. the router itself does not use "AllowedIPs (Client)" at all, it's only there to populate the client config file/qrcode to your client.

Thank's. ZebMcKayhan

Now i spend my sunday to study LAN mask's, understanding everything and to migrate mi LAN to other ranges to prevent routing issues. I hate you and i love you

30 devices, Aimesh, IOT, 3x NAS, some static devices and configurations. Funny

This LAN range remain untouched son many years its time to work on it, after all simply works, but you are right that's a legacy settings from my RT-N16 --> Ac68u --> AC86u --> Ax88u --> AX86 Pro. Its better not stay on default's range most used in the world.

Thanks for your's explanation.

 

[ZebMcKayhan]

For future reference, there are typically 3 ways your wireguard server fails to connect to your local lan resource, assuming the tunnel itself are up and running.

1. Remote/Local ip conflict. If the lan your roaming client share the same ip range as your lan has. Could be mitigated by adding more precise routes to your resources in AllowedIPs (client). Moving your own lan ip range is a better option but no guarantee.
2. Routing issue on your router when using vpn clients. If your I.e NAS is set to use a VPN client it may not be possible to contact it via your vpn server. This could be fixed by adding a vpn director rule: Local IP (blank), Remote IP: 10.6.0.0/24, Interface: WAN. Should not be needed on 388.2_2 and onwards as it's taken care of in fw.
3. Access issue due to your local resource own firewall. Nas, windows machines and such all have build in firewall that allows access from local lan only. The firewall needs to be opened up for access from wg network (10.6.0.0/24) on every device you want to access (not on your router). Could be "fixed" by including wg network into lan (change wg ip to be adjacent to lan ip and expand lan network mask to include both) or as a last resort, add a custom firewall rule to MASQUARADE wg to lan data.

There are examples of 1 and 2 in this thread.