I need help troubleshooting a WireGuard VPN setup on my MikroTik router.
My setup:
MikroTik router connected to a modem (MikroTik has public IP).
WireGuard server running on the MikroTik.
My phone has a WireGuard client profile configured.
When I’m outside my network (e.g., mobile data or other Wi-Fi), the VPN works fine — I can access LAN and internet.
But when I connect my phone to the same network as the MikroTik (e.g., same Wi-Fi) and try to connect to the VPN, it connects but no internet or server access and no handshake works.
Goal: I want to be able to test the VPN even when I’m on the same local network.
What I’ve tried:
Ensured WireGuard config is correct (works from other networks).
Tried enabling “Allow Remote Requests” in IP > DNS.
Checked firewall NAT and routing rules, but not sure if I’m missing a hairpin NAT or routing tweak.
Any advice on how to allow VPN connections from clients inside the same network to still work as if they’re remote (split/full tunnel)?
Of course it wont work if your behind the router, as you are not coming in on the WAN side you are entering from the LAN side.
To test from your smart phone while home, simply use your cellular connection (turn wifi off).
Also if the wireguard interface is to reach home, where are you trying to reach when connected to a local LAN, in other words you are already connected locally and you have no external remote entities you are trying to reach ( other than perhaps internet which you can do locally anyway).
Not sure if this is helpful, but I sometimes use the following workaround for a similar issue:
Assuming remote access via wireguard to 192.168.44.0/24
I would often set the wireguard on the client with an allowed ip addresses of 192.168.44.0/23
So when remote it will connect to 192.168.44.0/24 via wireguard.
But when on the lan with 192.168.44.0/24 it will bypass wireguard and always use lan even when wireguard is active. (because of longer prefix)
I have no issue with this on my Android devices running the official WG client. On the Android devices I use the public IP address of the router as endpoint (including having a domain pointing to that IP address). It works for either IPv4 or IPv6 public address of the router used as the Endpoint address.
The Android devices can be in any of the multiple VLANs managed by that same router. Only the Windows WireGuard client requires you to uncheck the “Block untunneled traffic” checkbox in such cases. The Android client requires no such setting.
I might be something with your firewall. You probably has an accept rule on chain input for the UDP port of WireGuard. Does that rule filter by interface/interface list and you did not include the LAN/VLAN interfaces?
Sorry but your input seems nonsensical. If you want to test your Wireguard connection ( meaning you dont want to go to a cafe etc…) simply use your cellular connection.
Attempting to test wireguard when already on the LAN, IS NOT the same thing and may require other settings on the router to be manipulated and this has nothing to do with actual use of wireguard, in this scenario.
Bogus approach and bad idea. ( stated nicely by the way )
Yes, this will be a protracted discussions if elect to engage.
It’s not a bogus use case, it’s very useful for testing. Don’t forget that unlike some other VPNs, such as those that use IKEv2, the traffic inside the tunnel happens on a separate interface (the WireGuard interface), that does not care about how the outer packets are transported.
Let’s say you want a configuration where WG clients only have access to some particular VLANs or some other resources in the network, while being denied to the rest. To test that, no need to put your phone on LTE or 5G or go outside, just use the normal WiFi and fire up the WG client. Once the WG tunnel is up you can test those firewall setups and there is no different from testing by connecting to WG through 5G at all. Because what important for that test is how the WG interface and the devices in the IP address range of that WG interface are handled by the FW, not whether the outer WireGuard packets came from the WAN interface or from the local bridge.
And of course, you can then use your wired desktop PC and your Laptop to test those use cases, no need to bring them to the coffee shop or turn on tethering on your phone at all.
Or let’s say you have multi-WAN and have configured so that clients from WG 1 tunnel always use WAN2 and clients from WG 2 tunnel always use WAN4 to go to the internet. Well, that becomes very handy, because now you can have your phone on your normal WiFi and if you suddenly want to browse some site using WAN2, instead of the default WAN1. No need to fire up WinBox or the MikroTik apps and fiddle with the router configurations, just open the WG app on the phone and select the peer for WG 1 and your phone now temporarily uses WAN2 for outside traffic. Then turn off the tunnel once done.
Another situation that I very often find myself in, is that I went outside and turned on the WG tunnel back to my home router on my 5G connection for the whole day. Now I can come home at the end of the day and my phone automatically switches to my WiFi network, while I don’t even need to remember to turn off the WG tunnel. I might even be on a call at that moment at it will still work. Because WG roaming is pretty great I won’t even notice anything and can continue to use my phone as usual, and the connections made by the phone to the remote servers are not even interrupted. And that’s thank to the ability of WG to accept connections from LAN.
(Of course, after some time, I’ll notice that my phone is still on WG and will turn the tunnel off to save some battery)
I agree that it’s not necessarily a non-sensical request. Testing can be (and should be) accomplished in some different way. The main use case for this is to not have to enable/disable tunnels upon entering/leaving the premises - which indeed is useful.
This however does not affect that this is a client issue, and different clients on different operating systems will behave differently, and will have to be configured differently.
So unlike port forwarding, there is no need to allow for hairpin nat situations etc…
Will have to try this out to see the result. You certainly point out valid use cases!!
That’s right, no need for hairpin-NAT because “outer” connections from the devices to the router only involve the input chain. And the connections inside the tunnel involve the WireGuard interface and for this there is no difference compared to when you use WG on your client devices while on the road.
But the official Windows WireGuard client has a special handling. If in your peer setting (in the Windows WG client, not on router box) you put 0.0.0.0/0 in AllowedIPs, you’ll see that the “Block untunneled traffic” checkbox is automatically turned on. In that case, you won’t be able to access any addresses in the orignal LAN subnet that the Windows machine was on (before starting the tunnel) anymore.
For example: your PC in on your 192.168.88.0/24 subnet, you start a tunnel to the router (using any of its IP addresses as endpoint), with AllowedIPs = 0.0.0.0/0 in the [Peer] section on Windows. Now the Windows WG client blocks access to every address in the 192.168.88.0/24 range.
If you turn off that “Block untunneled traffic” checkbox, the AllowedIPs field is changed to 0.0.0.0/1, 128.0.0.0/1 (and ::/1, 8000::/1 if you also had ::/0) and the PC will still have access to other devices in the same LAN subnet, but directly and not through WG. If you want that access to also be through WG, then don’t turn off the checkbox (keep 0.0.0.0/0) but add, for example 192.168.88.15/32 to AllowedIPs too and you’ll be able to access that device through the tunnel.
The Android client doesn’t have that “kill-switch” behavior. With 0.0.0.0/0 and ::/0 in Allowed IPs, you can access the original LAN subnet through the tunnel (if forwarding was allowed from the wireguard interface to that LAN/VLAN interface).
I’ll be taking some time to digest all your inputs and see what workaround I can come up with, and update as soon as i have something.
I appreciate all your engagement, it helped me view issues from multiple points.
