pjhtech ToolsA WireGuard handshake can work while the remote LAN is absent from allowed-address, has no route through WireGuard, or is blocked by forward. Use the matching correction below; a handshake alone does not configure LAN access.
Scope: RouterOS WireGuard, routed IPv4 LANs with a recent handshake.
Keep the test source consistent
Example: A client 192.0.2.10/24 uses gateway 192.0.2.1; B server 198.51.100.20/24 uses gateway 198.51.100.1. Each gateway is the local RouterOS router. Both routers already have a working WireGuard interface named wg-site, with tunnel addresses 10.77.0.1/30 on A and 10.77.0.2/30 on B. The existing peer is named site-b on A and site-a on B (peer names require RouterOS 7.15+); substitute your names. A router-originated ping may use the tunnel address; it does not test the client’s source prefix or forward policy.
/interface/wireguard/peers/print proplist=name,interface,allowed-address,current-endpoint-address,current-endpoint-port,last-handshake,rx,tx
/ip/address/print where interface=wg-site
/ip/route/print detail where dst-address=198.51.100.0/24
/ip/firewall/filter/print detail where chain=forward
/ip/firewall/filter/print stats where chain=forwardCheck the main-table route in both directions
The peer entry does not replace an IP route. For the ordinary main-table setup, A needs an active route covering B’s LAN through wg-site. On B, run /ip/route/print detail where dst-address=192.0.2.0/24 to inspect the return prefix.
The exact /24 filters show only entries for those prefixes. An empty exact search does not prove that the route is missing. Run /ip/route/print detail and look for an active covering route in main. A summary may already carry the traffic; check that a more-specific route does not send the test destination through another gateway. Add a route only after confirming that no suitable route covers the destination.
The route examples below assume both LAN flows use main, as in the site-to-site configuration.
LAN prefix missing from the peer: update allowed-address
Read the peers with the first command above. If the opposite LAN is missing, update that peer. These examples include the opposite LAN and tunnel address. set allowed-address= replaces the full list: retain every existing required prefix, and avoid overlapping prefixes on peers of the same interface.
/interface/wireguard/peers/set [find where name="site-b"] allowed-address=198.51.100.0/24,10.77.0.2/32/interface/wireguard/peers/set [find where name="site-a"] allowed-address=192.0.2.0/24,10.77.0.1/32No route covers the remote LAN
Use these additions only when no active route covers the remote LAN. An empty exact /24 search can still have a valid covering route. If an existing static route uses the wrong gateway, correct its verified ID with /ip/route/set <route-id> gateway=wg-site. These examples use the main table.
/ip/route/add dst-address=198.51.100.0/24 gateway=wg-site/ip/route/add dst-address=192.0.2.0/24 gateway=wg-siteThe forward rule drops the client connection
If filter counters show the test is dropped, permit the required service before that drop. For this example, only A client 192.0.2.10 may initiate HTTPS to B server 198.51.100.20. Both routers must already accept established,related replies before their forward drop. Replace each drop placeholder with the corresponding rule number from that router’s fresh print detail; retain invalid-state handling and deliberate security rules above the permit.
/ip/firewall/filter/add chain=forward action=accept out-interface=wg-site src-address=192.0.2.10 dst-address=198.51.100.20 protocol=tcp dst-port=443 connection-state=new place-before=<A-forward-drop-id> comment="A client to B HTTPS"/ip/firewall/filter/add chain=forward action=accept in-interface=wg-site src-address=192.0.2.10 dst-address=198.51.100.20 protocol=tcp dst-port=443 connection-state=new place-before=<B-forward-drop-id> comment="A client to B HTTPS"Reconnect to HTTPS from the A client and compare both routers’ counters. If the server receives the request without replying, check the server itself.
On Linux, ss -lnt should show TCP 443 listening on 198.51.100.20 or a wildcard, and ip route get 192.0.2.10 should select gateway 198.51.100.1. A listener bound only to 127.0.0.1 is unreachable from the tunnel. If both checks pass, investigate host filtering or the application. Broad masquerade can conceal a missing return route and change the source seen by B’s policy.
Retest the actual client application and a previously working subnet. If reverting an allowed-address edit, restore the complete old list, not just the last prefix added.
If the client uses policy routing
Read /routing/rule/print detail and compare src-address, dst-address and table with the client flow. Read /ip/firewall/mangle/print detail and /ip/firewall/mangle/print stats for matching mark-routing rules and counter changes during the test.
If a rule or routing mark sends this flow to another table, check that table’s active route and any lookup fallback. A working main-table route alone is insufficient when the flow must use a different table. Resolve the table selection before applying the main-table route examples.