How to set up a VPN on Windows 11

There are two ways to run a VPN on Windows 11, and they are not equivalent. The provider's app installs a driver and manages the tunnel for you. The built-in client, under Settings, Network & internet, VPN, only speaks the protocols Windows itself implements — IKEv2, L2TP/IPsec, SSTP and the long-obsolete PPTP. It cannot speak WireGuard or OpenVPN at all, which is why almost every current provider ships an app rather than a set of manual instructions.

The app route

1. Download the installer from the provider's own site. The Windows download page has VPNmine's.
2. Run it and accept the driver installation prompt. The driver is what creates the virtual network adapter; without it there is no tunnel.
3. Sign in, or skip where the provider allows it.
4. Pick a server and connect.
5. Turn on the kill switch before you rely on it. It is off by default in most clients.

The WireGuard client route

If you have a config file rather than an app, the official WireGuard for Windows client imports it directly. Install it, choose Add Tunnel, select the .conf file, and activate. It is small, it is the reference implementation, and it does one thing.

What it does not give you is a server picker, automatic failover or a kill switch beyond AllowedIPs. Setting AllowedIPs = 0.0.0.0/0, ::/0 routes everything, and the client's "block untunneled traffic" option adds a firewall rule that behaves as a kill switch. Both are worth setting.

The DNS problem Windows has by default

Windows resolves names by asking every network interface at once and taking the first answer. Microsoft calls this smart multi-homed name resolution, and it is documented behaviour rather than a bug. With a VPN connected, it means lookups can be answered by your provider's resolver on the physical adapter before the tunnel's resolver replies, so your ISP still sees every domain you open even though the traffic is encrypted.

Two fixes:

• Use a client with leak protection. Most modern apps set firewall rules that block DNS on every adapter except the tunnel.
• Disable the behaviour by policy. In Group Policy, under Computer Configuration, Administrative Templates, Network, DNS Client, set Turn off smart multi-homed name resolution to Enabled. On Home editions the equivalent registry value is DisableSmartNameResolution under HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters.

Confirm the result with the DNS leak test. If the resolvers that answer belong to your internet provider, the leak is still open.

Interface metrics, when traffic ignores the tunnel

If the tunnel connects but traffic keeps leaving through Wi-Fi, two adapters are both claiming a default route and Windows is preferring the wrong one. Check with:

route print 0.0.0.0

Both adapters will be listed with a metric; lower wins. Setting the VPN adapter's metric below the physical one, in the adapter's IPv4 properties under Advanced, fixes it. Most clients set this themselves, and a client that does not is worth replacing.

Browsers that bypass the system resolver

Edge, Chrome and Firefox can all use DNS-over-HTTPS to a resolver of their own, independently of what Windows is configured to do. That is good for privacy on an untrusted network and confusing behind a VPN, because the browser's lookups go somewhere the tunnel's DNS settings never touched.

If the leak test shows a resolver you did not configure anywhere, check the browser's secure DNS setting before assuming the VPN is at fault.

Confirm it works

Open what is my IP. The address should be the server's, in the country you picked. Then run the DNS leak test and confirm no resolver belonging to your internet provider answers. Those two checks together cover the overwhelming majority of misconfigurations.

What to turn on before you rely on it

• Kill switch or leak protection, so a dropped tunnel blocks traffic rather than passing it in the clear.
• Auto-connect on untrusted networks, if the client offers it.
• IPv6 handling. Either the tunnel carries ::/0, or IPv6 is disabled on the adapter. A tunnel that carries IPv4 only, on a connection with working IPv6, leaks every dual-stack site.

Split tunnelling on Windows

Windows has no system-wide split tunnelling of its own, so whether you can send some apps through the tunnel and others around it depends entirely on the client. Where it exists it is implemented either by application name or by destination address, and the two behave differently: an app-based rule follows the program wherever it connects, while an address-based rule follows the destination whatever opens it.

Use it sparingly. Every app you exclude is an app whose traffic your network can see, and the usual reason for excluding one — a banking site that objects to a foreign address — is better solved by connecting to a server in your own country.

When Windows itself is the problem

Two settings outside the VPN client cause failures that look like the VPN's fault.

Fast startup leaves the network stack in a partially restored state after a shutdown, so the tunnel comes up before the adapter is ready and fails silently. Turning it off, under Power Options, Choose what the power buttons do, removes a whole category of intermittent connection problems.

A third-party firewall may block the tunnel's UDP port outbound, which produces a client stuck at "connecting" with no error. Allowing the client through, rather than disabling the firewall, is the fix worth keeping.