Solved

Remote Desktop Connection over Linksys RV042 VPN tunnel

Posted on 2004-10-08
26
3,470 Views
Last Modified: 2008-02-07
I have two Linksys RV042 Cable/DSL  VPN routers at work and at our remote location.  I  can connect the two locations over The Linksys VPN, and I can ping the remote server and get a response.

The problem comes when I try to connect to the server from my XP laptop at work to the remote Windows 2003 server with Remote Desktop Connection.   I keeps getting a "Cannot conect to the remote computer" messsage.

I've made sure that the 1723 and 3389 ports are open.  I've even set up both sides with all ports open, again I can connect with the VPN tunnel and ping without a problem.

If I take my WinXP laptop to the remote location and connect locally, I can Remote Desktop to the server without a hitch.  I am not partial to the idea of the Web remote connection since it requires IIS, and I'm trying to keep the remote server lean.

I'm at a loss as to what to check next.

0
Comment
Question by:acpeed3
  • 14
  • 11
26 Comments
 
LVL 5

Expert Comment

by:netspec01
ID: 12261222
TCP 3389 is what RDP uses.   Are you connecting by IP address?  

Try another machine and see if you get the same results.
0
 

Expert Comment

by:bmirza
ID: 12261340
Just a "duh" question...

Is your WinXP firewall turned off?  I know it sounds like a stupid idea, but believe it or not, it's caused me some stress.
0
 
LVL 5

Expert Comment

by:netspec01
ID: 12261729
Yes, if your remote PC has installed SP2 ince you last looked at it, it will have any shares and inbound connections blocked by default.
0
 

Author Comment

by:acpeed3
ID: 12279114
Sorry for the delay in responding.  I've been on-site dealing with a customer with a number of "dead" workstations.  !@#$% spyware!

The remote PC is a Windows 2003 Server.  My local PC in the office is a WinXP laptop WITHOUT SP2, and the XP firewall is off.  I have all the ports open (just for now until I get things working, then I will lock it down), so 3389 is open.

For Grins and Giggles,  I turned off the firewall on my XP laptop (Zonealarm),  I then went in and connected the tunnel, and as usual, I was able to ping the remote server.  I got times of 85ms and one that was 105ms.  When I tried to use RDC, the response was "The remote connection has timed out.  Please try connecting to the remote computer again."

Help! Please!
0
 
LVL 5

Expert Comment

by:netspec01
ID: 12279365
If...
1. you can ping the host through the VPN
2. you can access the server's file shares through the VPN tunnel
3. you can do RDP to the server locally (no VPN)
4. all other traffic seems to pass through the VPN ok:


Then I'd say that your firewall/VPN is not passing the TCP 3389 requests to the server.

Next steps:
1. see if you can RDP to any other machine through the VPN
2. if yes then there is no problem with the firewall/VPN
3. if no, use a protocol anlyzer (sniffer, ethereal, TCPdump, etc) to capture traffic at the destination end.  You could even use Zone Alarm to show the connection requests.  The problem is on the server or a routing issue.

 
0
 

Author Comment

by:acpeed3
ID: 12300560
I used Ethereal to sniff the remote side.

When I initiate an RDP, I get an ESP packet going from the local Broadband IP address to the specific internal IP address of the remote server.  What comes back is an ICMP packet saying that the Local broadband IP Address is "Destination unreachable".

The local connection to the internet is cable via Road Runner, while the remote side is DSL.

Any thoughts?
0
 
LVL 5

Expert Comment

by:netspec01
ID: 12301117
The "Destination unreachable" indicates a routing issue.  This is usually sourced from a routing device.  

Is the source and destination for RDP correct in the trace?  Source should be the near side client ip address.  Destination should be the RDP server at the remote end.  Does your remote end router have a default gateway of the next hop router (ISP)?
0
 

Author Comment

by:acpeed3
ID: 12301192
Well, the source is  the company's Static IP that Road Runner assigned us, not our internal (non-routable IP of my laptop) and the destination IS the remote side internal non-routable IP address of the Server, not the Dynamic IP address issued by the DSL ISP.

 As for  Default Gateway on the remote router, it's set to the company's Static IP.
0
 
LVL 5

Expert Comment

by:netspec01
ID: 12301386
Trace your ping (which you said was successful).  Compare the source/dest to your RDP trace.  On all of the tunnels I have worked with you should see the 1) actual source IP address from LAN1 PC; 2) destination IP address of the RDP server on LAN2.  You VPN policy on each VPN device should take care of routing, whether to put the traffic in the VPN tunnel or send it out to the Internet.

PC2----LAN1-----VPN1--------VPN2-----LAN2-----PC2

Are there any other routing/NAT devices that could be interfering with the routing/NAT?  Some cable modems/ADSL modems are actually doing routing and NAT.
0
 

Author Comment

by:acpeed3
ID: 12302208
I'll look in to it, probably tomorrow.  I have a conference call about to start today.  Thanks.
0
 

Author Comment

by:acpeed3
ID: 12322005
I finally got a chance to check with the cable company.  Since we have a business Internet account, the cable modem does not have any security features activated - so says the cable company.  The DSL router does not have any security features since it is an older Cisco model.

I'm trying to get some further answers from Linksys, but it looks like this may be out of range of the Help Desk scripts.

I'm starting to think that either the cable company and/or the DSL company  may be doing some filtering, but since I'm going through a VPN tunnel, should that not protect my RDP protocol from outside filtering?

I have a feeling the eventual answer will be something simple and hiding in plain sight.
0
 

Author Comment

by:acpeed3
ID: 12322303
Some new info.  Most curious!

I remembered a utility I used to use - Superscan.  I ran it on both IP ranges while the tunnel was connected, and to my surprise RDP port 3389 was open on the terminal servers in both locations.

So what's blocking the connection?  Hmmmm......?
0
 
LVL 5

Expert Comment

by:netspec01
ID: 12327974
Here's somthing to try.  I have heard that MTU has stopped RDP connections through VPN.  On your D-Link router on the client side, look for a setting called MTU (Linksys has this setting, hopefully D-Link also).  Try setting this to something like 500.

You mentioned that you can ping the remote server through the VPN tunnel.  You can test your MTU by setting ping to NOT fragment.  Try this:

ping <remote server> -f -l 1472     <==== change the length of the packet by changing the 1472 parameter.  That's an "el" not a one.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 

Author Comment

by:acpeed3
ID: 12328638
The best MTU I got is 1298, anything higher got no response.  On the RV042 Firewall, I can set the MTU from Auto to manual and enter a size.  I had tried this earlier with a size of 1380 using ping with the flags.  Since it now appears to vary, maybe it needs to be lower.  Possibly I need to start low, like 500, and increase it as I test.

I think I can set Terminal Services 2003 to use a lower MTU, but I've yet to find how or where.

Oh, when the tunnel is connected, at Linksys' suggestion, I found if I do RUN \\192.168.1.50, then I get an explorer window of the remote server and can open shared drives and folders on the server.  In Googling this, I've seen some people say that to use RDP ov VPN, in the "Computer" line for the connection you need to put the Fully Qualified Domain Name (FQDN) for the computer, AND the domain needs to end in .local not .com.  I've also seen I need to us "IP and FQDN" in setting the Local Security Gateway Type for both sides on the Tunnel configuration.

I still got the feeling it is something simple, something stupid that is not set or configured correctly.

Thanks

0
 
LVL 5

Expert Comment

by:netspec01
ID: 12328900
>In Googling this, I've seen some people say that to use RDP ov VPN, in the "Computer" line for the connection you need to put the Fully Qualified Domain Name (FQDN) for the computer, AND the domain needs to end in .local not .com.  I've also seen I need to us "IP and FQDN" in setting the Local Security Gateway Type for both sides on the Tunnel configuration.

FQDN or ip address it doesn't matter.  If the FQDN resolves to the correct ip address it shouldn't make any difference.  If your tunnel is up and you are able to do RUN \\server and get an explorer window you have made it past any VPN negotiation issues.

Try the MTU at some smaller values and report back.
0
 

Author Comment

by:acpeed3
ID: 12333020
If I set the MTU on the routers, then pinged with the flags, I had to go to lower sizes than what I had set. Hmmm.

I did some more digging, and found on Microsoft Knowledge Base #120642 where to set in the registry activating TCP's  ability to detect "Black Hole" routers, and make TCP discover the Maximum MTU - two registry additions.  It's not there in WinXP nor WinServer 2003.  I have to go set the remote side so I''ll report later on this.

Thanks
0
 
LVL 5

Expert Comment

by:netspec01
ID: 12333083
If you set your router to a lower value it should force your PC to use that value (or smaller).  Did you try to do the RDP after setting to a lower value.  You should only have to make changes on the initiating end of your VPN.

I'll look at the KB article.  I have a similar problem that is probably black-hole/MTU that I will be working on tomorrow.  Normally the network devices will be aware of max MTU and this is taken care of automatically.
0
 

Author Comment

by:acpeed3
ID: 12333440
Woo-Hoo!!!!

At the remote site I was able to Remote Desktop to my test server at work, yea!

The only change was the addition of those two tcp settings in the registry.  I'm not willing to say this is fixed yet until I get to work tomorrow afternoon and try connecting from work to the remote site, but it looks promising!

"Normally the network devices will be aware of max MTU and this is taken care of automatically."  Yeah, but we're talking about a Microsquish product here, so anything goes. <g>

Thanks

P.S.  I thought I was the only one silly enough to work on his/her days off.  <g>  Though I did it this weekend so I could work without being interrupted with whiny, crybaby customer issues.  We actually had one call from a customer this Spring about our system not working.  It took ten minutes before we dragged out of them that the electric power in the area had been cut off to repair the lines from a tornado!!!  Honest, the customer couldn't figure out why our system could not run with the power off!  <!@#$%^&* customers!>
0
 

Author Comment

by:acpeed3
ID: 12334794
It turns out I had to run an errand that was near work, so I stopped in to test RDP from the local side.  Nope, work side cannot connect with the remote site.

I'm going to focus on Monday on both routers, it has to be a setting on one of them.  I do think the two registry additions are part of the fix.  I just need tofind out what the fix on the router(s) is.
0
 

Author Comment

by:acpeed3
ID: 12349905
The more things change, the more they stay the same.

I can still only RDP in from the remote site to an Office server.   If I try to RDP from the Office to the Remote Server, it now takes a while then times out with "A licensing error occurred while the client was attempting to connect (Licensing timed out) Please Try connecting to the remote computer again" error.

Today I blew the remote server away and rebuilt it fresh.  I could RPD into it from the remote site's LAN, but not from the office over the VPN tunnel to the remote site. <sigh>  I can still RPD from the remote site to the Office test server.  The one way I REALLY need RDP to function, is the one that doesn't work.  

Any suggestions, insights, or winning lottery numbers for tonights drawing?

Thanks.
0
 
LVL 5

Expert Comment

by:netspec01
ID: 12354683
>"A licensing error occurred while the client was attempting to connect (Licensing timed out)

You may want to follow up on this error and look at the event log.  Term server licensing is only required when you have a server in "application serving mode".
0
 

Author Comment

by:acpeed3
ID: 12359053
The remote server only has Terminal Server and File Server roles activated.  What I did not have active on the remote server was Active Directory.  I decided that since the server at work DOES have Active Directory running and I can RDP to it, that AD may be a factor.

I install AD on the remote server as a different domain from work.  Today at work I ran RDP and got the RDP screen! (yay!), but no desktop,(phooey!).

It's fighting us tooth and nail, but we're slowly wearing it down! <g>
0
 
LVL 5

Accepted Solution

by:
netspec01 earned 500 total points
ID: 12370256
> Today at work I ran RDP and got the RDP screen! (yay!), but no desktop,(phooey!).

I am not sure what results you had here.  Were you able to enter you credentials and get authenticated?
0
 

Author Comment

by:acpeed3
ID: 12370902
I ran Ethereal on the remote server yesterday, and from what I can see I logged on, but that's it.

It can't be the cable company or the DSL company filtering packets since it's all going through the VPN.

All  of the sudden I can't get the tunnel to connect, nor can I remote in to manage the router at work.  I'll have to check that out when I get to the office.  
0
 

Author Comment

by:acpeed3
ID: 12374277
IT WORKS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I had changed a number of things so I'm not sure what the real fix was. but here is the list

1.  I removed Active Directory from both servers, since I think it just added more complexity to the connection process.
2.  Linksys just released a firmware upgrade for the RV042.  I went from Version 1.2.3 to version 1.3.1, and it had a long list of fixes.
3.  I found on the remote router under SETUP -- FORWARDING, I found that for the RDP the service when I added it, I missed the ENABLE checkbox.  DOH!

Netspec1, you were a big help to me.  Your suggestions helped to keep me from wasting time on a lot of  blind alleys, and you stayed in there with me.  I assigning you the points.

Thanks,

Al
0
 
LVL 5

Expert Comment

by:netspec01
ID: 12380572
glad to help!
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

Sometimes you might need to configure routing based not only on destination IP address, but also on a combination of destination IP address (or hostname) and destination port number. I will describe a method how to accomplish this with free tools. …
Many of us in IT utilize a combination of roaming profiles and folder redirection to ensure user information carries over from one workstation to another; in my environment, it was to enable virtualization without needing a separate desktop for each…
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…
You have products, that come in variants and want to set different prices for them? Watch this micro tutorial that describes how to configure prices for Magento super attributes. Assigning simple products to configurable: We assigned simple products…

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now