Connecting to a VPN from your Windows VPS

What this is#

You want your Windows VPS to route some or all of its outbound traffic through a VPN, a commercial provider, your company's OpenVPN, a WireGuard peer. That's allowed and it works, Windows VPS is a full virtual machine, so TAP and WireGuard adapters install without any platform tweaks.

The catch is one of the most reliable footguns in server administration: connect a VPN client with default settings, and your RDP session dies within seconds, taking your access with it. This page explains why that happens, how to set up so it can't lock you out, the one fix that works with every client, and how to recover if you're reading this from the outside of a VPS you can no longer reach.

Why RDP dies the moment the VPN connects#

Understanding the mechanism makes every fix below obvious.

Your RDP session rides on a conversation: packets from your computer arrive at the VPS's public network adapter, and the VPS sends replies back the same way, using its default route. A consumer VPN client's whole job is to capture your traffic, so on connect it makes itself the default route (OpenVPN pushes redirect-gateway, WireGuard uses AllowedIPs = 0.0.0.0/0, commercial apps do one or the other under the hood).

The moment that happens:

1. Your RDP packets still arrive at the public adapter, inbound routing hasn't changed.
2. But the VPS's replies now follow the new default route, into the tunnel, exiting somewhere else on the internet with a different source address.
3. Your computer gets replies from an address it never talked to (or nothing at all) and discards them. The session freezes, then drops.

This is asymmetric routing, and it's not a bug in the VPN client, it's the client doing exactly what it was designed to do on a laptop, where nobody connects in. On a server, "capture all traffic" and "stay reachable" are in direct conflict.

Two aggravators worth knowing:

• Kill switches (NordVPN, Surfshark, Proton, Mullvad, and others have them) add firewall rules that block any traffic outside the tunnel. With one active, even correct routing won't save you, inbound RDP is simply dropped.
• redirect-gateway def1 (OpenVPN) doesn't replace your default route, it adds two more-specific routes (0.0.0.0/1 and 128.0.0.0/1) that win against it. route print will still show your original default route, looking innocent, while the /1 pair above it takes all the traffic.

Before you connect: the safety net#

Do these three things before the first connection attempt, they cost two minutes and convert "locked out" into "mildly inconvenienced".

1. Know the Console exists. The out-of-band Console in your client area reaches your VPS's screen without RDP or working networking. Note that on Windows VPS it signs into the VPSDime Support Account's session, a different desktop is normal, sign out and log in as Administrator for your own session.

2. Schedule an undo. Before connecting the VPN, arm a reboot:

   shutdown /r /t 900 /c "VPN experiment safety net"

   If the VPN eats your access, the VPS reboots itself in 15 minutes, and since a freshly installed VPN client doesn't auto-connect at boot unless you've told it to, the reboot comes back clean. If everything works, cancel it with shutdown /a. (Make sure the client's "launch and connect at startup" option is off until you've proven the configuration.)

3. Write down two numbers: your own public IP as the VPS sees it, and the VPS's gateway. Both in one look:

   netstat -n | findstr :3389
   route print 0.0.0.0

   The netstat line shows the established RDP connection, the remote address is your IP. The route print shows the gateway of the public adapter. You'll want both below.

The fix that works with every client: a host route for yourself#

Whatever the VPN does to the default route, a more specific route always wins. Pin the path back to your own IP through the real adapter, and your RDP replies can never be captured by the tunnel:

route -p add 203.0.113.7 mask 255.255.255.255 192.0.2.1 metric 1

Replace 203.0.113.7 with your IP (from the netstat line above) and 192.0.2.1 with the VPS's gateway (from route print). The -p makes it survive reboots. Undo later with route delete 203.0.113.7.

This one line is the universal answer: it works under OpenVPN, WireGuard, and every commercial app, because it operates at the routing layer they're all fighting over. Two caveats:

• A kill switch can still block you at the firewall layer regardless of routes. Turn the kill switch off, on a server you don't want it anyway (a VPN drop on a server should degrade its outbound privacy, not sever its administration).
• If your home IP is dynamic, the route goes stale when your IP changes. Add your current one again (or a broader mask covering your ISP's range if you know it), or rely on split tunneling below instead.

Per-client configuration#

The host route makes you safe. These settings make the client behave properly so you're not depending on it.

OpenVPN#

The server config usually pushes the full tunnel (redirect-gateway def1). Override it on the client, edit your .ovpn file (in C:\Program Files\OpenVPN\config\) and add:

pull-filter ignore "redirect-gateway"

The tunnel comes up, routes to the VPN's own subnets work, but your default route stays put. If you want specific networks through the tunnel, add explicit route lines for them. The heavier alternative, route-nopull, ignores every pushed route, then nothing goes through the tunnel except what you route by hand.

WireGuard#

The full tunnel is spelled AllowedIPs = 0.0.0.0/0 in the peer config, and the Windows app shows a "Block untunneled traffic (kill-switch)" checkbox whenever it sees it, make sure that's unticked on a server. For split tunnel, replace 0.0.0.0/0 with just the networks that belong in the tunnel (for example 10.8.0.0/24, 192.168.100.0/24). With a scoped AllowedIPs, WireGuard never touches your default route at all.

Commercial apps (NordVPN, ExpressVPN, Surfshark, Proton, Mullvad, PIA)#

Every major client has two settings that matter here, the names vary:

• Split tunneling (Surfshark calls it Bypasser): configure it so the tunnel carries only the apps you choose (browser, downloader), rather than "everything except". Inverse-mode ("only selected apps use the VPN") is the server-friendly mode, RDP and system traffic never enter the tunnel.
• Kill switch: off, for the reason above.

And keep "auto-connect on startup" off until the configuration has survived a reboot with RDP intact.

Tailscale and ZeroTier#

Safe by default: they route only their own overlay subnets, not your default route, so RDP keeps working. The exception is Tailscale's exit node feature, telling your VPS to use another machine as exit node is exactly the full-tunnel trap again. Bonus: once the VPS is on your tailnet, you can RDP to its overlay IP, which keeps working even if you later break public routing.

Locked out already? Recovery#

1. Open the Console from your client area (expect the Support Account's desktop; sign out and log in as Administrator).
2. Disconnect the VPN: from the client's own UI, or bluntly, end its process in Task Manager. For Windows' built-in VPN: rasdial "ConnectionName" /disconnect.
3. If RDP is still dead, inspect route print: look for 0.0.0.0/1 and 128.0.0.0/1 entries or a default route pointing at a TAP/WireGuard adapter, and delete the offenders (route delete 0.0.0.0 mask 128.0.0.0 and route delete 128.0.0.0 mask 128.0.0.0). A reboot achieves the same if the client doesn't auto-connect.
4. Before reconnecting the VPN, add the host route and fix the client's settings as above.

A note on the built-in Windows VPN#

If you use Windows' native VPN (IKEv2/SSTP/L2TP) instead of a third-party app, the same trap lives in one checkbox: the connection's "Use default gateway on remote network". Disable it in one line:

Set-VpnConnection -Name "ConnectionName" -SplitTunneling $true

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• which VPN client and whether a kill switch or split tunneling is configured,
• whether the Console works, and what route print shows if you've looked.

Related questions#

• "I connected a VPN on my VPS and lost RDP, how do I get back in?"
• "How do I run a VPN client on my Windows VPS without losing access?"
• "Why does RDP drop the moment my VPN connects?"
• "How do I set up split tunneling on a VPS?"
• "Should the VPN kill switch be on for a server?"
• "How do I stop OpenVPN from taking over the default route?"
• "What does AllowedIPs 0.0.0.0/0 do in WireGuard?"