WireGuard on macOS: the two installs, and the interface name that breaks Linux tutorials

Installing WireGuard on a Mac looks trivial until the tutorial you are following was written for Linux. Two things trip people up: there are two different WireGuard products for macOS, and the interface name everyone uses in examples, wg0, cannot exist on a Mac.

The two installs, from the official page

The WireGuard install page lists both, and they are genuinely different software:

The Mac App Store app. A graphical client with a menu-bar item, tunnel import, and on-demand activation. This is what most people want.

The command-line tools.

brew install wireguard-tools
# or, with MacPorts
port install wireguard-tools

This gives you wg and wg-quick, the same commands you use on a server. Under the hood it runs the userspace Go implementation rather than a kernel module, because macOS has no in-kernel WireGuard.

They do not share a tunnel list. A tunnel you import in the app will not appear in wg show, and vice versa. Choose one for a given machine unless you have a reason to run both.

The part that breaks Linux tutorials: wg0 does not exist here

This is the single most common failure, and the error message rarely explains it.

On Linux you create wg0 and move on. On macOS, tunnels ride the utun driver, and the WireGuard cross-platform documentation states the constraint plainly: the utun driver cannot have arbitrary interface names. You must use utun followed by a number, such as utun0, or plain utun to let the kernel choose one for you.

# fails on macOS
sudo wg-quick up wg0

# works
sudo wg-quick up utun

So if you copied a guide that says wg0, rename the config file and any command referencing it. The keys, AllowedIPs, Endpoint and DNS lines are unaffected: only the interface name is platform-specific.

Finding out which utun you got. If you let the kernel pick, you need a way to know the result. Set WG_TUN_NAME_FILE before bringing the tunnel up and the chosen name is written there:

export WG_TUN_NAME_FILE=/tmp/wg-name
sudo -E wg-quick up utun
cat /tmp/wg-name    # e.g. utun4

Without that, you are reading ifconfig output and guessing which utun belongs to you, which is fine once and tedious in a script.

Importing a config you already have

If you generated a client config on your server, it transfers as-is. In the App Store app, use the import option and select the .conf file; the tunnel appears in the list, ready to toggle. With the CLI, place it at /opt/homebrew/etc/wireguard/utun.conf (Apple Silicon) or /usr/local/etc/wireguard/utun.conf (Intel), naming the file after the interface, then run wg-quick up utun.

A config generated for a phone works on a Mac too. It is a peer definition, not a device-specific artefact, provided each device has its own key pair rather than a shared one.

Checking it actually works

Bring the tunnel up, then confirm two things rather than assuming.

sudo wg show

A healthy peer shows a latest handshake within the last two minutes and non-zero transfer in both directions. Sent-but-not-received is the signature of a blocked return path. If the handshake never completes, our handshake troubleshooting guide walks the causes in order of likelihood.

Then confirm the traffic is really going through the tunnel, not just that the interface exists: check your public IP from the browser, and if you route DNS through the tunnel, verify there is no leak. Our note on WireGuard DNS leak prevention covers the settings that matter.

The short version

Two products: the App Store app for a graphical client, wireguard-tools via Homebrew or MacPorts for the same CLI as your server. They do not share tunnels. And on macOS the interface must be named utun or utunN, never wg0, because the utun driver does not accept arbitrary names. That single line explains most failed Mac setups copied from Linux guides.