Automatically add host route when peer address is within AllowedIPs?
Brian Candler
b.candler at pobox.com
Sun Jul 1 12:44:07 CEST 2018
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 = <snip>
ListenPort = XXXXX
Address = 10.12.0.1/24
[Peer]
PublicKey = GtMlTPv3tL++jG1eI2h7gJuuozgDp5F6iF+JUu0I/Fo=
AllowedIPs = 10.12.0.0/24
---- Client config ----
[Interface]
PrivateKey = <snip>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20180701/58bc3421/attachment-0001.html>
More information about the WireGuard
mailing list