Changing Terminal Server/Remote Desktop listening port on Server 2008

Two questions:
1. What is the best way to change the Terminal Server/Remote Desktop listening port on Windows Server 2008 and Windows Server 2012 from Port 3389 to something else?

2. Any recommendations on what port number to change it to or does it matter?

Who is Participating?
Start Registry Editor.
Locate and then click the following registry subkey:
On the Edit menu, click Modify, and then click Decimal.
Type the new port number, and then click OK.
Quit Registry Editor.
Restart the computer.

The better way to do it is to keep the existing port and then do NAT translation from WAN to LAN on your router (assuming it supports it) and use a high numbered random port.  If you are changing you can use any number up to 65535.
Tony GiangrecoCommented:
Yes, you can change the port to 3390 or possibly a much higher port, but hackers will still try scanning for open ports and try logging in.

If that is your problem, I suggest installing a Firewall like a Sonicwall TZ210 or 215. After that, setup port translation from a port like 15000 to 3389 or 3390 so hackers can't determine what port to use.  This is what I did for our 2008 R2 terminal/RDP Server and it worked very well.

If you just want to change the port, here is how to do it
b1dupreeAuthor Commented:
Thanks.  Can you confirm that SBS 2008 uses port 443 for Terminal Server traffic so if I do port translation on the SonicWall I forward the traffic from the new port (15000) that I created on the SonicWall to port 443 (secure web)?
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Cliff GaliherCommented:
SBS uses 3389 for RDP traffic just like any other OS when left to defaults.

SBS *does* include the RDGateway role (which is available as a standalone role with other server editions as well). The RDGateway role acts, as the name implies, as a gateway and allows a compatible and properly configured RDP client to request a machine behind the gateway. The actual RDP traffic is tunneled over 443 to the gateway, but then the gateway establishes the RDP connection via 3389 (including to SBS itself) as normal.

The RDGateway port *cannot* be changed, and attempting to do so will break other services that also rely on and use 443, such as RWA. As pointed out, port scanning is trivial so changing the listening port adds little to no security. Strong passwords and intrusion monitoring are a far better and more reliable defense.
b1dupreeAuthor Commented:
Okay.  So, on an SBS server, if I use Port Translation with the SonicWall am I forwarding traffic from the new port that I created on the SonicWall to port 443 or port 3389?
Cliff GaliherCommented:
That depends on what you are trying to accomplish.

If you *really* want to have your SBS server's RDP service exposed directly to the web, then you want to forward port 3389. This, however, is terribly insecure and not something I'd *ever* do. You'd be far better off using RWA to access the server, which uses the RDGateway service (so 3389 is never *directly* exposed) and has been hardened.

If you are trying to change the port that RWA (or more specifically RDGateway) uses, then the simple answer is that you can't. The RDGateway service and clients that understand RDGateway were both engineered to use 443 for a variety of reasons and therefore the port can't be changed. While you could configure the port forwarding rule and it wouldn't hurt anything, no client could ever use that rule so it be completely ineffective...except as another point of exposure for port scanners.

In short, I don't consider either option to be particularly useful or secure. You *should* forward port 443 externally to 443 internally (no custom port) and use RWA to access your server. That is both more secure and conforms to the standards that the services and clients expect. Additionally, basic monitoring (which you should have in place anyways, even if you were not forwarding any traffic) to alert you when an excessive number of authentication failures have occurred will help you handle any brute-force attacks.

 Regarding that last bit and security; brute force attacks *will* happen. If not against RDGateway or RWA, will still happen against OWA or the SMTP service if you expose it. You put a service on the internet, brute force attacks will occur. Unless you want to have no internet access whatsoever. The best you can do is mitigate the risk and the above suggestions go a long ways towards that. As always, the security landscape is one that is every changing as new attacks and new methods to block those attacks get developed (such as cryptolocker.) The above advice is, I believe, valid and accurate as of the time of this writing though and would be better than the alternatives you are considering.
b1dupreeAuthor Commented:
Yes, I understand that.

If I setup port forwarding with the SonicWall then port 3389 is no longer exposed.  I would shut down port 3389 on the SonicWall (thereby no longer exposing 3389) and I would create an alternate port on the SonicWall which would forward internally to 3389 or 443.  I just am not sure whether to forward internally from the alternate port (say 15000) to 3389 or 443 once it is inside the SonicWall.
Cliff GaliherCommented:
"I would shut down port 3389 on the SonicWall (thereby no longer exposing 3389)"

Why would you expose it in the first place. Sonicwalls, like most UTMs, are configured in a default-closed state. So if you don't *open* 3389 (and it isn't by default) then you have nothing to close. 3389 would not be exposed in a default configuration.

So now we are back to what you are trying to accomplish. Forwarding a custom port *opens* up a security hole. It doesn't close an existing one.
Tony GiangrecoCommented:
You could close 3389 and open 15000. Then have all RDP users come into port 15000 useing this on the rdp cloent:


That works for us.
Tony GiangrecoCommented:
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.