SSH tunneling is a really neat all-purpose technique for getting TCP/IP traffic securely from you to a remote server.
Once you know how to setup an SSH tunnel for one type of traffic, it’s easy to setup tunnels for other services as the only thing that changes are the TCP ports involved in the tunnel. This post shows the typical setup of a SSH tunnel through to a VMWare Server.
I believe VMWare Server has built-in support for SSL, which means it’s not necessary to resort to SSH tunneling for security, however tunneling can have other benefits, such as allowing you to:
- Work-around firewalls that aggressively block outbound traffic
- Access your VMWare Server from a remote location without having to directly expose it at your network’s boundary
Before you get too excited by the way, I should remark on the speed. My experience of VMWare Server over SSH is that it is slooow. Don’t expect to be driving any Windows guest machines over this type of connection. Tasks like creating new virtual machines, restarting machines etc are quite do-able though. For remote access to guest operating systems you should still SSH / VNC / Remote Desktop directly to the guest machines.
To be able to tunnel VMWare Server traffic over SSH, you must first have a SSH server set up somewhere that you can connect to. That SSH server must in turn have unencumbered access to the host machine running VMWare Server on the port that VMWare Server is listening on, which is port 902 by default. Probably the most common setup would be to use a SSH server on the same network or even the same host as the VMWare Server, but other configurations are possible too.
So now that we can establish an SSH connection we can define a tunnel to pipe traffic between our local machine and the remote VMWare Server over that connection.
In PuTTY define a connection profile that will let you connect to your remote SSH server. Most likely you have already created such a profile. To get to the Tunnels configuration page, select the Tunnels category on the left.
Now, when you’re defining a tunnel, you define the start and end point. The start is just a TCP port on your local machine that you will be able to connect to. The end is defined from the perspective of the SSH server you’re connecting to - you have to tell the SSH server where to send the traffic.
The port number for the start of the tunnel can be anything you like, as long as it’s not being used by some other service. Normally I’ll pick a high port number that is similar to the port of the service I’m tunneling to. By default VMWare Server listens on port 902, so I’d pick something like 33902 for the start point.
To check if a given port is in use, grab a command prompt and type
netstat -an | more
Then look carefully through the list of listening connections to see if the port number you want to use is already being used. The port number is the bit after the colon in the Local Address column. Here you can see nothing is using port 33902 on my workstation:
The following example shows a typical tunnel configuration. We’ve defined the start point of the tunnel to be port 33902 (in other words 127.0.0.1:33902). For the end point, the remote SSH server needs to send it’s traffic to port 902 on 192.168.0.12, which is the host where VMWare Server is running.
Once you’ve defined the tunnel, save your profile and open the SSH server. Once the connection is established, do another netstat and look for a listening port on whatever you defined as your start port number. Here you can see my machine is listening for traffic on port 33902:
VMWare Server Connection
Great! So the final step is to connect the VMWare Server console to the remote server through the tunnel. This is done as normal, but the address will now be the start point of the SSH tunnel, in our case: 127.0.0.1:33902
The SSH tunnel forwards all traffic to and from the VMWare Server console to the remote VMWare Server.
If you’re on a slow link, give the VMWare Server console plenty of time to connect. I occasionally have to use VMWare Server over a link that gets me 10 to 20 kbps of traffic. Under these conditions it takes VMWare Server up to and beyond a full minute to connect and retrieve information about the state of guest machines, and during this time it looks like it’s hung.
If the console really can’t connect to the VMWare Server, then you need to check each part of the connection step by step:
- Transport - Is your link via SSH up? The good think about whacking a SSH tunnel through PuTTY is that you also get the shell so you can do a quick ls -l or something to see if you’re connection is there.
- Tunnel - Check the output from netstat to make sure your computer is listening on the port you configured for your SSH tunnel’s start point
- Server - Make sure the server is up and listening on it’s port (default 902). If you have shell access to the machine running the VMWare server, then the netstat command can be used here again to check that it is listening for traffic. The netstat command is present on Linux / UNIX as well.