RDP port: 3389 on TCP and UDP, the RD Gateway ports, and how to check them

Short answer: Remote Desktop (RDP) listens on TCP port 3389 by default, and on current Windows versions also on UDP port 3389. TCP is the one you cannot do without; UDP is an optional faster transport, and when it is blocked RDP simply stays on TCP. An RD Gateway, if you run one, takes TCP 443 and UDP 3391 instead, and nothing else (135, 139, 445) is needed for a client to reach a server.

IANA lists 3389 under the service name ms-wbt-server for both TCP and UDP, which is why tools like nc and Nmap print that name instead of “RDP”. The number is only a default: an administrator can move it, and then every client has to name the new port. Moving it is covered step by step in how to change the RDP port; this page is about finding out which ports are in play, testing them and keeping them safe.

Is RDP TCP or UDP?

Both, in a fixed order. The client always opens TCP 3389 first. Over that connection the server offers a second transport over UDP, secured with TLS or DTLS, and once the UDP handshake succeeds the bulk of the traffic, screen updates above all, moves to UDP while the TCP connection stays open. Microsoft’s protocol documentation calls this the multitransport extension; the UDP channel is never set up on its own. That has two practical consequences:

• Block UDP 3389 and RDP still works. It falls back to TCP only, which feels slower on lossy Wi-Fi or mobile links but is otherwise identical.
• Block TCP 3389 and nothing works. UDP alone cannot start a session, so a firewall rule for UDP only is useless.

The UDP transport arrived with RDP 8.0 in Windows 8 and Windows Server 2012 (Windows 7 SP1 got it through an update). On current Windows Server and Windows client versions it is on by default on both ends. A Group Policy can switch it off: on the server it is Select RDP transport protocols under Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections. To see whether someone set it:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name SelectTransport -ErrorAction SilentlyContinue

No output means the policy is not set and UDP is allowed. SelectTransport : 1 means “Use only TCP” is enforced (0 and 2 allow UDP). A client can opt out on its own as well: the client policy “Turn Off UDP On Client” sets fClientDisableUDP under the same key’s Client subkey, a common workaround when sessions freeze over a flaky UDP path. During a full-screen session, the signal-strength icon on the connection bar opens a dialog that says whether UDP is enabled. On the server, every accepted connection is logged with its transport and the client’s address:

Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational'; Id = 131 } -MaxEvents 10 |
    Format-List TimeCreated, Message

Event 131 reads “The server accepted a new TCP connection from client…” or the same with UDP. It is logged before any login, so on a server with 3389 open to the internet it also lists every stranger’s address that knocks.

Which ports does RDP not need?

Several “RDP ports” lists add TCP 135, 139 and 445 for printer and drive redirection. That is not how redirection works. Drives, printers, the clipboard, audio and smart cards travel as virtual channels inside the RDP connection on 3389, so a client with only 3389 reachable gets all of them. The RPC and SMB ports appear in Microsoft’s list of RDS ports for traffic between servers of a Remote Desktop Services deployment: Session Hosts talking to the license server, the Connection Broker and Active Directory. On a single Windows server you reach from home, opening them only exposes SMB and RPC to the internet, which you never want.

The same goes for ICMP: ping is handy for diagnosis, but RDP does not use it, and a server that ignores ping can still accept Remote Desktop.

How to check which port RDP listens on

The registry holds the configured port; the socket table shows what is listening right now. Check both, in the console or an existing RDP session:

# the configured port (a decimal number)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber

# what is actually listening, TCP and UDP
Get-NetTCPConnection -LocalPort 3389 -State Listen
Get-NetUDPEndpoint -LocalPort 3389

PortNumber   : 3389

LocalAddress LocalPort RemoteAddress RemotePort State  AppliedSetting OwningProcess
------------ --------- ------------- ---------- -----  -------------- -------------
::           3389      ::            0          Listen                1052
0.0.0.0      3389      0.0.0.0       0          Listen                1052

LocalAddress LocalPort
------------ ---------
::           3389
0.0.0.0      3389

If PortNumber shows another value, use that number in the next two commands. If the registry and the socket table disagree, the port was changed but Remote Desktop Services has not been restarted yet; the socket table is what clients meet. No TCP line at all means Remote Desktop is switched off or its service is not running. If TCP listens but UDP does not, check the transport policy above.

The classic command works too, in Command Prompt or PowerShell:

netstat -ano | findstr :3389
tasklist /svc /fi "SERVICES eq TermService"

  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1052
  TCP    [::]:3389              [::]:0                 LISTENING       1052
  TCP    192.0.2.10:3389        198.51.100.23:50412    ESTABLISHED     1052
  UDP    0.0.0.0:3389           *:*                                    1052
  UDP    [::]:3389              *:*                                    1052

Image Name                     PID Services
========================= ======== ============================================
svchost.exe                   1052 TermService

The last column of netstat is the process ID, and tasklist confirms it belongs to TermService, the Remote Desktop Services service, which runs inside an svchost.exe process. An ESTABLISHED line from an address that is not yours is someone else’s client connected or trying to log in. Note that findstr :3389 also matches ports such as 33890, so read the numbers.

Then check which ports the firewall actually lets in. The built-in rule group is called “Remote Desktop” on English systems:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
    Where-Object Enabled -eq True |
    Get-NetFirewallPortFilter |
    Format-Table Protocol, LocalPort

You want to see TCP and UDP with the port from the registry. A line with TCP and Any is the “Remote Desktop - Shadow” rule, which is tied to the shadowing program RdpSa.exe rather than to a port. If RDP runs on another port, the built-in rules no longer match it and you need rules of your own, as in the change-port guide.

How to test the RDP port from outside

A port that listens on the server can still be blocked on the way. Test from your own computer, replacing YOUR_SERVER_IP with the server’s public address and 3389 with its port:

Test-NetConnection YOUR_SERVER_IP -Port 3389
# shortcut for 3389 only:
Test-NetConnection YOUR_SERVER_IP -CommonTCPPort RDP

nc -vz -G 5 YOUR_SERVER_IP 3389

nc -vz -w 5 YOUR_SERVER_IP 3389

• TcpTestSucceeded : True, or an nc line ending in [tcp/ms-wbt-server] succeeded!: the path is open. If login still fails, the problem is credentials, NLA or the client.
• Connection refused (nc answers at once): the server answered but nothing listens on that port. Remote Desktop is off while its firewall rule is still open, or it listens on another port.
• Timed out (nc waits the full five seconds): something drops the packets. That is a firewall on the server or at the provider, a wrong IP, or your own network blocking outgoing 3389, which hotels and company networks often do.

Test-NetConnection prints TcpTestSucceeded : False in both failure cases, so it cannot tell a refusal from a drop; nc can.

Without a terminal, the open port checker runs the same TCP test from our server in Amsterdam against any public IP address (not a host name) and port. If you have already limited 3389 to your own address, expect “no answer” there: that is the rule working. None of these tools can prove a UDP port open: UDP has no handshake, so silence looks the same whether the port is open or filtered. Confirm UDP from the session dialog or event 131 instead. When the test fails and you need the full checklist, Remote Desktop can’t connect goes through it in order.

How to connect to RDP on a non-default port

Every client takes the port after the address, separated by a colon. Without it, the client tries 3389.

mstsc /v:YOUR_SERVER_IP:13389

# Debian 12: xfreerdp (FreeRDP 2) · Debian 13, Ubuntu 24.04: xfreerdp3
xfreerdp3 /v:YOUR_SERVER_IP:13389 /u:Administrator

• Remote Desktop Connection (Windows): type YOUR_SERVER_IP:13389 in the Computer field. A saved .rdp file keeps it as full address:s:YOUR_SERVER_IP:13389.
• macOS, iPhone, iPad, Android: Microsoft’s Windows App, which replaced the Microsoft Remote Desktop app. Choose + → Add PC and enter YOUR_SERVER_IP:13389 as the PC name.
• Remmina (Linux): new RDP profile, server YOUR_SERVER_IP:13389.
• IPv6: put the address in brackets, [2001:db8::10]:13389, so the colons of the address are not read as the port separator.

Replace 13389 with the port your server uses. Through an RD Gateway, the client talks to the gateway on 443 and names the target separately: mstsc /v:SERVER /g:GATEWAY.

Restrict port 3389 to your own IP

An open 3389 is found quickly by the scanners that sweep the whole internet, and then receives password guesses around the clock. The single most effective fix is to let only your own addresses reach it. Your current public address is shown by the what is my IP tool.

# replace with your own address(es); ranges like 192.0.2.0/24 also work
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -RemoteAddress YOUR_IP

# check the result
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Get-NetFirewallAddressFilter |
    Format-Table RemoteAddress

This narrows the built-in TCP and UDP rules together. Two things undo it silently. One is a second rule that opens the same port to everyone, which this lists:

Get-NetFirewallPortFilter | Where-Object LocalPort -eq 3389 | Get-NetFirewallRule |
    Format-Table DisplayName, Enabled, Direction, Action

The other is a separate “block” rule: in Windows Firewall a block rule beats every allow rule, including yours. Narrow the allow rule; do not add a block rule next to it. If you moved RDP to another port, use that number above and narrow your own rules by name instead of the group, for example the two rules the change-port guide creates:

Set-NetFirewallRule -DisplayName "RDP 13389 TCP", "RDP 13389 UDP" -RemoteAddress YOUR_IP

Does changing the RDP port make it secure?

No. A different port takes you off the list of the laziest bots, and the log gets quieter. A scan of all 65,535 ports still finds the listener and identifies it as RDP, and a weak password is just as weak on port 13389. What actually keeps an RDP server safe:

• A source allowlist, as above. It removes password guessing from the picture.
• No public port at all. Reach RDP through a VPN or an SSH tunnel to 127.0.0.1:3389 on the server, or through an RD Gateway on 443, and close 3389 from outside.
• Network Level Authentication on. It is the default and makes the client authenticate before Windows builds a login screen. The registry value UserAuthentication in the same RDP-Tcp key should be 1.
• An account lockout policy. net accounts shows the current values. Installations set up with the October 2022 updates or later already lock an account for 10 minutes after 10 failed attempts; if yours says Lockout threshold: Never, set it with net accounts /lockoutthreshold:10 /lockoutwindow:10 /lockoutduration:10. The built-in Administrator is only covered when the policy “Allow Administrator account lockout” is enabled, and even then the lockout applies to network logons such as RDP only, so the VNC console still gets you in.
• Updates. Several serious RDP flaws needed no password at all; BlueKeep (CVE-2019-0708) let anyone who reached 3389 run code on unpatched Windows 7 and Server 2008 R2 machines.

If you want a Windows server where you set all of this yourself, a Windows VPS gives you the Administrator account with Remote Desktop on the default port 3389, and the Windows RDP plans run in Amsterdam and Frankfurt with a VNC console in the panel for the moment a firewall rule goes wrong.

Frequently asked