The tunnel is being built, I can ping 100.64.0.1 from router 2 and vice versa.
But the client in router 1 can not ping 10.0.1.1 or any other client on router 2 and vice versa.
What routes do I need to set up? I already put the corresponding 10.0.x.x IPs on wireguards allowed IPs and activated masquerade. I made a static unicast route from 10.0.0.0/24 to 10.0.1.1, but also no success.
Hmm, OK -- I am assuming a routed tunnel is OK and that you don't need to deal with a unified broadcast domain. At least last I knew, Wireguard didn't support Layer 2 tunnels.
Thinking through the routing, first with the routers "up" and no Wireguard (pidgin route notation)
Router 1
default via 192.168.80.1 dev WAN
192.168.80.0/24 dev WAN
10.0.0.0/24 dev LAN
Router 2
default via 192.168.0.1 dev WAN
192.168.0.0/24 dev WAN
10.0.1.0/24 dev LAN
Hosts on either of the two LANs route via their router and each router has a default route.
Enable Wireguard link
Router 1
default via 192.168.80.1 dev WAN
192.168.80.0/24 dev WAN
10.0.0.0/24 dev LAN
100.64.0.2 dev wg0
Router 2
default via 192.168.0.1 dev WAN
192.168.0.0/24 dev WAN
10.0.1.0/24 dev LAN
100.64.0.1 dev wg0
Routers can ping each other's tunnel-portal.
Incoming packets destined for the other's LAN still being routed over default gateway
Add static routes for other's LAN
Router 1
default via 192.168.80.1 dev WAN
192.168.80.0/24 dev WAN
10.0.0.0/24 dev LAN
100.64.0.2 dev wg0
10.0.1.0/24 via 100.64.0.2 dev wg0
Router 2
default via 192.168.0.1 dev WAN
192.168.0.0/24 dev WAN
10.0.1.0/24 dev LAN
100.64.0.1 dev wg0
10.0.0.0/24 via 100.64.0.1 dev wg0
Now each router "knows" about the "hidden" subnet behind the other.
Edit: These static routes will cause the other LAN to be "unreachable" if the Wireguard link is down, rather than trying to route them through the local router's default gateway. For many applications, this is desirable behavior.
Masquerade seams unnecessary if you are able to configure allowedips on both sides. But you need to enable "Route Allowed IPs" or add static routes manually.
You also need to allow the traffic in the firewall. By adding the wireguard interface to the LAN zone or add a new vpn zone and allow forwarding between lan and VPN, or allow specific protocols and/or ports.
From the limited Wireguard/netmask knowledge I have, you should be using this:
Define a 10.0.x.x subnet for the Wireguard interfaces (e.g. 10.0.10.1)
Set 10.0.0.0/16 as allowed_ips on the peer? So you can ping both 10.0.10.x and 10.0.0.x
If you stick with 100.64.0.x as Wireguard interfaces, you would basically need to open up all available subnets for routing, since 100.x.x.x and 10.64.x.x don't even fit in the same /24 subnet (and typically a LAN subnet for home use is defined as IPv4 /24).
Sure, you can got calculating what subnets would be allowed to squeeze in 100.64.x.x and 10.0.1.x together, but it's way too wide to be anything of a security measure. Keep in mind the IP ranges that have been defined for private (home/corporate) use and use those. 100.x.x.x is definitely not one of those.
Seconded, 100.64.x.x is not a valid subnet for private use. Change those to 10.64.x.x. However:
there's no need to calculate a single netmask that spans both the network and WireGuard's internal IPs, allowed_ips can take multiple entries. I would suggest
On Router 1: 10.0.1.0/24 and 10.64.0.2
On Router 2: 10.0.0.0/24 and 10.64.0.1
Also I seem to remember that 10.0.1.1/24, although notated perfectly fine, would not be picked up by WireGuard, you'd have to use 10.0.1.0/24. I don't know if this is still the case, but I remember it tripped me up for a minute.