Remote Desktop Control thru VPN, did work! Not now (sigh)...

[Doc]

It was going so well...
I've been able to setup VPN.
I've been able to setup Remote Desktop Connections
I've been (at one location) able to 'tunnel' the RDC thru the VPN.

BUT another SITE is giving me fits. I can VPN and get connected.
I can Remote Desktop Connect and have full control over the desktop
behind the Netgear RP614v2 -
With VPN, I've port forwarded to the defualt PORT (1723, although in
the Netgear it is a preconfigured PPTP setting - but it works as VPN
and I connect VPN from the remote computer instantly.

UNLIKE the other setup, I CANNOT gain remote control over the desktop
thru the VPN. I can get RDC to work by just bypassing VPN and opening
the default port (but I will be RDC to three others and I wanted to
just come thru the ONE PIPE, VPN_)...

Perhaps I don't understand the TWO in combo (and it was just dumb
luck that got the first one running at a different location)...
I've followed the VPN client and server setup and it works.
I've setup the 'server' (in the VPN chain) to "AlLOW REMOTE DESKTOP
CONTROL" and used a single USER (who, BTW, is the same NAMED user
and SAME given P/W as the user at the "client" end of the VPN tunnel)

The Remote Desktop Connection efforts are just not connecting.
I have entered several different IP addresses (in an attempt to
see if ANYTHING will connect)...
I initially used ONE of the ASSIGNED IP addresses that I name in
the 'server side' setup for VPN - they are the same class exactly
as the 'server' side LAN and, being private, the same CLASS SCHEME
as the DHCP assigned 'client' IP address (provided by that end's
ISP setup of that Modem/router - it is using DHCP and only three
IPs are leased out). All thru the VPN, no VPN? Works nicely thru 3389.

I could not connect. So tried the IP address of the "server" PC as
it IS given in that LOCAL LAN - no go.
I tried the OTHER (called the Client IP) address provided in the
VPN server setup, no go.

I did even try the IP address (static) of the WAN side of the
MODEM/Router (I know, I know) and it wouldn't go.

Any help is GREATLY appreciated..
Thanks.

 

[Bill Sanderson]

Are the addresses at the far end of the VPN tunnel on the same subnet as
those on your end?

If your target host machine is the one terminating the VPN tunnel, I'd go
for whatever IP address is specified in the VPN connectoid (down by the
clock, status, details) as the "server ip address."

You've got the right instinct--you want a single pipe to put you on the lan
at the far end, able to address any given machine with RD--and this should
be possible, if you can get the IP addressing right.

Since this is all private addressing we are talking about (if not, why not
just leave off the last part if the addresses)--it'd be easier for me to
visualize if you could just tell us straight out what the addresses
are--those given out by DHCP at the host end, those you've specied for the
VPN use at the host end, and those in use at the client end--and those that
actually appear in properties of the tunnel when it's open.

 

[Doc]

Bill Sanderson typed this:

Are the addresses at the far end of the VPN tunnel on the same subnet as
those on your end?

Absolutely! Private Scheme - 192.168.0.xxx / the subnets on both LANS
are default

If your target host machine is the one terminating the VPN tunnel, I'd go
for whatever IP address is specified in the VPN connectoid (down by the
clock, status, details) as the "server ip address."

Yes... that is right and what I am using.

You've got the right instinct--you want a single pipe to put you on the lan
at the far end, able to address any given machine with RD--and this should
be possible, if you can get the IP addressing right.

I'm hoping I can get it running. As I mentioned, can VPN by itself. Can
Remote Desktop by itself, can't mix 'em. Think this could be MTU?????

Since this is all private addressing we are talking about (if not, why not
just leave off the last part if the addresses)--it'd be easier for me to
visualize if you could just tell us straight out what the addresses
are--those given out by DHCP at the host end, those you've specied for the
VPN use at the host end, and those in use at the client end--and those that
actually appear in properties of the tunnel when it's open.

Sure the "client" or controlling PC is 192.168.0.XXX
The "host" or server PC is 192.168.0.xxx
The 'VPN' provided addresses are not DHCP selected, but manually
entered and DO show up in the 'connectoid' in the lower right , both
are Class C, private scheme (192.168.0.x - and NONE of the provided
VPN IP addresses are IN USE at either end - but I AM double checking
that!)...

Many thanks... head has big bruise from beating it against the wall. If
I come up with the answers it will be posted here. Thanks again.

 

[Bill Sanderson]

Pick whichever end of the link is easiest to change--perhaps your end, for
now, and change the subnet to a different one: Say, 192.168.2.x

Bill Sanderson typed this:

Are the addresses at the far end of the VPN tunnel on the same subnet as
those on your end?

Absolutely! Private Scheme - 192.168.0.xxx / the subnets on both LANS are
default

If your target host machine is the one terminating the VPN tunnel, I'd go
for whatever IP address is specified in the VPN connectoid (down by the
clock, status, details) as the "server ip address."

Yes... that is right and what I am using.

You've got the right instinct--you want a single pipe to put you on the
lan at the far end, able to address any given machine with RD--and this
should be possible, if you can get the IP addressing right.

I'm hoping I can get it running. As I mentioned, can VPN by itself. Can
Remote Desktop by itself, can't mix 'em. Think this could be MTU?????

Since this is all private addressing we are talking about (if not, why
not just leave off the last part if the addresses)--it'd be easier for me
to visualize if you could just tell us straight out what the addresses
are--those given out by DHCP at the host end, those you've specied for
the VPN use at the host end, and those in use at the client end--and
those that actually appear in properties of the tunnel when it's open.

Sure the "client" or controlling PC is 192.168.0.XXX
The "host" or server PC is 192.168.0.xxx
The 'VPN' provided addresses are not DHCP selected, but manually
entered and DO show up in the 'connectoid' in the lower right , both
are Class C, private scheme (192.168.0.x - and NONE of the provided
VPN IP addresses are IN USE at either end - but I AM double checking
that!)...

Many thanks... head has big bruise from beating it against the wall. If
I come up with the answers it will be posted here. Thanks again.

 

[Doc]

Bill Sanderson typed this:

Pick whichever end of the link is easiest to change--perhaps your end, for
now, and change the subnet to a different one: Say, 192.168.2.x

Ouch.. have six on this end and 35 on the other end... so my end is
'easier'...
Let me ask a (perhaps) subjective question. Leaving aside multiple
Remote Desktops 'in' (which I do want thru VPN), are there ANY
security benefits doing the Remote Desktop 'thru' a VPN (I mean they
are both 128 bit encrypted...)

Also, purely on an aside... I need to COPY files from the 'server/host'
to the 'client' computer in Remote Desktop??? Any way to print a file
from the 'server/host' to a local 'client' printer? Anyone?????

Many thanks.

 

[Bill Sanderson]

Ouch. If you are connecting to lots of remote locations, pick a 10.x subnet
at your end.

VPN benefits (PPTP): The RDP protocol by itself is susceptable to a
man-in-the-middle attack. Adding VPN on top adds some additional protection
against such an attack. I've no idea whatsoever how to quantify the
importance of this vulnerability, or the added protection.

If you set your local drives to be visible at the host, you can copy files
via Remote Desktop. It will be somewhat faster to do the same copy via VPN
and network shares.

Printing is an easy one. RDC is designed to set the client's default
printer as the default printer for the RD session at the host. The printer
port is redirected, and the driver for the client printer must be available
at the host. There are glitches to this mechanism, primarily for
USB-connected printers using a DOT4 port at the client end. The event log
at the host end will have useful clues if this doesn't work. Look for either
nothing (port not getting redirected) or messages about missing drivers.

Bill Sanderson typed this:

Pick whichever end of the link is easiest to change--perhaps your end,
for now, and change the subnet to a different one: Say, 192.168.2.x

Ouch.. have six on this end and 35 on the other end... so my end is
'easier'...
Let me ask a (perhaps) subjective question. Leaving aside multiple Remote
Desktops 'in' (which I do want thru VPN), are there ANY
security benefits doing the Remote Desktop 'thru' a VPN (I mean they
are both 128 bit encrypted...)

Also, purely on an aside... I need to COPY files from the 'server/host'
to the 'client' computer in Remote Desktop??? Any way to print a file
from the 'server/host' to a local 'client' printer? Anyone?????

Many thanks.

 

[Doc]

Bill Sanderson typed this:

Ouch. If you are connecting to lots of remote locations, pick a 10.x subnet
at your end.

The "client" end will have only three IPs so I can change 'em easy 'nuff'.

VPN benefits (PPTP): The RDP protocol by itself is susceptable to a
man-in-the-middle attack. Adding VPN on top adds some additional protection
against such an attack. I've no idea whatsoever how to quantify the
importance of this vulnerability, or the added protection.

Very interesting. I have forwarded the routers logs to me every hour so
I can see, but you know some are just to 127.0.0.0 -

If you set your local drives to be visible at the host, you can copy files
via Remote Desktop. It will be somewhat faster to do the same copy via VPN
and network shares.

By 'visible', do you mean shared?

Printing is an easy one. RDC is designed to set the client's default
printer as the default printer for the RD session at the host. The printer
port is redirected, and the driver for the client printer must be available
at the host. There are glitches to this mechanism, primarily for
USB-connected printers using a DOT4 port at the client end. The event log
at the host end will have useful clues if this doesn't work. Look for either
nothing (port not getting redirected) or messages about missing drivers.

Great. That helps me. The 'client' end printer is just a LPT HP deskjet.
I'll install the drivers at the other end... good to know. Still trying
to get the VPN to 'tunnel' the Remote Desktop... weired. Thanks.

 

[Bill Sanderson]

If you are connecting to XP, and the printer is supported by XP out of the
box, there's probably nothing to install--try it out.

Drives:

Remote Desktop Connection
Options
Local Resources
Local Devices

Check off Disk Drives.

Open My Computer on the host to find all client drives listed after all
drives at the host end.

You will get a security warning upon attempting the connection. Both
viruses and "company secrets" can be passed via such a connection.

Security: Put in MS04-007. (that goes for everyone!) Use a strong
password. Log both successful and unsuccessful authentications. An account
lockout is a good idea.

I've no idea what to make of the man-in-the-middle issue. This is
"published"--i.e. you can google it, and I've seen it acknowledged by
Microsoft staff. Microsoft's published articles about RDP show it used over
a VPN tunnel.

 

[Doc]

Bill Sanderson typed this:

If you are connecting to XP, and the printer is supported by XP out of the
box, there's probably nothing to install--try it out.

Drives:

Remote Desktop Connection
Options
Local Resources
Local Devices

Check off Disk Drives.

Open My Computer on the host to find all client drives listed after all
drives at the host end.

You will get a security warning upon attempting the connection. Both
viruses and "company secrets" can be passed via such a connection.

Security: Put in MS04-007. (that goes for everyone!) Use a strong
password. Log both successful and unsuccessful authentications. An account
lockout is a good idea.

I've no idea what to make of the man-in-the-middle issue. This is
"published"--i.e. you can google it, and I've seen it acknowledged by
Microsoft staff. Microsoft's published articles about RDP show it used over
a VPN tunnel.

Ain't it the truth. I've read and re-read all of MS VPN and Remote
Desktop connections and have not found anything I've *not* tried. DANG.
Just get the basic 'network is busy or maybe you don't have rights' and
neither is true. Will look some more. thanks for the help and ideas...
Also posted at dslreports and nothing coming up there either. Will post
if I get a solution.

 

[Bill Sanderson]

You're welcome--hope it straighten's itself out--I don't see what you are
doing wrong.

 

[Doc]

Bill Sanderson typed this:

You're welcome--hope it straighten's itself out--I don't see what you are
doing wrong.

Unknowing to me, an outside vendor installed a networked copier and
'stole' a static IP Address. Wouldn't you know that the ONE he selected
was the "VPN *server* (as in workstation/host, not real server) IP
Address"?! Tuesday I'll resubmit the VPN with unused IP addresses and
SEE IF I can Remote Desktop Control thru that connection as I could
earlier. Believe that the 'multiple' use of the IP address is a no-no
;^)...
Thanks.

 

[Bill Sanderson]

That could definitely break it!
You cannot have duplicate IP's on the network--the first one wins.
I can see where he might have grabbed it--it wouldn't be visible
anywhere--but he should have asked!

 

[Doc]

Bill Sanderson typed this:

That could definitely break it!
You cannot have duplicate IP's on the network--the first one wins.
I can see where he might have grabbed it--it wouldn't be visible
anywhere--but he should have asked!

It is working now, that was the problem.

 

[Bill Sanderson]

Terrific!

Bill Sanderson typed this:

That could definitely break it!
You cannot have duplicate IP's on the network--the first one wins.
I can see where he might have grabbed it--it wouldn't be visible
anywhere--but he should have asked!

It is working now, that was the problem.