Re: Nested Wireguard tunnels not working on Android and Windows

[Frank Carmickle <frank@carmickle.com>]

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 <iiordanov@gmail.com> 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.