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
