Remote Desktop keeps freezing from home to work only

June 7, 2007 8:48 AM

Problem: Remote Desktop freezes after the login screen and refuses to allow client to connect to the server computer. This problem only occurs from the home ip to the work ip but not from any other ip address to work.

I have a client that has dell p4 Windows XP pro SP2 server on a static DSL IP that they remote access using windows remote desktop from home on their Sony VAIO Intel Centrino Windows XP Media Center Edition 2005 and time warner cable high speed. IT has worked for 2 years and it quit working monday. Here is the problem they can no longer remotely access the server from home it will work for any other connection including a twc one but not from home. At home they can remote to test servers I setup at alternate ip addresses but not to test servers at the work ip or even the work server.

Things I have tried:
1. reset of all equipment on both ends
2. Verification of the correct configurations on the routers
3. Checked the MTU settings on both routers 1492
4. Turned off themes and bitmap caching in remote desktop
5. changed the screen resolution to be 800x600 at 256 bit color on the laptop and in remotoe desktop and made the remote server match
6. turnned of the firewalls on the dell and disable norton 2006 on the laptop and all of its features. nothing.
7. DId the obligatory scans for spyware and viruses using hitman pro for spyware and running all of those tools in paid mode. Scaned for Viruses with AVG, Avast and Antivir
8. checked on MS technet they said I needed to upgrade to the newest version of terminal services. I did it did not help.
9. I changed the MTU on both sides to 1492 since that is the suggest from SBC for PPOE dsl connection prior it was 1500 in both locations
10. I installed tightvnc and they still cannot get home access for the computer it will connect, prompt for a password and freeze after 1/2 of the screen is loaded and die which is better than remote desktop that wont even load the screen

::EDIT:: I just tried putting the server in the dmz on the router still no good. I genuinely believe it has something to do with somehting one of the isp's has changed. Nothing new has been installed on the computers in ages other than windows updates.

I found this article and I have a almost the same problem but I cannot get his results
Remote Desktop
http://www.quest4.org/etc/rda-blackscreen(no_login).htm

I just don't know what else to do I am working the search engines and not really finding much helpful

Any help or suggestions would be greatly appreciated its killing me here

posted by the_binary_blues to Computers & Internet (12 answers total)

So you are behind some kind of router at home? Or what do you mean with "putting the server in the dmz ...".
posted by donut at 8:52 AM on June 7, 2007

the home connection is behind a netgear router wgt624
the work connection is behind a linksys router BEFSX41
I put the work server into the dmz portion of the linksys router and I still could not connect from the home ip
posted by the_binary_blues at 9:07 AM on June 7, 2007

Can you move the "Home PC" to another location? Can you try a laptop or some other PC at the home location?

At this point it could be either PC or network, and I would tend to believe it's the PC, and not the network. But that's just hunch, with no basis for that conclusion.
posted by stovenator at 10:26 AM on June 7, 2007

I tried my mac using remote desktop at the home location and also tried my windows xp pro sp machine on there as well still nothing. IF I move the home laptop to another location it is able to connect to the server.
posted by the_binary_blues at 11:39 AM on June 7, 2007

You then might try the following:

1. Plug the HomePC directly into the cable modem (powercycle the cable modem to release the MAC ), and see if it can connect. I assume this will work. If it does, it means the router config at home is to blame. If not, could be a TWC issue. Put the HomePC back behind the router.

2. I'm betting at this point, it's an MTU issue. Newer RDP clients have the Do Not Fragment bit set, and it's possible Windows Update upgraded your RDP client. Try lowering the MTU even further (1400, 1300, etc.).

(after a little more research, see this thread )

If that doesn't fix it, try the following:

3. Put the HomePC in the DMZ. See if there's a firewall issue with the router.

4. Try turning port forwarding on at home, pointing port 3389 at the HomePC.

5. Try connecting both wired and wirelessly to the WGT624.
posted by stovenator at 12:10 PM on June 7, 2007

@stovenator

would the mtu issue affect vnc as well?
just wondering why would I like to foward port 3389 to the home pc?
posted by the_binary_blues at 12:18 PM on June 7, 2007

do I change the MTU on the router on the actual NIC's
I have changed the one on the router but I take that as along w/ the forum link I need to change the mtu on the actual network cards.
posted by the_binary_blues at 12:20 PM on June 7, 2007

3,4,5 are just other things I would try if the above things didn't fix it.

The router should report the MTU to all of the PC's , as long as ICMP traffic is not being blocked. This means that you should be able to set it on the router, and have everything work.

Yes, the MTU could affect VNC, although I'm not entirely certain. I think VNC creates an encrypted tunnel, and if so, fragmented packets could cause a problem in reassembling those datagrams.
posted by stovenator at 1:10 PM on June 7, 2007

ok I did 1,3,4,5 and five nothing. now I am messing with the MTU's do I need to mess w/ both mtu's or just the home connection since I am able to access the server from other locations?
posted by the_binary_blues at 1:21 PM on June 7, 2007

ok so according to to the link that was given for a site to site vpn + RDP I ran the
ping -l 1500 -f command and found out that while the mtu on the router was 1492 at work it was running at 1470 really and changing it to 1470 dramatically speed up the pings and the tracert's however it still did not allow for connection from home. I am getting ready to drive over to the home to work on settings there
posted by the_binary_blues at 2:18 PM on June 7, 2007

Some sites suggest that for PPPoE connections, you should set a lower MTU - 1400 is a safe (but slightly low) value. I'd try setting both endpoints to this - don't set the routers to a lower value than the endpoints otherwise you'll be fragmenting your traffic even before it gets out of the building.

As a complete guess, I'd suggest that somewhere between 'home' and 'office' there's a filter that's stopping ICMP traffic - whether that's at a point that you can control or elsewhere - ICMP is needed for MTU Path Discovery but over zealous firewall admins often block all ICMP traffic.
posted by koshmar at 2:34 PM on June 7, 2007

the problem is solved amazingly enough. Thanks to all of you for you help. The problem was the MTU size on the home connection.
The Office connection was 1492 and that was the same as the setting on the home router. The issue actually was on the cable modem.
I Logged onto the modem and disabled the SPI firewall and changed the mtu size to 1473 on the modem and everything worked perfectly.
IF I turned the SPI firewall on the modem on it would not work. If I raised the mtu to 1474 I would have packets drop and at 1475 or higher it would not work.
So thank you all of you for all of your help and suggestions. You rock.

::EDIT 2:: the ICMP traffic both in and out was being limited by the modem. I still think that the traffic is being limited a point further down than the modem due to the discrepency in size

whenever i use this comand

ping -l 1500 -f

and change the mtu size above its current setting from the home connection to any ip address I get this message
Packet needs to be fragmented but DF set.
and when I do a tracert with that large of a packet actually configured I get "request timed out"

therefore:

Should I drop the office MTU down to match the home or leave it as is now?
posted by the_binary_blues at 6:11 PM on June 7, 2007