Unable to RDP to Terminal server externally despite Nat rules being in place

Hi There.

I have an odd situation whereby I can RDP onto my terminal server and main server internally, so RDP is working and enabled, However when trying to connect externally from another location, the connection fails. I get the standard error (Remote Desktop can't connect to the remote computer for one of the following reasons:.....) the same as if you had mistyped the address. I am however able to connect to the main server from an external location.

Here are the facts:

Nat rule set for main server to port forward 3390 to on internal port 3389
Nat rule set for TERMINAL server to port forward 3389 to on internal port 3389

Connection to remote.company.com:3390 (or external static IP) to main sbs server WORKS
Connection to remote.company.com:3389 (or external static IP) to Terminal Server DOES NOT

All connections onsite using internal host names and local IP addresses work.

Troubleshooting steps:

Router NAT rules: SWAP the local IP addresses between the two servers round. See if the internal IP was being blocked. No change. Checked with external port checker and the termserver always shows as blocked, regardless of the port or internal IP used.

Completely removed all NAT rules on the DrayTek firewall/router and re-created

Installed NEW router with NAT rules present

Created a completely new virtual network adapter with a different IP address on the Terminal Server

Changed the internal port within the registry from 3389 to 3391

Turned off ALL firewall rules on router and completely disabled the firewall on Terminal server

Re-created RDP connection in TS configuration

Stopped all Sophos AV and firewall services

Checked startup icons in MSconfig - nothing untoward

Scanned with Malware Bytes and rougue killer, delete 5 items but no change - also uninstalled a number of unusual program that have been installed.

Checked for any strange processes running that could be blocking access (odd software firewall etc) - nothing untoward

Reboot on a number of occasions during the above troubleshooting processes.

Short of re-installing the operating system, I am at a loss as to what else I can try.

Many thanks
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Lee IngallsDirector of IT/TS, Quality and FinanceCommented:
I've used SSH IP Port Forwarding... once the SSH tunnel is established then RDP/MSTSC to local host. Works beautifully!

Here is a guide with several options. I prefer using PUTTY for SSH.
Miguel Angel Perez MuñozCommented:
Try changing  rdp port 3389 by 3390 by sbs server: http://support.microsoft.com/kb/306759

It is possible can not use same destination port by different computers.
stevebootesAuthor Commented:
Thanks for the input, I have however already changed the listening port from 3389 to 3390

Changed the internal port within the registry from 3389 to 3391

One thing I may have forgotten to mention is that this setup is very similar across a number of networks I manage and has worked for this particular network until recently breaking for no apparent reason.

Thanks again
Learn SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

What is different about this network versus other networks?
stevebootesAuthor Commented:
The setup is a very basic SBS server/Terminal server setup with fixed IP for remote RDP and VPN access, using basic NAT port forwarding rules to pass the traffic through to the local devices. There aren't any strict firewall rules (none actually) and nothing different than any other setup in that respect.

It has worked without issue for a number of years, and access to the main SBS server is still working via RDP.

I can also successfully VPN onto the network and RDP to the Terminal server using the local IP.

Many thanks again
Thanks for the input, I have however already changed the listening port from 3389 to 3390

As of this moment, could you please show us the exact port forwarding rules? The reason I ask if I notice one place where you mention 3390 and 3391. Just want to be sure that that one particular rule is sorted out properly.
stevebootesAuthor Commented:
Current NAT rules:
Index   Proto   WAN IP:Port                 Private IP:Port             Act
R01     TCP     -- ALL --:25                    Y
R02     TCP     -- ALL --:80                    Y
R03     TCP     -- ALL --:443                  Y
R04     TCP     -- ALL --:4125                Y
R05     TCP     -- ALL --:1723                Y
R06     TCP     -- ALL --:3389                Y
R07     TCP     -- ALL --:389                  Y
R08     TCP     -- ALL --:82                   Y
R09     TCP     -- ALL --:3390                Y = Main SBS server = Terminal Server

There are some IP filters too for the main server but nothing for the Terminal Server.
Should R09 be forwarding to port 3389 or port 3390?

Thanks for the input, I have however already changed the listening port from 3389 to 3390
stevebootesAuthor Commented:
R09 is external access to the main SBS server.  Obviously the RDP service runs on :3389 on the machine itself, though we're accessing it through 3390 externally via an IP filter.

R06 is the NAT rule for the Terminal Server - the RDP port has reverted back to a standard :3389 since changing it to :3390 didn't fix the problem.
How is Windows Firewall configured on the Terminal Server?
stevebootesAuthor Commented:
We have tried it with the RDP exception added as well as completely disabling the firewall.
Do you have any sort of log within Windows Firewall or your router? Don't try disabling the firewall service itself. Last couple times I did that, it actually blocked every connection rather than allowing them.
stevebootesAuthor Commented:
Right, some updates after more testing:
There is nothing showing up in the firewall filter logs.
We've switched on the Windows Firewall logging (success and failure).  We can see entries for a successful connection to the RDP service (TCP/3389) on the Terminal Server when we connect internally from another machine.  We can also see dropped packets if we connect to an invalid port (e.g. TCP/3390) or if we disabled the "allow RDP" rule in the Windows Firewall.  However, if we try and connect externally (e.g. via the NAT router) nothing shows in the firewall logs, as if there is no NAT rule in place.
We have already changed the router, but just to check out general port forwarding to the Terminal Server machine we setup a FileZilla FTP Server as a test and forwarded TCP/21 - it worked fine externally, so the NAT rules do appear to be working fine to that internal IP address.
What type of equipment do you have in use?
stevebootesAuthor Commented:
We have now managed to resolve the issue, looks like changing the listening port (again - it didn't seem to work the 1st time) to 3395 and rebooting the server, then changing the NAT rules and firewall rules to point to the new port, has allowed us access into the server externally.

We have also kept the an additional registry entry for 3389 for internal use (as this still worked)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
stevebootesAuthor Commented:
This has allowed us to regain external access to the server, so I regard this as a fix, however we are still not really sure as to why we cannot connect externally through ports 3389, but this is not an issue for us.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Networking

From novice to tech pro — start learning today.