Archived from groups: microsoft.public.windowsxp.work_remotely (
More info?)
If this is true then the remote desktop client will need to know the correct
router address to connect-to with mstsc, which would be available via
traceroute from the wireless client to any internet host on the second hop,
i.e. Localhost-> Default Gateway -> ISP Router WAN Port.
This is probably not going to happen, as I doubt the ISP will do a one to
one NAT for them so they can forward 3389 to a specific private address.
Patrick Rouse
Microsoft MVP - Terminal Server
http://www.workthin.com
"Sooner Al" wrote:
> Patrick,
>
> If you read back in the thread the gentleman seems to being trying to reach a PC (in Brazil) that is
> connected to a wireless ISP of some sort. The PC is getting an address in the private range. They
> claim there is no firewall/NAT/router involved at the host site... That is why I suggested, in one
> of my replies, that the folks in Brazil get hold of the ISP to sort this out as far as opening TCP
> Port 3389...
>
> --
> Al Jarvi (MS-MVP Windows Networking)
>
> Please post *ALL* questions and replies to the news group for the mutual benefit of all of us...
> The MS-MVP Program -
http://mvp.support.microsoft.com
> This posting is provided "AS IS" with no warranties, and confers no rights...
>
> "Patrick Rouse [MVP]" <PatrickRouseMVP@discussions.microsoft.com> wrote in message
> news:99A4041E-EF0A-4C41-8C8C-6349723CAAD4@microsoft.com...
> > 1. Port forwarding is done by you, not your ISP, although I have seen ISPs
> > that block TCP Port 3389 on their routers, in which case you'd have to
> > configure Terminal Server to listen on a different port. If the remote
> > computer can not telnet to port 3389 of the destination computer then Remote
> > Desktop will not work with the default configuration.
> >
> > Screenshot of port forwarding with a Linksys router:
> >
http://workthin.com/images/LinksysPortForwarding.JPG
> >
> > 2. The only time you can directly address a Private IP Address is if it's
> > on your network, i.e. not separated by the Public Internet. For a person to
> > allow traffic to their computer from the public internet (when they're behind
> > a NAT firewall) they forward trafic addressed to the firewall's WAN port to
> > their specific private IP Address for the type of traffic they desire, i.e.
> > TPC/UDP Port number. The remote user addresses the Firewall's WAN IP
> > Address, NOT the private IP Address of the destination computer.
> >
> > 3. A class or book on Cisco Routing Fundamentals or Networking Fundamentals
> > would make the IP Addressing a lot clearer.
> >
> > Free online tutorial:
> >
http://www.ind.alcatel.com/fundamentals/index2.html?pass=true
> >
> > Book:
> >
http://www.ciscopress.com/title/1587050676
> >
> >
> > Patrick Rouse
> > Microsoft MVP - Terminal Server
> >
http://www.workthin.com
> >
> >
> > "Patrick Rouse [MVP]" wrote:
> >
> >> Can the remote client connect to any Terminal Server on the Public Internet?
> >> This would be the first thing I would verify. If you do a search on Google
> >> for Remote Desktop Web Connection, many public connections are listed (while
> >> admins should probably block robots/spiders from picking these up) which
> >> could be used to test your connectivity. I'm not recommending trying to
> >> logon to any of them, but if you can get to their GINA Logon then you're
> >> connected over port 3389 and know that the remote computer is working
> >> properly.
> >>
> >> Another thing you will have a problem with is a highly latent connection,
> >> regardless of the measured thruput. 20Kbps is barely enough bandwidth to
> >> work over a 800x600 desktop at 256 colors with mediocre performance when
> >> latency is not a problem, but when you add a high latency to the connection
> >> the performance may reach abismal.
> >>
> >> The lowest speed connection I've found to be sufficient for a working RDP
> >> session @ 800x600 & 256 color depth is 26.4Kbps.
> >>
> >> As far as VPNs go, I not only do NOT recommend them for securing RDP
> >> connection, but believe that unless they are managed IPSec/L2TP VPNs that
> >> they are a security risk as you're allowing any garbage or services on the
> >> remote computer to directly interact with a corporate network. PPTP VPNs add
> >> zero extra security to an RDP Session, as the tunnel is setup with the
> >> credentials provided by the end-user, not by PKI based certificates.
> >>
> >> Secondary authentication (i.e. Safeword or SecureID) is a better way to
> >> increase the already solid security of Windows Terminal Server, whether using
> >> RDP or ICA protocol.
> >>
> >> Patrick Rouse
> >> Microsoft MVP - Terminal Server
> >>
http://www.workthin.com
> >>
> >> "Bill Sanderson" wrote:
> >>
> >> > Keep talking to Al, but I just want to reiterate that the VPN is not
> >> > necessary for RD to work, nor is the VPN needed so that the information
> >> > being transmitted is encrypted.
> >> >
> >> > A VPN connection does make the connection more secure--less susceptable to
> >> > certain types of attacks--"man in the middle" attacks.
> >> >
> >> > You can definitely work without it and many of us do, regularly.
> >> >
> >> > "Daniel Rascoe" <danielrascoe@hotmail.com> wrote in message
> >> > news:uWcXgOzpEHA.3464@TK2MSFTNGP14.phx.gbl...
> >> > >I want to remotely control a computer that has Windows XP Pro SP2 on it.
> >> > >I'd like to use remote desktop in the simpliest configuration. Can I use RD
> >> > >without a VPN connection? Should I be using something other than RD? FYI,
> >> > >the client computer is running windows 2000 pro SP4. I've followed the
> >> > >directions at
> >> > >
http://www.microsoft.com/windowsxp/using/mobility/getstarted/remoteintro.mspx
> >> > > But I can't seem to get RD to work.
> >> > >
> >> > > Daniel
> >> > >
> >> >
> >> >
> >> >
>
>