How to Set Up a WireGuard VPN for Remote Employees
Practice4 minInnovialabs editorial team
In short
Run WireGuard on a router, VPS or office server, give every device its own key pair and VPN IP, list only office subnets in AllowedIPs, and remove the peer from the server when someone leaves.
The setup in brief
WireGuard is a simple, fast VPN protocol. It has no usernames or passwords: every device has a key pair, and the server knows the public keys of allowed clients. Whoever holds the private key can connect.
That leads to the main rules:
- one key, one device — no shared configs per department;
- every client gets its own IP inside the VPN;
- you keep a register of which key belongs to whom.
Step 1. Where to run the server
| Option | Pros | Cons |
|---|---|---|
| Router with WireGuard support | No extra hardware, direct access to the office network | Needs a public IP or DDNS, adds router load |
| VPS in the cloud | Static IP, the office opens no ports | The office must be linked to the VPS with its own tunnel |
| Office server or mini PC | Flexible, powerful | Port forwarding on the router, routing setup |
For a small office with a public IP, the router is simplest. Without a public IP, use a VPS that both employees and the office router connect to.
WireGuard runs over UDP. Open the port on the server and forward it on the router if needed.
Step 2. Generate keys
On Linux, keys are created with the wg tool:
umask 077
wg genkey | tee server.key | wg pubkey > server.pub
wg genkey | tee alice-laptop.key | wg pubkey > alice-laptop.pub
Never send private keys (.key) as plain text in messengers. Many client apps can generate the key on the device itself — then the private key never leaves the laptop and you only receive the public one.
Step 3. Server configuration
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <contents of server.key>
[Peer]
# alice-laptop
PublicKey = <contents of alice-laptop.pub>
AllowedIPs = 10.8.0.2/32
On the server, AllowedIPs is the address the client is allowed to use. If the server is a separate machine rather than the router, enable IP forwarding on it and set up a route or NAT into the office network.
Step 4. Client configuration
[Interface]
PrivateKey = <device key>
Address = 10.8.0.2/32
DNS = 192.168.1.1
[Peer]
PublicKey = <contents of server.pub>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24, 192.168.1.0/24
PersistentKeepalive = 25
Here 192.168.1.0/24 is an example office subnet — use your own. PersistentKeepalive keeps the tunnel alive behind NAT. A phone config is easy to hand over as a QR code.
Step 5. Split or full tunnel
This is decided by one AllowedIPs line in the client config:
- Split tunnel —
AllowedIPs = 10.8.0.0/24, 192.168.1.0/24. Only office traffic goes through the VPN; the rest of the internet goes direct. Less load on the office line. - Full tunnel —
AllowedIPs = 0.0.0.0/0, ::/0. All traffic goes through the office. Needed when services are allowed only from the office IP or traffic must be filtered.
For most offices, split tunnel is enough.
Step 6. Revoking access
When an employee leaves or loses a laptop:
- Remove the peer from the running interface:
wg set wg0 peer <public key> remove
- Delete the
[Peer]block from the config file so it does not come back after a restart. - Record the revocation date in the key register.
- Check whether the person has other devices with keys.
Without a register, a year later nobody can tell who owns a peer without a comment.
Common mistakes
- One config for several people — you cannot revoke access for just one.
- Full tunnel without a reason — the office line fills up with unrelated traffic.
- The office subnet matching an employee's home network (both
192.168.1.0/24, for example) — routing breaks. Use a less common subnet for the office. - Sending private keys in group chats.