I think that the entire peer should be removed rather than just the routes. You also probably want to make this change so that the init command does not object to None values in the Endpoint: mwt@ee325a3

I've been making my own fork over here for personal use: https://github.com/mwt/wg-meshconf/

It contains a modified version of @rudolfbyker's code which hides the entire peer when a direct connection is not possible.

It is worth noting that this config is only useful if you want all NATed peers to route through the same "lighthouse". If you want peers to route through their nearest lighthouse (e.g. peers in Singapore connect to each other through Singapore and peers in Germany connect to each other through Germany) then you need to have asymmetric AllowedIPs values. This setup does not work for that. Though, I think this is still useful.

Edit: To clarify, this will not maximize the speed of NAT -> NAT connections, but it will "just work" and I think it's a useful feature.

You should remove , "Endpoint" in line 101

Why? Sorry, it's been a long time since I made these changes, so the code is not fresh in my memory.

You should remove , "Endpoint" in line 101

Why? Sorry, it's been a long time since I made these changes, so the code is not fresh in my memory.

That part checks to make sure that endpoint is not None when you run the init command. The way it's written, it will throw an error if it detects any None value in that column.

Because this PR makes None a valid input, you do not want this behavior.

I rebased my branch on the latest master! Please review :)

@mwt wrote:

I think that the entire peer should be removed rather than just the routes.

Quite right, and I only realized this now. For anyone wondering why, see the docs at https://github.com/pirate/wireguard-docs#how-public-relay-servers-work .

I updated the PR.

In addition, we can mark one peer as relay (flag in config) and add subnets that are not directly accessible to it

In addition, we can mark one peer as relay (flag in config) and add subnets that are not directly accessible to it

Good idea for the next PR after we get this merged! :)

What prevents this from being merged? It's a valuable feature, and works properly.