RDC Port 3389: Find, Change, and Test Windows Remote Desktop

Posted on 2026-06-30 by Sam Snider

The default RDC port is TCP 3389. Windows Remote Desktop uses this listening port when the service is enabled, the device is reachable, and the connecting account passes the required authentication checks. A custom port can be configured, but the service, Windows Firewall, NAT forwarding, client command, and verification tests must all use the same value.

The standard change is to update the PortNumber value under the RDP-Tcp registry key, restart Remote Desktop Services, permit the new port, and connect with syntax such as mstsc.exe /v:server.example.com:3390.

Understand the default RDC port and connection path

Confirm 3389 and the listening interface

TCP 3389 is the default listening port for Windows Remote Desktop. Some RDP connections can also use UDP 3389 for transport performance, but TCP is the essential listener to check when determining whether the service is accepting connections.

On the Windows computer hosting Remote Desktop, run PowerShell as an administrator and check the service:

Get-Service -Name TermService

The service should show a status of Running. The service status alone does not prove that the expected port is listening. Check the socket separately:

Get-NetTCPConnection -State Listen -LocalPort 3389

Alternatively, use:

netstat -ano -p tcp | findstr “:3389”

A result such as 0.0.0.0:3389 or [::]:3389 indicates that the listener is bound to all IPv4 or IPv6 interfaces. A specific local address indicates that the listener is bound to that interface. No result usually means that the service is stopped, the port has been changed, or the listener failed to start.

The connection path normally has these stages:

The client resolves the server name to an IP address.
The client opens a TCP connection to port 3389 or the configured custom port.
Network devices and NAT forward the connection to the Windows host when the server is not directly reachable.
Windows Firewall permits or blocks the inbound port.
Remote Desktop Services accepts the connection and applies authentication, authorization, and session policies.

Separate port changes from Remote Desktop access

Changing the port does not enable Remote Desktop. The Remote Desktop feature must already be enabled, and the fDenyTSConnections setting, local policy, or organizational policy must allow incoming connections. Authentication requirements, Network Level Authentication, user rights, account status, and session limits are separate controls.

A listening socket also does not prove network reachability. A local check can succeed while a firewall, router, security group, VPN route, or NAT rule blocks the same port from a remote client. These conditions should be tested independently so that a port configuration problem is not confused with an access or routing problem.

Use the RDP command line with host:port syntax

Connect with mstsc.exe

The built-in Remote Desktop client accepts a server name or IP address followed by a colon and port number. The basic rdp command line syntax is:

mstsc.exe /v:server.example.com:3390

For the default port, the port suffix can be omitted:

mstsc.exe /v:server.example.com

The same syntax works with an IPv4 address:

mstsc.exe /v:192.0.2.25:3390

When using an IPv6 address, enclose the address in brackets so the final colon clearly separates the address from the port:

mstsc.exe /v:[2001:db8::25]:3390

The port belongs after the host supplied to the /v: option. A space between the option and the host, such as /v: server.example.com:3390, is not the standard syntax.

Other useful options can be added when needed. For example, /admin requests an administrative session where permitted, and /f opens the session full screen:

mstsc.exe /v:server.example.com:3390 /admin

The command selects the endpoint; it does not bypass firewall rules, authentication, certificate checks, or user permissions.

Test the endpoint before changing service settings

From the intended client computer, test TCP reachability with PowerShell:

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

For a custom port, replace 3389 with the configured value:

Test-NetConnection -ComputerName server.example.com -Port 3390

A result with TcpTestSucceeded : True confirms that the client reached a TCP listener at that host and port. It does not confirm that the RDP login will succeed. A false result points to a listener, firewall, routing, DNS, or NAT issue rather than an RDP credential issue.

Run the test from outside the server when checking a real network path. Testing localhost or the server’s own address confirms only local behavior and may not expose an external firewall or NAT problem.

Change the RDP port in the registry

Edit the PortNumber value

The rdp port registry setting is stored in the PortNumber DWORD value under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Using Registry Editor, open regedit, browse to that path, and select PortNumber. Choose Decimal before entering the new value, such as 3390. Registry Editor may otherwise display the number in hexadecimal, which can make a correct value appear different.

PowerShell provides a direct method for reading and changing the value. First, record the current setting:

$path = ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’

Get-ItemPropertyValue -Path $path -Name PortNumber

To change the port to 3390:

Set-ItemProperty -Path $path -Name PortNumber -Value 3390

The existing value should remain a REG_DWORD. The port must be an available TCP port from 1 through 65535, and it should not conflict with another service on the host. A high, unused port can reduce accidental collisions, but it does not replace authentication or network security controls.

Changing the registry while Remote Desktop is running does not instantly move an existing listener. The old port can remain active until the service is restarted, and clients will continue to use the old port until their connection command or saved configuration is updated.

Restart the service and keep a rollback path

After changing PortNumber, restart Remote Desktop Services:

Restart-Service -Name TermService -Force

Restarting the service can disconnect active Remote Desktop sessions. A planned server restart also applies the setting, but a service restart is usually sufficient and makes the timing of the change clearer.

Before editing the registry, export the RDP-Tcp key or record the original value. For example:

reg export “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” “C:\Temp\RDP-Tcp-backup.reg” /y

To roll back a change, restore PortNumber to 3389, restart TermService, and return the firewall and NAT rules to their previous port. The rollback should be performed through console access or another management path if the new port makes Remote Desktop temporarily unreachable.

Update firewall and NAT rules, then verify the RDP listener

Align Windows Firewall and NAT

The built-in Remote Desktop firewall rules commonly allow the default port. They do not necessarily follow a registry change automatically. Inspect the existing rules and their port filters:

Get-NetFirewallRule -DisplayGroup “Remote Desktop” | Get-NetFirewallPortFilter

If the custom port is not allowed, create an inbound rule for the appropriate network profiles. This example allows TCP 3390 on Domain and Private profiles:

New-NetFirewallRule -DisplayName “Remote Desktop TCP 3390” -Direction Inbound -Protocol TCP -LocalPort 3390 -Action Allow -Profile Domain,Private

The profiles and source-address scope should match the server’s actual network design. If RDP UDP transport is also required, create a separate UDP rule for the same port after confirming that the network path supports it:

New-NetFirewallRule -DisplayName “Remote Desktop UDP 3390” -Direction Inbound -Protocol UDP -LocalPort 3390 -Action Allow -Profile Domain,Private

Do not assume that changing a Windows Firewall rule changes an upstream firewall or router. For a server behind NAT, forward the selected external port to the Windows host’s selected internal port. If both are 3390, forward TCP 3390 to TCP 3390. If the router translates an external port such as 443 to internal port 3390, the client must use the external form, such as:

mstsc.exe /v:remote.example.com:443

The Windows listener and local firewall still use 3390 in that example. NAT translation must therefore be documented separately from the port configured on the server.

Verify the service and listening socket

After the restart and firewall update, verify the complete path in order. On the Windows host, confirm the service and new listener:

Get-Service -Name TermService

Get-NetTCPConnection -State Listen -LocalPort 3390

Or use:

netstat -ano -p tcp | findstr “:3390”

The expected result is a listening entry on the new port. A remaining listener on 3389 may indicate that the registry value was edited in the wrong location, the service was not restarted, or another application owns that port. Confirm the configured value directly:

Get-ItemPropertyValue -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’ -Name PortNumber

From a remote client, test the new endpoint:

Test-NetConnection -ComputerName server.example.com -Port 3390

Then make a real RDP connection:

mstsc.exe /v:server.example.com:3390

If the local listener exists but the remote TCP test fails, inspect Windows Firewall, upstream firewall rules, routing, security groups, and NAT forwarding. If the TCP test succeeds but the RDP session is rejected, investigate Remote Desktop enablement, Network Level Authentication, account permissions, certificates, and session policy rather than changing the port again.