This will be a minefield (or at least that's how it feels to me while writing it down)
I have a site-to-site Wireguard VPN set up between 4 sites.
All sites are running OpenWrt with Wireguard installed.
Site A and Site B has public IPv4 addresses, site C and D have CGNAT addresses only. (the latter two are set to initiate the connections by default)
Site A is connected to Site B, C, D
Site B is connected to Site A, C, D
Site C is connected to Site A & B only
Site D is connected to Site A & B only
From my computer (Site A lan) I can ping all the local Wireguard interface addresses but not the remote WG interface IPs (except Site B's remote WG interface). From the LAN (site A) I can not ping the remote subnet or remote WG Interface IPs of site C and D.
However if I log into the router of Site A I can reach all remote WG IPs and subnets just fine.
The situation is the same on Site B, as in I can reach/ping the Site A lan and the local Wireguard IP addresses from the LAN but not the remote Wireguard IPs or subnets of Site C and Site D.
SSHing into any of the 4 router allows me to ping the remote subnet of the connected sites and the remote WG Interface IPs.
I do not have a local device to test for access from the lan on Site C and Site D, so I don't know whether the situation is the same there at this very moment.
I have tried adding the Interfaces to a separate Firewall zone (called it VPN) and made the appropriate Firewall zone forwarding.
First you need to have all the LANs be different IP subnets so that ordinary destination-based routing can work properly.
If you can ping C or D from the A router but not a machine on A's LAN, that probably means C and D don't have a route to A's LAN or A's LAN is not in their allowed_ips.
There are three things that need to all be correctly configured to allow tunneling lan-lan:
Kernel routes
wireguard allowed_ips
firewall rules
Having a "forward" in the firewall only allows such forwarding after the kernel routing table(s) direct it and Wireguard permits it. The firewall alone does not cause a forward to happen, it can only block stuff that otherwise would happen.
The subnets are non-overlapping /24 subnets, the Wireguard IPs are all in their separate /31 network
The Allowed IPs are set in the Peer setting (Wireguard interface subnet + remote lan subnet) for all WG interfaces
all connected lan IPs of all sites are reachable from the routers... but not from the lan.
Routes are automatically set up with the Wireguard's "Route allowed IPs" box ticked, firewall zone forwarding is set up.
(just trying to clarify all the points you raised.)
Managed to find the solution and it was somewhat unexpected...
Not sure yet if it was down to me using a /31 networks for the tunnels or this is by design and I have missed it...
Since I use the /31 IP subnet I assigned x.x.x.0/31 for Site A and x.x.x.1/31 for the other site.
When configuring the Allowed Peer IP address I have to configure the IP subner with the remote IP's address... meaning on site A with interface IP being x.x.x.0 the Allowed Peer IP has to be the exact remote address IP with /31 so it must be x.x.x.1/31 (despite that the /31 denotes a whole /31 subnet which happens to have only 2 IPs in it unlike a /24 where there are 255…)
so after reconfiguring all the interfaces with this in mind I have a fully functioning setup.
