Setting up WireGuard VPN on Windows: a practical guide

WireGuard has quietly become the default answer for site-to-site links and remote staff access. It is small enough to audit, fast enough that people stop noticing it is on, and simple enough that a working tunnel is a dozen lines of configuration rather than an afternoon with a vendor manual.

Setting it up on Windows is genuinely straightforward. There is, however, one piece of behaviour that catches almost everyone the first time, and it is worth understanding before you roll it out to staff laptops.

Installing the client

Use the official client from wireguard.com/install. It supports Windows 10, Windows 11, and Windows Server 2016 through 2025, and it ships WireGuardNT, the native kernel driver — which is why throughput on Windows is now comparable to Linux rather than an afterthought.

Avoid the repackaged installers that turn up in search results. This is a VPN client with a kernel-mode driver; the download source is part of your threat model.

Reading the configuration

A WireGuard tunnel is one text file with two sections. Here is a typical client config:

[Interface]
PrivateKey = <this machine's private key>
Address    = 10.10.0.5/32
DNS        = 10.10.0.1

[Peer]
PublicKey           = <the server's public key>
Endpoint            = vpn.example.com:51820
AllowedIPs          = 10.10.0.0/24, 192.168.50.0/24
PersistentKeepalive = 25

Worth knowing about each piece:

• Keys are per-machine, not per-user. Generate a fresh keypair on every device. The client will do it for you when you create an empty tunnel — let it, rather than copying a config between laptops.
• Endpoint is the public address of the server. WireGuard runs over UDP; 51820 is the usual port but nothing requires it.
• PersistentKeepalive = 25 matters when the client sits behind NAT. Without it, the NAT mapping expires and inbound connections stop arriving until the client speaks first. Set it on the side behind NAT.
• AllowedIPs is the one that does all the work. Read on.

AllowedIPs is the whole routing policy

There is no “split tunnel” toggle in WireGuard, because AllowedIPs already is one. It serves two purposes at once: which source addresses are accepted from that peer, and which destinations get routed to it.

So a narrow list sends only the office networks over the tunnel and leaves everything else on the local connection:

AllowedIPs = 10.10.0.0/24, 192.168.50.0/24

Whereas a default route sends everything:

AllowedIPs = 0.0.0.0/0, ::/0

For most business use — reaching a file server, an ERP box, a management network — the narrow version is the right answer. Pushing all of a user's traffic through head office costs you bandwidth and gains you very little.

The kill-switch behaviour nobody expects

This is the part worth reading twice.

If a WireGuard interface on Windows has exactly one peer and that peer's AllowedIPs contains a /0 route, the client silently enables a kill switch. It installs firewall rules that block all traffic except: packets through the tunnel, loopback, DHCP and NDP, the tunnel service's own packets, and DNS — but only to the DNS servers named in the config.

That is excellent behaviour for a privacy VPN. It is occasionally a support ticket for a business laptop, because the moment that tunnel is up, the local printer, the local NAS and the hotel captive portal all stop responding, and the user reports that “the internet is broken”.

The official documentation gives a clean way out. If you want a full tunnel without the restrictive firewalling, replace the /0 routes with two halves that cover the same space:

AllowedIPs = 0.0.0.0/1, 128.0.0.0/1, ::/1, 8000::/1

This routes essentially everything through the tunnel but does not trigger the kill-switch rules. The client's editor exposes the same thing as a Block untunneled traffic checkbox. Decide which behaviour you want deliberately — do not let it be a side effect of how you happened to write the routes.

DNS

Set DNS in the [Interface] section whenever the tunnel needs to resolve internal names. Without it, Windows applies its normal multihomed resolution, which means queries for internal hostnames can go to whichever resolver answers first — usually the local one, which knows nothing about your internal zone.

With a /0 route and the kill switch active, the DNS entry becomes load-bearing: queries to anything other than the listed servers are blocked outright.

When it does not work

Four causes cover almost every failed tunnel:

1. No handshake at all. UDP is not reaching the server. Check the firewall on the server, and check that the endpoint port is actually open from the client's network — some hotel and mobile networks block outbound UDP on unusual ports.
2. Handshake succeeds, no traffic. Almost always AllowedIPs. The destination you are trying to reach is not in the list, or the server's config does not list your client's tunnel address.
3. Small requests work, large transfers stall. This is MTU. The client normally sets the tunnel MTU to 80 below the MTU of the default-route interface, but some links need it lower — try 1380 and work from there.
4. Works, then dies after a few minutes of idle. Add PersistentKeepalive = 25 on the side behind NAT.

Before you deploy it to staff

A tunnel on one laptop is a five-minute job. A fleet of them is a system, and deserves to be treated like one:

• Generate keys on the device; never reuse a config across machines. A shared key means you cannot revoke one laptop without revoking all of them.
• Give every client its own /32 address so logs and firewall rules can tell them apart.
• Keep a record of which public key belongs to which device and person. WireGuard has no identity layer — the key is the identity, and an undocumented key is an account you cannot audit.
• Decide the offboarding step now: removing the peer from the server config is what actually revokes access.
• Restrict what the tunnel reaches. A VPN that drops every remote user onto a flat internal network has replaced a perimeter with a longer cable.

Worth it?

For most small and mid-sized networks, yes. WireGuard gives you a fast, modern, genuinely auditable tunnel without a licence server or a per-seat bill, and the Windows client is good enough that non-technical staff can run it with a single switch. The complexity it does have sits almost entirely in AllowedIPs and in key management — get those two right and the rest largely looks after itself.

Livezen Technologies designs and manages secure remote access, site-to-site VPNs and network infrastructure for businesses in Sri Lanka, the UAE, the UK and the USA. If you are planning remote access for your team, get in touch and we will help you scope it properly.