A site to site tunnel works one way

Two locations, one tunnel. From head office you can reach the server at the branch. From the branch you reach nothing at head office. Or it does work, but only after somebody at the other end did something, and after ten minutes of silence it is gone again.

A tunnel is symmetrical; traffic over it is not. One missing route, one list of allowed addresses that is too short, or one rule that stops new traffic, and you get exactly this picture. If nothing passes in either direction, read The VPN connects but nothing passes.

The quick checks, in this order

1. Compare both ends. Run every check below on both routers and lay the answers side by side. The end where something is missing is the broken one, and it is usually not the end you are sitting at.
2. Does the peer know the other network? /interface wireguard peers print detail. A good answer: allowed-address holds both the peer's tunnel address and the network behind it. If that network is missing at one end, WireGuard throws the traffic away there.
3. Does the route exist? /ip route print. A good answer: a route to the other side's network at both ends, with the tunnel interface as gateway, and active.
4. Test with the right source address. /ping 192.168.2.10 src-address=192.168.1.1. Without src-address the router uses its own tunnel address, and then you are testing something other than what your users do.
5. Is anything being dropped? /ip firewall filter print stats on the side where the traffic arrives, while you ping from the other side. A good answer: no drop rule with a counter moving along.
6. Does the tunnel stay awake? /interface wireguard peers print and look at last-handshake. If it only goes fresh when you start, the tunnel falls asleep and keepalive is the answer.

The usual causes

• The networks behind the peer are filled in at one end only. By far the most common. The peer needs both the tunnel address and every network behind it, at both ends. The tool writes the matching routes alongside.
• No keepalive on the side behind NAT. If one location sits behind a modem that does NAT, only regular traffic keeps the hole open. Without keepalive the tunnel works only after that side sends something, and dies again afterwards.
• The same address range at both ends. If home and office are both 192.168.1.0/24, the routes clash and each router picks its own network. This often looks like "one side works", because that side happens to have less overlap.
• An isolated VLAN at one end. Isolation drops new traffic that is not heading for WAN. Traffic from that VLAN towards the tunnel therefore never leaves, while traffic from the other side into that VLAN arrives fine. Exactly one direction.
• The device's own firewall. A server that trusts its own subnet only answers a connection it set up itself and refuses a new one from outside.
• "Management VLAN only" at one end. You then cannot ping that router any more while traffic through it works normally.

What the configurator does about it

Clashing address ranges are caught. Draw a routed tunnel between two routers on the network board where both sides use the same network and the tool names it: the routes over the tunnel clash. Put the routers in locations with their own address range. The same goes for two locations with their own router that end up on the same subnets, even without a tunnel: they cannot talk over a VPN later.

For a site to site peer the tool fills in the allowed addresses and the routes together: the peer's tunnel address, plus every network you enter under Networks behind the peer, and one route per network via the tunnel interface. Leave that field empty at one end and that is the end that cannot reach the other.

A tunnel to a device that does not route produces a warning: a routed tunnel achieves nothing there. BGP on without an AS number is an error. And for the tunnel types that do not accept a name as their destination, the tool says an IP address belongs there.

What the tool does not check: whether keepalive is frequent enough for the NAT at the other end, and whether a server's firewall inside trusts the other subnet. The Keepalive field is 25 seconds per peer by default, which is enough for nearly any NAT.

When it is not your router

• The modem at the other end. A location behind double NAT can call out and not be called. Turn keepalive on there and let that side set the tunnel up.
• A customer firewall in between. Somebody else's office sometimes has a box you do not manage.
• The server itself. Test the router on the far side first, then the device behind it.

Further reading: Site to site tunnels, Several devices in one site and Example: two locations.