Kernaali ToolsA recent handshake proves that the peers exchanged authenticated tunnel messages. It does not prove that a client subnet has a route, is accepted by allowed-address, or can pass the forwarding policy. Follow one client-to-server flow in both directions before adjusting MTU.
Applies to: RouterOS 7 WireGuard, routed IPv4 site-to-site with separate LAN prefixes and a working recent handshake. The current peer reference is used; no platform-specific bug fix is asserted. A tunnel with no handshake needs endpoint, UDP reachability and key checks first.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Choose a flow and distinguish router-originated traffic
Synthetic topology: site A client 192.0.2.10/24 uses router A; site B server 198.51.100.20/24 uses router B. The WireGuard interfaces use 10.77.0.1/30 and 10.77.0.2/30. Test the intended server application, for example TCP 443, from the actual site A client.
A ping from router A can select its tunnel address and tests local output, not the client forward chain. A ping to router B also tests its input chain rather than forwarding to the server. Record the real source address for each result; do not treat these as equivalent tests.
Check the peer and route independently
/interface/wireguard/peers/print proplist=interface,allowed-address,current-endpoint-address,current-endpoint-port,last-handshake,rx,tx
/ip/route/print detail where dst-address=198.51.100.0/24
/ip/firewall/filter/print stats where chain=forwardThe peer on A must permit site B source prefixes and select that peer for outgoing destinations. B must permit site A sources. Include the tunnel addresses only when they are part of the intended router-to-router tests. Peers on the same WireGuard interface cannot have overlapping allowed-address ranges. Peer parameter reference explains that allowed-address serves both received-source validation and outgoing peer selection.
A matching allowed-address is not a substitute for the IP route to the remote LAN. Inspect the active route and next hop on each router; the official site-to-site example configures routes separately. A more-specific local route or a routing rule may change the actual lookup.
Read counters as a branch, not as a verdict
| During the same test | Follow this branch |
|---|---|
| No useful increase in A tunnel transmit traffic | Check client gateway, route selection and A forward policy |
| A transmits, B receives, server sees no request | Check B allowed sources, forward policy and route to the server |
| Server receives the request but the client sees no response | Check server firewall/service, default gateway, B route and A allowed sources |
| Small requests work; large transfers stall | Now investigate path MTU, ICMP errors and MSS with controlled packet sizes |
Counter changes may include other peer traffic. Keep the test narrow and correlate both ends. Do not publish peer identities, keys or complete exports as evidence.
Make the correction indicated by the failed hop
Add the one missing remote prefix to the appropriate peer only after checking it does not overlap another peer. Correct the specific route or add a source/destination/service-scoped forward permit at the intended point in the policy. Keep input permission separate if a router service is actually required. Do not add broad input accepts or masquerade every tunnel flow to hide a missing return route.
Changing allowed-address can remove working prefixes if you replace the list carelessly. Record the complete old list and affected rule or route before editing, retain an independent management path, and restore those exact values if the bounded test fails.
Verify both the new flow and the existing networks
Success means the real client completes the remote application transaction and receives replies with the expected source and route. Repeat from an existing working subnet and check that a disallowed client remains blocked. A fresh handshake by itself is not completion. Stop any temporary capture and remove only temporary test rules.
Input and forward chains · MSS calculation when packet-size evidence supports it · Compare the intended prefix lists
Technical references
Found an issue? Send a correction with a reproducible example.