RDP Port 3389: How to Check It, Change It, and Keep It Private

Remote Desktop Protocol (RDP) uses TCP port 3389 by default. Modern RDP can also use UDP on port 3389 to improve responsiveness; TCP remains the baseline. If a connection fails, the useful question isn’t just “Is 3389 open?” but “Is RDP listening, can the client reach it, and is the session allowed?”

First, identify which RDP setup you have

For a regular connection from one computer to another, TCP and UDP 3389 are the main ports to know. A larger Remote Desktop Services (RDS) deployment may involve additional services and ports—for example, an RD Gateway typically receives connections over TCP 443, while a session host can remain behind it on 3389.

If you’re troubleshooting a single Windows PC, start with 3389 rather than opening a collection of ports intended for an RDS farm.

Check the server and the network separately

A port check can tell you whether a network path accepts a connection. It does not prove that RDP authentication or the desktop session will succeed.

On the Windows machine that should accept connections, check for a TCP listener in PowerShell:

Get-NetTCPConnection -LocalPort 3389 -State Listen

On a Linux machine running an RDP server such as xrdp, you can check the TCP listener with:

ss -tlnp | grep 3389

If there’s no listener, investigate whether Remote Desktop or the relevant service is enabled and bound to that port. Opening a firewall rule won’t help if nothing is listening.

Then test from the client machine. In PowerShell:

Test-NetConnection -ComputerName pc1.example.com -Port 3389

On macOS or Linux, test the TCP connection with:

nc -zv pc1.example.com 3389

A successful TCP test means the TCP path is reachable from that client. It doesn’t verify UDP, credentials, permissions, or whether RDP will accept a session. For a broader checklist of firewall layers and why an allowed port may still be unreachable, see this guide to opening ports across Windows, Linux, routers, and cloud firewalls.

If the machine is behind a home or office router, a separate NAT or port-forwarding rule may affect external access. Cloud security groups can be another independent layer. Check these only when they apply to your network; don’t assume a local firewall rule makes a service reachable from outside.

Connect on a custom port

If the RDP host is listening on a different port, specify it after the hostname or IP address in Remote Desktop Connection:

mstsc /v:pc1.example.com:3390

You can also enter pc1.example.com:3390 in the app’s Computer field. The server configuration, firewall rules, and any network forwarding in between must all agree on the intended port.

Changing the Windows listening port

Changing the port involves more than editing the registry: you also need inbound firewall rules for the new port. The following example changes the configured port to 3390. Run the commands in an elevated PowerShell session on the RDP host:

# Check the current port
Get-ItemProperty `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name 'PortNumber'

# Set a new port
$portValue = 3390
Set-ItemProperty `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name 'PortNumber' `
  -Value $portValue

# Allow the new port through Windows Firewall
New-NetFirewallRule -DisplayName 'RDP-Custom-TCP-In' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3390
New-NetFirewallRule -DisplayName 'RDP-Custom-UDP-In' -Direction Inbound -Action Allow -Protocol UDP -LocalPort 3390

Scope firewall rules to the appropriate network profile instead of allowing access on Public by default. Where possible, restrict access further to trusted source IP addresses or a private network. If you connect from outside the local network, the router or cloud firewall may also need an updated rule.

Changing the registry value and adding rules doesn’t guarantee the service is already listening on the new port. Verify the listener and test from the client before relying on the change. Keep an existing way to administer the machine while you check connectivity so a configuration mistake doesn’t cut off your access.

Don’t expose RDP directly to the internet

An open RDP port can attract automated scans, and compromised RDP credentials are a known route into Windows systems. Changing 3389 to another number is not a meaningful security boundary: it may reduce noise from scanners that only check the default port, but it doesn’t stop broader scans or protect weak or reused credentials.

A safer pattern is to keep RDP off the public internet and require access through a VPN or RD Gateway. Use strong, unique credentials and Network Level Authentication (NLA) where appropriate. Treat a custom port as a configuration choice, not a substitute for controlling who can reach the service.

When TCP connects but Remote Desktop still fails

If Test-NetConnection succeeds but the desktop session is rejected, the network path may be working while a later RDP check fails. Verify that:

• The account is permitted to sign in through Remote Desktop. Standard users may need to be added to Remote Desktop Users; policies can affect this.
• The client and server can meet the server’s NLA requirements.
• The machine’s Windows edition and session limits allow the connection you’re attempting. Non-server Windows editions typically allow only one interactive session at a time.
• If this is an RDS deployment, check for licensing issues as well as the additional services in that setup.

The practical order is: confirm a listener on the host, test TCP reachability from the client, then investigate RDP permissions and session requirements. That keeps a successful port check in perspective: it confirms one part of the connection, not the whole remote desktop session.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.