Jason, that sounds like an amazing feature, but would it be possible with the current Go/Android VPN implementation? In my (limited) experience, entering 2 or more comma-separated IP ranges does not work. I get "Error bringing up tunnel: Bad Address" if I try to set Allowed IP's to "10.5.0.1/24,192.168.1.0/13" but it works with "0.0.0.0/0". The Android VPN subsystem only seems to allow a single subnet in that parameter. I'm running Wireguard for Android v0.0.20180625. ________________________________ From: WireGuard on behalf of Jason A. Donenfeld Sent: Thursday, July 5, 2018 10:46 AM To: Eric Kuck Cc: WireGuard mailing list Subject: "Exclude Private IPs" in Android App Hey Eric, While you're iterating on the "Excluded Applications" feature, what would you think of also taking a stab at the "Exclude Private IPs" feature? It's kind of in the same ballpark and works over the same code you're currently playing with. First some background: Some people don't want packets intended for their local network to go through a tunnel. On desktop linux's wg-quick(8), this is the default with some very clever use of ip-rule(8)'s suppress_prefixlength parameter. It works perfectly 100% of the time, without any need for heuristics. I've written to the folks I know working on Android's networking stack to allow for the same kind of clever thing, but if that happens, it'd of course be quite a ways off. So in the meantime, rather than introducing a switch called "exclude local networks", which would have all sorts of races with detecting local networks and making decisions about network types and such, plus the need to toggle VpnService in a racy way, etc, I have a much cleaner idea: "Exclude Private IPs". "Exclude Private IPs" works in the most dumb and straightforward way possible, that is guaranteed to not fail. We add a checkbox underneath "AllowedIPs". The checkbox is visible if "0.0.0.0/0" or ${MAGICRANGE} is included in the AllowedIPs; otherwise it is hidden. When the checkbox is checked, it replaces 0.0.0.0/0 with ${MAGICRANGE}. When the checkbox is unchecked, it replaces (after sorting) ${MAGICRANGE} with "0.0.0.0/0". ${MAGICRANGE} is defined to be 0.0.0.0/0 modulo RFC1918: "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" I think this approach will be simple and consistent, and implementing this as a static modification of AllowedIPs rather than runtime set subtraction makes it more obvious what's going on. What do you think of that idea? Jason _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.zx2c4.com%2Fmailman%2Flistinfo%2Fwireguard&data=02%7C01%7C%7Cf70032b86fee46134b9c08d5e29f5941%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636664096373456109&sdata=OuSYdUZQEB1%2BZ4Wf9%2FEv%2BeHLgTFWIjwMCk1xXJOzOWg%3D&reserved=0