11/9/2006
Eric Low

I needed a way for users to connect to a remote Windows Desktop, similar to a terminal server. It had to be fast in terms of screen updates and actual machine speed (which means VNC was out of the question, since screen draws are slow as hell), yet it also had to provide adequate security (meaning SSH with a very high-grade encryption).

After looking into different products for remote Windows connections, I decided that Remote Desktop (the one that actually COMES with Windows XP) was the best solution - more than anything, it's FAST, but it also provides local drive mappings onto the virtual machine, as well as local printer redirection. No sense in paying $200 for a third-party product that could accomplish the same thing, even though it meant that the machines had to run XP! (I looked long and hard for a solution that could be run on Windows 2000).

Remote Desktop, however, uses low-grade RC4 encryption (an algorithm that has been broken for years) and uses a mere password for authentication. I like to require public/private keypair certificates!

Rather that set up individual physical machines for each server, I decided to make them virtual. This allowed me to set things up as if I had three or four physical machines running through a Linux firewall/gateway, but to actually have them running on that Linux firewall gateway itself. The only fast virtual machine product I've ever found for Linux is VMware, so I went with that. VMware Server is a free product now, and provides some more advanced featues than VMware Workstation or Player, so I installed that using the following procedure:

In order to give the virtual machines bridged networking, but still be able to control it, I told the machines to use a specific network device, /dev/vnmet0 (note that this interface does not show up in ifconfig). I then ran vmware-config.pl and set up vmnet0 to use the dummy0 interface.

I used SSH port forwarding in order to tunnel Remote Desktop traffic through SSH and thus, provide adequate security. A Windows user would need to log onto the remote gateway with Putty (using SSH2 and a 2048-bit Diffie-Hilman key), with port forwarding enabled, and then the gateway would redirect them to a free Remote Windows VM.

* SSH port forwarding does NOT follow the routing table! It will send everything through localhost, rather than the proper interface, if the IP address exists on the maching AT ALL.

To solve this, I applied this patch, which removes the part of the LVS code that ignores the loopback address.

* LVS uses its OWN connection tracking scheme, completely separate from Netfilter. Therefore, iptables CANNOT see LVS statefulness (established/related packets). To solve this, I applied this patch, which forces the return packets through Netfilter.