Windows VPS RDP Setup: Fix Connection Errors, Lock It Down

If you just spun up a Windows VPS, chances are you're staring at either a stubborn "can't connect" error in Remote Desktop Connection, or you're wondering why your Security event log is full of failed logon attempts from IP addresses you've never seen. Both are normal first-week problems. Here's how to fix the connection and then lock the door before someone else walks through it.

Symptom: "This computer can't connect to the remote computer"

You open mstsc, type in your VPS IP, and get one of these:

• "This computer can't connect to the remote computer. Try connecting again..."
• "An authentication error has occurred. The function requested is not supported" (CredSSP-related)
• The connection just hangs and times out with no error at all

Cause

Nine times out of ten it's one of these:

• Windows Firewall on the VPS is blocking inbound RDP (TCP 3389) — common right after a fresh OS reinstall, since some providers ship images with the firewall re-enabled by default
• Your hosting provider's network-level firewall or security group hasn't opened 3389 for your IP
• The Remote Desktop service isn't actually enabled on the server
• A CredSSP patch mismatch — your local Windows is more recently patched than the server (or vice versa) and the encryption oracle fix rejects the handshake
• You're using the wrong port, if a previous admin already changed RDP off 3389 for security

Fix

Start from the server side using your provider's web console (VNC/KVM access), since if RDP is fully blocked you won't be able to get in via RDP itself to fix RDP.

1. Confirm Remote Desktop is on: System Properties → Remote tab → "Allow remote connections to this computer" checked.
2. Check Windows Defender Firewall has an inbound rule for "Remote Desktop - User Mode (TCP-In)" enabled, or run:

   netsh advfirewall firewall set rule group="remote desktop" new enable=yes

3. From PowerShell, verify the service is actually listening:

   Get-Service TermService
   netstat -an | findstr :3389

   You want to see TermService running and a line like 0.0.0.0:3389 LISTENING.
4. If it's a network firewall issue, check your VPS provider's control panel for a security group or firewall page and confirm TCP 3389 (or your custom port) is open to your IP, not just "internal" traffic.
5. For the CredSSP error, patch both ends. As a temporary workaround only, you can loosen the encryption oracle policy on your local machine via gpedit.msc → Computer Configuration → Administrative Templates → System → Credentials Delegation → Encryption Oracle Remediation, setting it to Vulnerable — but treat this as a stopgap, not a permanent fix, and revert once both machines are patched.

Symptom: hundreds of failed RDP logon attempts in Event Viewer

Open Event Viewer → Windows Logs → Security, filter for Event ID 4625, and you'll likely see a wall of failed logon attempts, often from usernames like administrator, admin, or test, hitting you every few seconds. This isn't a targeted attack on you specifically — it's automated bots scanning every public IP on the internet for open port 3389.

Why this matters

RDP brute-force is one of the most common ways Windows servers get compromised, especially when the built-in Administrator account is left enabled with a guessable password. Once an attacker is in, they typically drop a coin miner, a ransomware payload, or use the box to launch further attacks — and by the time you notice, it's a rebuild, not a cleanup.

Fix: lock it down properly

Do these in order — each one closes a different door.

1. Move RDP off port 3389

This doesn't stop a determined attacker, but it drops you out of most automated scans overnight. In the registry:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber -Value 33890
New-NetFirewallRule -DisplayName "RDP Custom Port" -Direction Inbound -Protocol TCP -LocalPort 33890 -Action Allow
Restart-Service TermService -Force

Pick any port in the 20000–50000 range that isn't already used, update your firewall rule to match, and remember to connect using ip:33890 going forward.

2. Rename or disable the built-in Administrator account

Rename-LocalUser -Name "Administrator" -NewName "svc-adm-9284"

Create a new admin-level account with a non-obvious name instead of using the default one — this alone kills most credential-stuffing attempts, since they're all guessing "Administrator" as the username.

3. Enforce account lockout policy

Under Local Security Policy → Account Policies → Account Lockout Policy, set:

This turns an unlimited brute-force attempt into a slow, mostly useless one.

4. Require Network Level Authentication (NLA)

NLA forces authentication before a full RDP session is established, which blocks a large class of pre-auth exploits. It's usually on by default, but confirm it under System Properties → Remote → "Allow connections only from computers running Remote Desktop with Network Level Authentication."

5. Restrict access by IP where you can

If you or your team connect from a small number of fixed office/home IPs, lock the firewall rule down to just those:

New-NetFirewallRule -DisplayName "RDP - Office Only" -Direction Inbound -Protocol TCP -LocalPort 33890 -RemoteAddress 203.0.113.10,203.0.113.11 -Action Allow

Then remove or disable the broader "Any" rule. If your team's IP changes often, a VPN or bastion host in front of RDP is a better long-term answer than opening it to the world.

6. Turn on brute-force protection at the OS level

Windows Server 2022 and newer includes built-in RDP brute-force mitigation via Windows Defender Firewall's Account Lockout policies, and there are also lightweight third-party tools like RDPGuard or IPBan that watch the Security log and auto-block IPs after repeated failures — similar in spirit to fail2ban on Linux, if you're used to that from cPanel/VPS work.

Prevention checklist

• Change the default RDP port on every new Windows VPS as part of your first-hour setup, not as an afterthought
• Never leave the built-in Administrator account active with RDP exposed
• Patch Windows monthly — most RDP-adjacent exploits (like BlueKeep) target unpatched servers specifically
• Keep a snapshot or backup before making firewall/registry changes, so a typo doesn't lock you out entirely
• Log RDP access in a shared doc if more than one person connects, so you can spot an unfamiliar session fast

If you manage a Windows VPS through Getwebup and get locked out after a firewall change, don't panic — reach the box through the web-based console/KVM in your control panel (it bypasses the network stack entirely) and roll back the rule from there.