?
Solved

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

Posted on 2014-03-14
16
Medium Priority
?
1,066 Views
Last Modified: 2014-04-09
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 192.168.1.1 on internal port 3389
Nat rule set for TERMINAL server to port forward 3389 to 192.168.1.2 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
0
Comment
Question by:stevebootes
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
16 Comments
 
LVL 9

Expert Comment

by:Lee Ingalls
ID: 39929075
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.
0
 
LVL 19

Expert Comment

by:Miguel Angel Perez Muñoz
ID: 39929112
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.
0
 

Author Comment

by:stevebootes
ID: 39929154
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
0
NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

 
LVL 30

Expert Comment

by:masnrock
ID: 39929730
What is different about this network versus other networks?
0
 

Author Comment

by:stevebootes
ID: 39929803
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
0
 
LVL 30

Expert Comment

by:masnrock
ID: 39929942
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.
0
 

Author Comment

by:stevebootes
ID: 39930129
Current NAT rules:
Index   Proto   WAN IP:Port                 Private IP:Port             Act
***********************************************************************
R01     TCP     -- ALL --:25                192.168.1.1:25              Y
R02     TCP     -- ALL --:80                192.168.1.1:80              Y
R03     TCP     -- ALL --:443               192.168.1.1:443             Y
R04     TCP     -- ALL --:4125              192.168.1.1:4125            Y
R05     TCP     -- ALL --:1723              192.168.1.1:1723            Y
R06     TCP     -- ALL --:3389              192.168.1.2:3389            Y
R07     TCP     -- ALL --:389               192.168.1.1:389             Y
R08     TCP     -- ALL --:82                192.168.1.21:80             Y
R09     TCP     -- ALL --:3390              192.168.1.1:3389            Y

192.168.1.1 = Main SBS server
192.168.1.2 = Terminal Server

There are some IP filters too for the main server but nothing for the Terminal Server.
0
 
LVL 30

Expert Comment

by:masnrock
ID: 39930289
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
0
 

Author Comment

by:stevebootes
ID: 39930968
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.
0
 
LVL 30

Expert Comment

by:masnrock
ID: 39930989
How is Windows Firewall configured on the Terminal Server?
0
 

Author Comment

by:stevebootes
ID: 39930995
We have tried it with the RDP exception added as well as completely disabling the firewall.
0
 
LVL 30

Expert Comment

by:masnrock
ID: 39931146
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.
0
 

Author Comment

by:stevebootes
ID: 39936174
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.
0
 
LVL 30

Expert Comment

by:masnrock
ID: 39940745
What type of equipment do you have in use?
0
 

Accepted Solution

by:
stevebootes earned 0 total points
ID: 39978063
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)
0
 

Author Closing Comment

by:stevebootes
ID: 39988226
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.
0

Featured Post

Efficient way to get backups off site to Azure

This user guide provides instructions on how to deploy and configure both a StoneFly Scale Out NAS Enterprise Cloud Drive virtual machine and Veeam Cloud Connect in the Microsoft Azure Cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Are you one of those front-line IT Service Desk staff fielding calls, replying to emails, all-the-while working to resolve end-user technological nightmares? I am! That's why I have put together this brief overview of tools and techniques I use in o…
Trying to figure out group policy inheritance and which settings apply where can be a chore.  Here's a very simple summary I've written which might help.  Keep in mind, this is just a high-level conceptual overview where I try to avoid getting bogge…
With the advent of Windows 10, Microsoft is pushing a Get Windows 10 icon into the notification area (system tray) of qualifying computers. There are many reasons for wanting to remove this icon. This two-part Experts Exchange video Micro Tutorial s…
Michael from AdRem Software explains how to view the most utilized and worst performing nodes in your network, by accessing the Top Charts view in NetCrunch network monitor (https://www.adremsoft.com/). Top Charts is a view in which you can set seve…

752 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question