Incorrect behavior of "exclude private IPs" in Android app

[Radon Rosborough]

Hello,

My understanding is that this mailing list serves as the issue tracker for Wireguard, based on my reading of https://www.wireguard.com/#about-the-project. Please redirect me to the appropriate destination if I'm in the wrong place.

The Wireguard Android app allows for the setting of an "Allowed IPs" list, which allows for tunneling only traffic destined to a subset of destinations. Since excluding local/private IPs from tunneling is a common use case for this, there is a built-in checkbox in the Android app for excluding private IPs. The checkbox populates a default list of CIDR ranges to exclude.

However, as far as I can tell, the value used by this checkbox is incorrect. It does not exclude the 127.0.0.0/8 address range, even though this is almost certainly not intended to be tunneled by a user. For example, consider a case where the user has forwarded the Wireguard port from a peer to Android over USB. Then the Wireguard Android app must be configured with a peer address of 127.0.0.1:51820. With the default checkbox settings, Wireguard will attempt to tunnel 127.0.0.1 to itself, and block all traffic, including DNS resolution.

The "Exclude private IPs" option was implemented in the Android app originally in https://lists.zx2c4.com/pipermail/wireguard/2018-July/003106.html, where the current list was proposed.

I found a website https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/ which allows for the calculation of correct "Allowed IPs" settings. It also provides a suggested default value for the "Allowed IPs" option.

Here is what is currently in the app:
0.0.0.0/5, 8.0.0.0/7, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6, 172.0.0.0/12, 172.32.0.0/11, 172.64.0.0/10, 172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, /32

Here is the proposed alternative:
1.0.0.0/8, 2.0.0.0/7, 4.0.0.0/6, 8.0.0.0/7, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/3, 96.0.0.0/4, 112.0.0.0/5, 120.0.0.0/6, 124.0.0.0/7, 126.0.0.0/8, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/8, 169.0.0.0/9, 169.128.0.0/10, 169.192.0.0/11, 169.224.0.0/12, 169.240.0.0/13, 169.248.0.0/14, 169.252.0.0/15, 169.255.0.0/16, 170.0.0.0/7, 172.0.0.0/12, 172.32.0.0/11, 172.64.0.0/10, 172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/4, ::/1, 8000::/2, c000::/3, e000::/4, f000::/5, f800::/6, fe00::/9, fec0::/10, ff00::/8

What do you think? Is this an appropriate change to make, so that users have a higher likelihood of the "Exclude private IPs" option doing what they expect?

Thank you,
Radon Rosborough

PS. I am not subscribed to the development mailing list; so I would like to be copied on replies.