RDP on ANY port other than 3389 (i.e., 3390, 3391, ETC.)

[guruuno]

Asked previously how to access multiple PC's on remote
network via RDP, answered, worked (at that time, using on
remote network a D-Link DI-604). Modified all PC's
registry for each port, all works as advertised.

However, different router, different remote network, this
one with ANY Linksys router. For this example, let's use a
WRT54G.

PC#1=192.168.15.100, PC#2=192.168.15.101, (FIXED IP's), all
configured correctly. Everything works everywhere, etc.

PC#1 RDP Port=3389
PC#2 RDP Port=3390

WRT54G Port Forwarding 3389-3389 to 192.168.15.100
WRT54G Port Forwarding 3390-3390 to 192.168.15.101

BOTH PC's correctly configured, etc (all required settings,
etc.)

However, PC#1, when attempting a remote access, does not
connect. telnet xxx.xxx.xxx.xxx 3389 hangs. (Where
xxx.xxx.xxx.xxx is PUBLIC IP)

PC#2, when attempting a remote access, DOES connect.
telnet xxx.xxx.xxx.xxx 3390 hangs. (Where xxx.xxx.xxx.xxx
is PUBLIC IP)

Via RDP, connection procedure is xxx.xxx.xxx.xxx:3389 for
PC#1 and xxx.xxx.xxx.xxx:3390 for PC #2. Again, to repeat,
PC#2 only connects, not PC#1.

(Yes, after modifying registry, PC was rebooted)

In any event, I did this all a few months ago in the exact
same fashion for 5 different PC's on remote network and
that remote network had the D-Link DI-604 router,
configured for the appropiate port forwarding (and it is
much more elaborate/specific...the settings.....than ANY
Linksys router)...and all did and still does work.

As stated, this setup when using any Linksys router seems
not to forward any ports other than 3389, no 3390, 3391, etc.

Other than the answer to use a D-Link router, what
specifically may be the issue(s) at hand to address and
resolve these matters to get this working, as I like using
the Linksys routers, but not having these problems....

Guruuno

 

[Robin Walker]

PC#1=192.168.15.100, PC#2=192.168.15.101, (FIXED IP's)

You say these are fixed IPs. But these IP addresses fall within the DHCP
allocation pool of a Linksys router, therefore the Linksys router is capable
of allocating these same IP addresses to other apparatus on your LAN. If
you wish to allocate static IP addresses to PCs on a LAN, you must allocate
addresses from outside the DHCP allocation pool, but still within the
router's LAN subnet. For instance, by default on a Linksys router,
addresses 2 to 99 are available for static allocation.

 

[Guest]

The DHCP Pool is: 192.168.15.102-192.168.15.127

Therefore, if I use .100 and .101, they DO NOT fall within
the DHCP pool range.

There are NO OTHER devices requesting any IP's on the network.

Also, this does not clarify as to why .101 works with port
3390 but .100 does not work with port 3389 ON A LINKSYS
ROUTER, yet it DOES on a D-Link router.

(2 different customers/remote networks, both with Linksys
routers, both with multiple PC's with reconfigured RDP orts
and forwarded via the router.

I appreciate the attempted resolve, but it does not address
the issue at hand.

Anyone........next?

 

[Robin Walker]

Also, this does not clarify as to why .101 works with port
3390 but .100 does not work with port 3389 ON A LINKSYS
ROUTER, yet it DOES on a D-Link router.

I have no difficulty using both ports 3389 and 3390 through a Linksys WRT54G
to different LAN IPs, so I suggest you look for the source of the problem
elsewhere: I do not think this problem has anything to do with the brand of
router as such. For instance, are the PC's firewalls configured to allow
these incoming calls?

Have you checked that you can make RDP calls to both PCs from other PCs on
the same LAN, using their LAN addresses and the appropriate port numbers?

 

[guruuno]

OK, I think I may have found out why the problem exists.

Seems the PC's that were on the D-Link at one client were
all on SP1 for all ports 3390 and up, and 3389 was on a pc
with SP2. I'll get to the point in a min. Can connect to
ALL PC's OK.

The other clients are all running SP2 (at other locations),
and the only ones I have success getting into are port 3389
as 3390 and up, cannot connect.

All port forwarding is configured correctly on all routers.

The problem is even though the registry has been modified
on the PCs requiring an optional port, the windows firewall
is on on the SP2 PC's. If you go into the firewall
settings, Remote Desktop and Remote Assistance are all
checked, but they refer to Port 3389. There is no way to
delete the entry or modify the port from there (firewall),
just enable or disable. Sure, I tried adding RDP-Port
3390, but it won't allow connects. Sure, I can turn off
the firewall, but I don't want to.

What I need to do is modify the firewall settings for RDP
to allow Port 3390, not 3389. Can this be done? Or do I
forward in the router (UPnP Port Forwarding), and if so, is
it 3390 --> 3389 or 3389 -->3390?

Be aware that the router had 'normal' port forwarding
(APP-port port tcp or udp ip add (nat) enable or disable
(check), and then there is the UPnP port forwarding.

Which configuration to use, or do I modify the firewall
port, and if so how?

 

[guruuno]

Tried ADDING a Firewall rule:
RDP Port 3390 TCP

Still no good
NEED answer to previous question
(Cannot modify existing rule for remote desktop in
firewall....greyed out, cannot modify, set to 3389, or what
is solution)

 

[guruuno]

Did this thread die?
Does anyone have a resolve?

 

[Bill Sanderson]

Adding a rule to the firewall should work.

Let me see if I can get that tested.

Sorry short delay - I am testing with a laptop which always hibernates, and
on which I had set a CHKDSK to happen on next reboot--ever notice how
annoying that is when you forget it is going to happen?

OK--after the reboot, ping still works (echo responses are turned on in
firewall settings).

Telnet to 3389 fails, telnet to 3390 fails.

OK--create new port exception, called rdp 3390, port 3390, TCP.

Telnet to 3389 fails, telnet to 3390 appears to do what I'd expect.

MSTSC at the command prompt with the argument: 192.168.2.28:3390 fails
However, if I run MSTSC <enter>
and enter the argument 192.168.2.28:3390, it works just fine.

So--the new exception in the firewall works, the port change worked, so it
all works as documented.

So--what are you doing wrong?