RDP connects only on the fifth try: how we found the culprit and secured the server against hacking in 15 minutes.

RDP Connects Only After Several Attempts: How to Diagnose and Secure Your Windows Server

If your Windows server accepts an RDP connection only after several attempts, or an active session frequently disconnects and reconnects, the problem may not be your Internet connection or the server itself.

One possible cause is a large number of automated login attempts against publicly accessible RDP and SSH ports.

In this example, a Windows VPS received more than 3,000 failed RDP login attempts in three days. Restricting access by IP address and moving RDP away from the default port resolved the connection problems.

Symptoms

The Windows VPS was running continuously with browser automation, scripts, and other services.

However, remote access became unstable:

• RDP connections succeeded only after 2–5 attempts.
• Active RDP sessions occasionally disconnected and immediately reconnected.
• SSH connections used by scripts also started failing with errors such as Connection reset by peer and Connection closed.

At the same time, the server itself appeared healthy:

• CPU usage was normal.
• Memory usage was normal.
• There was no packet loss.
• Network latency was stable.

Step 1. Check RDP Connection Logs

Windows includes built-in event logs that can help identify incoming Remote Desktop connections.

Open PowerShell as Administrator and run:

# Show RDP connections from the last 3 days
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational'
    Id        = 131
    StartTime = (Get-Date).AddDays(-3)
} | Select-Object TimeCreated, Message -First 50

Event ID 131 shows when the RDP service accepts a new TCP connection from a client.

You can also check the number of failed Windows logins using Security event ID 4625:

(Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-3)
}).Count

What We Found

In this case, the logs showed:

• 3,231 failed RDP login attempts in three days.
• 1,605 failed SSH login attempts in one day.
• New connection attempts arriving every few seconds from many different IP addresses.
• Repeated connect, disconnect, and reconnect events for the legitimate RDP user.

The RDP and SSH services were continuously processing unwanted connection attempts while the legitimate user was trying to connect.

Why This Happened

The server was expected to be protected by the provider-side network filter.

However, testing showed that the standard ports were still accessible from the Internet:

• RDP: TCP/UDP port 3389
• SSH: TCP port 22

The default Windows Firewall rules for Remote Desktop and OpenSSH also allowed connections from any remote address.

Important: Do not assume that a port is inaccessible simply because a network filter is configured in a provider control panel. Always verify access from an external network.

Step 2. Restrict RDP and SSH by IP Address

The most effective protection in this scenario is to allow RDP and SSH only from trusted IP addresses.

For example:

• Your home IP address
• Your office IP address
• Another trusted server
• Your VPN subnet

Open PowerShell as Administrator.

Define the addresses that should be allowed:

$allowed = @(
    '203.0.113.10',
    '198.51.100.20',
    '10.10.10.0/24'
)

Replace these example addresses with your actual trusted IP addresses.

Then apply the whitelist to the RDP and OpenSSH firewall rules:

foreach ($rule in 'RemoteDesktop-UserMode-In-TCP',
                         'RemoteDesktop-UserMode-In-UDP',
                         'OpenSSH-Server-In-TCP',
                         'sshd') {

    Set-NetFirewallRule `
        -Name $rule `
        -RemoteAddress $allowed `
        -ErrorAction SilentlyContinue
}

Windows Firewall should normally be configured to block unsolicited inbound connections by default.

With this configuration, connections from addresses that are not included in the whitelist will be blocked before they reach the RDP or SSH service.

Step 3. Change the Default RDP Port

The IP whitelist provides the primary access restriction.

You can also move RDP away from the default port 3389 to reduce unwanted connection attempts from automated scanners.

Important: Make sure the new port is allowed in Windows Firewall before restarting the Remote Desktop service. Incorrect firewall configuration may prevent you from reconnecting to the server.

First, choose an available port.

For example:

$port = 50000

You can replace 50000 with another available TCP/UDP port.

Change the RDP port in the Windows Registry:

Set-ItemProperty `
    'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
    -Name PortNumber `
    -Value $port

Create firewall rules for the new port:

New-NetFirewallRule `
    -Name "RDP-$port-TCP" `
    -DisplayName "RDP $port (whitelist)" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort $port `
    -RemoteAddress $allowed `
    -Action Allow

New-NetFirewallRule `
    -Name "RDP-$port-UDP" `
    -DisplayName "RDP $port UDP (whitelist)" `
    -Direction Inbound `
    -Protocol UDP `
    -LocalPort $port `
    -RemoteAddress $allowed `
    -Action Allow

Restart the Remote Desktop Services service:

Restart-Service TermService -Force

Important: Your current RDP connection will be disconnected when the service restarts.

After changing the port, connect using:

SERVER_IP:PORT

For example:

203.0.113.100:50000

Step 4. Configure a Backup Access Method

If you restrict RDP access to your home or office IP address, remember that your public IP may change.

If that happens, the whitelist may prevent you from connecting.

For this reason, it is recommended to prepare an alternative access method before applying strict firewall rules.

For example:

• A VPN connection such as WireGuard
• Another trusted server with a static IP address
• Provider VNC or recovery console access

The backup access method should use an IP address or network that is already included in the whitelist.

Step 5. Verify the Result

After applying the changes, check the configuration from both an allowed and an unauthorized network.

Verify that:

• RDP works from your trusted IP address.
• The new RDP port is accessible.
• The old port 3389 is no longer publicly accessible if it is no longer required.
• Connections from unauthorized IP addresses are blocked.
• The RDP event log no longer contains continuous unwanted connection attempts.
• SSH connections remain stable.

In the example described here, after applying the restrictions:

• The server accepted the legitimate RDP connection on the first attempt.
• RDP sessions stopped disconnecting unexpectedly.
• SSH sessions became stable.
• Unwanted connection attempts stopped reaching the services.

Additional Security Recommendations

You can further improve server security with the following measures:

• Use SSH keys instead of passwords. If possible, disable password authentication for SSH.
• Use a strong Administrator password. An IP whitelist should not replace strong authentication.
• Keep a recovery access method available. VNC or another provider console can help if Windows Firewall blocks your normal connection.
• Monitor failed login attempts. Periodically review Windows Security and Remote Desktop event logs for unusual activity.

Conclusion

If RDP connects only after several attempts or frequently disconnects, check whether the server is receiving a large number of unwanted connection attempts.

In this case, the problem was caused by RDP and SSH being accessible from the public Internet while automated systems continuously attempted to connect.

Restricting RDP and SSH to trusted IP addresses and moving RDP away from the default port eliminated the unwanted traffic and restored stable remote access.