Learn WireGuard - Client-to-Site (Remote Access)

#Introduction

The most common real-world scenario: an employee working from home needs to access internal office servers. This is where client-to-site, or remote access, VPNs come in. A single WireGuard server at the office serves many clients, and each client is just one peer on the server side.

Episode 10 covers how to build this scheme: server configuration, the difference between split tunnel and full tunnel from the client's point of view, per-client key management, and centralized management tools for when the number of clients grows large.

#Remote Access Architecture

#One Server, Many Clients

The office WireGuard server has a single wg0 interface with many [Peer] sections — one per client. Each client gets a unique tunnel address on the same subnet, and the server acts as the gateway to the office network.

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <kunci privat server>
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
 
[Peer]
PublicKey = <kunci publik laptop>
AllowedIPs = 10.0.0.2/32
 
[Peer]
PublicKey = <kunci publik hp>
AllowedIPs = 10.0.0.3/32

Each [Peer] uses the /32 AllowedIPs belonging to its client. This is not just convenience: this way, revoking a client's access only requires removing that peer from the server.

#Configuration on the Client Side

The client only needs to know the server as its single peer. For a split tunnel to the office network:

[Interface]
Address = 10.0.0.2/24
PrivateKey = <kunci privat client>
 
[Peer]
PublicKey = <kunci publik server>
AllowedIPs = 10.0.0.0/24, 192.168.10.0/24
Endpoint = 203.0.113.5:51820
PersistentKeepalive = 25

PersistentKeepalive = 25 is mandatory on clients because they are almost always behind NAT — as we learned in episode 7.

#Split Tunnel vs Full Tunnel

#When to Choose a Split Tunnel

A split tunnel sends only traffic to the office subnets through the tunnel. Its advantages: browsing stays on the fast local internet, office bandwidth is not burdened, and video conferences keep their quality. It suits everyday work that only needs access to internal servers.

#When to Choose a Full Tunnel

A full tunnel with AllowedIPs = 0.0.0.0/0 sends all of a client's traffic through the office server. This is mandatory when security policy requires all traffic to pass through office proxy or filtering, or when the client is on an untrusted network. Its costs: office bandwidth becomes the single path and the latency of all traffic increases.

#Client Management

#Generating Keys per Client

Each client must have its own key pair. Never share a private key between clients, because revoking one client's access would also revoke the others:

wg genkey | tee client-privatekey | wg pubkey > client-publickey
chmod 600 client-privatekey

The private key is stored on the client side with chmod 600; the public key is registered as a [Peer] on the server.

#Adding and Revoking Clients

Adding a new client takes a single command on the server:

sudo wg set wg0 peer <PUBLIK_CLIENT_BARU> allowed-ips 10.0.0.4/32

Revoke access by removing the peer:

sudo wg set wg0 peer <PUBLIK_CLIENT_LAMA> remove

#Centralized Management

#When Clients Multiply

Managing peers manually in a configuration file becomes impractical after dozens of clients. Several open-source tools provide an interface and an API:

• wg-dashboard: a simple web panel for managing interfaces and peers.
• Firezone: WireGuard-based access with user authentication and policies.
• Netmaker: WireGuard mesh network management with automation features.

All three use WireGuard as the tunnel engine and provide a management layer on top. At small scale, wg set and configuration files are still more than enough.

#Closing

Episode 10 completed the remote access scheme: one WireGuard server serving many clients, each with its own unique key and address, choosing split tunnel or full tunnel according to need, and using centralized management tools as scale grows.

Key takeaways:

• Each client has its own /32 AllowedIPs on the server side.
• PersistentKeepalive = 25 is mandatory for clients behind NAT.
• A split tunnel saves bandwidth; a full tunnel guarantees all traffic passes office policy.
• Each client must have its own key pair.
• Revoking access is as simple as removing the peer on the server.
• wg-dashboard, Firezone, and Netmaker help manage many clients.

In episode 11 we cover multi-peer and hub topology — building hub-and-spoke with the server as the routing center between clients, comparing it with full mesh, and calculating the scaling cost of each approach.