XRDP via SSH session

To make use of Windows Remote Desktop Client to connect to Graphical X session on Ubuntu Linux server, there are three basic components that would help make a secured connection:

XRDP server

SSH server

VNC server

XRDP protocol would be used to forward VNC session to Windows RDC. For security reason, it will be done through the data encapsulation by using SSH tunnel.

The benefit is that it doesn't require the client to install VNC viewer and use standard Remote Desktop Client on Windows computer.

For better security, Putty will be used to create SSH connection first and do the port forwarding as follows:

For example:

Port 5555 (client port, any other port than 3389 or 3390) => localhost:3389 (remote server port)

On the server, Firewall rules restrict that only SSH port is open to the users for connection. Through SSH session, we can connect it with Windows RDC by using URI like:

localhost:5555

Before all these happen, we need to make sure that SSH server, VNC server and XRDP server are installed  and configured properly on Linux server.

Use the following commands to install all required servers:

$ sudo apt-get install openssh
$ sudo apt-get install vnc4server
$ sudo apt-get install xrdp

Just skipped SSH and VNC setup whereas you could find lots of references on the other forums.

For XRDP, we need to make a little adjustment on the file "/etc/xrdp/xrdp.ini" .

Depending on the setup of vnc4server, you need to define the VNC port to be forward by XRDP protocol. Under the section "xrdp1" in the file "xrdp.ini", please comment out the line of "port=-1" and add a working VNC port for use, i.e., port=5901.

[globals]
bitmap_cache=yes
bitmap_compression=yes
port=3389
crypt_level=low
channel_code=1

[xrdp1]
name=sesman-Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
#port=-1
port=5901

Then restart XRDP service:

$ sudo service xrdp restart

Now, it's time to test from the client side by initiating SSH connection using Putty client.

Then open Remote Desktop Client on Windows comptuer with the URI:

localhost: 5555

You should a GUI login screen for xrdp session. Using linux username and password, you can login to VNC session like what a VNC viewer normally does.

Enjoy your RDC!

Back to the old school days of TCP/IP

Just imagine that you are hosting your favorite web site which loads smoothly at your side, even at home, on the bus or in the coffee shop. Til one day, you received a complaint from your old school friend who challenged that you might have really poor web authoring skills. Sometime, what he had seen was a blank page while he was visiting your web site. Blank, in that way, white color with no extra icon, text or even error message, purely blank. Pressing [Refresh] button and things appear again. It sounds like you have been hosting a broken web server. Anyway, it was fine to visit any other web sites from your friend's computer except this one.

"Is the web site crippling enough for me to visit?!!", you might ask. No worry, there is nothing wrong with the web server. Bad client settings of web browser? Maybe.

However, you might not work out how the web browser actually works to display a blank page like this. This, in my opinion, indicates that the web traffic doesn't actually come through. Internet is a huge network coordinated by different routing equipment. They can be linked up with fiber optics, copper wires or even wireless signal in the air. Along the years, the speed of Internet is growing faster than ever before. People change their gears from a wired 56K modem to nowadays USB/built-in Wi-Fi adapter up to 300mbps in transmission. They might forget those days while scientists were excited about the data packets being sent through a co-axial cable successfully.

There are some articles reviewing one of the common TCP/IP features called TPC extensions for high performance network, a.k.a., RFC1323. You may have interest to have a look at the request for comment like this in bare text format which was dated back to 1992.

http://www.ietf.org/rfc/rfc1323.txt

Among those, TCP Window Scaling Option contributes faster packet transfer by controlling receiving window dynamically inside the network adapter. This boosts the rate of data transfer to next level. A single server can significantly increased its network capability by turning this feature on.

Somehow, this has been seen as industry standard for years. People argued that it still has not been implemented well on some routers and causes all sort of problems in basic TCP/IP communication.

A blogger pointed out that some router would reset a vital parameter during TCP communication and lead to misunderstanding by the computers at both ends.

http://inodes.org/2006/09/06/tcp-window-scaling-and-kernel-2617/

In this case, people would normally not aware of the problem until they realized that they couldn't access some web sites and think the sites might be down for service.

There might be some broken routers or switches along the pathway to the target computer whereas they might been poorly managed and finally the doomsday comes. It might also be a long time ago since the network administrator updated the firmware on their routers. So, what about your side? Can you do something to ease that problem even you know that their router won't last long? For the best interests of the end users, we still need to find a way to sort this out.

Okay. In order to get TCP Window Scaling working, TCP Window Scaling Option must be turned ON from both ends. Either one of them has turned it OFF, TCP Window Scaling would not happen. Nowadays, this basic TCP feature might possibly turned on at the client side. Therefore, to sacrifice a bit of your server performance, you need to turn off TCP Window Scale Option on your server. What I say a bit could means huge difference of the user experience at far side. Depending on the actual server performance, it might take longer time to transmit the same set of data packets with TCP Window Scale Option OFF.

If all these don't work for you, then check your browser settings or hardware like network adapter. You may find a reason for this.

Reference materials can be found in the following links:

http://prowiki.isc.upenn.edu/wiki/TCP_tuning_for_broken_firewalls

http://wiki.squid-cache.org/KnowledgeBase/BrokenWindowSize

http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/