I eventually replaced my Unifi router with a Mikrotik device which has a lot more capability, even if it does mean having to do more work yourself. Part of that capability is a builtin wireguard server, rather than it needing to be a separate box on the network. This is great because it simplifies routing a lot.

Original research notes are on a subpage: /ResearchOnAppliances

The new router is servers/helian

Adding a new client

This assumes you're using a frontend app for your OS, and not faffing around with manual config files in /etc/wireguard/wg0.conf

Create a new tunnel config, which should generate a fresh private/public keypair for your client. Then the config for new peers is roughly as follows:

[Interface]
PrivateKey = <WHATEVER THE CLIENT GENERATED ITSELF>
# this address matches the normal at-home IP address allocation, with the third octet changed to a .2
Address = 192.168.2.x/32
# this can be the pihole, which'd be 192.168.1.26 instead
DNS = 192.168.2.1

[Peer]
PublicKey = WZXMo7jqXcHWhVW+OxwLcahjB/ksSURC8PRGLjEfCCo=
PresharedKey = <GENERATE A NEW ONE ON THE SERVER FOR EACH CLIENT, AND COPY IT HERE>
# this is a non-split tunnel
AllowedIPs = 0.0.0.0/0
Endpoint = vpn.thighhighs.top:8443
PersistentKeepalive = 61

Grab the client's public key, copy it to the router and add the client as a new peer.

The command in RouterOS will be something like this:

/interface/wireguard/peers/add interface=AreaS09 public-key="XXX=" allowed-address=192.168.2.XX/32 preshared-key="XXX=" persistent-keepalive=1m1s comment="the-hostname"

Network layout

This is much simpler than the setup I had last time, and not really any less convenient. I had the server running on asval with clients getting IP addresses in the same /24 as the rest of the LAN, but technically residing in a /27 subnet near the top of it. Clients would be sending all packets to asval anyway, which would diligently forward them to other hosts on the LAN as required, the destinations just happened to be on a super-subnet of the VPN clients. Return traffic was assumed to be in the same segment, so asval has to proxy-arp for the VPN clients, receive the traffic, then forward it down the tunnel to the "directly connected" remote peers.

Now all the clients just live in the 192.168.2.0/24 subnet and helian routes their traffic, no NAT or other trickery needed. Any client in the usual LAN range can have a matching IP in the VPN range, just change the 3rd octet.