I run a similar setup. I didn't end up going for a full router-side hub inside the LAN, to avoid extra hops for things when they're inside the network.
Some of my notes:
* I have multiple servers outside the LAN that have WG connections back to specific interior systems for things like metrics/log-shipping, monitoring, and backups. All of those are "point-to-point" (the cloud-hosted systems have multiple Peers for different internal systems). This means that they can only talk to the things I expect them to, w/o me needing to also handle that at the firewall level.
* The Wireguard Mac and iOS apps are very solid. I use them heavily on multiple devices, and they can be trained for OnDemand activation based on SSIDs. This means that when my phone tries to load my NVR dashboard, it uses Wireguard if I'm mobile and doesn't if I'm at home (which saves me a hop through the cloud hub). The iOS app is reliable enough that I set it up once on my partner's phone so they could access the cameras and then never had to think about it again.
* Because the only things you need to set up a peer link are shared pubkeys and to agree on IPs, wiring up my endpoints via Puppet was super smooth and adding/adjusting has likewise been smooth. My systems generate a keypair during setup, publish their public key where the other nodes can find it, and all I have to do is update the map of "hey, this server get this WG-internal IP, and this is who should link to it".
> it uses Wireguard if I'm mobile and doesn't if I'm at home (which saves me a hop through the cloud hub)
Appropriate netmasks in the routing tables do this regardless of physical interfaces. For example, if your local network has netmask 255.255.255.128, the local link is prioritised over the tunnel link which could have netmask 255.255.255.0, but you have to decide which nets/subnets are useful to you.
Not really? That would rely on my local devices sharing a subnet with my phone/laptop, and would also blow up in fun ways if I ever got on a hotel wifi that used similar subnets to my home network.
You should pick a random network (like in 10.x.x.x if ipv4) and a smaller mask for your VPN than any public wifi would ever choose. Then a yet smaller mask for your home network. The probability of collision then is tiny.
I don’t think you’re quite grokking the problem space here.
The goal is “I want my phone to always connect to a given hostname. When I’m on my home WiFi, that connection should be direct. When I’m not, that connection needs to bounce through the WireGuard tunnel”.
The target system isn’t even on the same subnet of my home LAN as my phone. So short of injecting custom routes, netmasks aren’t helping me at all. But even if they were, short of running split horizon DNS, I’d need my WireGuard subnet to be a superset of my home LAN, and for my home LAN to be a portion of that, and also my WireGuard subnet can’t conflict with whatever network I’m on. So I’ve now made a bunch of complex constraints and my home LAN is taking constraints from my remote access flow.
Or I just tell WireGuard to route the IP of the LAN-side system and to disable itself if I’m home.
I understand your goal. I've run this solution for more than a decade, originally with openvpn and multiple subnets.
Yes, it does require your local networks to be subnets of the VPN. If you can't control dhcp, then you can add static alias IPs to the local interfaces and thus have "another" local subnet for this purpose. In these cases, the wireguard link might need two addresses (AllowedIPs: 10.x.x.x/31) where one of them is configured on the local interface with the local subnet mask, the wireguard ip configured with the wider VPN mask.
Adding IP aliases doesn't seem to be possible on phones though ...