Alpha Snapshots of WireGuard for Android and macOS

Hey folks,

We're gradually adding more platforms capable of running WireGuard, thanks to some still-buggy userspace code Mathias and I have been developing. Today you can try WireGuard on two new platforms: Android and macOS.

[NEW] WireGuard for Android
---------------------------
You can download the app from the Play Store or from F-Droid. It supports adding wg-quick(8)-style .conf files or .zips of them. The app uses the kernel module if available, which gives the best performance, stability, and battery life, and falls back to the userspace code if it's not available. Download at:
https://play.google.com/store/apps/details?id=com.wireguard.android

[NEW] WireGuard for macOS
-------------------------
You can install wg-quick, wg, and wireguard-go using Homebrew. Then you should be able to run wg-quick up whatever and familiar commands as you're used to. If you're setting up a network manually, you can run wireguard-go utun3 in place of the usual Linux command ip link add utun3 dev wireguard. Install with the Homebrew command:

$ brew install wireguard-tools

[FUTURE] WireGuard for ${YOUR_FAVORITE_PLATFORM}
------------------------------------------------
It's a work in progress, and we hope to have nice things to announce in the coming weeks. If you're interested in helping to develop support for a particular platform, please send us an email at [email protected].

[WORKHORSE] WireGuard for Linux
-------------------------------
The Linux kernel implementation remains the recommended and most complete WireGuard implementation, and we're actively working on upstreaming this code to kernel.org. Install instructions are available for every major distro on:
https://www.wireguard.com/install/

[DISCLAIMER] Alpha Warning for Security-related Software
--------------------------------------------------------
The new implementations for macOS and Android are alpha quality, at best, so keep expectations low. There are bugs. There may even be security issues, and we don't yet certify that this software does what we want it to do. Let us know as you encounter the inevitable nasty bugs. Consider this as "pre-release" software.

Enjoy!
Jason

MacOS users should be aware that if you have manually assigned DNS servers the current wg-quick implementation will remove them and not restore them.

Wow, that was fast. Indeed, from the source [1], see comment:

set_dns() {
# TODO: this should use scutil and be slightly more clever. But for now # we simply overwrite any _manually set_ DNS servers for all network # services. This means we get into trouble if the user doesn't actually # want DNS via DHCP when setting this back to "empty". Because macOS is # so horrible to deal with here, we'll simply wait for irate users to # provide a patch themselves.
local service response
{ read -r _; while read -r service; do
[[ $service == "*"* ]] && service="${service:1}"
while read -r response; do
[[ $response == *Error* ]] && echo "$response" >&2
done < <(cmd networksetup -setdnsservers "$service" "${DNS[@]}")
done; } < <(networksetup -listallnetworkservices)
}

del_dns() {
local service response
{ read -r _; while read -r service; do
[[ $service == "*"* ]] && service="${service:1}" while read -r response; do
[[ $response == *Error* ]] && echo "$response" >&2
done < <(cmd networksetup -setdnsservers "$service" Empty)
done; } < <(networksetup -listallnetworkservices)
}

If you'd like to contribute a patch to do this properly, please don't hesitate.

[1] https://git.zx2c4.com/WireGuard/tree/src/tools/wg-quick/darwin.bash

Hi Tim,

That was actually surprisingly easy:

https://git.zx2c4.com/WireGuard/commit/?id=302195d3563491b5f7a0b6c35fdeb7a53891a1f0

Let me know if the updated script works well for you:

$ curl -o /usr/local/bin/wg-quick
https://git.zx2c4.com/WireGuard/plain/src/tools/wg-quick/darwin.bash

Jason

Hi Jason,

thanks for your hard work!

there seems to be sth. weird with the routing rules/tables. The wireguard routes are not set up properly on my phone.

My wireguard network is 10.80.100.0/24, the wireguard server is 10.80.100.1, the phone is 10.80.100.27.

On the phone:

lux:/ # ip route
10.80.100.0/24 dev tun0 proto kernel scope link src 10.80.100.27 10.160.151.136/29 dev rmnet_data0 proto kernel scope link src 10.160.151.139

lux:/ # ip route get 10.80.100.1
10.80.100.1 via 10.160.151.140 dev rmnet_data0 src 10.160.151.139 uid 0
cache

-> wrong. this routes via the mobile radio device.

lux:/ # ip route flush cache

lux:/ # ip route get 10.80.100.1
10.80.100.1 via 10.160.151.140 dev rmnet_data0 src 10.160.151.139 uid 0
cache

How can I debug this further?

I have an openvpn server on the same box, in another subnet. This works fine on the phone:

lux:/ # ip route
10.100.40.0/24 dev tun0 proto kernel scope link src 10.100.40.2 10.160.151.136/29 dev rmnet_data0 proto kernel scope link src 10.160.151.139

lux:/ # ip route get 10.80.100.1
10.80.100.1 dev tun0 src 10.100.40.2 uid 0
cache

-> works, the wireguard subnet is routed via tun0.

Stefan

Check the output of "ip rule".

-- Matthias Urlichs

As a user I can't read anything useful out of this, since I don't known how wireguard android sets its fwmarks, etc. But here it is:

lux:/ # ip rule
0: from all lookup local
10000: from all fwmark 0xc0000/0xd0000 lookup legacy_system
10500: from all oif dummy0 uidrange 0-0 lookup dummy0
10500: from all oif rmnet_data0 uidrange 0-0 lookup rmnet_data0
11000: from all iif tun0 lookup local_network
12000: from all fwmark 0x0/0x20000 iif lo uidrange 0-99999 lookup tun0
12000: from all fwmark 0xc0065/0xcffff lookup tun0
13000: from all fwmark 0x10063/0x1ffff lookup local_network
13000: from all fwmark 0x10064/0x1ffff lookup rmnet_data0
13000: from all fwmark 0x10065/0x1ffff uidrange 0-99999 lookup tun0
13000: from all fwmark 0x10065/0x1ffff uidrange 0-0 lookup tun0
14000: from all oif dummy0 lookup dummy0
14000: from all oif rmnet_data0 lookup rmnet_data0
14000: from all oif tun0 uidrange 0-99999 lookup tun0
15000: from all fwmark 0x0/0x10000 lookup legacy_system
16000: from all fwmark 0x0/0x10000 lookup legacy_network
17000: from all fwmark 0x0/0x10000 lookup local_network
19000: from all fwmark 0x64/0x1ffff lookup rmnet_data0
21000: from all fwmark 0x65/0x1ffff lookup rmnet_data0
22000: from all fwmark 0x0/0xffff lookup rmnet_data0
23000: from all fwmark 0x0/0xffff uidrange 0-0 lookup main
32000: from all unreachable

Stefan

Hi all,

So - I don't know if it's me being *thick* or wg-quick isn't supposed to do this, but:

I have a wireguard config on my Macbook with addresses 10.3.0.5/31 & fd10::10:3:41/127, other endpoint is .4 and :40.

Running wg-quick up wg-xxxxx works fine - pinging the v4 of the other side doesn't work however v6 does -

# ping 10.3.0.4
PING 10.3.0.4 (10.3.0.4): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
# ping6 fd10::10:3:40
PING6(56=40+8+8 bytes) fd10::10:3:41 --> fd10::10:3:40
16 bytes from fd10::10:3:40, icmp_seq=0 hlim=64 time=16.008 ms
16 bytes from fd10::10:3:40, icmp_seq=1 hlim=64 time=16.019 ms
16 bytes from fd10::10:3:40, icmp_seq=2 hlim=64 time=14.460 ms

I think I see the problem:

# ip route get 10.3.0.4
10.3.0.4 via 10.2.0.1 dev en0  src 10.2.0.71
# ip -6 route get fd10::10:3:40
fd10::10:3:40 dev utun1  src fd10::10:3:41

and it's fixable, of course, I was just wondering if this is intended behaviour considering v6 works perfectly OK?

Tom