VPN To Another User's PC?

P

(PeteCresswell)

I'm on Verizon's FIOS.

My daughter, 100+ miles away, is Verizon's "Broadband" (seems tb
DSL).


My guess that in both cases the IP address of the PC is dynamic -
i.e. it can change from logon-to-logon, or even from
hour-to-hour.

I VPN to various client sites every day - but I'm hooking into
their VPN servers.


Is there any hope of me being able to create a Remote Desktop
Connection to her PC in order to troubleshoot some email issues?
 
P

(PeteCresswell)

Per Newbie Coder:
I would prefer to use RealVNC (http://www.realvnc.com). Her's being the host &
you only need the viewer

How critical is desktop scaling (lacking in the freebie version)?
Maybe a moot question bc, although my main PC has more bits than
hers, I've got another PC where the screen rez is the same.

Why the preference for RealVNC over what comes with XP Pro?

Something about servers?
 
V

Vanguard

in message
I'm on Verizon's FIOS.

My daughter, 100+ miles away, is Verizon's "Broadband" (seems tb
DSL).


My guess that in both cases the IP address of the PC is dynamic -
i.e. it can change from logon-to-logon, or even from
hour-to-hour.

I VPN to various client sites every day - but I'm hooking into
their VPN servers.


Is there any hope of me being able to create a Remote Desktop
Connection to her PC in order to troubleshoot some email issues?


You and your daughter are using dynamically assigned IP addresses.
That means they can change. If you use dial-up, they change everytime
you dial in. If you use an always-on connection, like DSL or cable,
they can change when they expire (all dynamic IP address have an
expiration). With the always-on connection, often you get reassigned
the same IP address but that is not guaranteed.

So the problem with using Remote Desktop or some flavor of VNC is that
you would have to know the other host's IP at the time you tried to
connect to it, and that IP address might be different tomorrow. You
need something that monitors the IP address of the remote host and
provides an IP *name* to which you connect which then resolves to the
current IP address of the remote host. Look into:

DynDNS.com
No-IP.com

Some NAT routers, for example, try to provide support for, say, DynDNS
to act as their client (what monitors the IP address) but there are a
couple problems with that setup. One, the IP address being reported
is the WAN-side IP address of the router, not of any intranet host
connected to it. That means you have to use port forwarding in the
router so when you connect to the router on that port then the traffic
goes to a specific intranet host. Two, I've found routers are a bit
flaky when acting as the DynDNS client. Often they only report the
WAN-side IP address of the router when it changes. For cable or DSL
connections, the IP address may not change for months. That is, each
time the dynamic IP address has expired, the new one happens to be the
same as the previous one so there is no change. Since there is no
change, the router doesn't report anything back to DynDNS. However,
free accounts at DynDNS will expire after so many weeks of being idle.
You'll end up getting e-mails telling you your DynDNS account is about
to expire (or the IP name lookup you define with them will expire).
If you don't access your DynDNS account in a few days, poof, you lose
the IP name redirect or the account. I believe No-IP is the same way.
Even if the IP address doesn't change, it is still a good idea to have
the client access your DynDNS account to keep it alive. Because of
these 2 problems, I instead choose to run their client program on the
host to which I want to connect remotely. It does the reporting back
to DynDNS and does it frequently enough to keep alive your account or
IP redirect, plus I don't need to do any port forwarding in the
router. The client only consumes 4.5MB of memory (0.8MB real + 3.9MB
virtual).

Once you define a IP name at DynDNS, you use that IP *name* to
identify the remote host in Remote Desktop or VNC. If the remote
host's IP address changes, the DynDNS client running on that remote
host will report it to DynDNS which will update the IP redirect so the
IP name is still valid (i.e., it continues to point at the remote host
despite the dynamic IP address change). When you connect using the IP
name, the DNS resolution passes through your DNS server (because it
isn't defined there) to pass it upstream to the next DNS server, and
so on, until it gets the lookup from DynDNS' nameserver which returns
the IP address for the remote host identified by that IP name.

Your daughter doesn't have to do anything to open and maintain a
DynDNS account. You would do that. At DynDNS, and after creating an
account with them (free), you want to define you want to define a
hostname. You create something like <hostname>.<domain> (e.g.,
glendacresswell.dyndns.org). They have several domains to chose from,
and you get to pick the username (as long as it isn't already used for
the domain that you selected. However, your daughter will have to
install the DynDNS client program on her host. In that client
program, she will have to specify that she will be updated the
glendacresswell.dyndns.org IP name that you defined in the account at
DynDNS. Obviously you don't want just anyone changing that definition
so the DynDNS client logins to your DynDNS account using whatever
login credentials are valid for your account. You'll have to give
those (username and password) to your daughter.

Using DynDNS or No-IP isn't super complicated but it does require
defining a hostname in your account and installing their client along
with configuring it to login to your account and to specify the same
hostname as you defined in your account. A simpler method is
GoToMyPC.com but it costs money. Yeah, they say "try it free" but
that's just hiding that it is 30-day trialware. It costs $20/month
with a discount if you prepay for a year contract. I don't think it
does anything more than DynDNS or No-IP except provide wizards to do
the setup (which can probably all be done from the client end rather
than defining the IP redirect in your account and then making the
client match up).
 
P

(PeteCresswell)

Per Vanguard:
DynDNS.com
No-IP.com

I think a plan is evolving.
---------------------------------------------------------------
- Drive down there, scoop up that PC (that I just built for her
last week....), take it back home, and run it side-by-side
with one of my spare PC's that has the same screen rez until I
get the Remote Desktop thing running on the two PCs
side-by-side.

- Set up DynDNS while I'm at it.

- Take it back down there, hook it up to her DSL modem again,
get my techie granddaughter on my home PC while I'm down there
and see if we can shake it down to where things are happening.
 
V

Vanguard

in message
Per Vanguard:

I think a plan is evolving.
---------------------------------------------------------------
- Drive down there, scoop up that PC (that I just built for her
last week....), take it back home, and run it side-by-side
with one of my spare PC's that has the same screen rez until I
get the Remote Desktop thing running on the two PCs
side-by-side.

- Set up DynDNS while I'm at it.

- Take it back down there, hook it up to her DSL modem again,
get my techie granddaughter on my home PC while I'm down there
and see if we can shake it down to where things are happening.
---------------------------------------------------------------


Sounds like you're just looking for an excuse to spy on, er, visit
your daugher. >;->
 
P

(PeteCresswell)

Per Vanguard:
Sounds like you're just looking for an excuse to spy on, er, visit
your daugher. >;->

Nah... she and her husband are going out of town the second half
of the week - so I can scoop the box without interfering.

Joking aside, your comment brings up something that I probably
need to deal with: the assurance to her that this facility cannot
be used without her explicit permission for each instance.
 
V

Vanguard

in message
Per Vanguard:

Nah... she and her husband are going out of town the second half
of the week - so I can scoop the box without interfering.

Joking aside, your comment brings up something that I probably
need to deal with: the assurance to her that this facility cannot
be used without her explicit permission for each instance.


She has the choice as to whether or not the DynDNS client program runs
on her host. If you want her to have control of the DynDNS account
then she needs to create that account and use whatever login
credentials she prefers. She is the one letting her host get accessed
so she should be in control of the DynDNS account.

If you are going to Remote Desktop to her host, she needs to configure
who gets to connect to her using that protocol. On her host,
right-click on the My Computer desktop icon and select Properties.
Click on the Remote tab panel to view it. Until you enable the
checkbox "Allow users to connect remotely to this computer", no one
can use RDP to connect to that host. Check that box to enable RDP to
that host (i.e., from you to her). Then click the button "Select
Remote Users". All admin-level users (i.e., anyone in the
Administrators group) defined on that host are allowed to connect to
that host from somewhere else using the same login credentials as they
use on that host. If the user chose to use a blank password on their
account then they chose to let anyone in to that host that can guess
their username. It's your choice how insecure to make a host. If you
want a remote user to only have restricted or limited access to the
host then you need to create a user account for them that is not an
admin account and then add that user's account to the list of those
allowed to remote connect.

If you use some version of VNC instead of RDP to connect to the remote
host then make sure you configure VNC to require login credentials;
otherwise, you've decided to let anyone get to your host.
 
P

(PeteCresswell)

Per Vanguard:
If you are going to Remote Desktop to her host, she needs to configure
who gets to connect to her using that protocol. On her host,
right-click on the My Computer desktop icon and select Properties.
Click on the Remote tab panel to view it. Until you enable the
checkbox "Allow users to connect remotely to this computer", no one
can use RDP to connect to that host....

Any idea what the facility my client's Help Desk uses?

I'm guessing it's not plain-vanilla Remote Desktop because I can
be logged on at the same time they're on and a "Do you want this
person fooling around on your PC?" pops that I have to answer
"Yes" to before they can connect.

I've been going on about "Remote Desktop" but, upon reflection,
what I just described is what I really want. i.e. the other
person has to be at the PC and explicitly say "Yes" every time I
want to connect.
 
P

(PeteCresswell)

Per Vanguard:
If you use some version of VNC instead of RD

Not to turn into a tarbaby on you but....

When I bring up www.ipchicken.com on this PC, I get an IP address
of 71.244.97.80 qualified by a "Remote Port" of 63142.

When I do IpChicken on another box I get, of course, the same IP
address... but qualified by a different "Remote Port" (63147).

If I bring that PC from my daughter's place home and sit it next
to my other PCs and connect it to the same router; is there any
hope of me shaking down the VPN thing under those circumstances?

My first instinct would be to use the local NIC card IP addresses
- which are unique to each machine.
 
V

Vanguard

(PeteCresswell) said:
Per Vanguard:

Any idea what the facility my client's Help Desk uses?

Help Desk? You mean her host is a company's workstation? Then you
better not connect it to their corporate network without their
permission. They don't want unmanaged and infected hosts connecting
to their network. When you come through their VPN, you come into a
different security zone than for their workstations. I'm sure what
"facility" you are asking about.
I'm guessing it's not plain-vanilla Remote Desktop because I can
be logged on at the same time they're on and a "Do you want this
person fooling around on your PC?" pops that I have to answer
"Yes" to before they can connect.

That is going through a 3rd party provider where you run a client on
your host (often via an ActiveX control by navigating to a particular
web page) that does the same thing as the DynDNS client. The company
then connects to the open invite you sent to this 3rd party but which
is open under a secure account established by the employer with that
3rd party. Only you know to where you are connecting to do this 3rd
party orchestrated connection.
I've been going on about "Remote Desktop" but, upon reflection,
what I just described is what I really want. i.e. the other
person has to be at the PC and explicitly say "Yes" every time I
want to connect.

Those 3rd party services are expensive, but they are lot cheaper than
having the tech reps spend 6 times more time on the phone trying to
yank useful info from the end user who they are attempting to use as a
voice-operated automaton.

I already mentioned GoToMyPc which is a similar service. Both the 3rd
party remote service and GoToMyPC simply automate what you can do
manually. Both only require a one-time setup. After that, it doesn't
matter if the remote host's IP address changes. Doesn't matter if you
are using Remote Desktop, VNC, FTP, or a web server (on the remote
host). You use the redirect service to get to the remote host. What
you want to do on that remote host depends on what protocol you are
using to connect to it.
 
V

Vanguard

in message
Per Vanguard:

Not to turn into a tarbaby on you but....

When I bring up www.ipchicken.com on this PC, I get an IP address
of 71.244.97.80 qualified by a "Remote Port" of 63142.

When I do IpChicken on another box I get, of course, the same IP
address... but qualified by a different "Remote Port" (63147).

If I bring that PC from my daughter's place home and sit it next
to my other PCs and connect it to the same router; is there any
hope of me shaking down the VPN thing under those circumstances?

My first instinct would be to use the local NIC card IP addresses
- which are unique to each machine.


You won't be doing the "VPN thing" to your daughter's host.

I don't have a clue what is ipchicken.com. Presumably this site tells
you what is your IP address that *they* see (every host knows the IP
address of the host that connects to it). Could be ipchicken is
simply showing you the IP address of the host that connects to it.
Well, if you have a NAT router than what the receiving host sees is
your router connecting to it. If the site uses Javascript, that runs
on the local host where the browser is loaded so it shows the IP
address of that host. However, usually the intranet IP address in a
home setup are 192.168.x.x, not 71.244.x.x (which looks to be the
WAN-side IP address of your router).
 
P

(PeteCresswell)

Per Vanguard:
However, usually the intranet IP address in a
home setup are 192.168.x.x, not 71.244.x.x (which looks to be the
WAN-side IP address of your router).

That cuts to the part that I keep tripping over.

I've tried three different tools for connecting to another PC,
but tried them all at home (i.e. on the same LAN, not from my
FIOS connection, across the internet, to somebody's DSL modem).

When firing up the "Viewer" (i.e. client) they all (naturally...)
want to know the IP address of the host.

But all they ask for is "IP Address".

No problem on the home LAN - I just type in the 168.... address
of the other box.

But in my limited understanding, that's the "private" address.

Seems tb meaningless in the context of FIOS
Router==>Internet==DSL modem.


But the WAN-side ("public"?) address doesn't seem adequate
either, since that would be the address of a router or DSL modem
- which could have more than one PC connected to it.

In another post/another thread somebody mentioned "tunneling" -
which I impute VPN tb a flavor of.

For the FIOS Router==>Internet==>DSL modem scenario I'm guessing
I need a third piece of software (besides the host and client
pieces): something to make the FIOS Router and the DSL modem look
as if they are part of a local LAN.

I *think* I've heard a couple of people describe such things -
but it's been couched in language that I only understand about
10% of.... so I haven't chosen to act on said descriptions.
 
J

John R

(PeteCresswell) said:
Per Vanguard:

That cuts to the part that I keep tripping over.

I've tried three different tools for connecting to another PC,
but tried them all at home (i.e. on the same LAN, not from my
FIOS connection, across the internet, to somebody's DSL modem).

When firing up the "Viewer" (i.e. client) they all (naturally...)
want to know the IP address of the host.

But all they ask for is "IP Address".

No problem on the home LAN - I just type in the 168.... address
of the other box.

But in my limited understanding, that's the "private" address.

Seems tb meaningless in the context of FIOS
Router==>Internet==DSL modem.


But the WAN-side ("public"?) address doesn't seem adequate
either, since that would be the address of a router or DSL modem
- which could have more than one PC connected to it.

In another post/another thread somebody mentioned "tunneling" -
which I impute VPN tb a flavor of.

For the FIOS Router==>Internet==>DSL modem scenario I'm guessing
I need a third piece of software (besides the host and client
pieces): something to make the FIOS Router and the DSL modem look
as if they are part of a local LAN.

I *think* I've heard a couple of people describe such things -
but it's been couched in language that I only understand about
10% of.... so I haven't chosen to act on said descriptions.

When computers are on the same LAN, they can normally contact each other on
any port without firewalls or NAT interfering. When they are on different
LANs, you need to understand "port forwarding" for such tools to work.

Your router (if it is using NAT) will allow multiple private IP addresses to
share one (or several) public IP addresses. When an unsolicited request
from the Internet hits the router, the router does not know what to do since
the originating IP address isn't wrapped in the packet headers (or a
firewall explicitly denies it). You can enable port forwarding (or do it in
a firewall), that will see the request and send it to the right place. But
you need to be careful that you have some authentication method behind it.

To get around this, you can use tools like gotomypc.com or logmein.com which
create a client side connection to a common server on the internet (and have
authentication built in). When a connection request is made, the server can
talk to both clients and make the connection work.

You could also create a VPN tunnel between routers, or between one client
and the opposite router. This makes the client appear to be on the remote
lan where again, port traffic isn't blocked and you have direct access to
remote IP addresses behind the router.

John R
 
V

Vanguard

(PeteCresswell) said:
Per Vanguard:

That cuts to the part that I keep tripping over.

I've tried three different tools for connecting to another PC,
but tried them all at home (i.e. on the same LAN, not from my
FIOS connection, across the internet, to somebody's DSL modem).

When firing up the "Viewer" (i.e. client) they all (naturally...)
want to know the IP address of the host.

But all they ask for is "IP Address".

No problem on the home LAN - I just type in the 168.... address
of the other box.

But in my limited understanding, that's the "private" address.

Seems tb meaningless in the context of FIOS
Router==>Internet==DSL modem.


But the WAN-side ("public"?) address doesn't seem adequate
either, since that would be the address of a router or DSL modem
- which could have more than one PC connected to it.

In another post/another thread somebody mentioned "tunneling" -
which I impute VPN tb a flavor of.

For the FIOS Router==>Internet==>DSL modem scenario I'm guessing
I need a third piece of software (besides the host and client
pieces): something to make the FIOS Router and the DSL modem look
as if they are part of a local LAN.

I *think* I've heard a couple of people describe such things -
but it's been couched in language that I only understand about
10% of.... so I haven't chosen to act on said descriptions.


That is why I say to use the DynDNS client that runs on the host to
which you connect. It eliminates the problem of your host having an
intranet IP address versus your router having a WAN IP address.
Obviously you need to let the software firewall running on your host
allow the DynDNS client connect out to the DynDNS server so it can
tell it how to get to your host. Otherwise, without using something
like the DynDNS client on the host, you end up having to punch a hole
through your router by using port forwarding. If the router supports
DynDNS as the client, it is the router that is talking to the DynDNS
server and it is the router's IP address that gets reported to the
DynDNS server, so you have to define to which intranet host any
connects on the protocol's port to the router. For example, if you
were punching through the router to use RDP on the intranet host then
you need to connects to port 3389 to which host in your intranet has
RDP enabled. Same for VNC: you tell your client to connect to the
router's IP address on a particular port and in the router you tell it
to forward those connects on that port to whichever host you want to
connect.

It is a lot easier to run the DynDNS client on the host to which you
want to connect inside your intranet than to configure port forwarding
in the router. I started with port forwarding but eventually went
with the local DynDNS client on the host to which I wanted to connect.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top