RDP connection fails with "This computer can't connect to the remote computer"
This error usually means Windows Firewall or Network Level Authentication is blocking your RDP session. Here's the real fix.
Yeah, that error message is about as helpful as a screen door on a submarine. You click Connect, wait a few seconds, and get "This computer can't connect to the remote computer." No code, no hint. Let me save you the back-and-forth with the logs.
The real fix (90% of the time)
Here's what I've fixed in dozens of help desk calls. We're going to check two things: the Windows Firewall rule for Remote Desktop, and the Network Level Authentication setting on the server. You'll need admin rights on the target machine.
- Open Windows Firewall with Advanced Security on the server you're trying to RDP into. Hit
Win + R, typewf.msc, press Enter. - In the left pane, click Inbound Rules. Wait for the list to populate. It might take a few seconds.
- Scroll down until you see rules named Remote Desktop (TCP-In). There should be three of them — one for each profile: Domain, Private, and Public.
- Right-click each rule and check if it's Enabled (green checkmark). If any are disabled, right-click and choose Enable Rule.
- Now double-click the rule for the Private profile. Go to the Advanced tab. Make sure Edge traversal is set to Allow edge traversal. This matters if you're connecting across subnets or VPNs.
- Click OK, then close the firewall window.
- Next, check Network Level Authentication. On the server, hit
Win + R, typesysdm.cpl, press Enter. - Go to the Remote tab. Under Remote Desktop, you'll see two radio buttons. Select Allow remote connections to this computer (the top one). Also, uncheck the box that says Allow connections only from computers running Remote Desktop with Network Level Authentication.
- Click Apply, then OK.
- Now test the connection from your client machine. Open Remote Desktop Connection (
mstsc), type the server's IP or hostname, and click Connect.
After you click Apply and OK on the Remote tab, you should see the settings stick. When you connect, you should see the login prompt. If you get a cert warning, that's normal for workgroup setups — click Yes.
Why this works
The firewall rule for RDP is enabled by default after you install Windows Server, but it can get disabled by group policy, security software, or a manual mistake. If that rule is off, Windows blocks the port — no packets get through. And Network Level Authentication? That feature forces the client to authenticate before the full session starts. Sounds good, but it conflicts with older RDP clients or certain VPN configurations. Disabling it removes that hurdle. Most modern RDP clients still encrypt the session, so you're not losing much security in a controlled network.
Less common variations
Sometimes the fix above doesn't cut it. Here are three other scenarios I've seen:
1. The Remote Desktop service is stopped
On the server, press Win + R, type services.msc, hit Enter. Look for Remote Desktop Services (or TermService on older Windows). Its status should be Running. If it's not, right-click it, click Start. Set its startup type to Automatic by double-clicking it and changing the dropdown.
2. Port 3389 is blocked by a router or cloud firewall
If you're connecting over the internet, your router or cloud firewall (AWS security group, Azure NSG) might block port 3389. Log into your router or cloud console and make sure TCP port 3389 is open to your client's IP. Don't open it to 0.0.0.0/0 — that's a security nightmare.
3. The RDP listener is bound to the wrong IP
On the server, open a command prompt as admin and run:
netsh interface portproxy show all
If you see any portproxy rules, they might misdirect traffic. To remove them, run:
netsh interface portproxy reset
Then restart the Remote Desktop Services service from Services.msc.
How to prevent this from happening again
Prevention is easier than guesswork. Here's what I tell every tech I train:
- Set a GPO for firewall rules. If you're in a domain, push a group policy that enables the Remote Desktop (TCP-In) rule for all domain-joined servers. That way, no manual mess-ups.
- Leave NLA enabled if possible. It's actually more secure. Only disable it if you're stuck with an old RDP client (like on Windows 7 without updates).
- Monitor the Remote Desktop Services service. Set up a simple scheduled task that restarts the service if it stops. PowerShell can do this in four lines.
- Document your firewall changes. Every time you open a port, note why in a change log. Sounds boring, but it saves you hours when someone asks "Who opened 3389 to the world?"
Was this solution helpful?