Exclude private IPs from Wireguard profile

[ViRb3]

From Wireguard Android 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, ::/0, 193.138.218.74/32

[ghost]

Hi, not sure if this works for you on Windows or with wg-quick, but when I import the file to NetworkManager it doesn't work at all.

When I revert your changes so that AllowedIPs gives 0.0.0.0/0, ::/0 it works properly. I think it's worth reconsidering these changes or finding an alternative to what you want to accomplish.

[ghost]

Also ::/0 would include private IPv6 addresses (fd00::/8). You probably want to use 2000::/3 instead (which is the internet block).

[ViRb3]

Thanks for reporting! I will take a look later today when I have access to a Linux machine.

[ViRb3]

I can confirm the issue on Ubuntu 20.04. I found a discussion of the same problem here:
https://www.reddit.com/r/WireGuard/comments/auuvn5/problem_excluding_private_networks_in_allowedips/

Essentially, AllowedIPs 0.0.0.0/0 is handled by WireGuard in a special way so that it excludes the server's public IP. With the public IP ranges I added in this commit, the server's public IP falls under one of those custom ranges, which is not handled in the same special way by WireGuard, resulting in no connection. Strangely enough the official Windows and Android clients seems to handle this properly. Either way, I'll patch the AllowedIPs generation so it specifically excludes the server's public IP.

[ViRb3]

Unfortunately, it seems like there is no good way to do this via the AllowedIPs config - in the worst case, 254 + 24 routes will have to be added, which we definitely don't want. I could add Linux-specific PostUp commands, but that will cause more issues than the amount of problems it will fix. So unless anybody has a clever idea, I will revert the commit for now.

[felipejfc]

did you get warp working on linux? I can't make internet work with the configs generated, the moment I do wg-quick up I lose connectivity

[jthomaschewski]

@felipejfc I do have the same issue

Update: Using network manager with nmcli connection import type wireguard file ./wgcf-profile.conf works for me and seems to be reliable.
wg-quick up ./wgcf-profile.conf randomly works as well, but still results in loss of connectivity most times. I wasn't able to detect a pattern.

Both tried with unmodified generated config. So I'm not sure if this issue is related to AllowedIPs setting.

[zadrakar]

@felipejfc , @jthomaschewski Don't you use some ubuntu (like) distribution? I have the same reliability problem in Linux Mint. In all other cases, wgcf always works. I've seen it here: #7

@ViRb3 It is necessary to exclude private addresses AND server addres engage.cloudflareclient.com = 162.159.192.1 Wireguard treats 0.0.0.0/0 in a special way. Finally, you need to re-add the range for your WARP IP 172.16.0.2/32. I did it like this:
0.0.0.0/0 - (10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,162.159.192.1/32) + 172.16.0.0/24 And it works. The result is not 254 IPv4 routes but "only" 58
AllowedIPs = 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/7, 162.0.0.0/9, 162.128.0.0/12, 162.144.0.0/13, 162.152.0.0/14, 162.156.0.0/15, 162.158.0.0/16, 162.159.0.0/17, 162.159.128.0/18, 162.159.192.0/32, 162.159.192.2/31, 162.159.192.4/30, 162.159.192.8/29, 162.159.192.16/28, 162.159.192.32/27, 162.159.192.64/26, 162.159.192.128/25, 162.159.193.0/24, 162.159.194.0/23, 162.159.196.0/22, 162.159.200.0/21, 162.159.208.0/20, 162.159.224.0/19, 162.160.0.0/11, 162.192.0.0/10, 163.0.0.0/8, 164.0.0.0/6, 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, 224.0.0.0/3, 172.16.0.0/24

You may not need to add the whole 172.16.0.0/24. It may not be necessary to exclude only 162.159.192.1/32 which would shorten the AllowedIPs even more. It seems that WARP uses a wider IP range. I use this online Wireguatd AllowedIPs calculator.

[duhd1993]

Allowed IP is not intended for this scenario, i guess. routes are supposed to be handled by the system native utility instead of wireguard.
The official macos app also gives you the option to exclude private IPs the same way. But obviously the connection is broken with that, which means at least some maintainers of wireguard have no idea how AllowedIPs work.
Wireguard is usually compared against anyconnect/openvpn for being efficient and small. Well, it turns out the extra size of those programs are not all wasted.

[zadrakar]

@duhd1993 The above list works fine at least on Linux. I use wgcf this way. The ranges listed in AllowedIPs appear as system routes.

[duhd1993]

@duhd1993 The above list works fine at least on Linux. I use wgcf this way. The ranges listed in AllowedIPs appear as system routes.

Yes. I figured how it works. thanks for the intro. I'm talking about the app giving me the option of excluding private ips, which does not work at all. Manually excluding server ip from allowed ip list solves the problem. Even so, this solution looks awkward. Not to mention 0.0.0.0/0 is specially treated but not documented. I ended up using netstat and route of macos directly. It's like ifconfig and iptables/ip of linux