Setting Up a WireGuard VPN Server for Remote Employee Access

Imagine this: 50 employees work remotely, but the corporate network is built on OpenVPN — it's slow, clients constantly drop, and licenses cost money. The solution is WireGuard. We deploy WireGuard VPN servers for secure remote access to corporate infrastructure. Over 5 years, we've completed projects for 50+ companies, from startups to enterprises with hundreds of employees. WireGuard is a modern protocol built into the Linux kernel that outperforms OpenVPN and IPSec in both performance and simplicity.

Why We Choose WireGuard Over Outdated VPNs

Our engineers switched to WireGuard long ago. The reason is the codebase: ~4000 lines vs. 400,000 for OpenVPN. This not only improves security (smaller attack surface) but also speed. WireGuard runs in kernel space, uses ChaCha20-Poly1305 and Curve25519 — on modern servers it delivers up to 2 Gbps per core. For comparison: OpenVPN on the same resources yields about 300 Mbps. The result: users don't notice delays when working with 1C, Bitrix24, or file storages. Savings on commercial VPN licenses reach 70%.

How We Set Up a WireGuard VPN Server Turnkey

Installation and Key Generation

# Ubuntu 20.04+, Debian 11+
apt install wireguard

# Generate server keys
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub
chmod 600 /etc/wireguard/server.key

# Keys for the first client
wg genkey | tee /etc/wireguard/client1.key | wg pubkey > /etc/wireguard/client1.pub

Server Configuration

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <contents of server.key>

# Enable forwarding and NAT for clients (if internet access is needed)
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE

# Client 1
[Peer]
PublicKey = <contents of client1.pub>
AllowedIPs = 10.10.0.2/32

# Client 2
[Peer]
PublicKey = <contents of client2.pub>
AllowedIPs = 10.10.0.3/32

# Enable IP forwarding
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.d/99-wg.conf
sysctl -p /etc/sysctl.d/99-wg.conf
# Start the interface and enable auto-start
systemctl enable --now wg-quick@wg0

Client Configuration

# /etc/wireguard/wg0.conf (on the client)
[Interface]
Address = 10.10.0.2/32
PrivateKey = <contents of client1.key>
DNS = 10.10.0.1 # DNS via VPN (optional)

[Peer]
PublicKey = <contents of server.pub>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0 # Route all traffic through VPN
# Or only the corporate subnet:
# AllowedIPs = 10.0.0.0/8, 172.16.0.0/12
PersistentKeepalive = 25 # Keep NAT hole open

PersistentKeepalive = 25 is important for clients behind NAT (laptops, mobile devices). Without it, the connection drops during idle — the NAT entry expires.

Managing Peers Without Restart

# Add a new client on the fly
wg set wg0 peer <new-client-pubkey> allowed-ips 10.10.0.10/32
# Save changes to config
wg-quick save wg0
# Remove a client
wg set wg0 peer <pubkey> remove
# Connection status
wg show

wg show displays the last handshake time for each peer — convenient to see who is connected right now.

How to Automate Mass WireGuard Client Deployment

We use scripts to generate configurations from templates. For a hundred employees, we prepare an Ansible playbook: it creates keys, forms configs, and sends them via email or a corporate portal. The process:

1. Inventory — list of employees with their subnets.
2. Key generation — for i in $(cat users.txt); do wg genkey | tee ${i}.key | wg pubkey > ${i}.pub; done.
3. Configuration assembly — substitute the server's public key and the client's private key into a template.
4. Distribution — via an internal Git repository or a distribution script.

This reduces manual operations to a minimum and eliminates errors during key copying. We store configurations in Git, allowing change tracking and rollback on errors — effectively GitOps for VPN. For Active Directory integration, we use scripts that generate keys based on user groups.

How to Monitor WireGuard via Prometheus?

For metrics collection, we use the wg_exporter. It exports the number of peers, data transferred, and last handshake time. In Grafana, we set up a dashboard: green peers (handshake < 2 minutes), yellow (2–5 minutes), red (>5 minutes). This provides instant visibility of VPN status. We configure Alertmanager based on SLO: if a handshake hasn't occurred within 2 minutes, an alert fires; MTTR is reduced to 5 minutes thanks to a prepared runbook. If you need VPN monitoring, contact us — we'll set up Prometheus and Grafana for your tasks.

Common Problems and Their Solutions

Clients behind NAT lose connection — add PersistentKeepalive = 25 and check iptables FORWARD chain. Slow speed on large volumes — we recommend setting MTU to 1420 and checking CPU load on the server. Subnet conflict — if the corporate network uses 10.0.0.0/8, change the VPN network to another, e.g., 172.16.0.0/12. For Kubernetes, we use WireGuard sidecar containers for secure access to the API server.

What's Included in WireGuard Setup

We evaluate the project in 1 business day. Timelines: from 2 hours to 2 days depending on scale. Order a consultation — an engineer will analyze your infrastructure and propose the optimal solution.

Timelines

Pricing is calculated individually after an infrastructure audit. Get a consultation — we'll send you a precise estimate.