I have a problem where I want to tunnel packets to a remote subnet, but that remote subnet also includes the external IP of the wireguard server. When that happens, the client goes into a loop which soaks up 100% of CPU. Here's the test setup: 10.12.255/24 | 10.12.254/24 --+--------+----------------- Router ------+---------------- | .11 | .12 .1 .1 | .115 Target WG WG Host server client * Wireguard "Server": Ubuntu 16.04, wireguard 0.0.20180620-wg1~xenial from PPA * Wireguard "Client": macOS 10.12.6, wireguard-tools 0.0.20180625 installed from Homebrew * Tunnel subnet is 10.12.0/24; the router has a static route to 10.12.0/24 via 10.12.255.12 * I want to reach hosts 10.12.255.x via the tunnel, such as target host 10.12.255.11 ---- Server config ---- [Interface] PrivateKey = ListenPort = XXXXX Address = 10.12.0.1/24 [Peer] PublicKey = GtMlTPv3tL++jG1eI2h7gJuuozgDp5F6iF+JUu0I/Fo= AllowedIPs = 10.12.0.0/24 ---- Client config ---- [Interface] PrivateKey = ListenPort = YYYYY Address = 10.12.0.2/24 [Peer] PublicKey = 1kEwJOwzfMARwZG9H+A1QMfL3F76HZoxDhn1ciRdPnY= EndPoint = 10.12.255.12:XXXXX #AllowedIPs = 10.12.0.0/24 # (1)ok #AllowedIPs = 0.0.0.0/0 # (2) ok #AllowedIPs = 10.12.0.0/16 # (3) fail AllowedIPs = 10.12.0.0/24, 10.12.255.0/24 # (4) fail PersistentKeepalive = 22 It works with (1) AllowedIPs = 10.12.0.0/24: the client can ping the server 10.12.0.1. And it works with (2) AllowedIPs = 0.0.0.0/0: I can ping the target subnet (but also all my Internet traffic is routed down the tunnel, which I don't want). However with configuration (3) or (4), shortly after I do "wg-quick up wg0", CPU load on the macOS client jumps to 100%, as shown by Activity Monitor or top -u, and the fans spin up. bash-3.2# wg-quick up wg0 [#] wireguard-go utun WARNING WARNING WARNING WARNING WARNING WARNING WARNING W G W This is alpha software. It will very likely not G W do what it is supposed to do, and things may go G W horribly wrong. You have been warned. Proceed G W at your own risk. G W G WARNING WARNING WARNING WARNING WARNING WARNING WARNING INFO: (utun1) 2018/07/01 10:56:26 Starting wireguard-go version 0.0.20180613 [+] Interface for wg0 is utun1 [#] wg setconf utun1 /dev/fd/63 [#] ifconfig utun1 inet 10.12.0.2/24 10.12.0.2 alias [#] ifconfig utun1 up [#] route -q -n add -inet 10.12.255.0/24 -interface utun1 [#] route -q -n add -inet 10.12.0.0/24 -interface utun1 [+] Backgrounding route monitor Within about 20 seconds, CPU usage jumps up to max. "wg" shows huge amounts of traffic sent. The following are captured at approximately 1 second intervals: bash-3.2# wg interface: utun1 public key: GtMlTPv3tL++jG1eI2h7gJuuozgDp5F6iF+JUu0I/Fo= private key: (hidden) listening port: YYYYY peer: 1kEwJOwzfMARwZG9H+A1QMfL3F76HZoxDhn1ciRdPnY= endpoint: 10.12.255.12:XXXXX allowed ips: 10.12.0.0/24, 10.12.255.0/24 latest handshake: 39 seconds ago transfer: 0 B received, *629.43 MiB sent* persistent keepalive: every 22 seconds bash-3.2# wg interface: utun1 public key: GtMlTPv3tL++jG1eI2h7gJuuozgDp5F6iF+JUu0I/Fo= private key: (hidden) listening port: YYYYY peer: 1kEwJOwzfMARwZG9H+A1QMfL3F76HZoxDhn1ciRdPnY= endpoint: 10.12.255.12:XXXXX allowed ips: 10.12.0.0/24, 10.12.255.0/24 latest handshake: 41 seconds ago transfer: 0 B received, *694.98 MiB sent* persistent keepalive: every 22 seconds bash-3.2# wg interface: utun1 public key: GtMlTPv3tL++jG1eI2h7gJuuozgDp5F6iF+JUu0I/Fo= private key: (hidden) listening port: YYYYY peer: 1kEwJOwzfMARwZG9H+A1QMfL3F76HZoxDhn1ciRdPnY= endpoint: 10.12.255.12:XXXXX allowed ips: 10.12.0.0/24, 10.12.255.0/24 latest handshake: 43 seconds ago transfer: 0 B received, *765.37 MiB sent* persistent keepalive: every 22 seconds But tcpdump shows only an initial exchange of packets: $ sudo tcpdump -i en0 -nn udp port YYYYY or udp port XXXXX Password: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes 11:06:07.340249 IP 10.12.254.115.YYYYY > 10.12.255.12.XXXXX: UDP, length 148 11:06:07.343687 IP 10.12.255.12.XXXXX > 10.12.254.115.YYYYY: UDP, length 92 11:06:07.344060 IP 10.12.254.115.YYYYY > 10.12.255.12.XXXXX: UDP, length 32 I suspect the problem is to do with the server external IP of 10.12.255.12 being within the AllowedIPs = 10.12.255.0/24 range. While the tunnel is up, here is the routing table on the client: bash-3.2# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.12.254.1 UGSc 15 0 en0 10.12/24 utun1 USc 0 0 utun1 10.12.0.2 10.12.0.2 UH 0 0 utun1 10.12.254/24 link#4 UCS 6 0 en0 10.12.254.1/32 link#4 UCS 1 0 en0 10.12.254.1 64:d1:54:xx:xx:xx UHLWIir 19 67 en0 1197 10.12.254.100 0:e:58:xx:xx:xx UHLWI 0 0 en0 1127 10.12.254.101 b8:e9:37:xx:x:xx UHLWI 0 0 en0 1125 10.12.254.103 0:e:58:xx:xx:x UHLWI 0 0 en0 1109 10.12.254.104 0:e:58:xx:xx:xx UHLWI 0 0 en0 1088 10.12.254.115/32 link#4 UCS 0 0 en0 10.12.254.117 44:d2:44:xx:xx:xx UHLWI 0 0 en0 1177 10.12.255/24 utun1 USc 1 0 utun1 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 1 122329 lo0 169.254 link#4 UCS 0 0 en0 192.168.56 link#11 UCS 1 0 vboxnet 224.0.0/4 link#4 UmCS 2 0 en0 224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 12 en0 255.255.255.255/32 link#4 UCS 0 0 en0 That seems to be it: if it were to send encrypted packets to 10.12.255.12 during this time, then they would be sent back down utun1 to be re-encrypted again. However, it does work fine with AllowedIPs = 0.0.0.0/0. Here is the routing table when I do that: bash-3.2# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 0/1 utun1 USc 4 1 utun1 default 10.12.254.1 UGSc 11 0 en0 10.12.0.2 10.12.0.2 UH 0 0 utun1 10.12.254/24 link#4 UCS 7 0 en0 10.12.254.1/32 link#4 UCS 1 0 en0 10.12.254.1 64:d1:54:xx:xx:xx UHLWIir 7 180 en0 1197 10.12.254.100 0:e:58:xx:xx:xx UHLWI 0 0 en0 963 10.12.254.101 b8:e9:37:xx:x:xx UHLWI 0 0 en0 961 10.12.254.103 0:e:58:xx:xx:x UHLWI 0 0 en0 945 10.12.254.104 0:e:58:xx:xx:xx UHLWI 0 0 en0 924 10.12.254.107 9c:4:eb:xx:xx:xx UHLWI 0 0 en0 708 10.12.254.115/32 link#4 UCS 0 0 en0 10.12.254.117 44:d2:44:xx:xx:xx UHLWI 0 0 en0 1163 10.12.254.255 ff:ff:ff:ff:ff:ff UHLWbI 0 3 en0 *10.12.255.12 10.12.254.1 UGHS 2 93 en0** *127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 1 122329 lo0 128.0/1 utun1 USc 1 0 utun1 169.254 link#4 UCS 0 0 en0 192.168.56 link#11 UCS 2 0 vboxnet 192.168.56.255 ff:ff:ff:ff:ff:ff UHLWbI 0 3 vboxnet 224.0.0/4 link#4 UmCS 2 0 en0 224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 76 en0 255.255.255.255/32 link#4 UCS 0 0 en0 I see that a specific host route has been added for 10.12.255.12. INFO: (utun1) 2018/07/01 11:30:01 Starting wireguard-go version 0.0.20180613 [+] Interface for wg0 is utun1 [#] wg setconf utun1 /dev/fd/63 [#] ifconfig utun1 inet 10.12.0.2/24 10.12.0.2 alias [#] ifconfig utun1 up [#] route -q -n add -inet 0.0.0.0/1 -interface utun1 [#] route -q -n add -inet 128.0.0.0/1 -interface utun1 *[#] route -q -n add -inet 10.12.255.12 -gateway 10.12.254.1** *[+] Backgrounding route monitor And I find this is documented - the wg-quick manpage says: /"If one of those routes is the default route (0.0.0.0/0 or ::/0), then it uses ip-rule(8) to handle overriding of the default gateway."/ So I think the answer is straightforward: I would like this rule to be added when the target IP is within any AllowedIPs subnet, not just for 0.0.0.0/0. Would you agree? If I add this route manually, everything seems to work fine. Thanks, Brian Candler.