agausmann
commented
1 month ago This is not an important feature for me right now, but the problem of android and vanilla connections has been in the back of my mind for a while, and I had this idea that I wanted to share.
If other people show some interest, then I wouldn't mind helping out. In the meantime, I may put together a repo with some scripts/configs for a relay server based on NAT.
Motivating example: I have an external network, and I want to make the external network and the innernet network fully routable between each other.
The idea I have is to use one innernet peer as a relay/router that forwards traffic between the two networks. I can set up the routes on my external network just fine, but the innernet peers also need to be configured to send traffic for the other network to the relay peer.
(For simplicity, let's assume the external network is on a separate subnet, not a part of the innernet subnet, and the only machine that is a member of both networks is the relay.)
To implement this, the additional addresses for the peer could be registered in the innernet server database, and then distributed to the other peers as "additional routes" of the relay peer. The innernet clients can add those addresses to the "Allowed IPs" list of the relay peer and add the corresponding routes in the OS network interface.
This is related to #2, #3, and a little bit of #210. If that external network I described before is a "vanilla Wireguard" network, managed separate from innernet, then this can give vanilla Wireguard clients (including Android) access to the innernet network. By using a relay server, the vanilla configuration stays simple and static, and doesn't require manual work or a daemon to maintain the full list of peers and do the whole NAT traversal dance. Most of the configuration is done once on the relay server.
Other alternatives: It is probably possible to use NAT on the relay, so all the traffic on the innernet side goes through the relay's primary innernet address. That has the usual drawbacks of NAT: only the external network can establish a connection to the innernet network, and not vice versa (besides port forwarding).