Nested Wireguard tunnels not working on Android and Windows

[i iordanov <iiordanov@gmail.com>]

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.