I've had basically this exact setup running on a cloud server for the past few months. It's pretty liberating to be able to open ports to 10.44.0.0/24 and have

I've had basically this exact setup running on a cloud server for the past few months. It's pretty liberating to be able to open ports to 10.44.0.0/24 and have all of my different machines easily access them, regardless of what networks they're connected to. I've added in an instance of nsd that manages a zonefile so I can do: ssh laptop.wg.mydomain.net which resolves into 10.44.0.3 for example. There are two major downsides with this approach: (1) all of your traffic must go by way of the bounce server, even if your machines are on the same LAN. (2) the bounce host can observe all of your traffic. I've been considering adding a second layer of wireguard on top of this for end-to-end encryption between nodes. Each machine would have one interface configured like this article suggests simply to assign a stable NAT-traversing IP address. Then they'd each have a second interface using the first-level IP addresses as endpoints. This would result in 2x the encryption overhead, both in CPU and more importantly in MTU, but it would mean the bounce host was no longer able to intercept even unencrypted data. If you run a daemon on all of the hosts, they can play with the endpoints used on this second level network to avoid using the bounce host when they find they can directly connect to each other, but the default path would work (if somewhat slowly) by the double tunnel process even without this daemon. For bonus points, run multiple bounce hosts, connect to all of them from each peer, then select the endpoint to use for each paired peer connection based on the total path latency.