💾 Archived View for thrig.me › tech › wireguard › macos-client.gmi captured on 2024-12-17 at 10:45:49. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Install the wireguard app from the app store, etc. If the server lacks a static addres then this will become more complicated.
[Interface]
PrivateKey = CLIENTPRIVATEKEY
Address = 192.0.2.3/24, 2001:db8:d0c::3/64
DNS = 192.0.2.1, 2001:db8:d0c::1
[Peer]
PublicKey = SERVERPUBLICKEY
PresharedKey = PRESHAREDKEY
AllowedIPs = 192.0.2.0/24, 2001:db8:d0c::/64
Endpoint = 198.51.100.42:4433
PersistentKeepalive = 25
Mostly I use this to direct DNS elsewhere, so that the ISP cannot spy on DNS requests that travel to the ISP's DNS server, or those that pass over the ISP's network unencrypted. This does mean that DNS requests may be observable by those who manage the networks and system the server runs on. There are trade-offs here.
A disadvantage of putting both clients onto the same subnet that use the same wg0 interface on the server is that there is no routing from one client to the other. Recall that the server is on 192.0.2.1 and the other client uses 192.0.2.2.
$ ping -c 1 192.0.2.1
PING 192.0.2.1 (192.0.2.1): 56 data bytes
64 bytes from 192.0.2.1: icmp_seq=0 ttl=255 time=18.092 ms
--- 192.0.2.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 18.092/18.092/18.092/0.000 ms
$ ping -c 1 192.0.2.2
PING 192.0.2.2 (192.0.2.2): 56 data bytes
36 bytes from 192.0.2.1: Redirect Host(New addr: 192.0.2.2)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 792b 0 0000 40 01 6c28 192.0.2.3 192.0.2.2
If you do need routing between the various clients then one should turn the server into more of a router between the various subnets the various clients will be on. Another method would have the clients directly connect to one another, though that may be made more complicated by random DHCP addresses, NAT, and such.
Here configuring one or more DNS servers is very important, in addition to modifying the AllowedIPs to route all traffic over the VPN. It does not appear possible to route only IPv6 over the tunnel, as if one sets "AllowedIPs = 192.0.2.0/24, ::/0" then both IPv4 and IPv6 routing is set to use the tunnel, as can be checked with `netstat -rn`.
[Interface]
PrivateKey = CLIENTPRIVATEKEY
Address = 192.0.2.3/24, 2001:db8:d0c::3/64
DNS = 192.0.2.1, 2001:db8:d0c::1
[Peer]
PublicKey = SERVERPUBLICKEY
PresharedKey = PRESHAREDKEY
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 198.51.100.42:4433
PersistentKeepalive = 25