From: Brian Candler <b.candler@pobox.com>
To: wireguard@lists.zx2c4.com
Subject: Automatically add host route when peer address is within AllowedIPs?
Date: Sun, 1 Jul 2018 11:44:07 +0100 [thread overview]
Message-ID: <1ea11592-82e2-1e90-acc1-52fd183d675f@pobox.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 10943 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 16478 bytes --]
reply other threads:[~2018-07-01 10:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ea11592-82e2-1e90-acc1-52fd183d675f@pobox.com \
--to=b.candler@pobox.com \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).