Using Remote Desktop Connection with dynamic dns

Just ran my own test of your "goal setup", and it works perfectly.

(1) I have two computers on my home network behind a Netgear router (and cable modem):

(a) 192.168.1.2 is the computer on which I allow RDP for this test, so that's the computer where I've enabled RDP. It's also the computer I've port-forwarded incoming 3389 requests to in my Netgear router.

(b) 192.168.1.3 is the computer on which I actually do allow RealVNC connections, for when I'm out of town and want to connect to my home computer. I actually turn off the other machine and just leave this one running when I'm away, as it is also my HTPC and does my DVR recording (using a cablecard-enabled Ceton 4-tuner card). So this machine needs to be on 24/7. I don't need to get to 192.168.1.2 when I'm away.

It is 192.168.1.3 that I'm going to use as the "requesting client" machine for this experiment, and 192.168.1.2 is the "target host" machine I'm going to try and "remote into" using RDP via a symbolic host name.

(2) Ordinarily I do not use RDP for away-from-home connection to 192.168.1.3, as I prefer the significant benefits of RealVNC Personal Edition over RDP. This involves running a RealVNC "host/server" program on this machine to which I want to connect to, and running a RealVNC "client" program on any machine from which I want to connect from.

I actually provide remote computer support for a large number of family and friends, so I have RealVNC "host/server" running on each of their machines and I use RealVNC's Address Book on my "client" machine to make connection to any of them a trivial single-click.

(3) I, too, have a dynamic IP address situation from my cable company as you do, where the assigned IP address lease renews every so often and there's no genuine way of knowing what that current IP address is without some other mechanism.

In fact, every one of my family and friends that I provide RealVNC remote support to also have the very same dynamic IP address situation.

My solution to this dynamic IP problem is much like what you've done... namely a "dynamic DNS client" to provide symbolic-to-absolute DNS resolution, but my provider is DynDNS.com.

DynDNS.com provides free support for 1-2 hosts, and a very small annual fee for I believe up to 30 hosts. Each target host machine that I wish to connect to remotely is defined as a "host name" on my account with DynDNS.com. As I support a fairly large number of friends and family, I pay for the service which provides a larger number of dynamic hosts.

A "DynDNS Updater" client program is installed on each host machine (that I want to be able to get to remotely through RealVNC), which every 10 minutes updates the DynDNS.com server with current IP address information for the host machine on which the DynDNS Updater client program is running. Thus the DynDNS.com server can be interrogated by any IP-based application (e.g. RealVNC, RDP, etc.) to provide the DNS resolution service of converting symbolic host name to IP address.

(4) RealVNC host/server normally accepts remote connection requests on ports 5800 and 5900. So my Netgear router is configured to port-forward 5800 and 5900 to 192.168.1.3, which is the machine I'm running DynDNS Updater and RealVNC host/server on. Windows Firewall on this machine is likewise configured to allow input on ports 5800 and 5900 for RealVNC.

For this RDP experiment I configured my Netgear router to port-forward 3389 to my other machine, 192.168.1.2. And I configured Windows Firewall on that machine to allow 3389 requests for RDP (including allowing Remote Desktop Connections in System Properties).

Note that my DynDNS Updater program is not running on the RDP machine, as it's only necessary to provide the current IP address of my cable modem to the DynDNS.com server, with all machines behind the router not really being visible (other than by internal LAN IP address to the router). So using either of my machines to run DynDNS Updater will work just fine, and it is the 3389 port-forwarding setup in the Netgear router that will send RDP requests from the outside to the 192.168.1.2 machine, whereas the 5800/5900 port-forwarding setup will send RealVNC requests from the outside to the 192.168.1.3 machine.

(5) Ok. That's the setup back-story. For the sake of discussion I will say that my "host name" as defined to DynDNS.com is "myhost.dyndns.com". This is essentially the symbolic name of my cable modem's current IP address, and the DNS resolution occurs via the DynDNS.com server whenever "myhost.dyndns.com" is used for connection purposes. Through the DynDNS Updater client program running on my 192.168.1.3 machine, the DynDNS.com server is kept apprised every 10 minutes of the current IP address assigned to my cable modem, for dynamic DNS absolute IP address resolution corresponding to symbolic host name "myhost.dyndns.com".

So I then went to my 192.168.1.3 machine and opened Remote Desktop Connection (client). In the connection are I specified "myhost.dyndns.com" and pushed the "connect" button.

This symbolic connection request (implicitly for port 3389 on "myhost.dyndns.com", since that's the default and I didn't specify a different port number on the RDP connection address) went up to DynDNS.com, and was resolved to the actual absolute IP address currently on file there for the "myhost.dyndns.com" host name. This absolute IP address with port 3389 was then used to complete the RDP connection to my cable modem and router, which then port-forwarded the request to my 192.168.1.2 machine per the Netgear configuration.

And presto, I was successfully connected using RDP from my 192.168.1.3 machine to my 192.168.1.2 machine... going out to DynDNS.com for DNS resolution to obtain the absolute IP address of my symbolic "myhost.dyndns.com" host name.

(6) I see no reason why you should not also be able to use exactly the same symbolic host name technique yourself, to connect remotely using RDP (or RealVNC, or any other similar remote desktop software).

In other words it is NOT necessary for you to first ping "myhost.dyndns.com" to receive the actual absolute IP address in the echo, although that certainly will work and you could then use that absolute IP address in your RDP connection dialog. It should only be necessary for you to use the symbolic "myhost.dyndns.com" address in the RDP connection dialog, if everything else is set up properly on the receiving end (i.e. proper port-forwarding of 3389 in your router, Windows Firewall allowing RDP connections, etc.).

(7) Note that the DynDNS.com hosting service is providing the dynamic DNS service of symbolic-to-absolute IP address resolution. But it is the port number in the request which then instructs the router where to send the request on to... in a multi-machine situation.

In other words if I wanted to provide RDP access to BOTH of my machines, I would need TWO DIFFERENT PORT-FORWARDING setups in my Netgear router. So I would do something like 3389 to 192.168.1.2, and 3390 to 192.168.1.3. And in each of the two machines I would set Windows Firewall to allow RDP connections, but on the 192.168.1.3 machine I would set that to be from port 3390 instead of 3389. Note that I haven't actually done this, but theoretically is is possible (in the inbound rule of "Advanced Settings" for Windows Firewall for Remote Desktop).

Then, on the remote machine requesting the RDP connection, if I wanted to connect to 192.168.1.2 I would connect to "myhost.dyndns.com" with port 3389 implied by default, or I could explicitly specify "myhost.dyndns.com:3389". And if I wanted to connect to 192.168.1.3 I would connect to "myhost.dyndns.com:3390".

Note that in the RealVNC equivalent multi-machine setup (as I have for my sister and brother-in-law, to provide remote support to EACH of their desktop machines), I have their router configured to port-forward 5800/5900 to one of their machines and 5801/5901 to the other of their machines. I have the RealVNC host/server and Windows Firewall on one machine set to listen for 5800/5900, and on the other machine set up to listen for 5801/5901.

RealVNC's connection mechanism is like that of RDP, with 5800/5900 being the "base port number" by default so it doesn't need to be specified. But connection to any other address must either use an explicit port number, or an incremental port number. So for example one machine could be connected to as "theirhost.dyndns.com" or "theirhost.dyndns.com:5900" or "theirhost.dyndns.com.0". The other machine could be connected to as "theirhost.dyndns.com:5901" or "theirhost.dyndns.com:1".

(8) Anyway, my RDP experiment was a complete success. I was able to "remote in" from my 192.168.1.2 machine to my 192.168.1.3 machine, connecting to "myhost.dyndns.com". This will work 100%, no matter what the current IP address is of my cable modem as assigned by my cable company.

Should work for you as well.

dsperber said:

Just ran my own test of your "goal setup", and it works perfectly.

(1) I have two computers on my home network behind a Netgear router (and cable modem):

(a) 192.168.1.2 is the computer on which I allow RDP for this test, so that's the computer where I've enabled RDP. It's also the computer I've port-forwarded incoming 3389 requests to in my Netgear router.

(b) 192.168.1.3 is the computer on which I actually do allow RealVNC connections, for when I'm out of town and want to connect to my home computer. I actually turn off the other machine and just leave this one running when I'm away, as it is also my HTPC and does my DVR recording (using a cablecard-enabled Ceton 4-tuner card). So this machine needs to be on 24/7. I don't need to get to 192.168.1.2 when I'm away.

It is 192.168.1.3 that I'm going to use as the "requesting client" machine for this experiment, and 192.168.1.2 is the "target host" machine I'm going to try and "remote into" using RDP via a symbolic host name.

(2) Ordinarily I do not use RDP for away-from-home connection to 192.168.1.3, as I prefer the significant benefits of RealVNC Personal Edition over RDP. This involves running a RealVNC "host/server" program on this machine to which I want to connect to, and running a RealVNC "client" program on any machine from which I want to connect from.

I actually provide remote computer support for a large number of family and friends, so I have RealVNC "host/server" running on each of their machines and I use RealVNC's Address Book on my "client" machine to make connection to any of them a trivial single-click.

(3) I, too, have a dynamic IP address situation from my cable company as you do, where the assigned IP address lease renews every so often and there's no genuine way of knowing what that current IP address is without some other mechanism.

In fact, every one of my family and friends that I provide RealVNC remote support to also have the very same dynamic IP address situation.

My solution to this dynamic IP problem is much like what you've done... namely a "dynamic DNS client" to provide symbolic-to-absolute DNS resolution, but my provider is DynDNS.com.

DynDNS.com provides free support for 1-2 hosts, and a very small annual fee for I believe up to 30 hosts. Each target host machine that I wish to connect to remotely is defined as a "host name" on my account with DynDNS.com. As I support a fairly large number of friends and family, I pay for the service which provides a larger number of dynamic hosts.

A "DynDNS Updater" client program is installed on each host machine (that I want to be able to get to remotely through RealVNC), which every 10 minutes updates the DynDNS.com server with current IP address information for the host machine on which the DynDNS Updater client program is running. Thus the DynDNS.com server can be interrogated by any IP-based application (e.g. RealVNC, RDP, etc.) to provide the DNS resolution service of converting symbolic host name to IP address.

(4) RealVNC host/server normally accepts remote connection requests on ports 5800 and 5900. So my Netgear router is configured to port-forward 5800 and 5900 to 192.168.1.3, which is the machine I'm running DynDNS Updater and RealVNC host/server on. Windows Firewall on this machine is likewise configured to allow input on ports 5800 and 5900 for RealVNC.

For this RDP experiment I configured my Netgear router to port-forward 3389 to my other machine, 192.168.1.2. And I configured Windows Firewall on that machine to allow 3389 requests for RDP (including allowing Remote Desktop Connections in System Properties).

Note that my DynDNS Updater program is not running on the RDP machine, as it's only necessary to provide the current IP address of my cable modem to the DynDNS.com server, with all machines behind the router not really being visible (other than by internal LAN IP address to the router). So using either of my machines to run DynDNS Updater will work just fine, and it is the 3389 port-forwarding setup in the Netgear router that will send RDP requests from the outside to the 192.168.1.2 machine, whereas the 5800/5900 port-forwarding setup will send RealVNC requests from the outside to the 192.168.1.3 machine.

(5) Ok. That's the setup back-story. For the sake of discussion I will say that my "host name" as defined to DynDNS.com is "myhost.dyndns.com". This is essentially the symbolic name of my cable modem's current IP address, and the DNS resolution occurs via the DynDNS.com server whenever "myhost.dyndns.com" is used for connection purposes. Through the DynDNS Updater client program running on my 192.168.1.3 machine, the DynDNS.com server is kept apprised every 10 minutes of the current IP address assigned to my cable modem, for dynamic DNS absolute IP address resolution corresponding to symbolic host name "myhost.dyndns.com".

So I then went to my 192.168.1.3 machine and opened Remote Desktop Connection (client). In the connection are I specified "myhost.dyndns.com" and pushed the "connect" button.

This symbolic connection request (implicitly for port 3389 on "myhost.dyndns.com", since that's the default and I didn't specify a different port number on the RDP connection address) went up to DynDNS.com, and was resolved to the actual absolute IP address currently on file there for the "myhost.dyndns.com" host name. This absolute IP address with port 3389 was then used to complete the RDP connection to my cable modem and router, which then port-forwarded the request to my 192.168.1.2 machine per the Netgear configuration.

And presto, I was successfully connected using RDP from my 192.168.1.3 machine to my 192.168.1.2 machine... going out to DynDNS.com for DNS resolution to obtain the absolute IP address of my symbolic "myhost.dyndns.com" host name.

(6) I see no reason why you should not also be able to use exactly the same symbolic host name technique yourself, to connect remotely using RDP (or RealVNC, or any other similar remote desktop software).

In other words it is NOT necessary for you to first ping "myhost.dyndns.com" to receive the actual absolute IP address in the echo, although that certainly will work and you could then use that absolute IP address in your RDP connection dialog. It should only be necessary for you to use the symbolic "myhost.dyndns.com" address in the RDP connection dialog, if everything else is set up properly on the receiving end (i.e. proper port-forwarding of 3389 in your router, Windows Firewall allowing RDP connections, etc.).

(7) Note that the DynDNS.com hosting service is providing the dynamic DNS service of symbolic-to-absolute IP address resolution. But it is the port number in the request which then instructs the router where to send the request on to... in a multi-machine situation.

In other words if I wanted to provide RDP access to BOTH of my machines, I would need TWO DIFFERENT PORT-FORWARDING setups in my Netgear router. So I would do something like 3389 to 192.168.1.2, and 3390 to 192.168.1.3. And in each of the two machines I would set Windows Firewall to allow RDP connections, but on the 192.168.1.3 machine I would set that to be from port 3390 instead of 3389. Note that I haven't actually done this, but theoretically is is possible (in the inbound rule of "Advanced Settings" for Windows Firewall for Remote Desktop).

Then, on the remote machine requesting the RDP connection, if I wanted to connect to 192.168.1.2 I would connect to "myhost.dyndns.com" with port 3389 implied by default, or I could explicitly specify "myhost.dyndns.com:3389". And if I wanted to connect to 192.168.1.3 I would connect to "myhost.dyndns.com:3390".

Note that in the RealVNC equivalent multi-machine setup (as I have for my sister and brother-in-law, to provide remote support to EACH of their desktop machines), I have their router configured to port-forward 5800/5900 to one of their machines and 5801/5901 to the other of their machines. I have the RealVNC host/server and Windows Firewall on one machine set to listen for 5800/5900, and on the other machine set up to listen for 5801/5901.

RealVNC's connection mechanism is like that of RDP, with 5800/5900 being the "base port number" by default so it doesn't need to be specified. But connection to any other address must either use an explicit port number, or an incremental port number. So for example one machine could be connected to as "theirhost.dyndns.com" or "theirhost.dyndns.com:5900" or "theirhost.dyndns.com.0". The other machine could be connected to as "theirhost.dyndns.com:5901" or "theirhost.dyndns.com:1".

(8) Anyway, my RDP experiment was a complete success. I was able to "remote in" from my 192.168.1.2 machine to my 192.168.1.3 machine, connecting to "myhost.dyndns.com". This will work 100%, no matter what the current IP address is of my cable modem as assigned by my cable company.

Should work for you as well.

Thank you for the detailed explanation. The first thing I did after acquiring my domain name was to sign up for a dynamic dns service at freedns.afraid.org. Then I installed their freedns clinet on one of my machines (not one of the ones I want to connect to). Because of my limited understand of how all this works, I was unable to make sense out of the directions and information provided on the freedns.afraid.org website. So, I signed on to a different dynamic dns service DNSdynamic.org. They use a web based client where you can find out what your current ip is. Once I did this I found that I could ping mydomain.com.dnsdynamic.com and get a response. I am unable to get a response when I ping mydomain.com and I am unable to connect using RDP to my machine using the url mydomain.com.dnsdynamic.com whether I specify the port number or not. I can connect to this machine from outside my LAN if I use the ip address, but not the url. So, I'm still stumped, but I will carefully read over everything you wrote to see if I can see where the difference is. Thanks again.

edit: I just spoke with register.com. I evidently needed to specify my primary and secondary dns servers when I registered, which I did not do. Now that this is done, I expect I will soon be able to locate my domain.

dsperber said:

Well, it may just be semantics here, but I didn't acquire a "domain name" from DynDNS.com. I simply registered a "host name", which essentially is nothing more than an artificial symbolic IP address that is resolved through their DNS capability.

When you create a "host name" with them, you pick the prefix part as well as choosing one of a set of available suffix parts, which must be domain names registered to DynDNS.com. The sum of the two parts is really just one symbolic "host name".

Sounds like what your services provide.

I am able to ping "myhost.dyndns.com" (again, using that as the example "host name" for my particular setup, although I have a number of similar individual "host name" definitions for each of my friends and family whose individual machines I support remotely through RealVNC), with the echo providing my proper current absolute IP address.

I can also go my account on the DynDNS.com site, log in, and see all of my defined "host names" and their current absolute IP addresses.

And, as I've now proven, not only can I connect remotely to target host machines via RealVNC (which uses ports 5800/5900) symbolically, but I can do the exact same thing to a target host machine (i.e. my 192.168.1.2 for this experiment) via RDP (which uses port 3389). Both for the RealVNC "viewer" (i.e. the requesting client program for RealVNC on the requesting machine) and RDP, the connection dialog setup specified the symbolic "host name" just as I've described above.

In other words, going through DynDNS.com for my dynamic DNS support both RealVNC and RDP connect perfectly with symbolic "host name" configuration. I do NOT have to use absolute IP addresses. I don't know what your problem might be, but I've now proven for myself that RDP works just as well as RealVNC using symbolic host name connections. Absolute IP addresses are NOT required for RDP.

You could certainly see if the dynamic DNS services which you've tried is the "culprit" in your problem, because you can register for a free "host name" at DynDNS.com if you only have 1-2 host names you want to support.

Since you say you CAN connect successfully if you use absolute IP address, that would confirm that your router (port-forwarding of 3389) and Windows Firewall setup is correct. And that would then point to whatever your dynamic DNS resolution service is or is not doing as the only component that could be responsible for your failure when trying symbolic connection.

Again, I have no problem with DynDNS.com as that service. RDP connection using symbolic "host name" works perfectly. Perhaps you should try it... since it can't hurt to try.

I assumed that when I signed up at register.com that my new domain name would magically find it way into the at&t dns system. Seems like that is what I'm paying for. When I went to the register.com website and tried to enter the dns names, it wouldn't accept them. Then I called at&t and asked them to give me the current names, which they did. However, when I tried the new dns names at register.com, they don't work either. I also can't understand why the dns names in my router aren't the right ones. Perhaps because it's a BellSouth router?? I will update when it all gets sorted out. thanks for your help.

edit: Turns out (according to BellSouth) I am already paying for a static ip so all of this was unnecessary, but educational.