Remote Desktop Connection over Linksys RV042 VPN tunnel

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.

acpeed3Asked:
Who is Participating?
 
netspec01Connect With a Mentor Commented:
> 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
 
netspec01Commented:
TCP 3389 is what RDP uses.   Are you connecting by IP address?  

Try another machine and see if you get the same results.
0
 
bmirzaCommented:
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
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

 
netspec01Commented:
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
 
acpeed3Author Commented:
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
 
netspec01Commented:
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
 
acpeed3Author Commented:
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
 
netspec01Commented:
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
 
acpeed3Author Commented:
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
 
netspec01Commented:
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
 
acpeed3Author Commented:
I'll look in to it, probably tomorrow.  I have a conference call about to start today.  Thanks.
0
 
acpeed3Author Commented:
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
 
acpeed3Author Commented:
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
 
netspec01Commented:
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
 
acpeed3Author Commented:
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
 
netspec01Commented:
>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
 
acpeed3Author Commented:
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
 
netspec01Commented:
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
 
acpeed3Author Commented:
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
 
acpeed3Author Commented:
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
 
acpeed3Author Commented:
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
 
netspec01Commented:
>"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
 
acpeed3Author Commented:
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
 
acpeed3Author Commented:
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
 
acpeed3Author Commented:
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
 
netspec01Commented:
glad to help!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.