[ previous ] [ next ] [ threads ]
 
 From:  "Chris James" <lists at chrisjames dot me dot uk>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Remote Desktop via NAT
 Date:  Fri, 06 May 2005 21:26:41 +0100
Hi All,

This is a post with information for people searching the archives in the
future, born out of my frustration in trying to get remote desktop
working. My set up is:

* Windows Remote desktop (RDP) server (windows 2000 terminal server)
  behind a monowall 1.1 box doing NAT.
* m0n0wall with port 3389 forwarded from WAN to the internal IP of the
  server, and with the equivalent firewall rule in place.
* Remote computer #1 with direct leased line connection to internet
* Remote computer #2 via a NAT home router connected to Cable Broadband
  - in this case a D-Link DI-624+ connected to NTL in Leeds, UK

My symptoms were:

* Computer #1 (Leased line public IP) could connect perfectly to the
  Remote Desktop server
* Computer #2 (Cable, NAT) simply timed out on every connection with the
  error: "The remote connection has timed out. Please try connecting to
  the computer again."

Solution:

To cut a long story short... in the WAN settings of my D-Link router,
the MTU of the connection was set to 1500. By reducing it to 1400 it
works. Apparantly, remote desktop protocol has a problem with fragmented
packets, and obviously somewhere down the line, a router with a lower
MTU was fragmenting me.

Further info:

What is MTU? http://www.webopedia.com/TERM/M/MTU.html Changing the MTU
in D-Link routers:
http://support.dlink.com/faq/view.asp?prod_id=1297&question=General-Routers
Changing the MTU with Dr. TCP on the client (note this was not required
for me - but I did use to get the 'safe' number of 1400):
http://kbserver.netgear.com/kb_web_files/n100603.asp Changing the MTU in
the registry: (again, not required by me - but possibly useful if you
have a similar problem, but have a machine directly connected to the
broadband network, not via a NAT router):
http://www.adslguide.org.uk/guide/mtu.asp

Hope this might help people with similar problems in the future.

Chris.
-- 
  Chris James
  http://www.chrisjames.me.uk