Android/GoBackend: Wrong Src IP

[Björn Fiedler]

Hi,

I'd like to report some kind of behavior from which I think it is a bug of the Android App with go backend.


The Scenario:
My android phone should participate in two private networks with distinct IP ranges, subnets and clients. As the android app is restricted to one interface at a time, the single config contains the settings for both private nets.

Server A:
[Interface]
Address = 10.14.0.221/24
ListenPort = 56345
PrivateKey = ...

[Peer]
AllowedIPs = 10.14.0.13
PublicKey = ...


Server B:
[Interface]
Address = 10.200.200.2/24
ListenPort = 37699
PrivateKey = ...

[Peer]
PublicKey = ...
AllowedIPs = 10.200.200.13/32



Android phone:
[Interface]
PrivateKey = ...
Address = 10.200.200.13/24
Address = 10.14.0.13/24
ListenPort = 6677


[Peer]
AllowedIPs = 10.200.200.0/24
Endpoint = server_a.example.com:56345
PublicKey = ...


[Peer]
AllowedIPs = 10.14.0.0/24
Endpoint = server_b.example.com:37699
PublicKey = ...



The Problem:
Issue a `ping 10.200.200.2` via termux works as expected.
Issue a `ping 10.14.0.221` via termux results in 100% packet loss.


The ip address assignment and routing tables of my phone seem to be as I would expect them
$ ip route
10.14.0.0/24 dev tun0 proto kernel scope link src 10.14.0.13
10.200.200.0/24 dev tun0 proto kernel scope link src 10.200.200.13
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.151

$ ip address  show tun0
42: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
     link/none
     inet 10.200.200.13/24 scope global tun0
        valid_lft forever preferred_lft forever
     inet 10.14.0.13/24 scope global tun0:1
        valid_lft forever preferred_lft forever
     inet6 fe80::ee0a:a411:b6b2:a911/64 scope link stable-privacy
        valid_lft forever preferred_lft forever


The kernel logs from server A shows the problem:
[309387.725202] wireguard: wg0: Packet has unallowed src IP (10.200.200.13) from peer 13 (192.168.2.151:6677)

It seems as if the wrong address is used as source addres by the android app or go backend. I've tested the same config on a linux machine using the wireguard-go userspace implementation but it worked correctly. Hence I would assume it is some kind of interworking problem of the android components.
Switching the two addresses in the interface section results in the same behaviour but inverted. It always uses the first address as source address.
The problem is not limited to ping but seems to affect all apps and protocols (tested http, ssh, ping).

App version:
WireGuard for Android v1.0.20210211
Go userspace backend v0.0.20201118
Installed via google play

Android 10 QKQ1.191215.002
Kernel 4.14.117-perf-ge9e6b4f


If you need more infos or my help for reproducing, let me know.

Thank you in advance,
Björn