A WireGuard VPN provides a fast, secure tunnel between endpoints. A macOS GUI client is available from the App Store
It works great. But its documentation is minimal. Even though the required keywords (which you must type manually) are the same as other clients, the GUI doesn’t give a hint about whether it’s right until you type it exactly correctly. Consequently, it can be a pain to configure it properly.
This screen shot shows a correctly configured (although fictitious) VPN tunnel. To get to this configuration window, use the Wireguard Manage Tunnels menu, click 
and choose Add Empty Tunnel… then fill in the resulting window as shown below:
Although there are plenty of guides to explain WireGuard, this summarizes my best understanding of the meaning of these fields. There may be additional ways to configure the VPN, but following this advice will result in a working secure configuration.
[Interface] Section
- PrivateKey: Private key for this computer. WireGuard uses this key to encrypt data sent to its peer, and decrypt received data. WireGuard displays the corresponding PublicKey (which you’ll enter into the peer) at the top of the window.
- Address: Address for the VPN tunnel interface on this computer. Use a /32 address chosen from an address range that not is in either this network or the peer’s network. (This example uses
10.0.10.2/32for this end. The peer (not shown) is10.0.10.1/32. They were chosen because the10.0.10.0/24subnet is not in use on either side of the tunnel.) - DNS: (Optional) Address(es) of DNS servers to be used by this computer. It’s OK to leave this out – by default, WireGuard will use the underlying OS DNS servers.
- ListenPort: (Optional) WireGuard listens on this port for traffic from its peer. It’s OK to leave this out – by default, WireGuard will select an unused port.
[Peer] Section
- PublicKey: The public key of the remote peer. WireGuard uses this key to decrypt the packets sent from the peer, and encrypt packets sent to the peer.
- PresharedKey: (Optional) This key will be used to encrypt the session. If specified, it is used in lieu of the public/private key pair for the peers.
- AllowedIPs: A comma-separated list of IP (v4 or v6) addresses with CIDR masks which are allowed as destination addresses when sending via this peer and as source addresses when receiving via this peer.
- Endpoint: (Optional) The address (or DNS name) and port of the remote peer. If specified, this peer will attempt to connect to the endpoint periodically.
- PersistentKeepalive: (Optional) The number of seconds this peer waits before sending another keep-alive message. These messages “keep the session alive” through NAT.
I would appreciate comments on these descriptions so I can make them more helpful/useful.
Additional Thoughts
The following thoughts are refinements to the advice shown above.
-
- The example above only allows traffic to/from the
192.168.4.0/24and172.30.42.0/24subnets to travel through the tunnel. To send all traffic through the tunnel (say, to avoid prying eyes of your ISP, etc), you can set the AllowedIPs to0.0.0.0/0. To send all IPv6 traffic through the tunnel, add::/0 - It neither necessary nor recommended to include the peer’s Address in the AllowedIPs list.
- Although both Endpoint and PersistentKeepalive are listed as optional, you normally set both when using the macOS WireGuard client. Activating the tunnel (from the WireGuard menu), causes WireGuard to begin sending Keepalive packets to the Endpoint, which starts up the tunnel.
- Dealing with NAT. If your ISP requires your remote peer to be behind NAT, you must configure your ISP’s router/modem to pass the WireGuard packets through. The setup varies from ISP to ISP, but in general, you’ll need to set up some kind of “virtual server”, “DMZ”, or “port forwarding” in the ISP router/modem to pass the WireGuard packets (on the port specified in the Endpoint) to the peer device.
- The example above only allows traffic to/from the
I’m not sure where the “not in use on either side of the tunnel” comes from.
I have on one end:
172.24.0.1/32 on wg0
172.24.0.1/24 on eth0
On the other end:
172.16.1.1/32 on wg0
172.16.1.1/24 on eth0
To me, this way of settings things up makes the most sense, and it works absolutely as expected. Unlike using “in between” addresses, which in my experience tends to give confusing results, unless you plan your network setup very carefully.
Maybe there’s some outdated standard that says you can’t do this? Maybe it doesn’t work on Windows? It definitely works on Linux, and as long as the wireguard interface is /32, I see no logical reason why it shouldn’t work (The mac runs DHCP on the LAN side, so I didn’t try it there).
I actually don’t understand all the ins-and-outs of Wireguard. I wrote this article a) to remind myself what I did to make it work; b) to give an example of macOS configuration that will undoubtedly work; and c) to document all the legal keywords in the Wireguard GUI. Whether other configurations (with the Wireguard interface taken from the subnet of the remote end) is beyond my ken: I simply chose 10.0.10.x for the address of the Wireguard interfaces so that I was sure they would work…
On second thought, I should probably mention, the IP addresses I posted before is the LAN side (both machines have two ethernet cards to act as firewalls). Doing it with the WAN (internet side) IP address would probably not be a good idea, as having the same IP address outside and inside the tunnel would likely make it try to route the wireguard-encrypted packets through the tunnel, encrypting them a second (and third (and fourth…)) time.
Maybe that’s what was meant, and I’m just being slow because my setup is more complex (being a lan-to-lan tunnel rather than a host-to-host or host-to-internet) than what most people will use Wireguard for.