Configuring access from outside your institution

When a student connects to a lab session, and particularly a VM within that lab session, WLab determines the VM’s IP address and then builds a web page with the VNC client application embedded. Part of this web page is a parameter to the VNC applet which specifies the IP address of the VM, so as a VNC connection can be made to it.

This is fine if the student’s client computer can “reach” this IP address, but in many cases – and with certainty if they are running their lab from outside your institution – there will be no direct route to the address. This is illustrated in the diagram below. Also shown in the diagram is the traditional method of creating a route through a firewall so that external clients can access an internal web server. One can thus easily arrange external access to the web application aspect of WLab. However, one cannot do the same for the dozens of VMs that WLab entails. Aside from the security implications, these addresses are not consistent and will frequently change.

In order to provide a route through institutional firewalls to WLab VMs, we have made use of an adapted instance of the Jumpgate project (http://jumpgate.sourceforge.net). Jumpgate runs on a server with a static IP address behind the firewall. A single external port is routed to a specified internal port on this server. Jumpgate then dynamically routes traffic through to the appropriate WLab VM:

How to use Jumpgate with WLab

If you are using OS X or Windows as your platform for your Jumpgate server, download the appropriate version of Jumpgate for your platform:

Unzip the zip file in a convenient location on the server where Jumpgate will be located.

On OSX, the zip file will contain a single executable simply called jumpgate. On Windows, you will see jumpgate.exe and cygwin1.dll – the DLL file must be kept in the same directory as the EXE file.

On Linux, because of the many differences between distributions, you should build Jumpgate from source. Follow these instructions to do so:

• In a command line or terminal, create a work directory (e.g. JumpgateSource directory and cd to it.
• Type svn co svn://wlab.paulneve.com/Jumpgate . - be sure to include the period . at the end of that command!
• Type make generic
• You should end up with an executable file called jumpgate in the directory.

You can now start Jumpgate with the command

jumpgate –l [port number] –i –p [password]

or on Windows:

jumpgate.exe –l [port number] –i –p [password]

The port number can be any number that is not being used by other network services on the server running Jumpgate. Higher (four digit) values are recommended to avoid unexpected “collisions” with services you may not have taken into account. The password can be whatever you like and pertains to Jumpgate only. It is to ensure that if anyone were to telnet directly to your Jumpgate server, who had read the source code and knew what response it was expecting, could not then connect to other machines on your internal network.

You should now configure an external IP address and port on your firewall. This will need to route traffic received through to the internal IP address of the Jumpgate server on the port you specified in the Jumpgate command line.

Finally, you need to configure WLab’s application-properties.xml as follows:

It should be emphasised again that the port and server settings in the configuration file should correspond to the external address configured on your firewall, not the internal address of the Jumpgate server.

Note that Jumpgate should stay resident in memory. However, it does not specifically have a shutdown parameter and will continue to run unless terminated using whatever means your operating system provides (e.g. the kill command on a UNIX-like OS, or using End Task in Task Manager on Windows).