WireGuard — private tunnel layer

What you are building

A small encrypted mesh (example family plan: 10.1.0.0/24) where each peer has:

• A private key + public key
• A unique WG IP (e.g. Mac 10.1.0.4, compute 10.1.0.5, VPS 10.1.0.2)
• AllowedIPs that only route the mesh (and maybe home LAN if you intend it)

Generate keys (any Mac / Linux)

wg genkey | tee peer.key | wg pubkey > peer.pub
chmod 600 peer.key

Peer config sketch (client Mac)

[Interface]
Address = 10.1.0.4/24
PrivateKey = <peer.key>
DNS = 10.1.0.1   # optional — only if you run DNS on mesh

[Peer]
PublicKey = <server.pub>
Endpoint = home.example:51820   # your router / always-on peer
AllowedIPs = 10.1.0.0/24
PersistentKeepalive = 25

Server / router sketch (always-on)

[Interface]
Address = 10.1.0.1/24
ListenPort = 51820
PrivateKey = <server.key>

[Peer]
PublicKey = <mac.pub>
AllowedIPs = 10.1.0.4/32

# Add a [Peer] block per laptop, phone, DGX, NAS…

Service binding law

On compute nodes, private services should listen on:

• 127.0.0.1 (same box)
• WireGuard IP (mesh peers)

Avoid binding private organs to 0.0.0.0 on the house LAN. Public access — if any — goes through a gated edge you control.

Verify

1. wg show — recent handshake, bytes both ways.
2. ping 10.1.0.5 (or your compute WG IP) from the Mac.
3. Open a mesh-only door only after handshake is healthy.
4. From a non-mesh machine on guest Wi‑Fi, the same organ port should fail. That failure is success.

Border / house split (advanced)

Full Family Office stacks often put an inner trusted network (compute + NAS) behind a stricter router, with a border tunnel to the outer house WAN. GL.iNet / OpenWrt makes that practical — see GL.iNet guide and the operator cheat-sheet docs/border-control-wg.md in the monorepo.

You can stop here

One always-on peer + one laptop peer is enough for travel access. DGX and NAS join as additional peers when you buy them — not before.

GL.iNet setup → Network layers All guides