Your VPN client says connected, the handshake is a minute old, and you can ping the router's tunnel address. Except that the NAS, the printer and the server behind that router answer nothing.
This chapter is about a tunnel that is up but passes nothing. If the tunnel never comes up, go to There is no WireGuard handshake. If no traffic passes at all, not even to the router, see The VPN is up but no traffic passes. If two sites reach each other only one way, see Two sites see each other only one way.
The quick checks, in order
- Does the client know where the LAN is? On Windows
route print, on Linuxip route, on a phone the routes in the VPN app. A good answer lists the LAN subnet, via the tunnel. If it is not there, your client never sends the packets and there is nothing to look for in the router. - Is traffic going through the tunnel?
/interface wireguard peers print. A good answer hasrxandtxclimbing, and alast-handshakeless than two minutes old. - Can the router reach the target?
/ping 192.168.88.10 src-address=10.10.10.1, using the router's tunnel address as source. If that fails, the problem is on the LAN side and not in the VPN. This is the most important fork in this chapter. - Do the packets leave the router?
/tool sniffer quick interface=bridge ip-address=10.10.10.2. If you see them go out and nothing come back, the target device is ignoring you. - Is a drop rule counting?
/ip firewall filter print statswhile you try. A rule whose counter moves exactly in step points at itself. - What is the target device doing? Look at its own firewall and its gateway. Ping back from that device to the client's tunnel address.
The usual causes, most common first
AllowedIPs does not contain your network
With WireGuard, AllowedIPs in the client configuration decides which destinations go through the tunnel. Switch All traffic through the VPN off in the tool and the configurator writes AllowedIPs = <tunnel network>, <LAN network>, and that LAN network is the untagged LAN only. If your machines live on a VLAN with a different subnet, that subnet is not in the file and the client simply sends those packets over its own internet connection. Add the missing subnets after a comma, or use full tunnel.
The target device's own firewall
Windows treats 10.10.10.2 as a foreign network. The rules that allow file sharing, RDP and printers often only cover the local subnet. The device then answers ping and nothing else. Add the tunnel subnet to the allowed ranges on that machine.
The target device does not use the router as its gateway
A NAS with its own gateway, a server with a manual route, a second router on the LAN: the reply then goes somewhere else and never returns through the tunnel. The sniffer check above shows it straight away.
Overlapping subnets
You are in a cafe on 192.168.88.0/24 and your office is 192.168.88.0/24 as well. The client then picks its own local network and no setting repairs that. It happens often, because that is exactly the RouterOS default range. The only cure is to choose a different LAN range; see Planning addresses.
You reach the hosts but not the router
That is a different problem with the same feel. The firewall's input chain only accepts traffic coming from the LAN list. If the tunnel is not in that list, you can reach LAN devices fine but not the router itself: no WinBox, no web interface, no DNS. That last one hurts most, because the generated client configuration points the client's DNS at the router's tunnel address.
With IKEv2 or L2TP: the policy does not cover your LAN
There the client decides what may go through the tunnel. Check /ip ipsec policy print for a dynamic entry with your LAN on the destination side, and /ip ipsec active-peers print for an active session.
What the configurator does about it
In the WireGuard section you create an interface with a tunnel address, a UDP port, the Tunnel counts as LAN toggle (on by default) and the peers. For a road-warrior peer the tool generates the key pair and writes a complete client configuration as an extra file next to the script, including Endpoint, DNS and AllowedIPs.
That Tunnel counts as LAN toggle does exactly one thing: it makes the WireGuard interface a member of the LAN interface list. That is what gives you access to the router itself. Traffic to devices behind the router passes without it too, because the closing drop in the forward chain looks at the WAN list, not at the LAN list. Worth knowing when you are wondering why it half works.
The firewall automatically gets a rule that lets in the UDP port of every WireGuard interface. The VLAN matrix breaks nothing here: those rules all carry in-interface set to a VLAN, so they never match traffic arriving from a tunnel. An isolated guest VLAN is therefore reachable from the VPN, whether you wanted that or not.
What the tool does not do: put the VLAN subnets in AllowedIPs, NAT the VPN traffic into the LAN, push routes to an IKEv2 client beyond the mode-config, check whether your LAN range clashes with whatever network the client happens to be on, or touch anything on the client itself. Those last two together account for most cases.
When it is not your router
The cafe wifi, the mobile network or the guest network your client sits on can block UDP or reuse subnets. The VPN app on the phone keeps its own route list. And the device you are trying to reach has a firewall of its own that you cannot see from the router.
Read on: WireGuard, Remote access VPN and Planning addresses.