Iordan, It's not totally clear to me how you are trying to achieve this, however I'm pretty certain that you want to be creating a second interface that routes the traffic to the endpoint reachable inside the other tunnel,
You say that it's possible to run a nested configuration on Linux and Macos with just a single interface each,. Have you done a packet capture to prove that that is in fact what is happening? That doesn't seem like how it would act given the design goals. --FC On Feb 25, 2021, at 12:48 PM, i iordanov <[email protected]> wrote: > > Hello! > > In order to allow traffic to assist devices that cannot reach each > other directly, I am setting up wireguard tunnels through a server > with a public IP (40.30.40.30 in the example below). > > For reasons of privacy, I'd like for the server to not be able to > decrypt my traffic. As a result, I would like for one encapsulating > Wireguard tunnel (subnet 10.1.2.0/24) to be peered through the server, > while a second nested Wireguard tunnel (subnet 10.1.3.0/24) to be > established through the first tunnel, peered only at the two devices > (Android and Linux in this case) that need to communicate. > > An attempt was made to use a single Wireguard interface. Doing it this > way works between two Linux machines and even between Linux and Mac OS > X, but does not work between a Pixel 3a XL running Android 11 with the > GoBackend Wireguard implementation and my Linux laptop. I also tried > the same config on Windows 10 to no avail. > > The config on the Android device, obtained with toWgQuickString(): > ====================================== > [Interface] > Address = 10.1.2.5/24, 10.1.3.5/24 > ListenPort = 46847 > MTU = 1200 > PrivateKey = PRIVATE_KEY > > [Peer] > AllowedIPs = 10.1.2.0/24 > Endpoint = 40.30.40.30:10000 > PersistentKeepalive = 3600 > PublicKey = VF5dic+a+6MllssbV+ShVwEBRrX9gr4do2iNylWrPGs= > > [Peer] > AllowedIPs = 10.1.3.1/32 > Endpoint = 10.1.2.1:51555 > PersistentKeepalive = 3600 > PublicKey = 0Awdb451Z4+3Gezm7UlbRquC1kcF52r68J9wG1x/zUE= > ====================================== > > The 10.1.2.0/24 subnet is the one that is "visible" to the public > server. The 10.1.3.0/24 subnet is the one that is private to the two > devices. > > The devices can actually reach each other with netcat over UDP at > 10.1.2.5:46847 and 10.1.2.1:51555 respectively. So the "encapsulating" > tunnel is working, and iperf3 were used to test it over UDP and TCP > successfully. > > The "nested" tunnel does not get established. > > The following permutations of the above config have the commented problems: > > # Only 10.1.2.0/24 works, 10.1.3.0/24 does not. > Address = 10.1.2.1/24, 10.1.3.1/24 > > # Only 10.1.2.0/24 works, 10.1.3.0/24 (as expected) does not. > Address = 10.1.2.1/24 > > # Neither network works > Address = 10.1.3.1/24, 10.1.2.1/24 > > This looks like a bug that is triggered when multiple addresses are > assigned to the interface. > > Any suggestions on what to try are welcome. > > Thanks! > iordan > > > -- > The conscious mind has only one thread of execution.
