Port 3389 is the default TCP and UDP port for Microsoft Remote Desktop Protocol, carrying login, screen, and keyboard-mouse data.
If you’ve ever connected to a Windows machine from across the office or across the globe, you’ve used a protocol that relies on a well-known port. That number is 3389. It’s how Remote Desktop clients and servers agree on where to talk by default. Once the handshake starts, your sign-in, your desktop graphics, and your input all flow over that channel.
Port 3389 Basics For Remote Desktop
Remote Desktop Protocol (RDP) listens on a single, predictable endpoint unless you tell it otherwise. On a fresh Windows install with Remote Desktop enabled, the listener binds to TCP 3389 and often also uses UDP 3389 for performance. TCP handles the reliable session; UDP helps with smoother graphics when the network isn’t perfect. Most clients try both and settle on what works.
Why This Port Exists
Every internet service needs a number so two computers can meet without confusion. For RDP, that number is registered as 3389 across TCP and UDP. The assignment lets firewalls, scanners, and admins identify the service quickly. It also means threat actors know where to knock if a system exposes that port to the open internet. More on safety in a bit.
What Actually Moves Through 3389
Think of the connection as a live feed of your screen and inputs. After the client authenticates, the host renders windows, compresses the display, and streams frames back. Your mouse and keyboard events travel the other way. Clipboard copy-paste, printer mapping, drive redirection, and audio can ride along when allowed by policy. The same session number keeps it all in sync.
How Clients Reach A Host
On a local network, you can point the client at a hostname or IP. If you leave the address bare, the app assumes 3389. If the admin changed the listener, you append a colon and the port, like 10.0.0.12:3390. Over the public internet, direct exposure is risky. A safer pattern is to place a gateway in front or require a VPN so 3389 isn’t reachable from the outside world.
Direct, VPN, Or Gateway?
Direct connections work inside a trusted LAN. VPN extends that trust across distance so the client reaches 3389 as if it were local. An RD Gateway terminates TLS on 443 and proxies RDP traffic inside, removing the need to open 3389 on an edge firewall. Many shops use a gateway for any off-site access to reduce the attack surface and keep a single HTTPS hole punched through perimeter filtering.
Security Fundamentals For 3389
RDP can be safe when locked down, and risky when left open. A few smart defaults make a big difference.
Use Network Level Authentication
With NLA, the client proves identity before the session spawns. That blocks anonymous login prompts and cuts resource usage on the host. It also reduces common password-spray noise. On modern Windows, NLA is easy to enforce with a checkbox or Group Policy.
Keep 3389 Off The Public Internet
Attackers mass-scan this port. If the service is reachable, you’ll see password guesses within minutes. Close it on the edge. Use a VPN or an RD Gateway so outside clients come in over 443 and only authenticated users can reach the endpoint. This single move removes a wide class of drive-by attempts.
Harden Accounts And Session Settings
- Require strong MFA wherever possible.
- Limit who can sign in via Remote Desktop.
- Set account lockout and smart throttling to slow automated guessing.
- Disable drive and clipboard redirection if the role doesn’t need them.
- Patch the OS and the Remote Desktop client on a steady cadence.
Should You Change The Port?
Moving the listener to a different number can cut the noise from indiscriminate scans. It does not “fix” exposure on its own. Treat it as a minor measure layered under a VPN or gateway. If you do change it, update firewalls and saved client entries so users don’t get locked out.
Admin Tasks You’ll Do With 3389
Here are sane, low-risk steps for common jobs around the RDP listener. Follow them during a maintenance window so people don’t lose sessions mid-work.
Check Whether The Port Is Listening
On the host, run a quick test to see if the listener is bound and reachable from a client.
On Windows (Client Side)
Test-NetConnection -ComputerName SERVERNAME -Port 3389
# or with IP
Test-NetConnection 203.0.113.25 -Port 3389On Windows (Host Side)
Get-NetTCPConnection -LocalPort 3389 | Where-Object {$_.State -eq 'Listen'}Open The Listener Through Windows Defender Firewall
Windows creates rules for Remote Desktop when you enable it. If you moved the port, add a matching rule for the new number:
New-NetFirewallRule -DisplayName "RDP Custom 3390" -Direction Inbound -Protocol TCP -LocalPort 3390 -Action AllowChange The Listener Only When You Must
If you decide to move from 3389, plan the cutover. Update documentation, client bookmarks, monitoring, and port-forward rules inside the same window. Rebooting the host may be required for the change to take effect.
Practical Designs That Keep You Safe
The best setups avoid exposing RDP straight to the wider internet. Two patterns stand out for small teams and enterprises alike.
VPN First, Then RDP
Users start a VPN that places their device on an internal subnet. Only then can they reach the listener on the target machine. The edge firewall keeps 3389 closed to the outside. Split tunneling can limit what goes through the VPN while still guarding RDP.
HTTPS Gateway In Front
An RD Gateway accepts TLS on 443 and tunnels RDP inside the network. Clients point to the gateway in their settings and never touch 3389 from the public side. This design lines up with standard outbound rules at hotels, cafes, and mobile providers, so connections succeed more often and logs live in one place.
For deeper planning, pair the gateway with MFA and conditional access. Add device checks so only patched, enrolled endpoints can sign in. Keep the gateway in a DMZ and forward only the required traffic to the hosts.
When 3389 Isn’t The Right Choice
You might not want direct host access at all. For one-off admin tasks, remote PowerShell or WinRM wrapped in Just-In-Time access can be safer. For end-user help, a take-control tool that brokers sessions over 443 without opening inbound ports keeps the attack surface small. Pick the method that fits the job rather than defaulting to desktop remoting every time.
Real-World Troubleshooting Tips
Connection fails? Walk this quick path before diving into deep logs.
- Ping the host by name. If name resolution fails, try the IP. Fix DNS if needed.
- Probe the port from the client with the test command above. If it’s closed, check firewalls on both ends.
- Confirm the session limit on the host. A desktop SKU may allow only one active user at a time.
- Check NLA settings. An old client may not handle NLA; update it instead of turning NLA off.
- Review recent patches. A reboot after updates often clears a stuck listener.
Common Questions, Straight Answers
Does RDP Use UDP As Well?
Yes. Many deployments enable UDP 3389 to improve interactive feel. If UDP is blocked, the session falls back to TCP only. You don’t lose reachability; you might feel more latency on high-loss links.
Is Moving Off 3389 Enough?
No. It lowers random scan noise but leaves the service reachable to anyone who knows the new number. Pair any port change with a VPN or gateway, plus strong authentication.
Can I Reach A Non-Default Port From The Client?
Yes. Append a colon and the port to the address field. Save the entry in your client so users don’t forget the suffix the next time.
Safe Defaults You Can Apply Today
- Leave 3389 closed on the edge. Reach hosts through a VPN or an HTTPS gateway.
- Enforce NLA and MFA for every Remote Desktop login.
- Limit Remote Desktop logon rights to the smallest group that needs it.
- Keep host OS and clients patched. Retire outdated ciphers on TLS endpoints.
- Log sign-ins and alert on repeated failures from one source.
- Consider moving the listener to a non-standard port inside the LAN to cut noise, while treating it only as a minor layer.
Port And Method Quick Reference
This compact table sums up the usual ports you’ll meet and when each pattern fits. Keep it as a checklist when you plan access from outside your network.
| Access Method | Ports Exposed | Typical Use |
|---|---|---|
| Direct RDP Inside LAN | TCP 3389, UDP 3389 (internal only) | Office or lab networks with trusted clients; no outside reach. |
| VPN Then RDP | VPN port on edge (varies), 3389 stays internal | Remote staff and admins who first join a private tunnel. |
| RD Gateway | TCP 443 on edge; 3389 inside | Any off-site access through HTTPS with central policy and logs. |
Where To Read Deeper
For port assignments, see the official registry. For Microsoft’s own breakdown of which Windows roles use which ports, read the service-port reference. Both answer nitty-gritty questions and help you line up firewall rules cleanly. Link to those pages sits here so you don’t need to guess:
Takeaway For Admins And Power Users
Port 3389 is the default rendezvous point for Remote Desktop. Keep it inside the network, put a VPN or an HTTPS gateway in front of any remote reach, and turn on NLA with strong auth. When you need to move the listener, treat it as a housekeeping change, not a shield. With these basics in place, remote work stays smooth and far less noisy.