Right, so other than their respective WAN ports being connected to the same larger network, there is no direct connection between routers A & B? They are, for all intents and purposes, two separate LANs?
And the intended purpose of the tunnel is to allow clients (only wireless?) on router A to access clients on router B and the internet through router B's WAN connection? Anything else?
That assumes router A is using 192.168.1.0/24 for LAN connectivity. Router B should use a different subnet.
The wg interface can be added to the LAN zone on each router assuming all connected clients are trusted and (in real world usage) there is an appropriately configured firewall on the device responsible for passing internet traffic. If either of those was not the case then you would add the wg interface to the WAN zone or add it to a separate firewall zone and add appropriate forwarding rules.
Do you want to try amending your setup to match the above and check the tunnel is working as intended? If the transfer issue still persists then we can begin looking at other areas.
Nope, the packets will have a destination address for a machine on the other side of the tunnel, i.e. 192.168.1.x/32, so that will match the allowed IPs of 192.168.1.0/24 and be allowed into the tunnel.
I've gotten it going, though I had to add back a forwarding from LAN to WAN (which I had deleted in my original config) in order to make it work. Initial testing shows that the internet upload is now significantly closer to no-wireguard. I can also do "large" transfers over SSH without that breaking. I will test further.
One thing I notice is that even though Router A and B are pretty much identically configured, with exception of their LAN subnets, the automatically generated routing information is quite different. Router A sets the default route to wg0 but Router B does not. Odd!
root@WG_1e8b:~# ip route
default via 192.168.8.1 dev eth0.2 proto static src 192.168.8.252
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev wg0 proto static scope link
192.168.8.0/24 dev eth0.2 proto kernel scope link src 192.168.8.252
192.168.219.0/24 dev wg0 proto static scope link
root@WG_264e:~# ip route # this is router A with WiFI LAN
default dev wg0 proto static scope link
192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.1
192.168.8.0/24 dev eth0.2 proto kernel scope link src 192.168.8.251
192.168.219.0/24 dev wg0 proto kernel scope link src 192.168.219.1
Also, any thoughts about why my previous approach (of putting wg into it's own firewall zone) was failing? Why does putting WG into the LAN zone help?
As vgaetera says, this is all due to the options within the respective peers. As they both have route_allowed_IPs set to 1 then WG will create appropriate routing rules based on the content of allowed_ips.
On router A you have allowed_ips set to 0.0.0.0/0 so you are telling WG that you want all traffic to go through the tunnel, which is why it sets the default route to wg0.
On router B you have allowed_ips set to 192.168.1.0/24 so you are telling WG you only want traffic destined for that subnet to go through the tunnel. WG therefore only creates a routing rule for that subnet.
It may be that changing the WG/peer configs is what has solved the issue, rather than moving WG into the LAN zone. The reason I recommended it was to remove as many variables as possible to begin troubleshooting. Having WG in another zone shouldn't, in itself, cause the issues you saw.
If, for your specific setup, you need the WG interface in it's own zone then I'd start by doing that on one of your current test routers. Put the interface in a new zone and set up forwardings to/from the LAN and WAN zone. See if that has any impact. If not, then try it on the other router as well. If that also has no impact then you can begin looking at finetuning rules/forwardings etc.
I'd still love to know where the wg routing is set up. I may be going in the wrong direction, but I am happy to learn from what is being done well already!
My goal is to have two routers, call them H and W, in different locations. When I connect to H, I have access to devices on the LAN of W as well as the internet from W. And symmetrically when I connect to W, I get access to the devices on the LAN of H as well as the internet from H.
Policy based routing will do this for me. I am also open to other alternatives if you want to propose them!
Hope that helps with your "nuts and bolts" question...that's not quite related to making things work.
I personally setup my routes and tables manually (in UCI syntax, of course ) wihtout the PBR package or checking "route allowed IPs" (especially necessary of some of your tunnels are different ad-hoc Internet VPNs, some traffic can't go to a streaming service, etc.).
This doesn't work if done on both ends. Since route_allowed_ips sets the route for 0.0.0.0/0 to go through the wg interface on both routers, the packets make it to the other router and then just head back through wg.
That is why I originally went with PBR.
I would also ideally like the router itself to be able to communicate directly with the internet, not via WG