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.

No config to import yet? Our free WireGuard config generator writes the server file and the Mac client file in your browser, ready to import as a .conf; keys are generated locally and nothing is sent to a server. The generator is free with no account, up to 250 devices, and its ZIP export holds every client .conf and its QR code as a PNG, handy to set up a whole office or family in one go.

No server yet? The Mac client needs a WireGuard server to connect to; a Contabo Cloud VPS (affiliate link) runs one with its own public IPv4, from 5.50 € a month on a 24-month term as read on 17 October 2026. If you would rather have a US host with a 30-day money-back guarantee, Ultahost VPS Basic is 5.52 $ a month on a 24-month term (1 GB RAM, dedicated IPv4, read on 21 October 2026), enough for a WireGuard server for a few devices. Choosing a host? Compare the best VPS for a VPN and Contabo vs Hetzner vs OVH on the price actually billed. Another option: HostPapa Unmanaged VPS Lite (affiliate link) is 2.95 $ a month on a 3-year term, then the regular rate (1 core, 1 GB RAM, 25 GB NVMe, root SSH access, 30-day money-back guarantee, read on 28 October 2026).

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, and the man page is permissive about it: any free-form string matching [a-zA-Z0-9_=+.-]{1,15} works, so up to 15 characters of whatever you like. 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. Nothing in the file is Mac-specific: the same 44-character base64 keys, the same Endpoint on 51820/UDP by default, and a PersistentKeepalive that accepts any value from 1 to 65535 seconds, with 25 the figure the man page suggests for a peer behind NAT.

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. Two minutes is not a rule of thumb: an initiator renegotiates after 120 seconds of session age, and the kernel refuses a key outright at 180 seconds, so a handshake older than that on a live tunnel means renegotiation is failing. 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. When the Mac side looks right and the handshake still never arrives, the fault is almost always on the server: the troubleshooting checklist in our WireGuard Self-Hosting Kit (9 USD, in English, PDF + .conf templates) lists 12 causes in diagnostic order with the command that confirms each one, and its client templates import into the macOS app unchanged. See the kit on Gumroad.

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.

A VPN changes your IP. It does not change your browser.

A tunnel replaces the address a service sees. It changes nothing about what your browser announces on its own - fonts, screen, time zone, graphics stack - and that combination is often stable enough to recognise you across sessions, tunnel or no tunnel.

Measure your own browser fingerprint - passive, no questions, no account, no email.

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.