Remote Access

  • This page describes access to the departmental networks and computers on them.
  • It is only useful if you have an account on the Intranet computers of the department.
  • So most probably it is not useful if you only have a student account (m, r, or s-number).
    • Consult the documentation about student computer labs if you are looking for help about which machines to use as a student and how to use them.
    • The only student accounts that have access to the departmental Intranet are master student accounts that have been granted such access explicitly ... if you don't know for sure that you have it, you can be sure that you don't have it.

The Department of Computer Science maintains several networks to connect computers to. These networks are allocated to different zones, with different access rights.

Most computers of our department are allocated to zones with a high degree of access to the different services of/on our computers.
Computers not belonging to our department do not have the same level of access to our services for obvious (security and privacy) reasons.

Thus, when you are connected to another network (i.e. your home-network, a network of another department, faculty or university, a public hot-spot, the internet in general) you can of course still access the services and data on our computers, but you must be prepared for a number of additional safety precautions.

Public and private services

Some of the services our computers offer, are meant to be used publicly. The web server(s) are a prime example of these. Anybody can access them from anywhere in the world without special actions.

Other services are private (i.e. only meant for members of the department, not for public use) but can be used from the Internet without special precautions. Our SSH and public LDAP/directory service are like this.

And there are of course also services that are private and can only be used from within the department or via additional safety precautions. Accessing your home directory via NFS or Samba are good examples. To access these from outside the departmental (cabled) networks, you must use our V(irtual) P(rivate) N(etwork) service.

Virtual Private Network

To use the (internal private) services of our computers from outside the department, you need to establish a safe connection. This safe connection serves 2 purposes :

  • to authenticate you as a valid user of our systems and their services.
  • to protect the connection itself from eavesdropping by third parties by encrypting all communication.

Such a safe connection is established by means of a V(irtual) P(rivate) N(etwork) between the computer you are working on and the computers of the Department.

For the moment you have a choice between 2 such VPN's:

  • our own, departmental OpenVPN (recommended VPN): Instructions and config files here
  • SSH and SSH-tunneling (see below): every platform that has a ssh client with tunneling capabilities

The available OpenVPN and SSH servers and ports of OpenVPN and SSH services are shown on the services overview.

  • There is also the KU Leuven VPN service but because this it still outside the departmental firewall, it doesn't help in getting access to departmental services. It might help for other uses though - YMMV.
What is most suitable for you?
  • By using our own OpenVPN, you can really work at home or elsewhere as if you are at your office: you don't need to change any URL's to get to where you want/need.
    • it works on all platforms that are supported by OpenVPN, of which there are a lot, therefore this is probably the recommended way to go.
  • SSH tunneling has both advantages and disadvantages:
    • you need to change the URL's pointing to internal services and replace the real (internal) hostname by localhost.cs.kuleuven.be where needed
    but also clear advantages:
    • it is less setup and easier to do on the spot once you get acquainted with how it works
    • it works with most ssh client software, so on all platforms

CAVEATs

There are some caveats you need to be aware of when using a VPN to access departmental services from outside the department ... we are confident that these issues are minor ones which most users will not notice, not even when using the VPN on a daily basis ... for those who do (by having to use an unreliable local network connection or by using some internal departmental service that isn't used widely or often) just be aware that the problems below might pop up ... your mileage may vary.

  • When accessing departmental services from outside departmental networks, there is one element that might cause some troubles: DNS. The departmental DNS service uses 2 views: an internal one and an external one. When referring to departmental services from outside the departmental networks, the external view is used; when referring from inside the departmental networks, the internal view is used. There are subtle differences between the views, so it is not guaranteed that each and every departmental service is indeed accessible and operational from outside departmental networks. We do our best to make all services available as much as possible, but if something doesn't seem to work the way it should, please let us know so we can look into it.
  • When establishing a VPN connection, you are of course still using you own, local network connection for the real network access. The VPN is just a safe tunnel over this otherwise untrustworthy network. If something happens to your real network connection, your VPN will of course be lost as well. Often, you will need to restart the VPN connection after your real network connection re-appears ... even if your network connection was only gone for a second or so. Some applications won't notice that your network connection and VPN dis- and re-appeared, but other applications will have to be restarted as well.

SSH and its Tunnels

Besides our own OpenVPN, you can also build your own, private VPN by using SSH to tunnel services (also called port forwarding).

You need to connect to one of the public departmental ssh servers or to a computer of your research group using an SSH client.
With/via this SSH connection, you can access the services you want to connect to :

  • a secure (encrypted) ftp client to access your files.
  • secure (encrypted) tunnels to :
    • visit internal web server(s)
    • access the print server(s)

Overview

To access services on/of the computers of the department of Computer Science, you need to :

  • have an SSH client available on your local computer
  • establish an SSH connection to some computer of the department (e.g. ssh.cs.kuleuven.be).
  • tunnel the services you need through that connection.
  • configure your local client for each specific service to look for that service on localhost.cs.kuleuven.be instead of on the real server.
  • use a secure way to transfer your files (i.e. scp and/or sftp)

Example

A typical example of such a SSH/VPN setup for remote access to departmental services might be:
(take care, the below line is probably wrapped in/by your browser)

    ssh -l your-username ssh.cs.kuleuven.be -L 10480:iwww.cs.kuleuven.be:80 -L 10443:iwww.cs.kuleuven.be:443

For putty, you can/should configure your tunnel configuration with:

  • fill in 10480 (or 10443) in the Source Port field
  • fill in iwww.cs.kuleuven.be:80 (or 443) in the Destination field
  • press the Add button (do not forget this !)
  • have a look at this screen grab to see what it should look like

With the above tunnels, you can access the internal web server with:

  • http://localhost.cs.kuleuven.be:10480/
  • https://localhost.cs.kuleuven.be:10443/

You can of course give a complete URL to directly access a specific web URL as in:

This gives access to your disk space without quota overview using the above ssh tunnel and thus from anywhere in the world.

For more information about tunneling, please read the somewhat outdated SSH Tunneling pages.

In any way, please make sure that your SSH tunnels are only accessible from your own machine: any configuration items such as Allow remote hosts to connect to tunnel should be configured such that only localhost can connect to any tunnel you set up ! If your tunnels are accessible for other machines as well, you risk creating huge holes in the departmental security ... so please take care.
For more detail, see the SSH pages and/or the page describing your SSH client in detail.

If you want to test your own machine to check whether your ssh tunnels are safe, the only way to get a reliable result is by testing from a second machine on the same network segment/cable. From such a second machine try to connect to such a tunnel by means of a simple telnet: 

    telnet the-name-or-ip-address-of-your-machine port-number
    (e.g. telnet cable-195-162-219-162.upc.chello.be 10480)
where port-number is any of the (local) ports in the above examples which you have configured. If these connections succeed, your SSH tunnels are not secure, if these connections are rejected, your SSH tunnels are secure.

If you do not have such a second machine on the same network segment/cable available, you can try the following simple, but only negative test (only negative because it will only show that you are not safe, it cannot show that your tunnels are secure indeed):

  • First determine your local IP address or host name of the machine you are currently using: 
      who am i
    Your local IP address or host name is displayed between the brackets.
  • Then establish your SSH connection including tunnels.
  • Then try to connect to (one of) the local port(s) of the tunnels. You can use the (machine of the) ssh session you just started for this: 
      telnet the-name-or-ip-address-of-your-machine 10480
If this connection succeeds, your tunnels are NOT secure ... please change your SSH configuration as soon as possible.
If this connection does not succeed, you still are not sure your tunnels are secure because it might have been rejected by some firewall between your own machine and the machine you connected to ... other machines, that can connect to your machine without this firewall might very well be able to connect to your tunnels anyway !