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. The IP-addresses corresponding to these networks are 134.58.x.0, where x ranges from 39 to 47. These networks are allocated to different zones, with different access rights. For more information about the network topology and different (security) zones, consult the documentation about the firewall and the D(e-)M(ilitarized) Z(one).

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. kotnet, a network of another department, faculty or university, 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 IMAP (for reading your E-Mail), SMTP (for sending your E-Mail), 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.

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 4 such VPN's:

  • our own, departmental OpenVPN (recommended VPN):
  • our own PPP-over-SSH VPN (not recommended):
    • needs ppp so probably only on MacOS-X and Linux
  • the KULeuven-wide SSL-VPN(not recommended for, see below): 
    • Java and browser based, so in principle platform independent, but you need some 32-bit browser and experience shows it only works reliably on Microsoft Windows
    • Endpoint is central KULeuven extranet server so still outside the departmental firewall ... some internal services are accessible but not all, so YMMV
  • SSH and SSH-tunneling (see below): every platform that has a ssh client with tunneling capabilities
    For the more adventurous there are a number of additional ways with which you can build you own VPN to our department. (documentation only accessible from within departmental networks - only in dutch - only for the not-so-faint-hearted who are willing to read and configure technical stuff)
What is most suitable for you?
  • By using our own OpenVPN (or PPP-over-SSH VPN), 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; they are rather complete and transparent VPN's.
    • On All Platforms, you can use our own OpenVPN, therefore this is probably the recommended way to go.
    • On Apple MacOS-X and Linux, you can use our own PPP-over-SSH
  • On Microsoft Windows (but some say it also works on MacOS), you can use the KULeuven SSL-VPN, but that probably doesn't help much if you need access to departmental services. The KULeuven SSL-VPN is hosted on a central KULeuven ICTS service and thus still outside the departmental firewall. You can use the KULeuven SSL-VPN when you need to access KULeuven services to which external access is limited or when you need to access external services with which the KULeuven has an agreement (publication databases/sites, ...)
  • SSH tunneling has both a disadvantage:
    • you need to change the URL's pointing to internal services and replace the real (internal) hostname by 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


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.
  • When using the KULeuven SSL-VPN you are still outside the networks of the department of Computer Science because it is a service from central KULeuven ICTS. We have configured the departmental firewall such that the KULeuven SSL-VPN connections have more access to internal departmental services, but not unlimited of course ... so you'll probably be able to get to most of the services you need, but for some (private or less used departmental service) you might need to ask usk to open up that service to the KULeuven SSL-VPN as well in our firewall configuration.


Besides our own OpenVPN, PPP-over-SSH VPN and the KULeuven wide SSL-VPN, 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)
    In the past you needed to use tunnels to read and/or send your E-Mail, but nowadays, our E-Mail servers are accessible from anywhere in the world directly, so without having to use such SSH tunnels.

On the SSH pages, you can find a number of SSH clients for various platforms and explanation about how to connect, transfer files and create tunnels for the different services.

  • For Windows, you can even find an SSH client that fits on a single floppy. You can take this floppy with you and use it on computers where no SSH client is installed. Or you can download it to a directory and use it from there.
  • There is also a Java implementation of an SSH client. You can use it on every computer that has a JVM (Java Virtual Machine).


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.
  • tunnel the services you need through that connection.
  • configure your local client for each specific service to look for that service on instead of on the real server.
  • use a secure way to transfer your files (i.e. scp and/or sftp)


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 -L -L

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

  • fill in 10080 (or 10443) in the Source Port field
  • fill in (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:


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

This gives access to your out-of-office and/or procmail configuration using the above ssh tunnel and thus from anywhere in the world.

For more information about tunneling, please read the 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 create 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 110)
    where port-number is any of the ports in the above table 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 establish your SSH connection including tunnels. Then try to connect to the calendar service using the usual calendar client. If this succeeds, close the calendar client again and then execute the following commands on the machine you connected to (usually ... you can of course use the ssh session you just started for this !

    • Determine your local IP address or host name using:
        who am i
      Your local IP address or host name is displayed between the brackets.
    • Try to connect to the calendar tunnel on your machine using:
        telnet the-name-or-ip-address-of-your-machine 5730
    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 !